Skip to content

Wie man Multi-Agenten-Systeme evaluiert

Ein praktischer Leitfaden zur Evaluation von Multi-Agenten-LLM-Systemen, zur Zuordnung von Fehlern zum verantwortlichen Agenten und zur Übergabe, zur Durchsicht des Interaktionsgraphen und zur Bewertung jedes Agenten und des Teams.

Ein Multi-Agenten-System sind mehrere LLM-Agenten (ein Planer, ein Coder, ein Reviewer und so weiter), die an einer Aufgabe zusammenarbeiten. Es zu evaluieren bedeutet mehr, als die endgültige Antwort zu bewerten, denn die Fehler, die zählen, passieren zwischen Agenten: eine fallengelassene Einschränkung bei einer Übergabe, der falsche Agent übernimmt, ein Team, das seine Arbeit nie überprüft. Die nützliche Beurteilungseinheit ist, welcher Agent, welcher Schritt und welche Übergabe. Potato ist ein Open-Source-Werkzeug für die menschliche Evaluation von Multi-Agenten-Läufen, mit einem zweckgebauten Satz von Annotationsoberflächen für die Teamstruktur.

Ein Multi-Agenten-System bedeutet hier einen von einem LLM gesteuerten Workflow, in dem distinkte Agenten, jeder mit einer Rolle, Nachrichten austauschen und die Kontrolle übergeben. Forschung dazu, warum diese Systeme scheitern (die MAST-Taxonomie, Why Do Multi-Agent LLM Systems Fail?), zeigt, dass ein großer Anteil der Fehler agentenübergreifend ist: Spezifikationsprobleme, Fehlausrichtung zwischen Agenten und fehlende Verifikation. Ein flaches Transkript verbirgt genau das.

Warum reicht die Evaluation eines einzelnen Agenten nicht aus?

Wenn du einen Agenten evaluierst, beurteilst du eine einzelne Sequenz aus Gedanken, Tool-Aufrufen und Beobachtungen. Ein Team fügt Fehlermodi hinzu, die nur zwischen Agenten existieren:

  • Übergabeverlust: Agent A kennt eine Einschränkung, die Agent B nie erhält.
  • Fehlzuordnung: Der Lauf scheitert, aber der verantwortliche Agent liegt vor der Stelle, an der der Fehler auftrat.
  • Koordinationsfehler: Jeder Agent ist einzeln kompetent, doch das Team dreht sich im Kreis, gerät ins Stocken oder verifiziert nie.
  • Ressourcen-Konkurrenz: Zwei Agenten berühren gleichzeitig dasselbe Tool oder dieselbe Datei und geraten in einen Deadlock.

Nur die endgültige Ausgabe zu bewerten sagt dir, dass das Team scheiterte, nicht wo. Die Zuordnung ist es, die die Daten zum Debuggen oder Trainieren nützlich macht.

Wie ordne ich einen Multi-Agenten-Fehler zu?

Die Literatur zur Fehlerzuordnung (Zhang et al., Which Agent Causes Task Failures and When?, ICML 2025) fasst das Label als Tripel: der verantwortliche Agent, der ausschlaggebende Schritt und ein Grund. In Potato befüllt das failure_attribution-Schema die Agenten- und Schrittauswahl aus dem Trace selbst, sodass die annotierende Person aus Agenten und Schritten wählt, die tatsächlich vorkamen:

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

Das Outcome-Schema mit der Zuordnung zu kombinieren bedeutet, dass das Tripel nur bei Läufen erhoben wird, die tatsächlich gescheitert sind.

Wie prüfe ich die Teamstruktur, nicht nur das Transkript?

Zwei Oberflächen machen die Struktur sichtbar. Der Interaktionsgraph stellt Agenten als Knoten und Übergaben als Kanten dar, und die annotierende Person markiert den kritischen Pfad und kennzeichnet problematische Kanten. Das Übergabe-Review macht jede Kontrollübergabe zu einer Karte, um Fehlausrichtung zu kennzeichnen und die Qualität zu bewerten:

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

Zur Bewertung bewertet die agent_scorecard jeden Agenten nach Rollentreue, Beitrag und Koordination und bewertet das Team nach seinen eigenen Dimensionen, sodass ein starker einzelner Agent in einem schlecht koordinierten Team in den Zahlen sichtbar wird.

Welche Methode sollte ich verwenden?

  • Eine Pipeline debuggen: Beginne mit dem Interaktionsgraphen und der Fehlerzuordnung, um zu lokalisieren, wo Läufe brechen.
  • Orchestrierungsmuster vergleichen: Füge die Scorecard hinzu, um sequenzielle vs. hierarchische vs. Gruppenchat-Designs bei denselben Aufgaben zu bewerten.
  • Trainings- oder Reward-Daten erstellen: Tagge Fehler auf Schritt-Granularität mit den MAST-Modi (über trajectory_eval), sodass die Labels am handelnden Agenten und Schritt hängen.
  • Nebenläufigkeitsfehler: Nutze die Tool-Konkurrenz-Zeitleiste, um Deadlocks und Races abzufangen, die ein Transkript nicht zeigen kann.

Miss die Übereinstimmung bei der Zuordnung genauso, wie du es für jedes subjektive Label tun würdest; siehe Inter-Annotator-Übereinstimmung.

Weiterführende Lektüre