Fine-Tuning vs RAG : Guide Décisionnel Pragmatique pour Modèles LLM

1. Forme vs Connaissance : le modèle mental clé

Le modèle mental le plus utile pour cette décision est le suivant : le fine-tuning change la façon dont un modèle répond ; le RAG change ce qu’il sait. Le fine-tuning met à jour les poids du modèle via une descente de gradient supplémentaire sur un jeu de données soigneusement constitué, ce qui modifie de façon fiable la forme de la sortie — le ton, la structure, le respect d’un schéma de sortie précis, l’usage d’une terminologie métier spécifique, ou un style de raisonnement particulier. Il n’enseigne pas de façon fiable de nouveaux faits, car le modèle a déjà compressé ses connaissances de pré-entraînement dans ses poids d’une manière que quelques milliers d’exemples de fine-tuning ne peuvent ni réellement écraser ni étendre.

Le RAG (Retrieval-Augmented Generation), lui, garde les poids du modèle figés et injecte des documents externes pertinents dans la fenêtre de contexte au moment de l’inférence, récupérés depuis une base vectorielle ou un index de recherche hybride en fonction de la requête. Cela résout directement le problème de connaissance : le modèle peut citer la page de tarification réelle de votre entreprise, votre dernier runbook interne, ou un document publié il y a cinq minutes, car il le lit à la volée plutôt que de s’appuyer sur quoi que ce soit intégré dans ses poids pendant l’entraînement.

L’erreur que les équipes commettent sans cesse est de choisir le fine-tuning pour résoudre un problème de connaissance — « on a fine-tuné sur notre doc produit pour que le modèle connaisse notre API » — et d’obtenir un modèle qui sonne davantage comme votre documentation mais qui continue d’halluciner des noms d’endpoints, car fine-tuner sur quelques centaines de paires question-réponse n’encode pas de façon fiable le contenu réel sous forme de faits interrogeables. Si l’exigence est « le modèle doit répondre correctement sur le contenu X », le RAG est presque toujours le bon premier réflexe, pas le fine-tuning.

2. Coûts, maintenance et fraîcheur des données

Le fine-tuning a un coût initial élevé et un coût marginal par requête faible. Entraîner un adaptateur LoRA sur un modèle ouvert de 7 à 13 milliards de paramètres avec quelques milliers d’exemples peut coûter de quelques dizaines à quelques centaines de dollars de compute, plus plusieurs heures de travail d’ingénierie pour constituer les données ; un fine-tuning complet sur des modèles plus grands coûte sensiblement plus. Une fois entraîné, l’inférence est un simple passage avant sans latence de récupération supplémentaire, sans base vectorielle à interroger, et sans tokens supplémentaires consommés par du contexte injecté — ce qui compte à l’échelle, puisque le contexte récupéré par le RAG ajoute souvent 500 à 2000 tokens par requête, augmentant directement le coût et la latence par requête.

Le RAG inverse cette logique : un coût initial quasi nul (vous pouvez répondre à des questions sur votre corpus documentaire en une après-midi avec un modèle d’embedding standard et une base vectorielle), mais un coût opérationnel continu — vous exécutez un pipeline de récupération (génération d’embeddings, recherche vectorielle, souvent une étape de reranking) à chaque requête, plus l’infrastructure nécessaire pour garder l’index à jour à mesure que les documents sources évoluent. Pour une base de connaissances mise à jour quotidiennement, cette fraîcheur est exactement ce que vous payez ; un modèle fine-tuné n’a pas d’équivalent et exige un cycle complet de réentraînement pour refléter la même mise à jour.

C’est sur la maintenance que l’asymétrie est la plus marquée. Mettre à jour les connaissances d’un système RAG est généralement une opération de ré-embedding et de réindexation que vous pouvez automatiser avec un pipeline simple déclenché par les changements de documents — pas d’entraînement de modèle, pas de suite de tests de régression, pas de risque d’oubli catastrophique. Mettre à jour les connaissances d’un modèle fine-tuné signifie constituer de nouveaux exemples d’entraînement, réentraîner, et relancer toute votre suite d’évaluation pour confirmer que la mise à jour n’a pas dégradé des comportements non liés — une boucle sensiblement plus lente et plus risquée.

3. L’approche hybride : spécialiste fine-tuné avec RAG

