Vous savez construire, évaluer et améliorer un RAG. Reste la question qui précède tout projet : en ai-je vraiment besoin ? Le RAG est un excellent outil, pas une réponse universelle. Selon le besoin, un simple prompt enrichi, un long-contexte avec prompt caching, ou un fine-tuning peuvent être plus adaptés. Cet article prend du recul : il compare le RAG au fine-tuning et au prompting, donne des critères pour décider si un RAG s'impose, et récapitule comment choisir sa base vectorielle pour la production.
Trois façons de spécialiser un LLM
Pour qu'un LLM réponde sur vos données ou selon votre comportement, trois approches, non exclusives.
- Le prompting (in-context learning) : on place dans le prompt les instructions, exemples et données utiles. Aucun entraînement, effet immédiat, mais borné par la fenêtre de contexte et le coût par token.
- Le RAG : on garde les connaissances à l'extérieur du modèle, dans une base, et on récupère dynamiquement les passages utiles à chaque question. Connaissances fraîches, traçables, mises à jour sans réentraînement.
- Le fine-tuning : on ré-entraîne le modèle sur un jeu d'exemples, ce qui ajuste durablement son style et son comportement — au prix d'un coût d'entraînement et d'une mise à jour lourde.
La distinction décisive : le RAG répond à un besoin de connaissances (quoi savoir), le fine-tuning à un besoin de comportement (comment répondre). On confond souvent les deux.
| Critère | Prompting | RAG | Fine-tuning |
|---|
| Apporte des connaissances à jour | limité (ce qu'on colle) | ✅ oui, dynamiques | ❌ figées à l'entraînement |
| Ajuste le style / comportement | un peu (via instructions) | non | ✅ oui, en profondeur |
| Mise à jour des données | immédiate | immédiate (on édite la base) | lourde (réentraîner) |
| Traçabilité des sources | non | ✅ oui | non |
| Coût initial | nul | moyen (infra) | élevé (entraînement) |
| Risque d'hallucination sur les faits | élevé | réduit (si bien ancré) | élevé |
Fine-tuning et RAG sont complémentaires
Ce n'est pas « RAG ou fine-tuning ». Le fine-tuning apprend au modèle un format, un ton, un jargon métier ou une tâche ; le RAG lui apporte les faits à jour. En production, on combine fréquemment les deux : un modèle fine-tuné sur le ton et la tâche, branché sur un RAG pour les connaissances. Pour les faits qui changent (politiques, catalogue, statut de commande), le fine-tuning est presque toujours le mauvais outil : il faudrait réentraîner à chaque changement.
« Ai-je vraiment besoin d'un RAG ? »
Le RAG ajoute une infrastructure — base vectorielle, pipeline d'ingestion, étape de retrieval, et donc de la latence et des points de défaillance. Avant de la déployer, posez-vous la question honnêtement.
Le long-contexte rend-il le RAG inutile ? Les fenêtres de contexte atteignent aujourd'hui des centaines de milliers de tokens. Si tout votre corpus tient dans le contexte — quelques documents, une base modeste —, vous pouvez parfois tout coller dans le prompt et vous passer de RAG. Le prompt caching rend cette option viable : le préfixe stable (le corpus) est mis en cache côté fournisseur, ce qui réduit fortement le coût et la latence des appels répétés. Pour un petit corpus stable et très sollicité, long-contexte + prompt caching peut battre un RAG en simplicité.
Mais cette option atteint vite ses limites : un corpus volumineux (des milliers de documents) ne tient pas, même dans une grande fenêtre ; coller beaucoup de contexte coûte cher et dilue l'attention du modèle (l'effet « perdu au milieu ») ; et l'on perd la traçabilité fine des sources. Le RAG reste le bon choix dès que le corpus est gros, change souvent, ou qu'on veut citer précisément ses sources.
Quelques repères pour décider :
- Corpus petit, stable, très sollicité → long-contexte + prompt caching, voire prompt simple. Le RAG est peut-être superflu.
- Corpus volumineux ou qui change souvent → RAG.
- Besoin de citer les sources → RAG.
- Besoin d'un ton / format / comportement spécifique → fine-tuning (en complément éventuel d'un RAG).
- Question purement générale, sans données propres → ni RAG ni fine-tuning : le modèle seul suffit.
Choisir sa base vectorielle en production
Pour prototyper, une base locale comme Chroma est parfaite. Le passage en production rouvre le choix, selon des critères qu'on peut hiérarchiser.
- Volume et débit. Quelques milliers de vecteurs : presque tout convient. Des dizaines de millions et des requêtes concurrentes : la performance de l'index devient décisive (Qdrant, Pinecone).
- Hébergement. Auto-hébergé (contrôle, données qui ne sortent pas) ou managé (rapidité, moins d'ops) ? Qdrant et pgvector s'auto-hébergent ; Pinecone est un SaaS ; Qdrant existe aussi en managé.
- Intégration à l'existant. Déjà sur PostgreSQL ? pgvector évite d'ajouter une brique : vecteurs et données métier dans la même base.
- Ouvert ou propriétaire. Coût, réversibilité, souveraineté des données. Open source (Chroma, Qdrant, pgvector) contre SaaS propriétaire (Pinecone).
- Fonctions avancées. Recherche hybride native, filtrage métadonnées riche, latence garantie : tous les moteurs ne se valent pas.
La trajectoire typique : prototyper avec Chroma, puis migrer vers Qdrant, pgvector ou Pinecone quand le volume, la disponibilité ou l'intégration l'exigent. On ne sur-dimensionne pas par principe : on choisit selon le besoin réel.
Conclusion
Le RAG répond à un besoin de connaissances fraîches et traçables ; le fine-tuning, à un besoin de comportement — et les deux se combinent. Avant de déployer un RAG, on vérifie qu'il est nécessaire : pour un petit corpus stable, long-contexte et prompt caching peuvent suffire ; pour un gros corpus changeant ou des sources à citer, le RAG s'impose. Et le choix de la base vectorielle se fait sur le volume, l'hébergement, l'intégration et l'ouverture, pas sur une préférence. Concevoir, évaluer, améliorer et décider : c'est la vue complète d'un RAG maîtrisé.
