🤖 AI

Toward Scalable Verifiable Reward: Proxy State-Based Evaluation for Multi-turn Tool-Calling LLM Agents

Dieser Beitrag stellt die Proxy-State-basierte Evaluation vor, ein von großen Sprachmodellen gesteuertes Simulationsframework, das eine skalierbare, zuverlässige und skalierbare Evaluation von Agenten für mehrstufige Werkzeugaufrufe ermöglicht, indem es aus Interaktionsspuren strukturierte Proxy-Zustände ableitet und damit eine praktische Alternative zu kostspieligen deterministischen Backends bietet, die sowohl das Modellranking als auch das On-Policy-Training unterstützt.

Ursprüngliche Autoren: Yun-Shiuan Chuang, Chaitanya Kulkarni, Alec Chiu, Avinash Thangali, Zijie Pan, Shivani Shekhar, Yirou Ge, Yixi Li, Uma Kona, Linsey Pang, Prakhar Mehrotra

Veröffentlicht 2026-05-14

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Yun-Shiuan Chuang, Chaitanya Kulkarni, Alec Chiu, Avinash Thangali, Zijie Pan, Shivani Shekhar, Yirou Ge, Yixi Li, Uma Kona, Linsey Pang, Prakhar Mehrotra

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

Stellen Sie sich vor, Sie versuchen, einem neuen Mitarbeiter (dem KI-Agenten) beizubringen, wie er komplexe Kundenanfragen bearbeitet, etwa das Finden des perfekten Schuhpaars oder die Verwaltung eines Bankkontos. Um dies zu tun, benötigen Sie eine Möglichkeit, ihn zu testen.

Der alte Weg: Aufbau einer perfekten, teuren Simulation
Traditionell bauten Unternehmen zur Prüfung dieser KI-Agenten eine Simulation einer „perfekten Welt". Stellen Sie sich dies wie den Bau eines voll funktionsfähigen Modells einer Bank oder eines Geschäfts mit echtem Geld, echtem Lagerbestand und strengen Regeln vor.

Das Problem: Der Bau dieser „perfekten Welt" ist unglaublich teuer und langsam. Es ist, als würde man ein Team von Ingenieuren einstellen, um eine falsche Stadt zu bauen, nur um einen Lieferfahrer zu testen. Wenn Sie den Test ändern möchten (z. B. „Was passiert, wenn der Kunde kein Geld hat?"), müssen Sie den Code der gesamten falschen Stadt neu schreiben. Der Bericht erwähnt, dass ein solches System fast 100.000 Codezeilen und mehr als ein Jahr Arbeit benötigte, nur um die Engine zum Laufen zu bringen.

Der neue Weg: Der „Proxy-Zustand" (Das intelligente Skript)
Die Autoren dieses Papiers schlagen einen intelligenteren, schnelleren Weg vor, der als Proxy-State-basierte Evaluation bezeichnet wird. Anstatt eine falsche Stadt zu bauen, nutzen sie ein Team sehr intelligenter KI-„Regisseure", um ein Stück aufzuführen.

So funktioniert die Analogie:

Das Szenario (Das Skript):
Anstelle einer Datenbank schreiben sie ein detailliertes Skript. Dieses Skript besagt:
- Wer ist der Kunde? (z. B. Sarah, die weiße Schuhe liebt).
- Was ist das Ziel? (z. B. Schuhe finden, die sie sich leisten kann).
- Wie sollte das Endergebnis aussehen? (z. B. Sarah hat 300 $ auf ihrem Konto, hat aber noch nichts gekauft).
Die Schauspieler (Die KI-Simulatoren):
- Der Benutzersimulator: Eine KI spielt die Rolle des Kunden und spricht mit dem Agenten.
- Die Werkzeug-Simulatoren: Andere KIs geben eine Bank oder ein Geschäft vor. Sie haben kein echtes Bankkonto; sie tun nur so, als hätten sie eines, basierend auf dem Skript.
- Der Zustandsverfolger (Der Gedächtnisbewahrer): Dies ist der wichtigste neue Teil. Während das Gespräch stattfindet, beobachtet eine spezielle KI alles und aktualisiert eine „mentale Punktzahl" (den Proxy-Zustand). Sie verfolgt: Hat der Agent nach Geld gefragt? Hat die „Bank" ja gesagt? Wie ist der Kontostand jetzt? Sie baut schrittweise ein Bild der Situation auf, ohne eine echte Datenbank zu benötigen.
Der Richter (Der Regisseur):
Am Ende des Gesprächs betrachtet ein finaler KI-Richter die „mentale Punktzahl" und das Gesprächsprotokoll. Er fragt: „Hat der Agent das im Skript definierte Ziel erreicht?"
- Wenn der Agent die Schuhe gefunden und den Kontostand im „mentalen Punktestand" korrekt aktualisiert hat, besteht er.
- Wenn der Agent Dinge erfunden hat (halluziniert) oder vergessen hat, den Kontostand zu prüfen, fällt er durch.

