RAG en production : ce qui marche vraiment
Retour terrain sur le RAG en production : retrieval hybride, jeux d'évaluation, erreurs à éviter et ordre des optimisations avant de toucher au modèle.
Publié le 28/07/2026 · Mis à jour le 28/07/2026
Nous avons intégré du RAG dans nos produits et chez nos clients. Voici ce qui a survécu au contact de la production - et ce que nous avons arrêté de faire. Ce n’est pas un tutoriel générique : ce sont les patterns qui tiennent quand le corpus bouge, que les tenants se multiplient et que les utilisateurs posent des questions hors périmètre.
Si vous construisez un agent métier plutôt qu’un simple Q&A, croisez avec agents IA : quand l’automatisation vaut le coût. Pour le multi-tenant qui isole les corpus, voir Multi-tenant NestJS.
Le retrieval d’abord, le modèle ensuite
La plupart des réponses médiocres ne viennent pas du LLM mais de ce qu’on lui donne. Avant de changer de modèle, travaillez la recherche :
- découpage aligné sur la structure réelle (sections, titres, pas des blocs arbitraires) ;
- filtres métier en amont (tenant, locale, type de document, date) ;
- recherche hybride : vecteurs + mots-clés (BM25 ou équivalent).
const hits = await search.hybrid(query, {
vector: 0.65, // similarité sémantique
bm25: 0.35, // mots-clés exacts
filters: { tenant, locale: 'fr' },
topK: 8,
});Sur Cabineto, le passage du tout-vectoriel à l’hybride a nettement réduit les réponses hors sujet, sans toucher au modèle ni au prompt. C’est le même ordre de priorités que sur nos services IA.
Évaluer avant d’optimiser
Sans jeu d’évaluation, chaque réglage est un pari. Le nôtre est simple :
- une centaine de questions réelles d’utilisateurs ;
- les passages attendus (ou une liste de documents sources) ;
- un score de couverture recalculé à chaque changement de pipeline.
C’est ce qui permet de dire « cette modification améliore » au lieu de « ça a l’air mieux ». Même logique que pour un audit technique : d’abord des signaux mesurables.
Ce qu’on a arrêté de faire
| Pratique | Pourquoi on a stoppé |
|---|---|
| Fine-tuning prématuré | 90 % des cas se règlent avec retrieval + prompt |
| Chunks géants | Au-delà de quelques centaines de tokens, le signal se noie |
| Re-ranking systématique | Utile seulement une fois le reste au propre |
| Démos sur 10 documents | Tester le corpus complet dès la première semaine |
Un RAG fiable n’a rien de magique : c’est de la recherche d’information bien faite, mesurée, puis seulement augmentée d’un modèle. Dans cet ordre.
Mise en prod : checklist courte
- Filtres tenant / ACL appliqués avant le ranking.
- Logs des passages retenus (pour debug et eval).
- Timeouts et fallbacks si le vector store est lent.
- Versioning du chunking (sinon l’eval devient incomparable).
Pour une infra minimale de livraison, voir de l’idée à la prod en six semaines.
FAQ
Qu’est-ce qu’un RAG en production
Un RAG (Retrieval-Augmented Generation) en production est un pipeline où la recherche documentaire, les filtres métier et l’évaluation sont stables, pas une démo sur un petit corpus.
Faut-il fine-tuner avant d’améliorer le retrieval
Non. Dans la majorité de nos projets, retrieval hybride et prompt corrigent plus vite et moins cher qu’un fine-tuning prématuré.
Pourquoi la recherche hybride
Les vecteurs captent le sens ; BM25 (ou équivalent) capture les identifiants exacts, codes, noms propres. Les deux se complètent.
Comment mesurer la qualité
Avec un jeu de questions réelles, des passages attendus et un score de couverture recalculé à chaque changement de pipeline.
Besoin d’intégrer un RAG ou des agents dans votre produit ? Écrivez-nous. Suite utile : agents IA, multi-tenant NestJS, services IA.
