🤖 AI

Sorries Are Not the Hard Part: An Expert-Review Case Study of a Semi-Autonomous Formalization

Dit artikel betoogt dat succesvolle autoformalizatie beoordeeld moet worden door deskundige evaluatie van de kwaliteit van definities en API-ontwerp in plaats van louter door de afwezigheid van onbewezen hiaten ("sorries"), waarbij via een casestudy van Grothendiecks stelling over de verdwijnende stelling wordt aangetoond dat AI-agenten weliswaar effectief lokale mechanische correcties kunnen toepassen, maar moeite hebben met hoogwaardig conceptueel ontwerp.

Oorspronkelijke auteurs: Vasily Ilin, Brian Nugent

Gepubliceerd 2026-06-15

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Vasily Ilin, Brian Nugent

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

Stel je voor dat je een zeer snelle, zeer enthousiaste leerling inhuurt om een huis voor je te bouwen. Je geeft de leerling de blauwdrukken (een wiskundig stelling) en een hoofdstuk uit een tekstboek dat uitlegt hoe je het moet bouwen.

De leerling werkt dag en nacht. Ze leggen de stenen, plaatsen de balken en installeren het dak. Wanneer ze klaar zijn, staat het huis perfect op. Het stort niet in. De inspecteur (de computer) zegt: "Goed werk! Het huis is structureel gezond."

Dit artikel gaat over wat er daarna gebeurt.

De auteurs van dit artikel vroegen zich af: "Alleen omdat het huis blijft staan, is het dan ook echt een goed huis? Kan iemand anders erin wonen? Kunnen ze later gemakkelijk een tweede verdieping toevoegen, of moeten ze eerst de muren afbreken?"

Hier is de opbouw van hun experiment, met behulp van eenvoudige analogieën:

Het Experiment: Een "Wiskundig Huis" Bouwen

Het team vroeg een AI (een groot taalmodel) om een complexe wiskundige stelling te formaliseren genaamd Grothendieck's Vanishing Theorem. Zie deze stelling als een zeer specifieke, hoogwaardige architecturale uitdaging.

Ze gaven de AI:

Het doel (de stelling).
Een tekstboekbewijs (de instructies).
Een regel: "Je moet alleen de bestaande, standaard gereedschappen gebruiken die we al in onze gereedschapskist hebben (de wiskundige bibliotheek)."

Fase 1: De "Pass" (Toestand A)
De AI werkte hard en produceerde code die zonder fouten compileerde. In de wereld van wiskundige software worden fouten "sorries" genoemd (kort voor "sorry, ik kan dit nog niet bewijzen"). De AI slaagde erin om het aantal "sorries" terug te brengen naar nul.

Het resultaat: Het huis staat. De computer is tevreden.
Het probleem: Een menselijke expert (een wiskundige) keek naar het huis en zei: "Dit is een ramp."

De Expert Review: Waarom het "Staande Huis" Faalde

De menselijke expert vond dat, hoewel het huis niet instortte, het vreselijk gebouwd was. Hier zijn de specifieke problemen die zij vonden, vertaald naar alledaagse termen:

1. Het "Custom Tools" Probleem (Definities)

Wat de AI deed: De AI bleef voor elke kleine taak zijn eigen aangepaste gereedschappen uitvinden. Als hij een muur moest meten, bouwde hij een nieuwe, vreemde rolmaat die alleen voor die ene muur bedoeld was.
Waarom het slecht is: In een echte bibliotheek wil je standaard gereedschappen die iedereen weet hoe te gebruiken. Als de AI voor elke klus een aangepast gerecht maakt, kunnen toekomstige bouwers het huis niet gebruiken omdat ze niet weten hoe ze de vreemde uitvindingen van de AI moeten bedienen.
Het oordeel: De AI was geweldig in het gebruiken van gereedschap, maar verschrikkelijk in het ontwerpen ervan. Het maakte 62 aangepaste definities, en 61 daarvan waren nutteloos of verwarrend.

