Décision : RAG vs fine-tuning

Pourquoi cette décision structure tout le projet

Après huit chapitres consacrés aux techniques de 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 — 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, instruction-tuning, alignement, évaluation — il reste une question préalable que beaucoup de projets règlent trop vite : fallait-il vraiment fine-tuner ? Dans une proportion significative des cas rencontrés en production, un système de retrieval-augmented generation (RAGRAGIATechnique 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) bien construit aurait résolu le problème plus vite, moins cher, avec moins de risque opérationnel.

Ce chapitre ne cherche pas à départager RAG et 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 dans l'absolu — les deux approches répondent à des besoins différents et se combinent fréquemment. Il propose une grille de décision opérationnelle, une cartographie des architectures hybrides, et une feuille de route pour arbitrer sans y passer des semaines de réunions.

La première question à se poser n'est pas « quelle technique est la plus performante » mais « la nature du problème relève-t-elle d'un déficit de connaissance ou d'un déficit de comportement ». Le RAG répond à un déficit de connaissance récupérable : le modèle sait raisonner mais ne dispose pas de l'information à jour. Le fine-tuning répond à un déficit de comportement, de format ou de raisonnement spécialisé : le modèle dispose peut-être déjà de l'information mais ne l'exploite pas de la bonne façon. Confondre les deux est la première cause de projets qui échouent après plusieurs mois d'investissement.

Rappel des deux mécanismes, en une phrase chacun

Le RAG injecte, 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, des documents pertinents récupérés dans une base externe — le plus souvent un index vectorielbase 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 — dans le 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 fourni au modèle, qui génère sa réponse à partir de ce contexte augmenté. Le fine-tuning modifie les poids du modèle, intégralement ou via des adaptateurs légers comme LoRA, pour qu'il internalise durablement un comportement, un style ou un vocabulaire.

Cette différence mécanique a des conséquences directes et souvent sous-estimées. Un RAG peut être mis à jour en remplaçant un document dans l'index, sans aucun ré-entraînement : la fraîcheur de l'information est quasi instantanée. Un modèle fine-tuné, à l'inverse, fige une connaissance au moment de l'entraînement ; toute évolution de cette connaissance nécessite un nouveau cycle d'entraînement, avec son coût et ses délais. En contrepartie, le fine-tuning agit sur la façon dont le modèle raisonne et s'exprime — quelque chose qu'un simple ajout de contexte ne peut pas garantir de façon fiable.

La matrice de décision

Le tableau suivant synthétise les critères les plus déterminants observés sur des projets réels. Aucun critère isolé ne suffit à trancher : c'est leur combinaison qui oriente la décision.

Le coût total de possession, pas seulement le coût d'entraînement

Comparer RAG et fine-tuning uniquement sur le coût de la phase d'entraînement conduit à une décision biaisée. Le coût total de possession inclut au minimum quatre postes pour chaque approche.

Pour un RAG : le coût d'ingestion et de 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 des documents (chunking), le coût de génération et de stockage des embeddingsembeddingIAReprésentation numérique dense d'un texte, d'une image ou d'un objet dans un espace vectoriel, utilisée pour la similarité et la recherche sémantique.Voir dans le glossaire, le coût d'hébergement de l'index vectoriel à l'échelle, et le coût de maintenance du pipeline de recherche (ré-indexation, gestion de la pertinence, filtrage). Ces coûts sont largement récurrents et proportionnels au volume de documents et au trafic de requêtes.

Pour un fine-tuning : le coût de constitution et d'annotationannotationIAProcessus d'étiquetage manuel des données d'entraînement par des experts humains. La qualité de l'annotation conditionne directement les performances du modèle d'apprentissage supervisé.Voir dans le glossaire du corpus d'entraînement — souvent le poste le plus sous-estimé —, le coût de calcul de l'entraînement lui-même (nettement réduit avec LoRA ou QLoRA par rapport à un fine-tuning complet), le coût d'évaluation et de validation avant mise en production, et le coût de chaque cycle de ré-entraînement lorsque le comportement doit évoluer. Ces coûts sont concentrés en pics plutôt que lissés dans le temps.

