🤖 AI

Automated Proof Generation for Rust Code via Self-Evolution

Dit artikel introduceert SAFE, een zelfevoluerend framework dat het gebrek aan menselijke bewijsdata overwint door synthetische bewijzen en zelfoplossend debuggen te combineren, waardoor open-source modellen in staat worden gesteld om met 52,52% nauwkeurigheid correcte formele bewijzen voor Rust-code te genereren, een aanzienlijke verbetering ten opzichte van GPT-4o.

Oorspronkelijke auteurs: Tianyu Chen, Shuai Lu, Shan Lu, Yeyun Gong, Chenyuan Yang, Xuheng Li, Md Rakib Hossain Misu, Hao Yu, Nan Duan, Peng Cheng, Fan Yang, Shuvendu K Lahiri, Tao Xie, Lidong Zhou

Gepubliceerd 2026-02-17

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Tianyu Chen, Shuai Lu, Shan Lu, Yeyun Gong, Chenyuan Yang, Xuheng Li, Md Rakib Hossain Misu, Hao Yu, Nan Duan, Peng Cheng, Fan Yang, Shuvendu K Lahiri, Tao Xie, Lidong Zhou

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 strenge, onfeilbare inspecteur hebt die elke regel code controleert die je schrijft. Deze inspecteur, genaamd Verus, is een magische bril die kan zien of je software echt veilig is, zelfs als je hem nooit uitvoert. Hij is onmisbaar voor het bouwen van betrouwbare systemen, maar hij heeft een groot probleem: hij praat een heel moeilijke taal.

Om Verus tevreden te stellen, moet je niet alleen je code schrijven, maar ook een bewijs (een "proof") leveren. Dit bewijs is een soort gedetailleerd stappenplan dat uitlegt waarom je code werkt. Het is als het schrijven van een wiskundig betoog voor elke functie die je programmeert.

Het probleem? Er zijn heel weinig mensen die deze bewijzen kunnen schrijven. Het is als proberen een orkest te leiden terwijl je alleen maar één vioolspeler hebt. Voor kunstmatige intelligentie (AI) is dit ook een probleem: er is geen "schoolboek" vol voorbeelden van deze bewijzen om de AI op te leren.

Hier komt het nieuwe systeem SAFE in beeld. Het is een slimme, zelflerende machine die dit probleem oplost. Hier is hoe het werkt, vertaald naar alledaagse beelden:

1. Het Gebrek aan Leerboeken (Het Data-probleem)

Normaal gesproken leer je een AI door hem duizenden voorbeelden te geven. Maar voor Verus-bewijzen bestaan die voorbeelden bijna niet. De auteurs van dit paper dachten: "Als we geen boeken hebben, laten we ze dan zelf schrijven!"

2. De "Zelf-evoluerende" Cyclus (De Magie van SAFE)

SAFE werkt als een slimme leermeester met een oneindige voorraad proefwerk. Het proces heeft drie hoofdstappen:

Stap 1: De Vertaler
SAFE neemt duizenden simpele programmeeropgaven (zoals "schrijf een functie die een lijst sorteert") en vraagt een super-AI (GPT-4o) om ze te vertalen naar de taal die Verus begrijpt. Het is alsof je een boek uit het Frans naar het Nederlands vertaalt, zodat de strenge inspecteur het kan lezen.
Stap 2: Het Schrijven van Specifaties (De Regels)
Nu heeft de AI de code, maar Verus wil ook weten wat de code moet doen (de regels). SAFE laat de AI deze regels bedenken.
- De slimme truc: De AI schrijft eerst een heleboel regels. Verus kijkt er dan naar en zegt: "Deze regels zijn te vaag" of "Deze regels kloppen niet". SAFE gooit de slechte regels weg en houdt alleen de goede.
- Analogie: Stel je voor dat je een chef-kok bent. Je laat 100 koks recepten schrijven. De inspecteur (Verus) proeft ze. De recepten die te zout of te zoet zijn, worden weggegooid. De goede recepten worden gebruikt om de volgende koks (de AI) te trainen.
Stap 3: Het Bewijzen (De Daadwerkelijke Taak)
Nu heeft SAFE duizenden stukjes code met goede regels. De AI probeert nu het bewijs te schrijven.
- Het probleem: De AI maakt veel fouten.
- De oplossing (Zelf-Debugging): Dit is het coolste deel. Als de AI een fout maakt, geeft Verus een foutmelding (bijvoorbeeld: "Je vergat te zeggen dat de lijst niet leeg is"). SAFE pakt deze foutmelding, de verkeerde poging en het juiste antwoord, en gebruikt dit als leermateriaal.
- Analogie: Het is alsof een leerling een wiskundetoets maakt, een fout maakt, en de docent (Verus) zegt: "Je hebt hier een minteken vergeten." De leerling kijkt naar die fout, leert ervan, en probeert het opnieuw. SAFE doet dit duizenden keren. De AI wordt steeds beter in het herkennen en repareren van zijn eigen fouten.