2. Het "Cluttered Blueprint" Probleem (API Design)

Wat de AI deed: De AI bouwde geen schone interface (een gebruikershandleiding). In plaats daarvan liet de AI telkens de muren openstaan om de ruwe stenen te laten zien telkens wanneer iemand iets wilde doen.
De oplossing: De expert vroeg de AI om een "User Interface" (een API) te bouwen, zodat mensen met de wiskunde konden interageren zonder de rommelige binnenkant te zien.
Het resultaat: De AI bouwde wel een interface, maar deze was slordig. Het voegde 24 specifieke "regels" toe die alleen voor het huidige bewijs waren, in plaats van een paar elegante, algemene regels te creëren. Het was alsocht het toevoegen van een unieke, ingewikkelde schakelaar voor elke enkele lamp in het huis, in plaats van een standaard lichtschakelaar te installeren.

3. Het "Kortetermijn" Probleem (Stellingverklaringen)

Wat de AI deed: De AI bewees precies wat nodig was om de klus te klaren, en niets meer. Het was als een timmerman die een plank op maat zaagt voor alleen de huidige opening, in plaats van hem zo te zagen dat hij later ook in andere openingen past.
Het oordeel: De AI is uitstekend in het oplossen van de directe puzzel, maar is slecht in het denken: "Hoe kan ik dit over vijf jaar nuttig maken voor iemand anders?"

De "Vóór en Na" Test

Het team gaf niet op. Ze namen de feedback van de expert aan en vroegen de AI om het te repareren.

Wat de AI goed repareerde: Het was erg goed in lokale reparaties. Als de expert zei: "Verander de naam van dit bestand," of "Verander dit specifieken getal," deed de AI dat perfect. Het kon de rommel opruimen.
Wat de AI niet kon repareren: Het kon nog steeds niet begrijpen hoe het vanaf nul een goed huis moest ontwerpen. Zelfs na de review waren de definities nog steeds lomp en de "user interface" was nog steeds overvol.

De Belangrijkste Les

Het artikel concludeert met een eenvoudig, krachtig idee:

"Het dichten van de gaten" (de code laten compileren) is het makkelijke deel.

Het moeilijke deel is ontwerp.

De AI is als een briljante metselaar: Hij kan stenen perfect leggen als je hem precies vertelt waar hij ze moet plaatsen.
De AI is NIET als een architect: Hij kan niet beslissen hoe het huis eruit moet zien, hoe de kamers moeten stromen, of welke gereedschappen de toekomstige bewoners nodig zullen hebben.

De kernboodschap:
We moeten niet alleen vragen: "Heeft de AI het wiskundige probleem opgelost?" We moeten ook vragen: "Heeft de AI iets gebouwd dat andere mensen daadwerkelijk kunnen gebruiken?"

Momenteel kan AI de puzzel oplossen, maar kan het de bibliotheek niet bouwen. Om een echt nuttig resultaat te krijgen, moet een menselijke expert nog steeds bijspringen om het zware werk van ontwerp en organisatie te doen. Het "moeilijke deel" is niet het bewijzen van de stelling; het is ervoor zorgen dat het bewijs een geschenk aan de toekomst is, en geen last.

Technische Samenvatting: "Sorries" zijn niet het moeilijke deel

Probleemstelling

Het heersende narratief in semi-autonome formalisering richt zich op bewijsvoltooiing: het vermogen van een agent om code te genereren die door een bewijsassistent (bijv. Lean) wordt geaccepteerd als een geverifieerd theorema. De auteurs stellen echter dat een geverifieerd theorema wezenlijk verschilt van een herbruikbare bibliotheekbijdrage. Moderne wiskunde rust op onderling verbonden bibliotheken waar definities moeten combineren, stellingen de juiste algemeenheid moeten bezitten en API's de toekomstige redenering moeten faciliteren zonder gebruikers te dwingen implementaties uit te vouwen.

