🤖 AI

Beyond Compilation: Evaluating Faithful Natural-Language-to-Lean Statement Formalization

Dit artikel betoogt dat het uitsluitend vertrouwen op Lean-compilatiesnelheden om de formalisering van natuurlijke taal naar Lean te evalueren misleidend is vanwege een aanzienlijke kloof tussen syntactische geldigheid en semantische getrouwheid, waarbij een rigoureuze door mensen gekalibreerde consensusmetriek wordt voorgesteld en elaboratie-feedback wordt geïdentificeerd als de meest kritieke interventie voor het verbeteren van de nauwkeurigheid van formele verklaringen.

Oorspronkelijke auteurs: Ke Zhang, Patricio Gallardo Candela, Sudhir Murthy, Yi Xie, Zhi Wang, Maziar Raissi

Gepubliceerd 2026-07-01

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Ke Zhang, Patricio Gallardo Candela, Sudhir Murthy, Yi Xie, Zhi Wang, Maziar Raissi

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

Het Grote Plaatje: Vertalen, niet alleen Controleren

Stel je voor dat je een bibliotheek hebt met complexe wiskundige problemen geschreven in gewone Engelse taal (zoals een tekstboek). Je wilt deze problemen vertalen naar een strikte, door de computer leesbare taal genaamd Lean.

In het verleden richtten onderzoekers zich vooral op de tweede stap: de computer een perfecte vertaling geven en vragen: "Kun je bewijzen dat dit waar is?"
Dit paper richt zich op de eerste stap: "Kun je de Engelse zin in eerste instantie correct vertalen naar Lean?"

De auteurs stellen dat het feit dat een vertaling "werkt" (de computer accepteert het zonder fouten) niet betekent dat het ook daadwerkelijk hetzelfde zegt als de oorspronkelijke Engelse zin. Het is als een vertaler die een zin schrijft die grammaticaal perfect is, maar per ongeluk de betekenis volledig verandert.

Het Kernprobleem: "Compileren" versus "Getrouw zijn"

Het paper introduceert een cruciaal onderscheid tussen twee zaken:

Compilatie (De Grammatica-check): De computer controleert of de Lean-code de regels van de syntaxis volgt. Als dat zo is, "compileert" de code.
- Analogie: Stel je een student voor die een essay schrijft. De docent controleert of de student de juiste spelling en interpunctie heeft gebruikt. Als dat zo is, "slaagt" het essay.
Getrouwheid (De Betekenis-check): Zegt de code daadwerkelijk wat de oorspronkelijke wiskundige probleem bedoelde?
- Analogie: De student kan een perfecte spelling hebben, maar heeft over "katten" geschreven terwijl de opdracht over "honden" ging. Het essay slaagde voor de grammatica-check, maar faaldede voor de betekenis-check.

De Grote Ontdekking:
De auteurs ontdekten een enorme kloof tussen deze twee.

Hun beste AI-systeem kon 89,5% van de vertalingen laten "compileren" (slagen voor de grammatica-check).
Echter, slechts 60,5% van die vertalingen was daadwerkelijk "getrouw" (ze betekenden hetzelfde).
De Kloof: Ongeveer 29% van de tijd produceerde de AI code die er perfect uitzag voor de computer, maar die feitelijk fout was in de betekenis. De AI had misschien een voorwaarde vergeten, een getal veranderd, of de stelling te makkelijk (of te moeilijk) gemaakt.

Hoe ze dit hebben Gemeten

Omdat computers niet altijd kunnen bepalen of een vertaling "betekenisvol" is, hebben de auteurs een nieuw testprotocol ontwikkeld:

De Benchmark: Ze verzamelden 400 moeilijke wiskundige problemen uit tekstboeken op graduate-niveau (Real Analysis, Complex Analysis, Topology en Algebra).
Het "Rechtbank"-panel: In plaats van slechts één computer, gebruikten ze twee verschillende geavanceerde AI-modellen om als rechters te fungeren. Ze vroegen deze rechters: "Betekent deze Lean-code hetzelfde als de Engelse zin?"
De Consensusregel: Voor een vertaling om als "Getrouw" te tellen, moesten beide AI-rechters ermee instemmen dat het goed was.
Menselijke Audits: Om er zeker van te zijn dat de AI-rechters niet door draalden, controleerden menselijke wiskunde-experts willekeurig de resultaten. Zij bevestigden dat wanneer de AI-rechters zeiden: "Nee, dit is fout," ze meestal ook gelijk hadden.

