La question revient à chaque cadrage : « faut-il un RAG ou un modèle fine-tuné ? ». Trop souvent, elle est tranchée par préférence d’équipe ou par ce qui a marché ailleurs. Voici la grille de décision que nous utilisons — six critères, une règle d’arbitrage.
Les deux approches, rappel opérationnel
RAG (retrieval-augmented generation) — le modèle reste générique, une base vectorielle est interrogée à l’exécution pour injecter le contexte pertinent dans le prompt. La connaissance vit dans la base, pas dans les poids.
Fine-tuning — les poids du modèle sont ajustés sur un corpus spécialisé, par exemples ou par instructions. La connaissance vit dans les poids, pas dans une base.
Ce sont des outils complémentaires, pas concurrents. La vraie question est : lequel choisir d’abord ?
Six critères de décision
1. Fraîcheur de la connaissance
Si les données évoluent — catalogue produit, réglementation, documentation technique — RAG gagne. On met à jour la base, le modèle répond à la nouvelle vérité immédiatement. Un modèle fine-tuné, lui, porte les données de son entraînement et périme avec elles.
2. Auditabilité
Pouvez-vous expliquer pourquoi une réponse a été produite ? Avec RAG : on cite les documents sources avec leurs passages exacts. Avec fine-tuning : le modèle a « appris » mais ne peut pas sourcer. Sur des contextes régulés (banque, santé, juridique), RAG est indispensable.
3. Coût total de possession
Un fine-tuning demande une infrastructure GPU coûteuse (H100, A100) pendant plusieurs heures à plusieurs jours selon le volume et la méthode (LoRA, QLoRA, full fine-tune). À cela s’ajoutent le stockage des variantes de modèles, le versionnage et la bascule en production.
Un RAG s’industrialise avec une base vectorielle (pgvector, Qdrant, Weaviate) et un modèle fondation accessible par API ou self-hosted. RAG est moins cher à l’entrée ; fine-tuning devient rentable quand le volume de requêtes annuelles justifie l’amortissement.
4. Latence
Le fine-tuning ne rallonge pas le temps d’inférence. Un RAG ajoute une étape de retrieval — typiquement 50 à 200 ms — avant l’appel au modèle. Si la chaîne doit tenir sous 1 seconde bout-en-bout sur un modèle 70B, le budget est tendu.
Règle pratique : en dessous de 500 ms cible, étudier le fine-tuning sérieusement. Au-dessus, RAG reste viable.
5. Spécialisation du comportement
Fine-tuner modifie le style, le format, le ton — RAG pas ou peu. Si votre besoin est de répondre « comme un avocat » ou « en JSON structuré systématiquement », le fine-tuning est efficace. Pour « en s’appuyant sur notre base documentaire », c’est RAG.
6. Risque d’hallucination et de drift
Un RAG bien conçu avec grounding strict (consigne de ne jamais répondre hors des documents retrouvés) réduit drastiquement les hallucinations. Un modèle fine-tuné peut « inventer » des réponses cohérentes avec son corpus d’entraînement mais fausses.
Sur des cas d’usage critiques, RAG avec grounding + garde-fous est le schéma de référence.
Matrice de décision
| Besoin | Recommandation |
|---|---|
| Documentation interne consultable | RAG |
| Connaissance évolutive | RAG |
| Format de sortie rigide (JSON, schéma métier) | Fine-tuning léger (LoRA) |
| Ton/style très spécifique | Fine-tuning |
| Connaissance stable + volume > 1 M requêtes/an | Fine-tuning (amortissement) |
| Réponses auditables par sources | RAG |
| Latence < 500 ms stricte | Fine-tuning |
| Domaine technique très pointu (médical, juridique) | RAG + fine-tuning complémentaire |
La vraie réponse : les deux, souvent
Sur nos déploiements régulés, l’architecture cible combine fréquemment les deux :
- Modèle fondation ouvert (Llama 4, Mistral Large 3, Qwen)
- Fine-tuning LoRA léger pour fixer le format de sortie et le ton
- RAG pour injecter la connaissance métier, mise à jour chaque nuit
- Garde-fous sémantiques + validateurs de schéma en sortie
- Observabilité sur les trois : qualité de retrieval, qualité de génération, drift
Cette combinaison n’est pas la plus simple à opérer. Elle est celle qui passe les audits.
Ce qu’il ne faut pas faire
- Fine-tuner « pour voir » sans métrique d’évaluation définie à l’avance
- Stocker dans un RAG des documents qui changent plus vite que la fréquence d’indexation
- Oublier la phase d’évaluation continue — un RAG fonctionne jusqu’à ce qu’on change de modèle fondation, un fine-tune jusqu’à ce qu’on ajuste un hyperparamètre en amont
Pour aller plus loin
- Le service qui porte ces architectures en production : Solutions IA
- Gouverner les comportements de vos agents avec un DSL : PCL — Persona Control Language
- Combien coûte réellement un LLM en exploitation : Coût total de possession
- Pourquoi la souveraineté change l’équation : Cinq exigences non négociables
Vous cadrez un projet IA et hésitez entre RAG et fine-tuning ? Écrivez-nous, nous revenons sous 24 h ouvrées avec une lecture argumentée.