Le benchmark ThinkingBox de Microsoft révèle l’écart entre les déclarations des agents et la réalité des bases de données

Microsoft a présenté un benchmark fondé sur un conflit persistant : un agent IA peut annoncer une réussite alors que les enregistrements sous-jacents de la base de données indiquent un échec. Le benchmark Microsoft ThinkingBox déplace l’attention des réponses convaincantes vers les changements vérifiés au sein d’applications simulées.

Cette distinction peut sembler limitée, mais elle touche au cœur du débat sur les agents. Les entreprises ne recrutent pas un agent pour décrire un remboursement, une mise à jour ou une réservation. Elles attendent de lui qu’il exécute la transaction sans corrompre les données, ignorer des contraintes ou simplement revendiquer une victoire.

Le benchmark ThinkingBox présente la base de données comme l’arbitre final. Son idée centrale remet en cause les évaluations qui récompensent une réponse finale convaincante sans vérifier l’état résultant du système. Pour les développeurs et les acheteurs en entreprise, cela redéfinit ce que signifie « fonctionner ».

Le benchmark Microsoft ThinkingBox teste le résultat, pas le récit

Le message final d’un agent est un indice de ce qu’il pense avoir accompli, et non une preuve de ce que le logiciel a réellement enregistré.

Les tests traditionnels des modèles de langage comparent généralement une réponse à une réponse attendue. Cette méthode fonctionne pour les questions dont les réponses sont textuelles. Elle devient bien moins utile lorsqu’un modèle doit utiliser un logiciel et modifier des données persistantes.

Un agent peut indiquer à un client qu’une adresse a été mise à jour. Il peut décrire l’adresse correcte et produire une confirmation soignée. Pourtant, l’application peut toujours contenir la valeur d’origine parce que l’appel d’outil a échoué, a ciblé le mauvais enregistrement ou n’a jamais été exécuté.

Le benchmark Microsoft ThinkingBox concentre l’évaluation sur cet écart. Selon sa présentation sur Hugging Face, le benchmark examine si les agents accomplissent des tâches applicatives dont les résultats peuvent être vérifiés par rapport à l’état sous-jacent de la base de données.

L’état de la base de données désigne les enregistrements stockés après la fin d’une interaction. Ces enregistrements constituent un test plus solide que le récit de l’agent, car ils reflètent ce que le système utilisera ultérieurement.

Cette approche rend également les échecs partiels plus visibles. Un agent peut modifier un champ obligatoire tout en en laissant un autre intact. Il peut créer un enregistrement en double au lieu de mettre à jour celui qui existe déjà.

Un évaluateur fondé uniquement sur le texte pourrait accepter la confirmation finale parce qu’elle contient les détails demandés. Un évaluateur fondé sur l’état peut inspecter les enregistrements concernés et déterminer si le résultat demandé existe réellement.

ThinkingBox traite donc la réponse de l’agent et l’état de l’application comme deux sorties distinctes. La première révèle l’interprétation du modèle. La seconde révèle le résultat opérationnel.

Cette séparation est importante, car les agents modernes interviennent souvent à travers plusieurs couches. Un modèle choisit une action, formate des arguments, appelle un outil, reçoit une réponse, puis décide si un travail supplémentaire est nécessaire.

L’échec peut survenir à chaque couche. Le modèle peut choisir le mauvais outil. L’outil peut rejeter la requête. L’application peut n’appliquer qu’une partie du changement. L’agent peut mal interpréter une réponse et s’arrêter trop tôt.

Une évaluation fiable doit observer davantage que la conversation. Elle doit vérifier l’environnement une fois que l’agent a terminé.

Il ne s’agit pas d’une amélioration cosmétique des benchmarks. Cela fait passer l’objectif de « produire une réponse crédible » à « laisser l’application dans le bon état ».

