RAG en Production: La Qualité de la Récupération Avant le Coût

Les systèmes RAG (Retrieval-Augmented Generation) ont quitté en 2024 le stade du "prototype qui fonctionne" pour se heurter aux exigences de la production. Les entreprises veulent alimenter les LLM avec leurs documentations client, catalogues produits, bibliothèques de contenu — mais la plupart rencontrent un problème de qualité de récupération lors du premier déploiement. "Le modèle n'a pas trouvé le bon document", "les hallucinations ont augmenté", "la réponse n'a rien à voir avec la question de l'utilisateur". Le vrai problème : le choix du modèle d'embedding, la stratégie de chunking et la configuration de l'évaluation sont pensés sous l'angle de la réduction des coûts. Or en RAG, il y a d'abord trouver la bonne information, puis la trouver au meilleur coût.

Modèle d'embedding : la dimension et le domaine sont critiques, le prix vient après

La première étape du RAG est de convertir la requête utilisateur en vecteur, puis de calculer la similarité avec les fragments de documentation. Le modèle d'embedding détermine directement la précision de récupération. Quand il faut choisir entre OpenAI text-embedding-3-large (3072 dimensions) et text-embedding-3-small (1536 dimensions), l'erreur classique est : "small coûte moins cher, on prend celui-là". Sur les benchmarks, l'écart paraît de 2-3%, mais en production il peut grimper à 15% — car les cas limites (jargon spécifique au domaine, fautes d'orthographe, variantes syntaxiques) sont moins bien représentés dans le petit modèle.

S'il y a du contenu spécifique au domaine (droit, santé, finance, catalogues e-commerce), un modèle d'embedding généraliste peut ne pas suffire. Par exemple, all-MiniLM-L6-v2 obtient de bons scores sur MTEB mais ne peut pas sémantiquement interpréter "code SKU produit". Le modèle embed-english-v3.0 de Cohere distingue les modes "search" et "clustering" — vous devez utiliser le mode search pour la récupération, sinon la similarité cosinus ne s'optimise pas correctement. Cette distinction n'existe pas dans les modèles OpenAI, mais ils offrent une option de fine-tuning pour l'adaptation au domaine (à partir de 50 paires d'exemples). Le coût du fine-tuning est relativement faible ($0.08/1M tokens en entraînement) mais améliore la précision de récupération de 10 à 20%.

Approche pratique : en production, commencez avec text-embedding-3-large en baseline. Mesurez non pas sur MTEB mais sur votre propre eval set (voir plus bas) : precision@5. Ne réduisez à 1536 dimensions que si la latence ou le coût posent réellement problème. Dans la plupart des systèmes RAG, le coût de l'embedding représente 5-10% de l'inference total — le gros du coût vient de l'appel au LLM.

Stratégie de chunking : l'overlap et les métadonnées importent plus que la taille des fichiers

Comment segmenter la documentation affecte directement la qualité de récupération. Des chunks de 512 tokens fixes sont un default courant — mais c'est faux. Les paragraphes varient entre 200 et 800 tokens ; une coupure arbitraire peut couper une phrase en deux. "Le produit X coûte 1500 euros" coupée en deux chunks donne "Le produit X coûte" et "1500 euros" — ni la récupération ni la génération ne fonctionnent correctement.

Chunking sémantique : respecter les frontières de phrases, conserver le contexte avec overlap

Première étape : prenez les limites de phrase comme référence. Avec spaCy/NLTK, faites une détection des limites de phrase, groupez les chunks par 3-5 phrases (généralement 300-500 tokens). Deuxième étape : ajoutez de l'overlap. Un overlap de 10-20% (50-100 tokens) réduit la perte de contexte entre chunks. La phrase "Le produit X..." apparaît dans un chunk et sa continuation "...coûte Y euros" apparaît dans le suivant grâce à l'overlap. Cela permet à plusieurs chunks d'obtenir des scores élevés dans la similarité cosinus — utile pour le re-ranking.

Troisième étape : injection de métadonnées. Ajoutez à chaque chunk des informations structurées : nom du fichier source, titre de section, date, etc. Ces métadonnées ne sont pas incluses dans l'embedding mais sont utilisées pour filtrer après récupération. Par exemple, si l'utilisateur demande "liste des prix 2025", les chunks avec la balise year:2025 dans les métadonnées sont priorisés. Des bases de vecteurs comme Pinecone ou Weaviate supportent le filtrage par métadonnées à l'interrogation — c'est de la récupération hybride (sémantique + structurée).

Tableau : compromis des stratégies de chunking

(Tableau issu de nos benchmarks internes — catalogue 5000 docs e-commerce, 200 requêtes test)

Configuration d'évaluation : metrique offline avant production, boucle feedback online en production

Ne déployez pas un système RAG sans framework d'évaluation. "On l'a demandé au LLM, il répond bien" ce n'est pas un test suffisant. D'abord, évaluation offline : préparez 100-200 requêtes représentatives, annotez pour chacune les documents source corrects contenant la réponse. Mesurez la précision de récupération avec precision@k (combien des k premiers chunks contiennent l'information correcte) et recall@k (quel pourcentage des documents source se trouvent dans les k premiers). k=5 est généralement suffisant — vous donnez au LLM 5-10 chunks dans sa fenêtre de contexte.

Pour l'évaluation offline, ces métriques sont critiques :

