🤖 AI

The Necessity of a Unified Framework for LLM-Based Agent Evaluation

Dieser Artikel argumentiert, dass der derzeitige Mangel an Standardisierung bei der Bewertung von LLM-basierten Agenten, der durch konfundierende Faktoren wie variierende Prompts und Umgebungen verursacht wird, einen einheitlichen Rahmen erfordert, um eine faire, reproduzierbare und strenge Bewertung der Modellleistung sicherzustellen.

Ursprüngliche Autoren: Pengyu Zhu, Li Sun, Philip S. Yu, Sen Su

Veröffentlicht 2026-05-27

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Pengyu Zhu, Li Sun, Philip S. Yu, Sen Su

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Das große Problem: Der „Blindgeschmackstest"

Stellen Sie sich vor, Sie möchten herausfinden, welcher Koch am besten ein bestimmtes Gericht zubereitet. Sie richten einen Blindgeschmackstest ein. Allerdings gibt es einen Haken:

Koch A erhält einen High-End-Profiofen, Premium-Zutaten und einen Sous-Chef, der das Gemüse schneidet.
Koch B erhält einen rostigen Toaster, gefrorene Zutaten und überhaupt keine Hilfe.

Wenn Koch A ein köstliches Mahl zubereitet und Koch B sein Gericht verbrennt, könnten Sie denken, Koch A sei der bessere Koch. Doch in Wirklichkeit lag der Unterschied im Ergebnis nicht nur an den Fähigkeiten der Köche, sondern an den Küchen, in denen sie gearbeitet haben.

Genau dieses Problem identifiziert das Papier bei Large Language Model (LLM) Agents.

Derzeit, wenn Forscher KI-Agenten (KI, die Werkzeuge nutzen, planen und Entscheidungen treffen können) testen, hüllen sie jede KI in eine andere „Küche" (ein sogenanntes Harness). Eine KI erhält vielleicht einen ausgefeilten Prompt, ein intelligentes Speichersystem und eine strenge Werkzeug-Schnittstelle. Eine andere erhält einen einfachen Prompt und eine unübersichtliche Schnittstelle. Wenn die Ergebnisse vorliegen, wissen wir nicht, ob die KI intelligenter ist oder ob sie einfach eine bessere „Küche" erhalten hat.

Die Lösung des Papiers: Eine standardisierte „Rennstrecke"

Die Autoren argumentieren, dass wir zum fairen Vergleich von KI-Modellen ein einheitliches Framework benötigen. Stellen Sie sich dies als den Bau einer einzigen, standardisierten Rennstrecke vor, auf der alle Autos (KI-Modelle) fahren müssen.

Das Auto (Das KI-Modell): Dies ist das, was wir testen wollen. Ist es schnell? Ist es effizient?
Die Strecke (Das Harness & die Umgebung): Dazu gehören die Straßenoberfläche, das Wetter, die Kraftstoffart und die Rennregeln.

Das Papier sagt: Halten Sie die Strecke für alle genau gleich.
Wenn wir die Strecke (die Prompts, die Speicherwerkzeuge, die Art und Weise, wie die KI mit dem Internet interagiert) für jeden einzelnen Test ändern, können wir nicht unterscheiden, ob eine schnellere Zeit darauf zurückzuführen ist, dass das Auto besser ist, oder weil die Straße glatter war.