3. Het Resultaat: Van Nul naar Helden

Aan het begin wist de open-source AI (DeepSeekCoder) niets van Verus. Het was alsof je iemand vraagt om een Formule 1-auto te bouwen zonder ooit een wiel te hebben gezien.

Na dit proces van "zelf-evolutie" (duizenden pogingen, fouten maken, leren van fouten, en opnieuw proberen):

De AI kon plotseling 52,52% van de moeilijke bewijzen correct schrijven.
De beste bestaande AI (GPT-4o), die zonder deze speciale training werkt, haalde slechts 14,39%.

Waarom is dit belangrijk?

Vroeger was het schrijven van veiligheidsbewijzen voor software een taak voor een handvol experts die jarenlang hadden gestudeerd. Met SAFE kunnen we nu een AI trainen die dit voor ons doet. Het is alsof we een machine hebben gebouwd die zichzelf kan leren hoe het veilig bouwen van software werkt, zonder dat we duizenden menselijke experts nodig hebben om het haar te leren.

Kort samengevat:
SAFE is een robot die eerst duizenden oefeningen maakt, daarna kijkt naar welke oefeningen goed zijn, en vervolgens duizenden keren probeert, faalt, en leert van zijn fouten totdat hij een meester is in het schrijven van onfeilbare software-bewijzen. Het is een cyclus van "proberen, falen, leren, en groeien" die de AI sterker maakt dan welke menselijke expert dan ook in dit specifieke vakgebied.

Titel: Automatische Bewijsgeneratie voor Rust-code via Zelf-ontwikkeling (SAFE)

Publicatie: ICLR 2025
Auteurs: Tianyu Chen et al. (Peking University, Microsoft Research, etc.)

1. Het Probleem

Hoewel Large Language Models (LLMs) indrukwekkende prestaties leveren in het genereren van code, is de correctheid van gegenereerde code niet gegarandeerd. Formele verificatie biedt een definitieve garantie voor correctheid, maar vereist aanzienlijke menselijke inspanning om formele specificaties en bewijzen te construeren.

De grootste hindernis voor het automatiseren van dit proces is het severe gebrek aan data:

Er zijn veel minder formele bewijzen dan codefragmenten beschikbaar om LLM's op te trainen.
Voor specifieke verificatietools zoals Verus (voor Rust-code) zijn er op GitHub minder dan 500 geverifieerde bestanden. Dit is te weinig voor het fine-tunen van modellen.
Bestaande methoden vertrouwen vaak op prompt engineering (wat beperkte generalisatie heeft) of fine-tuning op bestaande datasets (wat niet mogelijk is bij gebrek aan data).

2. Methodologie: Het SAFE Framework

Het paper introduceert SAFE (Self-evolving Automated prooF gEneration), een framework dat het data-tekort overwint door een zelf-ontwikkelende cyclus (self-evolving cycle) te creëren. In deze cyclus werken data-synthese en model-fine-tuning samen, waarbij een symbolische verifier (Verus) fungeert als de "leraar" die correcte van incorrecte bewijzen onderscheidt.

Het proces verloopt in drie hoofdstappen:

Stap 1: Genereren van Verus-compatibele Code

Omdat Verus niet alle Rust-functies ondersteunt (bijv. bepaalde iterators of HashMaps), gebruikt SAFE GPT-4o om bestaande Python- en Rust-programma's (uit datasets zoals MBPP en CodeNet) te "vertalen" naar Verus-compatibele Rust-code. Alleen code die compileert met de Verus-compiler wordt behouden.

Stap 2: Zelf-ontwikkelende Specificatie-synthese

Om bewijzen te genereren, heeft Verus formele specificaties (pre- en post-condities) nodig.

Bootstrapping: GPT-4o genereert initiële specificaties op basis van de code en docstrings.
Iteratie: Een open-source LLM wordt gefine-tuned op deze specificaties om in de volgende ronde betere specificaties te genereren.
Kwaliteitsfiltering: Omdat perfecte specificaties niet nodig zijn voor de volgende stap, maar wel correcte en redelijk complete, worden specificaties gefilterd op basis van twee metrics (gebaseerd op testcases):
- Correctness: Welk percentage van de geldige testcases voldoet aan de specificatie? (Doel: ≥80%)
- Completeness: Welk percentage van de gemuteerde (ongeldige) testcases wordt afgewezen? (Doel: ≥60%)
Slechte specificaties worden verworpen; goede worden gebruikt voor de volgende ronde.

