WildToolBench: Warum kein LLM eine Sitzungsgenauigkeit von 15 % bei der realen Tool-Nutzung überschreitet

Die Tool-Nutzung-Benchmarks, die ich verfolgt habe – BFCL, ToolBench, τ-bench – teilen alle einen gemeinsamen Designfehler: Sie konstruieren Aufgaben aus der Vorstellung der Benchmark-Autoren darüber, was Nutzer tun. WildToolBench, akzeptiert auf der ICLR 2026, greift auf echte Nutzerprotokolle zurück und fragt, was Nutzer tatsächlich tun. Die Antwort ist ernüchternd: 57 evaluierte LLMs, keines überschreitet eine Sitzungsgenauigkeit (Session Accuracy) von 15 %.

Das Paper

Peijie Yu, Wei Liu, Yifan Yang und Kollegen bei Alibaba präsentieren WildToolBench (arXiv:2604.06185), einen Benchmark mit 256 mehrstufigen Dialogszenarien und 1.024 Aufgaben, die aus authentischen Nutzerverhaltensmustern abgeleitet und in rund 1.600 öffentlichen APIs verankert sind. Das Hauptargument ist, dass bestehende Benchmarks nicht deshalb Sättigungspunkte erreichen, weil die Modelle so gut sind, sondern weil die Aufgaben künstlich sind. Echte Nutzer bündeln Anfragen, lassen Kontext weg, den sie vor zwei Runden geteilt haben, und wechseln zwischen einer Tool-Frage, Smalltalk und der Bitte um Klärung – manchmal innerhalb einer einzigen Nachricht. WildToolBench operationalisiert diese Fehlermodi in drei strukturierte Herausforderungskategorien und misst sowohl die Genauigkeit auf Aufgabenebene als auch die wesentlich strengere Sitzungsgenauigkeit, die den Erfolg bei allen vier Aufgaben eines Dialogs erfordert.

Kernaussagen

• Die Sitzungsgenauigkeit bricht bei den meisten Modellen in den einstelligen Bereich ein: Gemini-2.0-Flash-Thinking führt mit 14,45 % Sitzungsgenauigkeit, gefolgt von Claude-4-Sonnet mit 12,50 % und GPT-4o mit 11,72 %. Alle Aufgaben in einer vierstufigen Sitzung zu bestehen ist so schwierig, dass selbst eine Aufgabengenauigkeit von 60 % in eine Sitzungsgenauigkeit von unter 15 % resultiert – eine „Steuer“ der Verbundwahrscheinlichkeit für jede Interaktion.
• Kompositionelle Orchestrierung ist die steilste Hürde: Gemischte sequenziell-parallele Tool-Topologien begrenzen die Top-Modelle auf 25 % Aufgabengenauigkeit, verglichen mit 54–62 % bei rein parallelen oder sequenziellen Ketten. Wenn eine Aufgabe einen parallelen Fan-out gefolgt von einem sequenziellen Merge erfordert, übersteigt das Koordinationsproblem das, was jedes aktuelle Modell zuverlässig bewältigen kann.
• Verborgene Absichten sind eine größere Lücke als bisher gemessen: WildToolBench stellt sicher, dass 100 % der Aufgaben implizite oder rundenübergreifende Informationen enthalten; BFCL v3 erreicht hier nur 15,7 %. Aufgaben mit weitreichenden Abhängigkeiten – bei denen die fehlende Information mehr als zwei Runden zurückliegt – sind der schwierigste Untertyp, wobei kein Modell selbst auf Aufgabenebene die 50 %-Marke knackt.
• Instruktionsübergänge potenzieren Fehler linear: Jeder zusätzliche Richtlinienwechsel (Tool-Aufgabe → Chat → Klärung → Tool-Aufgabe) senkt die Genauigkeit um etwa 5 bis 15 Prozentpunkte. Bei drei Übergängen verlieren die am stärksten betroffenen Modelle 30 Punkte. Die Autoren nennen dies „Self-Conditioning“: Frühere Antworten beeinflussen die Interpretation nachfolgender Anweisungen durch das Modell auf eine Weise, die mitten in der Sitzung schwer zu korrigieren ist.
• Die optimale Pfadrate (Optimal Path Rate) bleibt unter 43 %: Selbst wenn Modelle Aufgaben korrekt abschließen, verbrauchen sie übermäßig viele API-Aufrufe. Claude-4-Sonnet erreicht die beste optimale Pfadrate mit 42,74 %, was bedeutet, dass die Mehrheit der korrekten Abschlüsse mehr Schritte als nötig benötigt – ein direkter Kostenfaktor bei Latenz und Token für jedes Produktionssystem.
• Spezialisierte Tool-Nutzung-Modelle schneiden schlechter ab als allgemeine Frontier-Modelle: xLAM-2-70B und ToolACE2-8B weisen beide Fehlerraten bei Funktionsnamen von über 30 % auf, was schlechter ist als bei GPT-4o oder Claude-4-Sonnet. Die Feinabstimmung auf engen Tool-Nutzung-Korpora scheint eher zu Sprödigkeit als zu Robustheit gegenüber Verteilungsverschiebungen hin zu realem Nutzerverhalten zu führen.