De Toolkit: Hoe de Vertalingen te Verbeteren

De auteurs testten een "tool-augmented agent" (een slimme AI-assistent) die drie specifieke tools kon gebruiken om haar fouten te herstellen. Ze behandelden dit als een wetenschappelijk experiment, waarbij ze de tools aan- en uitzetten om te zien welke het meest hielp.

Beschouw de AI als een student die probeert een wiskundige vertaling te schrijven. De tools zijn:

Expert Drafting (T): De AI vraagt een gespecialiseerde "vertaler-bot" om een eerste concept.
- Analogie: Een professionele vertaler vragen om een ruwe versie voordat je gaat redigeren.
Search (S): De AI zoekt definities en symbolen op in de wiskundige bibliotheek (Mathlib) of op het web.
- Analogie: Een woord opzoeken in het woordenboek om er zeker van te zijn dat je de juiste term gebruikt.
Feedback (F): De AI probeert de code te compileren. Als dat mislukt, geeft de computer een foutmelding en probeert de AI het te herstellen.
- Analogie: De docent die het essay nakijkt en zegt: "Je bent hier een komma vergeten," of "Deze zin is niet logisch."

De Resultaten van de Toolkit:

Feedback (F) is de MVP: Dit was de krachtigste tool. Het herstelde de meeste "grammaticafouten" (compilatieproblemen). Echter, het onthulde ook een probleem: door de grammatica zo agressief te herstellen, creëerde het soms code die grammaticaal perfect was, maar nog steeds de verkeerde betekenis had.
Search (S) helpt bij het funderen: Het hielp de AI om de juiste woorden te kiezen, maar het was niet zo krachtig als Feedback.
Expert Drafting (T) werd minder belangrijk: Zodra de AI beschikte over Feedback en Search, voegde de "ruwe versie" van de expert-bot niet veel meer waarde toe. De AI kon net zo goed presteren als zij de andere tools tot haar beschikking had.

De Belangrijkste Conclusie

De auteurs concluderen dat we moeten stoppen met het vieren van AI enkel omdat het code kan "compileren".

De Oude Manier: "Kijk! De AI schreef code die de computer accepteerde!"
De Nieuwe Manier: "Kijk! De AI schreef code die de computer accepteerde EN die ook daadwerkelijk betekent wat we vroegen!"

De auteurs tonen aan dat hoewel AI erg goed wordt in de "grammatica" van wiskundige code, het nog steeds moeite heeft om de "betekenis" intact te houden. Ze bieden een nieuwe manier om deze kloof te meten en laten zien dat het gebruik van een combinatie van tools (vooral feedback en zoekopdrachten) de beste manier is om deze kloof te overbruggen, maar zelfs dan blijft een aanzienlijk deel van de vertalingen de oorspronkelijke betekenis kwijtraken.

Kortom: Alleen omdat de computer zegt "Goed gedaan", betekent het niet dat de AI de wiskunde echt begrepen heeft. We moeten controleren of de betekenis behouden is gebleven, niet alleen of de code werkt.

Technisch overzicht: Voorbij compilatie: Evaluatie van getrouwe natural-language-naar-Lean statement formalisering

1. Probleemstelling

Het artikel behandelt de taak van natural-language-naar-Lean statement formalisering: het automatisch vertalen van informele wiskundige beweringen naar geldige Lean 4-stellingverklaringen. Deze taak is verschillend van stellingbewijzen (theorem proving). In benchmarks voor stellingbewijzen (bijv. MiniF2F, LeanDojo) is de formele verklaring vastgesteld en betrouwbaar; het doel van het systeem is om een bewijs te genereren dat wordt geaccepteerd door de checker. Bij statement formalisering moet het systeem zelf de verklaring genereren.

De kernuitdaging is dat compilatie een noodzakelijke maar onvoldoende voorwaarde is voor succes. Een Lean-verklaring kan type-checken (compileren) terwijl deze:

Cruciale hypothesen weglaat.
Het domein van de discussie verandert.
De bewering versterkt of verzwakt.
Een triviale versie van het resultaat codeert.