Warum ist dies besser?

Geschwindigkeit & Flexibilität: Sie müssen keine falsche Bank bauen. Sie schreiben einfach ein neues Skript. Wenn Sie ein anderes Szenario testen möchten, ändern Sie den Text, nicht den Code.
Zuverlässigkeit: Die Autoren testeten dies, indem sie menschliche Experten die Bewertung der KI überprüfen ließen. Sie stimmten den KI-Richtern in über 90 % der Fälle zu.
Training: Da dieses System schnell ist, kann es Tausende von Übungsgesprächen generieren. Der KI-Agent kann aus diesen Übungsrunden lernen (sowohl wenn er mitmacht, als auch wenn er zusieht, wie ein besserer Agent spielt), wodurch er viel schneller intelligenter wird.

Die Ergebnisse
Das Papier testete dieses System mit verschiedenen KI-Modellen. Sie stellten fest, dass:

Intelligente KI-Modelle (oder Modelle, die länger nachdenken, bevor sie antworten) höhere Punktzahlen erreichten.
Das Training der KI mit diesem System sie signifikant besser bei der Problemlösung machte, selbst bei Szenarien, die sie noch nie gesehen hatte.
Das System sehr gut darin war, zu erkennen, wenn die KI lügt oder Fehler macht, mit fast null „falschen" Fehlern aus der Simulation selbst.

Zusammenfassung
Dieses Papier stellt eine Methode vor, um KI-Agenten zu testen und zu trainieren, indem ein „skriptiertes Stück" mit KI-Schauspielern und einem gedächtnisbewahrenden KI-System verwendet wird, anstatt eine massive, teure Simulation der realen Welt zu bauen. Es ist schneller, günstiger und genauso genau, was es Unternehmen ermöglicht, ihre KI-Agenten viel schneller zu iterieren und zu verbessern.

Technische Zusammenfassung: Proxy-State-basierte Evaluation für Multi-Turn-Tool-Calling-LLM-Agenten

Problemstellung

Interaktive Large-Language-Modelle (LLM)-Agenten werden zunehmend in industriellen Workflows (z. B. E-Commerce, Kontoverwaltung) eingesetzt, um Multi-Turn- und Multi-Step-Tool-Calling-Aufgaben zu lösen. Eine effektive Entwicklung erfordert zwei Komponenten: (1) eine stabile Evaluation, die genau widerspiegelt, ob ein Agent Benutzerziele erreicht, und (2) eine on-policy-Datengenerierung, um Lernen aus Interaktion und Umgebungsfeedback zu ermöglichen.

Aktuelle Agenten-Benchmarks (z. B. $\tau$ -bench, $\tau^2$ -bench, AppWorld) nutzen ein „Benchmark-as-Environment"-Paradigma mit einer Final-State-basierten Evaluation. Obwohl dieser Ansatz korrekte Bewertungen von terminalen Datenbankzuständen liefert, anstatt starrer Trajektorien-Matches, setzt er vollständig deterministische Backends voraus. Der Aufbau und die Iteration dieser deterministischen Engines erfordern erheblichen Ingenieursaufwand (z. B. Schema-Design, deterministische Tools, Assertions); einige Benchmarks benötigen Zehntausende Zeilen Code und umfangreiche Unit-Tests. Diese ingenieurtechnische Belastung verlangsamt die Iteration und begrenzt die Skalierbarkeit für industrielle Anwendungen.

