Comment évaluer l’ancrage des réponses RAG avec une fiche de preuves

Par Michael Shamanoff, fondateur d’Achla AI Dernière révision : 1 août 2026

Une checklist d’évaluation de l’ancrage d’un RAG n’est utile que si elle laisse un dossier vérifiable. Pour chaque réponse testée, séparez les affirmations matérielles, reliez chacune à un passage source exact et formulez un verdict limité assorti d’une raison. Enregistrez ensuite la requête, les passages récupérés, la réponse, les citations, les versions des sources et la version du système afin de pouvoir rejouer le même cas. Le résultat n’est ni un score de précision ni la promesse qu’une réponse est vraie. C’est une fiche de preuves au niveau des affirmations qui montre ce que les preuves visibles étayent, où une citation est simplement attachée et où le système devrait enregistrer une absence honnête.

Cet article décrit ce protocole de consignation et de rejeu. Il ne remplace volontairement pas l’explication plus large de la recherche IA ancrée, des citations et de l’abstention. Sa tâche plus étroite consiste à rendre une réponse testable auditable, sans inventer de benchmark ni dissimuler le jugement dans un taux de réussite.

Qui a créé ce protocole, comment a-t-il été préparé et pourquoi ?

Michael Shamanoff, fondateur d’Achla AI, en est l’auteur. Le protocole a été préparé à partir du brief éditorial approuvé par le propriétaire, de l’artefact produit actuel et de la documentation officielle de Microsoft, Ragas et AWS. La demande pour ce sujet reste une hypothèse expérimentale, faute de données GSC, Keyword Planner, de volume sous licence ou d’autocomplétion stable.

La méthode transforme une réponse en petites décisions de preuve qu’une personne peut reproduire. Dans cette évaluation d’une réponse ancrée, une source liée peut être pertinente pour le sujet sans étayer la phrase qui l’accompagne. L’objectif reste limité : diagnostiquer les problèmes visibles de récupération et d’étayage dans un cas de test figé. Si vous avez besoin d’une définition concise avant d’utiliser la fiche, consultez le glossaire de la recherche IA.

Commencez par un cas de preuve figé

Ne commencez pas par attribuer une note. Commencez par figer un cas. Un jeu de test d’évaluation RAG doit conserver la requête exacte, la version de la collection source, les passages récupérés dans l’ordre de retour, la réponse générée et les citations affichées. Indiquez aussi l’état de preuve attendu : quels passages seraient nécessaires à une réponse prudente et quel point demandé ne peut pas être traité par la collection.

Voici le cas synthétique utilisé dans tout l’article. Il décrit une boutique imaginaire ; ce n’est ni un résultat Achla AI ni un résultat client.

Requête Q-017 : « Puis-je retourner un article en vente finale après 30 jours, et quand commence le traitement du remboursement ? »

Source D-01, `/returns`, version `returns-v4`, passage `p04` : « Les articles achetés directement dans la boutique d’exemple peuvent être retournés dans les 30 jours calendaires suivant la livraison. Les articles en vente finale sont exclus. »

Source D-02, `/refunds`, version `refunds-v2`, passage `p07` : « Le traitement du remboursement commence lorsque l’article retourné arrive à l’entrepôt. »

État de preuve attendu : D-01 étaye un délai de 30 jours pour les achats directs éligibles et exclut explicitement les articles en vente finale. D-02 étaye le point de départ du traitement du remboursement. Aucun passage n’indique la durée du traitement.

Réponse consignée A-017 : « Vous pouvez retourner n’importe quel article dans les 30 jours, y compris les articles en vente finale.[D-01] Votre remboursement commence lorsque vous envoyez la demande.[D-02] Il est normalement terminé dans les cinq jours. »

Le cas est volontairement imparfait. Sa valeur vient du fait que chaque verdict ultérieur renvoie à un texte figé. Si votre équipe teste d’abord une différence de vocabulaire, le guide sur la récupération sémantique malgré des formulations différentes explique pourquoi récupération et génération doivent être examinées séparément.

Décomposez la réponse en affirmations matérielles

Une affirmation matérielle pourrait modifier la décision du lecteur si elle était erronée ou absente. Séparez les conjonctions, quantités, exclusions, dates, causalités et étapes de procédure lorsqu’elles reposent sur des preuves différentes. N’évaluez pas un paragraphe entier comme une seule unité.

Pour A-017, la fiche contient quatre affirmations :

