RAG ou fine-tuning pour un LLM en production ?

Le bon choix dépend du problème réel : information ou comportement. Si vos connaissances bougent souvent, le RAG gagne vite. Si le modèle doit adopter un style ou une logique stable, le fine-tuning devient intéressant. Le piège, c’est de confondre les deux.

Quel problème voulez-vous résoudre ?

Le choix entre RAG et fine-tuning devient beaucoup plus simple quand je pose la bonne question : Est-ce que le modèle manque d’information, ou est-ce qu’il se comporte mal ?

Si le problème vient d’un manque de connaissance, je pars plutôt sur du RAG. Le RAG, pour Retrieval-Augmented Generation, consiste à récupérer des documents, des extraits, des données métier ou des connaissances externes, puis à les ajouter au prompt au moment de la requête. Le modèle ne “sait” pas tout par magie, on lui met juste les bonnes infos sous les yeux avant qu’il réponde.

Si le problème vient du comportement du modèle, je regarde plutôt le fine-tuning. Le fine-tuning consiste à entraîner le modèle sur des exemples pour modifier sa façon de répondre. On ne lui donne pas seulement du contexte, on lui apprend une forme, un style, une structure, parfois une logique de réponse plus adaptée à votre cas.

Beaucoup de projets se plantent à cet endroit. J’ai vu des équipes vouloir fine-tuner un modèle pour intégrer une documentation produit. Sur le papier, ça semblait logique. Dans la vraie vie, la documentation changeait toutes les semaines. Un RAG propre aurait permis de mettre à jour les informations sans relancer un entraînement, sans versionner un nouveau modèle, sans recréer toute une chaîne de validation.

Découvrez égalementRAG vs fine-tuning quel choix pour vos LLM ?

L’inverse arrive aussi. Certaines équipes empilent du RAG partout alors que le vrai sujet, c’est que le modèle ne respecte pas les consignes. Il reçoit les bons documents, mais il répond quand même dans le mauvais format, il oublie des règles, il improvise. Dans ce cas, ajouter encore plus de contexte ne règle pas le fond du problème.

La suite est donc assez naturelle. Je vais regarder comment fonctionne le RAG, comment fonctionne le fine-tuning, puis les vrais arbitrages de production : coût, latence, maintenance, gouvernance, mises à jour et niveau de contrôle réel.

Comment fonctionne le RAG ?

Le RAG, pour Retrieval Augmented Generation, fonctionne simplement : je vais chercher du contexte externe pertinent au moment où la question est posée, puis je le donne au modèle pour qu’il réponde avec de meilleures informations. Le LLM ne “sait” pas tout par magie. Il reçoit les bons extraits, au bon moment, et il s’en sert pour générer sa réponse.

Le flux ressemble souvent à ça dans une entreprise :

• On part de documents internes : documentation produit, politiques RH, tarifs, fiches support, procédures métier, base de connaissances client.
• On découpe ces contenus en petits passages, parce qu’un modèle travaille mieux avec des blocs précis qu’avec un PDF de 80 pages.
• On transforme chaque passage en embedding, c’est-à-dire une représentation numérique du sens du texte.
• On stocke ces embeddings dans une base vectorielle, ou dans un moteur de recherche plus classique.
• Quand l’utilisateur pose une question, on récupère les passages les plus pertinents.
• On injecte ces passages dans le prompt, puis le modèle génère la réponse.

Le gros avantage, c’est la mise à jour. Si un prix change, si une règle conformité évolue, si une procédure support est corrigée, je mets à jour le document ou l’index. Je ne réentraîne pas le modèle. C’est souvent ce qui rend le RAG beaucoup plus réaliste en production qu’un fine-tuning pour tout ce qui bouge souvent.

Découvrez égalementComment créer un RAG avec Gemini API File Search ?

Mais il faut être honnête : un RAG moyen donne des réponses moyennes. Si la recherche récupère le mauvais contexte, le modèle va répondre avec les mauvais éléments, parfois avec beaucoup d’assurance. Je l’ai vu chez un client avec une base support mal découpée : le LLM répondait proprement, mais sur l’ancienne version du produit.

Un bon RAG demande donc un vrai moteur de recherche. La recherche dense par embeddings aide à retrouver le sens. La recherche sparse, basée sur les mots clés, reste utile pour des références exactes comme un code produit, un tarif ou une clause. Le re-ranking sert à retrier les résultats pour garder les meilleurs passages. Le monitoring permet de vérifier ce qui est récupéré, ce qui est répondu, et là où ça dérape.

