Architecture RAG en assurance : du document source à une réponse réellement vérifiable

Ce qu’il faut retenir

• Une architecture RAG vérifiable ne se résume pas à « rechercher puis générer ». Elle relie chaque affirmation à un document autorisé, une version, un passage, une règle de sélection et une exécution identifiable.
• La récupération, le reranking, la construction du contexte, la rédaction et l’attribution ont des critères distincts. Un score de réponse final ne permet pas d’identifier l’étage défaillant.
• Le système doit représenter explicitement l’absence de preuve, les contradictions et les documents obsolètes. Sinon, le générateur transforme silencieusement un vide documentaire en texte plausible.
• La recette compare les résultats attendus à chaque frontière : documents admissibles, passages candidats, passages retenus, affirmations produites et citations effectivement probantes.
• Pour un usage assurance, la réponse reste une préparation contrôlable. La décision, l’interprétation contractuelle et l’action sur le dossier suivent une règle et une responsabilité séparées.

Choisir l’unité de preuve avant l’architecture

Le mot « réponse » cache plusieurs objets. Une réponse peut contenir une valeur, une synthèse, une règle, une incertitude et une recommandation. Pour qu’elle soit vérifiable, l’équipe doit d’abord décider quelle unité documentaire peut soutenir chacune de ces affirmations : page, paragraphe, ligne de tableau, cellule accompagnée de ses en-têtes, clause avec son titre ou ensemble de passages reliés.

Une citation vers un PDF de quarante pages n’est pas une preuve localisée. À l’inverse, une phrase isolée peut perdre l’exception située juste après. L’unité de preuve est donc différente de l’unité d’affichage et parfois de l’unité indexée. Le fragment récupéré conserve un chemin vers le document canonique, sa version, sa page, sa région et ses voisins utiles.

L’article fondateur de Lewis et al. sur la Retrieval-Augmented Generation combine une mémoire paramétrique et un index dense de passages pour des tâches de connaissance. Il pose notamment la question de la provenance et de la mise à jour des connaissances. Une architecture métier prolonge cette idée, mais doit ajouter droits, versions, localisation, contradictions et règles d’usage qui ne figurent pas automatiquement dans un modèle RAG de recherche.

Construire un corpus admissible et versionné

Le corpus n’est pas un dossier partagé copié dans un index. C’est une collection gouvernée dans laquelle chaque document possède un statut. Pour une notice ou un contrat, ce statut comprend au minimum le produit, la population, la date d’effet, la date de fin, le territoire, la version, la relation avec les avenants et le niveau d’accès. Les documents supprimés de l’usage actif peuvent rester dans une archive, mais ne doivent pas réapparaître silencieusement dans une réponse courante.

L’ingestion sépare le fichier original, le texte extrait et les fragments indexés. L’empreinte du fichier permet de savoir si deux noms différents décrivent le même binaire. La version de l’extracteur, la langue détectée, l’ordre des pages et les erreurs de lecture sont conservés. L’article sur la Document AI, l’OCR et la structure de page décrit cet étage ; le RAG ne corrige pas magiquement une colonne mal lue ou une page manquante.

La suppression logique d’un document de l’index doit être vérifiée. Une liste de suppression non appliquée, un cache ou un index secondaire peut maintenir un passage interdit. La recette injecte un document témoin retiré, vérifie son absence à toutes les profondeurs de recherche et contrôle les journaux sans y recopier son contenu.

Transformer la question sans perdre ses contraintes

La question utilisateur ne contient pas toujours le produit, la version ou le type de pièce. Une couche de préparation peut extraire ces contraintes du contexte autorisé du dossier et construire une requête de recherche. Cette opération doit être observable : texte original, reformulation, filtres ajoutés, valeurs inconnues et source de chaque contrainte.

Une reformulation générative peut améliorer le vocabulaire de recherche mais aussi supprimer une négation, généraliser un produit ou injecter une hypothèse. L’architecture conserve donc la requête originale et compare plusieurs voies : recherche lexicale sur les termes exacts, recherche dense sur la formulation et, si nécessaire, expansions bornées. Les numéros de clause, références, montants et dates ne doivent pas être remplacés par une paraphrase.

Les droits sont appliqués avant de construire les candidats. Le système ne recherche pas largement pour filtrer ensuite des pièces auxquelles l’utilisateur n’a pas accès lorsque cette stratégie crée une exposition ou une journalisation indue. Le comportement précis des filtres dépend du moteur ; il est testé avec des identités, tenants et produits distincts.

Récupérer des candidats et mesurer la couverture

Le retriever a une seule responsabilité : former un ensemble de candidats assez complet pour la question, dans le corpus admissible. Dense Passage Retrieval décrit une architecture à deux encodeurs pour retrouver des passages sur des jeux de question-réponse ouverte. Ses résultats ne démontrent rien sur un corpus assurance, mais la séparation retriever/lecteur reste un diagnostic utile.

