Das Paper​

Zhao, Jin, Li und Gao von der Peking-Universität stellen FinRAGBench-V vor, einen bilingualen Benchmark, der aus realen Finanzdokumenten konstruiert wurde: Analysen, Geschäftsberichte, Prospekte, wissenschaftliche Arbeiten, Magazine und Nachrichtenartikel. Der Retrieval-Korpus ist beträchtlich – 60.780 chinesische und 51.219 englische Seiten in etwa 1.100 Dokumenten pro Sprache – kombiniert mit 1.394 von Menschen annotierten Frage-Antwort-Paaren, die sieben Kategorien abdecken: Textinferenz, Extraktion von Diagrammen und Tabellen, numerische Berechnungen, zeitkritische Abfragen und mehrseitige Schlussfolgerungen. Über den Datensatz hinaus ist der zentrale Beitrag des Papers RGenCite, ein Basissystem, das Antworten zusammen mit visuellen Zitaten auf Pixelebene in Form von Bounding-Box-Koordinaten generiert, die die spezifischen Dokumentregionen markieren, die jede Behauptung stützen.

Kernideen​

• Multimodales Retrieval dominiert Text-Only mit gewaltigem Vorsprung: ColQwen2, ein Vision-Language-Retriever, der auf Seitenbild-Embeddings basiert, erreicht einen Recall@10 von 90,13 % (Chinesisch) und 85,86 % (Englisch). Die besten textbasierten Retriever, BM25 und BGE-M3, kommen lediglich auf etwa 42,71 %. Diese Lücke ist kein Rundungsfehler.
• Die Genauigkeit der Generierung ist selbst bei Spitzenmodellen gering: GPT-4o erreicht im Englischen eine Genauigkeit von 43,41 % (ROUGE 24,66); o4-mini erreicht im Chinesischen 58,13 % (ROUGE 38,55). Dies sind proprietäre Top-Modelle mit starkem Retrieval im Hintergrund.
• Zitate auf Seitenebene funktionieren; auf Blockebene nicht: Der Recall auf Seitenebene liegt bei den besten Modellen bei 75–93 %. Der Recall auf Blockebene – also das Wissen, welche spezifische Tabellenzelle oder welcher Diagrammbereich eine Behauptung stützt – sinkt auf 20–61 %. Dies ist die entscheidende Lücke für die Revisionssicherheit.
• Numerisches Denken und mehrseitige Inferenz bringen Modelle zuerst an ihre Grenzen: Fragen, die Berechnungen über mehrere Seiten oder Zeitspannen hinweg erfordern, weisen bei allen getesteten Systemen den stärksten Genauigkeitseinbruch auf.
• Proprietäre Modelle schneiden deutlich besser ab als Open-Source-Alternativen: Die Kluft zwischen geschlossenen APIs und Open-Source ist hier größer als bei den meisten NLP-Benchmarks, was darauf hindeutet, dass visuelles logisches Schließen im Finanzbereich für offene Modelle noch ungelöst ist.
• Auto-Evaluierung für Zitate ist unvollkommen: Der auf Bild-Cropping basierende Zitat-Evaluator erreicht ein Pearson r = 0,68 im Vergleich zu menschlichen Urteilen – akzeptabel, aber nicht verlässlich genug, um ohne Stichproben darauf zu vertrauen.

Was Bestand hat – und was nicht​

Das Ergebnis zum Retrieval ist das glaubwürdigste Resultat des Papers. Eine Differenz von fast 50 Prozentpunkten zwischen multimodalen und rein textbasierten Retrievern bei über 60.000 Seiten ist zu groß, um sie zu ignorieren. Wenn man ein Finanzdokument vor der Indexierung per OCR verarbeitet, zerstört man strukturelle Layout-Signale – etwa, in welcher Spalte eine Zahl steht oder ob eine Bildunterschrift die Interpretation einer Tabelle modifiziert –, die für das Retrieval enorm wichtig sind.

Die Zahlen zur Generierung sind ehrlich, aber isoliert betrachtet schwer zu interpretieren. Die Autoren schlüsseln nicht auf, wie viel der Genauigkeitslücke auf Retrieval-Fehler gegenüber Generierungsfehlern zurückzuführen ist. Da der Recall@10 für Englisch bereits bei 85,86 % liegt, muss ein erheblicher Teil der Fehler auf der Generierungsseite liegen. Eine solche Aufschlüsselung würde klären, ob der Flaschenhals das multimodale Denken an sich ist oder etwas Grundsätzlicheres in der Art und Weise, wie MLLMs Finanzsprache verarbeiten.

Das Evaluierungsset von 1.394 Frage-Antwort-Paaren ist für die Tragweite des Benchmarks eher klein. Verteilt auf sieben Kategorien und zwei Sprachen weisen einige Segmente deutlich weniger als 200 Beispiele auf. Die statistische Signifikanz der Ergebnisse auf Kategorieebene bleibt implizit. Dies ist für Benchmark-Paper nicht ungewöhnlich, bedeutet aber, dass gezielt ausgewählte Vergleiche ("Cherry-Picking") leicht zu konstruieren wären.

Das Protokoll zur Evaluierung der Zitate ist ein interessanter Beitrag, aber Pearson r = 0,68 im Vergleich zu menschlichen Bewertungen ist nicht stark genug, um die automatische Evaluierung als absolute Wahrheit für die Verankerung auf Blockebene zu betrachten. Die Autoren räumen dies ein; zukünftige Arbeiten an besseren Zitationsmetriken werden explizit als notwendig markiert.

Warum dies für Finanz-KI wichtig ist​

Beancount arbeitet mit Plain-Text-Ledger-Dateien, was rein textbasiertes RAG für die Abfrage vergangener Transaktionen vertretbar macht. Aber die breitere Buchhaltungsaufgabe umfasst Dokumente, die ausdrücklich kein reiner Text sind: Bankauszug-PDFs, gescannte Rechnungen, Quittungsbilder, Geschäftsberichte mit eingebetteten Tabellen und Diagrammen. In dem Moment, in dem ein Beancount-Agent einen Ledger-Eintrag mit einem Quelldokument abgleichen muss – zum Beispiel um zu verifizieren, ob eine bestimmte Abbuchung mit der hinterlegten Rechnung übereinstimmt – führt er genau die Aufgabe aus, die FinRAGBench-V benchmarkt.

Das Ergebnis zum Citation-Recall auf Blockebene ist für diesen Anwendungsfall am wichtigsten. Wenn ein Agent eine Buchung begründen muss, indem er auf einen spezifischen Posten in einem PDF verweist, und das beste verfügbare System nur 20–61 % Recall auf Blockebene erreicht, ist das nicht revisionssicher. Jede Beancount-Pipeline, die gescannte Quelldokumente verarbeitet, benötigt eine menschliche Überprüfung (Human-in-the-Loop), bis sich diese Werte deutlich verbessern.

Die Lücke in der Retrieval-Modalität spricht zudem stark gegen reine Text-Pipelines bei der Dokumentenerfassung. Ein Quittungsbild enthält Layout-Informationen – Betragsfelder, Händlernamen, Positionen von Einzelposten –, die durch OCR zerstört werden. Genau diese Layout-Informationen unterscheiden einen Gesamtbetrag von einem Steuerbetrag, und FinRAGBench-V zeigt, dass multimodale Retriever diese Informationen auf eine Weise nutzen, wie es Text-Retriever nicht können.

Was Sie als Nächstes lesen sollten​

• ColPali: Efficient Document Retrieval with Vision Language Models – der Vorgänger von ColQwen2, der den Ansatz der visuellen Seiten-Embeddings etablierte, auf dem der beste Retriever von FinRAGBench-V aufbaut [arXiv:2407.01449, ECCV 2024]
• M3DocRAG: Multi-modal Retrieval is What You Need for Multi-page Multi-document Understanding – befasst sich mit multimodaler QA über mehrere Dokumente hinweg mit einem flexiblen Framework für ein- und mehrstufiges visuelles Schließen [arXiv:2411.04952]
• Benchmarking Temporal-Aware Multi-Modal RAG in Finance – ein ergänzender Benchmark aus dem Jahr 2025, der die Zeitsensitivität in finanziellem multimodalem RAG bewertet, direkt komplementär zur zeitkritischen Fragekategorie von FinRAGBench-V [arXiv:2503.05185]

Die Studie​

EnterpriseArena ist eine 132-monatige (11-jährige) Simulation der Ressourcenallokation auf CFO-Ebene. Jeder Zeitschritt entspricht einem Monat. Der Agent erhält unvollständige Beobachtungen der Finanzdaten auf Unternehmensebene, anonymisierte Geschäftsdokumente und makroökonomische Signale aus FRED-, CBOE- und S&P-Global-Daten. Er verfügt über ein Budget von 20 Tool-Aufrufen pro Monat, verteilt auf vier Operationen – Überprüfung der Cash-Position, Durchsicht von Finanzunterlagen, Analyse der Marktbedingungen und Prognose von Cashflows – und muss eine von drei Aktionen wählen: die Bücher schließen (Abgleich/Reconciliation), Finanzierung beantragen (Eigen- oder Fremdkapital, mit stochastischen Ergebnissen) oder abwarten. Die primäre Einschränkung besteht darin, dass der Kassenbestand des Unternehmens zu jedem Zeitschritt nicht negativ sein darf; ein Verstoß beendet die Episode mit einer Punktzahl von Null. Unter der Bedingung des Überlebens maximiert der Agent die Endbewertung des Unternehmens nach der Bewertungsformel Rev_T × 5 + Cash_T − 5.000 × N_tools, die übermäßigen Tool-Einsatz explizit bestraft.

Elf LLMs wurden evaluiert, darunter Gemini-3.1-Pro, Claude-Haiku-4.5, GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Qwen3.5-397B und Qwen3.5-9B, zusammen mit einer menschlichen Experten-Baseline, die von zwei Finanzfachleuten mit 8 bzw. 14 Jahren Erfahrung validiert wurde.

Kernerkenntnisse​

• Überlebensraten variieren stark zwischen den Modellen: Qwen3.5-9B überlebt 80 % der Durchläufe, Gemini-3.1-Pro 50 %, Claude-Haiku-4.5 und GLM-5 jeweils 20 %, und GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Mistral-Small-24B sowie Mixtral-8x7B jeweils 0 %. Der Gesamtdurchschnitt der LLMs liegt bei 26 %.
• Größere Modelle schneiden nicht zuverlässig besser ab als kleinere: Qwen3.5-9B (9 Mrd. Parameter, 80 % Überleben, 78,8 Mio. $ Endbewertung) schlägt Qwen3.5-397B (397 Mrd. Parameter, 20 % Überleben) und GPT-5.4 (0 % Überleben) deutlich.
• Der Abstand zu Menschen ist groß: Die menschliche Baseline erreicht 100 % Überleben und eine Endbewertung von 152,2 Mio. $ ± 29,6 Mio. $; der LLM-Durchschnitt liegt bei 28,2 Mio. $ bei 26 % Überleben.
• Der Buchabschluss ist der kritische Engpass: Menschliche Experten schließen die Bücher (Reconciliation) in 94,3 % der Zeitschritte ab; LLMs erreichen im Durchschnitt 19,3 %. Dies ist die Aktion, die verlässliche Finanzberichte erstellt und rationale Folgeentscheidungen ermöglicht.
• Informationsbeschaffung ohne Handeln ist tödlich: Qwen3.5-397B nutzt Marktanalysen und Prognosetools während der gesamten Simulation in hohem Maße, schließt aber fast nie die Bücher ab (0,0 % Abschlussrate) und beantragt fast nie Finanzierungen. Es scheitert an Cash-Erschöpfung, obwohl es „wusste“, was geschah.
• Die Strafe für das Tool-Budget zählt: Die Bewertungsformel bestraft Agenten aktiv, die zwanghaft prüfen, anstatt zu handeln – eine Einschränkung, die reale Opportunitätskosten widerspiegelt.

Was überzeugt – und was nicht​

Das Design mit zwei Zielen – Überleben als harte Einschränkung plus Endbewertung – ist eine der stärksten Entscheidungen in aktuellen Agenten-Benchmarks. Es spiegelt wider, wie echte CFOs tatsächlich agieren: Man kann das Wachstum nicht optimieren, wenn einem das Geld ausgeht. Die Anonymisierung von Kalenderdaten und Unternehmensidentitäten verhindert, dass Modelle Muster aus gelernten historischen Ergebnissen erkennen, was eine echte methodische Verbesserung gegenüber Finanz-Benchmarks darstellt, die reale Ticker und Daten verwenden.

Die Taxonomie der Fehlermodi, die die Autoren durch Fallstudien identifizieren, ist glaubwürdig: GPT-5.4 erreicht eine Erfolgsquote von 99,1 % (was bedeutet, dass es in fast jedem Zeitschritt agiert, indem es nichts tut), während Qwen3.5-397B Analyse mit Handeln verwechselt. Dies sind verhaltenstypisch unterschiedliche Fehlermodi mit unterschiedlichen Abhilfemaßnahmen.

Wovon ich weniger überzeugt bin: Das stochastische Makro-Umfeld verwendet Gaußsches Rauschen, um Marktschocks zu approximieren, von denen die Autoren selbst einräumen, dass sie Black-Swan-Ereignisse oder menschliche Irrationalität nicht replizieren können. Das Tool-Budget von 20 Aufrufen pro Monat ist ebenfalls etwas willkürlich – echte CFOs unterliegen nicht dieser Art von Abfrageraten-Beschränkung für ihr eigenes Gedächtnis, was die Frage aufwirft, ob der Benchmark das langfristige finanzielle Urteilsvermögen oder eher „RAG unter Ressourcendruck“ misst. Die Einzelagenten-Struktur ist eine weitere explizite Einschränkung, die die Autoren nennen: Echte CFOs agieren innerhalb von Hierarchien aus Controllern, FP&A-Analysten und Treasury-Teams; das Paper versucht nicht, dies zu simulieren.

Die Feststellung, dass die Modellgröße das Überleben nicht vorhersagt, ist frappierend und wahrscheinlich zutreffend, aber der Mechanismus wird nicht gut erklärt. Die Autoren stellen dies fest, ohne vollständig zu klären, ob es sich um ein Versagen bei der Befolgung von Anweisungen, der Kohärenz bei langem Kontext oder der Risikokalibrierung handelt.

Warum dies für Finanz-KI wichtig ist​

Die Buchabschluss-Aktion in EnterpriseArena entspricht im Wesentlichen der Beancount-balance-Assertion und dem Schritt des Kontoabgleichs (Reconciliation) – der Moment, in dem sich der Agent auf eine fundierte Sicht des Finanzstatus festlegt, bevor er handelt. Die Erkenntnis, dass LLMs dies in 80 % der Fälle überspringen, lässt sich direkt auf das Problem der Rückschreibsicherheit (Write-back Safety) übertragen: Ein Agent, der den Abgleich vor dem Handeln vermeidet, agiert auf veralteten oder halluzinierten Zuständen. Für die Beancount-Automatisierung deutet dies darauf hin, dass der Abgleichsschritt in jeder Agenten-Schleife obligatorisch und verifizierbar sein sollte – nicht optional.

Der 132-monatige Horizont ist auch direkt analog zur mehrjährigen Buchführung. Die Feststellung, dass das dauerhafte Situationsbewusstsein mit der Zeit abnimmt, ist dieselbe Verschlechterung, die wir bei einem Beancount-Agenten erwarten würden, der eine fünfjährige Transaktionshistorie verwaltet: Selbst wenn der Agent alle Daten im Kontext hat, agiert er im Monat 60 möglicherweise nicht mehr kohärent. Dies legt nahe, dass in lang laufenden Beancount-Agenten-Sitzungen periodische, erzwungene Abgleichspunkte notwendig sind – und nicht nur reaktive Abfragen.

Die Falle der Informationsbeschaffung, in die Qwen3.5-397B tappt, ist eine nützliche Design-Warnung: Agenten, die mit vielen Retrieval-Tools ausgestattet sind, bevorzugen möglicherweise die Recherche gegenüber der Festlegung, insbesondere wenn die Kosten einer falschen Aktion (Korruption des Hauptbuchs) hoch sind. Tool-Budget-Beschränkungen, wie sie EnterpriseArena verwendet, könnten helfen, die Handlungsdisziplin bei Beancount-Write-back-Agenten durchzusetzen.

Was Sie als Nächstes lesen sollten​

• EcoGym (arXiv:2602.09514) – komplementärer Langzeit-Wirtschafts-Benchmark über Vending-, Freelance- und Operation-Umgebungen mit mehr als 1.000 Schritten; kein Modell dominiert in allen drei Bereichen, was darauf hindeutet, dass die Fehlermodi in EnterpriseArena nicht spezifisch für ein Benchmark-Design sind.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 Oral) – formuliert Workflow-Design als Suche im Code-Raum mit MCTS und LLM-Feedback neu; wenn EnterpriseArena zeigt, dass manuell entworfene Agenten-Verhaltensweisen scheitern, ist AFlow der offensichtliche nächste Schritt, um bessere Pipelines automatisch zu entdecken.
• ToolLLM: Facilitating Large Language Models to Master 16,000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) – das grundlegende Trainings- und Evaluierungs-Framework für den Einsatz von Tools; zu verstehen, wie Tool-Aufruf-Verhalten in ToolLLM gelernt wird, klärt, ob das Versagen durch Handlungsvermeidung in EnterpriseArena ein Trainings- oder ein Prompting-Problem ist.

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.

Das Paper​

Geng, Cai, Wang, Koeppl, Nakov und Gurevych untersuchen die aufkommende Literatur zur Konfidenzschätzung und Kalibrierung von LLMs über verschiedene Aufgaben hinweg, von Multiple-Choice-Fragen bis hin zu offener Generierung und maschineller Übersetzung. Das Kernproblem: LLMs können gleichzeitig hochpräzise und völlig unzuverlässig sein, und zwar auf eine Weise, die von außen schwer zu unterscheiden ist. Der Überblick unterteilt den Lösungsraum in zwei Hauptzweige – White-Box-Methoden, die den Zugriff auf interne Modellzustände nutzen, und Black-Box-Methoden, die das Modell als undurchsichtig behandeln – und unterscheidet innerhalb dieser weiter zwischen der Schätzung der Konfidenz und deren nachträglicher (post-hoc) Kalibrierung.