Was behoben werden muss (die „Strecken"-Teile)

Das Papier zerlegt die „Küche" oder „Strecke" in fünf spezifische Teile, die standardisiert werden müssen, damit sie die Ergebnisse nicht verfälschen:

Die Verkehrsregeln (Inferenz): Manchmal wird eine KI durch einen Sicherheitsfilter blockiert, eine andere nicht, nur weil sie verschiedene Internetanbieter nutzen. Der Test muss sicherstellen, dass die Regeln für alle gleich sind.
Das Handbuch (Prompting): Bei einigen KI-Tests erhält das Modell eine 200-Wörter-Anweisung, während andere ein 2.000-Wörter-Handbuch erhalten, das der KI im Grunde genau sagt, wie sie denken soll. Das Papier sagt: Die Aufgabe darf unterschiedlich sein, aber die Art und Weise, wie die Anweisungen gegeben werden, muss gleich bleiben.
Das Notizbuch (Speicher): Einige KI-Agenten erhalten ein perfekt organisiertes Notizbuch, um vergangene Ereignisse zu merken. Andere erhalten einen chaotischen Stapel Papiere, bei dem alte Informationen zufällig verworfen werden. Der Test muss sicherstellen, dass jede KI die gleiche Art von Notizbuch erhält.
Der Werkzeuggürtel (Werkzeugaufruf): Einige KI-Modelle werden darin geschult, Werkzeuge in einem sehr strengen Format zu verwenden; anderen wird erlaubt, schlampig zu sein. Wenn eine KI scheitert, weil sie ein Komma in einem Werkzeugaufruf vergessen hat, eine andere aber erfolgreich ist, weil der Test nachsichtig war, ist das kein fairer Vergleich.
Die Welt (Umgebung): Das ist ein wichtiger Punkt. Wenn eine KI auf einer „live"-Website getestet wird, könnte sich die Website morgen ändern. Wenn die KI scheitert, weil sich die Website geändert hat, liegt das nicht an der KI. Das Papier argumentiert, dass wir „eingefrorene" Momentaufnahmen der Welt verwenden müssen, damit sich die Umgebung während des Tests nicht ändert.

Wofür dieses Framework NICHT gedacht ist

Die Autoren betonen sehr sorgfältig, wofür dieses Framework nicht gedacht ist:

Es ist nicht darauf ausgerichtet, Innovationen bei realen KI-Produkten zu stoppen. Unternehmen wie Anthropic oder OpenAI sollten weiterhin frei sein, die erstaunlichsten, komplexesten und innovativsten „Küchen" für ihre Produkte zu bauen.
Es ist nicht darauf ausgerichtet, alle KI gleich aussehen zu lassen.
Es ist nur für den wissenschaftlichen Test (die „Prüfung") gedacht.

Stellen Sie sich dies wie den Formel-1-Rennsport vor:

Der Motor (Das KI-Modell): Dies ist das, was die Hersteller verbessern wollen.
Die Vorschriften (Das einheitliche Framework): Die FIA (der Rennsportverband) setzt strenge Regeln für die Reifengröße, den Kraftstoff und die Chassisabmessungen fest.
Warum? Damit wir wissen, wenn ein Auto schneller ist als ein anderes, dass es am Motor liegt und nicht daran, dass ein Team bessere Reifen oder einen anderen Kraftstoff verwendet hat.

Der vorgeschlagene Plan

Das Papier schlägt ein dreiteiliges System vor, um dies zu beheben:

Ein kontrolliertes Substrat: Ein standardisierter „Läufer", der Prompts, Speicher und Werkzeuge für jeden Test konstant hält.
Eine standardisierte Bewertungsmethode: Anstatt nur „Bestanden/Nicht bestanden" zu sagen, müssen wir messen, wie die KI abgeschnitten hat (hat sie zu viele Schritte benötigt? hat sie zu viel Speicher verbraucht?).
Versionskontrolle: Da sich die Technologie schnell entwickelt, muss dieses „Regelwerk" Versionen haben (wie v1.0, v2.0). Wenn sich die Regeln ändern, vergleichen wir keine Ergebnisse aus der alten Version mit denen der neuen Version, genau so, wie wir die Rundenzeit eines Autos von 2020 nicht mit der von 2024 vergleichen, ohne die neuen Regeln zu berücksichtigen.

Zusammenfassung

Das Papier behauptet, dass wir derzeit Äpfel mit Birnen vergleichen, weil jeder KI-Test eine andere Konfiguration verwendet. Um wirklich zu wissen, welche KI die „klügste" ist, müssen wir sie alle in den exakt gleichen Raum stellen, ihnen die exakt gleichen Werkzeuge geben und beobachten, wie sie die gleichen Probleme lösen. Nur dann können wir sagen: „Diese KI ist besser", anstatt: „Diese KI hat ein besseres Setup erhalten."

Technische Zusammenfassung: Die Notwendigkeit eines einheitlichen Rahmens für die Evaluierung agenter Fähigkeiten von LLMs

Problemstellung

Die Evaluierung agenter Fähigkeiten von Large Language Models (LLMs) hat sich zunehmend auf ausführbare Benchmarks verschoben, bei denen Modelle in Agenten-Harnesses (Prompts, Speicher, Schnittstellen für Tools, Parser) gekapselt und in Ausführungsumgebungen platziert werden. Das Papier identifiziert ein kritisches Identifikationsproblem: Wenn zwei LLMs unterschiedliche Scores auf Agenten-Benchmarks erzielen, kann die Varianz nicht zuverlässig den intrinsischen agentenbezogenen Fähigkeiten der Modelle zugeschrieben werden. Stattdessen werden die Scores durch nicht-LLM-Komponenten verfälscht, darunter:

Kompatibilität der Harnesses: Unterschiede in der Prompt-Scaffolding, Planungsstrategien (z. B. ReAct vs. Chain-of-Thought) und Speicherformatierung.
Inferenzvariabilität: providerspezifische Inhaltsmoderation, API-Einschränkungen und engine-spezifische Decodierungsverhalten (z. B. vLLM vs. Transformers).
Diskrepanzen bei der Tool-Aufrufung: Inkompatible Schemadefinitionen, Handhabung von Parametertypen und Parser-Strenge (z. B. regex-basiertes JSON-Parsing vs. natives Funktionsaufrufen).
Umweltdrift: Die Verwendung liveer, dynamischer Umgebungen (z. B. Websuche) führt zu nicht-reproduzierbarem Rauschen, bei dem die Aufgabenlösung vom Zustand des Internets zum Zeitpunkt der Evaluierung abhängt und nicht von der Modellfähigkeit.

Die Autoren argumentieren, dass ohne die Berücksichtigung dieser Störfaktoren Benchmark-Scores die Modellfähigkeit mit Engineering-Entscheidungen im umgebenden Stack vermischen, was vergleichende Analysen zwischen verschiedenen LLMs wissenschaftlich ungültig macht.

Methodik und vorgeschlagener Rahmen

Das Papier schlägt ein einheitliches Evaluierungsframework vor, das auf dem Prinzip der „Variablenkontrolle" basiert, analog zu Windkanaltests in der Aerodynamik oder GPU-Benchmarks in der Hardware. Das Framework zielt nicht darauf ab, alle Agentenprodukte zu standardisieren oder Innovationen in eingesetzten Systemen einzufrieren; vielmehr soll es eine kontrollierte experimentelle Substrat für die spezifische Evaluierung der LLM-Komponente schaffen.

Das Framework besteht aus zwei Kernkomponenten:

1. Kontrolliertes Ausführungs-Substrat

Diese Komponente standardisiert die nicht-LLM-Schichten, die das Modell umgeben, um sicherzustellen, dass sie über alle Evaluierungen hinweg konstant bleiben. Sie schreibt vor:

Feste Harness-Mechanismen: Eine standardisierte Laufzeit für Prompt-Konstruktion, Speicher-Serialisierung und Tool-Dispatch. Das Papier schlägt vor, bestehende allgemeine Scaffolds (z. B. smolagents) als Referenzimplementierung zu übernehmen, um Einheitlichkeit in der Speicherrepräsentation, Fehlerbehandlung und Planungsloops zu gewährleisten.
Deterministische Umgebungen: Ersetzung liveer, dynamischer Umgebungen durch versionsgebundene, snapshot-basierte Umgebungen (z. B. Snapshots von Webinhalten oder simulierte Datenbanken), um Umweltdrift zu eliminieren.
Standardisierte Ein-/Ausgabe-Verträge: Sicherstellung, dass Tool-Definitionen, Parametertypen und Parsing-Regeln über alle Benchmarks hinweg konsistent sind, die auf dem Substrat ausgeführt werden.

2. Prinzipiengeleitete Evaluierungsmethodik

Diese Komponente standardisiert, wie Agentenverhalten gemessen und berichtet wird:

Kanonische Metriken: Überwindung einzelner skalärer Scores hin zu einem mehrdimensionalen Berichtssystem, das Trajektorienkorrektheit, Änderungen des Umgebungszustands und Ressourcennutzung (Token-Kosten, Latenz) abdeckt.
Pareto-Frontier-Analyse: Evaluierung von Modellen basierend auf Dominanz in Bezug auf Korrektheit, Effizienz und Kosten, anstatt eines einzigen aggregierten Scores.
Gemeinsame Fehler-Taxonomie: Etablierung einer einheitlichen Klassifizierung für Agentenfehler (z. B. „Falsche Info", „Ungültiges Format"), um vergleichbare Fehleranalysen über verschiedene Benchmarks hinweg zu ermöglichen.
Versionsgesteuerte Governance: Implementierung eines Versionierungssystems (ähnlich wie MLPerf oder vLLM), bei dem Scores mit der spezifischen Framework-Version gekennzeichnet sind. Dies ermöglicht es, dass sich die Spezifikation mit der Technologie weiterentwickelt, ohne historische Daten zu entwerten, und verhindert die Versteinerung aktueller Konzepte.

Hauptbeiträge

Diagnose verfälschender Varianz: Das Papier kategorisiert systematisch Quellen von Evaluierungsrauschen jenseits des LLM, einschließlich Inferenzkonfiguration, Prompt-Scaffolding, Speichermanagement, Semantik des Tool-Aufrufs und Umweltdynamik. Es liefert konkrete Beispiele (z. B. wie ein strenger Parser im Vergleich zu einem permissiven Tool-Nutzungsscores verändert), um das Ausmaß dieser Effekte zu demonstrieren.
Unterscheidung zwischen Evaluierung und Bereitstellung: Die Autoren klären, dass ein einheitliches Framework für den kontrollierten Vergleich von Modellfähigkeiten gedacht ist, getrennt vom Design eingesetzter Agentenprodukte (wie Claude Code oder Codex), wo Harness-Innovation wünschenswert ist.
Operative Spezifikation: Das Papier skizziert die strukturellen Anforderungen, damit Benchmarks „plug-compatible" mit dem Substrat sind, und definiert ein Tripel aus Instruktionssets ( $I$ ), Tool-Sets ( $T$ ) und Umgebungssets ( $E$ ), die bestimmte strukturelle Constraints erfüllen müssen (z. B. automatisierbare Erfolgskriterien, versionsgebundene Umgebungen).
Governance-Modell: Es wird ein versionsbasiertes Governance-Modell vorgeschlagen, um die Spannung zwischen der Notwendigkeit von Stabilität in der Evaluierung und dem schnellen Tempo der Innovation bei LLM-Agenten zu bewältigen.

Ergebnisse und Evidenz

Das Papier präsentiert keine neuen experimentellen Ergebnisse, die spezifische Modelle vergleichen. Stattdessen leiten sich seine „Ergebnisse" ab aus:

Empirischen Beobachtungen: unter Berufung auf die Holistic Agent Leaderboard [10], die zeigte, dass dasselbe LLM bei Evaluierung unter verschiedenen Harnesses auf demselben Benchmark erheblich unterschiedliche Scores liefert.
Fallstudien:
- Prompt-Scaffolding: Vergleich des ~200-Wörter-BFCL-Prompts mit dem ~2.000-Wörter-smolagents-Scaffold, der zeigt, wie Letzterer explizite Planungs- und Replanungslogik kodiert, die die Leistung künstlich steigert.
- Speicherrepräsentation: Gegenüberstellung strukturierter Speicher-Schritte (smolagents) mit flachen Chat-Verläufen (τ-bench, BFCL), wobei gezeigt wird, wie Fehlermarkierung und Schritt-Typisierung die Wiederherstellungsfähigkeiten beeinflussen.
- Umweltdrift: Analyse von drei Trajektorien aus BrowseComp und BFCL V4, bei denen livee Websuchergebnisse (veraltete Snippets, Anti-Bot-Blockaden, Verschiebungen im Suchindex) dazu führten, dass korrekte Reasoning-Spuren als Fehler markiert wurden, was beweist, dass Scores ebenso den Zustand der Umgebung wie die Fähigkeit des Modells widerspiegeln.

Bedeutung und Behauptungen

Das Papier behauptet, dass der aktuelle Zustand der LLM-Agenten-Evaluierung eine „strukturelle Barriere" für wissenschaftlich interpretierbaren Fortschritt darstellt. Seine Bedeutung liegt in:

Ermöglichung fairer Zuschreibung: Durch Konstanthaltung von Harness und Umgebung erlaubt das Framework Forschern, Leistungsunterschiede strikt dem LLM zuzuschreiben und Modellfähigkeit von Engineering-Aufwand zu trennen.
Reproduzierbarkeit: Es adressiert die „nicht-reproduzierbare" Natur aktueller Agenten-Benchmarks, die durch Umweltdrift verursacht wird, und stellt sicher, dass Scores Eigenschaften des Modells und nicht des Testzeitpunkts sind.
Community-Standardisierung: Es fordert einen Wechsel von maßgeschneiderten, benchmark-spezifischen Stacks zu einer gemeinsamen, versionierten Infrastruktur, ähnlich wie MLPerf die GPU-Benchmarking standardisiert hat.

Die Autoren positionieren diese Arbeit nicht als Einschränkung der Innovation im Agentendesign, sondern als notwendige Voraussetzung für die genaue Messung der agentenbezogenen Fähigkeiten der zugrundeliegenden Modelle, die diese Designs antreiben.