Skip to content

Comment évaluer les systèmes multi-agents

Un guide pratique pour évaluer les systèmes multi-agents à base de LLM, attribuer les échecs à l'agent et à la passation responsables, examiner le graphe d'interaction et noter chaque agent et l'équipe.

Un système multi-agents, ce sont plusieurs agents LLM (un planificateur, un développeur, un relecteur, et ainsi de suite) qui coopèrent sur une seule tâche. L'évaluer, c'est plus que noter la réponse finale, car les échecs qui comptent se produisent entre les agents : une contrainte abandonnée lors d'une passation, le mauvais agent qui prend le relais, une équipe qui ne vérifie jamais son travail. L'unité de jugement utile est : quel agent, quelle étape et quelle passation. Potato est un outil open source pour l'évaluation humaine des exécutions multi-agents, avec un ensemble de surfaces d'annotation conçues sur mesure pour la structure d'équipe.

Un système multi-agents désigne ici un flux de travail piloté par un LLM où des agents distincts, chacun avec un rôle, échangent des messages et se transmettent le contrôle. La recherche sur les raisons de l'échec de ces systèmes (la taxonomie MAST, Why Do Multi-Agent LLM Systems Fail?) constate qu'une grande partie des échecs sont inter-agents : problèmes de spécification, désalignement entre agents et vérification manquante. Une transcription à plat masque précisément ceux-là.

Pourquoi l'évaluation d'un agent unique ne suffit-elle pas ?

Lorsque vous évaluez un seul agent, vous jugez une unique séquence de raisonnements, d'appels d'outils et d'observations. Une équipe ajoute des modes d'échec qui n'existent qu'entre les agents :

  • Perte à la passation : l'agent A connaît une contrainte que l'agent B ne reçoit jamais.
  • Erreur d'attribution : l'exécution échoue, mais l'agent responsable se situe en amont de l'endroit où l'erreur est apparue.
  • Échec de coordination : chaque agent est individuellement compétent, et pourtant l'équipe boucle, stagne ou ne vérifie jamais.
  • Contention de ressources : deux agents touchent le même outil ou le même fichier en même temps et se bloquent mutuellement.

Noter uniquement la sortie finale vous dit que l'équipe a échoué, et non où. L'attribution est ce qui rend les données utiles pour le débogage ou l'entraînement.

Comment attribuer un échec multi-agents ?

La littérature sur l'attribution des échecs (Zhang et al., Which Agent Causes Task Failures and When?, ICML 2025) formule l'étiquette comme un triplet : l'agent responsable, l'étape décisive et une raison. Dans Potato, le schéma failure_attribution renseigne les sélecteurs d'agent et d'étape à partir de la trace elle-même, de sorte que l'annotateur choisit parmi les agents et les étapes qui se sont réellement produits :

yaml
annotation_schemes:
  - annotation_type: radio
    name: outcome
    description: "Did the system succeed?"
    labels: [success, failure]
  - annotation_type: failure_attribution
    name: attribution
    description: "If it failed: which agent, which step, and why?"
    steps_key: steps
    agent_key: agent

Associer le schéma de résultat à l'attribution signifie que le triplet n'est collecté que sur les exécutions qui ont réellement échoué.

Comment examiner la structure de l'équipe, et pas seulement la transcription ?

Deux surfaces rendent la structure visible. Le graphe d'interaction rend les agents sous forme de nœuds et les passations sous forme d'arêtes, et l'annotateur marque le chemin critique et signale les arêtes problématiques. L'examen des passations transforme chaque transfert de contrôle en une carte pour signaler les désalignements et évaluer la qualité :

yaml
annotation_schemes:
  - annotation_type: handoff_review
    name: handoffs
    description: "For each handoff: flag any misalignment and rate the quality."
    steps_key: steps
    agent_key: agent
    flags: [info_loss, dropped_constraint, garbling, goal_drift]
    quality_scale: 5

Pour la notation, le schéma agent_scorecard note chaque agent sur la fidélité au rôle, la contribution et la coordination, et note l'équipe sur ses propres dimensions, de sorte qu'un agent individuellement solide au sein d'une équipe mal coordonnée se voit dans les chiffres.

Quelle méthode utiliser ?

  • Déboguer un pipeline : commencez par le graphe d'interaction et l'attribution des échecs pour localiser où les exécutions se brisent.
  • Comparer les modèles d'orchestration : ajoutez la fiche de score pour noter les conceptions séquentielles vs hiérarchiques vs en discussion de groupe sur les mêmes tâches.
  • Constituer des données d'entraînement ou de récompense : marquez les échecs à la granularité de l'étape avec les modes MAST (via trajectory_eval) pour que les étiquettes s'attachent à l'agent en action et à l'étape.
  • Bugs de concurrence : utilisez la chronologie de contention des outils pour détecter les interblocages et les conditions de concurrence qu'une transcription ne peut montrer.

Mesurez l'accord sur l'attribution de la même manière que pour n'importe quelle étiquette subjective ; voir Accord inter-annotateurs.

Pour aller plus loin