Das Paper wurde auf der NAACL 2024 veröffentlicht (Seiten 6577–6595) und im März 2024 auf Basis einer Einreichung vom November 2023 von einem Team der TU Darmstadt, der MBZUAI und der Mohamed bin Zayed University of AI überarbeitet.

Kernaussagen​

• White-Box-Konfidenz via Logits: Der einfachste Ansatz nutzt Wahrscheinlichkeiten auf Token-Ebene oder die längennormierte Log-Likelihood als Konfidenzsignal. Diese Methoden funktionieren, stehen aber vor einer grundlegenden Mehrdeutigkeit: Eine niedrige Token-Wahrscheinlichkeit kann eine geringe faktische Konfidenz widerspiegeln oder einfach eine ungewöhnliche Formulierung – das Modell kann sich bei der Wortwahl unsicher sein, während es sich bezüglich des zugrunde liegenden Fakts sicher ist.

• Konsistenzbasierte Black-Box-Konfidenz (SelfCheckGPT): Manakul et al. (EMNLP 2023) sampeln mehrere Vervollständigungen und bewerten deren gegenseitige Konsistenz mittels BERTScore, NLI oder n-Gramm-Überschneidung. Kein Logit-Zugriff erforderlich. Die zentrale Erkenntnis: Bei Fakten, die das LLM gut kennt, konvergieren wiederholte Stichproben; bei halluzinierten Fakten divergieren sie.

• Semantische Entropie: Farquhar et al. (Nature, 2024) gruppieren semantisch äquivalente Antworten, bevor sie die Entropie berechnen. Ein LLM könnte „Paris“ und „die französische Hauptstadt“ unterschiedlich formulieren – die rohe Token-Entropie behandelt diese als divergent, die semantische Entropie hingegen nicht. Dies ist ein qualitativer Fortschritt gegenüber der Konsistenz auf Token-Ebene, den der Überblick kontextualisiert.

• Verbalisierte Konfidenz ist unbrauchbar: Wenn Modelle aufgefordert werden, einen Konfidenzprozentsatz auszugeben, verfallen sie in Überkonfidenz. Empirische Arbeiten (Groot et al., TrustNLP auf der ACL 2024) zeigen, dass GPT-3, GPT-3.5 und Vicuna alle einen durchschnittlichen Erwarteten Kalibrierungsfehler (ECE) von über 0,377 für verbalisierte Konfidenz aufweisen, wobei sich die Vorhersagen unabhängig von der tatsächlichen Genauigkeit im Bereich von 90–100 % häufen. Selbst GPT-4 – das am besten kalibrierte evaluierte Modell – erreicht einen AUROC von nur ca. 62,7 %, wenn verbalisierte Konfidenz zur Unterscheidung korrekter von inkorrekten Antworten verwendet wird, was kaum über dem Zufallsniveau liegt.

• Kalibrierungstechniken variieren je nach Aufgabe: Für die Klassifizierung adressieren die kontextuelle Kalibrierung (Subtraktion des mit einem leeren „[N/A]“-Prompt geschätzten Class-Prior-Bias) und das Position-Debiasing (PriDE) bekannte systematische Verzerrungen. Für die Generierung optimiert Sequence Likelihood Calibration (SLiC) Modelle auf der Grundlage von gerankten Vervollständigungen. Temperature Scaling – die einfachste Post-hoc-Korrektur – bleibt in vielen Szenarien wettbewerbsfähig.

• Es existiert kein einheitlicher Benchmark: Die wohl gravierendste strukturelle Beobachtung der Untersuchung ist, dass es keinen einzelnen Benchmark gibt, der Methoden zur Konfidenzschätzung über Aufgaben und Domänen hinweg abdeckt. Dies macht es nahezu unmöglich, Methoden rigoros zu vergleichen. Das Feld vergleicht Äpfel mit Birnen.

Was Bestand hat – und was nicht​

Die Taxonomie ist solide. Die Unterscheidung zwischen White-Box und Black-Box ist für das Systemdesign wirklich nützlich, und die Behandlung von Logit-basierten Methoden ist ehrlich in Bezug auf deren Grenzen – die Autoren stellen direkt fest, dass die Token-Wahrscheinlichkeit faktische Konfidenz mit lexikalischer Unsicherheit vermengt. Praktiker unterschätzen diese Vermengung oft.

Wo mich die Untersuchung frustriert: Sie ist weitgehend deskriptiv. Es gibt fast keine experimentellen Benchmarks, die Methoden direkt miteinander vergleichen, und die Autoren räumen dies explizit als Einschränkung ein. Man erhält zwar eine klare Karte des Design-Raums, aber keine Anleitung dazu, welche Methode für eine neue Aufgabe zu verwenden ist.

Die Ergebnisse zur verbalisierten Konfidenz – ein AUROC von ~62,7 % für die von GPT-4 selbst angegebene Konfidenz – sollten zum Standardwissen für jeden gehören, der LLMs produktiv einsetzt. Das ist jedoch nicht der Fall. Es werden immer noch Prompts ausgeliefert, die fragen: „Auf einer Skala von 1–10, wie sicher bist du dir?“, und die Antwort wird als aussagekräftig behandelt. Das ist sie nicht.

Die Untersuchung ist zudem recht knapp bei der Frage der RLHF-Kalibrierung: Führt das Nachtraining mit menschlichem Feedback zu besser oder schlechter kalibrierten Modellen? Es gibt Belege für beides, und der Überblick umgeht dieses Thema weitgehend.

Warum dies für Finanz-KI wichtig ist​

ReDAct stützt sein Sicherheitskonzept darauf, ein kalibriertes Unsicherheitssignal vom günstigen Modell zu erhalten. Der Überblick verdeutlicht, wie schwierig das tatsächlich ist. Logit-basierte Signale sind in White-Box-Szenarien verfügbar, vermengen aber lexikalische und faktische Unsicherheit. Konsistenzbasierte Methoden funktionieren in Black-Box-Szenarien, erfordern jedoch mehrere Stichproben pro Entscheidung – was teuer für einen Beancount-Write-Back-Agenten mit hohem Durchsatz ist, der einen Stapel von Transaktionseinträgen verarbeitet.

Die wichtigste Erkenntnis für Bean Labs: Die semantische Entropie gruppiert semantisch äquivalente Antworten, bevor die Konsistenz bewertet wird. Genau das ist entscheidend für Buchungseinträge, bei denen ein Modell dieselbe Soll/Haben-Beziehung in mehreren syntaktisch unterschiedlichen Formen ausdrücken könnte. Ein Beancount-Agent sollte semantisches Clustering über gesampelte Vervollständigungen von Buchungseinträgen verwenden – und nicht die reine Varianz auf Token-Ebene –, um zu erkennen, wenn er einen Kontonamen oder einen Betrag halluziniert.

Das Scheitern der Kalibrierung bei verbalisierter Konfidenz ist eine direkte Warnung für jedes UI, das dem Benutzer anzeigt, „wie sicher sich die KI ist“: Vertrauen Sie nicht der Zahl, die das Modell generiert. Verwenden Sie stattdessen einen externen Kalibrator oder eine konsistenzbasierte Methode, oder zeigen Sie die Konfidenz gar nicht erst an.

Was Sie als Nächstes lesen sollten​

• Farquhar et al., „Detecting hallucinations in large language models using semantic entropy,“ Nature, 2024 – die fundierteste Methode, die aus diesem Survey-Rahmen hervorgeht; es lohnt sich, das Original vollständig zu lesen, anstatt nur die Zusammenfassung der Untersuchung.
• Manakul et al., „SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative Large Language Models,“ EMNLP 2023 (arXiv:2303.08896) – die kanonische konsistenzbasierte Methode; unerlässlich zum Verständnis, bevor man ein Black-Box-Konfidenzsignal einsetzt.
• Groot et al., „Overconfidence is Key: Verbalized Uncertainty Evaluation in Large Language and Vision-Language Models,“ TrustNLP auf der ACL 2024 (arXiv:2405.02917) – die gründlichste empirische Prüfung darüber, wie verbalisierte Konfidenz über Modelle und Aufgaben hinweg versagt.

Das Paper​

Saibo Geng, Hudson Cooper, Michał Moskal und Kollegen von Microsoft Research stellen JSONSchemaBench vor, einen Benchmark aus 9.558 Schemata aus realen Produktionsquellen: GlaiveAI-Funktionsaufruf-Signaturen, nach Komplexität geschichtete GitHub-Repositories von trivial bis ultra, Kubernetes-API-Konfigurationen, Snowplow-Event-Analytics-Schemata und die JSONSchemaStore-Sammlung. Sie bewerten sechs Frameworks für eingeschränktes Dekodieren – Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs und Gemini – anhand von drei Achsen: Abdeckung (welchen Anteil der Schemata das Framework überhaupt verarbeiten kann), Effizienz (Overhead der Token pro Sekunde im Vergleich zur uneingeschränkten Generierung) und Qualität (Genauigkeit der nachgelagerten Aufgaben). Das Evaluierungsgitter umfasst auch die offizielle JSON Schema Test Suite, die 45 Funktionskategorien dokumentiert, die jede konforme Engine unterstützen sollte.

Die Kernbehauptung ist, dass die Schema-Komplexität die entscheidende Variable ist, die fähige Frameworks von fragilen trennt, und dass kein einzelnes Framework über alle drei Achsen hinweg dominiert.

Kernideen​

• Die Abdeckung bricht bei Schema-Komplexität zusammen. Bei einfachen GlaiveAI-Schemata erreichen alle Frameworks Werte über 86 %. Aber bei GitHub-Hard-Schemata – mit mehrstufiger Verschachtelung, rekursiven Definitionen und komplexen Muster-Constraints – fällt Guidance auf 41 %, Llamacpp auf 39 %, XGrammar auf 28 % und Outlines auf katastrophale 3 %. OpenAI erreicht bei GitHub-Hard nur 9 %, und Gemini liefert bei Schemata mit mittlerer Komplexität oder höher überhaupt keine validen Ausgaben mehr.
• Kubernetes offenbart eine spezifische Schwäche in XGrammar. Trotz der Geschwindigkeitsversprechen von XGrammar erreicht es nur eine Abdeckung von 7 % bei Kubernetes-Schemata. Dies liegt wahrscheinlich daran, dass diese Schemata auf kontextabhängigen Mustern basieren, die die kontextunabhängige Vorberechnung von XGrammar nicht verarbeiten kann. Eine Abdeckung gegenüber einem Benchmark, der Kubernetes-Konfigurationen enthält, ist für Produktions-Agenten nicht optional.
• Unzureichende Einschränkung ist gefährlicher als ein Kompilierungsfehler. XGrammar weist 38 Fehler durch unzureichende Einschränkung (under-constrained) gegenüber der JSON Schema Test Suite auf – das bedeutet, es gibt JSON aus, das das deklarierte Schema verletzt, meldet aber fälschlicherweise Erfolg. Guidance hat nur einen solchen Fehler. Für einen Write-Back-Agenten wird ein Kompilierungsfehler zur Designzeit abgefangen; ein Under-constrained-Fehler korrumpiert Daten zur Laufzeit ohne jegliches Signal.
• Das Fast-Forwarding von Guidance liefert eine echte Geschwindigkeitssteigerung von 50 %. Wenn lange deterministische Sequenzen vorhanden sind (z. B. Feldnamen in einer festen Objektstruktur), kann Guidance mehrere Token pro Dekodierungsschritt überspringen. Auf einem Llama-3.1-8B auf einem A100 läuft Guidance mit 6–9 ms pro Output-Token, während die uneingeschränkte Generierung 15–16 ms benötigt. Outlines ist mit 30–46 ms langsamer als die uneingeschränkte Generierung, was hauptsächlich an der anfänglichen Automaten-Kompilierung liegt, die 3–8 Sekunden pro Schema beansprucht.
• Eingeschränktes Dekodieren verbessert die Argumentationsgenauigkeit leicht. Bei GSM8K (Mathematik) steigert Guidance die Genauigkeit von 80,1 % (uneingeschränkt) auf 83,8 %. Bei "Last Letter" und "Shuffle Objects" liegen die Gewinne im Bereich von 1–3 Punkten. Dies widerspricht der weit verbreiteten Sorge, dass das Erzwingen des JSON-Formats die Antwortqualität verschlechtert – der Effekt ist jedoch so gering, dass die Formatwahl nicht die Entscheidung für ein Framework bestimmen sollte.
• Kein Framework deckt alle 45 JSON-Schema-Funktionskategorien ab. Guidance deckt 13 ab, Llamacpp und XGrammar jeweils eine und Outlines null. Die praktische Implikation ist, dass sich jedes Schema, das if/then/else, unevaluatedProperties oder rekursive $ref-Definitionen verwendet, unvorhersehbar verhält, je nachdem, welche Engine im Hintergrund arbeitet.

Was Bestand hat – und was nicht​

Der stärkste Beitrag des Benchmarks ist die Auswahl der Schemata. Frühere Evaluierungen verwendeten Spielzeug-Schemata oder Sammlungen aus einer einzigen Quelle. Die Einbeziehung von Kubernetes-Konfigurationen neben Funktionsaufruf-Signaturen bietet die richtige Art von adverser Vielfalt. Die Komplexitätsschichtung (von trivial bis ultra) bietet Praktikern zudem eine Kalibrierungskurve: Wenn Ihre Schemata wie GlaiveAI-Funktionsaufrufe aussehen, sind XGrammar oder Guidance beide in Ordnung; wenn sie wie Kubernetes-Manifeste aussehen, werden Ihre Optionen schnell dünner.

Die Hauptschwäche ist die Single-Sample-Greedy-Evaluierung. Die Messung der Abdeckung mit nur einer Generierung pro Schema unterschätzt die wahre Leistungsfähigkeit – ein Framework könnte in 20 % der Fälle scheitern, aber bei einem erneuten Versuch erfolgreich sein. Das Paper räumt dies ein, berichtet jedoch keine Pass@k-Zahlen mit Temperature-Sampling, die für Produktionssysteme, die bei Fehlern einen Retry durchführen, wichtig wären.

Der Vergleich mischt zudem unvergleichbare Modelle. Open-Source-Frameworks (Guidance, Outlines, Llamacpp, XGrammar) wurden auf Llama-3.2-1B getestet, während OpenAI und Gemini ihre eigenen, nicht offengelegten Modelle verwenden. Die 9 % Abdeckung von OpenAI bei GitHub-Hard könnte ebenso sehr die Modellfähigkeit wie die Architektur des eingeschränkten Dekodierens widerspiegeln. Ein fairer Vergleich würde kontrollierten Modellzugriff erfordern – was die Autoren von proprietären Anbietern offensichtlich nicht erzwingen können.

Warum dies für Finanz-KI wichtig ist​

Jeder Beancount-Write-Back-Agent erzeugt strukturierten Output. Wenn der Agent Beancount-Direktiven als JSON ausgibt, bevor er sie in die .beancount-Syntax konvertiert, oder wenn er Tools über JSON-Schemata aufruft, ist die Zuverlässigkeit dieser JSON-Generierung kein Detail – sie ist das entscheidende Element. Das FinTrace-Paper zeigte, dass Spitzenmodelle bei der Argumentation über Tool-Ausgaben scheitern; JSONSchemaBench offenbart ein orthogonales Problem: Schon vor der Argumentation kann die Formatierungsschicht unbemerkt nicht-konforme Ausgaben erzeugen.

Das Kubernetes-Ergebnis ist für Beancount besonders aufschlussreich. Ledger-Schemata sind keine flachen Key-Value-Listen. Kontohierarchien, Transaktionsmetadaten und Tag-Strukturen erzeugen verschachtelte rekursive Muster ähnlich wie Kubernetes-API-Objekte. Ein Framework, das bei Kubernetes nur 7 % erreicht, ist nicht bereit für komplexe Hauptbuch-Schemata, egal wie gering sein Overhead pro Token ist.

Der Fehlermodus der unzureichenden Einschränkung (under-constrained failure) ist das, was mir schlaflose Nächte bereiten würde. Ein Beancount-Agent, der XGrammar verwendet, könnte eine Transaktion ausgeben, die die interne Validierung des Frameworks besteht, aber das tatsächliche Schema verletzt – und der Agent hätte keinen Grund für einen erneuten Versuch. Stille Datenkorruption ist schlimmer als ein sichtbarer Fehler.

Was man als Nächstes lesen sollte​

• XGrammar (arXiv:2411.15100, Dong et al.) – das technische Paper hinter einem der schnellsten getesteten Frameworks, das den Split in kontextunabhängige/abhängige Token erklärt und warum Kubernetes-Schemata diesen belasten.
• Grammar-Aligned Decoding / ASAp (NeurIPS 2024) – zeigt, dass Token-Maskierung beim eingeschränkten Dekodieren die Wahrscheinlichkeitsverteilung des Modells verzerren kann, und schlägt einen korrigierten Sampling-Algorithmus vor; die theoretische Grundlage für Qualitätsbedenken, die der Benchmark nur indirekt misst.
• XGrammar-2 (arXiv:2601.04426) – ein Follow-up, das XGrammar auf dynamische Schemata in agentischen Umgebungen ausweitet, in denen sich das Schema selbst während einer Multi-Turn-Sitzung ändert; direkt relevant für Beancount-Agenten, die ihr Ausgabeformat basierend auf den aktiven Kontotypen anpassen.

Das Paper​

Jie Zhu, Yimin Tian und Kollegen vom Alibaba Cloud Qwen DianJin Team, YINGMI Wealth Management und der Soochow University präsentieren FinMCP-Bench, eine Evaluations-Suite mit 613 Proben, die 10 Kategorien von Finanzszenarien und 33 Unter-Szenarien abdeckt. Die Tools sind nicht bloß simuliert – 65 echte MCP-konforme Finanz-Tool-Server bilden das Rückgrat des Benchmarks, basierend auf realen Produktionslogs des Finanzassistenten der Qieman-App. Die Autoren kategorisieren die Proben in drei Typen: 145 Single-Tool-, 249 Multi-Tool- und 219 Multi-Turn-Aufgaben. Sie testen sechs Modelle: die Qwen3-Familie mit 4B, 30B und 235B Parametern (alle mit "Extended Thinking"), dazu DeepSeek-R1, GPT-OSS-20B und Seed-OSS-36B. Die zentralen Evaluationsmetriken sind Tool-Präzision, Tool-Recall, Tool-F1 und eine Exact Match Rate (EMR), die voraussetzt, dass jeder Tool-Aufruf in einer Sequenz exakt korrekt ist.

