Des réponses fiables, des sources citées, le droit de ne pas savoir

Un chatbot RAG fiable ancre chaque réponse dans vos documents, cite le passage qui la justifie et sait dire qu’il ne sait pas quand le corpus ne permet pas de répondre. Le but est double : une réponse fondée sur vos sources, et une réponse vérifiable par celui qui la lit.

RAG désigne la génération augmentée par récupération : avant de répondre, le système recherche dans un fonds documentaire les extraits pertinents, puis les transmet au modèle, qui rédige sa réponse à partir de ces extraits. Le modèle reçoit des extraits de vos documents en complément de ses connaissances d’entraînement. Leur fraîcheur et leur pertinence dépendent de votre chaîne documentaire.

Cette architecture apporte des éléments documentaires, sans garantir la fidélité de chaque réponse. Une recherche peut manquer le bon passage, et une synthèse peut déformer un passage correct. La fiabilité ne vient pas de l’architecture elle-même, mais des tests, des citations et des garde-fous qui l’entourent. Le contexte technique de ce choix est développé dans le RAG, la seule architecture qui tienne.

Avant de tester le chatbot, vérifiez la préparation du corpus, la recherche autorisée, les citations et le suivi des erreurs, car ces éléments conditionnent la recette.

• Un découpage cohérent de vos documents, qui préserve le sens des passages au lieu de les couper au hasard.
• Une recherche dans vos fonds, filtrée par les droits de l’utilisateur avant toute génération.
• Des citations systématiques, qui pointent vers le passage effectivement utilisé.
• Le retour des utilisateurs, avec un moyen simple de signaler une mauvaise réponse.
• Des indicateurs suivis, rejoués après chaque changement de modèle, de corpus ou de consigne.

Un chatbot documentaire doit résoudre un besoin précis dans un corpus délimité, décrit avant le choix du modèle : utilisateur, documents, résultat attendu et conséquence d’une erreur. Retrouver une clause et comparer des procédures ne demandent pas les mêmes preuves.

Dans un exemple fictif de remboursement, la réponse doit reprendre la procédure du bon produit et de la bonne date. Le lien vers une procédure périmée ne suffit pas. Désignez une personne capable de résoudre chaque question témoin et d’indiquer le passage de référence.

Le fonds doit permettre de répondre aux questions retenues : le corpus est le projet. Cette préparation rend un audit du système IA plus utile qu’une démonstration sur des questions faciles.

Tester un chatbot RAG impose de vérifier d’abord les passages retrouvés, puis la réponse construite à partir de ces passages, parce que ces deux étapes échouent pour des raisons différentes. Cette séparation évite de corriger le prompt lorsque le problème se situe dans l’index ou la recherche.

Pour chaque question, conservez le document attendu et les extraits récupérés. Si l’extrait utile n’apparaît pas, examinez les filtres, le découpage, les termes employés et la version du document. Le découpage est souvent en cause, et ses choix sont détaillés dans découper un document, le choix qui décide de tout. Si l’extrait est présent mais que la réponse le déforme, examinez la consigne de synthèse, le format demandé et le comportement du modèle face à l’incertitude.

Le jeu de tests doit inclure des questions auxquelles le corpus ne permet pas de répondre. Sinon, un système qui invente une réponse à chaque demande peut paraître plus complet qu’un système prudent. Évaluez séparément les réponses correctes, les refus appropriés et les refus inutiles.

Une citation exploitable permet de retrouver le passage effectivement utilisé par le chatbot et de vérifier qu’il soutient la réponse affichée, sans refaire toute la recherche documentaire. Indiquez si possible page, section, extrait et version.

Une référence réelle peut accompagner une conclusion absente de la source. Faites comparer chaque affirmation importante au passage cité ; notez séparément pertinence de la recherche et fidélité de la réponse.

Testez aussi la disparition d’une référence : suppression, changement de droits ou procédure remplacée. L’interface doit signaler l’indisponibilité sans présenter une ancienne réponse comme une preuve actuelle.

