FinToolBench: Evaluierung von LLM-Agenten bei der Nutzung von Finanzwerkzeugen in der Praxis

Die meisten Finanz-KI-Benchmarks testen lediglich, 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 entscheidende Lücke für jedes System, das versucht, echte Finanzarbeit zu automatisieren, und es ist die Lücke, auf deren rigorose Schließung ich gewartet habe.

Das Paper

Jiaxuan Lu und Kollegen führen FinToolBench (arXiv:2603.08262, März 2026) als den nach ihren Angaben ersten realen, ausführbaren Benchmark zur Evaluierung von Agenten ein, die den Umgang mit Finanzwerkzeugen erlernen. Der Ansatz ist direkt: Bestehende Finanz-KI-Evaluierungen konzentrieren sich auf statisches QA über Dokumenten, während allgemeine Benchmarks zur Werkzeugnutzung wie ToolLLM Finanzen nur als eine weitere API-Kategorie ohne domänenspezifische Compliance-Beschränkungen behandeln. FinToolBench versucht, den Raum zwischen diesen beiden Fehlermodi zu füllen.

Der Benchmark kombiniert 760 ausführbare Finanzwerkzeuge – 261 Live-Endpunkte von RapidAPI und 499 Schnittstellen von AkShare – mit 295 streng kuratierten Evaluierungsabfragen, aufgeteilt in 166 Einzelwerkzeug- und 129 Mehrwerkzeug-Fälle. Die Werkzeuge decken die Bereiche Aktien, Anleihen, Fonds, Devisen, Derivate, Makroökonomie und Krypto ab. Entscheidend ist, dass es sich um echte, aufrufbare APIs handelt und nicht um simulierte Stubs. Die Autoren führen außerdem FATR (Finance-Aware Tool Routing) ein, einen Basis-Agenten, der BGE-M3 Retrieval (Top-20 Kandidaten), mit Finanzattributen annotierte Tool-Cards und einen auf fünf Schritte begrenzten, beschränkungsbewussten ReAct-Planer verwendet.

Kernaussagen

• Die Ausführung ist nicht der Engpass – das logische Schlussfolgern über die Ergebnisse ist es. GPT-4o hat den höchsten Conditional Soft Score (CSS = 0,670), was bedeutet, dass es korrekte Antworten gibt, wenn es ein Werkzeug erfolgreich aufruft, aber es ruft Werkzeuge nur in 22,7 % der Fälle auf (TIR = 0,227). Qwen3-8B ruft Werkzeuge in 87,1 % der Fälle auf, erhält aber nur in 40,4 % der Fälle die richtige Antwort, wenn der Aufruf gelingt.
• Intent-Mismatch ist der vorherrschende Compliance-Fehler. Die IMR (Intent Mismatch Rate) liegt bei den meisten Modellen über 50 %, was bedeutet, dass Agenten routinemäßig transaktionale Aufrufe tätigen, wenn die Abfrage nur eine Informationsabfrage erfordert. Das ist ein ernstes Problem in regulierten Finanzkontexten.
• Die Injektion von Finanzattributen hilft der Compliance, ohne die Leistungsfähigkeit zu beeinträchtigen. Die Tool-Cards des FATR-Basismodells – die jedes Werkzeug mit Aktualität, Intent-Typ und Regulierungsbereich annotieren – reduzieren Aufrufe veralteter Daten (TMR) und Bereichsverletzungen (DMR), ohne die Aufrufrate signifikant zu verschlechtern.
• Mehrwerkzeug-Abfragen decken die Zuverlässigkeitslücke auf. Die 129 Mehrwerkzeug-Abfragen erfordern das Verketten von Aufrufen und das Übergeben von Ergebnissen zwischen den Schritten; die Leistung sinkt im Vergleich zu Einzelwerkzeug-Fällen erheblich, was mit den Ergebnissen von FinTrace und TheAgentCompany übereinstimmt.
• Kleine Modelle können mehr Aufrufe tätigen, aber große Modelle logisch nicht übertreffen. Die TIR von Qwen3-8B von 0,871 gegenüber 0,227 bei GPT-4o zeigt, dass kleinere Modelle „schussfreudiger“ 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 offenbart, dass GPT-4o weitaus präziser ist, wenn es sich für den Aufruf eines Werkzeugs entscheidet.

Was Bestand hat – und was nicht

Die Entscheidung des Benchmarks, tatsächlich live geschaltete, ausführbare APIs zu verwenden, ist sein primärer und wesentlicher Beitrag. Simulierte APIs waren das schmutzige Geheimnis von Werkzeugnutzungs-Benchmarks: Die 16.000 APIs von ToolLLM klingen beeindruckend, bis man merkt, dass die Evaluierung ein LLM als Richter darüber einsetzt, ob ein Aufruf funktioniert „hätte“. FinToolBench vermeidet das.