1. C-017-1 : N’importe quel article peut être retourné.
2. C-017-2 : Le délai de retour est de 30 jours.
3. C-017-3 : Le traitement du remboursement commence lors de l’envoi de la demande.
4. C-017-4 : Le traitement du remboursement est normalement terminé dans les cinq jours.

« Y compris les articles en vente finale » appartient à C-017-1, car cette précision étend « n’importe quel article » et contredit une exclusion explicite. L’affirmation des 30 jours est séparée, car le passage étaye bien ce délai, sous réserve de son périmètre. L’affirmation finale sur la durée est séparée, car aucun passage récupéré ne traite de la durée.

Cette décomposition empêche un fragment étayé de faire passer pour valable un autre qui ne l’est pas. Elle rend aussi les désaccords visibles : une personne peut contester les limites de C-017-1 sans modifier silencieusement le verdict de C-017-2. Pour les collections scientifiques ou techniques, la même discipline est centrale dans un processus de recherche fondé d’abord sur les citations, même si des spécialistes du domaine doivent parfois décider de ce qui est matériel.

Construisez la fiche de preuves au niveau des affirmations

Utilisez une ligne par affirmation matérielle. Une fiche exploitable contient :

• identifiants du cas, de la requête, de la réponse et de l’affirmation ;
• texte de l’affirmation copié depuis la réponse consignée ;
• identifiants des citations attachées tels qu’affichés ;
• identifiant et version de la source récupérée, identifiant du passage et rang de retour ;
• passage exact examiné ;
• verdict et raison sur l’attachement de la citation ;
• verdict et raison écrite sur l’étayage sémantique ;
• diagnostic limité aux preuves visibles ;
• personne chargée de l’examen, heure et note non résolue.

La fiche du cas se présente ainsi :

Conservez le passage exact dans le dossier de test, pas seulement l’URL de la page. Une page peut contenir plusieurs sections apparemment pertinentes, et un rejeu ne peut les distinguer si le repère est vague. Si la source possède des ancres stables, stockez URL et ancre avec l’identifiant du passage capturé. Sinon, stockez un hash du contenu et assez de texte voisin pour retrouver le passage après modification.

Les cadres officiels appliquent des séparations similaires. La documentation des évaluateurs RAG de Microsoft distingue l’évaluation de la récupération de celle de la réponse. Ragas décrit la faithfulness par rapport aux affirmations soutenues par le contexte récupéré. AWS distingue les modes retrieve-only et retrieve-and-generate. Ces références aident à séparer pertinence de la récupération et fidélité RAG ; elles ne fournissent aucun seuil universel pour cette fiche.

Séparez l’attachement d’une citation de son étayage sémantique

« Attachée » répond à une question mécanique : la réponse enregistrée a-t-elle associé une source à l’affirmation ou à la phrase ? « Étayée » répond à une question sémantique : le passage exact justifie-t-il l’affirmation en conservant sa portée, ses exclusions, quantités et délais importants ?

Ne fusionnez jamais ces champs. C-017-1 possède une citation attachée, mais le passage cité contredit l’affirmation. C-017-4 n’a ni citation attachée ni soutien récupéré. Dans un autre cas, un passage récupéré pourrait étayer l’affirmation sans citation affichée : ce serait un problème d’attachement, pas la preuve d’un échec de récupération.

Utilisez quatre verdicts limités :

• étayée : le passage visible soutient l’affirmation matérielle et ses qualificatifs importants ;
• partiellement étayée : il soutient une partie séparable mais laisse une condition, une portée ou une relation matérielle non résolue ;
• non étayée : les passages visibles ne justifient pas l’affirmation ou la contredisent ;
• non évaluable : le dossier est incomplet ou la décision exige une expertise ou des preuves hors du cas.

Chaque verdict exige une raison écrite. Le libellé est un index, pas l’analyse. « Non évaluable » doit préciser ce qui manque ; il ne doit pas remplacer commodément l’examen.

Diagnostiquez uniquement ce que permet le dossier visible

La fiche peut révéler un symptôme sans prouver sa cause cachée. Utilisez un langage prudent et séparez observation et hypothèse.

La matrice n’est pas un évaluateur automatique et n’attribue pas l’erreur à un composant. Elle resserre l’inspection suivante. Cette distinction aide particulièrement lors du passage de la recherche de pages à une interface de réponses ; voir pourquoi la recherche de site trouve des pages alors que les visiteurs veulent des réponses.

Consignez une absence honnête comme résultat de premier ordre

