🤖 AI

Faithful Autoformalization of Natural Language Assertions

Het artikel introduceert Monty, een autoformaliseringsframework dat de precisie van het synthetiseren van uitvoerbare beweringen uit natuurlijke taal verbetert door door een LLM gegenereerde outputs te filteren met behulp van nieuwe conformiteitsscores en validiteitsscores, waarbij een gemiddelde precisiewinst van tot wel 20 punten wordt behaald ten opzichte van naïeve vertaalmethoden.

Oorspronkelijke auteurs: Hongyi Liu, Madhusudan Parthasarathy, Adithya Murali

Gepubliceerd 2026-07-16

📖 7 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Hongyi Liu, Madhusudan Parthasarathy, Adithya Murali

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 Dilemma van de Vertaler: Wanneer Code Menselijke Woorden Ontmoet

Stel je voor dat je een enorme digitale stad bouwt. Om de verkeersstroom op gang te houden en de gebouwen overeind te houden, heeft elke straathoek en elke wolkenkrabber een regelboek nodig. In de wereld van software worden deze regelboeken "formele specificaties" genoemd. Het zijn precieze, wiskundige instructies die een computer precies vertellen wat een stuk code moet doen en wat het nooit mag doen. Beschouw ze als de onbreekbare natuurwetten voor een digitale wereld. Het probleem is dat het schrijven van deze wetten ongelooflijk moeilijk is. Het vereist een niveau van precisie dat aanvoelt alsof je een totaal andere taal spreekt, een taal die de meeste menselijke programmeurs saai en foutgevoelig vinden.

Hier komt het "autoformalisatie"-probleem om de hoek kijken. Dit is de zoektocht om een rommelig, natuurlijk taalidee van een mens — zoals "laat de lijst niet te groot worden" — automatisch te vertalen naar die strikte, wiskundige code. Jarenlang hebben wetenschappers geprobeerd om Kunstmatige Intelligentie (AI), specifiek Large Language Models (LLMs), te gebruiken als vertalers. Deze AI-modellen zijn als super-intelligente polyglotten die bijna alles hebben gelezen wat ooit geschreven is. Ze zijn erg goed in het raden van de betekenis van een zin. Maar hier is de crux: wanneer je een AI vraft om een vage menselijke gedachte te vertalen naar een strikt juridisch contract, hallucineert het vaak. Het kan regels verzinnen die niet bestaan, een minuscuul detail missen dat het hele systeem breekt, of vol vertrouwen een "misschien" vertalen in een "absoluut". De kernvraag die dit artikel aanpakt is: Hoe kunnen we een AI-vertaler vertrouwen wanneer de inzet hoog is en de menselijke instructies vaag zijn?

Maak kennis met Monty: De Detective die het Huiswerk van de AI Controleert

Dit artikel introduceert een nieuw framework genaamd Monty, een systeem ontworpen om een sceptische, detailgeoriënteerde redacteur te zijn voor door AI gegenereerde coderegels. De auteurs, onderzoekers van de University of Wisconsin-Madison en de University of Illinois, realiseerden zich dat het simpelweg vragen aan een AI om een zin in code te vertalen niet genoeg is. Als je een AI vraagt om "de lijst moet leeg zijn" te vertalen, kan de AI raden dat dit betekent "de lijst heeft nul items" of "de lijst bevat helemaal geen items". Beiden klinken juist, maar in computercode kunnen ze heel verschillende dingen betekenen.

Monty vertrouwt niet zomaar op het eerste antwoord dat de AI geeft. In plaats daarvan fungeert het als een detective die een reeks tests uitvoert. Zo verloopt het verhaal:

1. De AI genereert een menigte verdachten
Eerst vraagt Monty aan een Large Language Model om een natuurlijke taal-bewering (een menselijke zin) te vertalen naar formele code. De AI geeft niet slechts één antwoord; het genereert een hele menigte "kandidaat"-vertalingen. Sommige zijn perfect, sommige zijn er net naast, en sommige zijn volkomen fout.

2. De "Fuzz" Test: De Code Breken
Vervolgens onderwerpt Monty deze kandidaat-vertalingen aan een stress-test die "fuzzing" wordt genoemd. Stel je een robot voor die willekeurige, wilde inputs naar de code gooit om te zien of de boel crasht of vreemd gedrag vertoont.

Als een kandidaat-vertaling de computer laat crashen of een foutmelding geeft, gooit Monty deze onmiddellijk weg.
Als de vertaling wel werkt, maar niet overeenkomt met de logica van de oorspronkelijke menselijke zin, krijgt deze een lage score.
Cruciaal is dat Monty er niet vanuit gaat dat de menselijke zin correct is. Soms schrijft een programmeur een regel die eigenlijk fout is (een "buggy" regel). Monty is slim genoeg om te beseffen dat een "geldige" vertaling van een "buggy" regel nog steeds een bug is. Het zoekt naar zowel de meest waarschijnlijke correcte vertaling als de meest waarschijnlijke onjuiste vertaling om te zien welke het beste in de context past.

