RAG de zéro : du document à la réponse vérifiée

La Retrieval-Augmented Generation ajoute à une requête des fragments de connaissances externes. Le système peut ainsi travailler avec des documents privés, des données récentes et des sources absentes de l’entraînement du modèle.

Le RAG ne met pas à jour les paramètres du LLM. Les connaissances restent dans un stockage externe : elles peuvent donc être versionnées, supprimées, soumises à des droits d’accès et citées.

Les PDF, le HTML, les e-mails et les tableaux contiennent du bruit : menus, doublons, en-têtes et pieds de page, caractères cachés et ordre de lecture incorrect. Si l’ingestion perd la structure, le retrieval ne pourra pas la reconstruire ensuite.

Chaque fragment doit conserver document_id, version, source, date, langue, droits d’accès et position dans l’original. Ces métadonnées sont nécessaires au filtrage, aux citations et à la suppression des enregistrements obsolètes.

Des chunks trop petits perdent le contexte ; des chunks trop grands mélangent les sujets et consomment une partie précieuse de la fenêtre de contexte. Il vaut mieux découper selon des limites sémantiques : titres, paragraphes, clauses de politique ou fonctions de code.

Après normalisation, les chunks sont transformés en embeddings. La recherche vectorielle trouve la proximité sémantique, mais pour les noms, codes et termes exacts il est préférable de la combiner à une keyword search et à des filtres de métadonnées.

Le premier retriever renvoie rapidement des candidats, puis un reranker détermine plus précisément quels fragments répondent réellement à la requête. Le modèle doit recevoir un ensemble compact des preuves les plus fortes.

Le modèle doit répondre à partir des sources fournies et signaler explicitement l’insuffisance de preuves. Les citations sont construites à partir de véritables valeurs source_id et le système vérifie que chaque identifiant figurait bien dans le contexte.

Le retrieval et la génération doivent être évalués séparément. Si le bon document n’a pas été trouvé, le problème ne vient pas du modèle. Si la preuve a été trouvée mais que la réponse ajoute des affirmations non étayées, le problème relève du grounding ou de la politique de génération.

Un jeu d’évaluation doit contenir de vraies questions, les sources attendues, les bonnes réponses et des cas négatifs où le système doit s’abstenir. Les métriques incluent retrieval recall, precision, groundedness et précision des citations.

Un RAG de base comprend ingestion, normalisation, chunking, embeddings, index, retrieval et génération de réponse. En production s’ajoutent les ACL, le versionnement des documents, les filtres de métadonnées, le reranking, la journalisation des requêtes et un mécanisme de suppression des fragments obsolètes. Sans ces couches, un prototype devient vite une collection de vecteurs ingérable.

Chaque chunk doit conserver sa provenance : document, version, page ou section, instant d’indexation et droits d’accès. Une réponse peut alors être expliquée, vérifiée et révoquée après modification de la source. Un vecteur sans provenance est presque inutilisable dans un système fiable.

Lorsqu’une réponse est incorrecte, commencez par vérifier si le modèle a reçu les preuves nécessaires. Évaluez le retrieval avec recall, precision, hit rate, MRR ou nDCG sur des requêtes dont les fragments pertinents sont connus. Évaluez séparément la génération : utilisation des sources, absence de contradictions et exactitude des citations.

Cette séparation accélère le diagnostic. Si un chunk pertinent n’a pas été récupéré, modifier le prompt ne servira à rien ; améliorez le chunking, les embeddings, le query rewriting ou le reranking. Si la preuve est présente mais ignorée, examinez l’assemblage du contexte, les instructions ou le modèle.

Les problèmes les plus fréquents sont des chunks trop grands ou trop petits, l’absence de filtres de métadonnées, les doublons, le mélange de versions, les requêtes utilisateur faibles et un nombre excessif de fragments retournés. Plus de contexte ne garantit pas une meilleure réponse : les passages non pertinents réduisent le signal et créent des contradictions.

Commencez avec un petit eval dataset, mesurez le retrieval avant de brancher le LLM et journalisez chaque étape. Après le lancement, collectez les requêtes en échec, classez leurs causes et mettez à jour l’index ou le pipeline sur la base de faits plutôt que de quelques démonstrations.

Traitez le premier RAG comme un pipeline mesurable : ingestion, parsing, chunking, embedding, indexing, retrieval, reranking, génération et validation des citations. Chaque étape doit disposer de ses propres identifiants et traces afin de repérer où le bon document a été perdu. Le dataset d’évaluation doit contenir de vraies requêtes, les sources attendues et des critères de complétude. Si les preuves sont insuffisantes, la réponse doit s’abstenir ou demander une précision au lieu de masquer un retrieval faible par une génération trop assurée.

Le socle de production comprend des filtres d’accès pendant le retrieval, un index versionné, un reindexing idempotent et un rollback. Les métriques doivent couvrir recall@k, la précision des citations, la groundedness, la latence p95 et le coût par réponse réussie. Après toute modification des embeddings, du chunking ou des prompts, relancez le même jeu de régression.

• Séparez les erreurs de retrieval des erreurs de réponse.
• Conservez les source IDs dans la réponse finale.
• Utilisez un processus de reindexing contrôlé.