Une réponse convaincante peut être pire qu’une absence de réponse. Dans une entreprise, le problème d’un système RAG n’est pas seulement qu’il peut se tromper : c’est qu’il peut se tromper avec aplomb devant la personne qui doit agir aujourd’hui.
Le vrai test n’est pas la vitesse de réponse, mais la capacité à se taire au bon moment.
C’est ce standard qu’il faut appliquer avant de faire confiance à un RAG métier : non pas juger s’il paraît intelligent, mais observer son comportement quand la documentation est incomplète, quand les sources se contredisent et quand la question ne mérite pas une réponse automatique. Cela change l’exploitation bien plus qu’une démo propre.
L’erreur classique : évaluer un RAG comme un moteur de recherche
Le piège le plus fréquent consiste à tester le système avec des questions faciles. “Quelle est la politique de retour ?”, “Comment demander un congé ?”, “Où est la politique de frais ?”. Le résultat paraît bon, mais cela ne dit pas encore s’il est utile au travail.
RAG signifie Retrieval-Augmented Generation, soit génération augmentée par récupération. En clair, le système combine recherche et rédaction. Son risque ne tient donc pas seulement à ce qu’il écrit, mais à ce qu’il récupère, à ce qu’il ignore et à sa réaction lorsque la récupération est faible ou contradictoire. Si vous n’examinez que la phrase finale, vous regardez la vitrine, pas l’atelier.
La question utile est plus inconfortable : le système peut-il montrer d’où vient chaque réponse, et que fait-il quand il ne sait pas ? Si vous ne pouvez pas répondre à cela, vous n’avez pas un assistant fiable ; vous avez une machine qui donne l’impression d’être sûre d’elle.
Les cinq questions qui séparent l’aide du bruit
Avant de valider un RAG, posez cinq questions très concrètes :
- Quelles sources est-il censé utiliser, et lesquelles sont hors périmètre ?
- Cite-t-il l’origine de la réponse de façon vérifiable ?
- S’abstient-il quand la preuve est insuffisante ?
- Demande-t-il une précision quand la question est ambiguë ?
- Escalade-t-il vers un humain quand le risque est opérationnel ou juridique ?
Pas besoin d’un laboratoire pour le voir. Il faut une petite série de cas réels : une ancienne politique, un document dupliqué, une procédure avec exceptions, une question mal formulée et une demande dont la bonne réponse est “je ne sais pas”.
La documentation OpenAI sur les evals va dans ce sens : définir des critères de test, utiliser des sources de données bien délimitées et exécuter des evals pour vérifier le comportement du système sur des données de test, pas seulement à l’intuition. Son approche des graders suit la même logique, en évaluant les réponses selon des critères précis plutôt qu’à partir d’une impression générale. (platform.openai.com)
Mini-cas : le problème n’était pas l’IA, mais la preuve
Imaginons une entreprise de taille moyenne avec un support interne et un RAG bâti sur des procédures. Au départ, tout semble bien : l’équipe pose des questions courantes et reçoit des réponses rapides. Quelques semaines plus tard, le vrai schéma apparaît.
Quand l’équipe technique modifie un processus et que l’ancien PDF reste indexé, le système mélange les deux versions. Quand une question comporte une exception selon le client ou le pays, il répond comme si la règle était universelle. Et quand il ne trouve pas assez d’éléments, il comble le vide avec une phrase élégante.
Dans ce cas, l’échec ne vient pas seulement du modèle. Il vient du mélange de sources sans hiérarchie, de l’absence de date de validité visible et du fait de ne pas avoir défini quelles questions doivent passer par une revue humaine. La leçon est rude mais utile : un RAG ne corrige pas le désordre documentaire ; il l’amplifie.
Le choix inconfortable : moins d’automatisation, plus de contrôle
Voici la partie la moins populaire. Un bon RAG métier ne doit pas répondre à tout. En réalité, plus la décision est importante, plus il devrait s’abstenir souvent.
Cela paraît moins utile, mais dans l’exploitation réelle il vaut souvent mieux qu’un système dise “à revoir” plutôt que de fournir une réponse inventée, mais bien présentée. En support, achats, RH ou conformité, une mauvaise réponse coûte plus de temps qu’elle n’en fait gagner.
On peut distinguer trois niveaux :
- les questions de référence générale, où le système peut répondre avec une certaine marge ;
- les questions opérationnelles, où il doit citer et vérifier ;
- les questions sensibles, où il doit s’arrêter et escalader.
Ce choix ne freine pas le projet ; il évite qu’un premier succès de démonstration devienne ensuite un problème de confiance.
Comment le revoir sans créer de bureaucratie
L’évaluation n’a pas besoin d’être lourde. Elle peut commencer avec un tableau simple : question, source attendue, bonne réponse, niveau de confiance, action si la preuve manque. L’important est de répéter l’exercice avec des cas réels, pas imaginés.
Trois signaux valent plus qu’une présentation soignée : des réponses avec citation claire, une abstention quand la preuve manque, et des revues humaines qui améliorent réellement la base documentaire. Si ces trois signaux n’apparaissent pas, le système est encore en mode démo, même s’il est déjà utilisé en production.
L’approche des evals d’OpenAI va dans cette direction : définir des données de test, mesurer des critères précis et revoir les résultats de manière systématique plutôt que de se fier à une première impression. (platform.openai.com)
Ce que vous pouvez demander cette semaine
Si vous évaluez un RAG, voici trois questions très pratiques à traiter cette semaine :
- Quelles sont les trois mauvaises réponses qui feraient vraiment perdre confiance ?
- Quels documents doivent primer sur les autres, et comment cela se voit-il concrètement ?
- Qui relit les réponses douteuses, et selon quelle règle la base est-elle corrigée ?
Si un système va influencer des décisions réelles, le standard ne devrait pas être qu’il semble prêt, mais qu’il sache quand il ne doit pas parler. Chez Codefuente, nous partons souvent de cette frontière : moins de promesse, plus de test et plus de contrôle opérationnel.