RAG en production : 18 mois de leçons de terrain

En février 2025, nous passions en revue sept leçons solides de mise en production de RAG : chunking sémantique, reranker, citations, évaluation, gouvernance. Douze mois plus tard, le terrain a encore bougé. Trois changements dominent, et aucun n'était mature il y a un an.

Premier mouvement : le RAG multimodal est devenu viable. Les corpus clients ne sont plus seulement texte — ils contiennent des tableaux financiers, des schémas techniques, des graphes de reporting, des captures d'outils internes. Les modèles de vision (Claude Sonnet 4.5, GPT-4o, Gemini 2.0 Flash) lisent ces éléments directement, sans OCR préalable dégradant. Sur un projet de conformité bancaire, 38 % des documents utiles étaient des tableaux ou des graphiques — sans capacités multimodales, plus d'un tiers du corpus était invisible.

Deuxième mouvement : les sorties structurées ont atteint la maturité production. Les JSON schema stricts d'OpenAI (`response_format: json_schema`) et le tool use d'Anthropic garantissent désormais une sortie conforme à un schéma, caractère par caractère. Nous n'écrivons plus de regex de post-traitement pour extraire `answer` et `citations` : c'est natif, c'est garanti par contrat, et ça tombe en panne proprement si le modèle échoue.

Troisième mouvement : le RAG agentique a remplacé le single-hop naïf. Plutôt qu'une seule retrieval suivie d'une génération, le modèle itère : il récupère, lit, décide s'il a assez, sinon reformule et récupère à nouveau (multi-hop). Sur des questions à plusieurs sauts — « comparer la politique RH 2023 et 2024 sur le télétravail » — le pattern agentique dépasse un RAG classique de 20 à 30 points de faithfulness.

En 2025, nous disions : « construisez un dataset de 200 à 500 questions ». C'est toujours vrai. Ce qui a changé, c'est la capacité à noter automatiquement chaque réponse. Le LLM-as-judge — utiliser un modèle pour évaluer la sortie d'un autre modèle sur des critères définis — est passé du papier de recherche au pipeline CI.

Trois frameworks dominent fin 2025. Ragas v0.2 expose des métriques solides : faithfulness (la réponse est-elle sourcée dans les contextes récupérés ?), answer relevancy, context recall/precision. DeepEval propose une intégration Pytest-native pratique pour les équipes Python. Promptfoo est notre choix pour les tests de non-régression cross-model : on y branche le même dataset sur GPT-4o, Claude Sonnet 4.5 et Llama 3.3 70B, et on compare les deltas en un tableau.

Le coût réel de l'évaluation continue nous surprend toujours. Sur un projet juridique (480 questions de référence, notées par Claude Sonnet 4.5 comme juge), chaque passe d'évaluation complète coûte 11 à 14 euros. Lancée sur chaque PR qui touche au prompt, au chunking ou au modèle, c'est 30 à 80 euros par semaine — négligeable. Le vrai coût caché, c'est la maintenance du gold standard : 5 à 8 % des questions doivent être réannotées chaque trimestre parce que le contexte métier évolue.

Le piège classique du LLM-as-judge : le biais de longueur (un juge note mieux les réponses longues) et le biais de position (mieux note-t-il la première réponse présentée). On l'atténue en randomisant l'ordre, en contraignant les longueurs, et en croisant systématiquement le score du juge avec un recall@5 mesuré sur retrieval. Si les deux métriques divergent, on enquête. Un juge seul ne suffit jamais.

Le prompt caching — qu'Anthropic a lancé sur Claude en août 2024 et OpenAI sur GPT-4o en octobre 2024 — est la baisse de coût la plus significative que nous ayons vue en deux ans. Concrètement : tout préfixe de prompt identique entre deux requêtes est mis en cache côté fournisseur, et facturé 10 à 50 % du tarif d'input normal pendant 5 minutes (Anthropic) à 1 heure (OpenAI).