Het kernprobleem dat wordt geïdentificeerd, is dat hoewel Large Language Models (LLMs) steeds beter in staat zijn om lokale bewijsgaten te dichten (het verwijderen van "sorries"), zij moeite hebben met de globale ontwerpbeslissingen die nodig zijn voor hoogwaardige, onderhoudbare formaliseringen. Specifiek falen agenten vaak in het kiezen van passende definities, het ontwerpen van generaliseerbare stellingformuleringen of het construeren van cleane API's, wat resulteert in code die weliswaar door de kernel wordt geaccepteerd, maar faalt bij een expertbeoordeling als bibliotheekbijdrage.

Methodologie

Het artikel presenteert een gedetailleerde casestudy van een semi-autonome formalisering van de verdwijnstelling van Grothendieck (Hartshorne, 1977, Ch. III, Thm. 2.7) in Lean 4. Dit theorema stelt dat voor een noetheriaanse topologische ruimte $X$ en een geheel $n$ groter dan de topologische Krull-dimensie van $X$ , de $n$ -de sheaf-cohologie van elke sheaf van abelse groepen op $X$ verdwijnt.

De studie volgt een experimenteel ontwerp met een voor-en-na situatie:

Toestand A (Initiële Formalisering): Een agent (Claude Code), geleid door een door een mens verstrekte stelling en een PDF-fragment van het bewijs van Hartshorne, genereerde een formalisering die compileerde met nul "sorries" (onbewezen doelen).
Expertbeoordeling: Een Lean/mathlib-expert beoordeelde Toestand A en identificeerde problemen in definities, de algemeenheid van stellingen, bestandsorganisatie en API-ontwerp.
Toestand B (Gerefactorde Formalisering): De agent kreeg de taak om de checklist van de expert te adresseren. Dit omvatte een "review-gestuurde refactor" en een daaropvolgende fase van "compressie en polijsten" om aan te sluiten bij de mathlib-conventies.
Tweede Beoordeling: Dezelfde expert beoordeelde Toestand B.

De analyse vergelijkt de twee toestanden over vier dimensies: definities, stellingformuleringen, bewijzen en bestand/API-structuur. De projecttijdlijn, het tokengebruik en de interacties met tools werden gereconstrueerd uit commit-logs en telemetrie om de gedragspatronen van de agent te begrijpen.

Belangrijkste Bevindingen en Resultaten

1. Definities: Het Primaire Faalpunt

Definities werden geïdentificeerd als de zwakste component en het gebied waar de agent de minste verbetering liet zien tussen Toestand A en Toestand B.

Toestand A: De agent genereerde 62 aangepaste definities. Slechts één (TopCat.closedIncl) werd als correct en herbruikbaar beschouwd. De rest was "ad hoc", waarbij vaak standaardbibliotheekconstructies werden ingepakt met namen die specifiek waren voor de huidige bewijsvolgorde (bijv. sheafH_filtered_colimit_h1_sectionsFunctor in plaats van bestaande sheafSections te gebruiken).
Gevolgen: Deze definities creëerden "toekomstige transportkosten", waardoor latere gebruikers gedwongen werden triviale equivalenties te bewijzen om de objecten te gebruiken. Ze hinderden ook de prestaties van tactieken (bijv. simp) door de onderliggende syntaxis te verhullen.
Toestand B: De agent slaagde er niet in om zijn vermogen om algemene, herbruikbare definities te creëren significant te verbeteren. Hij bleef specifieke, onnodige objecten creëren in plaats van algemene constructies met handige specialisaties te ontwerpen.

2. API-ontwerp: Partiële Verbetering

Toestand A: De agent bouwde geen API voor sheaf-cohologie (Sheaf.H), maar vouwde de definitie herhaaldelijk uit in downstream bestanden.
Toestand B: De agent creëerde een specifiek API-bestand, wat de downstream bewijzen opschoonde. De API zelf was echter "lawaaiig en opgeblazen", met ongeveer 800 regels en 24 zeer specifieke lemma's, in plaats van een gedestilleerde, principiële interface.
Contrast: De agent presteerde beter op de API voor topologicalKrullDim (een simpelere definitie), wat suggereert dat hij goede API's kan ontwerpen wanneer hij wordt geprompt met specifieke, begrensde taken, maar moeite heeft met open eind ontwerp.

