Quand fine-tuner (vs RAG et prompt)

Pourquoi ce chapitre est le plus utile

Trois techniques permettent d'adapter un modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire à un usage métier : le prompt engineeringpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire, la génération augmentée par récupérationRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire (RAG) et le fine-tuningFine-tuningIAAjustement des poids d'un modèle pré-entraîné sur un jeu de données spécifique pour adapter son comportement à un domaine ou une tâche cible.Voir dans le glossaire. Elles ne sont pas interchangeables et ne répondent pas au même problème. Confondre ces registres conduit à des projets qui coûtent cher pour un résultat décevant — un fine-tuningaffinageIAPoursuite de l'entraînement d'un modèle existant sur des données propres à un usage. Il enseigne une manière de répondre, non des connaissances fiables — d'où la préférence pour le RAG en entreprise.Voir dans le glossaire lancé pour résoudre un problème de fraîcheur documentaire, ou un RAG empilé pour corriger un ton que seul un réentraînement peut changer durablement.

Ce chapitre pose la grille de décision qui structure tout le reste de la formation. Les chapitres suivants détaillent la mécanique du fine-tuning — LoRALoRAIAMéthode d'adaptation légère d'un LLM : seules de petites matrices de rang faible sont entraînées, ce qui réduit fortement le coût GPU par rapport au fine-tuning complet.Voir dans le glossaire, QLoRA, full fine-tuning, RLHF — mais celui-ci répond à une question plus en amont : faut-il fine-tuner, et pour résoudre quel type de problème exactement.

Les trois leviers d'adaptation

Un modèle préentraîné encode une compétence générale figée au moment de l'entraînement. Trois leviers permettent de l'orienter vers un usage précis, et ils agissent à des niveaux différents du système.

Le prompt engineeringprompt engineeringIADiscipline consistant à concevoir des instructions précises pour guider un LLM vers la réponse souhaitée. Elle inclut les techniques de chain-of-thought, few-shot, rôle et format de sortie.Voir dans le glossaire agit au moment de l'inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire, sans toucher au modèle : instructions, exemples en contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire (few-shotFew-shotIATechnique de prompt où l'on fournit quelques exemples entrée-sortie pour guider le modèle sans réentraînement.Voir dans le glossaire), formatage de sortie. C'est le levier le moins coûteux et le plus réversible — on change un prompt, l'effet est immédiat et sans risque de régression ailleurs.

Le RAG injecte, toujours au moment de l'inférence, des documents pertinents récupérés dans une base externe. Le modèle reste inchangé ; c'est le contexte qui s'enrichit dynamiquement à chaque requête.

Le fine-tuning modifie les poids du modèle par un réentraînement sur un jeu de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire spécifique. C'est le seul levier qui touche la mémoire paramétrique elle-même, et donc le comportement par défaut du modèle, même en l'absence d'instruction explicite dans le prompt.

Le prompt engineering et le RAG modifient ce que le modèle voit au moment de répondre. Le fine-tuning modifie ce que le modèle sait faire par défaut. Un problème de contexte insuffisant ne se résout pas par un réentraînement ; un problème de comportement systémique ne se résout pas en ajoutant des documents dans le prompt.

Le prompt engineering : premier réflexe

Avant d'envisager quoi que ce soit d'autre, il faut avoir épuisé le prompt engineering. Ce n'est pas une politesse méthodologique : le prompt engineering résout, à coût quasi nul, une proportion étonnamment grande des problèmes qu'on croit devoir régler par un fine-tuning.

Un prompt bien conçu peut :