La différence rappelle l’écart entre un test qui vérifie une notification de réussite et un autre qui interroge l’enregistrement de production. Les deux tests peuvent réussir lorsque tout fonctionne. Seul le second détecte une fausse confirmation.

Pour les agents IA, cette fausse confirmation est particulièrement dangereuse. Un langage fluide peut faire paraître une action incomplète définitive, précise et digne de confiance.

Pourquoi les déclarations de réussite des agents mettent les workflows d’entreprise sous pression

Le benchmark relève le niveau d’exigence précisément là où les organisations courent le plus grand risque : les actions qui modifient des enregistrements, des autorisations, de l’argent ou des engagements envers les clients.

Les démonstrations d’agents mettent souvent l’accent sur les progrès visibles. Le modèle ouvre une interface, navigue entre des écrans, saisit des informations et fournit un résumé assuré. Ces actions donnent lieu à des vidéos convaincantes.

Les entreprises ont besoin d’un autre type d’assurance. Elles doivent savoir si le bon enregistrement a été modifié, si les contraintes de politique sont restées intactes et si le résultat peut être audité.

Une recherche échouée entraîne un désagrément. Une modification de compte faussement confirmée crée un problème opérationnel. Le client, l’employé et les logiciels en aval peuvent tous agir sur la base d’informations que la base de données ne confirme pas.

Prenons le cas d’un agent de service client traitant une demande liée à un abonnement. L’agent pourrait expliquer qu’une résiliation est terminée alors que l’abonnement actif reste inchangé.

La conversation immédiate pourrait sembler réussie. Le système de facturation pourrait néanmoins continuer à facturer le client par la suite. Le personnel d’assistance devrait alors traiter un litige créé par la confirmation non étayée de l’agent.

Le même schéma s’applique aux achats. Un agent peut affirmer avoir modifié une adresse de livraison alors qu’il a mis à jour le profil du fournisseur au lieu de la commande en attente. Chaque action d’outil prise séparément peut sembler valide, tandis que le résultat métier demandé reste incomplet.

La santé, les services financiers et l’administration publique ajoutent des conséquences plus strictes. Une déclaration erronée peut affecter l’accès, l’éligibilité ou la conformité. Ces environnements s’appuient déjà sur le rapprochement, car les opérateurs humains et les intégrations logicielles commettent des erreurs.

Les agents IA ajoutent une nouvelle source d’incertitude. Ils peuvent générer une explication cohérente même lorsque leur plan interne diverge de l’état réel du système.

Cela accroît la pression sur les fournisseurs d’agents et les équipes internes de plateforme. Les acheteurs demanderont de plus en plus comment un système vérifie l’achèvement, et pas seulement dans quelle mesure il comprend les instructions.

La réponse ne peut pas reposer exclusivement sur un autre modèle de langage chargé d’évaluer la conversation. Les juges fondés sur des modèles sont utiles pour évaluer une qualité ouverte, mais l’exactitude transactionnelle exige des preuves déterministes chaque fois que possible.

Une vérification déterministe compare un état observable à des conditions explicites. Si la tâche consiste à modifier l’adresse d’un seul client, l’évaluateur peut inspecter cette adresse et confirmer que les enregistrements non concernés sont restés inchangés.

Cette norme exerce également une pression sur les concepteurs de benchmarks. Ils ont besoin d’environnements reproductibles, d’un état inspectable et de définitions de tâches assorties de critères d’achèvement précis.

Ces exigences rendent l’évaluation plus difficile. Elles rendent aussi les résultats plus pertinents pour les déploiements réels.

Les recommandations d’Anthropic sur les agents efficaces distinguent les workflows aux parcours prédéfinis des agents qui dirigent eux-mêmes leur utilisation des outils. Une autonomie accrue augmente le nombre de décisions qui exigent une validation.

Le cadre proposé par ThinkingBox ajoute une conséquence importante. Chaque décision autonome crée une occasion supplémentaire pour le récit de réussite de l’agent de se dissocier de la vérité de l’application.