Les deux techniques sont complémentaires, pas concurrentes, et la plupart des systèmes de production sophistiqués en 2026 utilisent les deux. Un pattern courant consiste à fine-tuner un modèle plus petit et moins cher pour qu’il respecte de façon fiable un format de sortie strict (extraction JSON structurée, style de citation spécifique, ton propre à l’entreprise), tout en lui fournissant des documents récupérés via RAG pour le contenu factuel réel. Cela offre le contrôle de forme dans lequel le fine-tuning excelle et la fraîcheur des connaissances dans laquelle le RAG excelle, sans demander à l’une des deux techniques de faire le travail de l’autre.

Un autre hybride efficace consiste à fine-tuner spécifiquement pour la qualité de récupération plutôt que pour la génération : fine-tuner le modèle d’embedding lui-même (ou un reranker) sur des paires requête-document propres à votre domaine, afin que la récupération renvoie des extraits plus pertinents pour du jargon métier qu’un modèle d’embedding généraliste ne distingue pas bien. C’est souvent un meilleur retour sur investissement que de fine-tuner le modèle de génération, car la qualité de récupération est fréquemment le véritable goulet d’étranglement de la qualité des réponses d’un système RAG, pas la fluidité du générateur.

Un troisième pattern mérite d’être nommé : fine-tuner pour des schémas d’usage d’outils et de raisonnement propres à votre domaine (par exemple, un modèle qui décide de façon fiable quand appeler un outil de recherche plutôt que répondre à partir de ses propres connaissances, ou qui suit un gabarit de raisonnement multi-étapes précis pour un flux de support), tout en laissant l’ancrage factuel passer entièrement par le RAG au moment de l’inférence. Cela sépare proprement « comment le modèle se comporte » de « ce que le modèle sait », en cohérence avec le modèle mental de la première section.

4. Évaluation : savoir ce qui a vraiment fonctionné

Aucune des deux approches ne devrait passer en production sans un jeu d’évaluation mis de côté qui reflète les vraies requêtes utilisateur, et les métriques à suivre diffèrent sensiblement entre les deux. Pour le RAG, la précision et le rappel de la récupération à k sont les indicateurs principaux — si le bon document n’est pas dans les 5 premiers extraits récupérés, aucune qualité de génération ne produira une réponse correcte ; déboguer une mauvaise réponse RAG devrait donc toujours commencer par inspecter ce qui a réellement été récupéré, avant de blâmer le modèle.

Pour le fine-tuning, le contrôle critique est la régression sur les capacités générales du modèle de base, pas seulement l’amélioration sur la tâche ciblée. Il est courant qu’un fine-tuning améliore le comportement visé tout en dégradant discrètement le suivi d’instructions ou le raisonnement sur des tâches hors de la distribution d’entraînement — un phénomène parfois appelé oubli catastrophique, même sous des formes légères. Faire tourner toute votre suite d’évaluation existante (pas seulement l’évaluation de la nouvelle tâche) avant et après un fine-tuning est le seul moyen fiable de détecter cela avant que ça n’atteigne la production.

5. Synthèse décisionnelle

Partez du RAG si le problème central est « le modèle ne connaît pas X » — nouveaux documents, informations qui changent fréquemment, données propriétaires ou privées sur lesquelles le modèle de base n’a jamais été entraîné, ou tout ce qui doit pouvoir être individuellement cité vers un document source. Cela couvre la grande majorité des cas d’usage LLM en entreprise : bases de connaissances internes, support client ancré dans la documentation produit, assistants augmentés par la recherche.

Tournez-vous vers le fine-tuning si le problème central est « le modèle connaît les bonnes choses mais répond de la mauvaise façon » — format de sortie incohérent, ton inadapté à votre marque, incapacité à suivre de façon fiable un schéma structuré précis, ou schémas de raisonnement métier que le prompting few-shot ne parvient pas à stabiliser sur de nombreuses requêtes. Le fine-tuning est aussi le bon choix quand les exemples few-shot dans le prompt consomment trop de votre budget de contexte ou trop de latence pour être inclus à chaque requête.

Combinez les deux quand vous avez besoin d’une forme fiable par-dessus des connaissances fraîches et citables — ce qui décrit la plupart des assistants de production sérieux. Construisez d’abord le pipeline RAG, car il est moins coûteux à itérer et vous amènera généralement à 70-80 % d’un système acceptable ; n’ajoutez le fine-tuning qu’une fois identifié un problème de forme ou de comportement précis et persistant que de meilleurs prompts et un meilleur réglage de la récupération ne peuvent réellement pas corriger.