Mauvaise réponse IA : trouver l’étape à vérifier avant de corriger le prompt

Commencer par la réponse attendue et sa pièce de référence

« L’IA se trompe » est un signal, pas un diagnostic. Conservez la question exacte, la sortie reçue, le moment de l’essai et les réglages connus. Identifiez ensuite le passage qui permet de dire ce qui aurait dû être répondu. Sans cette référence, on risque de remplacer une impression par une autre.

Vérifiez que ce document s’applique bien au cas : version, public, période et éventuelles exceptions. Une sortie peut reproduire fidèlement un texte périmé. Le problème se situe alors en amont de la rédaction. La personne compétente sur le fond doit confirmer quelle règle fait autorité.

Ma ligne est simple : je préfère une cause encore inconnue à une explication technique inventée. La présence d’un lien dans une réponse ne démontre ni la validité de la source ni l’accès du modèle au passage précis au moment de l’essai.

Séparer recherche et production de la réponse

Dans un dispositif RAG, des passages documentaires sont recherchés pour alimenter la réponse. Microsoft distingue l’évaluation de cette recherche de celle de la réponse : fidélité au contexte, pertinence pour la question et couverture de l’information attendue. ^[1] Ces dimensions aident à organiser les contrôles ; elles ne donnent pas un seuil universel de fiabilité.

Notre diagnostic ajoute un premier examen métier : le contenu disponible était-il pertinent et applicable ? Il s’agit d’une proposition de méthode, pas d’un audit certifié du système. Pour comprendre les dispositifs possibles, consultez le guide RAG, documents joints et recherche web.

Exemple fictif : une condition disparaît

Une procédure fictive indique : « Les demandes ordinaires passent par le formulaire A. Les demandes urgentes passent par le canal B. » La question porte explicitement sur une demande urgente. L’assistant répond : « Utilisez le formulaire A. » Aucun logiciel n’a été exécuté pour cet exemple.

Trois observations conduiraient à trois pistes différentes. Si le texte extrait ne contient plus la phrase sur l’urgence, examinez la préparation du document. Si cette phrase existe dans le texte extrait mais n’apparaît pas dans les passages transmis, examinez la recherche. Si elle est présente dans ces passages, examinez la consigne et la production de la réponse.

Ces pistes restent des hypothèses à tester. Un journal peut être incomplet, plusieurs défauts peuvent se cumuler et une nouvelle exécution peut varier. Le fait de corriger une réponse en lui donnant directement le bon extrait ne prouve pas que la recherche fonctionnera ensuite dans le circuit habituel.

Préparer un test qui départage les hypothèses

Pour l’exemple, préparez une réponse attendue courte : demande urgente, canal B, référence à la condition applicable. Posez la même question dans le dispositif habituel puis, si le cadre technique et les accès le permettent, avec le passage pertinent fourni explicitement. Conservez les résultats séparément.

Changez un élément identifiable à la fois. Sinon, une amélioration obtenue après modification du document, du moteur de recherche et de la consigne ne permet pas de savoir ce qui a aidé. Une correction provisoire peut rester utile ; nommez-la comme telle et gardez le diagnostic ouvert.

Ajoutez des cas voisins : demande ordinaire, urgence non précisée, question hors périmètre. L’objectif est de vérifier qu’une correction ciblée n’a pas conduit à répondre « canal B » à toutes les questions. Le nombre d’essais dépend du périmètre et des conséquences ; cet article ne propose pas un échantillon statistiquement représentatif.

Demander les bonnes traces quand l’outil est opaque

Si l’interface ne montre que la réponse finale, ne déduisez pas le contenu exact utilisé. Demandez au fournisseur ou à l’équipe technique ce qui est observable : version documentaire, texte extrait, passages retrouvés, paramètres et restrictions d’accès. Certaines informations peuvent ne pas être disponibles.

Transmettez les pièces dans le canal autorisé, en limitant les données au nécessaire. Pour reproduire un problème, privilégiez un cas de démonstration qui conserve la difficulté sans recopier inutilement des informations confidentielles. Une reproduction simplifiée peut cependant ne pas présenter toutes les conditions du cas initial.

Le journal de vérification d’une réponse IA conserve le constat utilisateur. Le journal de maintenance suit la correction et les conditions de reprise. Ne confondez pas une note bien remplie avec la résolution technique.

Décider ce que le contrôle permet réellement

À la fin, formulez une conclusion proportionnée : « Sur ces cas, avec cette version documentaire et cette configuration, la condition a été correctement reprise. » Évitez de transformer cette observation en promesse générale d’absence d’erreur. Le guide de vérification des réponses complète le contrôle avant réutilisation.

Si la cause reste inconnue et que l’erreur peut avoir des conséquences importantes, limitez le périmètre concerné et utilisez une source ou un circuit de vérification adapté. Continuer les essais n’autorise pas à exploiter une réponse douteuse dans une décision réelle.

Un bon diagnostic rend la prochaine action plus précise : corriger une référence, réparer une extraction, ajuster une recherche, revoir une consigne ou demander une expertise. C’est cette précision qui évite d’accumuler des règles dans le prompt sans traiter le problème.

Questions fréquentes

Une réponse avec une citation est-elle forcément fidèle ? Non. Vérifiez le passage et la manière dont il soutient l’affirmation. Le lien peut être pertinent sans établir la conclusion donnée.

Un meilleur modèle suffit-il ? Cela reste à tester. Un changement de modèle ne corrige pas automatiquement une source périmée ou un passage absent.

Peut-on diagnostiquer sans journaux techniques ? On peut documenter l’erreur, contrôler la source et préparer une reproduction. L’attribution précise à une étape restera parfois impossible.