Les organisations qui explorent un workflow IA devraient donc distinguer l’assistance de l’autorité. Rédiger une mise à jour de statut comporte un risque différent de celui de modifier les enregistrements sources qui la sous-tendent.

Cela ne signifie pas que chaque action d’un agent nécessite l’examen d’un humain. Cela signifie que la méthode de vérification doit correspondre aux conséquences de l’action.

Les tâches à faible risque peuvent tolérer des contrôles légers. Les modifications à fort impact doivent exiger une validation plus solide, des journaux durables et des voies de récupération claires.

Le véritable adversaire est l’achèvement assuré sans vérification

Le conflit central n’oppose pas Microsoft à un autre laboratoire. Il oppose la déclaration assurée d’achèvement de l’agent à un état applicatif vérifiable.

Ce choix est important, car il évite que le sujet ne devienne une nouvelle comparaison de classements de modèles. ThinkingBox met en lumière un problème d’évaluation plus profond qui concerne tous les fournisseurs développant des agents utilisant des outils.

Les modèles de langage sont entraînés à poursuivre les conversations de manière utile. Lorsqu’une action semble réussir, la réponse conversationnelle naturelle consiste à confirmer l’achèvement et à résumer le résultat.

Les systèmes logiciels obéissent à d’autres règles. Une requête peut expirer après avoir atteint le serveur. Un outil peut retourner une réponse syntaxiquement valide qui contient une erreur d’application.

Une mise à jour peut réussir pour un objet et échouer pour un autre. Une transaction peut également être annulée après que le modèle a reçu un signal de réussite intermédiaire.

L’agent doit interpréter correctement ces conditions. Plus important encore, le système qui l’entoure ne doit pas considérer l’interprétation du modèle comme l’autorité finale.

Le benchmark Microsoft ThinkingBox rend cette tension mesurable en comparant les résultats visés aux résultats enregistrés. Cela transforme une préoccupation abstraite de fiabilité en une question concrète de réussite ou d’échec.

L’enregistrement demandé a-t-il été modifié ? L’agent a-t-il créé un doublon indésirable ? A-t-il préservé les champs que l’utilisateur ne lui a jamais demandé de modifier ?

Ces questions révèlent une faiblesse des évaluations fondées uniquement sur les trajectoires. Une trajectoire enregistre les actions qu’un agent a tenté d’effectuer, comme des clics, des appels ou des commandes générées.

Une trajectoire plausible ne garantit pas un résultat correct. Un agent peut suivre des étapes sensées et pourtant s’arrêter après un échec silencieux.

À l’inverse, une trajectoire surprenante peut tout de même produire le bon état. L’évaluation à la fois du chemin et du résultat aide à distinguer une réussite inefficace d’un échec soigneusement présenté.

L’état final devrait revêtir une importance particulière pour les tâches transactionnelles. Les utilisateurs se préoccupent de savoir si le résultat s’est produit, et non de savoir si le raisonnement de l’agent semblait raisonnable.

Cela rappelle les pratiques établies de test logiciel. Les tests unitaires examinent un comportement isolé, tandis que les tests d’intégration vérifient le fonctionnement conjoint de composants connectés.

Les tests de bout en bout exercent un processus complet et vérifient son résultat. Un agent qui utilise une application doit recevoir le même traitement, car sa sortie linguistique ne représente qu’un seul composant.

Le guide de création d’agents d’OpenAI décrit les garde-fous et l’intervention humaine comme des éléments importants des systèmes de production. ThinkingBox renforce l’argument en faveur d’une couche supplémentaire : la vérification des résultats après l’exécution des outils.

La vérification ne doit pas être confondue avec le fait de demander au même modèle s’il a réussi. Cela ne fait que répéter le problème de confiance initial dans une autre invite.

Un modèle plus robuste interroge directement le système faisant autorité. L’application peut renvoyer l’enregistrement stocké, l’identifiant de transaction, le numéro de version ou une autre preuve liée à l’action demandée.

