🤖 machine learning

Understanding Tool-Augmented Agents for Lean Formalization: A Factorial Analysis

Dit onderzoek analyseert systematisch hoe tool-geaugmenteerde agenten, die gebruikmaken van fijngetrainde modellen, kenniszoekfuncties en compiler-feedback, de vertaling van informele wiskunde naar correcte Lean 4-code verbeteren door de hallucinaties van grote taalmodellen te verminderen en de compilatiesuccesratio te verhogen.

Oorspronkelijke auteurs: Ke Zhang, Patricio Gallardo, Maziar Raissi, Sudhir Murthy

Gepubliceerd 2026-04-21

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Ke Zhang, Patricio Gallardo, Maziar Raissi, Sudhir Murthy

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Titel: Hoe we een slimme robot helpen om wiskunde te "vertalen" naar een taal die computers begrijpen

Stel je voor dat je een boek met ingewikkelde wiskundeverklaringen hebt, geschreven in gewoon Nederlands. Je wilt dat een computer dit begrijpt en omzet in een strikte, foutloze programmeertaal (genaamd Lean 4). Dit is als proberen een verhaal te vertellen aan een robot die alleen maar "ja" of "nee" zegt, en waar elke letter en puntje perfect moet kloppen.

Het probleem? De robot (een kunstmatige intelligentie of AI) is erg slim in het schrijven van verhalen, maar hij is ook erg goed in het uitvinden van dingen die niet bestaan. Hij denkt dat hij een wiskundig symbool kent, maar in werkelijkheid bestaat dat symbool niet in de computerbibliotheek. Het resultaat? De computer roept: "Fout! Dit werkt niet!" en de vertaling mislukt.

De auteurs van dit paper hebben een slimme oplossing bedacht: ze hebben de robot niet alleen de tekst laten schrijven, maar hem ook gereedschappen gegeven om zichzelf te controleren. Ze noemen dit een "Agent".

Hier is hoe het werkt, vertaald naar alledaagse analogieën:

1. Het Probleem: De "Dromer" vs. De "Controleur"

Stel je voor dat je een architect bent (de AI) die een huis ontwerpt.

De oude manier (Zonder gereedschap): De architect tekent een prachtig huis op papier. Maar als hij het bouwpakket gaat bestellen, blijkt dat de deuren te groot zijn of dat er geen ramen in de muur passen. Het huis stort in. De AI probeerde het in één keer perfect te doen, maar droomde dingen in die niet bestonden.
De nieuwe manier (Met gereedschap): De architect krijgt nu drie hulpmiddelen:
1. De Expert: Een senior architect die een eerste schets maakt.
2. De Woordenlijst: Een telefoon om direct te checken: "Bestaat deze schroef wel?"
3. De Bouwmeester: Een robot die het huis probeert te bouwen. Als het mislukt, zegt hij precies: "De balk is te kort."

2. De Drie Hulpmiddelen (De "Gereedschapskist")

De onderzoekers hebben gekeken welke van deze drie hulpmiddelen het meest belangrijk zijn. Ze hebben een experiment gedaan met 400 wiskundige problemen (zoals een proefexamen voor wiskundestudenten).

Hulpmiddel A: De Expert (De "Schrijver")
Dit is een gespecialiseerde AI die al veel wiskunde heeft geleerd. Hij geeft een eerste versie van de code.
- Resultaat: Het helpt een beetje, maar niet heel veel. Het is alsof je een goede schets hebt, maar als je niet controleert of de materialen bestaan, bouw je het huis toch niet.
Hulpmiddel B: De Woordenlijst (De "Zoeker")
Dit tooltje zoekt direct in de computerbibliotheek op: "Wat betekent dit symbool?"
- Resultaat: Dit helpt om fouten te voorkomen voordat je begint. Het is als het controleren van de voorraadkast voordat je kookt. Het maakt de robot iets slimmer, maar lost niet alle problemen op.
Hulpmiddel C: De Bouwmeester (De "Feedback")
Dit is het belangrijkste! Dit is de computer die de code echt probeert uit te voeren. Als er een fout is, geeft hij een melding: "Fout in regel 5: je hebt een komma vergeten." De robot leest dit, past de code aan, en probeert het opnieuw.
- Resultaat: Dit is de game-changer. Zonder deze "bouwmeester" faalt de robot vaak. Met deze feedback kan de robot zichzelf corrigeren, net zoals een mens die een proefopdracht maakt, de antwoorden controleert, en de fouten verbetert.

