RAG en production : les 7 pièges que personne ne vous dit
Implémenter un système RAG en PoC, c'est facile. Le mettre en production dans un environnement bancaire ou industriel, c'est une autre histoire. Voici les 7 problèmes que j'ai rencontrés — et comment les résoudre.
Tout le monde parle de RAG (Retrieval-Augmented Generation). Les démos impressionnent. Les PoC fonctionnent en 2 jours. Et puis arrive le moment de passer en production — et là, les vraies questions émergent.
J'ai industrialisé plusieurs systèmes RAG dans des environnements contraints (Défense, Banque, Industrie). Voici ce que j'aurais aimé savoir avant.
1. La qualité de l'indexation détermine tout
Le modèle LLM ne peut pas compenser une mauvaise indexation. Si vos chunks sont trop grands, trop petits, ou mal délimités sémantiquement, vos réponses seront médiocres — peu importe le modèle utilisé.
Ce qui fonctionne :
- Chunking sémantique (par section logique, pas par taille fixe)
- Overlap de 10–15% entre chunks pour préserver le contexte
- Méta-données riches sur chaque chunk (source, date, type de document)
- Reranking post-retrieval avec un cross-encoder
2. L'embedding ne se choisit pas à la légère
text-embedding-ada-002 n'est pas toujours le meilleur choix. Pour des documents techniques en français, j'ai obtenu de meilleurs résultats avec des modèles multilingues comme intfloat/multilingual-e5-large.
Testez vos embeddings sur vos données, pas sur des benchmarks génériques.
3. La latence est votre ennemi n°1
Un système RAG complet enchaîne :
- Embedding de la requête
- Recherche vectorielle
- Reranking
- Appel LLM
En production, chacune de ces étapes peut devenir un goulot. Mise en cache agressive des embeddings de requêtes fréquentes, async pipeline, et streaming de la réponse LLM sont non-négociables.
4. La souveraineté des données impose des contraintes d'architecture
Dans les environnements réglementés, vous ne pouvez pas envoyer vos données chez OpenAI. Cela implique :
- LLM local (Llama 3, Mistral) via Ollama ou vLLM
- Vector DB on-premise (Qdrant self-hosted)
- Embeddings locaux
J'ai déployé cette stack "air-gapped" chez Sandvik. La performance est inférieure aux modèles cloud, mais le gain en conformité est non-négociable.
5. Les guardrails sont une feature, pas une option
Sans guardrails, votre RAG :
- Hallucine quand le contexte est insuffisant (au lieu d'avouer son ignorance)
- Peut être manipulé par prompt injection dans les documents indexés
- Divulgue des informations d'autres utilisateurs si vous ne segmentez pas correctement le corpus par tenant
Implémentez :
- Confidence scoring sur la pertinence des chunks récupérés
- Filtre de sécurité sur les queries entrantes
- Isolation des corpus par utilisateur/organisation
6. L'évaluation continue est indispensable
Un RAG qui fonctionne aujourd'hui peut dégrader demain si :
- De nouveaux documents modifient la distribution du corpus
- Le modèle d'embedding est mis à jour
- Les patterns de requêtes évoluent
Mettez en place un pipeline d'évaluation automatisé avec des datasets golden (questions + réponses attendues) et mesurez régulièrement la fidélité et la pertinence.
7. Le monitoring LLMOps est différent du monitoring applicatif classique
Les métriques classiques (latence, erreurs) ne suffisent pas. Il vous faut :
- Faithfulness : la réponse est-elle fondée sur les chunks récupérés ?
- Answer relevance : répond-elle à la question posée ?
- Context precision : les chunks récupérés sont-ils pertinents ?
- Cost tracking : combien de tokens sont consommés par requête ?
Des outils comme LangSmith, Phoenix ou Helicone facilitent ce monitoring.
Le RAG est une technologie puissante, mais son industrialisation demande une rigueur d'ingénierie qui va bien au-delà du PoC. Si vous êtes en train de passer ce cap et avez besoin d'un regard externe, contactez-moi.