AWS montre comment 100 % de précision de recherche masquent l'échec d'un agent IA

Votre agent répond avec assurance aux questions des employés, joint des liens et passe la vérification de la recherche. Peut-on le mettre en production ? Dans l'exemple d'AWS, les fragments trouvés ont obtenu 100 % de précision sur l'une des métriques, mais pour la question sur l'arrêt maladie, aucun ne contenait l'information requise. Après une modification du prompt, la réponse est devenue encore pire. La leçon pratique : avant la prochaine modification de l'instruction, il vaut mieux vérifier si la réponse figure seulement dans les documents.

AWS a décrit ce cas dans un article consacré à l'Agent Development Lifecycle, ou Agent DLC. Il s'agit d'une approche de développement d'agents dans laquelle l'équipe définit à l'avance les critères d'acceptation, vérifie chaque modification et réinjecte dans l'ensemble de vérifications les problèmes constatés en production. Pour le développeur, l'intérêt est de disposer d'une méthode concrète pour déterminer quel composant doit être corrigé.

Pourquoi 100 % dans le rapport ne suffisaient pas

Les auteurs ont construit un agent RH de référence et l'ont testé sur trois questions. Parmi les mesures figuraient l'étayage des affirmations par les sources, l'utilité des fragments trouvés et la présence d'une réponse à chaque sous-question de l'utilisateur.

Imaginez un employé qui demande quand il faut fournir un certificat médical. La recherche ramène un document général sur les congés, où les arrêts maladie ne sont évoqués qu'en passant. Le fragment est pertinent par rapport au sujet et reçoit une évaluation positive. Mais le délai de remise du certificat n'y figure pas. C'est précisément cet écart que masquait la métrique de précision au niveau des fragments entiers.

Pour la question problématique, cette précision était de 100 %, la part de faits utiles au sein du matériel trouvé de 9 % et la couverture des sous-questions de 0 %. Les auteurs ont ensuite vérifié les documents sources : il n'existait effectivement pas de politique distincte sur les arrêts maladie dans le corpus.

L'équipe n'a modifié que le prompt système : elle a exigé de s'appuyer strictement sur les sources, d'ignorer le superflu et de répondre sur le fond. Sur la question de l'évaluation des employés, la part d'affirmations étayées est passée de 83 % à 87 %. Sur la question de l'arrêt maladie, elle est tombée de 39 % à 31 %. L'instruction ne pouvait pas ajouter les informations manquantes. L'étape suivante aurait dû être d'enrichir la base et de vérifier la recherche.

Que vérifier avant la mise en production

Dans l'Agent DLC, le point de départ est un ensemble convenu de critères, de seuils et d'exemples de vérification. Par exemple, pour un agent de support, il faut définir quelles affirmations exigent un lien, quand il faut reconnaître l'absence de données et quelles informations sur le client peuvent être utilisées.

Ensuite, l'équipe évalue la version, analyse le cheminement jusqu'à l'erreur, modifie un seul composant et répète la vérification selon les mêmes règles. Cet ordre permet de relier le résultat à une modification précise. Si l'on réécrit le prompt, met à jour la base et change les critères en même temps, il devient beaucoup plus difficile d'expliquer l'évolution de la note.

Il est recommandé d'exécuter chaque exemple plusieurs fois : une même requête peut conduire l'agent à des réponses et à des appels d'outils différents. Les évaluateurs eux-mêmes doivent aussi être vérifiés. Si les réponses sont jugées par un autre modèle, ses notes doivent être comparées à des exemples validés par des humains, et leur dispersion doit être mesurée.

Les critères n'ont pas tous le même poids. La violation de l'interdiction de divulguer les données d'autrui bloque la mise en production. Pour la qualité de la réponse, on peut fixer un seuil d'exécutions réussies. Certains indicateurs peuvent d'abord être simplement observés, jusqu'à ce que l'équipe soit sûre de savoir les mesurer de façon fiable.

Où s'arrêtent les conclusions de l'expérience

Une note élevée d'étayage ne garantit pas non plus une réponse acceptable. Dans un cas, l'agent a affirmé connaître le mode de contact préféré de l'utilisateur. Il ne disposait pas du profil de l'utilisateur : le modèle a combiné des informations issues de différents documents et les a présentées comme un fait personnel. La réponse a obtenu 90 % en étayage, de sorte que ce type d'invention exige une vérification distincte.

L'étude est de portée modeste : trois questions dans une implémentation de démonstration. Ce n'est ni un résultat client ni la preuve que l'approche est prête pour n'importe quel déploiement industriel. Les auteurs préviennent également que les évaluations varient d'une exécution à l'autre.

L'étape pratique pour une équipe consiste à prendre les échecs réels de son agent et à les ajouter à l'ensemble de vérification. Pour chaque cas, déterminer si les sources suffisaient, si les outils ont été utilisés correctement et si des informations inventées sont apparues. Ensuite, corriger la cause identifiée et répéter les exécutions. Les vérifications devraient aussi être lancées selon un calendrier : un modèle externe, une API ou une base de connaissances peuvent changer sans le moindre commit dans votre dépôt.