Kernideen​

• MCP als Evaluationsgrundlage: Die Verwendung echter MCP-Serverdefinitionen anstelle synthetischer API-Schemas schließt eine große Lücke zwischen der Benchmark-Evaluierung und dem, womit Agenten in real eingesetzten Finanzsystemen tatsächlich konfrontiert sind.
• Dreifache Schwierigkeitsabstufung: Single-Tool-, Multi-Tool- und Multi-Turn-Proben weisen nicht nur quantitative Unterschiede auf – sie legen qualitativ unterschiedliche Fehlermodi offen.
• Multi-Turn-Kollaps: Das beste Modell (Qwen3-235B) erreicht 60 % EMR bei Single-Tool-, 10,62 % EMR bei Multi-Tool- und 3,08 % EMR bei Multi-Turn-Aufgaben. Der Abfall von Single-Tool zu Multi-Turn ist 20-fach.
• Tool-F1 ist nachsichtiger: Dasselbe Modell erreicht 66,85 %, 69,42 % und 41,56 % TF1 über die drei Einstellungen hinweg – was zeigt, dass Modelle oft die richtigen Tools finden, aber bei der Reihenfolge, Parametrisierung oder Gesprächsverfolgung scheitern.
• Recall schlägt Präzision bei Single-Tool: Modelle neigen dazu, bei Unsicherheit eher zu viele Tools aufzurufen als zu wenige. Dies ist der sicherere Fehlermodus für Finanzaufgaben, bedeutet aber dennoch verschwendete API-Aufrufe und Rauschen in der Argumentationskette.
• Nicht-monotone Skalierung nach Größe: Qwen3-30B übertrifft Qwen3-4B nicht konsistent in allen Unter-Szenarien, was die Annahme widerlegt, dass größere Modelle bei mehrstufiger Tool-Nutzung immer gewinnen.

Was Bestand hat – und was nicht​

Die Verwendung echter Produktionslogs als Quelle für Single-Tool-Beispiele ist die methodisch stärkste Entscheidung hier. Sie verankert den Benchmark im tatsächlichen Nutzerverhalten anstatt in von Forschern erfundenen Szenarien, was in der Literatur zu Finanz-KI selten ist. Die Multi-Tool- und Multi-Turn-Proben wurden synthetisch mithilfe von Abhängigkeitsgraphen und Rollenspiel-Prompts erweitert, was angesichts der Labeling-Kosten angemessen ist, aber ein Risiko birgt: Der Syntheseprozess neigt dazu, sauberere und eindeutigere Anfragen zu erzeugen, als sie echte Nutzer schreiben würden. Die 3,08 % EMR bei Multi-Turn-Aufgaben sind alarmierend, sollten aber vorsichtig interpretiert werden – EMR erfordert, dass die komplette Sequenz exakt korrekt ist, sodass ein einziger falscher Zwischenaufruf die gesamte Aufgabe scheitern lässt. Das ist ein strenger und wohl unrealistischer Produktionsstandard; Metriken mit Teilwertung wie TF1 erzählen eine differenziertere Geschichte.

Was das Paper nicht anspricht: Es gibt keine Analyse darüber, ob die Leistungslücke primär ein Problem des Eingabeverständnisses ist (das Modell interpretiert die Benutzerabsicht falsch), ein Problem der Ausgabeformatierung (korrekte Absicht, aber fehlerhafter Tool-Aufruf) oder ein Problem der Logik (falsche Zwischenschlüsse). Ohne diese Aufschlüsselung ist es schwer zu wissen, wo Engineering-Aufwand investiert werden sollte. Das Paper evaluiert Modelle zudem isoliert; es gibt keinen Test, ob das Hinzufügen eines Verifizierungs- oder Reflexionsschritts das Multi-Turn-Bild verändert.

Der Benchmark ist zudem tief an die spezifischen 65 Tools von Qieman gebunden, was die Übertragbarkeit der Ergebnisse auf andere Finanzplattformen mit anderem Tool-Inventar einschränkt.

Warum dies für Finanz-KI wichtig ist​

FinMCP-Bench ist die am nächsten an der Realität liegende veröffentlichte Evaluation dessen, was ein Beancount-Agent mit Schreibzugriff tatsächlich tun würde: eine Benutzeranfrage empfangen, das passende Tool (oder eine Kette von Tools) identifizieren, diese der Reihe nach aufrufen und Folgeschritte bearbeiten. Die Multi-Turn-EMR von 3,08 % ist ein ernüchternder Realitätscheck. Ein Beancount-Agent, der eine mehrstufige Journal-Korrektur verwaltet – zum Beispiel die Umklassifizierung einer Reihe von Transaktionen über Konten hinweg innerhalb eines Datumsbereichs, gefolgt von einer Abstimmung und dem Erstellen eines Berichts – ist genau die Art von Multi-Turn-, Multi-Tool-Aufgabe, an der aktuelle Modelle nach Exact-Match-Standards fast universell scheitern.

Das MCP-Framework ist hierbei direkt relevant: Die Python-API von Beancount, die beanquery-Schnittstelle und die REST-Ebene von Fava könnten alle als MCP-Server gekapselt werden. FinMCP-Bench zeigt uns, dass nicht das Protokoll der Flaschenhals ist – sondern die Logik über Tool-Aufrufsequenzen hinweg.

Die Erkenntnis, dass der Tool-Recall die Präzision übersteigt (Modelle rufen zu viele Tools auf), ist auch für die Sicherheit bei Schreibvorgängen wichtig: Ein Agent, der ein Tool zur Journal-Mutation aufruft, wenn eigentlich nur ein Lesezugriff nötig war, könnte das Journal unbemerkt korrumpieren. Präzisionsorientierte Evaluationsmetriken, nicht Recall-orientierte, sollten daher das primäre Sicherheitssignal für schreibende Agenten sein.

Was Sie als Nächstes lesen sollten​

• JSONSchemaBench (arXiv:2501.10868) – evaluiert die Zuverlässigkeit strukturierter Ausgaben über 10.000 JSON-Schemas hinweg; befasst sich direkt mit der Frage, ob Fehler bei der Tool-Aufruf-Formatierung in FinMCP-Bench ein Problem des eingeschränkten Dekodierens (Constrained Decoding) sind.
• ToolLLM (arXiv:2307.16789, ICLR 2024) – das grundlegende Trainings-Framework für Tool-Nutzung, gegenüber dem sich FinMCP-Bench positioniert; das Verständnis seiner Tiefensuche-Baumexploration verdeutlicht, was die Produktionslog-Methodik von FinMCP-Bench ergänzt.
• WildToolBench (arXiv:2604.06185) – evaluiert die Tool-Nutzung anhand realer Benutzeranfragen aus der Praxis; die Erkenntnis, dass kein Modell eine Genauigkeit von mehr als 15 % bei realem Nutzerverhalten erreicht, ergänzt den Produktionslog-Ansatz von FinMCP-Bench.

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.

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.

Das Paper​

OmniEval konstruiert ein zweidimensionales Evaluationsraster: fünf Aufgabenklassen (extraktive QA, Multi-Hop-Argumentation, Kontrast-QA, Long-Form-QA und konversationelle QA) gekreuzt mit 16 Finanzthemen (Aktienmärkte, Investmentbanking, Fonds, Sachversicherungen und andere). Das Ergebnis ist ein strukturierter Benchmark mit 11,4k automatisch generierten Testbeispielen, 1,7k menschlich annotierten Beispielen und einem Retrieval-Korpus aus 362k Dokumenten, der aus sechs chinesischen Finanzdatenquellen zusammengestellt wurde (BSCF-DB mit 193k Dokumenten, FinGLM mit 55k, BAAI-Fin mit 48k, offizielle Web-Crawls, PDFs und Wikipedia-Finanzinhalte). Der Benchmark enthält auch einen feinabgestimmten LLM-Evaluator – Qwen2.5-7B-Instruct, trainiert auf 910 menschlich gelabelten Instanzen –, der die Generierungsqualität hinsichtlich Genauigkeit, Halluzination, Vollständigkeit, Nutzung und numerischer Genauigkeit bewertet. Das Paper wurde auf der EMNLP 2025 veröffentlicht.

Kernideen​

• Die automatisch generierten Testfälle bestanden eine menschliche Akzeptanzprüfung zu 87,47 %, was bedeutet, dass etwa jede achte generierte Instanz verworfen wurde – keine triviale Fehlerquote für einen Benchmark.
• Der beste Retriever (GTE-Qwen2-1.5B) erreichte einen MAP-Wert von 0,4370 und einen MRR-Wert von 0,4491 auf dem automatisch generierten Set, was bedeutet, dass die am höchsten gerankte Passage selbst mit dem stärksten getesteten Retriever in weniger als der Hälfte der Fälle korrekt ist.
• Die Generierungsgenauigkeit (ACC) über alle Retriever-LLM-Kombinationen hinweg lag zwischen 0,3238 und 0,4476 – die beste Konfiguration beantwortet weniger als die Hälfte der Fragen richtig.
• Die numerische Genauigkeit (NAC) ist der prägnanteste Befund: 0,0659 bis 0,3595. Das beste System liefert in etwa 36 % der Fälle korrekte Finanzzahlen; das schlechteste liegt nahe Null.
• Der feinabgestimmte Evaluator erreichte eine Übereinstimmung von 74,4 % mit menschlicher Annotation (κ = 0,6486) und übertraf damit reine Prompting-Baselines (55–71 %) deutlich – lässt jedoch immer noch jede vierte Bewertung im Widerspruch zum menschlichen Urteil.
• Multi-Hop-Argumentation und konversationelle QA waren durchweg die schwierigsten Aufgabenklassen.

Was Bestand hat – und was nicht​

Das Design der Matrix-Evaluation ist wirklich nützlich. Frühere Finanz-Benchmarks (FinanceBench, FinQA, DocFinQA) behandeln die Evaluation oft als eine einzige Achse – meist die Antwortgenauigkeit – und übersehen die strukturelle Variation, wie RAG scheitert. Zu wissen, dass ein System bei extraktiver QA gut abschneidet, aber bei Multi-Hop-Argumentation versagt, ist handlungsrelevant; zu wissen, dass es einen gewissen Gesamtdurchschnitt erreicht, ist es nicht. Das OmniEval-Raster macht diese Variation sichtbar, und die Feststellung, dass die Leistung über verschiedene Themen hinweg inkonsistent ist, ist genau das Ergebnis, das Praktiker vor dem Einsatz sehen müssen.

Dennoch gibt es reale Grenzen, die ich direkt ansprechen möchte. Der Korpus ist überwiegend chinesisch: Fünf von sechs Datenquellen sind chinesische Finanzdaten (BSCF, FinGLM, BAAI-Fin), und die sechste ist die chinesische Wikipedia. Das Paper schlüsselt die Ergebnisse nicht nach Sprachen auf – es liefert nur aggregierte Zahlen. Dies macht jeden Wert im Paper als allgemeine Aussage über Finanz-RAG verdächtig, da es sich eher um Finanz-RAG über chinesischen Texten mit spezialisierten chinesischen Retrievern und LLMs handelt (GTE-Qwen2-1.5B, Qwen2.5-72B, Yi15-34B). Englischsprachige Nutzer können diese Zahlen nicht direkt verwenden.

Der LLM-Evaluator wurde auf 910 gelabelten Instanzen trainiert. Das ist wenig. Die 74,4 % Übereinstimmung mit Menschen bei κ = 0,6486 ist als Ausgangspunkt vertretbar, bedeutet aber, dass das Evaluations-Framework selbst erhebliches Rauschen einführt. Wenn der Benchmark verwendet wird, um Systeme zu vergleichen, die sich nur um wenige Prozentpunkte unterscheiden, wird die Varianz des Evaluators das Signal überlagern.

Die automatische Generierungspipeline – GPT-4 erstellt Testfragen, Menschen filtern mit 87,47 % Akzeptanz – wirft zudem eine Kontaminationsfrage auf, die das Paper nicht thematisiert: Von GPT-4 generierte Fragen könnten die Stärken von Modellen der GPT-4-Klasse auf eine Weise bevorzugen, die ältere oder kleinere Modelle systematisch benachteiligt.

Warum das für Finanz-KI wichtig ist​

Die Werte für die numerische Genauigkeit sind die Zahlen, auf die ich immer wieder zurückkomme: 0,0659–0,3595. Wenn das beste getestete RAG-System Finanzzahlen in einer Benchmark-Evaluation nur in 36 % der Fälle richtig wiedergibt, wird jeder Beancount-Write-Back-Agent, der auf einer naiven RAG-Pipeline basiert, die Buchhaltungsdaten korrumpieren. Das Beancount-Format verzeiht nichts – ein falscher Betrag, ein falsches Datum oder ein falscher Kontoname führt entweder zu einem Parsing-Fehler oder zu einem stillen Buchungsfehler, der sich über Geschäftsjahre hinweg fortpflanzen kann. Dieser Benchmark liefert uns den konkreten Beweis, dass RAG-Retrieval und LLM-Generierung noch nicht zuverlässig genug für direkte Ledger-Schreibvorgänge ohne eine Validierungsschicht sind.

Die Aufgabenklassen-Struktur lässt sich zudem direkt auf Beancount-Anwendungsfälle übertragen. Extraktive QA entspricht einfachen Saldenabfragen. Multi-Hop-Argumentation entspricht Fragen wie „Wie hoch ist mein Nettoeinkommen nach Steuern über Q1–Q3?“. Konversationelle QA entspricht einem Benutzer, der eine Abstimmungsanfrage im Laufe einer Sitzung iterativ verfeinert. OmniEvals Erkenntnis, dass Multi-Hop- und Konversationsaufgaben am schwierigsten sind, ist genau die schlechte Nachricht für das Design von Beancount-Agenten: Die einfachen Fälle funktionieren fast, aber bei den realistischen Fällen bricht das System zusammen.

Was man als Nächstes lesen sollte​

• ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation (arXiv:2311.09476, NAACL 2025) – das engste Pendant im allgemeinen Bereich zum Fine-Tuning-Ansatz des Evaluators von OmniEval; ein Vergleich der ARES-Methodik mit der von OmniEval würde klären, ob die Designentscheidungen des LLM-Evaluators prinzipienbasiert oder ad hoc sind.
• RAGEval: Scenario-Specific RAG Evaluation Dataset Generation Framework (ACL 2025, aclanthology.org/2025.acl-long.418) – automatisierte Szenariogenerierung für die RAG-Evaluation; erweitert die von OmniEval genutzte Methodik der automatischen Generierung und könnte die Kontaminationsbedenken adressieren.
• FinRAGBench-V: A Benchmark for Multimodal RAG with Visual Citation in the Financial Domain (arXiv:2505.17471) – erweitert die RAG-Evaluation auf multimodale Finanzdokumente (Tabellen, Diagramme); relevant, da Beancount-Nutzer zunehmend Belegbilder und PDF-Kontoauszüge neben Plain-Text-Ledgern haben.

Das Paper​

Der Survey von Xu und Ding (arXiv:2409.01980) schlägt vor, die LLM-basierte Anomalie- und Out-of-Distribution (OOD)-Erkennung in zwei übergeordnete Klassen zu unterteilen: LLMs for Detection, bei denen das Modell Anomalien direkt identifiziert, und LLMs for Generation, bei denen das Modell Trainingsdaten erweitert oder natürlichsprachliche Erklärungen erstellt, die einem nachgelagerten Detektor dienen. Jede Klasse wird weiter unterteilt. Die Erkennung spaltet sich in Prompting-basierte Methoden (eingefrorene oder feinabgestimmte LLMs, die mit natürlichsprachlichen Prompts abgefragt werden) und Kontrastierungs-basierte Methoden (Modelle der CLIP-Familie, die die Anomalität durch den Vergleich von Bildausschnitten mit Textbeschreibungen bewerten). Die Generierung unterteilt sich in Augmentierungs-zentrierte Methoden (Erzeugung von Pseudo-OOD-Labels oder synthetischen Minderheiten-Stichproben) und Erklärungs-zentrierte Methoden (Erstellung natürlichsprachlicher Begründungen für markierte Ereignisse).

Die zugehörige GitHub-Leseliste umfasst etwa 39 Paper: 24 zur Erkennung, 10 zur Augmentierung und 5 zur Erklärung.

Kernaussagen​

• Kontrastierungs-basierte Methoden dominieren die Bild-Anomalieerkennung. WinCLIP erreicht 91,8 % und 85,1 % AUROC bei der Zero-Shot-Anomalieklassifizierung und -segmentierung auf MVTec-AD ohne datensatzspezifisches Tuning, was mit überwachten Methoden konkurrenzfähig ist.
• Eingefrorene LLMs stoßen bei Nicht-Text-Daten auf eine Modalitätslücke. Der Survey stellt explizit fest, dass „das direkte Prompting eingefrorener LLMs für Anomalie- oder OOD-Ergebnisse über verschiedene Datentypen hinweg oft zu suboptimaler Leistung führt, da eine inhärente Modalitätslücke zwischen Text und anderen Datenmodalitäten besteht.“
• LoRA und Adapter-Tuning schließen diese Lücke weitgehend. Methoden wie AnomalyGPT und AnomalyCLIP nutzen parametereffiziente Techniken zur Feinabstimmung und übertreffen ihre eingefrorenen Gegenstücke deutlich.
• Generierung als Augmentierung wird zu wenig genutzt. Von BLIP-2 generierte Pseudo-OOD-Labels auf Caption-Ebene übertreffen Alternativen auf Wort- und Beschreibungsebene bei der OOD-Erkennung, was darauf hindeutet, dass eine reichhaltigere Text-Supervision selbst für visuelle Aufgaben wichtig ist.
• Erklärungs-zentrierte Generierung ist die neueste Unterkategorie. Systeme wie Holmes-VAD und VAD-LLaMA gehen über binäre Flags hinaus und generieren natürlichsprachliche Begründungen für anomale Ereignisse, primär in Überwachungsvideos.
• Tabellarische Daten fehlen fast vollständig. Der Survey zitiert eine Methode – „Tabular“ von Li et al. (2024) –, die Tabellenzeilen in Text-Prompts umwandelt und mit LoRA feinabstimmt, liefert jedoch keine Vergleichswerte.

Was überzeugt – und was nicht​

