Un modèle de langage généraliste connaît Wikipédia, mais pas votre catalogue produit. Il sait écrire un courriel, mais pas avec votre charte juridique. Il répond avec aplomb sur le droit du travail français, sauf que ses connaissances s’arrêtent à sa date d’entraînement. Pour le rendre utile sur votre besoin, il faut le spécialiser. Et là, trois familles de méthodes s’affrontent, souvent confondues : le prompting, le RAG et le fine-tuning.
Ces trois leviers ne font pas la même chose, ne coûtent pas la même chose, et ne répondent pas au même problème. Les confondre, c’est dépenser des semaines à fine-tuner un modèle quand un simple bloc de contexte aurait suffi. Ce dossier décortique le mécanisme réel de chacune, ce qu’en dit la recherche primaire (Lewis et al. 2020 pour le RAG, Brown et al. 2020 pour l’in-context learning, Ovadia et al. 2024 pour la comparaison directe), leurs coûts, et propose une grille de décision testable.
Avant le mécanisme, posons les définitions. Chacune doit tenir seule.
Spécialiser un LLM, les trois leviers :
- Prompting : on guide le modèle via les instructions et les exemples placés dans la fenêtre de contexte, sans rien modifier au modèle.
- RAG : on récupère à la volée des documents pertinents dans une base externe et on les injecte dans le prompt avant de générer la réponse.
- Fine-tuning : on poursuit l’entraînement du modèle sur des données spécifiques, ce qui modifie ses poids de façon permanente.
La distinction de fond tient en deux questions. Première question : est-ce qu’on touche aux poids du modèle ? Non pour le prompting et le RAG, oui pour le fine-tuning. Deuxième question : d’où vient l’information au moment de répondre ? Du prompt seul (prompting), d’une base interrogée en direct (RAG), ou de la mémoire interne du modèle (fine-tuning). Tout le reste découle de ces deux axes.
Le prompting est la méthode qui consiste à spécialiser un modèle uniquement par le texte qu’on lui envoie : instructions, rôle, format attendu, et éventuellement quelques exemples résolus. Aucun entraînement, aucune infrastructure. C’est la méthode par défaut, et souvent la seule nécessaire.
La découverte qui rend le prompting puissant porte un nom : in-context learning, l’apprentissage en contexte. Brown et ses coauteurs, dans le papier qui a introduit GPT-3, ont montré qu’un modèle de langage suffisamment grand peut accomplir une tâche nouvelle simplement en lisant quelques exemples placés dans son prompt, sans aucune mise à jour de ses poids. Le modèle ne « réapprend » rien. Il reconnaît un motif dans les exemples fournis et le prolonge.
Techniquement, le modèle conditionne sa prédiction du mot suivant sur l’intégralité du contexte présent. Quand vous écrivez « Traduis en allemand. chat : Katze. chien : Hund. oiseau : », le modèle infère la règle « mot français deux-points traduction allemande » à partir des deux exemples, puis la complète. Brown et al. nomment cela le few-shot learning : la performance grimpe avec le nombre d’exemples montrés, sans gradient, sans entraînement.
In-context learning, ce que montre le papier GPT-3 :
- 175 milliards de paramètres / taille du modèle GPT-3 testé
- 0 mise à jour de poids / la performance vient du seul prompt
- 3 régimes étudiés / zero-shot, one-shot, few-shot (jusqu’à 100 exemples)
- la performance few-shot croît avec la taille du modèle / l’effet est quasi nul sur les petits modèles
Source : Brown et al., Language Models are Few-Shot Learners, arXiv:2005.14165, NeurIPS 2020.
Le prompting gagne sur trois terrains : le délai (zéro temps de mise en place), le coût fixe (nul) et la souplesse (vous changez l’instruction en une seconde). Pour cadrer un ton, imposer un format de sortie, ou faire raisonner le modèle sur un cas, c’est imbattable. C’est d’ailleurs l’un des leviers qui distinguent un usage avancé de l’IA d’un usage de surface.
Sa limite est physique : la fenêtre de contexte. Tout doit tenir dans le prompt. Vous ne pouvez pas y coller 40 000 pages de documentation interne, et même si vous le pouviez, chaque token coûte à chaque requête. Le prompting ne donne pas non plus de connaissance nouvelle durable au modèle : il la lui prête le temps d’une réponse. Dès la requête suivante, le modèle a tout oublié. C’est exactement le manque que le RAG vient combler.
Le RAG (Retrieval-Augmented Generation, ou génération augmentée par récupération) est une architecture qui, avant de générer une réponse, va récupérer les documents les plus pertinents dans une base externe et les injecte dans le contexte du modèle. Le terme et la méthode viennent de Lewis et al., chez Facebook AI, en 2020.
Le pipeline RAG se déroule en quatre temps, et comprendre l’enchaînement évite la plupart des contresens sur la méthode.
Le point clé que beaucoup ratent : dans le RAG, le modèle ne mémorise rien. Sa connaissance reste celle de son entraînement. Ce qui change, c’est qu’on lui sert, au bon moment, la bonne page. Lewis et al. décrivent cette architecture comme la combinaison d’une mémoire paramétrique (les poids du modèle pré-entraîné) et d’une mémoire non paramétrique (l’index vectoriel de Wikipédia, consultable et modifiable). On peut mettre à jour la base sans toucher au modèle.
RAG, le papier fondateur (Lewis et al., 2020) :
- 2 mémoires combinées / paramétrique (le modèle) et non paramétrique (l’index)
- 21 millions de passages Wikipédia / la base de connaissance externe indexée
- état de l’art sur 3 tâches de question-réponse en domaine ouvert / au moment de la publication
- la base est éditable sans réentraîner le modèle / la connaissance se met à jour à chaud
Source : Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, arXiv:2005.11401, NeurIPS 2020.
L’argument central en faveur du RAG : il ancre la réponse dans des sources réelles et citables, au lieu de laisser le modèle puiser dans sa mémoire floue. Quand le modèle répond à partir d’un passage qu’on lui a fourni, il peut citer sa source, et l’utilisateur peut vérifier. C’est un garde-fou, pas une garantie. Le modèle peut toujours mal interpréter un passage, ou inventer si la récupération échoue à trouver le bon document. Sur le mécanisme profond de l’invention, voir notre décryptage de pourquoi les LLM hallucinent.
La qualité d’un RAG dépend presque entièrement de la qualité de la récupération. Si l’étape 2 remonte le mauvais passage, le modèle répondra parfaitement à côté, avec assurance. D’où une vérité de terrain : un projet RAG qui déçoit est presque toujours un problème de découpage des documents ou d’embeddings, rarement un problème de modèle.
Le fine-tuning est la méthode qui poursuit l’entraînement d’un modèle pré-entraîné sur un jeu de données spécifique, ce qui ajuste ses poids de façon permanente. Contrairement aux deux autres méthodes, ici on transforme le modèle. Le résultat est un nouveau modèle, spécialisé.
Fine-tuner, c’est refaire de la descente de gradient sur de nouvelles données : on montre au modèle des paires entrée/sortie de qualité, on mesure son erreur, on ajuste ses poids pour la réduire, on recommence. Le problème, sur un modèle à des milliards de paramètres, c’est le coût. Réentraîner tous les poids de GPT-3 demande une infrastructure de plusieurs dizaines de gigaoctets de mémoire GPU rien que pour stocker les états de l’optimiseur.
C’est ce qui a rendu LoRA incontournable. Hu et al., chez Microsoft, ont proposé en 2021 de geler les poids d’origine et de n’entraîner que de petites matrices ajoutées, en pariant que l’ajustement nécessaire a un « rang intrinsèque » faible. Le gain est spectaculaire et il explique pourquoi le fine-tuning est devenu accessible.
LoRA, le fine-tuning rendu abordable (Hu et al., 2021) :
- 10 000 fois moins de paramètres entraînables / vs un fine-tuning complet de GPT-3 175B
- 3 fois moins de mémoire GPU requise / vs l’entraînement complet
- 0 latence ajoutée à l’inférence / les matrices peuvent être fusionnées aux poids d’origine
- qualité comparable au fine-tuning complet / sur les tâches testées dans le papier
Source : Hu et al., LoRA: Low-Rank Adaptation of Large Language Models, arXiv:2106.09685, 2021.
Le fine-tuning excelle pour enseigner un comportement ou un format : un ton de marque, un style de réponse, une structure de sortie systématique, une tâche très répétitive. Il déplace cette compétence dans le modèle, donc plus besoin de la rappeler dans chaque prompt. Sur des tâches de classification ou d’extraction très spécialisées, un petit modèle fine-tuné peut battre un gros modèle généraliste, pour bien moins cher à l’inférence.
Là où il déçoit souvent, c’est pour injecter des connaissances factuelles. Et ce n’est pas une intuition, c’est mesuré. C’est exactement la question qu’a tranchée la recherche.
La question « faut-il fine-tuner ou faire du RAG pour donner de la connaissance à un modèle ? » a été étudiée directement. Deux papiers font référence, et ils convergent.
Ovadia et ses coauteurs ont comparé frontalement le fine-tuning non supervisé et le RAG sur des tâches exigeant de la connaissance, sur plusieurs sujets et plusieurs modèles. Leur conclusion est nette : le RAG l’emporte de façon constante, à la fois sur des connaissances déjà vues à l’entraînement et sur des connaissances entièrement nouvelles. Pire pour le fine-tuning, les modèles peinent à apprendre des faits nouveaux par ce biais.
RAG vs fine-tuning pour la connaissance (Ovadia et al., EMNLP 2024) :
- 0,875 vs 0,504 / score RAG contre fine-tuning sur des faits d’actualité nouveaux (modèle Mistral 7B)
- 0,876 vs 0,511 / même comparaison sur le modèle Orca2 7B
- le RAG plus que double le score / sur l’injection de connaissances entièrement nouvelles
- exposer le modèle à plusieurs variations d’un même fait / atténue, sans résoudre, la difficulté du fine-tuning
Source : Ovadia, Brief, Mishaeli, Elisha, Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs, arXiv:2312.05934, EMNLP 2024.
La lecture d’expert : le fine-tuning non supervisé est mauvais pour mémoriser des faits précis parce qu’on demande au modèle d’encoder une information ponctuelle dans des poids conçus pour capturer des régularités statistiques. Le RAG, lui, garde le fait à l’extérieur, intact, et le ressort au moment voulu. Pour de la connaissance qui change ou qui doit être exacte, externaliser bat mémoriser.
Le deuxième papier nuance la guerre RAG contre fine-tuning. Balaguer et al., dans une étude appliquée au domaine agricole, montrent que les deux approches sont cumulatives. Le fine-tuning apporte un gain, le RAG en apporte un autre par-dessus, et l’addition donne le meilleur résultat.
RAG et fine-tuning combinés (Balaguer et al., 2024, étude agriculture) :
- plus de 6 points de pourcentage gagnés / par le fine-tuning seul
- 5 points de pourcentage supplémentaires / ajoutés par le RAG par-dessus le fine-tuning
- gains cumulatifs / les deux méthodes ne se concurrencent pas, elles s’additionnent
- modèles testés / Llama2-13B, GPT-3.5 et GPT-4
Source : Balaguer et al. (Microsoft), RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture, arXiv:2401.08406, 2024.
La synthèse qui se dégage des deux études : pour savoir des choses (faits, documentation, données à jour), le RAG est l’outil. Pour se comporter d’une certaine façon (style, format, tâche spécialisée), le fine-tuning est l’outil. Et sur les cas exigeants, on combine les deux.
Ces résultats portent sur des modèles et des tâches précis, à un instant donné. Le fine-tuning testé chez Ovadia et al. est non supervisé ; un fine-tuning supervisé sur des paires question-réponse de qualité se comporte différemment. Et les modèles progressent vite : une fenêtre de contexte qui passe à plusieurs centaines de milliers de tokens change l’équation du prompting, qui peut alors avaler ce qui aurait demandé un RAG il y a deux ans. Les conclusions tiennent sur le fond ; les seuils bougent.
Voici les trois méthodes confrontées sur les critères qui décident d’un projet.
| Critère | Prompting | RAG | Fine-tuning |
|---|---|---|---|
| Modifie les poids du modèle | Non | Non | Oui |
| Coût de mise en place | Nul | Moyen (base vectorielle) | Élevé (entraînement) |
| Délai avant production | Minutes | Jours à semaines | Semaines |
| Mise à jour des connaissances | À chaque prompt | Immédiate (on édite la base) | Réentraînement requis |
| Apporte des faits nouveaux | Oui, temporairement | Oui, durablement | Mal (cf. Ovadia et al.) |
| Apprend un style ou un format | Partiellement | Non | Oui, sa spécialité |
| Réponses traçables et citables | Non | Oui | Non |
| Coût récurrent à l’inférence | Tokens du prompt | Tokens du contexte récupéré | Souvent supérieur au modèle de base |
Une précision sur la dernière ligne, car elle surprend souvent : un modèle fine-tuné se facture généralement plus cher à l’usage que le modèle de base. Chez OpenAI, l’inférence sur GPT-4.1 fine-tuné se facture autour de 3 $ par million de tokens en entrée et 12 $ en sortie, soit l’ordre de grandeur du modèle de base, auquel s’ajoute le coût d’entraînement initial. Le fine-tuning n’est donc pas un raccourci économique par défaut : il le devient seulement quand il permet de basculer vers un modèle beaucoup plus petit.
Ordres de grandeur de coût (tarifs OpenAI, 2025) :
- 3 $ par million de tokens / entraînement d’un fine-tuning GPT-4.1
- 3 $ / 12 $ par million de tokens / inférence entrée/sortie d’un GPT-4.1 fine-tuné
- 0,80 $ par million de tokens / entraînement d’un GPT-4.1 mini (option économique)
- le prompting et le RAG / aucun coût d’entraînement, on paie les tokens de contexte
Source : OpenAI, grille tarifaire API, consultée en 2025 (tarifs susceptibles d’évoluer).
La règle de tri tient en une logique d’escalade : on commence toujours par le moins cher, on ne monte d’un cran que si le besoin l’exige. Inutile de fine-tuner ce qu’un prompt résout.
Le piège le plus courant dans les projets : vouloir fine-tuner pour « apprendre la documentation au modèle ». C’est l’erreur que la recherche déconseille explicitement. La documentation, on la met dans un RAG. Le fine-tuning, on le garde pour la manière de répondre, pas pour ce qu’il y a à savoir.
Quelle est la différence entre RAG et fine-tuning ?
Le RAG laisse le modèle intact et lui fournit, à chaque requête, des documents récupérés dans une base externe. Le fine-tuning modifie les poids du modèle en le réentraînant sur des données spécifiques. Le RAG excelle pour la connaissance factuelle et à jour ; le fine-tuning pour le style et le comportement. Les deux peuvent se combiner.
Le prompting suffit-il pour spécialiser une IA ?
Dans une majorité de cas, oui. Si votre besoin est de cadrer un ton, un format ou de raisonner sur des données qui tiennent dans la fenêtre de contexte, le prompting suffit, sans coût ni infrastructure. Il atteint sa limite quand la connaissance est trop volumineuse pour le contexte ou doit être tracée à une source.
Le fine-tuning permet-il d’apprendre de nouvelles connaissances à un modèle ?
Mal, selon la recherche. L’étude d’Ovadia et al. (EMNLP 2024) montre que le RAG dépasse largement le fine-tuning non supervisé pour injecter des faits nouveaux, avec des scores plus que doublés. Pour de la connaissance, le RAG est l’outil adapté ; le fine-tuning sert plutôt à enseigner un comportement.
RAG ou fine-tuning : lequel coûte le moins cher ?
Le RAG n’a pas de coût d’entraînement mais paie les tokens du contexte récupéré à chaque requête. Le fine-tuning a un coût d’entraînement initial et une inférence souvent plus chère que le modèle de base. Le fine-tuning ne devient économique que s’il permet de basculer vers un modèle nettement plus petit.
Peut-on combiner RAG et fine-tuning ?
Oui, et c’est même recommandé sur les cas exigeants. L’étude Microsoft sur l’agriculture (Balaguer et al., 2024) montre des gains cumulatifs : plus de 6 points de pourcentage par le fine-tuning, puis 5 points supplémentaires par le RAG par-dessus. Le fine-tuning fixe le comportement, le RAG apporte la connaissance à jour.
Spécialiser une IA n’est pas un choix unique mais une escalade : prompting d’abord, RAG quand la connaissance dépasse le contexte, fine-tuning quand c’est le comportement qu’il faut graver. La recherche est claire sur la ligne de partage. Le RAG pour ce que le modèle doit savoir, le fine-tuning pour ce qu’il doit faire, et le prompting pour tout amorcer. Choisir le bon levier, c’est déjà la moitié de la réussite d’un projet IA.
Vous avez un cas concret et hésitez sur l’approche ? C’est exactement le genre d’arbitrage que nous traitons à l’agence Ordiama : choisir l’architecture la plus simple qui résout vraiment le problème, sans sur-ingénierie.
Ordiama, c'est aussi une agence IA à Strasbourg : on crée votre site, on vous rend visible dans l'IA et on automatise vos tâches.