3. Wat hebben ze ontdekt? (De Grote Leer)

De onderzoekers hebben een "factoriële analyse" gedaan. Dat is een fancy woord voor: "We hebben alle combinaties van gereedschappen geprobeerd om te zien wat er gebeurt."

Hier is wat ze vonden, in simpele taal:

Feedback is alles: Als je de robot alleen maar laat schrijven (zonder feedback), faalt hij bijna altijd (slechts 26% slaagt). Maar als je hem de Bouwmeester geeft die zegt "dit werkt niet, probeer het anders", stijgt het succes naar 89%.
Zoeken helpt, maar is niet alles: Als je de robot laat zoeken naar woorden zonder dat hij de code kan testen, helpt het wel, maar niet genoeg. Maar als je beide hebt (zoeken + testen), werkt het nog beter en sneller.
De "Expert" is niet nodig: Als de robot al kan testen en zoeken, heeft hij de hulp van de gespecialiseerde "Expert" eigenlijk niet meer nodig. De gewone robot (de "Generalist") is al slim genoeg als hij maar mag leren van zijn fouten.

4. Waarom is dit belangrijk?

Vroeger dachten mensen dat we alleen maar betere AI's moesten bouwen (die meer wiskunde uit het hoofd leerden) om dit probleem op te lossen.

Dit paper zegt: "Nee, dat is niet het antwoord."
Het antwoord is interactie. Geef de AI een omgeving waar hij kan proberen, falen, en leren van de foutmeldingen. Het is niet belangrijk dat de AI alles weet voordat hij begint; het is belangrijk dat hij kan controleren terwijl hij werkt.

Conclusie in één zin

Om wiskunde van mens naar computer te vertalen, heb je geen perfecte "dromer" nodig, maar een praktische bouwer die voortdurend zijn werk controleert en aanpast tot het perfect past.

Dit maakt het mogelijk om in de toekomst veel meer wiskundige theorieën veilig en betrouwbaar in computers te zetten, wat essentieel is voor de toekomst van wetenschap en technologie.

Probleemstelling

De automatische vertaling van informele wiskundige teksten (natuurtaal) naar correcte Lean 4-code wordt gehinderd door een fundamentele dissonantie tussen de informele, op verzamelingenleer gebaseerde intuïtie van wiskundigen en de strikte, type-theoretische eisen van formele bewijshulpmiddelen.

Huidige benaderingen, zoals één-shot prompting (direct genereren) of fine-tuning op statische datasets, lopen vast op de volgende obstakels:

Hallucinaties: Modellen creëren vaak niet-bestaande theorema's of bibliotheekdefinities omdat trainingsdata voor geavanceerde wiskunde schaars is.
Semantische mismatch: Zelfs als de code compileert, kan deze semantisch incorrect zijn (een "vacuüm" statement) door de kloof tussen tekstboeken en Lean's afhankelijke type-theorie.
Verouderde kennis: Mathlib 4 is een snel evoluerende community-bibliotheek. Modellen getraind op statische snapshots genereren code die verwijst naar verouderde of niet-bestaande definities.

Methodologie

De auteurs introduceren een agent-architectuur die statische generatie vervangt door een iteratief verfijningsproces. Het systeem bestaat uit een centrale LLM-orchestrator (GPT-5.2) die communiceert met een Lean 4-omgeving via een gesloten lus van "draften, verifiëren en repareren".

Het onderzoek voert een systematische factoriële analyse uit om de bijdrage van drie specifieke tool-categorieën te kwantificeren:

Fine-tuned Model Querying (T): Toegang tot een gespecialiseerd, fijngetuned model (Herald) voor het genereren van een eerste concept (expert drafting).
Knowledge Search (S): Tools om symbolen op te zoeken (bijv. lean inspect name) en definities direct uit Mathlib te halen om hallucinaties te voorkomen.
Compiler Feedback (F): Een Lean REPL (Read-Eval-Print Loop) die de gegenereerde code compileert en exacte foutmeldingen teruggeeft voor iteratieve correctie.

Experimenteel Ontwerp:

Dataset: Een nieuw benchmark van 400 geavanceerde stellingen uit vier domeinen: Real Analysis, Complex Analysis, Topology en Algebra.
Evaluatie: Een tweestapsprotocol:
1. Compiler Verification: Code moet compileeren.
2. Semantic Equivalence: Een LLM-as-a-Judge (GPT-5.2) beoordeelt of de Lean-stelling logisch equivalent is aan de originele tekst (score 0-10). Een stelling is "Faithful" als deze compileert en een score ≥9 haalt.
Factoriële Design: Alle $2^3 = 8$ combinaties van de tools (aan/uit) worden getest om hoofd-effecten en interacties te isoleren.

Belangrijkste Resultaten

1. Prestatieverbetering (Agentic Premium)
De volledige tool-augmented agent (alle tools ingeschakeld) overtreft één-shot baselines aanzienlijk:

Compilatie-succes: Steeg van ~26% (bij baselines) naar 89,5%.
Semantische trouw (Faithfulness): Steeg van ~28% naar 60,5%.
Dit bevestigt dat iteratieve verfijning essentieel is voor betrouwbare formalisatie.

2. Factoriële Analyse: De drijvende krachten
De analyse van de bijdrage van elke tool onthult een duidelijk hiërarchisch patroon:

Compiler Feedback (F) is de kritieke bottleneck: Het inschakelen van de REPL zorgt voor een enorme prestatieboost (+32,3 punten). Dit is de dominante factor die het systeem transformeert van een onbetrouwbare naar een betrouwbare regime. Zonder feedback blijven de resultaten laag, ongeacht andere tools.
Zoeken (S) is een stabilisator: Symbol-search verbetert de prestaties met +6,8 punten door hallucinaties te verminderen. Het effect is echter het grootst wanneer er geen compiler feedback is. Zodra feedback beschikbaar is, neemt de meerwaarde af (interactie-effect), omdat de compiler zelf al veel informatie levert.
Expert Drafting (T) is substitueerbaar: Het gebruik van een gespecialiseerd model (Herald) levert slechts een marginale verbetering (+0,9 punten) op. Zodra feedback en zoekfuncties beschikbaar zijn, wordt de specifieke draft overbodig; de generalistische orchestrator kan de fouten zelf corrigeren. In sommige gevallen verstoort het zelfs het herstelproces.

3. Interactie en Efficiëntie

Er is een negatief interactie-effect tussen Feedback en Zoeken ( $F \times S$ ). Wanneer de compiler feedback geeft, is de noodzaak voor externe symbol-zoekopdrachten kleiner.
Het toevoegen van de zoektool vermindert het aantal dure compilatie-iteraties (REPL calls) met ongeveer 30%, wat aangeeft dat de agent efficiënter informatie verzamelt voordat hij compileert.

4. Robuustheid
De resultaten zijn consistent over verschillende orchestrator-modellen (GPT-5.2, Claude Sonnet 4.5, Gemini-2.5-Pro), wat aantoont dat het succes structureel ligt in de tool-architectuur en niet afhankelijk is van één specifiek model.

Bijdragen en Significantie

Technische Bijdragen:

Eerste systematische factoriële analyse van tool-augmented agents voor wiskundige formalisatie, wat de causale bijdrage van individuele componenten kwantificeert.
Open-source Framework: De auteurs publiceren de volledige benchmark (400 stellingen), de agent-implementatie, evaluatiescripts en interactielogs.
Validatie: Rigoureuze validatie van de LLM-as-a-Judge met menselijke experts, waarbij een hoge overeenkomst (97,8%) wordt aangetoond.

Wetenschappelijke en Praktische Betekenis:

Paradigmaverschuiving: Het paper toont aan dat voor snel evoluerende formele bibliotheken (zoals Mathlib), statische fine-tuning onvoldoende is. De sleutel tot schaalbare formalisatie ligt in verificatie-gekoppelde iteratie (execution) en retrieval, niet alleen in parametrische kennis.
Ontwerpprincipe: Voor redenerende agents in formele domeinen moeten hoog-precisie uitvoeringsomgevingen (zoals een compiler) dienen als het primaire skelet voor redenering, met zoekfuncties om convergentie te versnellen.
Toekomstige RL: De gegenereerde interactielogs vormen een waardevolle dataset voor toekomstig Reinforcement Learning (RL) onderzoek, waarbij modellen kunnen leren om fouten te voorspellen en te repareren zonder de hoge kosten van live compilatie.

Kortom, dit werk bewijst dat de combinatie van een generalistische LLM met een live compiler-feedbacklus de meest effectieve strategie is om de kloof tussen informele wiskunde en formeel bewijs te overbruggen.