L’agent peut alors comparer cette preuve avec l’objectif. Un service déterministe distinct peut effectuer la comparaison lorsque les conditions sont structurées.

Cette architecture fait de l’achèvement un protocole plutôt qu’une phrase. L’agent propose et exécute le travail, tandis que le système détermine si les postconditions requises sont satisfaites.

Les postconditions sont des faits qui doivent être vrais après la fin d’une opération. Elles peuvent exiger qu’un enregistrement soit modifié, qu’un autre reste intact et qu’un événement d’audit existe.

Lorsque ces conditions échouent, le système doit signaler une action incomplète. Il ne doit pas laisser une réponse fluide transformer l’incertitude en réussite apparente.

Cette conception améliore également la récupération. Un échec vérifié peut déclencher une nouvelle tentative, une escalade, une annulation ou une demande d’informations manquantes.

Un succès non vérifié masque le problème jusqu’à ce qu’un client ou un processus en aval le découvre.

Ce que la vérification en base de données révèle sur la fiabilité des agents

L’évaluation fondée sur l’état révèle des défaillances que la notation des réponses peut manquer, mais elle ne couvre pas toutes les qualités qui rendent un agent sûr.

Son principal avantage est la vérification objective. Les applications structurées stockent souvent les faits exacts nécessaires pour évaluer une tâche.

Un benchmark peut capturer un instantané de la base de données initiale, exécuter l’agent, puis examiner la base de données finale. Il peut comparer des champs sélectionnés tout en recherchant des modifications non intentionnelles.

Cette dernière étape est essentielle. Un agent ne devrait pas obtenir tous les crédits pour avoir satisfait la demande en endommageant des données sans rapport.

Supposons qu’un utilisateur demande de déplacer un rendez-vous. L’état souhaité inclut la nouvelle heure du rendez-vous, mais aussi la préservation du patient, du prestataire et des autres rendez-vous.

Un évaluateur limité pourrait ne vérifier que l’heure demandée. Un évaluateur plus robuste contrôle également les invariants, c’est-à-dire les conditions qui doivent rester vraies tout au long de l’opération.

Les invariants peuvent détecter des mises à jour étendues, la création de doublons, des enregistrements supprimés ou des champs écrasés. Ils aident à distinguer une exécution précise d’un succès accidentel.

Les tests fondés sur l’état peuvent aussi révéler des problèmes d’idempotence. Une action idempotente produit le même résultat attendu lorsqu’elle est répétée, sans créer d’effets en double.

Les agents réessaient fréquemment après des réponses ambiguës des outils. Sans opérations idempotentes ou identifiants de requête uniques, une nouvelle tentative peut créer deux commandes, deux tickets ou deux remboursements.

L’état final de la base de données rend ces doublons visibles. Une évaluation conversationnelle pourrait les ignorer, car l’agent ne décrit qu’une seule action achevée.

Les contrôles de base de données facilitent aussi la classification des erreurs. Les développeurs peuvent séparer les erreurs de planification, les échecs d’exécution et les arrêts prématurés.

Une erreur de planification sélectionne la mauvaise opération. Un échec d’exécution survient lorsque l’opération sélectionnée ne se termine pas. Un arrêt prématuré se produit lorsque l’agent ne vérifie pas le résultat avant de déclarer un succès.

Ces catégories conduisent à des correctifs différents. De meilleurs prompts peuvent améliorer la planification. De meilleurs schémas d’outils peuvent réduire les requêtes mal formées.

Des réponses d’erreur plus explicites peuvent améliorer la gestion de l’exécution. Des contrôles de relecture obligatoires peuvent réduire les achèvements prématurés.

La contribution plus large du benchmark est donc diagnostique. Il peut aider les équipes à localiser le point où une exécution qui semble réussie devient un état incorrect de l’application.

