FinQA: Der Benchmark zur Messung numerischer Schlussfolgerungen von KI in Finanzberichten

FinanceBench hat letzte Woche gezeigt, dass nicht das Retrieval der schwierige Teil von Finanz-Q&A ist, sondern das numerische logische Denken. FinQA, veröffentlicht auf der EMNLP 2021, ist das Paper, das darlegt, warum das so ist. Ich lese es jetzt, weil es der grundlegende Benchmark für Finanzarithmetik ist; jede nachfolgende Arbeit in diesem Bereich baut darauf auf oder nutzt es als Vergleichsgröße. Zu verstehen, woran seine Modelle scheitern, erklärt auch, wo aktuelle Beancount-Agenten an ihre Grenzen stoßen werden.

Das Paper

Zhiyu Chen, Wenhu Chen und Kollegen der UC Santa Barbara, J.P. Morgan und Amazon stellten FinQA: A Dataset of Numerical Reasoning over Financial Data (arXiv:2109.00122, EMNLP 2021) vor. Die Kernaufgabe: Gegeben ist ein Ergebnisbericht, der sowohl Fließtext als auch eine oder mehrere Finanztabellen enthält. Es soll eine Frage beantwortet werden, die mehrstufige Arithmetik über Fakten aus beiden Quellen erfordert. Die Antwort muss über ein explizites numerisches Programm hergeleitet werden – eine Sequenz von bis zu fünf Operationen (Addition, Subtraktion, Multiplikation, Division, Vergleich, Tabellenaggregation und einige andere), die auf extrahierte Werte angewendet werden.

Elf US-amerikanische Finanzexperten (CPAs, MBAs) erstellten den Datensatz manuell aus 2.789 Seiten von S&P 500-Ergebnisberichten aus den Jahren 1999–2019. Der fertige Datensatz enthält 8.281 annotierte Q&A-Paare, jeweils mit den korrekten Belegfakten (Gold Facts) und dem vollständigen Logikprogramm, was ihn vollständig ausführbar und prüfbar macht.

Kernaussagen

• Die Lücke zum Zeitpunkt der Veröffentlichung ist gravierend. FinQANet (RoBERTa-large), das beste neuronale Modell der Autoren, erreichte eine Ausführungsgenauigkeit von 61,24 % und eine Programmgenauigkeit von 58,86 % auf dem Testset. Menschliche Finanzexperten erzielten 91,16 % bzw. 87,49 %. Nicht-Experten aus der Crowd erreichten nur 50,68 % – kaum mehr als die neuronale Baseline. Das zeigt, dass die Domäne echtes Fachwissen erfordert und nicht nur Leseverständnis.
• Bei mehreren Schritten bricht alles zusammen. Bei Programmen, die drei oder mehr Logikschritte erfordern, sinkt die Genauigkeit von FinQANet auf 22,78 %. Das Modell kann zweistufige Arithmetik passabel bewältigen; alles, was darüber hinausgeht, führt zu kumulierten Fehlern.
• Modalitätsübergreifende Fragen sind der schwierigste Fall. Fragen, deren Belege sich sowohl über Tabellen als auch über den Fließtext erstrecken, weisen eine Genauigkeit von 43,80 % auf, etwa 17 Prozentpunkte unter dem Gesamtdurchschnitt. Eine Zahl aus einem Tabellenabschnitt mit einer Qualifizierung im Text in Verbindung zu bringen, gelingt standardmäßigen vortrainierten Modellen nicht gut.
• Domänenkonstanten sind ein lautloser Killer. Wenn ein Programmschritt eine Konstante erfordert, die eine Finanzkonvention ist (z. B. dass eine Million tausend Tausender hat oder dass ein Basispunkt 0,01 % entspricht) und nicht explizit im Dokument steht, sinkt die Genauigkeit auf 43,88 %. Das Modell kann nicht zuverlässig unterscheiden zwischen „diese Zahl steht im Dokument“ und „diese Zahl gehört zum Allgemeinwissen der Welt“.
• ~50 % der Fehler sind auf Lücken im Domänenwissen zurückzuführen, nicht auf Fehler beim Retrieval oder der arithmetischen Ausführung. Das Modell fand die richtigen Fakten, wendete aber die falsche Finanzlogik an.
• Neuere LLMs verringern die Lücke erheblich, schließen sie aber nicht. GPT-4 wird mit einer Ausführungsgenauigkeit von etwa 76 % bei FinQA angegeben, und aufgabenspezifische SOTA-Systeme erreichten bis 2024 rund 89 % – immer noch unter der Leistung menschlicher Experten.

Was Bestand hat – und was nicht

Das Design des Benchmarks ist solide. Die Verwendung ausführbarer Programme anstelle von Freitextantworten ist die richtige Entscheidung: Man kann ein Modell eindeutig bewerten und erhält Einblick darin, wie es geschlussfolgert hat, nicht nur, ob das Ergebnis stimmte. Die Entscheidung, sowohl Tabellen- als auch Textbelege zu fordern, spiegelt die reale Finanzanalyse wider, bei der die Tabelle die Zahl liefert und die Fußnote erklärt, was diese Zahl bedeutet.