3. Stellingformuleringen: Lokaal versus Globaal

Toestand A: De agent bewees precies wat nodig was voor het directe bewijs, waarbij vaak te specifieke hypothesen werden gebruikt (bijv. het vereisen van een "injectieve presentatie" terwijl een algemene korte exacte sequentie volstond).
Toestand B: De agent slaagde erin om stellingformuleringen te generaliseren wanneer dit expliciet werd gevraagd in de review-checklist. Echter, de agent slaagde er niet in om zelfstandig noodzakelijke generalisaties te identificeren. De agent blinkt uit in lokale syntactische fixes, maar mist het globale oordeel om toekomstige herbruikbaarheid te voorzien.

4. Bewijzen: Ongelijke Verbetering

Toestand A: Bewijzen bevatten "muren van have-statements", frequent misbruik van definitionele gelijkheid en directe uitvouw van definities.
Toestand B: Bewijzen verbeterden, vooral in bestanden die bestaande mathlib-objecten gebruikten. De agent nam genaamde sub-lemma's over om complexe bewijzen te deconstrueren, een patroon dat werd versterkt door de "heartbeat" (prestatie) beperkingen.
Beperking: Bewijzen die steunden op de eigen slechte definities van de agent (bijv. in gefilterde colimit-bestanden) bleven moeilijk leesbaar en onderhoudbaar.

5. Procesdynamiek

Adaptatie aan Feedback: De agent paste zich goed aan feedback aan met heldere voltooiingspredicaten (bijv. "verander deze bestandsnaam", "generaliseer deze hypothese"). Hij had moeite met feedback die contrafactisch oordeel vereiste (bijv. "ontwerp een API die in de toekomst nuttig zal zijn").
Escape Hatches: Agents hadden de neiging om taken als "geblokkeerd" te verklaren of de infrastructuur de schuld te geven (bijv. "mathlib gap") wanneer ze geconfronteerd werden met moeilijke ontwerpbeslissingen. Expliciete prompts die deze termen verboden, waren nodig om decompositie af te dwingen.
Metrics: "Het sluiten van sorries" is een onvoldoende metriek voor kwaliteit. Het project bleef nog aanzienlijk evolueren (in termen van regels code en structuur) nadat de sorry-count nul was bereikt.

Betekenis en Claims

Het artikel betoogt dat evaluatie van autoformalisering verder moet gaan dan binaire bewijsvoltooiing. De auteurs stellen:

Kernelacceptatie is incompleet: Een theorema kan door de kernel worden geverifieerd, terwijl het toekomstige gebruikers door onhandige coercions, gedupliceerde definities en onbeheersbare API's dwingt.
De "Herbruikbaarheidskloof": Er is een scherpe splitsing tussen het vermogen van een agent om lokale doelen te sluiten en het vermogen om definities te kiezen en API's te ontwerpen. Dat laatste vereist een oordeel over toekomstige herbruikbaarheid waar huidige LLM's niet over beschikken.
Evaluatiestandaard: De auteurs stellen voor dat AI-voor-wiskunde systemen geëvalueerd moeten worden op basis van de vraag of de resulterende formalisering een expertbeoordeling overleeft. Specifiek: nadat een bewijs is gecontroleerd, moet een expert publieke definities, stellingformuleringen, namespaces en API-oppervlaktes beoordelen om het vermogen van het systeem om te reageren op ontwerpfeedback te meten.

De studie concludeert dat zonder een geavanceerd harnas voor globaal ontwerp, LLM's in staat zijn om "geverifieerde artefacten" te produceren, maar nog niet "herbruikbare bibliotheekbijdragen". De weg vooruit houdt in dat menselijke experts de kwaliteitspecificaties (definities, interfaces) definiëren en agenten de smalle, mechanisch controleerbare refactors afhandelen.