FinTrace: Evaluation von LLM-Tool-Aufrufen für Finanzaufgaben auf Trajektorie-Ebene

FinTrace (arXiv:2604.10015) erscheint eine Woche nach FinToolBench, das ich beim letzten Mal protokolliert habe, und die beiden Arbeiten stehen in direktem Dialog miteinander. Während FinToolBench misst, ob ein Agent die richtigen Tools aufruft, stellt FinTrace die schwierigere Frage: Selbst wenn ein Agent die richtigen Tools aufruft, reflektiert er tatsächlich über die Ergebnisse? Diese Unterscheidung ist der Kern der Arbeit und, wie ich meine, der Kern des gesamten Beancount-Write-Back-Agent-Problems.

Das Paper

Cao et al. führen FinTrace ein, einen Benchmark aus 800 von Experten annotierten Trajektorien, die 34 reale Finanzaufgaben-Kategorien in den Schwierigkeitsstufen einfach, mittel und schwer abdecken. Die Autoren bauen ihre Evaluation um eine Rubrik von neun Metriken auf, die entlang von vier Achsen organisiert sind: Aktionskorrektheit (Tool-Aufruf-F1, Aufgabenrelevanz), Ausführungseffizienz (Schritt-Effizienz, Redundanz-Score), Prozessqualität (logische Abfolge, Informationsnutzung, Fortschritts-Score) und Output-Qualität (Aufgaben-Bestehensrate, Qualität der endgültigen Antwort). Sie evaluieren 13 LLMs und veröffentlichen zudem FinTrace-Training, einen Datensatz mit 8.196 kuratierten Präferenz-Trajektorien für das Fine-Tuning.

Die zentrale Behauptung ist, dass Frontier-Modelle die Tool-Auswahl beherrschen, aber systematisch am schwierigeren Schritt scheitern: der Nutzung dessen, was die Tools zurückgeben. Der Benchmark untersucht dies mit einer 5-Punkte-Skala für Informationsnutzung, logische Abfolge und Fortschritts-Score sowie algorithmischen Metriken für Tool-F1 und Schritt-Effizienz.

Kernideen

• Das leistungsstärkste Modell, Claude-Opus-4.6, erreicht einen Tool-Aufruf-F1 von 0,896 — eine starke Auswahl —, erzielt aber nur 3,23/5 bei der Informationsnutzung, der schwächsten der vier Output-orientierten Metriken.
• Die Aufgaben-Bestehensrate von Claude-Opus-4.6 liegt bei 2,65/5 und die Qualität der endgültigen Antwort bei 3,34/5; selbst das Top-Modell liefert nicht konsistent korrekte, vollständige Antworten.
• Qwen-3.5-9B weist ein degeneriertes Muster auf: nahezu perfekte Schritt-Effizienz (1,000) und Redundanz (1,000), weil es kaum Tools aufruft, was sich in einem Tool-Aufruf-F1 von 0,109 widerspiegelt. Effizient, aber nutzlos.
• Das Training auf FinTrace-Training verbessert die Metriken des Zwischenprozesses (Logische Abfolge steigt von 2,29 auf 2,56 mit DPO; Fortschritts-Score von 2,00 auf 2,30), aber die Qualität der endgültigen Antwort bleibt ein Flaschenhals — keine Variante übertrifft signifikant den Durchschnitt von 1,21 auf der 1–5-Skala bei kleinen Modellen.
• DPO übertrifft SFT bei der Unterdrückung katastrophaler Fehlermodi: Der Anteil an Scores für die logische Abfolge von 1 sinkt von 11,9 % (SFT) auf 9,5 % (DPO).
• Die universell schlechteste Unterkategorie über alle 13 Modelle hinweg ist Reasoning QA, bei der Claude-Opus-4.6 insgesamt nur 0,62 erreicht — eine harte Obergrenze, die selbst das stärkste Frontier-Modell teilt.

Was Bestand hat — und was nicht

Die Kernerkenntnis — dass Tool-Auswahl und Tool-Reasoning voneinander trennbar sind — ist gut begründet, und die Rubrik mit vier Achsen ist ein echter Beitrag. Frühere Benchmarks wie FinToolBench hören bei Ausführungspfaden auf; FinTrace fügt LLM-beurteilte Prozessqualitätsmetriken hinzu, die offenlegen, was dazwischen passiert. Das Inter-Rater-Cohen's-κ von 0,89 bei einer Validierung von 100 Stichproben ist ermutigend für einen Benchmark, der teilweise auf LLM-Judges basiert.