• Imposer un format de sortie strict (JSON, structure de rapport, gabarit d'e-mail)
• Fixer un registre de langue et un ton
• Fournir des exemples représentatifs (few-shot) qui cadrent le style de réponse attendu
• Décomposer une tâche complexe en étapes explicites (chain-of-prompting)

Ses limites sont également claires. Le prompt consomme de la fenêtre de contexte à chaque appel, ce qui a un coût en tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire et en latence. Les instructions longues sont parfois partiellement ignorées, en particulier quand elles entrent en tension avec des régularités fortement ancrées dans les données d'entraînement. Et un prompt ne donne au modèle aucune connaissance qu'il n'a pas déjà : il ne fait qu'orienter l'usage de ce qu'il sait.

Beaucoup d'équipes basculent vers le RAG ou le fine-tuning après un seul essai de prompt mal calibré. Avant de changer de levier, testez systématiquement : instructions plus explicites, exemples few-shot variés, découpageChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire de la tâche en étapes. Un gain de qualité de 20 à 30 points est courant simplement en resserrant le prompt.

Le RAG : injecter de la connaissance externe

Le RAG répond à un problème précis : le modèle doit raisonner sur une information qu'il ne possède pas en mémoire paramétrique, parce qu'elle est postérieure à son entraînement, propriétaire, ou trop volumineuse pour être mémorisée par descente de gradient (catalogue produit, base documentaire interne, réglementation qui change chaque trimestre).

Le mécanisme : une requête déclenche une recherche, souvent par similarité vectorielle, dans une base de documents indexés ; les passages les plus pertinents sont injectés dans le prompt ; le modèle génère sa réponse en s'appuyant sur ce contexte.

Le RAG est le bon choix quand :

• L'information change fréquemment (prix, stock, statut d'un dossier)
• La source doit rester traçable et citable (conformité, support client)
• Le volume de connaissance dépasse ce qu'un fine-tuning peut raisonnablement absorber
• On veut pouvoir retirer ou corriger une information sans réentraîner quoi que ce soit

Il a ses propres coûts : infrastructure de recherche (base vectoriellebase vectorielleIABase spécialisée qui indexe des embeddings pour retrouver rapidement les passages les plus proches d'une requête (cœur du RAG).Voir dans le glossaire, pipeline d'indexation), latence additionnelle, qualité de réponse dépendante de la qualité de la récupération. Un mauvais découpage de documents (chunking) ou une recherche peu pertinente produisent des réponses fausses avec la même assurance qu'une hallucinationhallucinationIAProduction par un modèle d'un énoncé faux formulé avec la même assurance qu'un fait établi. Le phénomène est structurel : le modèle optimise la vraisemblance, pas la vérité.Voir dans le glossaire pure.

Le RAG ajoute de l'information, il ne change pas la façon dont le modèle raisonne, structure ses réponses ou applique un ton. Si le problème est « le modèle ne suit pas notre méthodologie d'analyse » ou « le modèle répond dans un registre inadapté à notre marque », empiler des documents dans le contexte ne réglera pas le problème — c'est au contraire un signal en faveur du fine-tuning.

Le fine-tuning : modifier les poids

Le fine-tuning entraîne le modèle sur un jeu de données représentatif de la tâche cible, ce qui ajuste ses poids et donc son comportement par défaut, sans qu'il soit nécessaire de le rappeler à chaque prompt.

Il se justifie quand :

• Le comportement souhaité doit être systématique, même sur des prompts courts ou mal formulés par l'utilisateur final
• La tâche exige un format ou un raisonnement spécialisé, répété à très haute fréquence (classification, extraction structurée, génération dans un style de marque constant)
• Le volume d'appels rend le coût d'un prompt long (few-shot volumineux à chaque appel) supérieur, à l'échelle, au coût d'un entraînement ponctuel
• On veut réduire la taille des prompts et la latence associée en interne
• Le comportement à corriger touche au raisonnement ou au style implicite du modèle, pas à une connaissance factuelle changeante

Le fine-tuning ne résout pas un manque de connaissance factuelle volatile : un modèle fine-tuné sur un catalogue produit de janvier restera figé sur ce catalogue en juillet, sauf nouveau cycle d'entraînement. C'est une erreur fréquente en production : fine-tuner pour « apprendre » des données qui auraient dû rester dans une base RAG.

Un service client qui doit répondre en citant les bonnes conditions générales, mises à jour chaque mois, relève du RAG : l'information change, la traçabilité de la source est exigée. À l'inverse, un moteur qui doit classer 50 000 tickets par jour selon une taxonomie interne stable, avec un format de sortie strict et un raisonnement toujours structuré de la même façon, relève du fine-tuning : le comportement est stable, répété à très haute fréquence, et le gain de fiabilité justifie l'investissement.

Grille de décision

Combiner les approches

