Fine-tuning vs RAG : quand utiliser quoi

Définitions

RAG (Retrieval-Augmented Generation) — Le modèle de base reste inchangé. On lui injecte dynamiquement des informations pertinentes dans le contexte à chaque requête.

Fine-tuning — On réentraîne le modèle sur un dataset spécifique pour modifier son comportement, son style ou ses connaissances de façon permanente.

Analogie : Le RAG c'est donner des notes à un expert avant un examen. Le fine-tuning c'est former un nouvel expert dès le départ.

Quand choisir RAG

Tes données changent fréquemment (base de connaissance, docs produit, FAQ)
Tu as besoin de citabilité des sources (le modèle doit référencer d'où vient l'info)
Tu veux démarrer rapidement — RAG peut être opérationnel en quelques heures
Tes données sont confidentielles et ne doivent pas être envoyées pour entraînement
Le budget est limité — pas besoin de GPU pour l'inférence RAG
Tu veux pouvoir mettre à jour les données sans réentraîner

// Cas d'usage RAG typiques :
// - Chatbot support client basé sur une FAQ
// - Assistant qui répond sur la documentation interne
// - Recherche dans des contrats, emails, rapports
// - Système Q&A sur une base de connaissances qui évolue

Quand choisir le fine-tuning

Tu veux un style de réponse très spécifique (ton, format, vocabulaire métier)
Le modèle doit apprendre des comportements impossibles à décrire par prompt
Tu as des milliers d'exemples entrée/sortie de haute qualité
La latence est critique — un modèle fine-tuné plus petit peut être plus rapide
Tu veux réduire la taille du contexte (pas besoin d'injecter des docs)
Tu dois respecter une structure de sortie très précise et répétable

// Cas d'usage fine-tuning typiques :
// - Classifier des emails dans des catégories métier spécifiques
// - Générer du code dans le style de ton équipe (conventions internes)
// - Extraire des entités dans un format JSON strict
// - Répondre dans le ton et vocabulaire de ta marque

Comparatif détaillé

Critère	RAG	Fine-tuning
Temps de mise en place	Quelques heures	Quelques jours/semaines
Données requises	Documents bruts	Paires input/output annotées
Mise à jour des données	Immédiate	Réentraînement complet
Coût initial	Faible	Élevé (GPU, temps)
Coût par requête	Plus élevé (contexte long)	Plus faible (modèle plus petit)
Traçabilité des sources	Oui (sources citables)	Non
Risque d'hallucination	Faible (ancré dans les docs)	Possible (mémoire du modèle)
Personnalisation du style	Limitée (via prompt)	Excellente

Coûts et ressources

// Fine-tuning GPT-4o-mini (OpenAI)
// - ~$25 / million tokens d'entraînement
// - Dataset recommandé : 50-1000 exemples minimum
// - Durée : 30 min à plusieurs heures selon la taille

// Fine-tuning open source (Llama, Mistral)
// - GPU requis : A100 80GB ou 2x RTX 3090 minimum
// - QLoRA réduit la RAM nécessaire de 70%
// - Outils : Unsloth, LLaMA Factory, Axolotl

// RAG
// - Embeddings : $0.02/1M tokens (text-embedding-3-small)
// - Vector store : Chroma (gratuit local), Pinecone (~$70/mois)
// - Inférence : coût normal de l'API + tokens de contexte supplémentaires

Recommandations pratiques

Règle des 80% : Dans 80% des cas, RAG + bon prompt engineering suffit. Le fine-tuning n'est justifié que quand RAG atteint ses limites.

Commence toujours par RAG — plus rapide et moins risqué
Si les résultats ne sont pas assez bons avec RAG, améliore d'abord le retrieval avant de passer au fine-tuning
Le fine-tuning ne connaît pas tes données récentes — combiner les deux est souvent la meilleure solution
Utilise le fine-tuning pour le style/format, RAG pour les connaissances

Stratégie hybride : Fine-tuner le modèle pour qu'il adopte ton style et ton format de sortie, puis utiliser RAG pour lui injecter les connaissances métier actualisées.