Die zentrale Frage lautet: Können wir die Vorteile einer Final-State-basierten Evaluation beibehalten, ohne ein schwerfälliges deterministisches Backend zu bauen?

Methodik: Proxy-State-basierte Evaluation

Die Autoren schlagen Proxy-State-basierte Evaluation vor, ein LLM-gesteuertes Simulationsframework, das die deterministische Datenbank durch einen von einem LLM abgeleiteten „Proxy-Zustand" ersetzt. Das System operiert als „Benchmark-as-Environment" und besteht aus fünf kooperierenden LLM-Komponenten:

Szenario-Spezifikation ( $z$ ): Ein strukturiertes Objekt, das das Benutzerziel, Benutzerfakten, Systemfakten (Initialzustand), den erwarteten finalen Proxy-Zustand und das erwartete Agentenverhalten definiert. Dies ersetzt die Notwendigkeit einer Ground-Truth-Trajektorie.
Reasoning Agent (RA): Das zu evaluierende Modell, das eine ReAct-artige Schleife (Reason $\to$ Act $\to$ Observe) durchläuft, um über Multi-Turn-Dialoge und Multi-Step-Tool-Calls mit der Umgebung zu interagieren.
User Simulator ( $f_{user}$ ): Generiert Benutzeräußerungen, konditioniert auf die Benutzerfakten, Ziele und eine spezifische Persona (z. B. Power-User, verwirrt, mehrdeutig) des Szenarios.
Tool Simulators ( $f_{tool}$ ): Simulieren Tool-Antworten (z. B. Kontoverwaltung, E-Commerce), indem sie basierend auf den Subqueries des RA und den Systemfakten den aktuellen Proxy-Zustand „auslesen" und „beschreiben".
State Tracker ( $f_{state}$ ): Eine LLM-Komponente, die den strukturierten Proxy-Zustand ( $\tilde{s}_{t,k}$ ) aus dem vollständigen Interaktionstrace bis zum Schritt $(t,k)$ ableitet. Im Gegensatz zu schrittweisen Zustandsupdates konditioniert sie auf den gesamten Trajektorien-Präfix, um Robustheit gegen Fehlerakkumulation zu gewährleisten.
LLM Judges:
- Goal-Completion Judge: Bewertet den finalen Proxy-Zustand und die Agentenantwort gegen den erwarteten finalen Zustand und das erwartete Verhalten des Szenarios, um Ergebnisse zu klassifizieren (Ziel erreicht, Benutzerfehler oder Agentenfehler).
- Hallucination Detection Judge: Erkennt, ob der Tool-Simulator oder User Simulator Informationen generiert hat, die mit den Szenario-Beschränkungen inkonsistent sind.

Evaluationsmetriken: Das Framework misst Goal-Completion (GC)-Raten, Benutzer-/Agenten-Fehlerraten und Halluzinationsraten (Tool und Benutzer). Es unterstützt sowohl on-policy-Datengenerierung (für Rejection Sampling Fine-Tuning) als auch off-policy-Datengenerierung (für Supervised Fine-Tuning).

Hauptbeiträge

Formalisierung der Proxy-State-basierten Evaluation: Die Arbeit formalisiert einen praktischen Benchmark, der die Prinzipien der Zustandsbasierten Evaluation bewahrt, ohne ein deterministisches Backend zu erfordern, und dabei einen von einem LLM abgeleiteten Proxy-Zustand nutzt, der aus Interaktionstraces extrahiert wird.
Szenario-Schema und Komponentenarchitektur: Es wird ein spezifisches Szenario-Schema und eine fünfkomponentige LLM-Architektur (Reasoning Agent, User Simulator, Tool Simulators, State Tracker, Judge) eingeführt, die zusammenarbeiten, um komplexe Workflows zu simulieren.
Zuverlässigkeitsframework: Die Autoren definieren Zuverlässigkeitskriterien, einschließlich gebooteter Standardfehler, Halluzinationsraten und der Übereinstimmung zwischen Mensch und LLM-Judge. Sie führen gezielte Ablationsstudien zur Persona-Sensitivität, zur Vollständigkeit von System-/Benutzerfakten und zur Stärke des State Trackers durch.
Skalierbare Datengenerierung: Die Umgebung generiert skalierbare on-policy- und off-policy-Rollouts, die für das Post-Training (SFT/RFT) geeignet sind, und liefert stabile Metriken für den Modellvergleich.

