Technisches Resümee: Counsel – Ein Meta-Evaluations-Datensatz für agentische Aufgaben

Problemstellung

Da agentische Systeme zunehmend zur Bewältigung komplexer, mehrstufiger Aufgaben eingesetzt werden, ist die Evaluierung ihrer Ausführungstrajektorien zu einem kritischen Engpass geworden. Die menschliche Annotation einer einzelnen Agenten-Trajektorie auf populären Benchmarks (z. B. SWE-bench) kann Stunden dauern, was die Skalierung von Evaluierungen zur Leistungsmessung oder zur Kuration von Trainingsdaten erschwert. Infolgedessen hat sich das Feld hin zu automatisierten Ansätzen entwickelt, insbesondere zum LLM-as-a-Judge (LLMJ), um Agenten sowohl auf Prozessebene (Schritt-für-Schritt) als auch auf Ergebnisebene zu kritisieren.

Es besteht jedoch eine signifikante Lücke: Während LLMJs weit verbreitet für die Datenkuration, das Training und den Einsatz genutzt werden, wird die Validität ihrer Kritiken selten gemessen. Bestehende Meta-Evaluationsbemühungen beschränken sich typischerweise auf den Vergleich finaler Urteile (Scores/Präferenzen) gegenüber dem menschlichen Ground Truth. Es fehlt ihnen an granularen, prozessbezogenen Daten, um zu bestimmen, ob ein LLMJ korrekt identifiziert hat, wo ein Fehler auftrat und ob seine Begründung für diesen Fehler fundiert war. Das Fehlen solcher Meta-Evaluationsdaten behindert die Fähigkeit, LLMJs direkt zu kalibrieren, zu verbessern oder darauf zu trainieren, diagnostisches Feedback von höherer Qualität zu erzeugen.

Methodik

Die Autoren führen Counsel ein, den ersten öffentlichen Datensatz von Meta-Evaluations für agentische Aufgaben. Die Konstruktion des Datensatzes erfolgt über eine dreistufige Pipeline:

1. Generierung von Agenten-Trajektorien

Die Autoren generierten Agenten-Trajektorien unter Verwendung von Open-Weight-Modellen über zwei unterschiedliche Benchmarks hinweg:

• $\tau$-bench (Retail): Eine Benchmark für den Kundensupport, die Multi-Turn-Interaktionen zwischen Tool, Agent und Nutzer simuliert. Die Autoren verwendeten den Retail-Subset (115 Aufgaben).
• DA-Code: Eine Benchmark für die datenwissenschaftliche Codegenerierung, die komplexe Workflows (Bereinigung, Analyse, Modellierung) in einer Sandbox-Umgebung umfasst. Die Autoren verwendeten die Subsets „Data Insights“ und „Data Manipulation“ (50 Aufgaben).

Agenten-Modelle: Um heterogene Fehlermodi zu gewährleisten, wurden die Trajektorien mit folgenden Modellen generiert:

• GPT-OSS-20B: Ein 20B-Parameter Mixture-of-Experts (MoE) Modell mit mittleren Reasoning-Fähigkeiten.
• Qwen3-235B-A22B-Instruct-2507: Ein 235B-Parameter MoE Modell ohne explizites Reasoning (System 1 Denken).

2. Generierung der Richter-Kritik (Judge Critique)

Jeder Schritt (Span) der Agenten-Trajektorien wurde von Open-Weight-LLMJs evaluiert. Die Richter erhielten denselben Kontext, der dem Agenten zum Zeitpunkt des Schritts zur Verfügung stand (keine Informationen über die Zukunft) und hatten die Aufgabe:

• Zu identifizieren, ob in dem aktuellen Schritt ein Fehler aufgetreten ist.
• Eine prägnante, menschenlesbare Kritik bereitzustellen, die den Fehler erklärt.
• Den Fehlertyp zu kategorisieren (z. B. Reasoning, Tool-Nutzung, Workflow).

Richter-Modelle: Um eine systematische Variation zu induzieren, setzten die Autoren folgende Modelle ein:

• GPT-OSS-120B: Evaluiert sowohl in Low- als auch in High-Reasoning-Settings.
• Qwen3-235B-A22B-Instruct-2507: Verwendet als Non-Reasoning-Baseline.
• Die Studie beinhaltete Same-Family- (z. B. GPT bewertet GPT) sowie Cross-Family-Paarungen, um Self-Preference-Bias zu analysieren.

3. Menschliche Meta-Evaluation

Menschliche Annotatoren (drei erfahrene Data Science Professionals mit über 10 Jahren Erfahrung) überprüften die Outputs der Richter. Entscheidend ist, dass die Annotatoren Zugriff auf die vollständige Trajektorie (vergangene und zukünftige Schritte) hatten, im Gegensatz zu den Richtern, die nur den aktuellen Kontext sahen.

