Construire un système RAG en production : retours d'expérience

RAG (Retrieval-Augmented Generation) est devenu le pattern dominant pour intégrer des LLMs dans des contextes métier. Mais entre un POC qui fonctionne et un système RAG en production, il y a un abîme. Voici ce qu'on a appris.

Architecture logicielle et intelligence artificielle

RAG (Retrieval-Augmented Generation) est le pattern dominant pour donner à un LLM accès à vos données sans fine-tuning. Un POC RAG se construit en une journée. Un système RAG fiable en production se construit en plusieurs semaines. Voici les problèmes que vous allez rencontrer et comment les anticiper.

Ce que RAG résout — et ce qu'il ne résout pas

RAG résout le problème de la date de coupure et de la connaissance propriétaire : votre LLM ne connaît pas vos documents internes, vos emails, votre base de connaissances. RAG lui donne accès à ces sources au moment de l'inférence.

RAG ne résout pas les hallucinations. Un LLM peut ignorer les sources récupérées, les interpréter incorrectement, ou fabriquer des informations entre les extraits fournis. C'est un problème distinct qui nécessite une évaluation et des guardrails spécifiques.

Les 5 décisions qui définissent la qualité de votre RAG

1. La stratégie de chunking

Découper vos documents en chunks est la décision la plus impactante et la moins discutée. Un chunk trop petit perd le contexte. Un chunk trop grand dépasse la fenêtre de contexte ou dilue la pertinence.

Les approches qui fonctionnent en production : le chunking sémantique (découper aux frontières naturelles du sens, pas aux 512 tokens), le chunking hierarchique (stocker le chunk et son résumé parent pour la récupération), et les chunks avec overlap (chaque chunk inclut les 100 derniers tokens du chunk précédent pour préserver la continuité).

2. Le modèle d'embedding

L'embedding transforme vos chunks en vecteurs. Le choix du modèle détermine la qualité de la recherche sémantique. En 2026, les modèles d'embedding multilingues (comme text-embedding-3-large d'OpenAI ou les modèles E5 d'Intfloat) surpassent les modèles anciens sur les tâches métier complexes.

Important : le modèle d'embedding doit être le même à l'indexation et à la requête. Si vous changez de modèle, vous réindexez tout.

3. La stratégie de récupération

La recherche vectorielle pure (cosine similarity) ne suffit pas. Les approches hybrides — combinant recherche vectorielle et recherche lexicale (BM25) — surpassent systématiquement la recherche vectorielle seule sur les benchmarks métier. Le re-ranking (passer les résultats dans un modèle cross-encoder pour reordonner par pertinence) améliore encore significativement la qualité finale.

4. La gestion du contexte dans le prompt

Comment vous présentez les sources récupérées au LLM impacte directement la qualité de la réponse. Les bonnes pratiques : indiquer explicitement la provenance de chaque extrait, demander au modèle de citer ses sources, et construire un prompt système qui guide le comportement en cas d'information insuffisante ("si les sources ne permettent pas de répondre, dis-le explicitement").

5. L'évaluation continue

Un système RAG sans évaluation est un système qui dégrade silencieusement. Mettez en place des métriques mesurables dès le jour 1 : faithfulness (la réponse est-elle fidèle aux sources ?), answer relevancy (la réponse répond-elle à la question ?), et context recall (les sources pertinentes ont-elles été récupérées ?). Des frameworks comme RAGAS permettent d'automatiser cette évaluation.

Les problèmes que vous ne voyez pas en POC

La latence — En POC, vous testez avec quelques dizaines de documents. En production, la récupération sur des millions de chunks, le re-ranking et l'appel LLM s'accumulent. Mesurez et fixez des SLAs dès le développement.

Les hallucinations situationnelles — Votre RAG peut fonctionner parfaitement sur 95% des questions et halluciner sur des edge cases spécifiques. Un jeu d'évaluation représentatif doit couvrir ces cas difficiles.

La fraîcheur des données — Votre base vectorielle devient obsolète dès que vos documents sources changent. Définissez votre politique de réindexation : temps réel (webhooks), batch quotidien, ou à la demande.

La sécurité et le contrôle d'accès — En production, tous les utilisateurs ne doivent pas accéder à tous les documents. L'autorisation au niveau du chunk (récupérer uniquement les sources accessibles à l'utilisateur courant) est complexe et souvent omise en POC.

Ce qu'on recommande pour démarrer

Commencez simple : chunking fixe avec overlap, embedding OpenAI ou Mistral, stockage dans PgVector (PostgreSQL). Ajoutez la complexité progressivement, guidé par les métriques. Ne sur-ingénieriez pas votre pipeline avant d'avoir un jeu d'évaluation représentatif.

L'équipe Valtieri conçoit des systèmes RAG en production pour des contextes métier critiques. Nous contacter pour un cadrage.

Un projet ? Une question ?

Nous contacter →