La recherche hybride juxtapose au moins une voie lexicale et une voie dense. Le lexical protège les identifiants, termes rares et correspondances exactes ; le dense apporte une proximité apprise entre formulations. Les listes portent l’origine de chaque candidat et sont dédupliquées par identité documentaire, pas seulement par texte.

Le rappel de pertinence mesure si les preuves annotées apparaissent dans les k candidats. Il ne doit pas être confondu avec le rappel technique de l’index approximatif contre une recherche vectorielle exacte. Le guide sur les embeddings et la recherche vectorielle détaille cette différence. Une perte ANN exige un réglage d’index ; une perte de pertinence peut venir du modèle, du découpage, de la requête, des filtres ou des jugements.

Pour une réponse qui exige garantie et exclusion, le test considère le paquet complet. Trouver la garantie seule peut donner un hit@k flatteur mais produire une réponse dangereusement incomplète. Les requêtes de recette indiquent donc le nombre et le rôle des preuves nécessaires, ainsi que les documents qui constituent des négatifs difficiles.

Reranker sans fabriquer une source

Le reranker réordonne un ensemble borné. Il ne peut récupérer un passage absent et ne doit pas créer une nouvelle citation. Son entrée contient la requête, l’identité des candidats et éventuellement leurs métadonnées admissibles ; sa sortie conserve les mêmes identifiants avec un score et un rang.

La recette mesure le gain entre l’ordre du retriever et l’ordre après reranking : premier passage suffisant, couverture du paquet de preuve, diversité documentaire et présence de contradictions. Elle vérifie aussi la latence et le coût, car augmenter le nombre de candidats peut améliorer le rappel tout en rendant le parcours inutilisable.

Un passage très proche de la question peut être obsolète ou incomplet. Les contraintes de version et de droit ne sont donc pas des suggestions au reranker. Elles sont appliquées en amont ou par une règle déterministe, puis attestées dans le manifeste. Le dossier consacré au reranking et aux citations propose les tests spécifiques de rang et d’attribution.

Assembler un contexte avec un manifeste de preuves

Le générateur ne reçoit pas une concaténation opaque. La couche de contexte construit un manifeste : identifiant de requête, fragments retenus, document et version, localisation, ordre, motif de sélection, budget utilisé et fragments écartés. Les délimiteurs empêchent de confondre deux sources et les métadonnées ne sont pas présentées comme du contenu contractuel.

L’ordre mérite un test. Une information présente dans une longue fenêtre n’est pas nécessairement utilisée de façon stable. Le guide sur la fenêtre de contexte et la qualité du dossier explique pourquoi le budget doit être composé par fonction. La recette permute l’ordre des passages, place la preuve au début, au milieu et à la fin, puis compare fidélité et complétude.

Les contradictions sont conservées et signalées. Si une notice et un avenant actif divergent, la couche ne choisit pas silencieusement le texte le plus récent sans vérifier leur relation. Elle produit un état structuré : documents en conflit, règle de priorité disponible ou non, et action d’escalade. Une déduplication textuelle ne doit pas éliminer une version dont le statut change la réponse.

Générer sous contrat de sortie

Le prompt n’est pas la seule barrière. Le schéma de sortie sépare les affirmations, leurs citations, les limites et l’action proposée. Chaque affirmation porte les identifiants des fragments censés la soutenir. Une réponse libre peut être rendue ensuite, mais la structure reste disponible pour le contrôle.

Le générateur reçoit l’instruction d’utiliser uniquement le manifeste et de s’abstenir lorsqu’il ne contient pas la preuve nécessaire. Cette instruction est testée avec des contextes volontairement vides, incomplets et adverses. Une consigne réussie sur quelques exemples n’est pas une garantie ; la règle déterministe empêche en plus d’émettre certains types de réponse si le paquet de preuve obligatoire est incomplet.

Le système différencie citation et décision. Citer une clause ne signifie pas avoir déterminé qu’elle s’applique. Une sortie peut préparer « le contrat contient la condition suivante » avec localisation, alors que « la condition est satisfaite dans ce dossier » demande des faits, des règles et une responsabilité supplémentaires.

Vérifier les affirmations et leurs citations

Une citation est correcte si elle pointe vers le bon objet. Elle est probante si ce passage soutient effectivement l’affirmation. Elle est complète si toutes les parties sensibles de l’affirmation sont couvertes. Ces trois propriétés sont évaluées séparément.