Annotationsschema: Annotatoren klassifizierten jeden markierten Span in eine der drei Kategorien:

1. Spot on: Der Fehlerort ist korrekt und die Begründung ist korrekt.
2. Korrekter Ort, aber schlechte Begründung: Der Fehlerort wurde korrekt identifiziert, aber die Erklärung ist fehlerhaft oder unzureichend.
3. Hätte nicht markiert werden dürfen: Der Richter hat fälschlicherweise einen Fehler identifiziert (sowohl Ort als auch Begründung sind falsch).

Die Annotatoren erreichten ein Krippendorff's $\alpha$ von 0,78, was auf eine hohe Inter-Annotator-Übereinstimmung hindeutet.

Zentrale Beiträge

1. Counsel-Datensatz: Ein öffentlich zugänglicher, permissiv lizenzierter Datensatz, der 1.131 menschliche Meta-Annotationen von Richter-Kritiken über 225 einzigartige Agenten-Trajektorien enthält.
2. Granulare Meta-Evaluation: Im Gegensatz zu bisherigen Arbeiten, die sich auf finale Scores konzentrieren, liefert Counsel Labels sowohl für die Fehlerlokalisierung als auch für die Qualität der Begründung, was die Evaluierung des diagnostischen Nutzens von LLMJs ermöglicht.
3. Open-Weight-Ökosystem: Die gesamte Pipeline (Agenten, Richter und Datensatzgenerierung) basiert auf Open-Weight-Modellen, was eine breite Nutzung durch die Community und Reproduzierbarkeit ermöglicht.

Ergebnisse und Analyse

Die Autoren präsentieren mehrere zentrale Erkenntnisse aus der Analyse des Datensatzes:

• Varianz der Richter-Performance:
  • Reasoning-Aufwand: Richter mit höherem Reasoning-Aufwand (GPT-OSS-120B:high) erreichten eine signifikant bessere Übereinstimmung mit Menschen als ihre Low-Reasoning-Pendants. Der stärkste Richter erreichte eine Übereinstimmung von ~88 % bei der Fehlerlokalisierung und ~65 % bei der Qualität der Begründung.
  • Domänenspezifität: Die Präzision der Kritik variierte je nach Domäne. So erreichte Qwen3 eine „Spot on“-Präzision von 43 % bei DA-Code, aber 63 % bei $\tau$-bench retail, was darauf hindeutet, dass die Effektivität eines Richters umgebungsabhängig ist.
• Self-Preference Bias: Die Studie untersuchte, ob Richter gegenüber Agenten derselben Modellfamilie wohlwollender waren. Statistische Tests (einseitige Normaltests für Proportionen) ergaben keinen signifikanten Self-Preference Bias bei keinem der evaluierten Richter.
• Fehlerlokalisierung vs. Recall: Das Design des Datensatzes priorisiert Präzision (Überprüfung nur markierter Fehler) gegenüber Recall. Obwohl der Datensatz relative Recall-Vergleiche ermöglicht (durch den Vergleich von True Positives zwischen Richtern), misst er nicht die Rate, mit der Richter bestehende Fehler nicht erkennen.

Bedeutung und Ansprüche

Das Paper positioniert Counsel als fundamentale Ressource für die rigorose Untersuchung und Verbesserung von LLM-basierten Evaluatoren. Die Autoren behaupten, dass der Datensatz drei primäre Anwendungsfälle ermöglicht:

1. Evaluierung der Kritikqualität: Über die Übereinstimmung finaler Scores hinausgehend, um zu beurteilen, ob Richter Fehler korrekt lokalisieren und qualitativ hochwertige Begründungen liefern.
2. Training von Meta-Richtern: Optimierung von Modellen, die Outputs von Richtern bewerten, ranken oder filtern, um qualitativ hochwertigere Kritiken auszuwählen.
3. Training von Richtern: Verwendung von Meta-Annotationen als Supervision oder Reward-Signale, um Richter direkt für eine bessere Generierung von Kritiken zu optimieren.

Die Autoren betonen, dass Counsel zwar die Kalibrierung und das Training automatisierter Evaluatoren unterstützt, es jedoch dazu bestimmt ist, die menschliche Beurteilung zu ergänzen, nicht zu ersetzen. Sie weisen auf Limitationen hin, darunter den Fokus auf Präzision statt Recall und die Beschränkung auf zwei spezifische agentische Domänen (Retail und Coding), was die Generalisierbarkeit auf andere Aufgabentypen einschränken könnte.

Ein vorläufiges Experiment im Paper zeigt, dass die Verwendung der Counsel-Meta-Annotationen als Few-Shot In-Context-Beispiele die Leistung eines Agenten in einer Schleife verbessern kann, insbesondere wenn „Spot on“-Feedback an einen Guardrail-Richter gegeben wird, wenngeeignet die Effektstärken generell gering waren.