Dans un chatbot RAG, les droits d’accès doivent être appliqués avant de transmettre les extraits au modèle, puis rester cohérents dans les caches, l’historique et les liens affichés. Une réponse exacte peut révéler une information que son lecteur n’aurait jamais dû voir. Le filtrage des droits d’accès dans un RAG détaille cette frontière et ses tests.

Construisez deux comptes de recette avec des périmètres différents. Posez la même question aux deux comptes et comparez les documents récupérés. Retirez ensuite un accès, remplacez une procédure et supprimez un document témoin. Vérifiez le comportement de l’index, de la réponse et de l’historique. Le délai de propagation doit être connu et compatible avec le risque de l’usage.

La même vigilance s’applique à ce qui part vers le modèle : un extrait transmis à un service externe sort du périmètre de l’organisation, ce qui pose les questions abordées dans ce qu’on a le droit de mettre dans un prompt.

Désignez aussi un propriétaire pour chaque collection documentaire. Il doit pouvoir expliquer qui valide une nouvelle version, qui déclenche la réindexation et comment repérer un document obsolète. Cette responsabilité évite de confondre disponibilité technique et fraîcheur documentaire.

Le jeu de tests d’un chatbot documentaire se construit à partir de questions réelles, chacune associée à son passage de référence, et il inclut volontairement des questions sans réponse dans le corpus.

1. Recueillir des questions réelles auprès des futurs utilisateurs, formulées avec leurs mots et non reformulées par l’équipe projet.
2. Associer à chaque question le passage de référence et la version du document, validés par la personne qui connaît le sujet.
3. Ajouter des questions sans réponse : un sujet hors du corpus, une procédure qui n’existe pas, une information supprimée.
4. Définir pour chaque cas le résultat attendu : réponse correcte avec citation, refus motivé, ou renvoi vers une personne.
5. Rejouer l’ensemble après chaque changement de modèle, de corpus ou de consigne, et comparer avec la version précédente.

La méthode détaillée figure dans construire un jeu de tests en une journée, et son exécution régulière dans l’évaluation continue.

La traçabilité des tests et le circuit de signalement peuvent être réutilisés lorsque le corpus change, mais les passages attendus et les critères métier doivent être révisés. Conservez les résultats précédents pour repérer une régression ; ne réutilisez pas une validation documentaire devenue obsolète.

Un chatbot RAG peut échouer à cause du corpus, de la recherche ou de la génération, et le diagnostic doit identifier l’étape concernée avant de choisir une correction.

• Indexer sans contrôler les versions, ce qui expose la recherche aux doublons et aux contradictions.
• Tester uniquement les questions faciles, ce qui laisse les refus et les droits d’accès sans vérification.
• Corriger le prompt sans examiner les passages, alors qu’une référence utile peut manquer à la recherche.
• Traiter un document comme une consigne, au lieu de le considérer comme une donnée potentiellement trompeuse. Testez les extraits qui demandent d’ignorer les règles ou de révéler une information interdite.

Un pilote de chatbot RAG peut être ouvert lorsque les critères de réussite, les limites d’usage et la procédure d’arrêt ont été définis, puis testés sur un jeu de cas représentatif. Il n’existe pas de score universel qui autorise tous les déploiements. Le profil du NIST publié en juillet 2024 constitue un cadre de gestion des risques, à adapter à l’usage.

Préparez un compte rendu avec le nombre de cas testés, les erreurs observées, les sources manquantes et les corrections nécessaires. Mesurez la latence et le coût en plus de la qualité. Incluez le temps de vérification humain : une réponse rapide qui exige plusieurs corrections peut déplacer la charge de travail. Les obstacles habituels de ce passage sont décrits dans sortir du prototype, les cinq verrous.

Pendant le pilote, gardez un moyen simple de signaler une mauvaise réponse. Rejouez le jeu témoin après un changement de modèle, de corpus ou de consigne. La décision finale doit préciser ce que le système sait faire aujourd’hui, ce qu’il ne faut pas lui demander et qui maintient ces limites. Le refus de répondre devient alors une fonction testée, et non une formule rassurante ajoutée au prompt.