Ce que chaque approche résout réellement
Trois leviers pour adapter un modèle
Face à un modèle de langage (Claude, GPT, Gemini, Llama, Mistral) qui ne répond pas exactement comme souhaité, trois approches existent, souvent confondues alors qu'elles résolvent des problèmes différents.
| Approche | Résout quel problème |
|---|---|
| Prompt engineering | Le modèle a la connaissance nécessaire mais formule mal la réponse (ton, format, structure) |
| RAG | Le modèle n'a pas accès à une information précise, privée ou à jour |
| Fine-tuning | Le modèle a besoin d'un comportement ou style profondément différent, appris sur de nombreux exemples |
Un exemple pour distinguer les trois
Une entreprise veut un assistant qui répond en respectant strictement le ton de sa marque, avec les informations à jour sur ses produits.
- Prompt engineering cadre le ton via un rôle système ("réponds toujours avec humour et un vocabulaire simple").
- RAG connecte le modèle au catalogue produit à jour, mis à jour quotidiennement.
- Fine-tuning pourrait être envisagé si le ton de marque est si spécifique et récurrent qu'un simple prompt ne suffit plus à le reproduire de façon fiable sur des milliers de générations.
Le coût et la complexité croissants
flowchart LR
A[Prompt engineering\nRapide, gratuit, iteratif] --> B[RAG\nInfrastructure a mettre\nen place, cout modere]
B --> C[Fine-tuning\nDonnees d'entrainement,\ncout et delai eleves]
Ces trois approches ne sont pas exclusives : la plupart des systèmes en production combinent prompt engineering et RAG, le fine-tuning restant réservé à des besoins très spécifiques après avoir épuisé les deux premières options.
Cas concret
Une entreprise veut d'abord améliorer un chatbot qui répond de façon trop verbeuse et manque d'informations produit récentes. Plutôt que de se lancer directement dans un coûteux fine-tuning, l'équipe commence par ajuster le prompt système (contrainte de longueur, ton) puis connecte le modèle à un système RAG sur le catalogue produit à jour. Ces deux ajustements, bien moins coûteux qu'un fine-tuning, résolvent la quasi-totalité des problèmes initialement identifiés, sans jamais avoir eu besoin de la troisième approche.
Erreurs fréquentes
- Se lancer directement dans un fine-tuning coûteux pour un problème que le prompt engineering ou le RAG auraient résolu à moindre coût et plus rapidement.
- Confondre "le modèle ne sait pas" (besoin de RAG) avec "le modèle formule mal" (besoin de prompt engineering), deux diagnostics différents avec des solutions différentes.
- Croire que ces trois approches sont mutuellement exclusives, alors que la plupart des systèmes en production combinent prompt engineering et RAG ensemble.
À retenir
- Le prompt engineering ajuste la formulation, le RAG ajoute des connaissances précises et à jour, le fine-tuning modifie un comportement profond du modèle.
- Le coût et la complexité augmentent généralement dans cet ordre : prompt engineering, puis RAG, puis fine-tuning.
- Ces trois approches se combinent souvent en pratique, le fine-tuning restant réservé aux besoins qui ne peuvent pas être résolus autrement.
Mini-exercice
Un chatbot répond correctement sur des sujets généraux mais ne connaît jamais les derniers tarifs de l'entreprise, mis à jour chaque mois. Quelle approche privilégier en premier ?
Réponse : le RAG, qui connecte le modèle à une base de connaissances à jour (les tarifs actuels), un problème d'accès à l'information plutôt qu'un problème de formulation (prompt engineering) ou de comportement profond (fine-tuning).