1 points par qlcla123 1 시간 전 | Aucun commentaire pour le moment. | Partager sur WhatsApp

Nous avons mesuré les exécutions en double d’agents dans des traces de benchmarks publics. La méthode consiste à compter les cas où le même outil est appelé deux fois avec les mêmes arguments, avec en plus le même résultat.

Sur 6 780 traces, nous avons relevé 8 042 cas ; en excluant près de la moitié qui correspondaient à des répétitions du type déclaration de fin de tâche, il en restait 4 249. Parmi eux, pour 3 432 appels en double à des outils modifiant l’état, nous avons comparé les ID d’entités présents dans les réponses : dans 159 cas, il a été confirmé que deux entités avaient réellement été créées. Par exemple deux documents avec le même titre, ou quatre feuilles de calcul identiques.

Il y a ici une limite évidente. Tous ces chiffres proviennent de traces de benchmarks. Il s’agit d’enregistrements de 22 modèles résolvant des tâches, pas de services réellement en production. Nous avons passé en revue huit jeux de données publics, et c’était le seul dans lequel ce phénomène pouvait être observé. La plupart des benchmarks sont conçus pour noter l’exactitude, avec une structure où un doublon entraîne une mauvaise réponse.

C’est pourquoi j’aimerais poser la question à celles et ceux qui opèrent réellement ce type de système.

  1. Combien d’outils (ou de serveurs) MCP utilisez-vous connectés ensemble ?

Les deux jeux de données que nous avons observés présentaient un taux de doublons différent d’un facteur 3 (0,80 % contre 2,41 %). Le nombre d’outils variait aussi fortement, 20 contre 523, mais comme la nature des tâches et la configuration des modèles différaient également, nous n’avons pas pu isoler le nombre d’outils comme cause.

Dans le benchmark, en répartissant par nombre de serveurs associés à une tâche, le taux était le plus élevé avec 4 à 5 serveurs (environ 2,5 %), puis diminuait au-delà, selon un motif non monotone. Nous n’avons pas observé de relation simple du type « plus il y a d’outils, plus il y a de doublons ». Je suis curieux de savoir ce qu’il en est en production réelle.

  1. Avez-vous déjà rencontré des exécutions en double ? Comment les avez-vous détectées ?

Dans la plupart des cas que nous avons vus, aucune erreur ne se produisait. Les deux appels renvoyaient 200 et les logs étaient propres ; a posteriori, on ne voyait donc rien en regardant seulement les logs. En pratique, j’imagine que cela se découvre souvent parce qu’un client le signale : est-ce aussi votre cas ?

  1. Les outils que vous utilisez renvoient-ils des ID d’entités dans leurs réponses ?

C’était le point qui permettait de distinguer « appelé deux fois » de « créé deux fois ». Les API de création de documents renvoient généralement un ID, tandis que les envois d’e-mails ne renvoient souvent qu’une chaîne du type « succès ». Sur les 3 197 cas impossibles à trancher, 2 011 correspondaient à cette situation, et 24 types d’outils ne renvoyaient jamais d’ID dans leur réponse.

Je ne cherche pas une réponse définitive, mais plutôt à me faire une idée de l’écart entre les benchmarks et la production réelle. Même de simples retours d’expérience seraient très utiles.

Aucun commentaire pour le moment.

Aucun commentaire pour le moment.