Vous avez construit un chatbot le mois dernier. Il a dit avec assurance à votre client que vous livriez en Mongolie. Ce n’est pas le cas. Le LLM ne savait pas ce qu’il ne savait pas, alors il a deviné.
C’est le problème du RAG — et la solution n’est pas un meilleur prompting.
La Génération Augmentée par Récupération (RAG) résout un mode de défaillance spécifique : lorsqu’un LLM n’a pas le contexte nécessaire pour répondre correctement, il hallucine. RAG insère vos données réelles dans la conversation avant que le LLM ne génère une réponse. Pas de données, pas d’hallucination. Simple en théorie. L’exécution est là où la plupart des implémentations échouent.
Ce guide présente le RAG en production — pourquoi il fonctionne, où les équipes se bloquent, comment construire l’architecture et les décisions de configuration spécifiques qui font ou défont la performance.
Pourquoi le RAG surpasse le Fine-Tuning (et quand il ne le fait pas)
Avant de décider du RAG, vous devez savoir ce que vous résolvez réellement. Il existe une différence fondamentale entre enseigner à un LLM et lui donner des données à référencer.
⚡ Key Takeaways
- Le RAG récupère le contexte pertinent au moment de l’inférence, évitant les réentraînements coûteux ; commencez par le RAG sauf si vos données sont suffisamment stables et volumineuses pour justifier le fine-tuning
- Le pipeline en quatre étapes (ingestion → embedding → récupération → génération) est non négociable ; sauter une étape et le système casse
- Le choix du modèle d’embedding détermine ce que signifie « pertinent » ; text-embedding-3-small d’OpenAI est le choix par défaut sûr, mais les modèles spécifiques au domaine surpassent sur les données spécialisées
- La récupération par similarité vectorielle de base manque environ 15 % des résultats pertinents ; la recherche hybride (sémantique + mots-clés) plus le réordonnancement les récupèrent
- La taille des morceaux dépend du contexte ; testez les plages de 256 à 1024 tokens sur des requêtes réelles avant le lancement en production
- Surveillez le taux de réussite (≥85 % au top 5) et le MRR (≥0,7) hebdomadairement ; la dérive des performances indique une dégradation des données ou de l’embedding, pas du comportement utilisateur
Le fine-tuning met à jour les poids du modèle. Vous donnez au modèle des milliers d’exemples de vos données et des sorties attendues, et il apprend des motifs. La connaissance fait partie intégrante du modèle. Cela coûte de l’argent (des centaines à des milliers par exécution d’entraînement), prend du temps (heures à jours) et modifie définitivement le comportement du modèle. Vous ne pouvez pas facilement le mettre à jour avec de nouvelles informations sans réentraîner.
Le RAG récupère le contexte pertinent au moment de l’inférence. Vous stockez vos données dans une base de données séparée, et lorsqu’un utilisateur pose une question, vous récupérez les morceaux pertinents et les incluez dans le prompt. Le modèle voit vos données actuelles à chaque requête. Vous pouvez mettre à jour les données sans réentraîner quoi que ce soit.
Voici le choix pratique :
- Utilisez le RAG quand : vos données changent régulièrement (documentation produit, prix, inventaire, profils clients), vous avez besoin d’informations à jour, vous souhaitez mettre à jour sans redéploiement, ou vous n’êtes pas sûr de ce que le LLM doit apprendre.
- Utilisez le fine-tuning quand : vos données sont stables et volumineuses, le motif est subtil (style d’écriture, ton, raisonnement spécialisé), et la vitesse d’inférence est plus importante que la fraîcheur des données.
- Utilisez les deux quand : vous avez des connaissances de domaine stables (fine-tuning) plus des données dynamiques (RAG). C’est courant dans les domaines spécialisés — fine-tuning sur la terminologie médicale, utilisation du RAG pour les historiques de patients.
La plupart des équipes devraient commencer par le RAG. C’est moins cher à construire, plus facile à itérer, et ne nécessite pas la profondeur en science des données que le fine-tuning exige. L’écart de performance entre un RAG bien réglé et le fine-tuning est plus étroit qu’il y a deux ans — surtout avec Claude Sonnet 4 et GPT-4o, qui ont de plus grandes fenêtres de contexte.
Le Pipeline RAG : Quatre Étapes Non Négociables
Un système RAG en production comporte quatre étapes. En sauter une et tout casse.
1. Ingestion. Vous chargez vos données (PDF, pages web, bases de données, documents structurés) et les convertissez en morceaux suffisamment petits pour l’embedding. Un morceau fait généralement 300 à 800 tokens — un paragraphe, pas un chapitre de livre. L’objectif est la granularité : chaque morceau doit répondre à une seule question sans nécessiter le contexte de cinq autres morceaux.
2. Embedding. Chaque morceau est converti en vecteur — une liste de nombres représentant sa signification sémantique. Vous utilisez un modèle d’embedding (comme text-embedding-3-small d’OpenAI ou embed-english-v3.0 de Cohere) pour créer ces vecteurs. Les vecteurs résident dans une base de données vectorielle (Pinecone, Weaviate, Milvus, ou même PostgreSQL avec l’extension pgvector). Le modèle d’embedding est séparé de votre LLM.
3. Récupération. Lorsqu’un utilisateur pose une question, vous embarquez la question en utilisant le même modèle d’embedding, puis recherchez dans la base de données vectorielle les morceaux les plus similaires. La similarité est mesurée par la distance cosinus — à quel point les vecteurs sont « proches » les uns des autres. Vous récupérez généralement les 3 à 10 meilleurs morceaux, en fonction de la quantité de contexte que votre LLM peut gérer.
4. Génération. Vous construisez un prompt qui inclut les morceaux récupérés, puis vous l’envoyez à votre LLM. Le LLM génère une réponse basée à la fois sur la question et le contexte. Si le contexte est bon, la réponse est précise. Si le contexte est mauvais, le LLM hallucine toujours — juste avec une plus grande confiance, car il a quelque chose sur quoi travailler.
Voici un flux concret :
# Étape 1 : Ingestion (unique, hors ligne)
documents_bruts = charger_pdf(
