La question que peu d’entreprises se posent avant d’investir dans le fine-tuning
Lorsqu’un dirigeant découvre qu’un modèle d’IA peut être entraîné sur les données de l’entreprise pour « parler la langue du métier », la réaction habituelle est l’enthousiasme. Le fine-tuning a tout de la solution définitive : un modèle qui connaît nos produits, notre terminologie, nos processus.
Le problème est que le fine-tuning coûte cher, demande une maintenance continue et, dans bien des cas, n’est pas l’outil adapté au problème à résoudre. Avant d’y investir, il vaut la peine de comprendre quand il a réellement du sens et quand il existe des alternatives plus efficaces.
Trois approches pour adapter un LLM : quand utiliser chacune
Prompt engineering
C’est le moyen le plus rapide et le moins coûteux d’adapter le comportement d’un LLM. Avec des instructions soigneusement conçues dans le prompt (contexte, rôle, format de réponse, exemples en few-shot), on obtient des comportements très précis sans toucher au modèle. C’est le bon point de départ pour presque tous les cas d’usage : si le prompt engineering résout le problème, il n’y a aucune raison d’aller plus loin.
RAG (Retrieval-Augmented Generation)
Lorsque le modèle a besoin d’accéder à des informations propres à l’entreprise (catalogues produits, documentation technique, base de connaissances interne, historique des dossiers), le RAG fournit ce contexte au moment de la requête, sans réentraîner le modèle. C’est la bonne solution dans la plupart des cas où le problème tient à l’accès à la connaissance, et non au style ou au comportement du modèle.
Fine-tuning
Le fine-tuning se justifie lorsqu’aucune des deux approches précédentes ne suffit. Plus précisément : lorsque le modèle doit adopter un style de réponse très particulier, difficile à saisir dans des prompts ; lorsqu’il faut améliorer l’efficacité de l’inférence en réduisant la taille du prompt système ; ou lorsque le cas d’usage exige un comportement que le modèle de base n’a pas nativement et qu’il faut renforcer avec des milliers d’exemples du bon style.
Quand le fine-tuning apporte une valeur réelle
Classifieurs et extracteurs spécialisés
Pour des tâches très ciblées, comme classer des documents dans des catégories propres à l’entreprise, extraire des entités définies en interne ou détecter dans des textes des schémas absents du langage courant, le fine-tuning d’un petit modèle surpasse en efficacité (vitesse, coût, précision) les grands modèles généralistes. Le fine-tuning de modèles de classification sur des données propres étiquetées est le cas d’usage au ROI le plus démontré.
Modèles au style de communication très marqué
Si l’entreprise a un ton de communication très particulier (technique, formel, très concis, avec une terminologie propre) et a besoin que le modèle le reproduise de façon constante, le fine-tuning sur des exemples du bon style peut obtenir des résultats que le prompt engineering n’atteint pas de manière stable.
Réduction des coûts à grande échelle
Pour les applications qui traitent des millions d’appels par jour, le fine-tuning d’un petit modèle sur une tâche précise peut revenir bien moins cher qu’un grand modèle généraliste avec de longs prompts. Cela suppose une analyse des coûts à l’échelle ; ce n’est pas pertinent pour de faibles volumes.
Coût, données et maintenance : ce dont on parle rarement
Le fine-tuning exige des données étiquetées de qualité (généralement de quelques centaines à quelques milliers d’exemples bien annotés pour les LLM, davantage pour les modèles de vision ou de classification), du temps de GPU pour l’entraînement (qui a un coût direct), une évaluation rigoureuse du modèle obtenu et un réentraînement périodique à mesure que le domaine évolue.
Un modèle affiné n’est pas un actif figé : il demande de la maintenance. Si le catalogue de produits change, si la terminologie évolue, si les cas d’usage du modèle s’élargissent, il faut le réentraîner. Sans pipeline de MLOps pour soutenir ce cycle, le modèle se dégrade avec le temps.
Questions fréquentes
Combien d’exemples d’entraînement faut-il pour le fine-tuning d’un LLM ?
Pour des LLM comme ceux d’OpenAI ou Llama, le fine-tuning supervisé peut montrer des améliorations avec seulement cent à cinq cents paires exemple-réponse de grande qualité pour des tâches très ciblées. Pour obtenir une constance solide sur des tâches complexes ou très variables, il en faut plusieurs milliers. La qualité des exemples compte plus que leur nombre : des exemples bien annotés valent mieux que des milliers d’exemples médiocres.
Fine-tuning d’un modèle open source ou d’un modèle commercial accessible par API ?
Les deux options sont viables. Le fine-tuning de modèles accessibles par API (OpenAI, Anthropic) est plus simple techniquement, mais les données d’entraînement sont envoyées au fournisseur. Le fine-tuning de modèles open source (Llama, Mistral, Qwen) donne un contrôle total sur les données et sur le modèle obtenu, mais exige une infrastructure GPU et davantage d’expertise technique. Pour des données sensibles, le fine-tuning en local est généralement la bonne option.
Quand choisir le RAG plutôt que le fine-tuning ?
Presque chaque fois que le problème relève de l’accès à la connaissance. Si le modèle doit connaître le prix d’un produit, le contenu d’un contrat ou les étapes d’une procédure, le RAG est plus souple, plus facile à mettre à jour et plus explicable que le fine-tuning. Le fine-tuning n’est pas une base de données : l’information injectée dans les poids du modèle est difficile à mettre à jour et ne peut pas être retrouvée de façon transparente. Le RAG maintient la connaissance en dehors du modèle, là où elle peut être gérée explicitement.