3. De "Clause Coverage" Check: De Omgekeerde Vertaling
Dit is het geheime wapen van Monty. Om te controleren of een AI-vertaling werkelijk getrouw is, gebruikt Monty een slimme truc genaamd clausal coverage. Het neemt de formele code van de AI en vraagt de AI om deze terug te vertalen naar gewone menselijke taal. Vervolgens vergelijkt het deze nieuwe Engelse zin met de oorspronkelijke menselijke zin.

Heeft de AI een deel van de oorspronkelijke zin gemist?
Heeft de AI iets toegevoegd dat er niet was?
Heeft het de betekenis veranderd?
De AI fungeert als een rechter en geeft een score op basis van hoe goed de onderdelen (clausules) van de twee zinnen overeenkomen. Als de terugvertaling een essentieel detail mist, daalt de score en wordt die kandidaat weggefilterd.

4. De Laatste Confrontatie: Active Learning
Soms genereert de AI twee kandidaten die er allebei perfect uitzien en alle tests doorstaan, maar die net iets andere dingen betekenen. Dit is waar de "ambiguïteit" van menselijke taal weer de kop opsteekt. In deze zeldzame gevallen gokt Monty niet. Het maakt gebruik van active learning. Het vindt een specifiek scenario (een "distinguishing valuation") waarin de twee kandidaten zich anders zouden gedragen. Vervolgens stelt het een mens (of een gesimuleerde oracle) een simpele vraag: "In dit specifieke geval, welke regel bedoelde u eigenlijk?" De mens kiest de winnaar, en Monty legt de juiste vertaling vast.

Wat Monty Vond

De onderzoekers testten Monty op 541 verschillende taken met betrekking tot Java-code, een populaire programmeertaal. Ze gebruikten datasets die zowel perfect geschreven regels als opzettelijk kapotte regels bevatten om te zien of Monty de rommeligheid van de echte wereld kon afhandelen.

De resultaten waren veelbelovend. Wanneer ze de AI de vertaling lieten doen zonder de hulp van Monty, was de nauwkeurigheid redelijk maar verre van perfect. Bijvoorbeeld, bij het gebruik van een specifiek model genaamd Qwen2.5-Coder, kreeg de ruwe AI de vertaling ongeveer 75% van de tijd goed op één dataset. Maar wanneer Monty ingreep om de antwoorden te filteren en te controleren, steeg die nauwkeurigheid naar 91,6%. Op een andere dataset ging het van 64% naar 85%.

Het artikel suggereert dat Monty bijzonder goed is in het oplossen van het "precisie"-probleem. Dit betekent dat wanneer Monty zegt: "Hier is de juiste regel," je die veel meer kunt vertrouwen dan wanneer je simpelweg een AI vraagt en het eerste antwoord accepteert. Het slaagde erin dit te doen zonder te veel correcte antwoorden weg te gooien (waardoor de "recall" hoog bleef).

Wat Monty Niet Doet

Het is belangrijk om te weten wat dit artikel niet beweert. Monty is geen toverstaf die elk programmeerprobleem oplost.

Het probeert niet de hoogwaardige "intentie" van een heel softwareproject te achterhalen (zoals "bouw een sociale media-app voor mij"). Het richt zich strikt op het vertalen van specifieke, gelokaliseerde regels voor individuele stukken code.
Het beweert niet het probleem van ambiguïteit voor altijd opgelost te hebben. Soms is de menselijke input zo vaag dat zelfs Monty een mens nodig heeft om te helpen bij de verduidelijking.
De auteurs argumenteren expliciet tegen het idee dat we er simpelweg vanuit moeten gaan dat elke regel die een programmeur schrijft correct is. Veel oudere tools gingen ervan uit dat als een regel was geschreven, deze ook waar moest zijn. Monty verwerpt dit en laat zien dat het doel soms is om de regel te vinden die faalt, om zo te bewijzen dat de code buggy is.

De Kernboodschap