Ergebnisse

Der Benchmark wurde über diverse Modellfamilien (GPT-5, GPT-4o, Gemini-2.5, Qwen3) und Reasoning-Aufwendungen hinweg evaluiert:

Modell-Differenzierung: Die Goal-Completion (GC)-Raten skalieren konsistent mit der Modellstärke und dem Reasoning-Aufwand zur Laufzeit. Beispielsweise erzielt innerhalb der GPT-5-Familie ein höherer Reasoning-Aufwand monotone GC-Gewinne (High: 85,76 % > Minimal: 66,04 %).
Wirksamkeit des Trainings: Das Training des Basismodells Qwen3-30B-A3B in dieser Umgebung verbesserte die Leistung signifikant. Supervised Fine-Tuning (SFT) mit off-policy-Daten eines stärkeren Teachers erhöhte die GC von 65,64 % auf 77,34 %. Auch Rejection Sampling Fine-Tuning (RFT) erzielte Verbesserungen.
Robustheit gegenüber Komplexität: Während die Leistung bei Basismodellen mit der Gesprächstiefe abnimmt, liefert SFT-Training erhebliche Gewinne bei langen Gesprächen (+26,69 Prozentpunkte), was darauf hindeutet, dass das Trainingssignal auf schwierigere, Multi-Step-Interaktionen generalisiert.
Zuverlässigkeit und Halluzinationen:
- Mensch-LLM-Übereinstimmung: Überstieg 90 % und validierte die automatisierte Evaluation.
- Simulator-Halluzinationen: Unter Standardkonfigurationen (GPT-5o mit mittlerem Reasoning-Aufwand) lagen die Halluzinationsraten für Tools und Benutzer nahe null (jeweils 1,33 % bzw. 0,67 %).
- Ablationsbefunde: Das Entfernen von Systemfakten oder Benutzerfakten aus Szenarien führte zu einem monotonen Anstieg der Halluzinationsraten, was bestätigt, dass eine sorgfältige Szenario-Spezifikation entscheidend ist. Schwächere State Tracker (z. B. GPT-4o) erhöhten die Tool-Halluzinationsraten und unterstreichen die Notwendigkeit einer genauen Zustandsableitung.
Modellübergreifende Robustheit: Die Modellrankings und Trainingsgewinne blieben konsistent, selbst wenn die Simulator- und Judge-Modelle ausgetauscht wurden (z. B. Verwendung von Gemini-2.5-Pro statt GPT-5o), wodurch ein zirkulärer Bias durch ein einzelnes Modell-Setup ausgeschlossen wurde.

Bedeutung und Behauptungen

Die Arbeit behauptet, dass die Proxy-State-basierte Evaluation eine praktische, skalierbare Alternative zu deterministischen Agenten-Benchmarks für industrielle LLM-Agenten bietet. Durch die Entkopplung der zustandsbasierten Evaluation vom ingenieurtechnischen Aufwand des Aufbaus deterministischer Backends ermöglicht das Framework:

Schnellere Iteration: Szenarien können schnell eingerichtet werden und mit Produkt-Roadmaps weiterentwickelt werden, ohne umfangreiche Code-Engineering-Arbeiten.
Strenge Evaluation: Sie bewahrt die Strenge der Final-State-Verifikation, unterstützt gleichzeitig aber die Flexibilität mehrerer korrekter Tool-Calling-Pfade.
Effektives Training: Sie generiert hochwertige on-policy- und off-policy-Daten, die offene Gewichte-Agenten erfolgreich durch SFT und RFT verbessern, wobei die Gewinne auf nicht gesehene Szenarien übertragen werden.

Die Autoren positionieren diese Arbeit nicht als Ersatz für alle deterministischen Tests, sondern als notwendige Evolution für industrielle Umgebungen, in denen die Kosten deterministischer Backends prohibitiv sind, das Bedürfnis nach zustandsbasierter, zielorientierter Evaluation jedoch weiterhin von höchster Priorität ist.