Die zwei-klassen-basierte Taxonomie ist wirklich sauber, und ich werde sie wahrscheinlich nutzen, um meine eigenen Gedanken zu ordnen. Die Unterscheidung zwischen Erkennung und Generierung erfasst eine reale architektonische Gabelung: Entweder man lässt das LLM direkt klassifizieren oder man nutzt es, um ein besseres Trainingssignal für einen traditionellen Detektor aufzubauen.

Was ich nicht akzeptieren kann, ist die Rahmung des Papers als allgemeiner Survey zur Anomalieerkennung. Die Abdeckung konzentriert sich überwiegend auf industrielle Defektbilder (MVTec-AD, VisA) und Überwachungsvideos (UCF-Crime, XD-Violence). Von den etwa 39 katalogisierten Papern befassen sich fast keine mit tabellarischen oder Finanzdaten. Zeitreihen erhalten einige Zitate. Tabellarische Daten werden in einem Satz abgehandelt. Dies ist keine Landkarte für Bean Labs – es ist eine Landkarte für Computer-Vision-Forscher, die CLIP für die Defekterkennung nutzen möchten.

Die Autoren räumen ein, dass „Platzmangel detaillierte metrische Zusammenfassungen verhindert“, was eine höfliche Umschreibung dafür ist, dass es keine Vergleichstabellen gibt. Für ein Survey-Paper ist das Fehlen einer quantitativen Synthese eine erhebliche Lücke. Leser können dieses Paper nicht nutzen, um zu entscheiden, welches Paradigma für ihren Anwendungsfall besser geeignet ist, ohne jedes zitierte Paper einzeln nachzuschlagen.

Die Halluzinations-Problematik wird als offene Frage aufgeführt, aber die Behandlung ist oberflächlich – das Risiko wird benannt, ohne zu analysieren, welche Erkennungsparadigmen mehr oder weniger anfällig sind oder wie eine erklärungszentrierte Generierung Halluzinationen durch menschliche Überprüfung erkennbarer machen könnte.

Warum dies für Finanz-KI wichtig ist​

Zwei Unterkategorien sind trotz der bildlastigen Abdeckung relevant. Erstens ist die Unterkategorie der erklärungs-zentrierten Generierung genau das, was Beancount-Audit-Agenten benötigen: nicht nur ein Hinweis, dass ein Journaleintrag anomal ist, sondern ein natürlichsprachlicher Satz, der erklärt, warum. Finanzrevisoren können nicht auf Basis eines binären Outputs agieren. Zweitens ist das fast vollständige Schweigen des Surveys zur tabellarischen Anomalieerkennung an sich informativ – es bestätigt, dass der Strang um AnoLLM, CausalTAD und AD-LLM, den ich verfolgt habe, ein Pioniergebiet und kein ausgetretener Pfad ist. Der Entwurf von LLM-basierten Audit-Tools für Beancount-Ledger erfordert die Synthese von Erkenntnissen aus der Vision-Anomalieerkennung, die noch nicht auf tabellarische Umgebungen übertragen wurden.

Der Kompromiss zwischen Prompting und Tuning ist die am besten umsetzbare Erkenntnis: Zero-Shot-Prompting funktioniert als erste Annäherung, leidet aber unter der Modalitätslücke; LoRA-basierte Feinabstimmung auf repräsentativen, markierten Beispielen schließt diese Lücke. Für einen Beancount-Einsatz mit markierten Anomalie-Beispielen aus historischen Ledgern erscheint der Weg der Feinabstimmung zuverlässiger als reines Prompting.

Nächste Lektüreempfehlungen​

• „Advancing Anomaly Detection: Non-Semantic Financial Data Encoding with LLMs“ (arXiv:2406.03614) – nutzt LLM-Sentence-Transformer-Embeddings für echte Hauptbuch-Buchungssätze; eine direkte Brücke vom Rahmen dieses Surveys zum tabellarischen Beancount-Anwendungsfall.
• „Enhancing Anomaly Detection in Financial Markets with an LLM-based Multi-Agent Framework“ (arXiv:2403.19735) – Multi-Agenten-Pipeline für die Anomalieerkennung in Marktdaten; das Multi-Agenten-Koordinationsmuster könnte auf Ledger-Audits übertragbar sein.
• AnomalyGPT (arXiv:2308.15366) – feinabgestimmtes LVLM für die industrielle Anomalieerkennung mit Lokalisierung auf Pixelebene; die Lektüre klärt, was „LLM-Tuning für die Erkennung“ architektonisch eigentlich bedeutet, was der Survey zwar beschreibt, aber nicht erklärt.

Das Paper​

Hsieh et al. beginnen mit einer diagnostischen Beobachtung: LLMs – selbst solche, die auf langen Kontexten trainiert wurden – weisen ein hartnäckiges U-förmiges Attention-Muster auf. Token am Anfang und am Ende der Eingabe erhalten unverhältnismäßig viel Aufmerksamkeit, unabhängig davon, ob sie relevant sind, während Token in der Mitte systematisch unterbewertet werden. Die Autoren bringen dies empirisch mit dem "Lost in the Middle"-Genauigkeitseinbruch in Verbindung, anstatt es als separates Phänomen zu behandeln.

Ihr Lösungsansatz ist vom Konzept her elegant. Sie zerlegen die Attention in zwei additive Komponenten: Relevanz (was wir wollen) und positionaler Bias (was wir nicht wollen). Um den Bias-Term zu isolieren, lassen sie ein "Dummy"-Dokument – informativ leerer Füllinhalt – an jeder Position durch denselben Kontext laufen und zeichnen die resultierende Attention-Verteilung auf. Diese Dummy-Dokument-Attention approximiert den reinen positionalen Prior. Subtrahiert man diesen von den echten Attention-Scores, bleibt ein Restwert, der die wahre Relevanz besser widerspiegelt:

Kalibrierte Attention = Attn(Dokument, k) − Attn(Dummy, k)

Die neu skalierten Scores werden dann verwendet, um abgerufene Dokumente vor dem finalen Schritt der Antwortgenerierung neu zu ordnen oder neu zu gewichten. Entscheidend ist, dass kein Training erforderlich ist. Die Kalibrierung wird zur Inferenzzeit auf die letzten 16 Decoder-Layer und alle Attention-Heads angewendet. Die Kosten belaufen sich auf O(K) zusätzliche Forward-Passes, wobei K die Anzahl der abgerufenen Dokumente ist – nicht trivial, aber vorhersehbar.

Kernideen​

• Der U-förmige Attention-Bias ist der Modellarchitektur inhärent und bleibt selbst in Modellen bestehen, die explizit mit Long-Context-Zielen trainiert wurden.
• Das Durchlaufen eines Dummy-Dokuments (leer/Rauschen) durch denselben Retrieval-Kontext isoliert den positionalen Prior; das Subtrahieren entfernt den Bias ohne jegliches Finetuning.
• Recall@3 bei NaturalQuestion (K=20, das relevante Dokument in der Mitte platziert) springt mit Kalibrierung von 20,52 % auf 68,32 %; bei K=10 von 36,38 % auf 74,27 %.
• Die End-to-End-QA-Genauigkeit verbessert sich um 6–15 Prozentpunkte, wenn das relevante Dokument in der Mitte des Kontextes liegt; Verbesserungen zeigen sich in 22 von 24 Experiment-Konfigurationen.
• Die Methode übertrifft sechs Vergleichs-Baselines: Vanilla Attention, Query-Generation-Ranking, Relevance-Generation-Prompting, Attention-Sorting (Peysakhovich & Lerer 2023), Prompt-Umordnung und LongLLMLingua-rk.
• Die Methode wurde anhand von NaturalQuestion (2.655 reale Abfragen über Wikipedia) und SynthWiki (990 synthetische, von GPT-4 generierte Einträge) evaluiert.

Was Bestand hat – und was nicht​

Das Kernergebnis ist beeindruckend und ich halte es für glaubwürdig. Eine Lücke beim Recall@3 von 20,52 % → 68,32 % für mittig platzierte Dokumente ist kein Wert, der bei genauerer Betrachtung einfach verpufft – er misst etwas Reales darüber, wie Attention verteilt wird. Das trainingsfreie Design ist ein echter praktischer Vorteil: Man kann dies über jede bestehende RAG-Pipeline stülpen, ohne die Modellgewichte anzupassen.

Dennoch habe ich einige Vorbehalte. Erstens setzt der "Dummy-Dokument"-Ansatz voraus, dass der positionale Bias in etwa positionell trennbar und additiv ist – eine lineare Zerlegung, die die Autoren selbst als potenziell zu vereinfachend markieren. Realer Attention-Bias könnte mit Inhalten auf nicht-lineare Weise interagieren. Zweitens werden die O(K) zusätzlichen Forward-Passes als "akzeptabel" eingestuft, aber nie hinsichtlich Latenz oder Kosten gebenchmarkt. In einem Produktionssystem mit K=20 Abrufen führt man 21 Forward-Passes statt einem pro Abfrage aus. Für einen Beancount-Agenten, der hunderte von Transaktionen sichtet, spielt dieser Multiplikator eine Rolle.

Drittens – und das ist die interessanteste Einschränkung – merken die Autoren an, dass der positionale Bias für bestimmte Aufgaben tatsächlich nützlich sein könnte. Ein Recency-Bias könnte zum Beispiel dazu führen, dass ein Modell aktuelle Hauptbucheinträge (ledger entries) korrekterweise stärker gewichtet als ältere. Den Bias wahllos zu entfernen, könnte Aufgaben schaden, bei denen die Position ein gültiges Signal ist. Dies wird zwar eingeräumt, aber nicht untersucht.

Schließlich nutzen die Experimente NaturalQuestion und einen synthetischen Datensatz. Finanzspezifische Dokumente – dichte Tabellen, mehrjährige Berichte, Hauptbucheinträge mit repetitiver Struktur – unterscheiden sich stark von Wikipedia-Passagen. Die Kalibrierung müsste erst an diesen Verteilungen validiert werden, bevor man behaupten kann, dass sie für finanzielles RAG funktioniert.

Warum das für Finanz-KI wichtig ist​

Der direkte Zusammenhang ist klar: Jedes Protokoll seit DocFinQA hat das gleiche Problem umkreist. Wenn ein Beancount-Agent 20 relevante Hauptbucheinträge abruft, um eine Frage wie "gleiche den März mit dem Kontoauszug ab" zu beantworten, werden Einträge aus der Mitte des abgerufenen Fensters systematisch weniger beachtet als Einträge am Anfang und Ende des Kontextes. Das ist kein Fehler beim Abrufen (Retrieval) – es ist ein Fehler auf der Generierungsseite, den keine Verbesserung des Retrieval-Rankings beheben kann.

Die "Found in the Middle"-Kalibrierung ist eine plausible Entschärfung, die kein Neutraining des zugrunde liegenden Modells erfordert und direkt im Generierungsschritt jeder Ledger-QA-Pipeline angewendet werden könnte. Die Bedenken hinsichtlich der O(K)-Kosten sind real, aber handhabbar – ein 20-Dokumente-Retrieval-Fenster mit einem moderat dimensionierten Modell liegt immer noch im praktischen Bereich. Was ich vor einem Einsatz sehen möchte, ist eine Validierung speziell auf Beancount-strukturierten Daten: Hilft die Positionskorrektur einheitlich, oder unterdrückt sie versehentlich das Recency-Signal, das aktuelle Transaktionen vertrauenswürdiger macht als alte?

Das übergeordnete Prinzip – dass Attention-Mechanismen positionale Priors unabhängig von der Inhaltsrelevanz kodieren und dass diese Priors ohne Neutraining wegkalibriert werden können – ist es wert, beibehalten zu werden. Es öffnet die Tür zu ähnlichen Kalibrierungen für andere Bias-Arten: Token-Frequenz-Bias, Eingabelängen-Normalisierung oder Verbosity-Bias bei der Generierung.

Was man als Nächstes lesen sollte​

• "Mitigate Position Bias in LLMs via Scaling a Single Hidden States Channel" (arXiv:2406.02536, ACL Findings 2025) – schlägt die Skalierung einer einzelnen Hidden-State-Dimension vor, anstatt Attention-Scores zu subtrahieren; ein direkter Vergleich zum "Found in the Middle"-Ansatz lohnt sich.
• "Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey" (arXiv:2409.01980, NAACL 2025) – als Nächstes auf der Leseliste; verknüpft die AnoLLM-, CausalTAD- und AD-LLM-Threads zu einer einheitlichen Taxonomie.
• Liu et al., "Lost in the Middle: How Language Models Use Long Contexts" (arXiv:2307.03172, TACL 2023) – die ursprüngliche Diagnose, auf die "Found in the Middle" antwortet; essenzielle Hintergrundlektüre.

Das Paper​

ReDAct (Reason-Defer-Act) baut auf dem ReAct-Prompting-Paradigma auf und führt eine Zwei-Modell-Agenten-Architektur ein. Ein kleines, günstiges Modell – Qwen3-80B, Llama3.3-70B oder Llama4-Maverick – übernimmt standardmäßig jeden Schritt. Bei jedem Schritt generiert es eine Gedankenkette (Reasoning Trace) und anschließend eine Aktion. Das System misst die Unsicherheit auf Token-Ebene nur über den Schritt der Aktionsgenerierung und vergleicht diese mit einem kalibrierten Schwellenwert. Wenn die Unsicherheit diesen Schwellenwert überschreitet, wird der Schritt von einem großen, teuren Modell (GPT-5.2, Qwen3-235B oder Qwen3-480B) erneut ausgeführt; andernfalls wird die Aktion des kleinen Modells ausgeführt.

Die Unsicherheitsmaße sind informationstheoretisch und erfordern nur Log-Wahrscheinlichkeiten auf Token-Ebene: Sequenzwahrscheinlichkeit (summierte negative Log-Wahrscheinlichkeit), Perplexität (längennormalisiert) und mittlere Token-Entropie (durchschnittliche Entropie über Token-Positionen hinweg). Der Schwellenwert wird anhand eines separaten Satzes von Rollouts des kleinen Modells kalibriert, indem der Wert gewählt wird, der eine Zielanzahl von Aufrufen des großen Modells pro Episode K erzeugt.

Kernideen​

• Unsicherheit beim Aktionsschritt messen, nicht beim Gedankengang. Ein Hilfsexperiment mit 2.411 ALFWorld-Schritten ergab, dass die Unsicherheit auf Reasoning-Ebene eine geringe Trennschärfe zwischen korrekten und inkorrekten Schritten aufweist; die Perplexität auf Aktionsebene hat als Prädiktor für die Korrektheit eine messbar höhere ROC-AUC und PRR.
• PPL-Weiterleitung mit Qwen3-80B + GPT-5.2 erreicht 80,8 % ± 1,1 % auf ALFWorld und übertrifft damit GPT-5.2 allein (78,3 % ± 1,9 %), bei Kosten von 16,25 $ gegenüber 45,21 $ – etwa 64 % günstiger.
• ~15 % der Schritte werden in der Praxis weitergeleitet, um ein Kalibrierungsziel von etwa 10 % zu erreichen; die Differenz entsteht, weil fehlgeschlagene (kürzere) Trajektorien überproportional zum Weiterleitungsbudget beitragen.
• Zufällige Weiterleitung bei gleicher Rate erzielt 77,0 % – immer noch besser als nur das kleine Modell (68,3 %), aber schlechter als UQ-gesteuerte Weiterleitung. Das Unsicherheitssignal ist tatsächlich von Bedeutung, nicht nur der Akt, das große Modell häufiger aufzurufen.
• MiniGrid zeigt weniger Spielraum. Qwen3-80B + GPT-5.2 mit PPL-Weiterleitung erreicht 95,0 % gegenüber 99,0 % für GPT-5.2 allein. Das kleinere Aufgabenvokabular schafft eine härtere Obergrenze für den Weiterleitungsansatz, wenn das kleine Modell strukturell unzureichend ist.
• Die Verteilung der Weiterleitungen ist aufgabenabhängig. ALFWorld leitet in späteren Schritten (längere Prompt-Historie) häufiger weiter, während MiniGrid ein bimodales Muster zeigt, das an die ursprüngliche Position des Agenten gebunden ist. Dies bedeutet, dass eine feste Schwellenwertkalibrierung innerhalb einer Aufgabenfamilie besser generalisiert als über Aufgabenfamilien hinweg.

Was Bestand hat – und was nicht​

Das zentrale empirische Ergebnis ist glaubwürdig: Die Perplexität über den Aktionsstring ist ein vernünftiger Proxy dafür, ob ein bestimmter Schritt kurz davor steht, schiefzugehen. Die Reasoning/Acting-Dekomposition in ReAct bietet von Natur aus einen sauberen Punkt, um ein Unsicherheitssignal anzubringen, und das Hilfsexperiment zur Korrektheitsvorhersage liefert eine echte mechanistische Rechtfertigung für die Designentscheidung.

Was mich weniger überzeugt: das Ergebnis „übertrifft das große Modell allein“ auf ALFWorld. 80,8 % ± 1,1 % vs. 78,3 % ± 1,9 % überschneiden sich bei einer Standardabweichung. Die Autoren führen dies auf komplementäre Stärken zurück – das kleine Modell erledigt Routineaufgaben ohne die gelegentliche Risikobereitschaft des großen Modells –, aber es gibt keine Ablationsstudie pro Schritt, um diese Erzählung zu verifizieren. Es könnte genauso gut Rauschen sein.

Die Wahl des Benchmarks ist ebenfalls einschränkend. ALFWorld und MiniGrid sind textbasierte Haushaltssimulationen und Gitterwelt-Navigationen – enge Umgebungen, in denen Tool-Aufrufe, Code-Ausführung oder Multi-Dokument-Retrieval nicht erprobt werden. Ob eine unsicherheitskalibrierte Weiterleitung in diesen reichhaltigeren Umgebungen (den für Beancount relevanten Umgebungen) Bestand hat, bleibt unbeantwortet. Und die Wahl von GPT-5.2 als großes Modell macht die Kostenzahlen schwer reproduzierbar.

Das Kalibrierungsverfahren weist eine nicht adressierte Zirkularität auf: Der Schwellenwert wird auf derselben Verteilung ausgewählt, auf der er kalibriert wurde, ohne Validierung an einem zurückgehaltenen Datensatz. Die Autoren räumen eine Verteilungsverschiebung zwischen Kalibrierung (Rollouts des kleinen Modells) und Evaluierung (Hybrid-Rollouts) ein, überlassen die Robustheit des Schwellenwerts jedoch zukünftigen Arbeiten.

