Toolformer: Zelf-gesuperviseerd toolgebruik en de beperkingen voor Finance AI

Toolformer (Schick et al., 2023, Meta AI) is de fundamentele paper over het aanleren van het aanroepen van externe API's aan taalmodellen via zelf-gesuperviseerde training. Ik heb het zorgvuldig lezen uitgesteld omdat "toolgebruik" zo'n modewoord is geworden dat de oorspronkelijke claims vertroebeld raken. Voordat ik een write-back agent ontwerp die grootboek-tools aanroept, moet ik begrijpen wat Toolformer daadwerkelijk heeft aangetoond — en waar het stilletjes tekortschiet.

De paper

Timo Schick en zeven co-auteurs bij Meta AI presenteren een methode om een taalmodel te trainen om te beslissen wanneer externe API's moeten worden aangeroepen, welke argumenten moeten worden doorgegeven en hoe resultaten in de eigen voorspellingen moeten worden opgenomen — zonder dat er handmatig gelabelde trainingsdata voor elke tool nodig is. De aanpak is zelf-gesuperviseerd: het model genereert kandidaat-API-aanroepen op plausibele posities in de tekst, voert die aanroepen uit en bewaart alleen de voorbeelden waarbij het API-resultaat de perplexiteit van het model op de omliggende tokens werkelijk vermindert. Die gefilterde dataset wordt vervolgens gebruikt voor fine-tuning. De geteste tools omvatten een rekenmachine, twee zoekmachines (BM25-retrieval en Wikipedia-zoekopdrachten), een QA-model, een vertaler en een kalender.

Het getrainde model is een op GPT-J gebaseerd model met 6,7 miljard parameters dat ze Toolformer noemen. De paper werd geaccepteerd voor NeurIPS 2023.

Belangrijkste ideeën

• Bij wiskundige woordproblemen (SVAMP) scoort Toolformer 6.7B 29,4% — vergeleken met de GPT-J baseline van 5,2%, OPT 66B van 4,9% en GPT-3 175B van 10,0%. Toolgebruik vlakt de gebruikelijke schalingscurve voor rekenkunde effectief af.
• Bij ASDiv-wiskunde bereikt Toolformer 40,4% versus GPT-J op 7,5% en GPT-3 op 14,0%; bij MAWPS 44,0% versus GPT-J op 9,9% en GPT-3 op 19,8%.
• Bij feitelijke QA-taken draait het beeld om: GPT-3 presteert nog steeds beter dan Toolformer op alle drie de QA-benchmarks (TriviaQA, WebQuestions, Natural Questions), ondanks dat Toolformer zoektools gebruikt. Toolformer TriviaQA: 53,5% versus GPT-J baseline 31,9%, maar GPT-3 zonder tools scoort nog hoger.
• De zelf-gesuperviseerde pijplijn voor datageneratie produceert trainingsvoorbeelden waarbij het model leert om een API niet aan te roepen als dat niet nuttig is — de filterstap gebruikt verbetering in perplexiteit als signaal voor "hielp deze tool-aanroep daadwerkelijk?".
• De vaardigheid voor toolgebruik ontstaat pas op schaal: modellen met minder dan ongeveer 775 miljoen parameters leren niet betrouwbaar wanneer ze tools moeten aanroepen, zelfs niet met hetzelfde trainingssignaal.
• De kalendertool wordt slechts in 0,2% van de gevallen aangeroepen bij temporele redeneertaken; het model stuurt temporele vragen voornamelijk naar de Wikipedia-zoektool.

Wat houdt stand — en wat niet

Het kerninzicht blijft overeind: de op perplexiteit gebaseerde filteringstruc is elegant omdat deze geen menselijke labeling vereist en geen oracle die het juiste antwoord kent — alleen of het ingevoegde API-resultaat de omliggende tekst voorspelbaarder maakte. Dat is een wezenlijke bijdrage, en de rekenkundige resultaten zijn opvallend. Een 6.7B-model dat GPT-3 verslaat op ASDiv is geen evaluatietruc; het is een duidelijke demonstratie dat de juiste tool-aanroep ongeveer 26 keer meer parameters waard is bij rekenkundige taken.

Wat ik minder overtuigend vind, is het QA-verhaal. De paper presenteert Toolformer als een brede verbetering van de prestaties, maar de QA-resultaten laten zien dat het GPT-3 — een veel groter model zonder tools — niet verslaat. De auteurs erkennen dit, maar de narratieve inkadering ("vaak competitief met veel grotere modellen") onderschat hoe selectief de overwinning is: het model wint op taken die duidelijk uiteenvallen in een enkele rekenmachine- of opzoekaanroep, en verliest of blijft gelijk op taken die werkelijk redeneren over de opgehaalde inhoud vereisen.

