RAG en production

Comment je construis des systèmes RAG prêts pour la production

Un blueprint concret couvrant gouvernance des sources, ingestion, retrieval hybride, réponses sourcées, évaluation et déploiement progressif.

28 mars 20265 min de lectureRAGGénération augmentée par recherche

La plupart des démonstrations RAG fonctionnent parce que le corpus est petit, propre et préparé à la main. Les documents d'entreprise sont différents : plusieurs versions coexistent, les mises en page cassent les parsers, l'ownership est flou, les accès varient selon l'utilisateur et une réponse critique peut dépendre d'un tableau ou d'une pièce jointe que l'indexation a silencieusement perdue. L'objectif n'est pas de faire répondre le modèle à un exemple. Il faut obtenir un comportement régulier et explicable malgré l'évolution des données et les contraintes de latence, de coût et de gouvernance. Le RAG doit donc être traité comme un système d'information complet, pas comme un prompt relié à une base vectorielle.

Définir le périmètre des sources avant le retrieval

Je commence par un registre des sources. Pour chacune, il décrit le propriétaire, le niveau d'autorité, l'audience, la politique d'accès, la fréquence de rafraîchissement, la rétention et le statut courant. Cela évite qu'un document archivé ou non officiel entre en concurrence avec la source approuvée. La résolution du périmètre doit précéder la recherche. L'identité de l'utilisateur, le contexte métier, le statut du document, la langue et la date d'effet peuvent déterminer le corpus valide. Appliquer ces contraintes après la recherche sémantique risque d'exposer une information ou d'ancrer la réponse dans la mauvaise version. Le pipeline d'ingestion doit ensuite rendre chaque étape observable :

collecter la source approuvée en préservant son identité ;
extraire texte, tableaux, structure et pièces jointes ;
normaliser métadonnées et attributs d'accès ;
découper le contenu selon la structure du document ;
produire les représentations de recherche ;
publier un index versionné et un rapport d'ingestion.

Les échecs doivent être visibles par document et par section. Un pipeline terminé avec succès ne prouve pas qu'un tableau a été compris ou que tous les documents attendus ont atteint l'index.

Concevoir le retrieval comme un système de classement mesurable

J'évalue le retrieval avant la génération. Si les preuves manquent, un modèle plus puissant produit souvent une réponse non sourcée simplement plus convaincante. Un stack de retrieval peut combiner :

filtres de métadonnées et de permissions ;
recherche lexicale pour les identifiants et termes métier exacts ;
recherche vectorielle pour la proximité sémantique ;
réécriture des requêtes ambiguës ou conversationnelles ;
reranking du jeu de candidats ;
diversification ou remontée au document parent lorsque les fragments manquent de contexte.

La bonne configuration dépend du corpus. Une politique juridique, une procédure de maintenance, un catalogue produit et un rapport financier n'ont ni la même structure ni le même coût d'échec. La taille des chunks ne constitue pas à elle seule une stratégie de retrieval. Pour l'évaluation, je conserve de vraies questions, les éléments attendus dans la réponse, les sources requises et les affirmations interdites. Recall at k et qualité du ranking aident à diagnostiquer la recherche, tandis qu'une revue humaine vérifie que les passages sont complets et utilisables. Le framework d'évaluation RAG détaille la séparation entre retrieval, génération, citations et signaux opérationnels.

Un RAG de production forme une chaîne complète. La qualité peut échouer avant que le modèle ne reçoive le moindre contexte.

Contraindre la génération par les preuves

La couche de réponse doit recevoir des preuves traçables et des règles explicites. Je définis la manière de citer les sources, traiter les documents contradictoires, exprimer l'incertitude et refuser lorsque les éléments sont insuffisants. Le refus est un résultat valide lorsque l'alternative serait une affirmation non sourcée. Je distingue la qualité de réponse de la qualité des preuves. Une réponse fluide avec une citation invalide reste un échec. Une information correcte appuyée par un document obsolète aussi. Le contrôle des citations doit donc vérifier que le passage existe, que l'utilisateur peut y accéder et qu'il soutient réellement l'affirmation. Le système doit proposer des fallbacks sûrs : préciser la requête, poser une question de clarification, suggérer une source approuvée ou router vers un owner humain. Il ne doit pas répondre silencieusement depuis la mémoire du modèle lorsque le produit promet un comportement fondé sur les sources.

Observer le pipeline et qualifier les échecs

Les traces relient la demande utilisateur au périmètre, à la transformation de requête, aux éléments récupérés, au reranking, aux appels de modèle, aux guardrails, aux citations, à la latence et au coût. Elles permettent de qualifier l'échec :

source : le contenu requis manque, est obsolète ou non autorisé ;
parsing : la structure, les tableaux ou le texte sont dégradés ;
retrieval : une preuve valide existe mais n'est pas sélectionnée ;
synthèse : le modèle interprète mal des preuves suffisantes ;
politique : le système répond, refuse ou escalade au mauvais moment ;
runtime : latence, timeout ou intégration brisent le parcours.

Cette taxonomie évite de modifier le prompt pour chaque problème de qualité. Elle clarifie aussi les responsabilités entre équipes contenu, data, retrieval, application et plateforme. Mon étude de cas publique DAISI présente réponses sourcées, évaluation, sécurité et tests opérationnels comme des dimensions distinctes de la préparation à la production. L'implémentation exacte reste propre à son environnement, mais cette séparation des responsabilités est largement réutilisable.

Déployer progressivement et anticiper l'évolution du corpus

Je commence par un jeu d'évaluation éditorialisé et un pilote en lecture seule. L'ingestion et le retrieval sont validés avant la couche de réponse. Un petit groupe fournit ensuite un feedback relié aux traces. L'ouverture dépend de modes d'échec compris, d'accès stables, d'une latence et d'un coût acceptables, ainsi que d'un fallback testé. Les releases d'index demandent la même discipline que les releases applicatives. Un parser, un modèle d'embedding, une règle de chunking ou une source peuvent modifier le comportement sans changement de prompt. Je versionne corpus et configuration de retrieval, compare les index candidats et conserve un retour vers la dernière version validée. Des compromis subsistent. Le retrieval hybride améliore la couverture mais ajoute du tuning et du coût. Le reranking peut améliorer la précision tout en augmentant la latence. Davantage de contexte peut renforcer la complétude ou diluer les preuves pertinentes. Une fraîcheur trop agressive peut publier du contenu mal vérifié. Ces choix doivent être faits par workflow et mesurés sur de vraies questions. Un RAG de production gagne la confiance par les preuves : sources connues, ingestion observable, retrieval mesurable, génération bornée, évaluation reproductible et rollout capable de s'arrêter ou de revenir en arrière lorsque le corpus change de manière inattendue.

Sources et références

Google Cloud : application d'IA générative avec RAGArchitecture de référence pour l'ingestion, le retrieval, la génération et le service applicatif
Tutoriel LangChain sur la recherche sémantique et le RAGGuide officiel sur les loaders, embeddings, bases vectorielles, retrievers et workflows RAG minimaux

Des principes aux systèmes livrés

Ces articles documentent mes méthodes de travail. Les études de cas montrent comment je les applique aux agents d'entreprise, au RAG et au MLOps.

Voir les études de cas Consulter mon CV

Continuer l'exploration

Des notes complémentaires sur les choix d'architecture, d'évaluation et d'exploitation des systèmes IA en production.

9 avril 20265 min de lectureÉvaluation RAGRAG