Le test d’absence honnête ajoute un cas dont le fait demandé manque. Pour Q-017, la durée de cinq jours n’a aucun soutien. Une réponse limitée pourrait dire : « Les sources disponibles indiquent que le traitement commence lorsque l’article retourné arrive à l’entrepôt, mais elles n’indiquent aucune durée d’achèvement. » La fiche doit consigner séparément le point de départ étayé et la durée indisponible.

Dans l’artefact Achla AI actuel, le parcours ancré principal exige un texte de réponse accompagné de citations pour être traité comme ancré ; le widget présente aussi un état visible sans réponse et peut afficher des liens source. C’est la description d’une implémentation locale inspectée, pas une affirmation de performance ou de fiabilité. Une absence nécessite toujours les métadonnées de rejeu, car une version ultérieure de la source peut ajouter le fait manquant.

Enregistrez les métadonnées de rejeu et de version

Un rejeu n’est utile que si l’équipe sait ce qui est resté fixe et ce qui a changé. Stockez :

• texte et identifiant de la requête ;
• texte et identifiant de la réponse ;
• passages récupérés ordonnés, scores exposés et filtres éventuels ;
• identifiants de citations affichés et rattachement à l’affirmation ou la phrase ;
• identifiant d’instantané de collection, sources, versions, passages et hash de contenu ;
• identifiants de configuration de récupération et de génération ;
• version du prompt ou des instructions, identifiant du modèle consigné et révision de l’application ;
• langue, heure du test, personne chargée de l’examen et version du schéma de la fiche.

Lors d’un rejeu de régression RAG, créez un nouvel identifiant d’exécution. N’écrasez pas l’ancienne réponse et n’ajoutez pas rétroactivement de nouveaux passages à l’ancien dossier. Ne comparez les lignes que lorsque les cas sont compatibles. Si la requête, l’instantané source ou le texte du repère a changé, signalez explicitement cette dimension. Un résultat différent mérite peut-être une enquête, mais la fiche n’en établit pas seule la cause.

N’en faites pas un classement. Ne transformez pas les verdicts en score inventé, ne définissez pas de seuil arbitraire et ne publiez pas un taux de succès depuis un jeu non représentatif. Une agrégation est possible dans un dispositif d’évaluation approuvé séparément ; cette fiche sert d’abord à préserver les preuves et le jugement.

Assemblez le dossier d’audit

Le plus petit dossier utile contient le cas figé, la sortie brute de récupération, la réponse consignée, les citations affichées, les lignes d’affirmation complétées, les notes, les métadonnées de version et la comparaison du rejeu. Ajoutez le schéma de la fiche et un manifeste avec les hash des fichiers. Si un élément manque, déclarez-le manquant au lieu de le reconstruire de mémoire.

Pour un corpus documentaire limité, conservez ce dossier avec le responsable opérationnel du processus de recherche documentaire, sans séparer l’historique des preuves de celui des versions source.

Conservez les décisions en ajout seul ou par versions. Une personne peut ensuite contester une décomposition ou un verdict : préservez la ligne initiale et la révision documentée. Cet historique est plus utile qu’une fiche propre en apparence mais impossible à retracer.

Limites

Ce protocole évalue l’étayage par rapport aux preuves visibles capturées. Il ne prouve pas qu’une source est factuellement correcte, actuelle, complète ou adaptée à une décision à fort enjeu. Il ne détecte pas toutes les sources pertinentes éventuellement manquées par la récupération. Il ne remplace ni l’expertise métier, ni les examens de sécurité, confidentialité et accessibilité, ni l’évaluation de la latence et de l’expérience utilisateur.

Les limites des affirmations et verdicts sémantiques exigent du jugement. Des personnes peuvent raisonnablement diverger, notamment lorsqu’un passage implique une relation sans l’énoncer. Consignez le désaccord et sa raison. Ne transformez pas ce protocole en juge automatique ou benchmark RAG universel sans méthode validée séparément.

Utilisez la fiche sur un corpus de site limité

Choisissez un petit ensemble versionné de vraies questions de visiteurs, incluez au moins une lacune de preuve connue et conservez le dossier d’audit pour chaque rejeu. Vous obtenez ainsi une checklist d’évaluation de l’ancrage RAG vérifiable, sans prétendre au-delà de ce que montre le dossier.

Pour tester le processus sur du contenu que vous contrôlez, connectez votre site et laissez les décisions factuelles, de sécurité et de publication à une personne responsable.