Eerder werk heeft vaak vertrouwd op compilatieratio's of referentiegebaseerde equivalentiemetrieken (bijv. BEq, back-translation). Dit artikel betoogt dat compilatie alleen een "compile-pass gap" creëert waarbij systemen succesvol lijken, maar falen in het behoud van de beoogde wiskundige betekenis. De auteurs definiëren het centrale probleem als het evalueren van getrouwe statement formalisering: het genereren van verklaringen die zowel compileren als de semantische intentie van de natural-language input behouden.

2. Methodologie

2.1 Benchmark Constructie

De auteurs hebben een graduate-level benchmark samengesteld bestaande uit 400 natural-language statements afgeleid van open-source LaTeX college aantekeningen en tekstboeken. De dataset is gebalanceerd over vier domeinen:

Real Analysis (100 items)
Complex Analysis (100 items)
Topology (100 items)
Algebra (100 items)

Cruciaal is dat deze statements geen bijbehorende gouden Lean verklaringen hebben, wat garandeert dat de taak echte vertaling vertegenwoordigt in plaats van retrieval.

2.2 Evaluatieprotocol

Het artikel stelt een Consensus LLM-as-Judge metriek voor, gekalibreerd door menselijke experts, om getrouwheid te evalueren. Het protocol omvat twee fasen:

Compiler Verificatie: Elke code die niet compileert, wordt onmiddellijk als ongetrouw beschouwd.
Semantische Consensus: Voor compilerende code vergelijken twee onafhankelijke LLM-judges (GPT-5.2 en Gemini-2.5-Pro) de gegenereerde Lean-verklaring met de oorspronkelijke natural-language statement. Ze kennen een getrouwheidsscore toe (0–10).
- Succesmetriek: Een vertaling wordt als Getrouw beschouwd indien en slechts indien het compileert EN beide judges een score van $\ge 9$ toekennen.
- Deze strikte consensus-aanpak is ontworpen als een conservatief operatiepunt voor systeemvergelijking, niet als een formeel bewijs van equivalentie.

2.3 Menselijke Kalibratie

Om de geautomatiseerde metriek te valideren, voerden de auteurs menselijke audits uit:

Consensus-Positief: 96,0% van de outputs die als getrouw werden gelabeld door de strikte consensus, werd bevestigd als getrouw door menselijke reviewers.
Consensus-Negatief (Compile-Pass): 82,4% van de outputs die compileerden maar werden afgewezen door consensus, werden door mensen bevestigd als echte semantische fouten.
Dit bevestigt dat de metriek een hoog-precisie, conservatieve filter is die effectief semantische drift identificeert.

2.4 Experimentele Opzet: Factorieel Ontwerp

De auteurs evalueerden diverse systemen (general-purpose LLMs, gespecialiseerde formalizers, prover-georiënteerde modellen en tool-augmented agents) met behulp van een $2^3$ factorieel ontwerp om de effecten van drie veelvoorkomende interventies te deconstrueren:

Parametric Expert Drafting (T): Het gebruik van een fine-tuned model (Herald) om een initiële conceptversie te genereren.
Knowledge Search (S): Het gebruik van tools om Mathlib te bevragen (symbol lookup, namespace resolution) en web searches uit te voeren voor grounding.
Lean Elaboration Feedback (F): Het gebruik van een REPL om code iteratief te compileren en foutmeldingen te ontvangen voor reparatie.

De agent-architectuur gebruikt een centrale orchestrator (GPT-5.2) die de staat bijhoudt en beslist welke tools te gebruiken op basis van de configuratie.

3. Belangrijkste Resultaten

3.1 De Compile-Pass Gap

De meest significante empirische bevinding is de divergentie tussen compilatieratio's en semantische getrouwheid:

Een volledige tool-augmented agent bereikte een compilatieratio van 89,5%.
Echter, onder de strikte consensus-metriek werd slechts 60,5% van de outputs als getrouw beschouwd.
Dit laat een gap van 29,0 punten achter waar outputs compileren maar falen in de semantische check. Menselijke audits bevestigden dat de meerderheid van deze "compile-pass, consensus-negative" gevallen echte semantische fouten zijn (bijv. ontbrekende hypothesen, triviale claims).

3.2 Modelprestaties