Pourtant, la vérité de la base de données n’est pas toute la vérité. L’état final peut être correct même si l’agent a enfreint une politique, exposé des informations sensibles ou suivi un chemin inutilement risqué.

Un agent pourrait obtenir l’enregistrement souhaité en utilisant des identifiants dépassant son autorité prévue. Il pourrait placer des données confidentielles dans un journal ou un prompt de modèle.

La base de données pourrait malgré tout sembler parfaite ensuite. Un évaluateur fondé uniquement sur l’état manquerait la défaillance de sécurité, à moins que le benchmark n’inspecte également les autorisations, les traces et les flux d’information.

Le profil de risque lié à l’IA du NIST encourage les organisations à évaluer les risques tout au long de la conception, du déploiement et de l’exploitation. Cette vision plus large reste nécessaire pour les systèmes d’agents.

L’évaluation en base de données dépend également de la conception des tâches. Les chercheurs doivent définir le résultat correct avec une précision suffisante pour pouvoir l’encoder.

Certaines tâches métier admettent plusieurs résultats légitimes. Les stocks, les politiques, les préférences des utilisateurs et le calendrier peuvent modifier ce qui est considéré comme correct.

Un benchmark reposant sur un instantané fixe peut mesurer la cohérence dans des conditions contrôlées. Il ne peut pas représenter automatiquement toutes les ambiguïtés d’une organisation en production.

Il existe aussi un risque d’optimisation pour le benchmark. Un agent pourrait apprendre des schémas efficaces dans les applications simulées sans devenir plus fiable ailleurs.

Cette préoccupation s’applique à la plupart des benchmarks. Elle devient plus sérieuse lorsque les tâches du benchmark ressemblent à un ensemble restreint d’interfaces ou de schémas de base de données.

Les résultats de ThinkingBox doivent donc être lus comme des éléments de preuve dans l’environnement testé. Ils ne doivent pas devenir des certificats universels de fiabilité.

La conclusion la plus solide est plus limitée et plus utile. Si un agent échoue à des tâches contrôlées dont les résultats sont directement vérifiables, les équipes ne devraient pas faire confiance à ses affirmations non vérifiées dans des systèmes aux enjeux plus élevés.

ThinkingBox expliqué à travers une architecture de déploiement réelle

La leçon pratique est simple : les agents de production ont besoin d’une couche de validation indépendante entre l’exécution des outils et la confirmation à l’utilisateur.

Un flux de travail sûr commence par la traduction de la demande de l’utilisateur en critères d’acceptation explicites. Ces conditions doivent identifier l’objet cible, la modification demandée, les champs protégés et les preuves acceptables.

L’agent choisit ensuite et appelle l’outil requis. L’outil doit renvoyer des informations structurées plutôt qu’un vague message de réussite.

Les réponses utiles comprennent des identifiants d’enregistrement, des versions mises à jour, des nombres de lignes affectées et des codes d’erreur. Ces détails aident le système à relier une action à un résultat précis.

Après l’exécution, le système doit relire l’état faisant autorité. Cette lecture peut passer par un point de terminaison de vérification dédié, avec des autorisations plus limitées que l’outil d’action principal.

Le vérificateur compare le résultat stocké aux critères d’acceptation. Il doit également tester les invariants importants et rechercher les effets secondaires non intentionnels.

Ce n’est qu’alors que l’interface doit afficher une confirmation finale. Si la vérification échoue, l’agent doit indiquer ce qui reste incomplet et ce qu’il fera ensuite.

Ce modèle réduit le risque que la confiance conversationnelle dépasse les preuves opérationnelles. Il produit aussi des enregistrements d’audit que les ingénieurs peuvent examiner après un incident.

Un exemple de support client montre comment les éléments s’articulent. Un utilisateur demande à un agent de modifier l’adresse de livraison d’une commande existante.

Les critères d’acceptation identifient la commande et la nouvelle adresse attendue. Ils exigent également que le profil client et les autres commandes restent inchangés.

