RAG vs fine-tuning : quand utiliser chacun (avec de vrais chiffres)

RAG vs fine-tuning : quand utiliser chacun (avec de vrais chiffres)

La plupart des conseils sur RAG vs fine-tuning passent à côté de la seule expérience qui a mesuré les deux sur la même tâche. Balaguer et al., dans arXiv:2401.08406 (cité 162 fois), ont soumis un jeu de questions-réponses agricoles aux deux approches : le fine-tuning a rapporté plus de 6 points de précision, et le RAG en a ajouté 5 autres par-dessus. Leur table 18 place GPT-4 à 75 % sans aide, 81 % après fine-tuning, 86 % après fine-tuning avec retrieval. Alors pourquoi conseillons-nous encore à la plupart des équipes de commencer par le RAG ? Parce que la fraîcheur des données, les citations et le calcul de coût ci-dessous tranchent plus de projets qu'un écart de précision d'un point.

Points clés à retenir

• Le RAG est le choix par défaut quand les connaissances changent souvent ou quand les réponses doivent citer leurs sources ; le fine-tuning l'emporte sur la cohérence du format et la latence.
• Les coûts du fine-tuning tombent au départ (entraînement) ; ceux du RAG tombent à chaque requête (embeddings plus tokens d'entrée supplémentaires).
• Preuves publiées sur une même tâche : le fine-tuning a ajouté 6 points de précision, le RAG 5 de plus, et l'hybride a battu les deux approches seules.
• Passez les cinq vérifications (fraîcheur des données, exemples étiquetés, latence, citations, compétences de l'équipe) avant d'écrire la moindre ligne de code d'entraînement.

Quand utiliser le RAG plutôt que le fine-tuning ? (verdict rapide)

Choisissez le RAG si vos connaissances changent souvent ou si vos réponses doivent porter des citations. Choisissez le fine-tuning si vous avez besoin d'un format de sortie cohérent et d'une faible latence, et que vous disposez de centaines d'exemples étiquetés. Utilisez les deux une fois le déploiement arrivé à maturité. Le RAG modifie le contexte que le modèle lit ; le fine-tuning modifie le modèle lui-même. La plupart des équipes ont besoin du premier, pas du second.

Une phrase à retenir : le RAG change ce que le modèle lit ; le fine-tuning change ce qu'est le modèle. Choisissez selon ce dont votre tâche a réellement besoin.

Le glossaire RAG de NVIDIA définit proprement le volet retrieval si vous voulez la version académique. Mais ce ne sont pas les définitions qui choisissent votre architecture. Ce sont les preuves, alors commencez par là.

Que montrent les preuves ? Une tâche, deux approches, mesurées

La seule comparaison mesurée sur une même tâche classée dans le top cinq de Google pour cette requête est Balaguer et al. 2024, une étude de Microsoft Research citée 162 fois. L'équipe a fait passer une tâche de questions-réponses agricoles dans un pipeline RAG, un modèle fine-tuné et un hybride des deux, puis a demandé à GPT-4 de noter les réponses. Dans leur configuration, le fine-tuning seul a devancé le RAG seul de justesse, et la combinaison des deux a battu chacune des approches avec une marge plus nette.

L'étude de cas agricole (arXiv:2401.08406)

L'étude, soumise en janvier 2024 par Angels Balaguer et 15 coauteurs, se demande ce qu'il faut pour donner aux agriculteurs des informations propres à leur localisation. Leur pipeline extrait l'information de PDF, en génère des paires question-réponse, et évalue Llama2-13B, GPT-3.5 et GPT-4 avec et sans retrieval.

Balaguer et al. rapportent un gain de précision de plus de 6 points de pourcentage grâce au fine-tuning, cumulable avec le RAG, qui ajoute encore 5 points par-dessus. Le pipeline hybride a battu chaque approche prise isolément. Leur table 18 montre l'ordre pour GPT-4 : 75 % sans aide, 80 % avec RAG, 81 % après fine-tuning, 86 % après fine-tuning plus RAG. Notez à quel point 80 % et 81 % sont proches ; l'écart entre le RAG seul et le fine-tuning seul est d'un point, tandis que l'hybride distance les deux de cinq points. Dans une expérience, le modèle fine-tuné a puisé dans des connaissances issues d'autres régions géographiques pour répondre à des questions locales, faisant passer la similarité des réponses de 47 % à 72 %.

Les preuves économiques

L'étude publiée par Snorkel AI (novembre 2022) couvre le volet coût. Sur un benchmark de classification juridique à 100 classes (LEDGAR, 80 000 clauses contractuelles), un modèle RoBERTa fine-tuné a égalé un GPT-3 fine-tuné tout en étant 1 400× plus petit, en utilisant moins de 1 % des étiquettes de référence, et en tournant à 0,1 % du coût d'inférence en production du modèle GPT-3 fine-tuné, soit environ un millième. Coût total de construction : 1 915 $ avec étiquetage programmatique contre 7 418 $ pour une annotation manuelle plus le fine-tuning de GPT-3. Une réserve : il s'agit de classification, pas de questions-réponses génératives, alors prenez ces ratios comme un ordre de grandeur.

Notre lecture

Notre interprétation : leur configuration est le cas le plus favorable que le fine-tuning puisse rencontrer, et il ne l'a emporté que d'un point. Balaguer et al. ont entraîné sur un corpus PDF figé et évalué sur ce même corpus gelé, si bien que rien de ce que les poids ont appris n'a eu l'occasion de devenir obsolète en cours d'expérience. La plupart des bases de connaissances en production ne restent pas immobiles ainsi. Un bot de support qui répond à des questions sur la release de la semaine dernière doit regagner les 6 points à chaque cycle de réentraînement, alors que l'index qui alimente le RAG se met à jour l'après-midi même. C'est pourquoi nous considérons un avantage de précision d'un point comme l'input le plus faible de cette décision, et la fraîcheur comme le plus fort. Là où les preuves ne se généralisent pas : le résultat de Snorkel porte sur un benchmark de classification, et aucune des deux études ne teste le contrôle du ton ou du format, qui reste l'argument le plus fort du fine-tuning.

Le fine-tuning est la bonne réponse moins souvent que les équipes ne le croient ; la plupart des projets qui disent « fine-tuner » veulent en réalité dire « récupérer ».

Comment fonctionne le RAG, et quand gagne-t-il ?

Le RAG (retrieval-augmented generation, génération augmentée par récupération) répond à partir de documents que vous contrôlez, plutôt qu'à partir de ce que le modèle a mémorisé pendant son entraînement. Proposé pour la première fois par Lewis et al. en 2020, il est devenu le choix par défaut pour le travail sur les connaissances, car celles-ci vivent en dehors du modèle : mettez à jour l'index, et toutes les réponses changent demain sans réentraînement.

Le pipeline tient en quatre étapes :

1. Ingestion. Analysez vos documents (PDF, wikis, tickets) pour former un corpus.
2. Découpage et embedding. Découpez en chunks de quelques centaines de tokens et convertissez chacun en vecteur avec un modèle d'embedding.
3. Récupération. Au moment de la requête, trouvez les K chunks les plus similaires, plus des correspondances par mots-clés pour les chaînes exactes comme les SKU et les codes d'erreur.
4. Augmentation et génération. Injectez ces chunks dans le prompt et laissez le LLM répondre avec les sources jointes.

Le RAG gagne sur trois axes : la fraîcheur (réindexer plutôt que réentraîner), les citations (chaque réponse pointe vers le chunk dont elle provient) et le contrôle des données (les données clients n'entrent jamais dans un run d'entraînement). Si vous voulez le guide de construction complet, voici comment créer une application RAG étape par étape.

Un avertissement sur la qualité du retrieval : le pipeline ne vaut que par son dosage entre embedding et récupération. Le Contextual Retrieval d'Anthropic a mesuré un taux d'échec de retrieval de 5,7 % dans le top 20 sur des configurations simples, ramené à 2,9 % avec des embeddings contextuels plus BM25, puis à 1,9 % une fois un reranker ajouté. Si les requêtes par correspondance exacte continuent d'échouer, la recherche hybride (BM25 vs vectorielle) est la solution.

Quand le fine-tuning gagne-t-il ? (et qu'est-ce que le PEFT ?)

Le fine-tuning gagne quand le problème est la façon dont le modèle répond, pas ce qu'il sait : format de sortie cohérent, ton de marque, ou budget de latence serré sans aller-retour de retrieval. C'est aussi le levier de l'économie des petits modèles. Le résultat de Snorkel ci-dessus, une qualité GPT-3 pour 0,1 % du coût, n'existe que parce que quelqu'un a fine-tuné un petit modèle au lieu de servir un gros modèle.

Fine-tuning complet vs PEFT (LoRA / QLoRA)

Le fine-tuning complet met à jour tous les poids du modèle. Il est cher, lent et rare en dehors des grands laboratoires. Presque tout le monde livre du PEFT (parameter-efficient fine-tuning) à la place. LoRA (Hu et al. 2021) gèle les poids de base et entraîne un petit adaptateur de bas rang, typiquement 0,1-1 % du nombre de paramètres. QLoRA ajoute une quantification 4 bits par-dessus, si bien qu'un modèle 13B tient sur un seul GPU grand public. Un terme voisin à connaître : le pré-entraînement continu, où un modèle poursuit son pré-entraînement sur un corpus brut du domaine (non supervisé) avant un fine-tuning supervisé sur des exemples étiquetés.

Une configuration LoRA minimale, d'après la documentation PEFT de Hugging Face :

from peft import LoraConfig, get_peft_model

config = LoraConfig(
    r=16,                          # low-rank dimension; 8-64 typical
    lora_alpha=32,                 # scaling factor, commonly 2x r
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)

model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: ~13M || all params: 6.7B || trainable%: 0.19

Pour la préparation du jeu de données, le nombre d'epochs et l'évaluation, voyez notre guide de fine-tuning étape par étape.

Les risques sont réels : le surapprentissage sur de petits jeux de données (quelques centaines d'exemples peuvent être mémorisés plutôt qu'appris), l'obsolescence (les poids gèlent vos connaissances à la date de coupure de l'entraînement) et l'absence d'attribution des sources (un modèle fine-tuné ne peut pas montrer ses preuves). Si l'un de ces trois points est rédhibitoire, vous venez de vous convaincre tout seul de revenir au RAG.

RAG vs fine-tuning vs prompt engineering : où se placent les autres ?

Les trois forment une échelle, pas des rivales. Le prompt engineering change les instructions, le RAG change le contexte que le modèle lit, et le fine-tuning change les poids. Le propre guide de fine-tuning d'OpenAI place le fine-tuning en dernier dans la boucle : d'abord les évaluations, ensuite les prompts, l'entraînement seulement quand le prompting ne suffit plus. Deux options plus récentes complètent la boîte à outils.

Une confusion mérite d'être nommée : les serveurs MCP et les frameworks d'agents relèvent de l'orchestration, pas de la personnalisation. Ils décident des outils et des sources que le modèle peut atteindre ; ils ne changent pas la façon dont le modèle répond. Vous pouvez faire tourner un pipeline RAG dans un agent et fine-tuner le modèle en dessous, et beaucoup de systèmes en production font les deux. Les guerres de l'autocomplétion (« vs MCP », « vs agents ») sont des erreurs de catégorie.

Le RAG est-il moins cher que le fine-tuning ? Le vrai modèle de coût

Réponse courte : à des volumes de requêtes réalistes, oui. La facture du fine-tuning tombe au départ (données étiquetées plus entraînement), tandis que celle du RAG arrive à chaque requête (embeddings plus tokens d'entrée supplémentaires). La documentation de fine-tuning d'OpenAI facture l'entraînement au token, mais les frais de tokens ne pèsent rien face au coût humain des exemples étiquetés. Voici le calcul sur les tarifs publics.

La question du point mort : combien de requêtes faut-il pour que la taxe cumulée du RAG par requête égale l'investissement du fine-tuning ?

break_even = training_cost / per_query_retrieval_delta
           = $1,915 / $0.0003
           ≈ 6.4 million queries

À 50 000 requêtes par mois, cela représente plus de dix ans. Pour la plupart des produits, l'investissement du fine-tuning n'est jamais rentabilisé par les seules économies de tokens ; on fine-tune pour le format et la latence, pas pour battre le RAG sur le coût. Le calcul s'inverse au-delà de millions de requêtes par mois ou avec de très grands contextes récupérés. Et notez l'asymétrie : la facture du fine-tuning se renouvelle chaque fois que la dérive des données impose un réentraînement, alors que le RAG évolue linéairement avec le volume multiplié par la taille des chunks. Si la dépense par requête est votre vraie inquiétude, commencez par réduire les coûts LLM par requête ; si vous prenez tout de même la voie de l'entraînement, comparez les outils de fine-tuning avant de signer le chèque.

Une note de fraîcheur : en juillet 2026, la documentation de fine-tuning d'OpenAI indique que la plateforme hébergée est progressivement fermée aux nouveaux utilisateurs, les utilisateurs existants conservant l'accès à l'entraînement pendant les mois à venir. C'est une raison de plus pour laquelle les équipes se tournent vers le PEFT sur modèles ouverts ou le RAG tout court.

5 vérifications avant de choisir

Passez ces cinq vérifications par oui ou non avant d'écrire la moindre ligne de code d'entraînement ; la configuration des réponses pointe vers le RAG, le fine-tuning ou l'hybride plus sûrement que n'importe quel benchmark. Répondez honnêtement, puis comptez.

1. Les connaissances changent-elles plus vite que vous ne pourriez réentraîner ? Oui → RAG. Un réentraînement à chaque mise à jour de document n'est pas un plan d'exploitation.
2. Disposez-vous de quelques centaines d'exemples étiquetés ? Non → RAG ou prompt engineering. Un fine-tuning sur 40 exemples mémorise ; il n'apprend pas.
3. Existe-t-il un budget de latence strict ? Serré → penche vers le fine-tuning. Sauter l'aller-retour de retrieval économise 50-200 ms.
4. Les réponses doivent-elles porter des citations ou une piste d'audit ? Oui → RAG. Les modèles fine-tunés ne peuvent pas pointer vers le chunk source.
5. L'équipe a-t-elle des compétences en ML plus un budget GPU ou API pour l'entraînement ? Non → RAG. Un index que vous pouvez reconstruire vaut mieux que des poids que vous ne pouvez pas réentraîner.

Majoritairement oui aux questions 1, 4, 5 → RAG. Majoritairement oui aux questions 2 et 3 avec un domaine stable → fine-tuning. Réponses partagées, ou un produit mature avec du trafic réel → hybride (section suivante). L'intérêt de la checklist est de décider par les preuves, pas selon la technique qui fait tendance dans votre fil ce mois-ci.

Peut-on utiliser le RAG et le fine-tuning ensemble ?

Oui, et pour les déploiements matures, le schéma hybride est la norme, pas l'exception. Fine-tunez pour la maîtrise du domaine et le format de sortie (le comment), récupérez pour les faits au moment de l'inférence (le quoi). Balaguer et al. rapportent exactement cela sur leur tâche agricole : le pipeline hybride a battu chaque approche seule, le gain de 5 points du RAG se cumulant par-dessus les 6 du fine-tuning.

Le chemin de maturité que nous recommandons : commencez par le prompt engineering, ajoutez le RAG dès que les réponses ont besoin de données privées ou fraîches, et n'ajoutez le fine-tuning qu'une fois que les incohérences de format ou la latence commencent à faire mal en production. Passez directement au fine-tuning et vous payez la taxe d'entraînement avant même de savoir si le retrieval avait déjà résolu le problème.

Le schéma hybride n'est pas un compromis ; pour les déploiements matures, c'est le choix par défaut : fine-tuner pour le format, récupérer pour les faits.

Comment évaluer votre gagnant ?

Choisissez le gagnant comme vous choisiriez une base de données : mesurez sur votre charge de travail, pas à l'intuition. La recette tient en un paragraphe et couvre les quatre chiffres qui décident réellement.

• Jeu de questions tenu de côté. 100-300 vraies questions d'utilisateurs. Pas de questions synthétiques, jamais rien de vu pendant l'entraînement ou l'indexation.
• Fidélité et justesse de la réponse. La fidélité demande si la réponse s'appuie sur le contexte récupéré ; la justesse demande si elle est réellement correcte. Le duo, popularisé par RAGAS, attrape à la fois les hallucinations et les échecs de retrieval.
• La latence au p95, pas la moyenne. Le retrieval ajoute un aller-retour ; mesurez la queue de distribution.
• Le coût pour 1 000 requêtes, tokens plus infrastructure, mesuré plutôt qu'estimé.
• Relancer en cas de dérive. Nouveaux documents, nouveau snapshot de modèle, nouveau trimestre : relancez le jeu.

Le détail complet des métriques, outillage compris, se trouve dans notre guide d'évaluation LLM.

Questions fréquemment posées

Peut-on utiliser le RAG et le fine-tuning ensemble ?

Oui. Fine-tunez pour le format de sortie et la maîtrise du domaine, et gardez le retrieval pour les faits au moment de l'inférence. Balaguer et al. ont mesuré cet hybride sur une tâche de questions-réponses agricoles et ont constaté qu'il battait chaque approche seule, les gains de précision se cumulant. La plupart des systèmes matures en production finissent ici : les poids pour le comment, le retrieval pour le quoi.

Quand ne pas utiliser le fine-tuning ?

Renoncez au fine-tuning quand vos connaissances changent plus vite que vous ne pouvez réentraîner, quand vous avez moins de quelques centaines d'exemples étiquetés, quand les réponses doivent porter des citations ou des pistes d'audit, ou quand il n'y a pas de budget pour réentraîner à mesure que les données dérivent. Ces quatre conditions décrivent la plupart des produits en phase de démarrage, c'est pourquoi le RAG est généralement le bon premier mouvement.

Le fine-tuning est-il obsolète ?

Non, mais son territoire s'est réduit. Les longues fenêtres de contexte et le RAG bon marché ont absorbé des cas d'usage qui exigeaient un fine-tuning en 2023. Ce qui reste est réel : format de sortie strict, ton de marque, budgets de latence sans aller-retour de retrieval, et économie des petits modèles. Si votre problème est la façon dont le modèle répond plutôt que ce qu'il sait, le fine-tuning reste l'outil.

Quand utiliser le RAG plutôt que le fine-tuning ?

Utilisez le RAG quand les réponses dépendent de connaissances privées ou fréquemment mises à jour, ou quand vous avez besoin de citations. Utilisez le fine-tuning quand vous avez besoin d'un format, d'un ton ou d'une latence cohérents et que vous disposez d'assez d'exemples étiquetés. Utilisez les deux une fois le produit arrivé à maturité. En cas de doute, commencez par le RAG : il coûte moins cher à défaire qu'un run d'entraînement.

Le RAG est-il moins cher que le fine-tuning ?

Au départ, oui. Le coût du RAG est par requête (embeddings plus tokens d'entrée supplémentaires), tandis que le fine-tuning facture une fois l'entraînement et les données étiquetées, puis se renouvelle à chaque réentraînement. Sur les tarifs publics, le point mort tombe autour de 6,4 millions de requêtes dans notre exemple chiffré, si bien qu'aux volumes habituels le RAG reste moins cher sur toute la vie du produit.

Le RAG est-il meilleur que le fine-tuning contre les hallucinations ?

En général, mais pas gratuitement. Le RAG ancre les réponses dans des chunks récupérés, si bien que vous pouvez citer les sources et auditer les échecs. Un mauvais retrieval empoisonne toutefois la réponse : Anthropic a mesuré un taux d'échec de retrieval de 5,7 % dans le top 20 sur des configurations simples, ramené à 1,9 % avec le retrieval contextuel plus le reranking. Le fine-tuning, lui, peut graver des erreurs dans les poids sans aucun moyen de les tracer.

RAG vs fine-tuning vs prompt engineering : quelle différence ?

Le prompt engineering change les instructions que vous envoyez. Le RAG change le contexte que le modèle lit au moment de la requête. Le fine-tuning change les poids du modèle. Chacun est une intervention plus lourde que le précédent : essayez d'abord les prompts, ajoutez le retrieval quand les connaissances sont le goulot d'étranglement, et n'entraînez que si le format, le ton ou la latence font encore mal.

Comment évaluer les performances du RAG face au fine-tuning ?

Constituez un jeu tenu de côté de 100-300 vraies questions d'utilisateurs et notez les deux approches dessus : fidélité (la réponse est-elle ancrée ?), justesse (est-elle correcte ?), latence p95 et coût pour 1 000 requêtes. Relancez le jeu à chaque changement de vos documents ou de votre snapshot de modèle. Les questions synthétiques flattent les deux systèmes ; les vraies les départagent.

Fine-tuning vs RAG pour les questions multi-sauts sur des connaissances nouvelles ?

Le RAG, avec un meilleur retrieval. Le mécanisme tranche celui-ci : un modèle fine-tuné ne peut raisonner que sur ce que ses poids ont absorbé, si bien qu'une connaissance qu'il n'a jamais vue reste inaccessible, quelle que soit la qualité de son entraînement. Le retrieval lui tend les pièces manquantes au moment de la requête. Le piège est qu'une seule passe de retrieval rassemble rarement tous les sauts, alors prévoyez une décomposition de requête ou un retrieval itératif plus un reranker, pas une simple recherche top-K.

Conclusion

Le récapitulatif, sans les précautions de langage :

• Le RAG est le choix par défaut pour les connaissances changeantes et les réponses citées. Le fine-tuning est le spécialiste du format, du ton et de la latence.
• Les preuves sur une même tâche (Balaguer et al.) donnent +6 pp au fine-tuning et +5 pp supplémentaires au RAG par-dessus, l'hybride étant le meilleur des trois. Notre conseil de commencer par le RAG repose sur la fraîcheur, les citations et le coût, pas sur ce tableau de scores.
• Le calcul de coût penche en faveur du RAG à des volumes réalistes : le point mort se situait autour de 6,4 millions de requêtes dans notre exemple chiffré.
• Décidez avec les cinq vérifications, pas avec l'habitude.

Vous avez choisi le RAG ? Voyez notre classement des outils RAG pour la pile qui entoure le pipeline.