Die Compliance-Metriken (TMR, IMR, DMR) sind konzeptionell richtig – Finanz-Agenten müssen den Unterschied zwischen dem Abrufen des gestrigen Schlusskurses und dem Initiieren eines Handels kennen –, aber die Beschreibung des Papers, wie diese Klassifizierungen durchgesetzt werden, ist dünn. Es ist nicht klar, ob die Ground-Truth-Label für den Intent-Typ (informativ vs. transaktional) von Rechts- oder Compliance-Experten verifiziert oder einfach von den Autoren des Datensatzes zugewiesen wurden. Das spielt in der Praxis eine große Rolle.

Die Liste der Modelle ist zudem seltsam schmal: 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, dass GPT-4o ein Ausreißer in Bezug auf Präzision bei geringer Abdeckung ist; ich würde gerne wissen, ob sich Claudes Werkzeugnutzungsverhalten eher dem konservativen Muster von GPT-4o oder dem aggressiven von Qwen3-8B annähert.

Das Evaluierungsset mit 295 Abfragen ist nach modernen Benchmark-Standards klein. Bei 760 Werkzeugen bedeutet eine Abdeckungsrate von 295 Abfragen, dass die meisten Werkzeuge nie getestet werden. Das Paper liefert keine Abdeckungsstatistiken pro Domäne, was bedeutet, dass die Hauptzahlen durch eine Teilmenge gut abgedeckter Domänen wie Aktien und Makroökonomie getrieben sein könnten.

Warum dies für Finanz-KI wichtig ist

Beancount-Write-Back-Agenten – also jeder Agent, der bean-add aufruft, eine Ledger-Datei patcht oder beanquery abfragt – sind genau mit den Fehlermodi konfrontiert, die FinToolBench aufdeckt. Das Intent-Mismatch-Problem lässt sich direkt übertragen: Ein Beancount-Agent, der einen Schreibaufruf absetzt, wenn der Benutzer eine Lesefrage gestellt hat, weist dieselbe Fehlercharakteristik auf wie eine IMR-Verletzung. Die Aktualitätsdimension lässt sich auf das Problem übertragen, einen veralteten, zwischengespeicherten Ledger-Zustand aufzurufen, wenn der Benutzer den aktuellen Saldo erwartet.

Das Spannungsfeld zwischen Präzision und Abdeckung (GPT-4o vs. Qwen3-8B) ist ebenfalls unmittelbar relevant. Für Beancount-Schreibvorgänge wäre mir das konservative Aufrufverhalten von GPT-4o – niedrige TIR, aber hohe CER und CSS – viel lieber als ein Modell mit hoher Aufrufrate, das häufig das falsche Werkzeug ausführt. Falsche Schreibvorgänge sind weitaus kostspieliger als gar keine Operation.

Der FATR-Ansatz, Werkzeuge mit Compliance-Attributen zu annotieren, anstatt sich darauf zu verlassen, dass das Modell diese ableitet, ist ein Designmuster, das es wert ist, übernommen zu werden. Das Umschließen von Beancount-CLI-Tools mit expliziten Metadaten darüber, ob ein Aufruf schreibgeschützt oder verändernd ist und ob er den aktuellen oder den archivierten Ledger-Zustand betrifft, ist dieselbe Idee, angewendet auf einen kleineren Umfang.

Was man als Nächstes lesen sollte

• FinTrace (arXiv:2604.10015) – Evaluierung auf Trajektorienebene über 34 Finanzaufgabenkategorien mit 9 Metriken; erweitert die Einzelaufruf-Evaluierung von FinToolBench direkt auf mehrstufige Sequenzen und optimiert Qwen-3.5-9B mit DPO, um das logische Zwischenschließen zu verbessern.
• FinMCP-Bench (arXiv:2603.24943) – 613 Proben über 65 MCP-basierte Finanzwerkzeuge, die Einzelwerkzeug-, Mehrwerkzeug- und Mehrrunden-Aufrufe testen; das MCP-Framing ist direkt relevant für Beancount-Werkzeugschnittstellen.
• ToolLLM (arXiv:2307.16789, ICLR 2024) – Das ToolBench-Paper, gegen das sich FinToolBench explizit positioniert; zu verstehen, was die Mock-API-Baseline messen kann und was nicht, verdeutlicht, wie viel die Ausführbarkeit von FinToolBench tatsächlich wert ist.