L’agent appelle l’outil de mise à jour de commande. L’application renvoie l’identifiant de la commande et une nouvelle version de l’enregistrement.

Le vérificateur lit cette commande dans la base de données faisant autorité. Il contrôle l’adresse, la version de l’enregistrement, l’état de la commande et les champs protégés.

Si toutes les conditions sont remplies, l’agent confirme la modification. Si l’adresse est restée inchangée, le système indique que la mise à jour n’a pas abouti.

La même conception peut prendre en charge l’approbation humaine. Une opération sensible peut être suspendue après la planification et avant l’exécution.

Une autre opération peut s’exécuter automatiquement mais nécessiter une revue humaine lorsque le résultat de la vérification est ambigu.

La frontière importante n’est pas « humain » contre « autonome ». C’est « vérifié » contre « supposé ».

Cette conception prend également en charge l’observabilité, c’est-à-dire la capacité de comprendre un système grâce à ses sorties, ses traces et ses signaux internes. Les équipes doivent voir ce que l’agent avait l’intention de faire, ce qu’il a tenté, ce qu’il a observé et ce qu’il a finalement modifié.

Une piste d’audit compacte peut enregistrer la demande initiale, l’action choisie, les arguments, la réponse de l’outil, la requête de vérification et la décision finale.

Cette séquence facilite bien davantage le débogage qu’une transcription seule. Elle peut révéler si le modèle a mal compris la tâche ou si l’application a rejeté une requête correcte.

L’écosystème d’agents de Microsoft comprend lui-même des frameworks pour orchestrer l’utilisation d’outils et de multiples composants. Quel que soit le framework, la leçon de ThinkingBox reste la même.

L’orchestration ne garantit pas la correction. Davantage d’agents, d’outils ou d’étapes de planification peuvent accroître les capacités tout en multipliant les frontières de défaillance.

Les développeurs doivent maintenir la vérification indépendante du composant évalué. Si le même agent sélectionne l’action puis définit le succès a posteriori, il peut rationaliser un résultat incomplet.

Les contrôles indépendants n’ont pas besoin d’être complexes. Une requête de base de données et un petit ensemble d’assertions peuvent fournir des preuves plus solides qu’un autre long prompt de modèle.

Les équipes peuvent également stocker ces assertions comme des tests réutilisables. Lorsque les prompts, les modèles, les outils ou les politiques évoluent, les mêmes tâches peuvent mesurer si la fiabilité s’est améliorée.

Cela crée un pont pratique entre l’évaluation de l’IA et l’assurance qualité logicielle conventionnelle. Le comportement des agents reste probabiliste, mais les résultats métier peuvent souvent être vérifiés de manière déterministe.

Une base de connaissances technique consultable peut préserver les définitions de tâches, les traces de défaillance et les décisions de remédiation. Ce contexte aide les équipes à reconnaître des schémas de défaillance récurrents.

Le résultat devrait être un processus de publication qui traite les modifications des agents comme des modifications d’application. Les équipes doivent tester des flux de travail représentatifs, examiner les effets secondaires et conserver des preuves pour les régressions.

Ainsi expliqué, ThinkingBox ne se résume pas à un score unique. Il s’agit d’intégrer la vérité opérationnelle au contrat de l’agent.

Ce qu’il faut surveiller après le benchmark Microsoft ThinkingBox

Le prochain test sera de savoir si l’évaluation fondée sur l’état devient une exigence de déploiement, et pas seulement un nouveau classement de recherche.

Le premier signal sera une couverture plus large des tâches. Un benchmark utile nécessite des applications variées, des opérations en plusieurs étapes, des échecs récupérables et des tâches comportant des contraintes légitimes.

Une extension renforcerait l’affirmation selon laquelle l’évaluation ancrée dans les bases de données se généralise aux flux de travail métier. Une couverture étroite limiterait les conclusions aux environnements testés.