1. Découper la réponse en affirmations vérifiables, sans considérer les transitions de style comme des faits.
2. Résoudre chaque identifiant de citation vers la version exacte du fragment.
3. Vérifier que la localisation existe dans le document original.
4. Comparer l’affirmation au passage, y compris négations, montants, dates, conditions et exceptions.
5. Rechercher les affirmations sans citation et les citations qui ne soutiennent aucune affirmation.
6. Contrôler que la réponse ne transforme pas une observation en décision.

Une évaluation automatique peut accélérer le tri, mais les cas critiques sont jugés sur une référence humaine et des critères écrits. Le modèle qui génère la réponse ne valide pas seul sa propre fidélité. Les désaccords sont classés : mauvaise récupération, mauvaise sélection, mauvaise attribution, mauvaise synthèse ou règle d’usage absente.

Scénario pédagogique : répondre sur une franchise et ses conditions

Scénario synthétique, sans client ni résultat réel. Un gestionnaire demande : « Quelle franchise s’applique au bris de glace et y a-t-il une condition particulière ? » Le corpus contient une notice active, une ancienne version très proche, un avenant qui modifie le montant et une fiche commerciale qui résume la garantie sans valeur contractuelle.

La vérité de référence exige trois preuves : la ligne de tableau avec le montant, l’en-tête identifiant la garantie et le passage de l’avenant qui indique sa date d’effet. La fiche commerciale est pertinente pour le thème mais non suffisante ; l’ancienne notice est un négatif difficile.

1. Le contexte du dossier fournit le produit et la date applicables sans exposer d’autre tenant.
2. Le lexical retrouve la référence de garantie et l’avenant ; le dense ajoute des formulations voisines.
3. Le filtre exclut l’ancienne version du paquet actif tout en la gardant comme cas de non-régression.
4. Le reranker place le tableau et l’avenant avant le résumé commercial.
5. Le manifeste relie les trois fragments, leur page et leur version.
6. La sortie sépare montant, condition, date d’effet et avertissement si un fait du dossier manque.
7. Le contrôleur d’attribution vérifie que chaque valeur est lisible dans la région citée.

Les variantes changent une seule variable : date du dossier, montant dans l’avenant, retrait de la page, ordre des passages ou présence de la fiche commerciale seule. Les effets attendus sont écrits avant exécution. Si le système maintient le même montant après retrait de sa preuve, la recette échoue même si la phrase reste plausible.

Recette par étage et signaux d’arrêt

Le jeu comprend des requêtes répondables, non répondables, ambiguës et contradictoires. Il segmente par produit, langue, document, complexité et niveau de risque. Les seuils bloquants sont fixés avant les résultats ; une amélioration moyenne ne compense pas une régression sur un montant, une version ou une frontière d’accès.

La comparaison commence par des baselines : recherche lexicale seule, dense seule, hybride, puis reranking et génération. Cette progression révèle la contribution de chaque étage. Ajouter un composant n’est justifié que si son gain est mesuré et si son échec reste observable.

Exploiter, versionner et revenir en arrière

Une exécution de production enregistre la version du corpus, de l’extracteur, des règles de filtrage, des retrievers, du reranker, du générateur, du prompt, du schéma et du contrôleur d’attribution. Les contenus sensibles ne sont pas dupliqués inutilement dans les logs ; les identifiants permettent de résoudre la preuve avec les droits appropriés.

Une mise à jour documentaire déclenche une indexation contrôlée et la vérification des suppressions. Un changement de modèle ou de découpage construit un index parallèle. Les requêtes de référence sont rejouées avant bascule, puis un petit trafic peut comparer les versions sans modifier les décisions. L’ancien chemin reste disponible jusqu’à l’expiration de la fenêtre de retour.

Le tableau de bord suit la distribution des requêtes, les listes vides, le recouvrement lexical/dense, le rappel sur le lot stable, les corrections d’attribution, les abstentions, les incidents et la latence par étage. Une dérive déclenche une investigation ; elle n’autorise pas à relâcher automatiquement les seuils.

Le cadre des sept indicateurs d’un POC IA assurance complète les mesures techniques par la baseline métier, le coût complet et l’adoption. Une architecture vérifiable ne vaut que si la vérification est utilisée, si les exceptions trouvent un propriétaire et si la voie de repli fonctionne réellement.

Sources et références primaires

Le critère décisif reste opérationnel : une réponse doit pouvoir être reliée à la bonne version d’un document, puis contestée et rejouée sans ambiguïté.

• Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020.
• Karpukhin et al. — Dense Passage Retrieval for Open-Domain Question Answering, EMNLP 2020.
• Thakur et al. — BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models, 2021.
• Muennighoff et al. — MTEB: Massive Text Embedding Benchmark, EACL 2023.
• Li et al. — Evaluating Object Hallucination in Large Vision-Language Models, EMNLP 2023, pour le principe de négatifs contrôlés appliqué ici par analogie méthodologique, pas comme benchmark RAG.
• NIST — AI Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1.