Le RAG aide aussi beaucoup côté gouvernance. On peut tracer les sources utilisées, contrôler les documents injectés, auditer la base de connaissance et limiter les réponses inventées. Il ne supprime pas toutes les hallucinations. Il réduit surtout le risque quand la récupération, les prompts et les contrôles sont bien faits.

À quoi sert le fine-tuning ?

Le fine-tuning ne sert pas d’abord à “ajouter de la connaissance” dans un modèle. Je le vois plutôt comme une façon de lui apprendre un comportement stable. Un ton, un format, une manière de répondre, une logique métier qui doit revenir encore et encore sans remettre trois pages de consignes dans chaque prompt.

Concrètement, le fine-tuning modifie les poids du modèle. Les poids, c’est un peu sa mémoire interne statistique, ce qui influence ses réponses. On lui donne des exemples supplémentaires, avec une entrée et une sortie attendue, puis il apprend à reproduire ce pattern. Si les exemples sont bons, il devient plus régulier. Si les exemples sont mauvais, il apprend n’importe quoi. C’est brutal, mais c’est souvent ça.

Découvrez égalementQuelle mémoire LLM choisir pour un agent IA fiable ?

Le fine-tuning a été très utile à une époque où les fenêtres de contexte étaient petites et chères. La fenêtre de contexte, c’est la quantité de texte que le modèle peut lire à chaque requête. Quand on ne pouvait pas lui donner beaucoup d’informations, entraîner le modèle sur des exemples était souvent la meilleure option.

Aujourd’hui, avec des contextes plus longs et des systèmes RAG plus solides, il faut vraiment justifier le fine-tuning. Surtout si le seul objectif, c’est d’ajouter des connaissances fraîches. Dans ce cas, je préfère souvent connecter le modèle à une base documentaire via du RAG. C’est plus simple à mettre à jour, plus contrôlable, et moins risqué.

Le fine-tuning demande un vrai chantier. Il faut préparer les données, nettoyer les exemples, tester les sorties, payer l’entraînement, versionner les datasets, gouverner les modèles. Et surtout, il faut éviter d’entraîner sur des réponses bancales. Un mauvais dataset donne un mauvais fine-tuning. J’ai déjà vu un client entraîner un modèle sur des tickets support historiques remplis de réponses approximatives. Résultat, le modèle est devenu très bon pour être approximatif.

Avant de fine-tuner, je teste souvent une version plus légère : RAG plus quelques exemples few-shot dans le prompt. Le few-shot, c’est simplement donner au modèle deux ou trois exemples du résultat attendu. Ça ne remplace pas toujours un fine-tuning, mais ça permet de vérifier vite si le besoin est réel avant de lancer un chantier plus lourd.

Quels compromis en production ?

En production, le choix se joue rarement sur une préférence théorique. Je regarde surtout cinq choses : le coût, la latence, la maintenance, la gouvernance et la capacité à faire évoluer le système sans tout casser.

Avec un RAG, le coût ne disparaît pas, il se déplace vers l’exécution. RAG veut dire Retrieval Augmented Generation, donc génération augmentée par récupération d’information. Avant de répondre, le système cherche des documents utiles, les injecte dans le contexte du modèle, puis génère la réponse. Ça veut dire embeddings, base vectorielle, recherche, parfois re-ranking, orchestration, logs, monitoring. Tout ça tourne à chaque requête, ou presque. Et oui, ça peut ajouter de la latence, parce qu’il y a une étape de récupération avant la génération.

Avec le fine-tuning, les coûts sont plutôt frontalisés. Il faut collecter les données, les nettoyer, créer les exemples, entraîner le modèle, l’évaluer, le déployer. C’est du travail sérieux. Une fois en production, par contre, un modèle fine-tuné, surtout s’il est plus petit ou open-weight, peut être plus rapide à l’inférence. Il n’a pas forcément besoin d’aller chercher des morceaux de documentation ailleurs avant de répondre.

Je le nuance quand même, parce que dans la vraie vie ce n’est pas RAG contre fine-tuning pour le plaisir. Dans beaucoup de systèmes solides, les deux cohabitent très bien. Le RAG apporte les faits à jour. Le fine-tuning stabilise le comportement, le format, le ton, les réflexes métier. Mais je conseille rarement de complexifier trop tôt. Chez un client, on avait commencé par parler fine-tuning. En regardant les erreurs, 80 % venaient juste d’une mauvaise récupération documentaire. On a nettoyé le RAG, et ça a suffi.

Mon réflexe est simple : si le problème est documentaire, je pars souvent d’un RAG propre, je mesure les erreurs, puis seulement après je regarde si le fine-tuning vaut le coût.

Comment décider sans se tromper ?