Le deuxième signal sera de savoir si les plateformes d’agents exposent la vérification comme une fonctionnalité standard. Les appels d’outils reçoivent déjà une attention considérable dans les API de modèles et les frameworks d’orchestration.

La question plus difficile est ce qui se passe après le retour d’un outil. Les plateformes peuvent exiger des preuves, prendre en charge des vérifications de postconditions et distinguer une exécution « tentée » d’une exécution « vérifiée ».

Cette distinction devrait apparaître dans les interfaces de développement et les produits destinés aux utilisateurs. Un système ne devrait pas utiliser la même confirmation visuelle pour une demande prise en compte et un résultat vérifié.

Si les plateformes adoptent ces modèles, ThinkingBox aura influencé l’architecture de déploiement. Si elles continuent à traiter le message final du modèle comme un achèvement, l’avertissement central du benchmark restera sans réponse.

Le troisième signal sera la reproduction indépendante. Microsoft et la publication de Hugging Face fournissent le cadrage, mais des équipes externes doivent tester différents modèles et piles d’agents.

La reproduction peut montrer si les défaillances proviennent principalement du raisonnement du modèle, de la conception des outils, du retour de l’application ou de la configuration de l’évaluation.

Elle peut également tester si des interventions simples améliorent les résultats. La relecture obligatoire de l’état, des schémas plus robustes, des identifiants de transaction et une meilleure gestion des erreurs sont tous des candidats plausibles.

Des résultats indépendants renforceraient la valeur du benchmark, surtout s’ils rapportent les trajectoires complètes et les changements d’état. L’absence de détails d’implémentation rendrait les comparaisons moins fiables.

Les acheteurs doivent également surveiller les métriques que les fournisseurs choisissent de publier. Un unique taux de réussite ne peut pas expliquer si les échecs étaient inoffensifs, récupérables ou destructeurs.

Des rapports plus informatifs distingueraient l’achèvement correct, l’achèvement partiel, la fausse confirmation, les effets secondaires non intentionnels et le refus sûr.

La fausse confirmation mérite une attention particulière. Elle combine une défaillance opérationnelle avec une communication trompeuse, rendant l’erreur plus difficile à détecter pour les utilisateurs.

Les équipes devraient poser une question directe aux fournisseurs : quelles preuves indépendantes étayent chaque message d’achèvement ?

Une réponse crédible devrait identifier le système faisant autorité, les conditions vérifiées et la réponse lorsque la vérification échoue. « Le modèle vérifie son travail » ne suffit pas.

Le benchmark Microsoft ThinkingBox n’établit pas que les agents sont inutilisables. Il établit une définition du succès plus exigeante et plus pratique.

Les agents peuvent encore apporter une valeur substantielle lorsque les tâches sont bien délimitées, les outils bien conçus et les résultats vérifiés. Leur langage devrait refléter la solidité des preuves disponibles.

Le secteur a consacré des efforts considérables à apprendre aux agents comment agir. La prochaine étape doit apprendre aux systèmes à déterminer quand une action est réellement terminée.

Ce changement aura des répercussions sur les benchmarks, les API, la conception des interfaces et les achats. Il rendra également les démonstrations moins théâtrales et plus utiles.

Pour les développeurs, l’action immédiate consiste à examiner un flux de travail qui fait actuellement confiance à la réponse finale d’un agent. Identifiez l’enregistrement de référence et définissez les postconditions qui prouvent l’achèvement.

Pour les acheteurs, demandez un exemple d’exécution ayant échoué en complément de la démonstration réussie. Vérifiez si le produit détecte l’échec avant l’utilisateur.

Pour tous ceux qui utilisent des agents, gardez à l’esprit le conflit central du benchmark. Le benchmark Microsoft ThinkingBox pose une question à laquelle tout système de production devrait répondre : lorsque l’agent affirme avoir terminé, que dit la base de données ?