Stap 3: Zelf-ontwikkelende Bewijs-synthese en Self-Debugging

Dit is de kern van het framework.

Bewijsgeneratie: Het model probeert bewijzen te genereren die Verus accepteert. Verus fungeert als de absolute waarheid: als het bewijs faalt, wordt het verworpen.
Self-Debugging (Cruciaal): Het framework maakt gebruik van de enorme hoeveelheid incorrecte bewijzen die in eerdere rondes zijn gegenereerd. Voor elk programma waarbij uiteindelijk een correct bewijs ( $P_{\checkmark}$ ) wordt gevonden, worden eerdere foutieve pogingen ( $P_X$ ) en de bijbehorende Verus-foutmeldingen ( $Error_{P_X}$ ) gebruikt als trainingsdata.
Het model leert hierdoor niet alleen bewijzen te genereren, maar ook bestaande bewijzen te repareren op basis van foutmeldingen. Dit verhoogt de efficiëntie aanzienlijk.

3. Belangrijkste Bijdragen

Overcoming Data Scarcity: SAFE lost het gebrek aan menselijke bewijzen op door een volledig geautomatiseerde, zelf-ontwikkelende cyclus te creëren die duizenden synthetische bewijzen genereert zonder menselijke tussenkomst.
Self-Debugging Mechanisme: Het introduceert een unieke aanpak waarbij foutieve bewijzen en de bijbehorende compiler-foutmeldingen worden omgezet in trainingsdata, waardoor modellen leren hun eigen fouten te corrigeren.
Kwaliteitscontrole via Symbolische Verificatie: Het framework gebruikt de Verus-compiler en een kwantitatieve methode voor specificaties om data-kwaliteit te garanderen zonder menselijke labels.
Open Data: Het paper publiceert een groot synthetisch dataset (19.017 specificaties en 9.706 geverifieerde functies) op HuggingFace.

4. Resultaten

De evaluatie is uitgevoerd op twee benchmarks: VerusBench (menselijk samengesteld) en CodeNet-Test (synthetisch, groter).

Prestatieverbetering:
- Op VerusBench bereikt het SAFE-model (gebaseerd op DeepSeekCoder) een nauwkeurigheid van 52,52% (bij Accuracy@2 met self-debugging).
- Dit is een enorme sprong vergeleken met GPT-4o, dat slechts 14,39% haalt.
- Zelfs zonder self-debugging (directe generatie) presteert SAFE (43,17%) veel beter dan GPT-4o (11,51%).
Efficiëntie: De fine-tuned modellen genereren bewijzen aanzienlijk sneller dan GPT-4o.
Impact van Self-Debugging: Het gebruik van de self-debugging functie (SAFE+) verbetert de nauwkeurigheid aanzienlijk. Bijvoorbeeld, op VerusBench stijgt de score van 43,17% naar 52,52% wanneer self-debugging wordt toegepast.
Kwaliteit van Data: Experimenten tonen aan dat het filteren van specificaties op kwaliteit essentieel is. Modellen getraind op "slechte" specificaties presteren drastisch slechter (soms 0% nauwkeurigheid).

5. Betekenis en Conclusie

SAFE vertegenwoordigt een doorbraak in het veld van geautomatiseerde formele verificatie voor programmeertalen. Het bewijst dat het mogelijk is om open-source modellen, die oorspronkelijk geen kennis hebben van formele verificatie, te trainen om complexe bewijzen te genereren voor Rust-code, zelfs wanneer er geen bestaande menselijke datasets zijn.

De belangrijkste inzichten zijn:

Zelf-ontwikkeling werkt: Een cyclus van synthese, filtering en fine-tuning kan de capaciteiten van LLM's exponentieel verbeteren in domeinen met data-schaarste.
Fouten zijn waardevol: Het gebruik van foutieve pogingen en foutmeldingen voor training (self-debugging) is net zo belangrijk als het genereren van correcte antwoorden.
Toekomstperspectief: Hoewel het zich nu richt op kleine Rust-functies, biedt SAFE een blauwdruk voor het schalen van formele verificatie naar grotere, real-world softwareprojecten, wat cruciaal is voor het bouwen van veiliger en betrouwbaarder software.