Sur un RAG, le système prompt, la documentation de tools et la liste de citations forment un préfixe stable de 2 000 à 6 000 tokens. Avec un cache hit consistent, le coût d'input chute de 50 à 90 %. Sur un projet de support interne (12 000 requêtes/mois, prompt système de 4 800 tokens), le passage au caching a réduit la facture Claude de 1 180 euros à 320 euros mensuels — sans aucun changement côté utilisateur.

Le cache sémantique reste pertinent pour une autre couche. Sur des questions proches (cosinus > 0,95 sur l'embedding de la requête), on sert la réponse précédente sans rappeler le modèle. Nos taux de hit typiques : 35 à 45 % sur des chatbots internes (où les collaborateurs posent souvent les mêmes questions), 12 à 18 % sur des assistants clients (où la diversité est plus forte). Outils testés : Redis avec `redisvl`, GPTCache auto-hébergé, ou Redis Vector Search managé.

Le troisième levier, c'est la délégation aux petits modèles. Claude Haiku 4, GPT-4o-mini et Llama 3.3 70B auto-hébergé prennent en charge 70 à 85 % du trafic sur nos projets : classification de requête, résumé court, reformulation, extraction d'entités. Le modèle large (Sonnet 4.5, GPT-4o) n'intervient que pour la génération finale longue et le raisonnement multi-hop. Coût moyen par requête RAG complète en 2026 : 0,018 euro, contre 0,07 euro à configuration équivalente en février 2025.

Pendant deux ans, le discours dominant annonçait la mort de BM25 au profit des embeddings seuls. La pratique de 2025 l'a enterré. Sur corpus technique, juridique ou médical — partout où des identifiants, des numéros de référence, des acronymes précis comptent — un BM25 seul bat souvent un dense seul, et la fusion des deux bat chacun pris isolément.

Le trio de référence en 2026 : BM25 + embeddings denses + reranker cross-encoder. Les embeddings capturent la similarité sémantique (« comment suspendre un compte » ≈ « procédure de blocage utilisateur ») ; BM25 capture la correspondance lexicale exacte (« article L.1235-7 » doit remonter même si l'utilisateur tape ce sigle) ; le reranker réordonne les 50 meilleurs candidats avec un modèle attentionnel plus coûteux mais plus précis.

Pour la fusion sparse-dense, deux pistes sérieuses ont émergé. SPLADE produit des embeddings sparse appris, qui se combinent nativement avec un vecteur dense dans un même index. ColBERT2 garde, pour chaque token, un vecteur distinct et fait un late interaction à la requête — précis mais gourmand en stockage (10 à 30 fois plus volumineux qu'un embedding dense unique). Nous utilisons ColBERT2 sur des corpus petits et critiques (< 50 000 documents, juridique), et BM25+dense+reranker ailleurs.

Pour le rerank, en 2026 nous oscillons entre Cohere Rerank 3 (managé, 2 euros pour 1 000 recherches) et BGE-Reranker-v2 auto-hébergé (GPU partagé, coût marginal nul après amortissement). Sur le projet juridique déjà cité, le rappel@5 passe de 71 % (dense seul) à 89 % (dense + rerank) — chiffre stable par rapport à 2025, ce qui confirme que le gain structurel d'un reranker reste massif quel que soit l'état de l'art des embeddings.

Trois incidents récents méritent un récit public, parce qu'ils sont reproductibles chez n'importe quelle équipe. Premier cas : un changement de chunking silencieux. Nous étions passés d'un découpage par paragraphe à un découpage par chevauchement fixe de 512 tokens pour « simplifier ». Aucune alerte n'a sonné, mais sur deux semaines, le taux de réponse « je ne sais pas » a grimpé de 4 % à 11 %. Cause : les chunks coupaient au milieu de paragraphes contenant les définitions critiques. Diagnostic par dérive du recall@5 sur le dataset d'évaluation. Réparation en moins de 24 heures, mais deux semaines de dégradation utilisateur.

Deuxième cas : une montée de version de modèle qui a introduit des hallucinations subtiles. Migration de Claude Sonnet 3.5 vers Sonnet 4 — gains globaux de qualité spectaculaires, mais sur 8 % des questions techniques pointues, le modèle se mettait à inventer des numéros de référence réglementaires au lieu d'admettre l'absence. Le LLM-as-judge en CI les a attrapées avant la mise en production. Sans évaluation continue, ce sont les utilisateurs qui auraient signalé l'erreur — bien trop tard.

Troisième cas : une panne de reranker qui a dégradé la qualité sans déclencher d'alerte. Cohere Rerank 3 tombait en 503 par à-coups, notre code fallback servait les résultats bruts du dense sans avertir personne. La latence p95 était correcte, le taux de réponse correct, mais le recall@5 silencieusement en chute de 89 % à 71 %. Nous avons ajouté une sonde spécifique : taux de succès reranker sur 5 minutes, alerte si < 95 %. Depuis, aucun reranker ne tombe sans qu'on le sache.

Leçon commune : un RAG dégrade souvent sans panne franche. Les métriques à surveiller ne sont pas seulement la latence ou le taux d'erreur HTTP — il faut monitorer le recall@5 en continu (via un échantillon de requêtes annotées), le taux d'abstention (« je ne sais pas »), la distribution des scores de citation, et toute dérive > 5 % sur 24 heures.

Si nous démarrions un nouveau projet RAG entreprise en janvier 2026, voici la stack que nous posons. Vector store : Qdrant pour la performance et les filtres metadata riches, ou pgvector quand le client veut rester sur une base Postgres unique et accepte une légère pénalité de latence. Les deux sont solides ; le choix dépend de l'existant infrastructure.

Embeddings : BGE-M3 (multilingue, sparse+dense+dense ColBERT natif, auto-hébergé sur une carte unique GPU) est devenu notre défaut francophone. Pour les corpus strictement anglais, OpenAI text-embedding-3-large reste excellent. On évite les embeddings propriétaires non reproducibles — la réindexation d'un corpus de 500 000 documents coûte cher en temps, pas en argent.

Rerank : Cohere Rerank 3 en managé pour démarrer vite, BGE-Reranker-v2 auto-hébergé quand le volume justifie un GPU dédié. Modèle de génération : Claude Sonnet 4.5 pour les cas exigeants en raisonnement et sur les corpus techniques longs ; GPT-4o pour la vitesse et la couverture multimodale ; Gemini 2.0 Flash quand le débit et le coût dominent. Haiku 4 ou GPT-4o-mini pour les tâches de routing et de classification.

Observabilité et évaluation : Langfuse pour le tracing de chaque requête (prompt, contexte récupéré, réponse, latence, coût), Promptfoo dans la CI pour les non-régressions, PromptLayer pour le versioning des prompts et l'A/B runtime. Le triptyque coûte 0 euros en licence (tous open-source auto-hébergeables) et couvre 90 % des besoins. Sur un projet récent, cette stack a tenu 14 millions de requêtes mensuelles sur une infrastructure de 4 800 euros par mois — un ordre de grandeur sous ce que nous mentions en 2025.

Trois signaux faibles pourraient devenir dominants en 2026. Premier signal : les contextes longs (1 à 2 millions de tokens chez Gemini, 400k chez Claude, 200k chez GPT-4o) remettent en question le chunking lui-même — pourquoi découper si tout le corpus tient dans le contexte ? Sur des corpus petits et stables (< 200 000 tokens pertinents), le « long-context RAG » (pas de chunking, retrieval minimal, modèle large) devient compétitif. Mais le coût et la latence restent prohibitifs au-delà.

Deuxième signal : les outils d'agents — MCP (Model Context Protocol) d'Anthropic, function calling standardisé — rendent le RAG agentique banal. Le pattern « récupère, vérifie, ré-utilise un outil si besoin » n'est plus un projet de R&D, c'est une primitive documentée. Sur le premier trimestre 2026, nous déployons deux RAG agents en production client avec ce pattern.

Troisième signal : la régulation durcit le cadre. L'AI Act entre en application progressivement, les exigences de traçabilité des systèmes GPAI s'étoffent, et les audits clients demandent désormais des preuves d'évaluation continue. Une infrastructure d'évaluation et de logging propre — Langfuse, Promptfoo, traces horodatées — n'est plus un luxe d'ingénieur, c'est un actif réglementaire. Anticipez-le dès la conception.