Fine-tuning vs Prompt Engineering vs RAG : quelle approche pour quel besoin

Face à un besoin précis, trois leviers permettent d'adapter un LLM générique : le prompt engineering change la question, le RAG change le contexte que vous donnez au modèle, le fine-tuning change le modèle lui-même. Ils ne sont pas concurrents. Chacun résout un problème différent, et un système de production utilise souvent les trois. Voici comment savoir quel problème vous avez réellement.

Les trois approches en un coup d'oeil

Lisez ce tableau comme un outil de présélection. Les sections suivantes expliquent quand chaque ligne compte vraiment.

Prompt engineering : le levier le moins cher, à tester en premier

Reformuler l'instruction, donner des exemples travaillés (few-shot), structurer la sortie attendue en schéma JSON ou en sections balisées, demander au modèle de raisonner étape par étape, poser un rôle. Rien de tout cela ne demande de code ni d'infrastructure supplémentaire, et les modèles modernes suivent assez bien les instructions pour qu'un prompt soigné retire souvent le besoin de quelque chose de plus lourd. C'est toujours la première chose à essayer.

• ✓Fait bien : mettre en forme la sortie, améliorer une réponse précise, imposer un format à petite échelle.
• ✓Limite : ne donne aucun accès à des connaissances que le modèle n'a jamais vues à l'entraînement.
• ✓Limite : un long prompt bourré de contexte pour compenser devient cher à chaque appel et fragile d'une version de modèle à l'autre.

RAG : quand le besoin est la connaissance, pas le comportement

Le Retrieval-Augmented Generation embarque vos documents, les stocke dans une base vectorielle, récupère les chunks les plus pertinents au moment de la requête, et les injecte dans le prompt comme contexte. Il répond à un manque de connaissance factuelle, privée ou fraîche : votre documentation, votre catalogue, vos données internes. Il n'entraîne rien. Le modèle reste générique, vous changez ce qu'il voit. Voir le guide complet du RAG pour le détail du pipeline.

• ✓Avantage : les mises à jour sont instantanées, vous réindexez le document modifié et la réponse suivante en tient compte.
• ✓Avantage : traçabilité, chaque réponse peut citer la source exacte d'où elle vient.
• ✓Avantage : aucune donnée d'entraînement à construire, et le modèle sous-jacent reste interchangeable.
• ✓Limite : ne change pas la façon dont le modèle écrit ou raisonne. La qualité du retrieval plafonne la qualité de la réponse.
• ✓Limite : ajoute un vector store et un pipeline à opérer.

Les grandes fenêtres de contexte ne suppriment pas le besoin de RAG. Vous pouvez mettre plus de documents dans le prompt maintenant, mais tout y entasser coûte quand même de l'argent à chaque appel, dilue l'attention du modèle sur du texte non pertinent, et ne vous donne aucun moyen de dire de quel document vient une réponse. Le RAG, c'est récupérer le bon contexte, pas contourner une petite fenêtre.

Fine-tuning : quand le besoin est le comportement, pas la connaissance

Le fine-tuning poursuit l'entraînement du modèle sur vos propres exemples pour changer durablement son comportement : un ton de marque spécifique, un format de sortie rigide, une tâche étroite et spécialisée comme la classification ou l'extraction structurée, ou simplement des prompts plus courts parce que le comportement est désormais intégré. Il demande un jeu de données curé de paires entrée-sortie, en général de quelques centaines à quelques milliers. LoRA et QLoRA le rendent bien moins cher que le fine-tuning complet en n'entraînant qu'un petit ensemble de poids adaptateurs.

// Données de fine-tuning : paires entrée/sortie, un objet JSON par ligne (JSONL)
{"messages": [
  {"role": "system", "content": "Tu es l'assistant support d'Acme."},
  {"role": "user", "content": "Comment réinitialiser mon mot de passe ?"},
  {"role": "assistant", "content": "Ouvrez Paramètres, puis Sécurité, puis Réinitialiser le mot de passe. Un lien vous est envoyé par email."}
]}
{"messages": [ /* ... */ ]}   // des centaines à des milliers d'autres, tous dans le style cible

Le fine-tuning n'est pas les embeddings