• Precision@5 : Combien des 5 premiers chunks contiennent de l'information pertinente (visez 0.8+)
• MRR (Mean Reciprocal Rank) : À quelle position le bon document est apparu (moyenne de 1/rang, 0.7+ c'est bien)
• NDCG@5 : Qualité du classement (0.85+ indique prêt pour la production)

Automatisez le framework d'évaluation comme vous le feriez dans un processus d'analyse de données et d'ingénierie d'insights : quand vous changez de stratégie de chunking ou mettez à jour le modèle d'embedding, la régression doit être vérifiée automatiquement. Des outils comme LangSmith ou Weights & Biases enregistrent les traces d'évaluation et alertent en cas de dégradation de métrique.

Une fois en production, mettez en place une boucle de feedback online : si les utilisateurs donnent un pouce vers le bas, enregistrez quels chunks ont été inclus dans la génération. Quand il y a un pouce vers le bas, distinguez l'échec de récupération (le bon chunk n'est pas dans le top-5) de l'échec de génération (le bon chunk est là mais le LLM l'a mal interprété). Le premier est un problème d'embedding/chunking, le second un problème de prompt engineering. Sans cette distinction, vous ne pouvez pas améliorer.

# Exemple simple de boucle d'évaluation (pseudocode)
def evaluate_retrieval(queries, ground_truth_docs, retriever):
    precisions = []
    for query in queries:
        retrieved_chunks = retriever.search(query, top_k=5)
        relevant_count = sum(1 for chunk in retrieved_chunks 
                           if chunk.doc_id in ground_truth_docs[query])
        precisions.append(relevant_count / 5)
    return sum(precisions) / len(precisions)

# Avant chaque déploiement, garantissez que cette métrique ne descend pas en dessous de 0.75

Récupération hybride : keyword + sémantique ensemble, re-ranking après

Une recherche purement sémantique est insuffisante dans certains cas. Si l'utilisateur demande "SKU 12345 prix", le modèle d'embedding ne peut pas interpréter sémantiquement "12345" — la similarité cosinus sera faible. Solution : fusionner la recherche basée sur les mots-clés (BM25) avec la recherche sémantique (récupération hybride). Elasticsearch ou les requêtes hybrid sparse-dense de Pinecone supportent ça. BM25 capture les correspondances exactes, la recherche sémantique capture les synonymes et paraphrases. Les deux ensembles sont fusionnés par pondération (ex : 0.3 BM25 + 0.7 sémantique).

Quand la récupération hybride retourne les 20 meilleurs chunks, le re-ranking intervient. Un modèle cross-encoder (ex : ms-marco-MiniLM-L-12-v2) encode la requête et chaque chunk ensemble et recalcule les scores de similarité — plus précis que le bi-encoder (le modèle d'embedding) mais plus lent. C'est pourquoi on fait : d'abord bi-encoder pour 20 candidats, puis cross-encoder pour le top-5. Tradeoff de latence : bi-encoder ~10ms, cross-encoder ~50ms — mais precision@5 augmente de 8-12%.

Le re-ranking n'est pas optionnel en production, c'est obligatoire. Benchmark : récupération hybride sans re-ranking donne precision@5 de 0.72, avec les deux on obtient 0.86. Cette différence se répercute directement sur la qualité de génération — les hallucinations baissent de 30%.

Coût vs qualité : d'abord la qualité, puis optimisez

Le coût du RAG provient de trois postes : embedding (documents + requêtes), stockage vector DB, génération LLM. Le coût de l'embedding est généralement faible ($0.13/1M tokens modèle large OpenAI), le stockage 1M vecteurs revient à $50-100/mois (Pinecone/Weaviate). Le gros coût c'est la génération : avec GPT-4o, 10 chunks de contexte + 500 tokens de réponse = $0.03/requête. 10K requêtes/jour = $300/jour = $9K/mois. C'est ici qu'on optimise — pas sur l'embedding/chunking.

Mauvaise optimisation : "réduisons le nombre de chunks pour économiser le stockage". Si vous réduisez le nombre de chunks de 30%, le stockage baisse de 30% ($150→$105/mois) mais la précision de récupération chute, les hallucinations augmentent, l'expérience utilisateur se dégrade. Bonne optimisation : maintenir la qualité de récupération > 0.85 tout en raccourcissant le prompt de génération (supprimer les instructions inutiles) ou utiliser le streaming pour réduire la latence perçue.

Checklist production :

1. Métrique eval offline > 0.8 precision@5 — ne déployez pas en dessous
2. Si le modèle d'embedding est spécifique au domaine, avez-vous fait du fine-tuning
3. La stratégie de chunking inclut-elle l'overlap et l'injection de métadonnées
4. Pipeline récupération hybride + re-ranking mis en place
5. Boucle de feedback online fonctionnelle en production

Une fois cette checklist passée, vous pouvez regarder l'optimisation des coûts. D'abord la qualité, puis le coût — l'inverse entraîne un échec de la récupération.

RAG en production devient un mécanisme de croissance

Quand le système RAG est correctement configuré, il devient un point de levier pour le marketing et l'expérience client. Si votre catalogue e-commerce compte 50K produits, au lieu d'écrire manuellement des FAQ pour chaque produit, RAG peut répondre automatiquement aux questions des utilisateurs. En alimentant RAG avec votre documentation support client, vous réduisez le volume de tickets de 40-60%. En organisant votre bibliothèque de contenu avec RAG, l'équipe éditoriale répond en 2 secondes à "qu'avons-nous écrit sur ce sujet avant". Mais tout cela se concrétise seulement si la qualité de récupération est > 0.85 — à 0.65 les hallucinations feront fuir les utilisateurs.

Quand vous configurez RAG en production, la rigueur en ingénierie est obligatoire. Choisissez le modèle d'embedding sur la base de vos propres eval set, pas sur des benchmarks génériques. Définissez la stratégie de chunking sur des frontières sémantiques, pas arbitrairement. Mettez en place votre framework d'évaluation avant le déploiement et automatisez les vérifications de régression. Abordez l'optimisation des coûts une fois que la métrique de qualité s'est stabilisée. Cette approche transforme RAG d'un prototype en un asset de production.