Warum dies für Finanz-KI wichtig ist​

Beancount-Write-Back-Agenten stehen bei jeder Transaktion vor genau derselben Weiterleitungsfrage. Ein routinemäßiger Lebensmitteleinkauf erfordert eine Kategorisierung; ein ungewöhnlicher mehrstufiger Fremdwährungsswap mit einem nur teilweise übereinstimmenden Verwendungszweck benötigt einen Menschen. Die aktuelle Praxis ist entweder volle Automatisierung (riskant) oder vollständige menschliche Überprüfung (teuer). Das Framework von ReDAct schlägt einen praktikablen Mittelweg vor: Das günstige Modell ausführen und eskalieren, wenn die Perplexität über den potenziellen Journaleintrag einen kalibrierten Schwellenwert überschreitet.

Der Finanzkontext fügt zwei Überlegungen hinzu, die das Paper nicht anspricht. Erstens sollte Weiterleitung hier oft bedeuten, einzuhalten und den Benutzer zu fragen, anstatt ein größeres LLM aufzurufen – der Standard für die Korrektheit des Ledgers ist die Absicht des Benutzers, nicht ein Benchmark-Score. Zweitens ist die Irreversibilität eines festgeschriebenen Beancount-Eintrags höher als ein falsch platzierter Gegenstand in ALFWorld. Das Kalibrierungsziel K sollte wahrscheinlich konservativ auf eine geringere Präzision beim kleinen Modell abgestimmt werden, bevor weitergeleitet wird, und nicht umgekehrt.

Das Signal der Kostensenkung um 64 % ist trotz dieser Vorbehalte ernst zu nehmen. Wenn ein Beancount-Agent die Transaktionen eines Monats verarbeitet und nur 15 % der Kategorisierungsentscheidungen das teure Modell benötigen, sieht die Wirtschaftlichkeit des Betriebs eines fähigen Write-Back-Agenten deutlich besser aus.

Was man als Nächstes lesen sollte​