Gespecialiseerde Formalizers & Prover Modellen: Dedicated statement formalizers (bijv. Herald, Kimina-Autoformalizer) en prover-georiënteerde modellen (bijv. Goedel-Prover, Kimina-Prover) presteerden slecht op statement generatie wanneer het formele doel niet werd meegeleverd. Hun getrouwheidscijfers varieerden van 4,0% tot 12,3%.
General LLMs: One-shot general-purpose LLMs bereikten 19,8–28,0% getrouwheid.
Tool-Augmented Agents: Het volledige agent-framework presteerde aanzienlijk beter dan one-shot baselines, met een getrouwheid van 60,5%. Verschillende orchestrators (Sonnet 4.5, Gemini-2.5-Pro) convergeerden echter naar vergelijkbare prestatieniveaus (60–65%) ondanks verschillende baselines, wat suggereer dat de winst structureel is aan de tool-augmented aanpak in plaats van specifiek aan het orchestrator-model.

3.3 Factoriële Decompositie van Interventies

De studie isoleerde de impact van de drie tools:

Elaboration Feedback (F): Dit was de grootste drijver van validiteit (compilatie), waardoor de compilatieratio aanzienlijk steeg. Echter, het vergrootte ook de "compile-pass maar ongetrouwe" categorie, omdat het meer syntactisch correcte maar semantisch afwijkende statements doorliet.
Search (S): Search verbeterde primair de grounding en selectiviteit. Het verminderde de compile-pass gap (d.w.z. het hielp semantisch incorrecte statements die toch compileerden eruit te filteren) en verbeterde de efficiëntie door het aantal benodigde REPL-iteraties te verminderen. Het marginale voordeel was het grootst wanneer feedback afwezig was.
Expert Drafting (T): De fine-tuned drafting prior was grotendeels vervangbaar zodra feedback en grounding beschikbaar waren. Sterker nog, met volledige feedback schaadde de drafting prior de prestaties licht, wat suggereert dat een sterke orchestrator met compiler feedback een gespecialiseerde draft kan overtreffen in deze specifieke tool stack.

3.4 Domeinspecifieke Variaties

Complex Analysis vertoonde de hoogste winsten door compiler feedback (+54,2 punten in getrouwheid), waarschijnlijk door de volwassen Mathlib-dekking.
Real Analysis en Algebra vertoonden kleinere winsten, wat wijst op ofwel beperkte library support of een hogere intrinsieke moeilijkheidsgraad van de formalisering.
Topology vertoonde specifieke uitdagingen met geavanceerde concepten (bijv. covering spaces), waarbij feedback vaak leidde tot geldige maar semantisch verschoven statements.

4. Betekenis en Claims

Het artikel claimt dat statement formalisering moet worden geëvalueerd als behoud van betekenis, niet enkel als Lean-acceptatie. De primaire bijdragen zijn:

Een Nieuwe Metriek: Een door mensen gekalibreerde, consensus-gebaseerde metriek die de "compile-pass gap" blootlegt, wat onthult dat veel systemen syntactisch geldige maar semantisch incorrecte statements genereren.
Diagnostische Decompositie: Een factoriële analyse die aantoont dat tools geen monotone toevoegingen zijn. Terwijl feedback de syntaxis herstelt, kan het semantische fouten maskeren; search verbetert de grounding maar heeft afnemende meeropbrengsten wanneer feedback aanwezig is; en gespecialiseerde drafting is niet altijd noodzakelijk in een feedback-rijke loop.
Systeemvergelijking: Bewijs dat huidige prover-georiënteerde modellen en gespecialiseerde formalizers hun bewijskracht niet automatisch overdragen naar semantisch getrouwe statement generatie zonder expliciete statement-gecentreerde training of tool-augmented protocollen.

De auteurs concluderen dat toekomstige systemen een sterke Lean feedback moeten combineren met semantische evaluatie en beleid dat bepaalt wanneer te zoeken, te repareren of te stoppen, in plaats van enkel te vertrouwen op gemiddelde nauwkeurigheidswinsten alleen. Het artikel vermijdt expliciet de claim dat hun metriek een formeel bewijs van equivalentie is, en positioneert het in plaats daarvan als een conservatieve, schaalbare beslissingsgrens voor systeemvergelijking.