Toolformer: Selbstüberwachte Werkzeugnutzung und ihre Grenzen für Finanz-KI

Toolformer (Schick et al., 2023, Meta AI) ist das grundlegende Paper für das Unterrichten von Sprachmodellen darin, externe APIs durch selbstüberwachtes Training aufzurufen. Ich habe eine sorgfältige Lektüre aufgeschoben, da „Werkzeugnutzung“ (Tool Use) zu einem solchen Modewort geworden ist, dass die ursprünglichen Behauptungen verwässert wurden. Bevor ich einen Write-back-Agenten entwickle, der Ledger-Tools aufruft, muss ich verstehen, was Toolformer tatsächlich demonstriert hat – und wo es im Stillen scheitert.

Das Paper

Timo Schick und sieben Co-Autoren von Meta AI präsentieren eine Methode, um ein Sprachmodell darauf zu trainieren, zu entscheiden, wann externe APIs aufgerufen werden sollen, welche Argumente übergeben werden müssen und wie die Ergebnisse in die eigenen Vorhersagen integriert werden – ohne manuell beschriftete Trainingsdaten für jedes Werkzeug zu benötigen. Der Ansatz ist selbstüberwacht: Das Modell generiert Kandidaten für API-Aufrufe an plausiblen Stellen im Text, führt diese Aufrufe aus und behält nur die Beispiele, bei denen das API-Ergebnis die Perplexität des Modells für die umgebenden Token tatsächlich verringert. Dieser gefilterte Datensatz wird dann für das Fine-Tuning verwendet. Die getesteten Werkzeuge umfassen einen Taschenrechner, zwei Suchmaschinen (BM25-Retrieval und Wikipedia-Suche), ein QA-Modell, einen Übersetzer und einen Kalender.

Das trainierte Modell ist ein auf GPT-J basierendes Modell mit 6,7 Milliarden Parametern, das sie Toolformer nennen. Das Paper wurde auf der NeurIPS 2023 angenommen.

Kernaussagen

• Bei mathematischen Textaufgaben (SVAMP) erreicht Toolformer 6.7B einen Wert von 29,4 % – im Vergleich zur GPT-J-Baseline von 5,2 %, OPT 66B mit 4,9 % und GPT-3 175B mit 10,0 %. Die Werkzeugnutzung lässt die übliche Skalierungskurve für Arithmetik effektiv kollabieren.
• Bei ASDiv-Mathe erreicht Toolformer 40,4 % gegenüber GPT-J mit 7,5 % und GPT-3 mit 14,0 %; bei MAWPS 44,0 % gegenüber GPT-J mit 9,9 % und GPT-3 mit 19,8 %.
• Bei faktischen QA-Aufgaben kehrt sich das Bild um: GPT-3 übertrifft Toolformer immer noch in allen drei QA-Benchmarks (TriviaQA, WebQuestions, Natural Questions), obwohl Toolformer Suchwerkzeuge verwendet. Toolformer TriviaQA: 53,5 % vs. GPT-J-Baseline 31,9 %, aber GPT-3 ohne Werkzeuge liegt noch höher.
• Die selbstüberwachte Daten-Generierungspipeline erzeugt Trainingsbeispiele, bei denen das Modell lernt, eine API nicht aufzurufen, wenn dies nicht hilfreich ist – der Filterungsschritt nutzt die Verbesserung der Perplexität als Signal dafür, ob „dieser Werkzeugaufruf tatsächlich geholfen hat“.
• Die Fähigkeit zur Werkzeugnutzung tritt erst ab einer gewissen Größe auf: Modelle unter etwa 775 Millionen Parametern lernen selbst mit demselben Trainingssignal nicht zuverlässig, wann sie Werkzeuge aufrufen sollen.
• Das Kalender-Werkzeug wird bei Aufgaben zum zeitlichen Denken nur in 0,2 % der Fälle aufgerufen; das Modell leitet zeitliche Fragen stattdessen überwiegend an das Wiki-Suchwerkzeug weiter.

Was Bestand hat – und was nicht

Die zentrale Erkenntnis ist beständig: Der perplexitätsbasierte Filtertrick ist elegant, da er keine menschliche Beschriftung und kein Orakel erfordert, das die richtige Antwort kennt – sondern nur, ob das eingefügte API-Ergebnis den umgebenden Text vorhersehbarer gemacht hat. Das ist ein echter Beitrag, und die mathematischen Ergebnisse sind beeindruckend. Dass ein 6,7B-Modell GPT-3 bei ASDiv schlägt, ist kein Evaluierungstrick; es ist eine klare Demonstration, dass der richtige Werkzeugaufruf bei Arithmetikaufgaben etwa das 26-fache an Parametern wert ist.

Was mich weniger überzeugt, ist die QA-Geschichte. Das Paper stellt Toolformer so dar, als würde es die Leistung auf breiter Front verbessern, aber die QA-Ergebnisse zeigen, dass es GPT-3 nicht schlägt – ein viel größeres Modell ohne jegliche Werkzeuge. Die Autoren räumen dies ein, aber der narrative Rahmen („oft wettbewerbsfähig mit viel größeren Modellen“) unterschätzt, wie selektiv der Sieg ist: Das Modell gewinnt bei Aufgaben, die sich sauber in einen einzelnen Taschenrechner- oder Suchaufruf zerlegen lassen, und verliert oder zieht gleich bei Aufgaben, die echtes Denken über die abgerufenen Inhalte erfordern.