Was Bestand hat – und was nicht

Das Benchmark-Design ist dort stark, wo es am wichtigsten ist. Die Unterscheidung zwischen Aufgabengenauigkeit und Sitzungsgenauigkeit ist genau richtig: Potenzierte Fehlermodi sind das, was reale Implementierungen scheitern lässt, und die meisten früheren Arbeiten berichten über Zahlen auf Aufgabenebene, die dies verschleiern. Die Taxonomie der drei Herausforderungen (kompositionelle Orchestrierung, verborgene Absicht, Instruktionsübergänge) ist gut begründet und empirisch belegt – die Leistungsabfallkurven über die Herausforderungstypen hinweg sind real und frappierend.

Der Schwachpunkt ist die Skalierung. 1.024 Aufgaben aus 256 Szenarien sind ein glaubwürdiges Forschungsartefakt, aber etwas dünn für ein Leaderboard, das 57 Modelle über die Zeit verfolgen soll. Die Autoren räumen dies direkt ein und erwähnen eine automatisierte Skalierungspipeline für zukünftige Arbeiten. Das andere Problem ist, dass die Aussage „basierend auf echten Nutzerprotokollen“ viel Interpretationsspielraum lässt: Die endgültigen Aufgaben sind teilweise synthetisch, von einem Multi-Agenten-System aus Seed-Mustern konstruiert und dann von menschlichen Annotatoren verifiziert. Der Anspruch ist fundiert, aber die Daten sind nicht wortwörtlich „wild“ – sie sind von der Realität inspiriert. Das ist wichtig dafür, wie wörtlich man die 15 %-Obergrenze interpretiert; ein Teil der Lücke könnte sich schließen, wenn die Generierungspipeline künstliche Schwierigkeiten einführt, die echte Nutzer so nicht zeigen.

Ich bin auch skeptisch gegenüber der Analyse der Instruktionsübergänge als architektonischem Anspruch. Das Paper schreibt dies einer grundlegenden Limitierung zu, aber das Missverhältnis in der Trainingsverteilung zwischen RLHF-Feinabstimmungszielen und multimodalen Nutzersitzungen ist die plausiblere Erklärung. Das ist behebbar, nicht strukturell.

Warum dies für Finanz-KI wichtig ist

Die drei Fehlermodi lassen sich fast perfekt darauf übertragen, wie reale Nutzer mit einem Beancount-Write-back-Agenten interagieren. Ein Nutzer fragt: „Wie viel habe ich letzten Monat für Lebensmittel ausgegeben, und wenn du schon dabei bist, füge den heutigen Beleg von Whole Foods hinzu“ – das ist eine kompositionelle Aufgabe, die in einem Durchgang gebündelt ist. Danach folgt: „Mach daraus doch 47,23 $ statt 42 $, ich habe nachgesehen“ – das ist eine Parameterkorrektur, die erfordert, dass der Agent den Sitzungsstatus verfolgt. Dann fragen sie: „Ist diese Kategorie richtig?“ – das ist eine Klärungsanfrage, und der Agent darf die soeben abgeschlossene Schreiboperation nicht erneut ausführen. Die 25 %-Grenze bei gemischter sequenziell-paralleler Orchestrierung und der 30-Punkte-Abfall bei Instruktionsübergängen sind genau die Fehlermodi, die sich in einem Ledger-Agenten manifestieren würden, der reale Nutzersitzungen bearbeitet.

Die Erkenntnis, dass spezialisierte Tool-Nutzung-Modelle schlechter abschneiden als allgemeine Frontier-Modelle, ist besonders relevant. Wenn wir in Erwägung ziehen würden, ein kleineres offenes Modell auf Beancount-spezifischen Tool-Aufruf-Beispielen feinabzustimmen – die offensichtliche Strategie zur Kostensenkung –, ist WildToolBench eine direkte Warnung, dass Spezialisierung die Robustheit gegenüber der Verteilung des tatsächlichen Nutzerverhaltens opfern kann. Auch das Ergebnis zur optimalen Pfadrate zählt: Ein Agent, der doppelt so viele API-Aufrufe benötigt, um eine Aufgabe zu erledigen, ist nicht nur ineffizient; bei Write-back-Operationen können redundante Zwischenaufrufe den Ledger in inkonsistenten Zwischenzuständen hinterlassen.

Was man als Nächstes lesen sollte

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) – das grundlegende Trainings-Framework, gegen das sich WildToolBench explizit positioniert; das Verständnis seines synthetischen Evaluationsdesigns verdeutlicht, was die Live-Ausführung tatsächlich ergänzt.
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045) – die engste Vorarbeit zur realistischen mehrstufigen Tool-Nutzung; ein Vergleich der Einzelhandels-/Flugbereich-Domänen von τ-bench mit der öffentlichen API-Abdeckung von WildToolBench zeigt, wie sehr sich die Herausforderung verallgemeinern lässt.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 Oral) – falls das Problem der Instruktionsübergänge durch das automatische Finden besserer Agenten-Workflows anstatt durch die Skalierung von Trainingsdaten lösbar ist, stellt AFlow den glaubwürdigsten Mechanismus dafür dar.