Une confusion fréquente. Un modèle d'embedding transforme du texte en vecteur pour que vous puissiez chercher par similarité. C'est la moitié retrieval du RAG, et il ne génère jamais de réponse. Le fine-tuning change les poids d'un modèle génératif pour qu'il écrive différemment. Vous pouvez fine-tuner un modèle d'embedding pour améliorer le retrieval sur votre domaine, mais c'est une tâche distincte du fine-tuning du LLM qui produit la réponse. Modèle différent, travail différent.

Comment choisir : un chemin de décision

• ✓La sortie est fausse en forme ou en qualité, de façon ponctuelle : prompt engineering.
• ✓Le modèle manque de faits qu'il n'a jamais vus à l'entraînement, ou qui changent souvent : RAG.
• ✓Le modèle connaît les faits mais les écrit avec le mauvais ton, format ou niveau de détail, de façon constante : fine-tuning.
• ✓Votre prompt gonfle juste pour imposer un style : fine-tuning, pour déplacer ce style dans le modèle et raccourcir le prompt.
• ✓Vous devez montrer d'où vient une réponse : RAG, jamais fine-tuning.

Les combiner

Les trois approches s'empilent. Un assistant de production les utilise souvent toutes : un modèle fine-tuné pour le ton et le format, du RAG pour les faits, et un prompt soigneusement conçu pour relier le contexte récupéré et la tâche. L'ordre pour les ajouter est l'ordre du coût : commencez par le prompt engineering, ajoutez le RAG quand la connaissance manque, et sortez le fine-tuning en dernier, une fois que le comportement reste à côté après les deux premiers.

Un exemple concret : un assistant support interne. Le prompt engineering pose la tâche et la structure de réponse. Le RAG tire les articles du centre d'aide et les runbooks internes pertinents pour chaque question. Le fine-tuning, ajouté seulement après la mise en ligne de la première version, apprend au modèle à répondre en étapes numérotées courtes et à toujours finir par un lien vers la source, pour que le prompt n'ait plus à l'expliciter à chaque fois.

Coût et effort, dans l'ordre

• ✓Prompt engineering : des heures, pas d'infrastructure, itération en minutes.
• ✓RAG : des jours à des semaines pour construire le pipeline, un coût récurrent pour le vector store et les appels d'embedding, itération par réindexation.
• ✓Fine-tuning : des semaines pour assembler et labelliser les données, un run d'entraînement, et un nouveau run pour chaque changement de comportement. Coût fixe le plus élevé, coût marginal le plus bas une fois entraîné.

FAQ

Quelle est la différence entre RAG et fine-tuning ?

Le RAG donne de l'information au modèle au moment de la requête sans changer le modèle ; le fine-tuning change les poids du modèle avant toute requête. Le RAG est pour la connaissance privée, volumineuse ou qui change souvent. Le fine-tuning est pour un comportement qui doit rester constant. Une réponse RAG peut citer sa source ; une réponse fine-tunée non.

RAG ou fine-tuning pour un chatbot sur ma documentation ?

Le RAG. Le chatbot a besoin de votre documentation comme connaissance, et cette documentation change. Le fine-tuning figerait un instantané dans le modèle qui deviendrait périmé à la mise à jour suivante. Ajoutez un fine-tuning léger par-dessus seulement si vous avez aussi besoin d'un style de réponse très précis que le prompt ne tient pas.

Fine-tuner un LLM, est-ce pareil qu'entraîner un modèle d'embedding ?

Non. Les modèles d'embedding sont entraînés pour la recherche par similarité et alimentent l'étape de retrieval du RAG. Fine-tuner un LLM change la façon dont il génère du texte. Ce sont des modèles différents qui font des travaux différents, et améliorer l'un n'améliore pas l'autre.

Le prompt engineering peut-il remplacer le RAG ?

Jusqu'à un certain point seulement. Vous pouvez coller quelques documents dans le prompt, mais ça ne passe pas à l'échelle : la fenêtre de contexte se remplit, le coût monte à chaque appel, et vous n'avez aucune étape de retrieval pour choisir les parties pertinentes. Au-delà d'une poignée de documents, le RAG est le bon outil.

La question n'est jamais quelle approche est la meilleure. C'est quel problème vous avez. Un manque de connaissance est un problème de RAG. Un manque de comportement est un problème de fine-tuning. Un manque de formulation est un problème de prompt. La plupart des systèmes réels en ont plus d'un, et en utilisent plus d'un.