Das tieferliegende methodische Problem besteht darin, dass die selbstüberwachte Pipeline davon ausgeht, dass das Modell bereits gut genug ist, um plausible API-Aufrufe zu generieren, bevor es darauf trainiert wurde. Dies ist ein Bootstrapping-Problem. Für gut strukturierte Werkzeuge wie einen Taschenrechner mit klarem Eingabeformat funktioniert es. Für Werkzeuge mit komplexeren Argumentschemata – genau die Art, die man für eine reale Ledger-Write-back-API benötigen würde – würde die Qualität der gesampelten Aufrufe schnell abnehmen.

Das Paper evaluiert jedes Werkzeug zudem isoliert, nicht in Kombination. Es gibt keine Demonstration einer mehrstufigen Pipeline, in der beispielsweise ein Suchergebnis in einen Taschenrechner einfließt. Die Autoren markieren dies als Einschränkung, aber es ist eine bedeutende: Echte Buchhaltungs-Workflows erfordern fast immer verkettete Werkzeugaufrufe.

Schließlich ist die Evaluierung zero-shot. Es gibt keinen Vergleich mit few-shot gepromptetem GPT-3 oder GPT-4 mit kontextbezogenen Werkzeugen, was innerhalb weniger Monate nach diesem Paper zum dominanten Paradigma wurde. Das Veröffentlichungsdatum auf der NeurIPS 2023 bedeutet, dass die Experimente vor der weit verbreiteten Einführung von Function-Calling-APIs stattfanden, was die Vergleichsgruppe zum Zeitpunkt der Veröffentlichung etwas veraltet erscheinen lässt.

Warum dies für Finanz-KI wichtig ist

Das Toolformer-Paper beantwortet eine Frage, die mich für Bean Labs interessiert: Kann ein Modell lernen, eine Write-back-API zuverlässig aufzurufen, und zu welchem Preis? Die Antwort aus den mathematischen Ergebnissen lautet „Ja, wenn die Werkzeugschnittstelle sauber ist und die Aufgabe sich in einen einzelnen Aufruf zerlegen lässt.“ Die Fehlermodi lassen sich jedoch direkt auf die schwierigsten Teile des Ledger-Problems übertragen.

Beancount-Write-back-Aktionen – das Klassifizieren einer Transaktion, das Ableiten von Kontenzuordnungen, das Erstellen eines Journaleintrags – sind keine einstufigen Taschenrechner-Aufrufe. Sie beinhalten das Abrufen von Kontext (frühere Einträge, Kontenrahmen), das Anwenden von Regeln (Buchungsregeln, Währungsbeschränkungen) und das Erzeugen einer strukturierten Ausgabe, die syntaktisch gültig sein muss. Das sind mindestens drei verkettete Werkzeugaufrufe, und die Toolformer-Architektur kann explizit keine Werkzeuge verketten. Das perplexitätsbasierte Trainingssignal wäre hier ebenfalls schwer anzuwenden: Es ist unklar, was „niedrigere Perplexität des umgebenden Ledger-Textes“ bedeutet, wenn die Ausgabe eine strukturierte .beancount-Datei anstelle einer fortlaufenden natürlichen Sprache ist.

Die nützlichere Lektion aus Toolformer für unsere Zwecke liegt im negativen Raum: Ein Write-back-Agent kann nicht einfach ein feinabgestimmtes Sprachmodell sein, das auswendig gelernt hat, wann die Ledger-API aufzurufen ist. Er benötigt eine explizite Denkebene (ReAct oder ähnlich), die planen, ausführen und Zwischenergebnisse prüfen kann, bevor ein Schreibvorgang festgeschrieben wird. Toolformer beweist, dass Werkzeugnutzung funktioniert; es beweist nicht, dass sie bei strukturierten Operationen mit Nebenwirkungen sicher funktioniert.

Was als Nächstes zu lesen ist

• ReAct: Synergizing Reasoning and Acting in Language Models (arXiv:2210.03629) – fügt explizite Chain-of-Thought-Denkschritte hinzu, die mit Werkzeugaufrufen verschachtelt sind; die Architektur, die die Verkettungsbeschränkung von Toolformer behebt und die Basis für die meisten modernen Agenten bildet.
• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) – skaliert die Werkzeugnutzung auf über 16.000 reale APIs über den ToolBench-Datensatz; das, was einem Stresstest für Werkzeugaufrufe auf dem Komplexitätsniveau eines echten Buchhaltungsagenten am nächsten kommt.
• FinMaster (arXiv:2505.13533) – Benchmarks für End-to-End-Buchhaltungs-Workflows einschließlich Journaleintrag und Abstimmung; wird zeigen, ob sich die Gewinne, die Toolformer bei der Arithmetik gezeigt hat, auf die mehrstufigen, schemagebundenen Aufgaben übertragen lassen, die für Beancount wichtig sind.