Comment vérifier qu’un agent IA n’a pas d’erreurs : évaluations et révision par des humains

Un agent d’IA qui lit des documents ou répond aux questions se trompera parfois. La question importante n’est pas de savoir s’il commet des erreurs, mais avec quelle fréquence, dans quels cas, et si quelqu’un les remarque avant que l’erreur n’atteigne un client ou un registre. Pour y répondre, il faut deux éléments : un ensemble d’évaluation en qui on a confiance et une étape d’évaluation intégrée au flux de travail.

Commencez par un ensemble de test issu de vos propres données

Les benchmarks génériques vous indiquent comment un modèle se comporte sur des tâches appartenant à d’autres. Ils ne disent pas grand-chose sur vos certificats de fournisseur ou vos modèles de contrat. Le premier résultat attendu de toute automatisation IA sérieuse doit être un ensemble de test constitué de cas réels :

• De 50 à 200 exemples réels pour commencer, plus pour les processus impliquant de nombreux types de documents ;
• La réponse correcte pour chacun, notée par la personne qui effectue le travail actuellement ;
• Cas difficiles inclus délibérément : scans de mauvaise qualité, notes manuscrites, champs manquants, documents dans une autre langue, deux documents agrafés en un seul PDF ;
• Une note indiquant quels erreurs sont coûteuses et lesquelles ne sont que gênantes.

Les données personnelles dans l’ensemble de test doivent être minimisées ou masquées, et l’ensemble lui-même stocké selon les mêmes règles d’accès que les documents originaux.

Mesurer ce qui compte vraiment

Un seul chiffre d’exactitude cache les échecs qui vous préoccupent. Décomposez le résultat :

• Exactitude au niveau des champs pour l’extraction : le numéro de facture, la date, le montant, le taux de TVA ont-ils été lus correctement ?
• Vérifications de règles pour les tâches de révision : l’agent a-t-il signalé le certificat expiré, la signature manquante, le délai de paiement différent de celui prévu dans le contrat ?
• Alertes fausses : nombre de documents corrects qui ont été marqués. Trop d’alertes et les utilisateurs cessent de les consulter.
• Abstention : fréquence à laquelle l’agent a répondu « je ne sais pas » au lieu de deviner. Un agent bien conçu s’abstient dans les cas qu’il ne peut pas gérer.

Les règles qui peuvent être vérifiées par du code doivent l’être par du code. Si la question est « la date du certificat est-elle dans le futur ? », comparez les dates dans un programme et utilisez le modèle uniquement pour trouver la date dans le document. Cela suffit à éliminer toute une catégorie d’erreurs.

Exécuter l’évaluation à chaque modification

Les prompts, les modèles, les paramètres d’OCR ainsi que le code de parsing évoluent tout au long de la durée de vie d’un projet. Chaque modification peut résoudre cinq problèmes tout en en créant trois autres. L’ensemble d’évaluation doit être exécuté automatiquement avant toute mise en production, et les résultats doivent être comparés à ceux de la version précédente. Si les performances chutent, la modification est mise en attente.

Il en va de même lors du changement de modèle. Un modèle plus récent ou moins cher n’est pas automatiquement meilleur pour vos documents. Exécutez l’ensemble d’évaluation, comparez les résultats, puis prenez une décision.

Placer une personne là où se trouve le risque

La révision par un humain n’est pas un signe que l’automatisation a échoué. C’est plutôt le moyen d’en tirer les avantages sans risquer l’entreprise en misant sur un modèle spécifique. Une configuration pratique :

• les résultats dépassant un seuil de confiance convenu et ayant passé toutes les vérifications de règles sont traités automatiquement, ou soumis à une vérification rapide ;
• Les résultats incertains, les vérifications échouées et les cas à haute valeur sont envoyés dans une file d’examen, avec le document source affiché à côté des données extraites ;
• Chaque approbation et correction est enregistrée, avec l’identité de la personne qui l’a effectuée et la date ;
• Les corrections sont réintégrées dans l’ensemble de test, de sorte que la prochaine évaluation inclut le cas qui a posé problème.

Le seuil est une décision commerciale. Commencez par des règles strictes, mesurez dans quelle mesure les examinateurs effectuent réellement des modifications, et assouplissez-les uniquement lorsque les chiffres le justifient.

Surveiller en environnement de production

Les données réelles évoluent constamment : un fournisseur modifie son modèle, un scanner est remplacé, un nouveau type de document apparaît. La surveillance par un agent IA doit permettre de connaître au moins la proportion de documents envoyés à l’examen, la proportion de corrections apportées par les examinateurs, les erreurs de traitement et les temps d’attente, ainsi que l’âge du document le plus ancien dans la file d’attente. Une augmentation du taux de corrections est généralement le premier signe qu’il y a eu un changement en amont.

À quoi ressemble un bon système

Vous pouvez, à l’aide de chiffres issus de vos propres données, indiquer avec quelle fréquence l’agent a raison pour chaque champ et chaque règle, ce qui se passe pour les cas où il se trompe, et comment vous détecterez ces changements. Si un fournisseur ne peut pas vous le montrer, vous avez affaire à une démonstration et non à un système en production.

Nous développons cette couche dans le cadre de notre service de démonstration à production ainsi que dans les agents IA pour l’examen de documents. Pour en savoir plus sur l’organisation de ceux qui la développent et en sont responsables, consultez ce qu’est un ingénieur déployé en amont.