Réponse courte : choisissez un RAG lorsque le système doit retrouver un savoir externe, changeant, attribuable ou filtré selon l'utilisateur. Envisagez un fine-tuning lorsque le modèle connaît déjà les informations nécessaires, mais exécute mal une tâche répétitive et stable que des exemples représentatifs peuvent enseigner. Combinez les deux seulement si vous avez démontré ces deux besoins séparément. Et si un prompt, quelques exemples dans le contexte, une recherche classique ou une règle déterministe corrigent l'échec, ne choisissez ni l'un ni l'autre.
Le sigle ne doit pas décider à la place du problème. « Mettre nos documents dans le modèle » mélange au moins deux objectifs : fournir une information au moment de la réponse et modifier la manière dont le modèle se comporte. La première question n'est donc pas « quelle technique est la plus puissante ? », mais « quelle défaillance précise voulons-nous corriger ? ».
La décision commence par l'échec à corriger
Constituez d'abord un petit jeu de situations réelles, autorisées et annotées. Exécutez le modèle de référence avec les instructions, outils et contraintes que vous pourriez raisonnablement exploiter. Pour chaque échec, classez la cause la plus probable :
- information absente : la réponse exige une règle, un document ou un état que le modèle ne reçoit pas ;
- mauvaise information retrouvée : la source existe, mais la recherche, le découpage ou le filtrage échoue ;
- tâche mal exécutée : les éléments utiles sont présents, mais la sortie ne respecte pas la décision, le format ou les distinctions attendues ;
- instruction ambiguë : les évaluateurs eux-mêmes ne s'accordent pas sur le résultat correct ;
- contrainte déterministe violée : une règle de droit d'accès, de calcul, de validation ou de format devrait être imposée par le logiciel plutôt que laissée au modèle.
Cette séparation évite deux erreurs coûteuses. Un fine-tuning n'est pas un mécanisme fiable pour rendre une source manquante ou périmée consultable et à jour. Un RAG ne transforme pas automatiquement un modèle en extracteur fiable, ne tranche pas une consigne ambiguë et ne remplace pas une validation de schéma. Si la référence elle-même est floue, corrigez d'abord la tâche et son guide d'évaluation.
RAG et fine-tuning ne modifient pas la même couche
Dans l'article fondateur publié à NeurIPS 2020, le RAG associe la mémoire paramétrique du modèle à une mémoire non paramétrique explicite, interrogée par un mécanisme de récupération. Les architectures actuelles varient, mais la frontière reste utile : le système cherche un contexte externe puis le fournit au générateur pour cette requête.
Un RAG ajoute donc une chaîne exploitable : ingestion, extraction, indexation, recherche, classement, filtrage, composition du contexte et génération. Il rend possible l'actualisation d'un corpus sans réentraîner le modèle et permet de conserver une référence vers les passages utilisés. Cela ne prouve pas que ces passages sont les bons, ni que la réponse leur reste fidèle.
Le fine-tuning poursuit un autre but. Le module Machine Learning Crash Course de Google le décrit comme l'adaptation d'un modèle de fondation à une tâche à partir de données propres à cette tâche. Les paramètres, ou un sous-ensemble dans les méthodes économes en paramètres, sont ajustés pour rendre certains comportements plus probables.
Le terme recouvre plusieurs pratiques. Une adaptation supervisée enseigne surtout des sorties attendues ; une adaptation de domaine peut aussi améliorer le traitement d'un vocabulaire ou de régularités propres à un corpus. Même dans ce second cas, les paramètres ne deviennent pas une base documentaire aisément actualisable, filtrable par droit et attribuable passage par passage. Ce guide compare donc des fonctions d'architecture, sans prétendre que toute connaissance reste absente d'un modèle adapté.
| Question | RAG | Fine-tuning |
|---|---|---|
| Ce qui change | Le contexte externe fourni à chaque requête | Le comportement encodé dans des paramètres adaptés |
| Bon signal de départ | Le savoir manque, évolue ou doit être cité | La tâche est stable mais mal exécutée malgré un contexte suffisant |
| Mise à jour | Modifier la source puis réindexer selon une politique maîtrisée | Constituer une nouvelle version des données, entraîner et revalider |
| Preuve à conserver | Sources candidates, passages récupérés, filtres et réponse | Jeu de données, version du modèle, configuration et résultats |
| Échec typique | Bonne source non retrouvée ou mauvais passage présenté comme preuve | Apprentissage d'un raccourci, régression ou faible généralisation |
Le tableau décrit des fonctions, pas des garanties. Le profil NIST AI 600-1 demande de documenter les sources, limites, versions et mesures d'un système génératif dans des conditions proches de son déploiement. Le composant choisi ne dispense jamais de cette évaluation du système complet.
Les sept portes à franchir avant de construire
Répondez aux portes dans l'ordre. Une condition éliminatoire ne doit pas être compensée par un score global flatteur.
- Cause démontrée. Pouvez-vous reproduire l'échec et montrer qu'il vient du savoir disponible ou du comportement, plutôt que d'une consigne, d'un outil ou d'une référence défectueuse ? Sans diagnostic, restez sur le système le plus simple.
- Fraîcheur. La connaissance change-t-elle plus vite que votre cycle réaliste de données, d'entraînement et de validation ? Si oui, gardez-la dans une source actualisable et privilégiez la récupération.
- Attribution. La personne doit-elle voir la source, la date et le passage qui fondent la réponse ? Si cette preuve est obligatoire, le savoir ne peut pas reposer uniquement sur les paramètres.
- Droits au moment de la requête. Deux utilisateurs peuvent-ils recevoir des documents différents ? Les autorisations doivent alors être appliquées avant la génération, au niveau des sources et de la recherche. Un modèle ajusté partagé n'est pas un système de contrôle d'accès.
- Exemples d'apprentissage. Possédez-vous des entrées et sorties autorisées, représentatives, cohérentes et séparables d'un jeu d'évaluation ? Sans données de qualité, le fine-tuning n'est qu'une hypothèse non financée.
- Stabilité du comportement. La bonne sortie peut-elle être définie assez durablement pour justifier une adaptation ? Une règle qui change chaque semaine doit rester explicite, versionnée et testable hors des paramètres.
- Capacité d'exploitation. Savez-vous surveiller les versions, les accès, les coûts, la latence, les erreurs et les régressions de la chaîne retenue ? Refusez l'architecture que l'équipe ne peut pas observer et remettre en état.
La documentation Microsoft Learn, mise à jour le 30 janvier 2026, oriente également le RAG vers les contenus dynamiques et le fine-tuning vers les tâches spécialisées disposant de données adaptées. Cette règle générale doit toutefois être vérifiée sur vos cas : une source stable peut nécessiter un RAG pour l'attribution, et une tâche spécialisée peut rester meilleure avec des exemples fournis dans le contexte.
Un arbre de décision à quatre sorties
- Le système de référence franchit-il déjà les seuils ? Si oui, sortie
NI L'UN NI L'AUTRE. N'ajoutez pas un composant sans défaut mesuré à corriger. - Les informations nécessaires sont-elles absentes du contexte ou doivent-elles rester actuelles, attribuables ou filtrées ? Si oui, testez
RAG. - Avec le bon contexte, le modèle échoue-t-il encore sur un comportement stable et mesurable ? Si oui, comparez d'abord prompt, exemples dans le contexte et validation déterministe. Si l'écart demeure et si les données sont suffisantes, testez
FINE-TUNING. - Les deux défauts indépendants sont-ils prouvés ? Si oui seulement, testez
HYBRIDE: récupération pour la connaissance et adaptation pour la tâche.
« Les deux semblent utiles » n'est pas une preuve de combinaison. Chaque branche doit nommer son échec cible, sa mesure, sa limite de coût et sa condition d'arrêt.
Le montage hybride doit justifier ses deux complexités
Un système peut légitimement récupérer des règles à jour et utiliser un modèle adapté pour transformer ces règles en une sortie métier stable. AWS rappelle dans son comparatif RAG et fine-tuning que les approches peuvent être combinées. Cette possibilité technique ne dit pas quand le surcoût est rationnel.
Avant un montage hybride, exigez une étude d'ablation en trois étapes :
- mesurer le système de référence avec le meilleur contexte autorisé ;
- ajouter uniquement la récupération et mesurer les défauts corrigés et créés ;
- n'ajouter l'adaptation que si un défaut de comportement persiste avec des sources correctement retrouvées.
Conservez ensuite quatre versions dans chaque résultat : corpus, index ou retriever, modèle de base et adaptation. Sans cette traçabilité, une régression devient difficile à attribuer. Une réponse peut se dégrader parce qu'un document a changé, qu'un filtre d'accès a exclu une source, que la recherche a classé un mauvais passage, que le prompt a évolué ou que le modèle adapté a changé de comportement.
Comparer les systèmes exploités, pas les démonstrations
| Poste | Questions pour un RAG | Questions pour un fine-tuning |
|---|---|---|
| Données | Qui publie, retire, classe et réindexe les sources ? | Qui sélectionne, annote, déduplique et versionne les exemples ? |
| Qualité | Mesure-t-on séparément récupération, attribution et réponse ? | Compare-t-on au modèle de base sur des cas jamais entraînés ? |
| Sécurité | Les droits filtrent-ils les documents avant leur passage au modèle ? | Les données d'entraînement sont-elles autorisées et expurgées des secrets ? |
| Changement | Quelle politique de fraîcheur et de suppression propage une mise à jour ? | Quel événement déclenche une nouvelle adaptation et une revalidation ? |
| Retour arrière | Peut-on restaurer corpus, index, filtres et configuration ? | Peut-on revenir au modèle de base ou à l'adaptation précédente ? |
Ni le RAG ni le fine-tuning ne neutralisent l'injection de prompt. L'OWASP GenAI Top 10 2025 le signale explicitement et décrit le risque indirect créé par des contenus externes malveillants. Sa fiche sur les faiblesses des vecteurs et embeddings ajoute les risques d'empoisonnement, de récupération inter-contextes et de fuite lorsque les contrôles sont mal alignés.
Traitez donc les documents récupérés comme des données, pas comme des instructions de confiance. Appliquez les autorisations avant la récupération, séparez les sources non fiables, limitez les capacités du modèle, validez les sorties et imposez une approbation humaine aux actions à conséquence élevée. Pour le fine-tuning, gouvernez aussi l'origine des exemples, les données personnelles, les licences et les résultats interdits.
Comparer les options sur la même preuve
Une comparaison honnête utilise le même jeu gelé, les mêmes contraintes et la même définition du succès. Le guide Comment évaluer les sorties textuelles d'une IA générative ? détaille le registre de cas, le guide d'annotation, la gravité, l'accord humain et la variabilité nécessaires à cette preuve.
Préparez quatre variantes seulement si elles sont pertinentes : référence, référence avec récupération, modèle adapté sans récupération, puis hybride. Pour chacune, conservez :
- la qualité par famille de cas et le nombre d'échecs critiques ;
- la provenance correcte des affirmations qui exigent une source ;
- les refus, fuites de périmètre et violations de droits ;
- la stabilité sur les cas importants répétés ;
- le temps humain de revue et de correction ;
- la latence, le coût observable et les incidents de la chaîne complète ;
- le travail nécessaire pour mettre à jour puis restaurer chaque variante.
Écrivez les seuils avant l'essai : zéro fuite d'accès, zéro source fabriquée sur une décision importante, limite de latence, niveau de qualité minimal par famille et effort maximal de correction. Le cadre Concevoir un pilote IA mesurable en 30 jours aide à transformer ces critères en décision de poursuivre, corriger, réduire ou arrêter.
Une moyenne supérieure ne suffit pas si une variante crée un échec éliminatoire. De même, une amélioration de qualité peut ne pas justifier une chaîne que l'équipe ne sait pas maintenir. La preuve doit couvrir la valeur et l'exploitation.
Trois scénarios pédagogiques, trois décisions différentes
Les situations suivantes sont fictives. Elles illustrent le raisonnement ; elles ne décrivent ni un client, ni un test, ni un résultat de Forge Labs.
| Situation pédagogique | Défaillance observée | Hypothèse à tester | Preuve décisive |
|---|---|---|---|
| Assistant de procédures internes | Il répond avec une ancienne règle et ne montre pas sa source | RAG avec date, version, filtre d'accès et abstention si aucune source valide | Bonne procédure retrouvée, citation exacte, retrait propagé et aucun document hors droits |
| Extraction vers un format stable | Le texte source est présent, mais les mêmes distinctions métier sont régulièrement confondues | D'abord exemples dans le contexte et validation de schéma ; fine-tuning seulement si l'écart persiste | Gain sur un jeu non vu, sans hausse des erreurs critiques ni régression sur les cas rares |
| Note structurée fondée sur des règles à jour | Le système doit citer la règle courante et produire une forme métier spécialisée | RAG pour la règle ; adaptation candidate pour la forme après preuve séparée | L'étude d'ablation montre que chaque composant corrige son propre défaut |
Un quatrième résultat reste possible dans chaque scénario : abandonner l'IA générative. Une recherche filtrée, un formulaire, un moteur de règles ou une extraction déterministe peut produire une réponse plus fiable, moins ambiguë et plus simple à auditer.
La fiche de décision tient sur une page
Avant d'autoriser la construction, complétez cette fiche :
- tâche : entrée, sortie, utilisateur et action permise ;
- échec de référence : exemples, fréquence observée et gravité ;
- cause visée : information, récupération, comportement, consigne ou règle logicielle ;
- sortie de l'arbre : ni l'un ni l'autre, RAG, fine-tuning ou hybride ;
- données autorisées : sources, droits, durée, exclusions et responsable ;
- preuve : jeu gelé, variantes, seuils éliminatoires et métriques ;
- exploitation : versions, surveillance, mise à jour, incident et retour arrière ;
- décision : poursuivre, corriger, réduire ou arrêter, avec date et propriétaire.
La règle finale est simple : gardez hors des paramètres ce qui doit rester visible, actualisable, attribuable ou soumis à un droit d'accès. N'adaptez le modèle que pour un comportement stable dont l'amélioration est démontrée sur des cas non vus. Si vous ne pouvez pas nommer la défaillance que chaque composant corrige, vous n'avez pas encore une architecture : vous avez une accumulation.
Sources consultées
- NIST AI 600-1 — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, juillet 2024, page mise à jour en avril 2026, consultée le 31 juillet 2026.
- Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020.
- Google for Developers — LLMs: Fine-tuning, distillation, and prompt engineering, consulté le 31 juillet 2026.
- Microsoft Learn — Augment large language models with retrieval-augmented generation or fine-tuning, mise à jour le 30 janvier 2026.
- AWS Prescriptive Guidance — Comparing Retrieval Augmented Generation and fine-tuning, consulté le 31 juillet 2026.
- OWASP GenAI Top 10 2025 — Prompt Injection et Vector and Embedding Weaknesses, consultés le 31 juillet 2026.