Het diepere methodologische probleem is dat de zelf-gesuperviseerde pijplijn ervan uitgaat dat het model al goed genoeg is om plausibele API-aanroepen te genereren voordat het daarvoor getraind is. Dit is een bootstrapping-probleem. Voor goed gestructureerde tools zoals een rekenmachine met een duidelijk invoerformaat werkt het. Voor tools met complexere argument-schema's — precies het soort dat je zou willen voor een real-world grootboek-write-back-API — zou de kwaliteit van de gesamplede aanroepen snel verslechteren.

De paper evalueert elke tool ook afzonderlijk, niet in combinatie. Er is geen demonstratie van een meerstaps-pijplijn waarbij bijvoorbeeld een zoekresultaat in een rekenmachine wordt gevoed. De auteurs markeren dit als een beperking, maar het is een aanzienlijke: echte boekhoudkundige workflows vereisen bijna altijd gekoppelde tool-aanroepen.

Ten slotte is de evaluatie zero-shot. Er is geen vergelijking met few-shot prompted GPT-3 of GPT-4 met tools in de context, wat binnen enkele maanden na deze paper het dominante paradigma werd. De publicatiedatum van NeurIPS 2023 betekent dat de experimenten voorafgaan aan de brede adoptie van functie-aanroepende API's, waardoor de vergelijkingsset op het moment van publicatie enigszins gedateerd was.

Waarom dit belangrijk is voor finance AI

De Toolformer-paper beantwoordt een vraag die mij bezighoudt voor Bean Labs: kan een model betrouwbaar leren om een write-back API aan te roepen, en tegen welke prijs? Het antwoord uit de rekenkundige resultaten is "ja, mits de tool-interface clean is en de taak uiteenvalt in een enkele aanroep". De faalmodi sluiten echter direct aan op de moeilijkste onderdelen van het grootboekvraagstuk.

Beancount write-back-acties — het classificeren van een transactie, het afleiden van rekeningtoewijzingen, het genereren van een journaalpost — zijn geen eenstaps-aanroepen van een rekenmachine. Ze omvatten het ophalen van context (eerdere boekingen, rekeningschema), het toepassen van regels (boekingsregels, valutabeperkingen) en het produceren van gestructureerde output die syntactisch geldig moet zijn. Dat zijn ten minste drie gekoppelde tool-aanroepen, en de Toolformer-architectuur kan expliciet geen tools koppelen. Het op perplexiteit gebaseerde trainingssignaal zou hier ook moeilijk toe te passen zijn: het is niet duidelijk wat "lagere perplexiteit op de omliggende grootboektekst" betekent wanneer de output een gestructureerd .beancount-bestand is in plaats van een voortzetting in natuurlijke taal.

De nuttigere les van Toolformer voor onze doeleinden is de negatieve ruimte: een write-back agent kan niet simpelweg een gefinetuned taalmodel zijn dat uit het hoofd heeft geleerd wanneer de grootboek-API moet worden aangeroepen. Het heeft een expliciete redeneerlaag nodig (ReAct of vergelijkbaar) die kan plannen, uitvoeren en tussenresultaten kan controleren voordat een boeking wordt definitief gemaakt. Toolformer toont aan dat toolgebruik werkt; het toont niet aan dat het veilig werkt bij gestructureerde operaties met neveneffecten.

Wat nu te lezen

• ReAct: Synergizing Reasoning and Acting in Language Models (arXiv:2210.03629) — voegt expliciete chain-of-thought redeneerstappen toe die verweven zijn met tool-aanroepen; de architectuur die de beperkingen van Toolformer op het gebied van koppeling aanpakt en de basis vormt voor de meeste moderne agents.
• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — schaalt toolgebruik op naar meer dan 16.000 echte API's via de ToolBench-dataset; de beste benadering van een stresstest voor tool-aanroepen op het complexiteitsniveau waar een echte accounting-agent mee te maken zou krijgen.
• FinMaster (arXiv:2505.13533) — benchmarkt end-to-end boekhoudkundige workflows inclusief journaalposten en afletteren; zal aantonen of de winst die Toolformer liet zien bij rekenkunde generaliseert naar de meerstaps, schema-beperkte taken die belangrijk zijn voor Beancount.