Un prototype RAG peut généralement être mis en place en quelques jours avec un index vectoriel basique et un promptpromptIAConsigne 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 de base. Il sert de référence de comparaison (baseline) : les échecs qu'il ne parvient pas à corriger, malgré un contexte pertinent et bien formé, sont ceux qui justifient réellement un investissement en fine-tuning. Cette approche évite d'engager un cycle d'entraînement pour un problème que de meilleurs documents ou un meilleur découpage auraient suffi à résoudre.

Les pièges classiques de mauvaise orientation

Quatre erreurs reviennent avec une régularité frappante dans les projets qui doivent revoir leur architecture après plusieurs mois.

Fine-tuner pour injecter des faits volatils. Une équipe fine-tune un modèle sur un catalogue produit, des tarifs ou des disponibilités de stock. Chaque mise à jour de ces données impose un nouveau cycle d'entraînement, ce qui devient vite intenable à un rythme hebdomadaire, voire quotidien. Le RAG, où la mise à jour se limite à remplacer un document dans l'index, est structurellement mieux adapté à ce cas.

Attendre du RAG qu'il change le comportement profond du modèle. À l'inverse, une équipe tente de faire adopter un ton, une structure de réponse stricte ou un raisonnement en plusieurs étapes uniquement via des instructions dans le prompt et des exemples en contexte. Le résultat est instable : le comportement dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire selon la longueur du contexte, l'ordre des documents récupérés, ou simplement la formulation de la requête. Un fine-tuning léger, même limité à quelques milliers d'exemples, stabilise ce type de comportement bien plus durablement.

Fine-tuner en pensant que le modèle « mémorisera » un corpus avec exactitude. Le fine-tuning ajuste des distributions de probabilité, il ne constitue pas une base de données consultable. Un modèle fine-tuné sur des documents internes peut reformuler, mélanger ou halluciner des détails de ces documents — sans qu'aucune source ne soit citée pour vérifier l'affirmation. C'est un problème particulièrement grave dans les secteurs régulés où chaque réponse doit pouvoir être tracée jusqu'à sa source.

Compenser un RAG mal construit par du fine-tuning. Un retrieval imprécis, un découpage de documents trop grossier ou un ré-ordonnancement (reranking) absent produisent un contexte pauvre. Plutôt que de diagnostiquer cette faiblesse, l'équipe se tourne vers le fine-tuning pour « faire deviner » au modèle ce que le contexte ne lui a pas fourni correctement. Le symptôme est traité, pas la cause — et le prochain document ajouté à la base souffrira du même problème de récupération.

Si les échecs observés viennent de documents non retrouvés, mal découpés ou mal classés par pertinence, aucun cycle de fine-tuning ne réglera durablement le problème. Diagnostiquer précisément l'origine de l'échec — retrieval ou génération — avant d'investir dans l'une ou l'autre technique évite des mois de travail sur la mauvaise couche du système.

Les approches hybrides

En production, la réponse la plus robuste combine fréquemment les deux techniques, chacune sur la couche où elle est structurellement la plus efficace.

Le schéma le plus courant associe un fine-tuning léger par adaptateurs LoRA, chargé de stabiliser le ton, le format de sortie et les tournures du domaine, à un pipeline RAG chargé d'apporter les faits à jour et les sources citables. Le modèle « sait comment répondre » grâce au LoRA, et « sait quoi répondre » grâce au contexte injecté par le RAG.

Un second schéma consiste à fine-tuner non pas le modèle générateur, mais le modèle d'embedding utilisé pour la recherche vectorielle. Un embedding entraîné spécifiquement sur le vocabulaire du domaine améliore la pertinence du retrieval, ce qui bénéficie indirectement à la qualité des réponses sans toucher au modèle de génération.

Un troisième schéma fine-tune le modèle sur la réécriture de requêtes (query rewriting) ou sur l'appel d'outilsappel d'outilsIAMécanisme par lequel un modèle produit un appel de fonction structuré que le code environnant décide d'exécuter. Le modèle n'a jamais d'accès direct : il propose, le code dispose.Voir dans le glossaire (function callingtool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire) au format strict attendu par le pipeline RAG, tandis que le contenu factuel reste entièrement porté par les documents récupérés.