En production, les trois leviers cohabitent plus souvent qu'ils ne s'excluent. Un cas fréquent : un modèle fine-tuné pour adopter un format de réponse et un raisonnement structuré propre à un domaine (par exemple l'analyse de contrats), alimenté en parallèle par un RAG qui lui fournit les clauses spécifiques à chaque dossier, le tout encadré par un prompt système qui rappelle les contraintes de ton et de format à chaque appel.

La hiérarchie reste la même : le prompt cadre l'interaction, le RAG apporte la connaissance changeante, le fine-tuning ancre le comportement stable. Investir dans le fine-tuning ne dispense pas de soigner le prompt système ni la qualité de la récupération documentaire — ce sont des couches complémentaires, pas concurrentes.

Cette combinaison a aussi un intérêt économique. Un modèle fine-tuné pour produire directement un format de sortie strict réduit la longueur du prompt système nécessaire à chaque appel, ce qui compense en partie le coût de l'entraînement sur les volumes élevés. À l'inverse, garder la connaissance factuelle dans un RAG plutôt que de la faire mémoriser au modèle évite de réentraîner l'ensemble du système à chaque mise à jour de catalogue ou de réglementation. Le fine-tuning porte alors sur ce qui bouge peu — méthode, structure, ton — pendant que le RAG absorbe ce qui bouge souvent.

Un fine-tuning bien mené améliore la constance du comportement, mais un pipeline RAG mal conçu (chunking incohérent, index mal à jour) continuera de produire des réponses factuellement fausses, quelle que soit la qualité du modèle sous-jacent. Les deux chantiers s'évaluent séparément.

Erreurs fréquentes

Les erreurs de choix entre ces trois leviers reviennent presque toujours à confondre un symptôme avec sa cause : un modèle qui « se trompe » sur une donnée récente n'a pas le même problème qu'un modèle qui répond dans un ton inadapté à chaque réponse, même si les deux se manifestent par une insatisfaction identique côté utilisateur. Diagnostiquer correctement la cause avant d'agir évite la majorité des projets qui échouent à produire le gain attendu.

• Fine-tuner pour corriger un manque de données récentes : le problème est de fraîcheur, pas de comportement ; un RAG bien indexé coûte moins cher et se corrige en quelques minutes.
• Traiter un RAG mal indexé comme un problème de modèle : avant de blâmer le modèle, vérifier la qualité du chunking, la pertinence de la recherche et la couverture de l'index.
• Sauter l'étape prompt engineering : lancer un fine-tuning sans avoir sérieusement testé un prompt optimisé revient à payer pour un gain qu'on aurait pu obtenir gratuitement.
• Fine-tuner sur un jeu de données trop petit ou non représentatif : le modèle surapprend des artefacts du jeu d'entraînement et régresse sur des capacités qu'il possédait déjà (catastrophic forgetting).
• Ne pas construire de jeu d'évaluation avant/après : sans mesure comparative sur des cas réels, il est impossible de savoir si le fine-tuning a réellement amélioré le comportement ciblé ou seulement déplacé le problème.

Checklist avant de se lancer

1. Le problème a-t-il été formulé précisément : fraîcheur de l'information, comportement systémique, ou simple cadrage de sortie ?
2. Un prompt optimisé (instructions, few-shot, découpage) a-t-il été testé et mesuré avant d'écarter cette option ?
3. Si la connaissance manque : cette connaissance est-elle volatile, volumineuse, ou nécessite-t-elle une traçabilité de source ? Si oui, RAG.
4. Si le comportement doit changer durablement, à haute fréquence, indépendamment du prompt fourni : fine-tuning.
5. Un jeu de données d'entraînement représentatif et suffisant est-il disponible ou constituable ?
6. Un jeu d'évaluation indépendant existe-t-il pour mesurer objectivement le gain après entraînement ?
7. Le coût de maintenance (réentraînement périodique, gestion de version du modèle) a-t-il été budgété, pas seulement le coût initial ?

Cette grille ne dispense pas d'itérer : un projet démarre souvent par un prompt, migre vers un RAG quand la connaissance devient trop volumineuse ou trop changeante, et n'envisage le fine-tuning qu'une fois le comportement cible stabilisé et mesuré sur un volume d'usage suffisant pour justifier l'investissement.