Uiteindelijk suggereert Monty dat de toekomst van het schrijven van code niet alleen draait om het vragen aan een AI om het werk te doen. Het gaat om het bouwen van een systeem waarbij de AI ideeën genereert, maar een slim, rigoureus proces deze controleert tegen de realiteit. Door de creativiteit van AI te combineren met de scepsis van testen en de precisie van "omgekeerde vertaling", laat Monty een pad zien naar het veiliger en betrouwbaarder maken van software. Het zet de stap van de rommelige, ambigue gedachten van menselijke ontwikkelaars naar de zuivere, onbreekbare wetten van de digitale wereld. Het artikel suggereert dat hoewel we er nog niet zijn, deze "controleer-je-werk"-benadering een belangrijke stap voorwaarts is in het maken van AI tot een betrouwbare partner in softwareontwikkeling.

Technische Samenvatting: Getrouwe Autoformalizatie van Natuurlijke Taal-asserties

Probleemstelling

Het artikel behandelt de uitdaging van betrouwbare autoformalizatie: het synthetiseren van uitvoerbare formele asserties (bijv. in Java Modeling Language, JML) vanuit natuurlijke taal (NL) specificaties. Hoewel Large Language Models (LLMs) een pad bieden om de kloof tussen informele ontwikkelaarsintentie en formele specificaties te overbruggen, lijden huidige benaderingen aan twee kritieke problemen:

Ongetrouwheid (Unfaithfulness): LLM's genereren vaak formalisaties die niet nauwkeurig de semantische inhoud van de oorspronkelijke NL-assertie weerspiegelen.
Ambiguïteit: Natuurlijke taal is inherent ambigu. Bestaande werken gaan vaak impliciet ervan uit dat de NL-assertie een geldige eigenschap van de code beschrijft. Echter, in contexten zoals het opsporen van bugs of het testen van door AI gegenereerde code, kan de assertie bedoeld zijn om ongeldig te zijn (d.w.z. om een foutieve staat te onthullen). Het aannemen van geldigheid kan leiden tot het wegfilteren van de correcte formalisatie als de code buggy is, of het accepteren van een formalisatie die de intentie van de gebruiker niet controleert.

Het doel is om een formalisatie te produceren die getrouw is aan de NL-specificatie, ongeacht of de resulterende assertie nu wel of niet geldig is met betrekking tot de code-implementatie.

Methodologie: Het Monty-framework

De auteurs stellen Monty voor, een framework dat LLM-generatie combineert met programma-testen en actieve leerprocessen om ambiguïteit op te lossen en getrouwheid te waarborgen. De pijplijn bestaat uit vier stadia:

1. Kandidaatgeneratie

Gegeven een codemodule (class), methode-signaturen, documentatie en een NL-specificatie, wordt een LLM geprompt om meerdere kandidaat formele specificaties ( $\psi_1, \dots, \psi_n$ ) te genereren in een uitvoerbare logica (JML).

2. Filteren en Scoringsproces

Kandidaten worden geëvalueerd met behulp van twee complementaire signalen:

Geldigheidsscore (Execution-Level): Een testgenerator (Randoop) creëert testinputs om de kandidaten te controleren.
- Syntactische controle: Controleert of de code compileert.
- Fuzz-veiligheidscontrole: Controleert of de assertie geen runtime-exceptions veroorzaakt.
- Fuzz-semantische controle: Bepaalt of de assertie test-geldig of test-ongeldig is voor de gegeven methode.
- Opmerking: Het framework verwerpt kandidaten niet simpelweg omdat ze test-ongeldig zijn; het behoudt ze om gevallen af te handelen waarin de gebruiker bedoeld heeft fouten te vinden.
Conformiteitsscore (Semantic-Level): Een nieuwe metriek genaamd Clausal Coverage wordt gebruikt.
- De formele kandidaat wordt door een LLM terugvertaald naar natuurlijke taal.
- Een tweede LLM (optredend als rechter) vergelijkt de clausale structuur van deze gegenereerde NL-beschrijving met de oorspronkelijke NL-assertie.
- Het controleert op Soundness (dekt de beschrijving alle clausules van de originele?) en Completeness (bevat het extra of conflicterende informatie?).
- Er wordt een score toegekend in $[-1, 1]$ , waarbij $+1$ duidt op perfecte conformiteit. Kandidaten onder een drempelwaarde (bijv. 0,6) worden verworpen.

3. Beslissingsmatrix

Het systeem selecteert de "meest waarschijnlijk getrouwe" formalisaties door kandidaten in twee categorieën te verdelen op basis van de validatiecontrole:

De kandidaat met de hoogste conformiteitsscore onder degenen die test-geldig zijn.
De kandidaat met de hoogste conformiteitsscore onder degenen die test-ongeldig zijn.
Deze aanpak erkent dat de "correcte" formalisatie afhangt van de intentie van de gebruiker (documentatie vs. bug zoeken) en vermijdt de bias van het veronderstellen van geldigheid.

4. Actief Leren voor Disambiguatie

