Die meisten Finanz-KI-Benchmarks testen, ob ein Modell ein Dokument lesen kann. FinToolBench testet, ob ein Modell etwas tun kann – eine Live-API aufrufen, aktuelle Marktdaten abrufen und eine korrekte Antwort liefern. Das ist die Lücke, die für jedes System, das versucht, reale Finanzarbeit zu automatisieren, entscheidend ist, und es ist die Lücke, deren rigorose Schließung ich erwartet habe.
Das Paper
Jiaxuan Lu und Kollegen stellen FinToolBench (arXiv:2603.08262, März 2026) als das ihrer Aussage nach erste reale ausführbare Benchmark zur Bewertung von Agenten vor, die lernen, Finanztools zu nutzen. Die Rahmung ist direkt: Bestehende Finanz-KI-Bewertungen konzentrieren sich auf statische Dokument-QA, während allgemeine Tool-Nutzungs-Benchmarks wie ToolLLM Finanzen nur als eine weitere API-Kategorie behandeln, ohne domainspezifische Compliance-Beschränkungen. FinToolBench versucht, den Raum zwischen diesen beiden Fehlermodi zu füllen.
Das Benchmark kombiniert 760 ausführbare Finanztools – 261 Live-Endpunkte von RapidAPI und 499 Schnittstellen von AkShare – mit 295 sorgfältig kuratierten Bewertungsabfragen, aufgeteilt in 166 Einzel-Tool- und 129 Multi-Tool-Fälle. Die Tools decken Aktien, Anleihen, Fonds, Devisen, Derivate, Makroökonomie und Krypto ab. Entscheidend ist, dass dies reale aufrufbare APIs sind, keine simulierten Stubs. Die Autoren führen außerdem FATR (Finance-Aware Tool Routing) ein, einen Basisagenten, der BGE-M3-Retrieval (Top-20-Kandidaten), mit Finanzattributen annotierte Tool-Karten und einen constraint-bewussten ReAct-Planer mit maximal fünf Schritten verwendet.
Kernideen
- Ausführung ist nicht der Engpass – Schlussfolgerung über Ergebnisse ist es. GPT-4o hat die höchste Conditional Soft Score (CSS = 0,670), d.h. es gibt korrekte Antworten, wenn es erfolgreich ein Tool aufruft, ruft aber nur in 22,7% der Fälle Tools auf (TIR = 0,227). Qwen3-8B ruft in 87,1% der Fälle Tools auf, erhält aber nur in 40,4% der Fälle die richtige Antwort, wenn der Aufruf erfolgreich ist.
- Intent-Diskrepanz ist der dominante Compliance-Fehler. Die Intent-Diskrepanzrate (IMR) übersteigt bei den meisten Modellen 50%, d.h. Agenten geben routinemäßig Transaktionsaufrufe ab, wenn die Abfrage nur Informationsabruf verlangt. Das ist ein ernstes Problem in regulierten Finanzkontexten.
- Das Injizieren von Finanzattributen hilft der Compliance, ohne die Fähigkeiten zu beeinträchtigen. Die FATR-Basis-Tool-Karten – die jedes Tool mit Aktualität, Absichtstyp und Regulierungsbereich annotieren – reduzieren stale-data-Aufrufe (TMR) und Domainverstöße (DMR), ohne die Aufrufrate signifikant zu verschlechtern.
- Multi-Tool-Abfragen zeigen die Zuverlässigkeitslücke. Die 129 Multi-Tool-Abfragen erfordern das Verketten von Aufrufen und das Übergeben von Ergebnissen zwischen Schritten; die Leistung sinkt erheblich im Vergleich zu Einzel-Tool-Fällen, konsistent mit Erkenntnissen von FinTrace und TheAgentCompany.
- Kleine Modelle können große bei der Aufrufrate übertreffen, aber nicht beim Schlussfolgern. Qwen3-8Bs TIR von 0,871 gegenüber GPT-4os 0,227 zeigt, dass kleinere Modelle auslösefreudig sind, aber die CER (Conditional Execution Rate, d.h. TESR/TIR) von 0,339 für Qwen3-8B gegenüber 0,618 für GPT-4o zeigt, dass GPT-4o bei der Entscheidung, ein Tool aufzurufen, deutlich präziser ist.
Was hält – und was nicht
Die Wahl des Benchmarks, wirklich Live- und ausführbare APIs zu verwenden, ist sein Hauptbeitrag, und er ist erheblich. Simulierte APIs waren das schmutzige Geheimnis von Tool-Nutzungs-Benchmarks: ToolLLMs 16.000 APIs klingen beeindruckend, bis man erkennt, dass die Bewertung ein LLM als Richter darüber verwendet, ob ein Aufruf "funktioniert hätte". FinToolBench vermeidet das.
Die Compliance-Metriken (TMR, IMR, DMR) sind konzeptionell richtig – Finanzagenten müssen den Unterschied zwischen dem Abrufen des gestrigen Schlusskurses und dem Initiieren eines Handels kennen – aber die Beschreibung des Papers, wie diese Klassifikationen durchgesetzt werden, ist dünn. Es ist unklar, ob die Ground-Truth-Labels für den Absichtstyp (informational vs. transaktional) von Rechts- oder Compliance-Experten verifiziert oder einfach von den Dataset-Autoren vergeben wurden. Das spielt in der Praxis eine große Rolle.
Die Modellliste ist auch auffallend eng: Doubao-Seed-1.6, Qwen3-8B, GLM-4.7-Flash und GPT-4o. Kein Claude Sonnet oder Gemini 2.5, was natürliche Vergleiche gewesen wären. Die Ergebnistabelle zeigt GPT-4o als einen Ausreißer mit hoher Präzision und niedriger Abdeckung; ich würde gerne wissen, ob das Tool-Verhalten von Claude eher dem konservativen Muster von GPT-4o oder dem aggressiven von Qwen3-8B entspricht.
Der Bewertungssatz von 295 Abfragen ist nach modernen Benchmark-Standards klein. Bei 760 Tools bedeutet eine Abdeckungsrate von 295 Abfragen, dass die meisten Tools nie getestet werden. Das Paper liefert keine pro-Domain-Abdeckungsstatistiken, was bedeutet, dass die Schlagzeilenzahlen durch eine Teilmenge gut abgedeckter Domänen wie Aktien und Makroökonomie getrieben sein könnten.
Warum das für Finanz-KI wichtig ist
Beancount-Write-back-Agenten – jeder Agent, der bean-add aufruft, eine Ledger-Datei patcht oder beanquery abfragt – sind genau mit den Fehlermodi konfrontiert, die FinToolBench aufzeigt. Das Intent-Diskrepanz-Problem lässt sich direkt übertragen: Ein Beancount-Agent, der einen Schreibaufruf abgibt, wenn der Benutzer eine Leseabfrage gestellt hat, hat dieselbe Fehlersignatur wie eine IMR-Verletzung. Die Aktualitätsdimension lässt sich auf das Aufrufen eines veralteten zwischengespeicherten Ledger-Zustands übertragen, wenn der Benutzer den aktuellen Kontostand erwartet.
Die Spannung zwischen Präzision und Abdeckung (GPT-4o vs. Qwen3-8B) ist ebenfalls sofort relevant. Für Beancount-Write-back würde ich das konservative Aufrufverhalten von GPT-4o – niedrige TIR, hohe CER und CSS – stark bevorzugen gegenüber einem Modell mit hoher Aufrufrate, das oft das falsche Tool ausführt. Fehlerhafte Schreiboperationen kosten weit mehr als No-Ops.
FATRs Ansatz, Tools mit Compliance-Attributen zu annotieren, anstatt sich auf das Modell zu verlassen, sie abzuleiten, ist ein Designmuster, das es wert ist, übernommen zu werden. Das Verpacken von Beancount-CLI-Tools mit expliziten Metadaten darüber, ob ein Aufruf schreibgeschützt oder mutierend ist und ob es sich um den aktuellen oder archivierten Ledger-Zustand handelt, ist dieselbe Idee in kleinerem Maßstab.
Was man als Nächstes lesen sollte
- FinTrace (arXiv:2604.10015) – Trajektorien-Ebene-Bewertung über 34 finanzielle Aufgabenkategorien mit 9 Metriken; erweitert FinToolBenchs Einzelaufruf-Bewertung direkt auf mehrstufige Sequenzen und feinabstimmt Qwen-3.5-9B mit DPO zur Verbesserung des Zwischenschlussfolgerns.
- FinMCP-Bench (arXiv:2603.24943) – 613 Stichproben über 65 MCP-basierte Finanztools, die Einzel-Tool-, Multi-Tool- und Multi-Turn-Aufrufe testen; die MCP-Rahmung ist direkt relevant für Beancount-Toolschnittstellen.
- ToolLLM (arXiv:2307.16789, ICLR 2024) – das ToolBench-Paper, gegen das FinToolBench sich explizit positioniert; das Verständnis dessen, was die Mock-API-Baseline messen kann und was nicht, verdeutlicht, wie viel FinToolBench reale Ausführbarkeit wert ist.