• KnowNo (Ren et al., 2023, CoRL): „Robots that ask for help: uncertainty alignment for large language model planners“ – verwendet konforme Vorhersagen, um eine Abdeckungsgarantie dafür zu kalibrieren, wann um Hilfe gebeten werden muss. ReDAct vergleicht sich nicht damit; das Verständnis des Kompromisses zwischen konformen Garantien und Schwellenwertkalibrierung ist wichtig, bevor man sich für einen Produktionsansatz entscheidet. [arXiv:2307.01928]
• A Survey of Confidence Estimation and Calibration in Large Language Models (Guo et al. aktualisiert, NAACL 2024) – systematische Taxonomie von verbalisiertem Vertrauen, stichprobenbasierten und Post-hoc-Kalibrierungsmethoden; der theoretische Hintergrund für die Entscheidung, ob Perplexität der richtige Proxy für Unsicherheit ist oder ob eine kalibrierte Logit-Skalierung besser abschneiden würde. [arXiv:2311.08298]
• UALA: Uncertainty-Aware Language Agent (Han, Buntine, Shareghi) – wendet einen strukturell ähnlichen Unsicherheitsschwellenwert auf die Entscheidung zur Tool-Innvokation an (ein Tool aufrufen vs. sich auf das Modellwissen verlassen) und reduziert Tool-Aufrufe um über 50 %; die direkte Ergänzung zu ReDAct für die Tool-Nutzungs-Achse der Agentenunsicherheit. [https://uala-agent.github.io/]

Das Paper​

OpenHands (Wang et al., 2024; ICLR 2025) ist eine Open-Source-Plattform zur Erstellung und Evaluierung von LLM-Agenten, die als generalistische Softwareentwickler agieren. Unter der Leitung von Xingyao Wang und Graham Neubig sowie einem Team von 24 Autoren behauptet das Paper im Kern, dass die meisten bestehenden Agenten-Frameworks entweder zu forschungsspezifisch (fest codierte Aufgabenschleifen) oder zu produktionsspezifisch (Closed Source oder zweckgebunden) sind, um als gemeinsame Grundlage für die Forschungsgemeinschaft zu dienen. OpenHands versucht dies zu beheben, indem es eine standardisierte Laufzeitumgebung, eine saubere Agentenabstraktion und 15 integrierte Evaluierungsbenchmarks in einem MIT-lizenzierten Repository bereitstellt.

Die Laufzeitumgebung ist eine Docker-sandboxed Umgebung, die eine Bash-Shell, einen Jupyter IPython-Server und einen Playwright-gesteuerten Chromium-Browser enthält. Agenten interagieren über drei primäre Aktionstypen: IPythonRunCellAction für Python, CmdRunAction für Shell-Befehle und BrowserInteractiveAction für die Web-Navigation. Ein Primitiv zur Koordination mehrerer Agenten, AgentDelegateAction, ermöglicht es einem Hauptagenten, spezialisierte Sub-Agenten zu erzeugen. Das Standard-Backbone ist CodeAct – ursprünglich als eigenständiges Paper veröffentlicht, das argumentiert, dass Code der ideale vereinheitlichte Aktionsraum für LLM-Agenten ist – und die Plattform liefert mehrere Agenten-Implementierungen mit, darunter einen allgemeinen CodeActAgent und einen spezialisierten BrowsingAgent.

Kernideen​

• Code als universeller Aktionsraum: CodeAct konsolidiert alle Agentenaktionen (Dateibearbeitungen, API-Aufrufe, Datentransformationen) in Python oder Bash, sodass das LLM in demselben Medium logisch argumentieren kann, in dem es am intensivsten trainiert wurde. Dies umgeht die Sprödigkeit von JSON-Schemata, die Agenten mit Funktionsaufrufen oft plagen.
• Sandboxed Docker-Laufzeitumgebung: Jeder Agent läuft in einem isolierten Container, sodass Agenten frei beliebigen Code ausführen können, ohne den Host-Rechner zu gefährden – eine Voraussetzung für jeden produktiven Finanzagenten, dem echte Zugangsdaten anvertraut werden könnten.
• 15 Benchmarks in einem System: SWE-Bench Lite (Code-Reparatur), HumanEvalFix (Fehlerbehebung), WebArena (Web-Navigation), GPQA (Argumentation auf Graduiertenniveau), GAIA (allgemeine Problemlösung) und zehn weitere. Die Zusammenführung dieser Benchmarks verhindert selektive Evaluierungen.
• CodeActAgent + claude-3.5-sonnet erreicht 26 % auf SWE-Bench Lite und 79,3 % auf HumanEvalFix; BrowsingAgent erreicht 15,5 % auf WebArena – wettbewerbsfähiges Zero-Shot ohne aufgabenspezifisches Training.
• GAIA-Performance: 32,1 % mit GPTSwarm, weit unter dem menschlichen Baseline-Wert von 92 % – konsistent mit jedem anderen allgemeinen Agenten-Benchmark, der eine Lücke von 60–70 Punkten zwischen Mensch und Agent zeigt.
• Community-Skalierung: 71,4k GitHub-Sterne und über 188 Mitwirkende zum Zeitpunkt der ICLR-Einreichung; TheAgentCompany hat OpenHands als Evaluierungssystem übernommen, was ihm de facto den Status einer Benchmark-Infrastruktur verleiht.

Was Bestand hat – und was nicht​

Das Design der sandboxed Laufzeitumgebung ist solide Ingenieurskunst. Die Isolierung der Agenten-Ausführung in Docker ist der richtige Standard für jedes System, dem später Schreibzugriff auf echte Finanzhauptbücher gewährt werden könnte. Es ist zudem wirklich nützlich, dass die Benchmarks zusammengeführt sind, anstatt über inkompatible Repositories verstreut zu sein.

Die Abdeckung der Benchmarks ist jedoch eher aspirativ als systematisch. Die 15 Benchmarks umfassen extrem unterschiedliche Aufgabentypen und Schwierigkeitsgrade, ohne ein klares Framework dafür, wie Ergebnisse aggregiert oder verglichen werden sollten. Die Angabe von 26 % auf SWE-Bench Lite neben 79,3 % auf HumanEvalFix im selben Paper riskiert den Eindruck, dass derselbe Agent gleichzeitig mittelmäßig und exzellent ist – die Aufgaben sind schlicht nicht vergleichbar. Die Autoren bieten keine fundierte Methodik zur Aggregation über mehrere Benchmarks hinweg an.

Die CodeAct-Annahme – dass Code das richtige universelle Aktionsformat sei – ist umstritten. Sie funktioniert gut für Entwicklungsaufgaben, erzwingt aber eine Python/Bash-Vermittlungsschicht für jede Aktion. Dies erhöht die Latenz und führt zu Problemen, wenn die Aktionssemantik nicht sauber auf Code abgebildet werden kann (mehrdeutige Benutzeranweisungen, reine Natural-Language-APIs). Das Paper führt keine Benchmarks gegen Nicht-Code-Aktionsräume durch, um zu beweisen, dass der Vorteil real ist und nicht nur auf dem LLM-Backbone basiert.

Die wichtigste Lücke ist vielleicht die Kluft zwischen Evaluierung und Einsatz. Der Wert von 26 % bei SWE-Bench stammt aus einem relativ sauberen, gut spezifizierten Benchmark. Community-Berichte und GitHub-Issue-Threads beschreiben konsistent eine viel geringere Zuverlässigkeit bei mehrdeutigen oder langfristigen Aufgaben in der realen Welt – derselbe Fehlermodus, den TheAgentCompany dokumentiert hat. Das Paper befasst sich nicht damit, wie Robustheit unter realistischen Bedingungen mit ungenauen Aufgabenspezifikationen gemessen oder verbessert werden kann.

Warum dies für Finanz-KI wichtig ist​

OpenHands kommt einem gemeinsamen Agenten-Substrat in der Community am nächsten. Wenn Bean Labs eine Evaluierungsinfrastruktur für Beancount-Agenten aufbaut, ist die Laufzeitarchitektur hier – Docker-Sandbox, Python/Bash-Aktionen, austauschbare LLM-Backends – eine Übernahme wert, anstatt sie neu zu bauen. Das AgentDelegateAction-Primitiv lässt sich natürlich auf eine Finanzagenten-Pipeline übertragen, bei der ein Orchestrator auf oberster Ebene an spezialisierte Sub-Agenten delegiert: einer für das Lesen des Hauptbuchs, einer für die Kennzeichnung von Anomalien, einer für einen vorgeschlagenen Rückschreibvorgang, den ein Mensch prüft.

Die Zahlen von SWE-Bench und TheAgentCompany etablieren zusammen eine ernüchternde Ausgangslage: Selbst die besten verfügbaren Agenten erledigen etwa 26–30 % der realistischen, eindeutigen Softwareaufgaben. Die Automatisierung von Finanzbüchern ist schwieriger – Transaktionen sind oft mehrdeutig, die Auswirkungen von Fehlern sind real und die Absichten der Benutzer sind häufig unterdefiniert. Die richtige Schlussfolgerung ist nicht, dass Agenten nicht bereit sind, sondern dass die ersten produktiven Einsätze eng gefasste Write-Once-Workflows (Kategorisierungsvorschläge, Kennzeichnung von Abstimmungen) sein werden, anstatt autonomer mehrstufiger Bearbeitungen des Hauptbuchs.

Was man als Nächstes lesen sollte​

• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — paart ein günstiges Modell mit einem teuren und delegiert nur dann an das teure Modell, wenn die Unsicherheit hoch ist; befasst sich direkt damit, wie ein Agent im OpenHands-Stil entscheiden sollte, wann er eine Beancount-Rückbuchung zur menschlichen Überprüfung eskaliert.
• FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Tasks (arXiv:2604.10015) — 800 von Experten annotierte Aufgabensequenzen in 34 Finanzszenarien; die Evaluierungsmethodik für finanzspezifische, langfristige Tool-Nutzung, die OpenHands fehlt.
• FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol (arXiv:2603.24943) — 613 Proben aus 65 echten MCP-Finanzwerkzeugen, direkt relevant dafür, wie ein auf der OpenHands-Laufzeit basierender Beancount-Agent in einem realen MCP-Einsatz evaluiert würde.

Das Paper​

Fin-RATE, im Februar 2026 von Yidong Jiang, Junrong Chen und Kollegen der Yale University sowie kooperierenden Institutionen veröffentlicht, führt einen Benchmark ein, der auf 2.472 SEC-Filings von 43 Unternehmen aus 36 Branchen im Zeitraum 2020–2025 basiert. Der Benchmark organisiert 7.500 Experten-kuratierte QA-Paare in drei Aufgabentypen, die professionelle Analysten-Workflows widerspiegeln: DR-QA (Details und Schlussfolgerungen innerhalb eines einzelnen Berichts), EC-QA (unternehmensübergreifender Vergleich zweier Firmen zu einem gemeinsamen Thema) und LT-QA (longitudinale Verfolgung desselben Unternehmens über Berichtsperioden hinweg). Jeder Aufgabentyp umfasst 2.500 Fragen. Die Evaluierung erstreckt sich über 17 LLMs – Closed-Source-Modelle wie GPT-4.1 und GPT-5, Open-Source-Allgemeinmodelle wie DeepSeek-V3 und Llama-3.3-70B sowie finanzspezialisierte Modelle wie Fin-R1, Fino1-14B, FinanceConnect-13B und TouchstoneGPT-7B. Die Bewertung erfolgt über ein einheitliches LLM-als-Richter-Framework mit drei unabhängigen Richtern (GPT-5, DeepSeek-V3.2, Qwen3-235B), die jede Antwort hinsichtlich Korrektheit und fünf analytischen Dimensionen bewerten.

Kernideen​

• Die Leistung bricht mit zunehmender Aufgabenkomplexität ein: Die Genauigkeit sinkt im Durchschnitt aller 17 Modelle um 18,60 % vom Einzeldokument-DR-QA zum longitudinalen LT-QA und um 14,35 % vom DR-QA zum unternehmensübergreifenden EC-QA.
• GPT-5 mit Websuche ist der Spitzenreiter, erreicht jedoch eine maximale Genauigkeit von nur 43–44 % über alle drei Aufgabentypen hinweg – ein klägliches Ergebnis für einen Benchmark, der reale Analysten-Workflows abbilden soll.
• Fin-R1, das auf Finanzwesen spezialisierte Reasoning-Modell, erreicht 57,48 % bei DR-QA, bricht aber bei EC-QA auf 3,32 % ein – ein Rückgang um 54 Punkte, der die Verschlechterung jedes allgemeinen Modells bei weitem übertrifft.
• Unter RAG-Bedingungen fällt die Leistung aller Modelle deutlich unter 27 %, verglichen mit einer Gold-Kontext-Leistung von bis zu 57,48 %; die Retrieval-Pipeline und nicht das LLM ist der entscheidende Engpass.
• Das Paper führt eine Fehlertaxonomie mit 13 Typen in vier Kategorien ein: Halluzinationen und Widersprüche, finanzspezifische numerische und semantische Fehler, Fehler beim Verständnis von Abfragen/Kontext und Fehler auf Retrieval-Ebene. Fehlende Beweise (Missing Evidence) machen 75,44 % der Fehler bei der EC-QA-Aufgabe unter RAG aus.
• Finanzspezialisierte Modelle zeigen bei komplexen Aufgaben systematisch höhere Halluzinationsraten als allgemeine Modelle, trotz besserer Finanzterminologie.

Was Bestand hat – und was nicht​

Die Struktur mit drei Pfaden ist wirklich gut durchdacht. Die meisten Finanz-Benchmarks (FinQA, TAT-QA, FinanceBench) behandeln QA als Einzeldokument-Aufgabe. Fin-RATE ist einer der ersten, der unternehmensübergreifende Vergleiche und longitudinale Verfolgung explizit als erstklassige Aufgaben modelliert. Die Ergebnisse legen eine fundamentale Lücke offen: Aktuelle LLMs bewältigen isolierte QA zu Offenlegungen passabel, scheitern aber in dem Moment, in dem sie Informationen über Dokumente, Einheiten oder Zeiträume hinweg synthetisieren müssen.

Der Einbruch von Fin-R1 ist die auffälligste Erkenntnis des Papers und wird meiner Meinung nach unterschätzt. Ein für den Finanzbereich optimiertes Modell, das bei der Extraktion aus Einzeldokumenten glänzt, hat sich offenbar in eine Sackgasse trainiert: Es hat Vorlagen für die Beantwortung innerhalb eines Dokuments gelernt, aber keine Reasoning-Strategien, um Einheiten und Zeiträume in Beziehung zu setzen. Dies ist eine konkrete Warnung vor eng gefasstem Domänen-Feintuning ohne explizite Überwachung des multidokumentären Reasonings. Das Modell hat sich wahrscheinlich auf das flache Muster "finde die Zahl im Bericht" überfokussiert und besitzt keinen Verallgemeinerungspfad für "vergleiche diese Zahl mit der entsprechenden Zahl in einem anderen Bericht eines anderen Unternehmens".

Dennoch gibt es methodische Bedenken. GPT-5 ist gleichzeitig eines der evaluierten Modelle und einer der drei Richter, die Antworten bewerten. Die Autoren nutzen drei Richter, um individuelle Voreingenommenheit zu reduzieren, was hilft, aber die Überschneidung von Richter und Modell beim stärksten evaluierten Modell ist unangenehm. Das Paper berichtet von einer hohen Übereinstimmung zwischen den Richtern, quantifiziert jedoch nicht separat, welcher Anteil der GPT-5-Antworten von GPT-5 selbst bewertet wurde oder ob die Selbstbewertungen von GPT-5 systematisch von den anderen beiden Richtern abweichen. Jeder Selbstbewertungs-Bias würde das Gesamtergebnis für das leistungsstärkste Modell der Studie aufblähen.

Die Stichprobe von 43 Unternehmen ist zudem dünn. Die Abdeckung der Berichtstypen ist lobenswert breit (10-K, 10-Q, 8-K, 6-K, DEF 14A sowie mehrere S- und SC-Serien), aber dieselben 43 Unternehmen tauchen in allen Aufgaben auf. Modelle, die die Offenlegungen dieser Unternehmen bereits im Pre-Training gesehen haben, besitzen einen unquantifizierten Vorteil, und das Paper enthält keine Kontaminationsanalyse.

Die Erkenntnis zum Retrieval ist wichtig, aber unvollständig. Das Paper stellt fest, dass die RAG-Leistung im Vergleich zum Gold-Kontext um etwa 30 Punkte einbricht, weil das Retrieval fehlschlägt. Es wird jedoch nur ein einziges Retrieval-Setup getestet – das Scheitern des Retrievals wird eher als Diagnose denn als systematisch zu variierende Variable behandelt. Ein Folge-Paper, das verschiedene Retrieval-Architekturen auf Fin-RATE untersucht, wäre weitaus handlungsrelevanter.

Warum dies für Finanz-KI wichtig ist​

Ein Beancount-Ledger-Audit benötigt genau die beiden Fähigkeiten, die laut Fin-RATE fehlerhaft sind: longitudinale Verfolgung (wie hat sich dieses Konto über die Geschäftsjahre entwickelt?) und unternehmensübergreifender Vergleich (lässt sich die Bilanz dieser Tochtergesellschaft mit dem Konzernabschluss abgleichen?). Der Genauigkeitsabfall von 18,60 % bei der zeitlichen Verfolgung ist eine konkrete Zahl, die die Erwartungen an jeden Beancount-Agenten kalibrieren sollte, der über mehrere Berichtsperioden hinweg schlussfolgert. Wenn Frontier-Modelle bei 43 % unter Gold-Kontext-Bedingungen in der longitudinalen SEC-QA scheitern, sollte ein Beancount-Agent, der durch mehrjährige Ledger-Historien navigiert, mit explizitem Retrieval, zeitlicher Fundierung und menschlicher Eskalation konzipiert werden – nicht mit End-to-End-LLM-Inferenz.

Die Erkenntnis über die Dominanz des Retrievals ist vor allem für die Priorisierung des Systemdesigns von Bedeutung. Wenn die Leistung im Gold-Kontext fast doppelt so hoch ist wie die RAG-Leistung, liegt die richtige Investition in besserem Chunking, Passagenselektion und Retrieval – nicht in einem leistungsfähigeren Backbone-LLM. Dies spiegelt wider, was DocFinQA für SEC-Filings mit langem Kontext feststellte: Die Pipeline um das Modell herum ist der Engpass.

Die Warnung bezüglich Fin-R1 gilt auch direkt für den Beancount-Anwendungsfall. Ein Feintuning auf Beancount-DSL-Syntax und Transaktionsmuster kann ein Modell hervorbringen, das die einfache Generierung von Einträgen gut beherrscht, aber bei der konten- und periodenübergreifenden Abstimmung scheitert, die ein Audit erst nützlich macht. Spezialisierung ohne Training für multidokumentäres Reasoning ist genau in der Weise fragil, wie Fin-RATE es misst.

Was man als Nächstes lesen sollte​

• Fin-R1 (arXiv:2503.16252) – um zu verstehen, welches Trainings-Setup eine so instabile dokumentübergreifende Leistung hervorbrachte und ob multidokumentäres Reasoning jemals vorgesehen war.
• FinTrace (arXiv:2604.10015) – Evaluierung der Tool-Aufrufe von LLMs auf Trajektorienebene über 34 Finanzaufgabenkategorien; ergänzt die statische QA-Sicht von Fin-RATE um eine Diagnose auf Prozessebene, wo Modelle zwar die richtigen Tools aufrufen, aber das Reasoning über die Ergebnisse misslingt.
• OpenHands (arXiv:2407.16741) – die offene Agentenplattform, die den Evaluierungen von TheAgentCompany zugrunde liegt; das Verständnis ihrer Architektur klärt, welche Basis-Agentenfähigkeiten verfügbar waren und welche Lücken eher der Aufgabenschwierigkeit als Plattformlimitierungen zuzuschreiben sind.

Das Paper​

Chanyeol Choi, Jihoon Kwon und Kollegen einer Finanz-KI-Firma präsentieren einen Datensatz aus 5.703 expertenannotierten Tripletts aus Anfrage, Evidenz und Antwort, die von einem realen Q&A-Service für Hedgefonds-Analysten stammen. Die Dokumente sind Form 10-K-Berichte von 490 S&P 500-Unternehmen, die von SEC EDGAR gesammelt wurden. Was FinDER von früheren Benchmarks unterscheidet, ist die Abfrageseite: 89,86 % der Anfragen enthalten drei oder mehr domänenspezifische Abkürzungen oder Akronyme. Statt „Wie hoch war der Gesamtumsatz von Unternehmen X für das Geschäftsjahr 2023?“ würde ein echter Analyst eher tippen: „GOOGL 10-K FY23 revs breakdown by segment“. Der Datensatz wurde auf dem ICLR 2025 Workshop on Advances in Financial AI veröffentlicht und erschien später auf der ICAIF 2025.

Kernideen​

• Der Retrieval-Recall ist durchgehend schockierend niedrig: E5-Mistral (der beste dichte Retriever) erreicht insgesamt nur 25,95 % Kontext-Recall; BM25 schafft 11,68 %. Die Kategorie „Financials“ – die für die Buchhaltung relevanteste – ist am schwierigsten: 15,84 % bzw. 6,42 %.
• Abfrage-Ambiguität allein kostet 8,2 Präzisionspunkte: Beim Testen von E5-Mistral mit 500 Anfragen vergleichen die Autoren wohlgeformte Paraphrasen (33,9 Präzision) mit den realen, abgekürzten Anfragen (25,7 Präzision). Die Lücke ist vollständig auf den Umgang mit Abkürzungen/Akronymen zurückzuführen, nicht auf die Komplexität der Dokumente.
• Die Retrieval-Qualität ist der dominierende Flaschenhals für die Generierung: LLMs ohne Kontext erzielen nahezu null Punkte (9–10 % korrekt); mit den Top-10 abgerufenen Passagen erreichen sie 29–34 %; mit perfektem „Oracle“-Kontext springen sie auf 60–68 %. Diese 35-Punkte-Lücke zwischen realistischen und Oracle-Bedingungen ist größer als der Unterschied zwischen Open-Source- und Frontier-Modellen.
• Kompositionelle Arithmetik scheitert selbst bei gutem Retrieval: Aufgaben mit mehrstufigen Berechnungen (kompositionelle Abfragen) erreichen bei allen vier Modellen – Claude-3.7-Sonnet, GPT-o1, DeepSeek-R1-Distill und Qwen-QWQ – nur ca. 20 % Korrektheit, selbst mit den Top-10 abgerufenen Passagen. GPT-o1 führt bei Multiplikationsaufgaben mit 42,90 %, fällt aber bei Division auf 27,78 % ab.
• LLM-Reranking bringt moderate, aber konsistente Verbesserungen: Wenn man Modelle die Top-10-Treffer von E5-Mistral vor der Beantwortung neu bewerten lässt, erreicht Claude-3.7-Sonnet einen F1-Wert von 63,05 und GPT-o1 62,90. Deepseek-R1-Distill liegt mit 60,01 dahinter, trotz starker Leistungen bei strukturiertem logischem Schließen in anderen Bereichen.
• Die Schwierigkeit der Kategorien ist ungleichmäßig: Risiko-Abfragen sind am einfachsten abzurufen (E5-Mistral: 33,07 Recall); Finanzen bleiben am schwierigsten (15,84). Dies korreliert mit der Abfragestruktur – Risiko-Offenlegungen nutzen natürliche Sprache, Finanztabellen nutzen dichte numerische Notation.

Was Bestand hat – und was nicht​

Der Kernbeitrag ist solide: Dies ist eine reale Abfrageverteilung von arbeitenden Analysten, und das Abkürzungsproblem ist echt. Jeder Benchmark, der auf Wikipedia oder Crowdsourcing im FinQA-Stil basiert, übersieht dies. Die dreistufige Evaluierungsstruktur – kein Kontext, realistisches Retrieval, Oracle-Kontext – ist das richtige Design; sie trennt die Retrieval-Qualität sauber von der Qualität des logischen Schließens und zeigt die verbleibende Generierungslücke (immer noch ~32–34 % Fehlerquote selbst bei perfektem Kontext bei qualitativen Fragen).

Die größte Schwäche des Papers ist die Reproduzierbarkeit. Zum Zeitpunkt der Veröffentlichung war der Datensatz nicht öffentlich verfügbar – die Autoren geben an, dass sie planen, ihn „zu einem späteren Zeitpunkt öffentlich freizugeben“. Dies ist ein erhebliches Problem für ein Workshop-Paper, das sich als Evaluierungsstandard präsentiert. Benchmarks, die nicht veröffentlicht werden, sind keine Benchmarks, sondern Fallstudien. Da es inzwischen auf der ICAIF 2025 erschienen ist, könnte die Veröffentlichung gefolgt sein, aber die arXiv-Version bestätigt dies nicht.

Die Retrieval-Evaluierung nutzt zudem nur vier einstufige Modelle (BM25, GTE, mE5, E5-Mistral). Es gibt kein hybrides Retrieval, keine Query Expansion, kein HyDE, keinen Umschreibungsschritt, der speziell auf das Abkürzungsproblem abzielt. Da die Autoren die Abkürzungslücke präzise charakterisiert haben, ist es überraschend, dass sie die naheliegende Lösung nicht testen: die Erweiterung der Abfrage („GOOGL“ → „Alphabet Inc.“) vor dem Retrieval. Dieses Experiment fehlt.

Die Generierungsergebnisse verdienen eine genauere Betrachtung. Die ~9–10 % Leistung ohne Kontext sind keine nützliche Untergrenze – es ist praktisch null –, aber die 60–68 % Oracle-Obergrenze ist informativer als sie scheint. Selbst mit der korrekten Passage in der Hand scheitern die besten Modelle bei etwa einem Drittel der qualitativen Fragen und vier Fünfteln der kompositionellen Arithmetik. Diese Obergrenze ist wichtig: Sie bedeutet, dass Retrieval allein das Problem nicht lösen kann.

Warum das für Finanz-KI wichtig ist​

Die Abfrageverteilung in FinDER lässt sich gut darauf übertragen, wie Beancount-Nutzer tatsächlich mit einem Ledger-Agenten interagieren. Ein Nutzer, der seine Konten seit Jahren führt, wird abgekürzte, kontextbezogene Anfragen tippen – „AMZN card Q3 reimb?“ statt „Was sind die Rückerstattungen der Amazon-Kreditkarte im 3. Quartal?“. Standard-Embedding-Modelle werden daran scheitern, die richtigen Einträge abzurufen, da sie auf sauberem, natürlichsprachlichem Text trainiert wurden. Der Präzisionsabfall von 8,2 Punkten von sauberen zu realen Anfragen ist für den Bereich privater Buchhaltung wahrscheinlich noch konservativ geschätzt, wo idiosynkratische Kurzschreibweisen („Hausverw Geb“ für „Hausverwaltungsgebühr“) noch weiter von den Trainingsdaten entfernt sind als SEC-Standardabkürzungen.

Die 25,95 % Recall-Obergrenze bei E5-Mistral ist ein Weckruf: Jede Beancount-RAG-Pipeline muss einen großen Anteil an fehlender Evidenz einkalkulieren. Eine Implikation ist, dass Re-Retrieval mit hohem Recall (mehrere Durchgänge, diversifizierte Abfrageformulierungen) wichtiger ist, als den F1-Wert eines einzelnen Durchgangs zu pushen. Eine weitere ist, dass die Abfragenormalisierung – das Mapping von Nutzer-Kürzeln auf kanonische Kontonamen vor dem Retrieval – ein expliziter Vorverarbeitungsschritt sein sollte und nicht dem Embedding-Modell überlassen werden darf.

Die 20 % Genauigkeit bei kompositioneller Arithmetik selbst mit Oracle-Kontext ist ein separates Signal: Für Beancount-Berechnungsaufgaben ist der Flaschenhals das logische Schließen, nicht das Retrieval. PAL-artiges Offloading (Generierung von Python-Arithmetik statt Freitext-Berechnung) bleibt die richtige Antwort für numerische Aufgaben, ungeachtet dessen, wie gut das Retrieval wird.

Was man als Nächstes lesen sollte​

• Fin-RATE (arXiv:2602.07294) – der begleitende Benchmark für mehrperiodiges Tracking in SEC-Einreichungen; die Genauigkeit sinkt bei zeitlichen Aufgaben um 18,60 %, was das mehrjährige Beancount-Ledger-Problem direkt anspricht.
• IRCoT (arXiv:2212.10509, ACL 2023) – Verzahnung von Retrieval mit Chain-of-Thought-Reasoning; die mehrstufige Retrieval-Struktur adressiert direkt den niedrigen Einstufen-Recall, den FinDER aufzeigt.
• Query Expansion mit LLMs für domänenspezifisches Retrieval – noch deckt kein einzelnes Benchmark-Paper dies gut ab, aber die FinDER-Abkürzungslücke macht es zu einer Forschungspriorität erster Ordnung; die Suche nach „HyDE financial domain“ und „query expansion SEC filings 2025“ ist der richtige Ausgangspunkt.

Das Paper​

„Lost in the Middle: How Language Models Use Long Contexts“ von Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni und Percy Liang führt zwei gezielte Experimente durch: Multi-Dokument-Frage-Antwort-Systeme über NaturalQuestions-Open (mit 10, 20 und 30 abgerufenen Dokumenten) und synthetisches Key-Value-Retrieval (mit 75, 140 und 300 Paaren). In jedem Experiment variieren sie systematisch die Position des relevanten Dokuments oder Key-Value-Paares innerhalb des Eingabekontexts – Anfang, Mitte oder Ende – während alles andere gleich bleibt. Das Ergebnis ist eindeutig: Die Leistung folgt einer U-förmigen Kurve mit dem Tiefpunkt in der Mitte des Kontexts, und diese Kurve zeigt sich bei jedem getesteten Modell.

Kernaussagen​

• Die U-Form ist real und konsistent. In der 20-Dokumente-QA-Einstellung lag die Leistung an der ersten Position bei etwa 75 % und sank auf rund 55 % an Position 10, bevor sie sich an Position 20 wieder auf etwa 72 % erholte – ein Unterschied von ca. 20 Punkten zwischen den Rändern und der Mitte.
• Alle Modelle folgen demselben Muster. Die getesteten Modelle umfassen proprietäre und Open-Source-Modelle, kleine und große: GPT-3.5-Turbo (4K und 16K), GPT-4, Claude-1.3 (8K und 100K), MPT-30B-Instruct und LongChat-13B. Die U-Kurve trat bei jedem von ihnen auf, einschließlich Modellen, die explizit für erweiterte Kontextfenster vermarktet werden.
• Selbst Claude-1.3-100K ist nicht immun. Die 100K-Kontext-Variante verhielt sich wie die anderen. Ein langes Kontextfenster bedeutet nicht, dass das Modell tatsächlich gleichmäßig darauf achtet.
• Die Closed-Book-Baseline setzt eine ernüchternde Untergrenze. GPT-3.5-Turbo ohne Dokumente beantwortete 56,1 % der NaturalQuestions korrekt; mit Oracle-Zugriff auf nur das eine relevante Dokument erreichte es 88,3 %. Doch an den schlechtesten mittleren Positionen in der 20-Dokumente-Einstellung sank die Leistung unter die Closed-Book-Baseline – was bedeutet, dass das Hinzufügen von mehr Kontext aktiv schädlich war.
• Encoder-Decoder-Modelle (Flan-T5-XXL, Flan-UL2) sind innerhalb ihrer Trainingslänge robuster, fallen aber zurück, wenn der Kontext diese überschreitet. Der architektonische Unterschied ist von Bedeutung, aber beide Modelle bauen bei zunehmender Skalierung dennoch ab.
• Die Ursache ist das kausale Attention-Masking. Da jeder Token nur auf vorangehende Token achten kann, kumulieren Positionen ganz am Anfang mehr Aufmerksamkeit über das gesamte Modell hinweg als Positionen in der Mitte. Recency-Effekte ziehen das Ende des Kontexts ebenfalls nach oben.

Was Bestand hat – und was nicht​

Das experimentelle Design hier ist bewundernswert sauber: Die Position ist die einzige manipulierte Variable, die Aufgaben sind Standard-Benchmarks, und das Ergebnis repliziert sich über eine Vielzahl von Modellfamilien hinweg. Ich habe keine Einwände gegen das Kernergebnis.

Weniger überzeugend finde ich die Einordnung der Key-Value-Retrieval-Aufgabe als aussagekräftigen Proxy für die reale Nutzung. UUID-zu-UUID-Lookups testen, ob ein Modell einen auswendig gelernten String wiedergeben kann, nicht ob es zu logischem Schlussfolgern fähig ist. Die U-Kurve zeigt sich auch dort, was die Behauptung des Positions-Bias stärkt, aber es bedeutet auch, dass das Paper zwei verschiedene Phänomene vermischt: Retrieval-Genauigkeit bei Exact-Match-Aufgaben und Reasoning-Qualität über relevante Passagen. Ich wüsste gerne, ob die U-Form schlimmer oder besser wird, wenn das relevante Dokument mehrstufige Inferenzen vor der endgültigen Antwort erfordert, statt nur eine wörtliche Wiedergabe.

Es gibt zudem eine Lücke, welche die Autoren zwar größtenteils anerkennen, aber nicht schließen: Sie testen nie, ob Instruction-Fine-Tuning oder RLHF die Positionssensitivität verändert, sondern nur, ob ein größeres Kontextfenster dies tut. Da die Ursache architektonisch bedingt ist (kausales Masking), vermute ich, dass Instruction-Tuning das Problem nicht beheben wird, aber das Paper bestätigt dies nicht.

Warum das für Finance-KI wichtig ist​

Dieses Paper liefert die mechanistische Erklärung für ein empirisches Muster, auf das ich immer wieder stoße. DocFinQA scheiterte an langen SEC-Filings. IRCoT und FLARE rufen beide mehrere Passagen ab und verketten sie vor dem Reasoning. Jede RAG-Pipeline, die ich mir im Finanzkontext angesehen habe, wirft abgerufene Passagen sequenziell in den Prompt und hofft, dass das Modell die richtige beachtet.

Die Auswirkungen für Beancount-Agenten sind konkret. Wenn ein Agent zehn Ledger-Einträge als Kontext abruft, besteht bei den Einträgen an den Positionen 3–7 das höchste Risiko, ignoriert oder durch Halluzinationen verfälscht zu werden. Dies ist kein Retrieval-Problem – es ist ein Präsentationsproblem. Aus diesem Paper ergeben sich zwei Konsequenzen: Entweder man platziert die diagnostisch relevantesten Einträge an den Anfang (und das Ende), oder man verzichtet ganz auf die Verkettung und führt das Reasoning über jeweils eine Passage einzeln durch.

Das Ergebnis verkompliziert auch das Long-Context-LLM-Narrativ. Jedes Quartal kündigt ein neues Modell ein größeres Kontextfenster an. Dieses Paper besagt, dass ein langes Fenster nicht das bedeutet, was man denkt, wenn man Informationen gleichmäßig darin verteilt. Ein 128K-Kontext-Modell, das die relevante Transaktion an Position 60K vergräbt, ist schlechter als ein 4K-Kontext-Modell, das präzise die richtige Passage abruft.

Hinsichtlich der Sicherheit beim Rückschreiben (Write-Back-Safety) sind die Implikationen unbequem: Wenn das Modell gebeten wird, eine Ledger-Sitzung zusammenzufassen, und die relevante Regel „diese Transaktion nicht buchen“ in der Mitte eines langen System-Prompts erscheint, verhält sich das Modell möglicherweise so, als hätte es diese Regel nie gelesen.

Was man als Nächstes lesen sollte​

• "Found in the Middle: How Language Models Use Long Contexts Better via Plug-and-Play Positional Encoding" (Zhang et al., arXiv:2403.04797) – schlägt Multi-scale Positional Encoding (Ms-PoE) als trainingsfreie Lösung mittels RoPE-Skalierung vor; behauptet eine Verbesserung von bis zu 3,8 Punkten bei Zero-SCROLLS und adressiert damit direkt die U-Kurve.
• "Never Lost in the Middle: Mastering Long-Context Question Answering with Position-Agnostic Decompositional Training" (arXiv:2311.09198) – verfolgt den entgegengesetzten Ansatz und trainiert das Modell darauf, explizit positionsagnostisch zu sein; der Vergleich mit Ms-PoE klärt, ob Fine-Tuning oder Inferenz-Tricks der bessere Hebel sind.
• "Mitigate Position Bias in Large Language Models via Scaling a Single Dimension" (arXiv:2406.02536) – identifiziert die spezifische Dimension der positional hidden states, die für den Bias verantwortlich ist, und skaliert sie ohne erneutes Training; der bisher präziseste Lösungsvorschlag, relevant für den Einsatz bestehender Modelle ohne Retraining.

Das Paper​

Tiankai Yang, Yi Nian und Kollegen von der USC und Texas A&M führen AD-LLM ein (arXiv:2412.11142, ACL Findings 2025), den ersten Benchmark zur systematischen Evaluierung von LLMs über drei Paradigmen der Anomalieerkennung auf NLP-Datensätzen hinweg. Der Rahmen ist die Ein-Klassen-Klassifizierung: Die Trainingsdaten enthalten nur normale Stichproben, und das Modell muss zum Testzeitpunkt Anomalien markieren. Die fünf Datensätze – AG News, BBC News, IMDB Reviews, N24 News und SMS Spam – stammen alle aus Textklassifizierungsaufgaben, bei denen eine Kategorie als anomal festgelegt wurde. Das Paper vergleicht zwei LLMs, GPT-4o und Llama 3.1 8B Instruct, mit 18 traditionellen unüberwachten Baselines, die von End-to-End-Methoden (CVDD, DATE) bis hin zu zweistufigen Kombinationen aus Einbettung und Detektor (OpenAI-Embeddings + LUNAR, LOF, Isolation Forest usw.) reichen.

Kernideen​

• Zero-Shot-Erkennung funktioniert gut für Text. GPT-4o erzielt einen AUROC-Wert von 0,9293–0,9919 über die fünf Datensätze im Normal+Anomalie-Szenario; Llama 3.1 erreicht 0,8612–0,9487. Die beste traditionelle Baseline, OpenAI + LUNAR, liegt bei etwa 0,92 auf AG News – GPT-4o erreicht oder übertrifft dies ohne jegliches Training.
• Synthetische Augmentierung hilft konsistent, aber bescheiden. Durch LLMs generierte synthetische Stichproben verbessern die OpenAI + LUNAR Pipeline auf allen fünf Datensätzen. Auch die Augmentierung von Kategoriebeschreibungen verbessert die meisten Baselines, wenngleich die Gewinne ungleichmäßig sind – Llama 3.1 verbessert den AUROC bei IMDB Reviews um +0,07, aber andernorts sind die Ergebnisse geringer.
• Modellauswahl ist das schwächste Glied. GPT-o1-preview empfiehlt Modelle, welche die durchschnittliche Baseline-Performance auf den meisten Datensätzen übertreffen und gelegentlich an die beste Methode heranreichen (z. B. bei IMDB Reviews und SMS Spam). Aber es identifiziert nie zuverlässig den Spitzenreiter, und die Autoren räumen ein, dass die Empfehlungen auf vereinfachten Eingaben basieren, denen datensatzspezifische Statistiken fehlen.
• Die Lücke zwischen Open-Source und proprietären Modellen ist real. Der AUROC-Vorteil von GPT-4o gegenüber Llama 3.1 8B beträgt je nach Datensatz 4–13 Punkte, eine Differenz, die mit dem Muster in Veröffentlichungen zur tabellarischen Zero-Shot-Anomalieerkennung übereinstimmt.
• Der NLP-Anomalieerkennung fehlt noch immer ein definitiver Benchmark. Fünf Datensätze, die alle von Klassifizierungskorpora abgeleitet sind, sind wenig. Das begleitende NLP-ADBench-Paper (EMNLP Findings 2025) erweitert dies auf acht Datensätze und 19 Algorithmen, nutzt aber immer noch dieselbe Konstruktion (semantische Kategorie als Anomalie), die diese Aufgaben etwas künstlich macht.

Was Bestand hat – und was nicht​

Die Zero-Shot-Ergebnisse sind glaubwürdig. Die Verwendung von LLMs als Scorer ohne Feinabstimmung auf markierten Anomaliedaten ist wirklich nützlich, wenn die Anomalieklasse semantisch kohärent ist – eine Spam-Nachricht unterscheidet sich von einer legitimen Nachricht auf eine Weise, die ein gut trainiertes Sprachmodell versteht. Die AUROC-Zahlen sind hoch, und der Vergleich mit starken Baselines auf Basis von OpenAI-Einbettungen ist fair.

Der Umfang ist jedoch enger, als das Paper suggeriert. In allen fünf Datensätzen werden Anomalien als eine andere Themenkategorie kodiert – Spam gegenüber legitimen SMS, Nachrichten eines zurückgehaltenen Herausgebers gegenüber In-Distribution-Quellen. Das bedeutet, dass das LLM im Grunde eine Themenklassifizierung durchführt, eine Aufgabe, für die es explizit vortrainiert wurde. Der Benchmark enthält keine semantischen Anomalien innerhalb einer einzelnen Kategorie (z. B. ungewöhnliche Transaktionen innerhalb desselben Kontotyps), was genau die Art von Anomalie ist, die für die Finanzprüfung relevant ist.

Die Aufgaben zur Daten-Augmentierung und Modellauswahl werden auf denselben fünf Datensätzen evaluiert, sodass das Paper letztlich testet, ob LLMs leicht unterschiedliche Ausschnitte desselben engen Problems geringfügig verbessern können. Die Autoren listen offen sechs Einschränkungen auf – darunter, dass sie nur eine Untergruppe von LLMs testen, Few-Shot- und Fine-Tuning-Regime ausschließen und sich bei der Modellauswahl auf vereinfachte Eingaben verlassen –, was intellektuell ehrlich ist, aber auch zeigt, wie vorläufig dieser Benchmark ist.

Ein Ergebnis, das für Skeptiker erwähnenswert ist: Die AUPRC-Werte sind für beide Modelle wesentlich niedriger als die AUROC-Werte. Llama 3.1 erreicht bei BBC News einen AUROC von 0,8612, aber nur einen AUPRC von 0,3960, was das Klassen-Ungleichgewicht im Ein-Klassen-Setup widerspiegelt. In Kontexten der Hochpräzisionsprüfung ist AUPRC die aussagekräftigere Metrik, und hier ist das Bild weniger schmeichelhaft.

Warum das für Finanz-KI wichtig ist​

Die Agenda von Bean Labs umfasst zwei Anwendungsfälle für die Anomalieerkennung: das Erfassen ungewöhnlicher Buchungssätze in Echtzeit (tabellarisch, strukturiert) und das Markieren verdächtiger narrativer Texte in Rechnungen, Memos oder Support-Tickets (unstrukturiert, NLP). AD-LLM spricht den zweiten Fall direkt an und liefert uns eine realistische Obergrenze: GPT-4o kann Anomalien auf Themenebene in Texten mit einem AUROC von über 0,93 auf sauberen, ausgewogenen Datensätzen im Zero-Shot-Verfahren erkennen. Das ist ein nützlicher Ausgangswert, aber Anomalien in Buchungstexten sind subtiler – ein Rechnungsmemo, das eine Routinedienstleistung beschreibt, aber zu einem Kreditor gehört, der wegen verdächtiger Muster markiert wurde, ist kein Problem der Themenklassifizierung. Der Benchmark bietet einen Ausgangspunkt, keine fertige Lösung.

Das Ergebnis zur Modellauswahl ist separat für das Systemdesign interessant. Der Traum, ein LLM zu fragen "Welchen Anomaliedetektor soll ich für diesen Datensatz verwenden?" und eine zuverlässige Antwort zu erhalten, erfüllt sich noch nicht. Das bedeutet, dass die Wahl zwischen Feinabstimmung im Stil von AnoLLM, kausalem Prompting im Stil von CausalTAD oder einer klassischen Einbettungsmethode weiterhin menschliches Urteilsvermögen oder systematische empirische Evaluierung erfordert – sie kann nicht an einen LLM-Berater delegiert werden.

Was man als Nächstes lesen sollte​

• NLP-ADBench (arXiv:2412.04784, EMNLP Findings 2025) – der begleitende Benchmark derselben Gruppe, der acht Datensätze und 19 Algorithmen abdeckt; er bietet den breiteren Kontext klassischer Baselines, den der fünf Datensätze umfassende Rahmen von AD-LLM nicht bieten kann.
• Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey (arXiv:2409.01980, NAACL Findings 2025) – gibt einen Überblick über die gesamte Landschaft der LLM-basierten AD-Ansätze für Text-, Bild- und tabellarische Modalitäten; ordnet AD-LLM in das Verhältnis zu früheren Arbeiten ein.
• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) – das tabellarische Gegenstück; der Vergleich seines Likelihood-basierten Ansatzes mit der Prompt-basierten Zero-Shot-Strategie von AD-LLM verdeutlicht, welches Paradigma für Beancount-Buchungssätze besser geeignet ist.

