Skip to content

Come valutare i sistemi multi-agente

Una guida pratica per valutare i sistemi LLM multi-agente, attribuire le failure all'agente e all'handoff responsabili, rivedere il grafo di interazione e assegnare un punteggio a ogni agente e al team.

Un sistema multi-agente è un insieme di agenti LLM (un planner, un coder, un reviewer, e così via) che cooperano su un unico task. Valutarlo significa più che assegnare un punteggio alla risposta finale, perché le failure che contano accadono tra gli agenti: un vincolo perso durante un handoff, l'agente sbagliato che prende il controllo, un team che non verifica mai il proprio lavoro. L'unità di giudizio utile è quale agente, quale passo e quale handoff. Potato è uno strumento open-source per la valutazione umana dei run multi-agente, con un insieme di superfici di annotazione apposite per la struttura del team.

Un sistema multi-agente qui indica un flusso di lavoro guidato da LLM dove agenti distinti, ciascuno con un ruolo, si scambiano messaggi e si passano il controllo. La ricerca sul perché questi sistemi falliscono (la tassonomia MAST, Why Do Multi-Agent LLM Systems Fail?) rileva che una larga parte delle failure è inter-agente: problemi di specifica, disallineamento tra agenti e verifica mancante. Una trascrizione piatta nasconde esattamente quelli.

Perché la valutazione di un singolo agente non basta?

Quando valuti un singolo agente, giudichi una singola sequenza di pensieri, chiamate di strumenti e osservazioni. Un team aggiunge modalità di failure che esistono solo tra agenti:

  • Perdita di handoff: l'agente A conosce un vincolo che l'agente B non riceve mai.
  • Attribuzione errata: il run fallisce, ma l'agente responsabile è a monte rispetto a dove l'errore è emerso.
  • Failure di coordinamento: ogni agente è individualmente competente, eppure il team va in loop, si blocca o non verifica mai.
  • Contesa delle risorse: due agenti toccano lo stesso strumento o file contemporaneamente e vanno in deadlock.

Assegnare un punteggio solo all'output finale ti dice che il team ha fallito, non dove. L'attribuzione è ciò che rende i dati utili per il debug o l'addestramento.

Come attribuisco una failure multi-agente?

La letteratura sull'attribuzione delle failure (Zhang et al., Which Agent Causes Task Failures and When?, ICML 2025) inquadra l'etichetta come una tripla: l'agente responsabile, il passo decisivo e un motivo. In Potato lo schema failure_attribution popola i selettori di agente e passo dalla traccia stessa, così l'annotatore sceglie tra agenti e passi che sono realmente accaduti:

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

Abbinare lo schema di esito all'attribuzione significa che la tripla viene raccolta solo sui run che hanno effettivamente fallito.

Come rivedo la struttura del team, non solo la trascrizione?

Due superfici rendono visibile la struttura. Il grafo di interazione rende gli agenti come nodi e gli handoff come archi, e l'annotatore segna il percorso critico e contrassegna gli archi problematici. La revisione degli handoff trasforma ogni trasferimento di controllo in una scheda per segnalare il disallineamento e valutare 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

Per il punteggio, lo agent_scorecard valuta ogni agente su fedeltà al ruolo, contributo e coordinamento, e assegna un punteggio al team sulle sue stesse dimensioni, così un singolo agente forte all'interno di un team mal coordinato è visibile nei numeri.

Quale metodo dovrei usare?

  • Debug di una pipeline: inizia con il grafo di interazione e l'attribuzione delle failure per localizzare dove i run si rompono.
  • Confronto di pattern di orchestrazione: aggiungi la scorecard per valutare i design sequenziale vs. gerarchico vs. group-chat sugli stessi task.
  • Costruzione di dati di addestramento o di reward: tagga le failure a granularità di passo con le modalità MAST (tramite trajectory_eval) così le etichette si attaccano all'agente che agisce e al passo.
  • Bug di concorrenza: usa la timeline di contesa degli strumenti per cogliere deadlock e race che una trascrizione non può mostrare.

Misura l'accordo sull'attribuzione nello stesso modo in cui lo faresti per qualsiasi etichetta soggettiva; vedi Accordo tra annotatori.

Approfondimenti