Un cabinet déploie un assistant de rédaction de clauses contractuelles. La jurisprudence et les modèles de clauses internes évoluent en continu : ils sont servis par un RAG interrogeant une base documentaire mise à jour quotidiennement, avec citation systématique de la source. La structure des clauses, le registre de langue attendu par les associés et le format de sortie (numérotation, renvois internes) sont, eux, stables dans le temps : ils sont internalisés via un fine-tuning LoRA entraîné sur plusieurs centaines de clauses validées par le cabinet. Aucune des deux techniques seule n'aurait suffi : le RAG seul aurait produit un style incohérent d'une réponse à l'autre, le fine-tuning seul aurait fini par citer une jurisprudence obsolète.

Roadmap de décision en cinq étapes

1. Cartographier le besoin. Lister séparément ce qui relève d'un manque de connaissance récupérable et ce qui relève d'un comportement à internaliser. Cette cartographie, produite en atelier avec les experts métier, évite de traiter la question de façon binaire.

2. Prototyper un RAG minimal. Mettre en place un pipeline de base — découpage simple, embedding généraliste, prompt de synthèse — en quelques jours. L'objectif n'est pas la perfection mais d'obtenir une référence mesurable.

3. Classer les échecs résiduels. Faire évaluer le prototype sur un jeu de questions représentatif et classer chaque échec : échec de retrieval (le bon document n'a pas été trouvé), échec de génération malgré un bon contexte, ou échec de comportement (ton, format) indépendant du contenu.

4. Décider du complément. Si les échecs sont majoritairement des échecs de retrieval, améliorer le pipeline RAG (découpage, reranking, embedding spécialisé) avant d'envisager un fine-tuning. Si les échecs persistent malgré un bon contexte et concernent le comportement ou le format, engager un fine-tuning léger ciblé sur ces échecs précis, pas sur l'ensemble du domaine.

5. Industrialiser avec gouvernance. Documenter la décision, les critères qui l'ont motivée, et les conditions qui la remettraient en cause (nouveau volume de données, changement réglementaire, dérive de performance mesurée).

Gouvernance et révision continue de la décision

Le choix entre RAG et fine-tuning n'est pas définitif. Un projet qui démarre avec un RAG peut légitimement évoluer vers un hybride lorsque le volume de retours utilisateurs permet de constituer un corpus d'entraînement de qualité suffisante. À l'inverse, un modèle fine-tuné sur des connaissances jugées stables peut nécessiter l'ajout d'un RAG le jour où le domaine se met à évoluer plus vite que prévu — un changement réglementaire, une nouvelle gamme de produits, une actualité sectorielle.

Le suivi de la dérive (drift) est le mécanisme de gouvernance central. Il consiste à mesurer périodiquement, sur un échantillon représentatif de requêtes réelles, le taux d'échecs par catégorie identifiée à l'étape 3 de la roadmap. Une hausse du taux d'échecs de retrieval signale un besoin de maintenance du pipeline documentaire. Une hausse du taux d'échecs de comportement, malgré un contexte stable et pertinent, signale que le fine-tuning existant ne couvre plus l'ensemble des cas rencontrés en production.

Un pipeline RAG reste, en général, plus facile à faire évoluer vers un autre modèle générateur — il suffit de rebrancher le nouveau modèle sur le même index. Un fine-tuning, en particulier un fine-tuning complet plutôt qu'un adaptateur LoRA, lie plus étroitement le comportement obtenu à l'architecture et à la version précise du modèle de base. Ce critère de réversibilité mérite d'être intégré à la décision initiale, en particulier dans un secteur où le paysage des modèles disponibles évolue vite.

Checklist finale avant de trancher

• Le besoin a-t-il été explicitement classé comme connaissance, comportement, ou les deux ?
• Un prototype RAG minimal a-t-il été testé avant d'envisager un fine-tuning ?
• Les échecs résiduels ont-ils été attribués précisément au retrieval, à la génération ou au comportement ?
• La fraîcheur requise des données a-t-elle été chiffrée (quotidienne, mensuelle, stable) ?
• La traçabilité des réponses jusqu'à une source est-elle une exigence réglementaire ou contractuelle ?
• Le coût total de possession a-t-il été comparé sur douze mois, pas seulement sur la phase de mise en place ?
• Un mécanisme de suivi de la dérive est-il prévu pour réévaluer la décision périodiquement ?
• La réversibilité vers un autre modèle de base a-t-elle été considérée ?

Cette checklist ne remplace pas le jugement d'équipe, mais elle évite l'écueil le plus fréquent observé sur le terrain : trancher sur la base de la technique la plus discutée du moment plutôt que sur la nature réelle du problème à résoudre.