Das Paper​

Wang et al. schlagen CausalTAD vor, eine Methode, die auf LLM-Anomaliedetektoren im Stil von AnoLLM aufsetzt und eine gezielte Änderung vornimmt: Anstatt Tabellenzeilen in zufälliger oder willkürlicher Spaltenreihenfolge zu serialisieren, erkennt sie kausale Abhängigkeiten zwischen den Spalten und ordnet diese so um, dass sie diesen Abhängigkeiten entsprechen, bevor das LLM die Zeile liest.

Das Paper besteht aus zwei Komponenten. Erstens, ein kausal gesteuertes Modul zur Spaltensortierung. Die Autoren adaptieren das COAT-Faktor-Extraktions-Framework: Ein LLM liest Spalten-Metadaten und Stichproben, um semantische Faktoren auf hoher Ebene zu extrahieren (bei Kreditkartentransaktionen könnte ein Faktor wie „Vergütung“ sowohl den Betrag als auch die Händlerspalten umfassen). Aus diesen Faktoren erstellen drei Algorithmen zur kausalen Entdeckung — PC, LiNGAM und FCI — jeweils einen gerichteten kausalen Graphen über die Faktoren. Das Problem der Spalten-Neusortierung wird dann zu einem linearen Ordnungsproblem (Linear Ordering Problem): Finde die Permutation π, die die Summe der Gewichte der gerichteten Kanten maximiert, sodass Ursachenspalten vor den Wirkungsspalten im serialisierten Text erscheinen. Da das LP viele nahezu optimale Lösungen hat, ziehen sie Stichproben von K ≈ 10 Sortierungen innerhalb von 90 % des Optimums und bilden den Durchschnitt über diese.

Zweitens, ein kausalitätsbewusstes Neugewichtungsmodul. Nicht alle Spalten sind gleichermaßen relevant. Eine Spalte, die viele Faktoren beeinflusst, erhält ein höheres Gewicht αj = |M⁻¹(cj)|, was der Anzahl der Faktoren entspricht, zu denen sie beiträgt. Der endgültige Anomalie-Score ist der gewichtete Durchschnitt der negativen Log-Likelihoods pro Spalte über die K Sortierungen hinweg.

Kernideen​

• Die Spaltensortierung ist ein nicht-trivialer induktiver Bias für autoregressive LLMs: Das Platzieren einer Ursachenspalte vor ihrer Wirkungsspalte ermöglicht es dem Modell, auf den korrekten Kontext zu konditionieren, wenn es der Wirkung eine Wahrscheinlichkeit zuweist.
• Kausale Entdeckung auf Faktorebene (statt auf der Ebene roher Spalten) ermöglicht es der Methode, Tabellen mit gemischten Datentypen zu verarbeiten, bei denen eine direkte kausale Entdeckung zwischen heterogenen Spalten fehleranfällig ist.
• In 6 Benchmark-Datensätzen mit gemischten Typen erreicht CausalTAD mit SmolLM-135M einen durchschnittlichen AUC-ROC von 0,834 im Vergleich zu 0,803 bei AnoLLM — eine absolute Verbesserung von 3,1 Punkten mit demselben Basismodell.
• Speziell beim Datensatz „Fake Job Posts“ erreicht CausalTAD 0,873 gegenüber 0,800 bei AnoLLM — ein relativer Gewinn von 9,1 %, was groß genug ist, um in einem realen Triage-System von Bedeutung zu sein.
• Über 30 numerische ODDS-Benchmark-Datensätze hinweg erzielt CausalTAD den besten durchschnittlichen AUC-ROC und übertrifft konsistent klassische Baselines (Isolation Forest, ECOD, KNN) sowie Deep-Learning-Methoden (DeepSVDD, SLAD).
• Alle drei Algorithmen zur kausalen Entdeckung schlagen die zufällige Sortierung in der Ablationsstudie; LiNGAM schneidet bei den gemischten Datentypen geringfügig besser ab als PC und FCI.

Was Bestand hat – und was nicht​

Die Kernbehauptung — dass eine kausale Spaltenreihenfolge hilft — ist gut belegt. Die Ablationsstudie ist sauber: Der Austausch der zufälligen Sortierung gegen eine der drei kausalen Entdeckungsmethoden verbessert die Ergebnisse beim Benchmark „Fake Job Posts“ (von 0,832 auf 0,870–0,873), und die Neugewichtung nach Faktoranzahl hilft in jeder Konfiguration weiter. Das ist eine glaubwürdige Argumentation.

Weniger überzeugend finde ich die Bootstrapping-Annahme. Der kausale Graph wird konstruiert, indem ein LLM verwendet wird, um semantische Faktoren aus genau den Daten zu extrahieren, die das System analysieren soll. Wenn das LLM die Domäne falsch versteht — etwa bei einem maßgeschneiderten Buchhaltungssystem mit unüblichen Spaltennamen — ist die Faktorextraktion fehlerhaft. Ein schlechter kausaler Graph ist womöglich schlimmer als eine zufällige Sortierung, da er einen systematischen Bias einführt. Die Autoren räumen dieses Risiko ein („hängt von der Fähigkeit der LLMs zur Faktorextraktion ab“), testen die Genauigkeit der Faktorextraktion jedoch nicht unabhängig.

Es gibt auch ein Problem mit dem Rechenaufwand, das schwerwiegender ist, als das Paper suggeriert. Das Ausführen von drei Algorithmen zur kausalen Entdeckung, das Lösen eines LP, das Sampling von K Sortierungen und die anschließende Inferenz bei K serialisierten Versionen jedes Testpunkts vervielfacht die Inferenzkosten um den Faktor K. Für ein Hauptbuch mit Millionen von Einträgen ist dies relevant. Das Paper merkt an, dass „zukünftige Arbeiten sich auf die Verbesserung der Effizienz konzentrieren könnten“, bietet aber kein konkretes Profiling an.

Schließlich sind die 30 numerischen ODDS-Datensätze gut untersucht und für Methoden wie diese wohl ausgereizt. Das aussagekräftigere Signal liegt in den 6 Datensätzen mit gemischten Typen — die für das Finanzwesen realistisch sind — und die dortigen Verbesserungen sind zwar real, aber in absoluten Zahlen eher moderat.

Warum das für Finanz-KI wichtig ist​

Beancount-Transaktionen haben eine echte kausale Struktur: Der Buchungsbetrag beeinflusst kausal die Kontenauswahl, das Konto bestimmt die Erwartung an die Gegenpartei, und der Buchungstext steht kausal am Ende dieser Kette. Eine zufällige Spaltenserialisierung ignoriert dies, was bedeutet, dass ein Modell im Stil von AnoLLM „memo: Lebensmittel | account: Ausgaben:Essen | amount: 4200 €“ genauso willkürlich sieht wie die korrekt geordnete Version.

CausalTAD bietet eine strukturierte Möglichkeit, „Betrag und Konto kommen zuerst“ zu kodieren, ohne dies als feste Regel festzuschreiben. Für Bean Labs Audit-Agenten legt dies eine praktische architektonische Entscheidung nahe: Bevor ein Stapel von Transaktionen auf Anomalien geprüft wird, führt man einen Durchlauf durch, um den kausalen Graphen über das Spaltenschema des Hauptbuchs zu ermitteln, und verwendet diese feste Reihenfolge für alle folgenden Inferenzen. Der Aufwand fällt nur einmal auf Schema-Ebene an, nicht pro Transaktion.

Das Beispiel der Kreditkarten-Betrugserkennung im Paper hat im Wesentlichen dieselbe Aufgabenstruktur wie die Anomalieerkennung im Hauptbuch: heterogene Merkmale, seltene Labels und eine kausale Ordnung, die Domänenexperten intuitiv kennen, die LLMs aber ansonsten ignorieren würden.

Was man als Nächstes lesen sollte​

• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — der systematische Benchmark über drei LLM-Anomalieerkennungs-Paradigmen hinweg, in den sich CausalTAD einfügt; die Lektüre bietet einen Gesamtüberblick statt nur des Vergleichs zwischen AnoLLM und CausalTAD.
• COAT: Boosting Large Language Model-Based In-Context Learning for Tabular Data (Liu et al., 2024) — das Framework zur Faktorextraktion, das CausalTAD adaptiert; zu verstehen, wie es funktioniert, verdeutlicht, an welchen Stellen die Qualität des kausalen Graphen scheitern kann.
• Causal discovery in heterogeneous data: a survey — zum Verständnis der relativen Vorzüge von PC gegenüber LiNGAM und FCI bei Tabellendaten mit gemischten Typen, da das Paper alle drei als austauschbar behandelt, sie aber unterschiedliche Unabhängigkeitsannahmen treffen.

Das Paper​

AnoLLM definiert die tabellarische Anomalieerkennung als Dichteschätzung eines Sprachmodells neu, anstatt als prompte-basierte Klassifizierung. Anstatt das LLM zu fragen, welche Zeilen verdächtig aussehen, führen die Autoren ein Feintuning eines vorab trainierten Sprachmodells auf serialisierten In-Distribution-Trainingszeilen (normalen Zeilen) durch. Anschließend wird jede Testzeile anhand ihrer negativen Log-Likelihood (NLL) unter dieser gelernten Verteilung bewertet. Eine Zeile, die der Trainingsverteilung überhaupt nicht ähnelt, erhält einen hohen NLL-Wert – das ist der Anomalie-Score. Kein Indexformat, kein Parsen der Ausgabe, keine fehleranfällige Regex-Extraktion.

Die Serialisierung wandelt jede Tabellenzeile in einen natürlichsprachlichen String mit Merkmalsnamen und -werten um. Bei textbasierten Spalten wird die NLL pro Spalte normalisiert, um einen Längen-Bias zu vermeiden, da längere Beschreibungen sonst mechanisch höhere Wahrscheinlichkeitskosten akkumulieren würden. Bei numerischen und kategorialen Spalten wird die rohe NLL auf Token-Ebene über das Feld summiert. Das Modell wird in einem semi-überwachten Setting feinabgestimmt – nur als normal gekennzeichnete Zeilen fließen in das Training ein – für bis zu 2.000 Schritte unter Verwendung von verteiltem GPU-Training.

Kernideen​

• Das Problem des Ausgabeformats: Frühere Ansätze zur Index-Vorhersage erfordern, dass LLMs zuverlässig anomale Zeilenindizes aus einem Batch ausgeben. Modelle der Llama-Familie paaren häufig falsche Indizes mit Werten, generieren Indizes außerhalb der Batch-Größe oder listen einfach alles als anomal auf. NLL umgeht dies vollständig.
• AnoLLM erzielt die beste Leistung auf sechs Benchmark-Datensätzen mit gemischten Merkmalsstypen, darunter Datensätze zur Erkennung von Kfz-Versicherungsbetrug und E-Commerce-Betrug von Kaggle.
• Auf den 30 überwiegend numerischen ODDS-Benchmark-Datensätzen schneidet AnoLLM gleichwertig mit den besten klassischen Baselines ab – nicht deutlich besser, aber wettbewerbsfähig.
• Die NLL-Normalisierung pro Spalte für Textmerkmale ist eine kleine, aber entscheidende technische Entscheidung: Ohne sie würde eine Transaktionsbeschreibung mit dreißig Token den Score gegenüber einem zweistelligen Betrag dominieren, was ein falscher induktiver Bias wäre.
• Kontext der Trainings-Baseline: Der Zero-Shot-GPT-4-Ansatz (arXiv:2406.16308) erreicht eine durchschnittliche AUROC von 74,1 auf ODDS, vergleichbar mit ECOD (75,5) und KNN (70,7). Der Vorteil von AnoLLM zeigt sich spezifisch bei Datensätzen, in denen Text und kategoriale Merkmale aussagekräftige Anomaliesignale enthalten.

Was Bestand hat – und was nicht​

Die Kernidee der NLL ist fundiert. Die Verwendung eines feinabgestimmten Sprachmodells als Dichteschätzer über serialisierte Zeilen ist prinzipientreu und verarbeitet die gemeinsame Verteilung aller Spalten gleichzeitig – etwas, das klassische unüberwachte Detektoren, die Spalte für Spalte angewendet werden, nicht sauber leisten können. Die Lösung für die Index-Vorhersage ist wirklich nützlich und der Vergleich mit der Zero-Shot-Baseline ist fair.

Was mich stört, ist die Kosten-Nutzen-Lücke, die im Paper unterrepräsentiert ist. AnoLLM erfordert das Feintuning und Bereitstellen eines LLMs für die Inferenz – eine erhebliche Infrastrukturinvestition im Vergleich zum Training von ECOD oder IsolationForest auf einer CPU in Sekundenschnelle. Auf dem ODDS-Benchmark (rein numerisch) ist AnoLLM nur „gleichwertig“, nicht besser. Das Argument für AnoLLM liegt also vollständig im Bereich der gemischten Datentypen, wobei die sechs evaluierten Datensätze zur Betrugserkennung von Kaggle stammen. Sechs Datensätze sind eine dünne empirische Grundlage für eine starke Empfehlung, zumal Benchmark-Datensätze von Kaggle dazu neigen, saubere Schemata, feste Spaltensemantiken und bekannte Grundwahrheiten zu haben – alles Dinge, die Produktions-Journaldaten oft fehlen.

Das Problem der Spaltenreihenfolge bleibt ebenfalls offen. CausalTAD (arXiv:2602.07798) identifizierte diese Lücke sofort: AnoLLM serialisiert Spalten in willkürlicher Reihenfolge und ignoriert die kausalen Beziehungen zwischen den Feldern. Für strukturierte Daten mit bekannten Kausalketten – der Kontotyp beeinflusst gültige Transaktionsbereiche, die wiederum den erwarteten Vertragspartner beeinflussen – ist dies eine echte Einschränkung. CausalTAD formuliert die Neuordnung als lineares Ordnungsproblem und berichtet von konsistenten Verbesserungen gegenüber AnoLLM über mehr als 30 Datensätze hinweg. Dass diese Lücke existierte und so schnell gefunden wurde, deutet darauf hin, dass das Serialisierungsdesign von AnoLLM nicht vollständig durchdacht war.

Es gibt auch eine Skalierungsfrage, die das Paper nicht adressiert: Ab welchem Volumen an normalen Trainingsbeispielen lohnt sich das Feintuning eines LLMs gegenüber beispielsweise einem tabellarischen Deep-Learning-Modell, das direkt auf den numerischen Merkmalen trainiert wurde? Für persönliche Beancount-Journale mit ein paar tausend Einträgen könnten die Rechenkosten jeden Genauigkeitsgewinn leicht in den Schatten stellen.

Warum dies für Finance AI wichtig ist​

Beancount-Journaleinträge sind genau die Art von Daten mit gemischten Typen, auf die AnoLLM abzielt: Beträge (numerisch), Kontonamen (strukturiert/Text), Zahlungsempfänger/Beschreibung (Freitext), Tags (kategorial), Daten (strukturiert). Eine einzelne Zeile wie 2024-03-15 * "AWS" "Cloud-Rechnung" Assets:Checking -2400.00 EUR kodiert Informationen über all diese Typen gleichzeitig. Klassische Anomalie-Detektoren tun sich hier schwer, weil sie für jeden Spaltentyp eine separate Handhabung benötigen und die Korrelationen zwischen ihnen verlieren – das gemeinsame Muster, dass "AWS"-Rechnungen in einem bestimmten Bereich liegen und ein spezifisches Konto betreffen sollten.

Der NLL-Ansatz von AnoLLM würde im Prinzip diese gemeinsamen Muster aus historischen Einträgen lernen und Abweichungen über jede Spaltenkombination hinweg markieren. Das ist potenziell nützlicher als regelbasierte Prüfungen oder statistische Tests einzelner Spalten.

Dennoch ist die Einschränkung der doppelten Buchführung ein strukturelles Wissen, das AnoLLM nicht allein aus serialisierten Zeilen lernen kann – Soll muss gleich Haben sein, Kontohierarchien müssen respektiert werden. Diese Domäneninvarianten sind harte Bedingungen, keine statistischen Regelmäßigkeiten, und kein noch so großes LLM-Feintuning auf historischen Zeilen wird sie zuverlässig erzwingen, wenn die Trainingsdaten Ausnahmen oder Rundungsartefakte enthalten. Die richtige Architektur kombiniert wahrscheinlich das NLL-Scoring von AnoLLM für semantische Anomalien mit expliziten Regelprüfungen für strukturelle Anomalien.

Was man als Nächstes lesen sollte​

• CausalTAD (arXiv:2602.07798) – verbessert AnoLLM direkt durch das Einfügen einer kausalen Spaltenreihenfolge; das unmittelbarste Follow-up zur Evaluierung.
• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) – bietet die systematische Multi-Paradigma-Evaluierung, die in den Papern zu Einzelmethoden fehlt.
• "Language Models are Realistic Tabular Data Generators" (Borisov et al., arXiv:2210.06280, ICLR 2023) – das BE-GREAT-Modell, das AnoLLM als Baseline verwendet; das Verständnis dieses Modells verdeutlicht, was AnoLLM über die Index-Vorhersage hinaus tatsächlich verbessert.

Das Paper​

Figueroa, Grundmann, Freidank, Löser und Nejdl evaluieren fünf Open-Weight-Modelle der ~7B-Klasse in einem Benchmark mit zwei Aufgaben, den sie LLMFinLiteracy nennen. Aufgabe 1 verlangt von den Modellen, Text-Szenarien zu generieren, die eine bestimmte Liquiditätskennzahl (Current, Quick oder Cash Ratio) beeinflussen würden, basierend auf einer echten Quartalsbilanz eines von fünf DAX-Unternehmen (Airbus, Bayer, Deutsche Telekom, Mercedes-Benz, SAP). Aufgabe 2 verlangt von den Modellen, diese Szenarien in kompilierbare Beancount-Transaktionen zu übersetzen. Der Beancount-Compiler dient dabei als Ground-Truth-Syntaxprüfung; menschliche Fachexperten bewerten die semantische Korrektheit. Das Paper führt eine 12-stufige Fehlertaxonomie über die beiden Aufgaben hinweg ein und nutzt einen 9-stufigen Chain-of-Thought-Prompt, der Regeln der doppelten Buchführung, ein Input/Output-Beispiel und die reale Unternehmensbilanz im Beancount-Format enthält. Die evaluierten Modelle – Llama-3-8B, Qwen-2-7B, Mistral-7B, CodeLlama-7B und CodeQwen-1.5-7B – wurden aufgrund der Sensibilität von Finanzdaten alle On-Premise ausgeführt. Der Korpus umfasst insgesamt 1.500 generierte Samples, wobei 300 stratifizierte Einträge von menschlichen Experten bewertet wurden.

Kernaussagen​

• Nur 7 von 300 evaluierten Szenario-Transaktions-Paaren (2,3 %) waren durchgehend korrekt; selbst bei einer Beschränkung auf die drei Allzweckmodelle steigt die Rate nur auf 3,8 %.
• Die beiden besten Modelle, Qwen-2-7B und Mistral-7B, produzieren nur in 21,67 % bzw. 20,00 % der Fälle korrekte Szenarien und nur in 16,67 % bzw. 10,00 % der Fälle korrekte, kompilierbare Transaktionen.
• Code-spezialisierte Modelle (CodeLlama, CodeQwen) erzielten bei beiden Aufgaben 0 %; sie antworteten auf das Prompt-Template mit der wörtlichen Zeichenfolge "Processed — Waiting for next input" und ignorierten die Aufgabe vollständig.
• Die Syntax ist nicht der Flaschenhals: Kein Modell produzierte auch nur einen einzigen Syntaxfehler. Die Fehler liegen vollständig in der buchhalterischen Logik – Saldierungsfehler dominieren bei Qwen-2 (61,67 %) und Llama-3 (38,33 %), während Mistral zumeist Konten referenziert, die in der bereitgestellten Bilanz nicht existieren (45 % Fehler durch unbekannte Konten).
• Ein signifikanter Teil der Transaktionen, die erfolgreich kompilieren, ist semantisch falsch – der Lieblingstrick der Modelle besteht darin, die Verringerung einer Verbindlichkeit als "Verkauf von Schulden" zu bezeichnen, was zwar die Barmittel erhöht, aber aus dem falschen Grund.
• GPT-4o, das als automatisierter Beurteiler eingesetzt wurde, scheiterte daran, Inkonsistenzen in allen 10 ihm gezeigten unsinnigen Szenarien zu erkennen. Dies bestätigt, dass LLM-Selbst-Evaluierung kein zuverlässiger Qualitätsfilter für Buchhaltungsergebnisse ist.
• Modelle kopieren weitgehend das Input/Output-Beispiel im Prompt, anstatt zu generalisieren: Die 7 korrekten Paare ähneln stark der Struktur der bereitgestellten Beispieltransaktion.

Was Bestand hat – und was nicht​

Der empirische Kernbeitrag des Papers ist solide. Der Beancount-Compiler ist ein objektives, reproduzierbares Korrektheitskriterium, und die Verwendung realer Unternehmensbilanzen anstelle von Spielzeugdaten erhöht die ökologische Validität. Die hierarchische Fehlertaxonomie ist durchdacht – die Evaluierung beim ersten Fehler zu stoppen, verhindert eine künstliche Aufwertung durch "Teilpunkte" für unbrauchbare Ausgaben.

Dennoch gibt es offensichtliche Einschränkungen, die von den Autoren größtenteils eingeräumt werden. Fünf ~7B Open-Weight-Modelle aus den Jahren 2023–2024 sind nur ein schmaler Ausschnitt der aktuellen Leistungsfähigkeit; GPT-4o und Claude wurden aus Datenschutzgründen ausgeschlossen, was verständlich ist, aber bedeutet, dass die Schlagzeile (2,3 % korrekt) das Potenzial der technologischen Spitze unterschätzt. Die Formeln der Finanzkennzahlen wurden bewusst aus den Prompts herausgehalten, um das inhärente Domänenwissen zu testen – eine methodisch interessante Entscheidung, die die Ergebnisse jedoch unvergleichbar mit jedem System macht, das sinnvollerweise eine Formeldokumentation enthalten würde. Zudem sind 300 menschlich bewertete Proben über fünf Modelle, drei Kennzahlen und fünf Unternehmen bescheiden; die Zellen pro Modell und Kennzahl sind mit 12 Proben zu klein, um starke Rückschlüsse auf die Varianz zu ziehen.

Die interessanteste methodische Lücke ist das Fehlen jeglicher iterativen oder feedbackbasierten Protokolle. Kein Tool-Calling, keine Selbstkorrektur, keine Compiler-Feedback-Schleife – nur One-Shot-Generierung. Da CRITIC (LOG-012) und verwandte Arbeiten zeigen, dass tool-interaktive Verfeinerung die Genauigkeit bei Aufgaben mit verifizierbaren Ergebnissen erheblich verbessert, wäre ein Beancount-Compiler-in-the-Loop-Experiment weitaus informativer in Bezug auf die Einsatzfähigkeit gewesen.

Warum dies für Finanz-KI wichtig ist​

Jede Designentscheidung für den Bean Labs Write-Back-Agenten basiert auf Annahmen darüber, was LLMs mit der Beancount DSL leisten können. Dieses Paper ist der erste empirische Ankerpunkt. Die zentralen Ergebnisse sind ernüchternd, aber auch auf nützliche Weise interpretierbar.

Erstens sind die Fehlermodi spezifisch und nicht zufällig. Saldierungsfehler und unbekannte Konten sind die beiden dominanten Probleme, und beide sind mit einer Compiler-in-the-Loop-Feedbackschleife behebbar: Der Beancount-Compiler sagt einem genau, welches Konto unbekannt ist und ob die Transaktion ausgeglichen ist. Eine Agentenarchitektur, die auf der Compiler-Ausgabe iteriert – anstatt einmal zu generieren und dann aufzuhören –, sollte die hier gezeigten One-Shot-Ergebnisse deutlich übertreffen. Zweitens ist die Syntax quasi "gratis". Die Modelle haben die Oberflächengrammatik von Beancount offensichtlich gelernt; sie können nur die finanzielle Absicht nicht zuverlässig in korrekte Kontenbewegungen übersetzen. Diese Unterscheidung ist wichtig dafür, wo man in Prompting und Fine-Tuning investieren sollte. Drittens erhöht die Erkenntnis, dass GPT-4o die Buchhaltungsqualität nicht automatisch bewerten kann, die Messlatte für jedes automatisierte Verifizierungssystem: Man benötigt den Compiler plus Stichproben durch Fachexperten, keinen LLM-Kritiker.

Das Paper bestätigt auch etwas, das ich bereits bei der Arbeit zur Anomalieerkennung (LOG-049) vermutet habe: LLMs, die auf Finanztransaktionen operieren, neigen dazu, zu schnell zu "kompilieren und abzusenden". Die Kategorie "Inkorrekt | Kompiliert" – Transaktionen, die die Syntaxprüfung bestehen, aber semantisch falsch sind – ist genau der Fehlermodus, den eine Sicherheitsleitplanke für Write-Backs abfangen muss. Eine Transaktion kann perfekt ausgeglichen sein und dennoch Einnahmen als Verringerung einer Verbindlichkeit buchen, was durch eine rein syntaktische Prüfung unentdeckt bliebe.

Was man als Nächstes lesen sollte​

• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) – Likelihood-basierte Anomalie-Bewertung als Alternative zum Batch-Erkennungsansatz; lässt sich natürlich mit einem Beancount-Compiler-Signal kombinieren, um strukturell valide, aber statistisch anomale Einträge zu markieren.
• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) – leitet Entscheidungen mit geringer Konfidenz an ein größeres Modell oder einen Menschen weiter; adressiert direkt die Frage, wann ein Beancount-Write-Back-Agent die Entscheidung an einen Menschen delegieren sollte, anstatt nach einer Compiler-Feedbackschleife fortzufahren.
• CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024) – die relevanteste existierende Arbeit für den Aufbau eines Compiler-in-the-Loop-Korrekturagenten auf Basis der in diesem Paper evaluierten Architektur.