Je décide rarement entre RAG et fine-tuning en partant de la techno. Je pars de l’erreur. C’est beaucoup plus fiable. Un RAG, pour faire simple, ajoute une étape de recherche dans vos documents avant de répondre. Le fine-tuning, lui, réentraîne un modèle sur des exemples pour modifier son comportement.

La vraie question, c’est celle-ci : pourquoi le modèle se trompe ? Si le modèle invente parce qu’il n’a pas la bonne information, je choisis plutôt RAG. Si le modèle a l’information mais répond mal, dans le mauvais format, avec le mauvais ton, ou sans respecter vos règles, là je regarde le fine-tuning.

Le RAG est souvent le bon choix quand on parle de connaissances propriétaires, de documentation produit, de politiques internes, de tarifs, de contenus qui changent souvent. J’y vais aussi quand le client a besoin de citer ses sources, de tracer d’où vient une réponse, ou de mettre à jour les connaissances sans relancer un entraînement. Dans une boîte avec des procédures qui changent tous les mois, le fine-tuning devient vite pénible. Le RAG respire mieux.

Le fine-tuning devient intéressant quand le problème est plus comportemental. Je l’utilise pour rendre une réponse répétable, imposer un format strict, adopter un ton spécifique, faire de la classification ou de l’extraction très stable. Il peut aussi servir à spécialiser un petit LLM, un grand modèle de langage, ou à réduire des prompts énormes à l’inférence. Moins de texte envoyé à chaque requête, parfois moins de coût, parfois moins de latence.

Quand les deux problèmes existent, je sépare les tests. Je mesure d’un côté la qualité de récupération. Est-ce que le bon document remonte ? Je mesure de l’autre côté la qualité du comportement. Est-ce que le modèle répond correctement quand je lui donne déjà la bonne information ? Ça évite de corriger le mauvais étage.

Avant de choisir, je regarde quelques indicateurs simples : taux de récupération correcte, exactitude factuelle, respect du format, latence, coût par requête, effort de maintenance. C’est moins glamour qu’un débat d’architecture, je sais. Mais c’est exactement ce qui évite de payer cher une mauvaise intuition.

Alors vous partez sur quoi maintenant ?

Je résume simplement : le RAG sert surtout à donner au LLM les bonnes informations au bon moment. Le fine-tuning sert plutôt à lui apprendre un comportement plus fiable, un style, un format ou une logique stable. En production, le vrai sujet n’est pas de choisir la techno la plus tendance, c’est de comprendre où se situe l’erreur. Information manquante, RAG. Comportement instable, fine-tuning. Et parfois les deux, mais pas dès le premier jour. Si vous posez ce diagnostic proprement, vous réduisez les coûts, la latence inutile, la maintenance bancale et vous construisez un système LLM plus fiable pour votre business.

FAQ

• Quelle est la différence entre RAG et fine-tuning ?
  Le RAG ajoute des connaissances externes au moment de la requête. Le fine-tuning modifie le modèle avec des exemples d’entraînement. En clair, le RAG aide le modèle à accéder aux bonnes informations, le fine-tuning l’aide à mieux se comporter.
• Quand faut-il choisir le RAG pour un LLM ?
  Je choisis le RAG quand les connaissances sont volumineuses, propriétaires ou souvent mises à jour. C’est typiquement le cas pour une documentation produit, des politiques internes, des prix, des procédures support ou une base de connaissances métier.
• Quand le fine-tuning devient-il plus intéressant ?
  Le fine-tuning devient pertinent quand le problème vient du comportement du modèle : ton de réponse, format strict, classification stable, extraction structurée, cohérence sur un petit modèle. Il est moins adapté si l’objectif est juste d’ajouter des connaissances qui changent souvent.
• Le RAG réduit-il vraiment les hallucinations ?
  Il peut les réduire, oui, mais seulement si la récupération est bonne. Si le système récupère les mauvais documents, le modèle peut quand même répondre à côté. Un bon RAG demande des documents propres, une recherche fiable, parfois du re-ranking, et une évaluation régulière.
• Peut-on combiner RAG et fine-tuning ?
  Oui, et c’est souvent une bonne architecture en production. Le RAG apporte les faits à jour, le fine-tuning stabilise le comportement. Je conseille quand même de commencer simple, de mesurer les erreurs, puis d’ajouter le fine-tuning seulement si le besoin est clair.

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en Tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent passer de la démo IA sympa à des systèmes vraiment exploitables en production. Avec webAnalyste et Formations Analytics, j’ai travaillé pour des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer un projet RAG, fine-tuning ou automatisation IA sans partir dans tous les sens, contactez-moi.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.