Als zowel een geldige als een ongeldige kandidaat overblijven (en beide een hoge conformiteitsscore hebben), identificeert het systeem een onderscheidende evaluatie (een specifieke input-toestand) waar de twee kandidaten van elkaar verschillen.

Het systeem bevraagt de gebruiker (of een oracle in evaluaties) om te bepalen welke kandidaat voldoet aan de beoogde specificatie voor deze specifieke evaluatie.
Het systeem selecteert vervolgens de bijbehorende formalisatie.

Belangrijkste Bijdragen

Getrouwe Autoformalizatie Framework: Een pijplijn die zowel waarschijnlijk geldige als ongeldige formalisaties genereert, waarmee de beperking van voorgaande werken die aannemen dat asserties geldig moeten zijn, wordt aangepakt.
Clausal Coverage Conformiteitscontrole: Een nieuwe techniek die gebruikmaakt van LLM-as-a-Judge om de semantische overlap tussen NL en formele asserties te evalueren via round-trip vertaling en clausale dekking-analyse. Het artikel beweert dat dit de standaard Natural Language Inference (NLI) baselines overtreft.
Actief Leren voor Disambiguatie: Een mechanisme om de inherente ambiguïteit van NL op te lossen door specifieke testgevallen te genereren die tussen concurrerende getrouwe formalisaties onderscheid maken.
Nieuwe Benchmark Suites: De auteurs hebben datasets samengesteld met 541 assertie-generatie taken over 22 Java collection-achtige klassen. Deze bevatten:
- C2S-Augmented: Synthetisch gegenereerde NL-specs afgeleid van formele asserties.
- Buggy Datasets: Scenario's met buggy code of opzettelijk onjuiste/misleidende asserties.
- Handmatige NL Specs: Door mensen geschreven specificaties om generaliseerbaarheid te testen.

Experimentele Resultaten

De auteurs hebben Monty geëvalueerd op 541 taken met diverse backbone LLM's (waaronder GPT-oss, Qwen2.5-Coder en grotere modellen).

Verbetering van Precisie: Monty verbetert de precisie van autoformalizatie aanzienlijk vergeleken met naïef "Oneshot" LLM-gebruik.
- Op de C2S-Augmented dataset verbeterde Qwen2.5-Coder (32B) de precisie van 75% naar 91,6%.
- Op de Manual NL dataset verbeterde de precisie van 64,1% naar 85,2%.
Behoud van Recall: Het filterproces behoudt een hoge recall (bijv. 97,6% voor GPT-oss op C2S-Aug), wat aangeeft dat correcte kandidaten zelden worden verworpen.
Robuustheid tegen Ambiguïteit: Het framework handelt "Buggy" datasets succesvol af waar de assertie bedoeld is om ongeldig te zijn, een scenario waarin naïeve LLM's vaak falen of hallucineren.
Ablatie-studies:
- De Clausal Coverage methode presteerde beter dan baselines (inclusief NLI en eenvoudige round-trip controles) in AUC-metrieken.
- Contextuele informatie (code-signaturen, docs) bleek cruciaal voor de kwaliteit van de ranking.
- Actief leren werd in een klein deel van de gevallen aangeroepen (waar zowel een geldige als een ongeldige kandidaat aan de conformiteitseisen voldeden), maar bleek effectief (100% nauwkeurigheid in in aanmerking komende gevallen voor GPT-oss).

Betekenis en Claims

Het artikel claimt dat Monty een betrouwbaarder pad naar autoformalizatie biedt door expliciet de ambiguïteit van natuurlijke taal en de onzekerheid van de geldigheid van asserties aan te pakken.

Betrouwbaarheid: Door te filteren op conformiteit en door het scheiden van geldige/ongeldige kandidaten, produceert de tool formalisaties die waarschijnlijker getrouw zijn aan de intentie van de ontwikkelaar.
Praktische toepasbaarheid: De aanpak vereist geen fine-tuning van modellen; het vertrouwt op prompting, testen en een beslissingsmatrix, waardoor het toepasbaar is op bestaande LLM's.
Beperkingen: De auteurs merken op dat de aanpak afhankelijk is van gelokaliseerde NL-asserties (module-niveau) en niet probeert om hoogwaardige applicatie-intenties te formaliseren of specs te extraheren uit ongestructureerde documentatie zonder een specifieke doelmethode. De actieve leercomponent vereist interactie met de gebruiker, hoewel het systeem dit minimaliseert door alleen te vragen wanneer dat noodzakelijk is.

Dit werk positioneert zich als een stap richting specificatie-gestuurde ontwikkeling met AI, waarbij menselijk leesbare specificaties worden opgesteld en vervolgens rigoureus worden getoetst aan de code middels autoformalizatie en testen.