Dennoch schränken mehrere methodische Entscheidungen ein, was ich aus den Zahlen für bare Münze nehmen kann. Die 34 Aufgabenkategorien sind im Hauptpaper nicht aufgeführt — sie werden in den Anhang B verschoben —, sodass ich nicht sagen kann, wie repräsentativ sie für die reale Finanzpraxis sind. Die Schwierigkeitsstufen werden durch Perzentil-Ränge innerhalb des eigenen Abfrage-Pools des Benchmarks definiert, was ein zirkuläres Maß ist: "Schwer" bedeutet hier nur ungewöhnlich im Vergleich zu den anderen 800 Trajektorien, nicht schwer in einem absoluten Sinne.

Die Fine-Tuning-Analyse ist frustrierend. Das Training eines 9B-Modells auf FinTrace-Training verbessert das logische Schlussfolgern im Zwischenschritt, aber die Qualität der endgültigen Antwort bleibt unzureichend. Das Paper führt dies auf eine "Trennung" zwischen Prozess und Output zurück, erklärt aber nicht, warum. Die plausibelste Erklärung — dass einem 9B-Modell der für Finanzaufgaben erforderliche Faktenabruf und die Rechenfähigkeiten fehlen, unabhängig von der Trajektoriequalität — bleibt unberücksichtigt. Da DPO-Ergebnisse nur für Qwen-3.5-9B gezeigt werden, ist es zudem unmöglich zu wissen, ob größere Modelle stärker profitieren.

Ich stehe auch der Aggregation des Gesamt-Scores skeptisch gegenüber. Die Kombination von algorithmischen Metriken (F1 ∈ [0,1]) mit LLM-beurteilten Scores auf 1–5-Likert-Skalen durch Normalisierung auf [0,1] und Mittelwertbildung vermischt sehr unterschiedliche Fehlertypen. Ein Modell, das völlig falsche Tools aufruft, ist nicht auf dieselbe Weise fehlerhaft wie ein Modell, das die richtigen Tools aufruft und dann den Output ignoriert.

Warum dies für Finanz-KI wichtig ist

Die Kernerkenntnis lässt sich direkt auf das Beancount-Write-Back-Problem übertragen. Ein Agent, der zuverlässig die richtigen Beancount-CLI-Tools aufruft, dann aber die Ausgabe falsch interpretiert — beispielsweise eine Bilanzantwort falsch parst und auf das falsche Konto bucht —, ist schlechter als gar keine Automatisierung: Er erzeugt selbstbewusst falsche Ledger-Einträge, die für einen flüchtigen Prüfer korrekt aussehen.

Die Metrik der Informationsnutzung ist diejenige, die ich bei jedem Beancount-Agenten am genauesten beobachten würde. Die Tatsache, dass das beste verfügbare Modell in einem kontrollierten Finanz-Benchmark hierbei 3,23/5 erzielt, sollte eine zwingende Einschränkung für jeden Produktionseinsatz sein. Dies spricht für eine obligatorische menschliche Überprüfung jeder Write-Back-Operation, zumindest bis wir diesen Score konsistent über 4,0 sehen.

FinTrace bestätigt auch, was ReDAct letzte Woche suggerierte: Die richtige Architektur ist nicht end-to-end LLM-Reasoning, sondern eine Pipeline, die die Verifizierung externalisiert. Ein Agent, der Tools gut auswählt (Tool F1 ~0,9) und die Ergebnisse dann vor der Ausführung an einen separaten Validierungsschritt übergibt, ist vertretbarer als einer, der versucht, in einem einzigen Durchgang über rohe Tool-Ausgaben zu reflektieren.

Was man als Nächstes lesen sollte

• FinMCP-Bench (arXiv:2603.24943): Das Begleitpapier, das MCP als Tool-Interface-Standard verwendet, steht als Nächstes auf der Leseliste — direkt vergleichbar mit FinTrace, baut aber auf einer anderen Protokollebene auf.
• "Benchmarking LLM Tool-Use in the Wild" (arXiv:2604.06185): Erschien zeitgleich und evaluiert Tool-Aufrufe außerhalb des Finanzbereichs; es könnte klären, ob die Lücke in der Informationsnutzung domänenspezifisch oder allgemeiner Natur ist.
• "Data-Driven Function Calling Improvements in Large Language Model for Online Financial QA" (arXiv:2604.05387): Zielt auf dieselben Fehlermodi bei Tool-Aufrufen aus der Perspektive von Trainingsdaten ab und könnte erklären, was bei der DPO von FinTrace-Training fehlt.