On voit trop d'équipes choisir le fine-tuning par défaut « parce que c'est plus sérieux ». Spoiler : dans 80 % des cas, le RAG est la meilleure réponse — moins cher, plus rapide, plus maintenable.
La vraie différence
Le RAG (Retrieval-Augmented Generation) injecte du contexte récupéré à la volée dans le prompt. Le fine-tuning modifie les poids du modèle pour qu'il « connaisse » de nouvelles informations.
La différence cruciale : avec le RAG, mettre à jour la base de connaissances prend 30 secondes. Avec le fine-tuning, ça prend des heures de calcul GPU et une nouvelle évaluation complète.
Quand choisir le RAG
Choisissez le RAG si :
- Votre base de connaissances change régulièrement (docs produit, FAQ, articles, etc.)
- Vous voulez des citations vérifiables dans les réponses
- Vous gérez plusieurs domaines ou clients (chaque client a son propre index)
- Vous avez moins de 100 GB de données textuelles à indexer
- Vous voulez un MVP en moins de 2 semaines
Quand choisir le fine-tuning
Choisissez le fine-tuning si :
- Vous voulez changer le style de sortie du modèle (ton, format, langue spécifique)
- Vous avez des milliers d'exemples de paires (entrée, sortie attendue)
- Votre base de connaissances est figée et hyper-spécialisée (génétique, droit fiscal niche)
- La latence est critique : un fine-tune plus petit peut tourner plus vite qu'un RAG + gros modèle
Les approches hybrides
En production, on utilise souvent les deux. Un petit modèle fine-tuné sur le style + RAG pour les faits à jour donne souvent les meilleurs résultats à coût maîtrisé.
Exemple chez un client : Claude Haiku fine-tuné sur leur tonalité de marque (2 000 exemples), avec RAG sur les 8 000 articles de documentation produit. Latence < 800 ms, coût divisé par 4 vs. Claude Sonnet en zero-shot.
Par défaut, commencez par le RAG. C'est plus simple à débugger, plus rapide à itérer, et le coût d'inférence est souvent comparable. Passez au fine-tuning uniquement quand vous avez prouvé que le RAG seul ne suffit pas.