Dennoch ist die Aufgabe enger gefasst, als es scheint. Die vordefinierte DSL (Domain Specific Language) der Operationen deckt die Standard-Finanzarithmetik ab, kann aber keine Kategorisierungsentscheidungen (z. B. „Ist diese Ausgabe wiederkehrend oder einmalig?“), Richtlinienprüfungen („Entspricht dieser Cashflow unserer Budgetrichtlinie?“) oder Dinge darstellen, die den externen Abruf von Marktdaten oder Rechnungslegungsstandards erfordern. Die Programme sind korrekt und erklärbar, aber sie existieren in einer Welt, in der die einzige Unsicherheit in der Arithmetik liegt, nicht im Urteilsvermögen.

Das Retrieval-Setup stellt dem Modell während des Trainings zudem die korrekten Belegfakten zur Verfügung, was die Zahlen schönt. In einer realen Anwendung müsste man erst die richtigen Tabellenzellen aus einem langen Dokument extrahieren, bevor man das Programm ausführen kann – und dieser Retrieval-Schritt ist keineswegs trivial, wie FinanceBench letzte Woche gezeigt hat.

Schließlich unterschätzen die Ergebnisse von 2021 die aktuellen Modellfähigkeiten. Die Baseline von ca. 61 % stammt aus der Zeit vor ChatGPT. Die GPT-4-Zahl von ca. 76 % und die SOTA-Werte von ca. 89 % stammen aus spezialisierten Pipelines, die Chain-of-Thought, Code-Ausführung und Fine-Tuning kombinieren. Der Abstand zu menschlichen Experten (91 %+) hat sich verringert, besteht aber weiterhin.

Warum das für Finanz-KI wichtig ist

Beancount-Hauptbücher sind im Grunde reduzierte Ergebnisberichte: strukturierte Zeilen von Soll und Haben mit Prosa-Metadaten in Transaktionsnotizen, Zahlungsempfängerfeldern und Kontohierarchien. Jede Fähigkeit, die der FinQA-Benchmark prüft, lässt sich direkt auf Aufgaben übertragen, die ein Beancount-Agent bewältigen muss.

Der modalitätsübergreifende Fehlermodus ist besonders wichtig. In einem Beancount-Kontext könnte ein Agent einen Transaktionsmetrag im Ledger, einen Fremdwährungskurs in einer Preis-Direktive und einen Kommentar im Notizfeld sehen – und alle drei benötigen, um den korrekten Wert in der Berichtswährung zu berechnen. Die 2021 von FinQA getesteten Modelle konnten diese Quellen nicht zuverlässig abgleichen. Aktuelle LLMs sind besser, aber die Genauigkeit von 22,78 % bei Programmen mit 3 oder mehr Schritten ist eine Warnung: Die Kettenlänge ist eine reale Fehlerquelle, und mehrstufige Aufgaben zur Abstimmung von Hauptbüchern (Ledger Reconciliation) werden darauf stoßen.

Auch das Problem der Domänenkonstanten lässt sich verallgemeinern. Die Buchhaltung hat ihre eigenen Konventionen – Invarianten der doppelten Buchführung, Semantik von Kontotypen, Geschäftsjahresgrenzen –, die ein Modell kennen muss, ohne dass sie explizit genannt werden. Die Fehleranalyse von FinQA, die ca. 50 % Fehler durch fehlendes Domänenwissen aufzeigt, legt nahe, dass ein Beancount-Agent entweder ein Fine-Tuning auf Buchhaltungskonventionen oder eine explizite Retrieval-Ebene für Buchhaltungsregeln benötigt, nicht nur für Ledger-Einträge.

Die Programmdarstellung des Benchmarks weist trotz ihrer Einschränkungen auch darauf hin, wie Beancount-Agenten ihre Argumentation ausdrücken sollten: nicht in möglicherweise vager natürlicher Sprache, sondern in ausführbaren Operationen, die überprüft, rückgängig gemacht oder auditiert werden können.

Was man als Nächstes lesen sollte

• TAT-QA (arXiv:2105.07624, ACL 2021) – erweitert das hybride Tabellen+Text-Szenario auf 16.552 Fragen mit einer größeren Vielfalt an Logiktypen; das vorgestellte TAGOP-Modell ist untersuchenswert hinsichtlich der gemeinsamen Extraktion von Informationen aus beiden Modalitäten.
• ConvFinQA (arXiv:2210.03849, EMNLP 2022) – die dialogorientierte Erweiterung von FinQA, bei der jeder Dialog numerische Abhängigkeiten über mehrere Runden aufweist; die mehrstufige Struktur lässt sich direkt auf einen interaktiven Beancount-Assistenten übertragen, der Berechnungen über Benutzernachfragen hinweg verfolgen muss.
• MultiHiertt (arXiv:2206.01347, ACL 2022) – erweitert das Szenario auf Finanzberichte mit mehreren hierarchischen Tabellen pro Dokument; ein notwendiger Schritt hin zu konsolidierten Abschlüssen und mehrjährigen Ledger-Ansichten, mit denen Beancount-Agenten konfrontiert werden.