🤖 machine learning

Calibration, Not Compilation: Detecting and Repairing Misspecified Probabilistic Programs Written by Language Models

Dit artikel betoogt dat voor probabilistische programma's gegenereerd door taalmodellen, statistische correctheid wordt gedefinieerd door kalibratie in plaats van compilatie, waarbij wordt aangetoond dat detectie en reparatie op basis van een Bayesian workflow aanzienlijk beter presteren dan traditionele unit testing en zelfreviewmethoden bij het identificeren en herstellen van statistische mis-specificaties.

Oorspronkelijke auteurs: Jian Xu, Delu Zeng, John Paisley, Qibin Zhao

Gepubliceerd 2026-07-01

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Jian Xu, Delu Zeng, John Paisley, Qibin Zhao

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 kernprobleid: "Draaien" betekent niet "Goed"

Stel je voor dat je een zeer slimme robot vraagt om een recept voor een cake te schrijven. De robot geeft je een lijst met ingrediënten en stappen. Je volgt de instructies, de oven werkt, de cake komt uit de oven en het ziet eruit als een cake.

In de wereld van computercode wordt dit "compileren en draaien" genoemd. Als de code draait zonder vast te lopen, zeggen traditionele softwaretesters: "Geweldig! Het programma werkt."

Maar in de wereld van probabilistische programma's (code die wordt gebruikt voor statistiek en data science), is dit gevaarlijk. Een programma kan perfect draaien en een cake produceren, maar als het recept "zout" in plaats van "suiker" opgaf, zal de cake verschrikkelijk smaken. De code liep niet vast, maar het resultaat is statistisch gezien fout.

De auteurs noemen dit "code-onzichtbare bugs." Dit zijn fouten die een computer niet kan zien door alleen naar de code te kijken of deze uit te voeren. Ze komen pas aan het licht wanneer je naar de data kijkt die het programma produceert.

De oude manier versus de nieuwe manier

De oude manier (De Unit Test):
Traditioneel gebruiken we "unit tests" om te controleren of code goed is. Dit is alsof je controleert of de cake de juiste vorm en het juiste gewicht heeft.

Draait het programma? Ja.
Geeft het getallen uit? Ja.
Resultaat: "Geslaagd!"

Het artikel laat zien dat dit voor statistische programma's nutteloos is. Een programma dat de verkeerde wiskunde gebruikt (zoals een rechte lijn om een curve te beschrijven), zal deze tests nog steeds halen. Het is alsof je zegt dat een cake perfect is omdat hij in de vorm past, zelfs als hij naar zeep smaakt.

De nieuwe manier (De Calibration Oracle):
De auteurs stellen een nieuwe verifieerder voor genaamd de Calibration Oracle. In plaats van alleen te controleren of de code draait, controleert het of het verhaal dat de code vertelt, overeenkomt met de werkelijkheid.

Denk hierbij aan een smaaktest of een controle van de weersverwachting:

Posterior Predictive Checks: Het programma voorspelt hoe de data er zou moeten uitzien. De Oracle vergelijkt deze voorspelling met de werkelijke data. Als de echte data enorme pieken heeft en het programma een vlakke lijn voorspelt, zegt de Oracle: "Je hebt de plank gemist."
Sampler Diagnostics: Het controleert of het programma moeite heeft om het antwoord te vinden (zoals een wandelaar die verdwaald is in een mistige berg). Als het programma in de war is, geeft het een foutmelding.
Held-out Density: Het test het programma op data die het nog niet eerder heeft gezien. Als het programma nieuwe data niet nauwkeurig kan voorspellen, is het fout gespecificeerd.

Het experiment: De robot leren om zichzelf te verbeteren

De onderzoekers hebben dit idee op drie manieren getest:

1. Detectie (De bug vinden)
Ze creëerden 200 fictieve scenario's waarin robots statistische programma's schreven met verborgen fouten (zoals het gebruik van de verkeerde wiskunde voor de data).

Het resultaat: De oude "Unit Test" vond 0% van de bugs. De nieuwe "Calibration Oracle" vond 88% van de bugs. Het was alsocht het hebben van een meesterkok die de zoutfout kon proeven, terwijl de oude methode alleen de panmaat controleerde.

2. Reparatie (De bug herstellen)
Ze lieten Large Language Models (LLM's) proberen hun eigen kapotte programma's te repareren. Ze gaven de robots drie soorten feedback:

Geen feedback: "Probeer het opnieuw."
Unit Test Feedback: "Je code is door alle tests heen gekomen. Het is prima." (Dit maakte de situatie eigenlijk slechter, omdat de robot dacht dat hij al perfect was en stopte met het proberen te oplossen van de verborgen fouten).
Calibration Feedback: "Je code draait, maar je voorspellingen komen niet overeen met de data. De spreiding is te smal."
Het resultaat: De robots die Calibration Feedback gebruikten, herstelden hun fouten veel beter. Voor sommige geavanceerde modellen steeg het succespercentage van 33% naar 92%. De "Unit Test" feedback was schadelijk; het werkte als een vals zelfvertrouwen dat de robot ervan weerhield het echte probleem op te lossen.

3. Real-World Test
Ze vroegen robots om vanuit het niets programma's te schrijven op basis van eenvoudige beschrijvingen (zonder hints).

Het resultaat: Hoewel 80-90% van de programma's gewoon "draaide", waren 15% tot 47% statistisch gezien fout. De unit tests merkten geen enkele fout op. De Calibration Oracle vond de fouten en hielp de robots ze te herstellen, waarmee ze zelfs andere geavanceerde AI-reviewers versloegen.

Belangrijkste inzichten

Correctheid is Calibratie, niet Compilatie: Alleen omdat een statistisch programma zonder problemen draait, betekent niet dat het klopt. Het is pas goed als de voorspellingen "gekalibreerd" zijn aan de echte wereld.
Tests kunnen verraderlijk zijn: Een slimme robot vertellen dat "alle tests zijn geslaagd" kan hem er juist toe brengen te stoppen met het oplossen van diepe, verborgen fouten. Het creëert een vals gevoel van veiligheid.
Het ideale punt: Deze nieuwe methode werkt het beste voor robots die al vrij slim zijn, maar nog niet perfect. Het geeft hen de specifieke "smaaktest"-feedback die ze nodig hebben om te verbeteren.

Kortom: Als je wilt dat een robot een statistisch model schrijft, vraag dan niet alleen of de code "draait". Vraag of de robot "de cake kan proeven" en of deze overeenkomt met het recept. Het artikel bewijst dat deze "smaaktest" (Calibratie) de enige manier is om de onzichtbare fouten te vangen en te herstellen die standaard codetests missen.

Technische Samenvatting: Kalibratie, niet Compilatie

Probleemstelling

Large Language Models (LLM's) worden steeds vaker gebruikt om probabilistische programma's te schrijven (bijv. in Stan, Pyro, NumPyro). Hoewel deze programma's vaak compileren, draaien en conventionele unit tests passeren, kunnen ze nog steeds statistisch mis gespecificeerd zijn. Veelvoorkomende fouten zijn het gebruik van een Gaussische likelihood voor heavy-tailed data, een Poisson-distributie voor overgedispergeerde counts, ongeldige prior supports, of pathologische parametrisaties (bijv. gecentreerde parametrisatie voor hiërarchische funnels).

Het onderzoek identificeert een kritieke kloof: standaard softwareverificatie (compilatie en unit tests) is blind voor deze statistische fouten. Een programma dat "draait en eindige samples teruggeeft" kan nog steeds een posterior produceren die slecht gekalibreerd is en niet overeenkomt met de gehouden data. De auteurs noemen dit code-onzichtbare misspecificaties. Het centrale probleem is dat de standaard "test oracle" (draait de code?) nul informatie biedt over statistische correctheid, wat potentieel een vals gevoel van vertrouwen opwekt dat noodzakelijke reparaties onderdrukt.

Methodologie

De Kalibratie Oracle

De auteurs stellen voor om de unit-test oracle te vervangen door een Kalibratie Oracle afgeleid van de Bayesiaanse workflow. Deze oracle aggregeert vier families van diagnostiek om te verifiëren of een gefit model statistisch correct is:

Posterior Predictive Checks (PPC): Evalueert of het model in staat is om sleutelstatistieken van de data (gemiddelde, SD, max, zero-counts) te reproduceren via staartkansen.
Simulation-Based Calibration (SBC): Controleert of de inferentieprocedure zelfconsistent is met de prior van het model door de rangverdeling van prior-trekken tegenover posterior-trekken te onderzoeken.
Sampler Diagnostics: Monitort split- $\hat{R}$ , effectieve steekproefomvang (ESS) en divergentie-transities om parametrisaties met onbereikbare posterior-geometrie te detecteren.
Held-out Predictive Density: Gebruikt de log-predictieve dichtheid op gehouden data als een strikt passende scoring rule om het model te vergelijken met een referentie.

De oracle geeft een oordeel: het model wordt alleen geaccepteerd als het aan alle drempelwaarden voldoet (bijv. $\hat{R} < 1.05$ , lage divergenties, PPC $p$ -waarden niet nabij 0 of 1, en hoge held-out dichtheid).

Experimentele Opzet

Benchmark: Een dataset van 200 instanties over 10 modelfamilies en 14 typen misspecificatie. Alle instanties compileren en draaien.
Bug Taxonomie:
- Code-zichtbaar: Fouten die detecteerbaar zijn door de broncode te inspecteren onder een neutrale korte instructie (bijv. hard-coded minimale ruis).
- Code-onzichtbaar: Fouten waarbij de code een getrouwe implementatie is van de instructie maar foutief is voor de specifieke data (bijv. verkeerde keuze van de likelihood). Dit is de primaire focus, aangezien test oracles hier falen.
Repair Loop: Een iteratief proces waarbij een LLM een programma ontwerpt, de oracle het evalueert, en indien niet gekalibreerd, een gestructureerde diagnostiek (bijv. "de spreiding van de data ligt in de extreme staart") wordt teruggekoppeld naar de LLM voor reparatie.
Modellen: Geëvalueerd over 15 schrijvers (Open source: DeepSeek, Qwen, Llama, Phi; API: GPT, Claude, Gemini).

Belangrijkste Bijdragen

Detectievermogen: De kalibratie oracle detecteert misspecificatie met een AUC van 0.97. Bij code-onzichtbare bugs signaleert het fouten in 93% van de gevallen bij een 2% fout-positief ratio, terwijl een unit-test oracle 0% van de fouten detecteert.
Referentievrije Werking: Het systeem vereist geen handgeschreven correct programma. Een referentievrije versie (PPC + sampler + SBC) detecteert 62% van de bugs. Het toevoegen van een klassieke GLM-baseline verhoogt dit naar 68%, en een geautomatiseerde modelzoektocht (LOO over een kleine bibliotheek) bereikt 78%. De genoemde 88% in de abstract gaat uit van een bekende correcte referentie (een bovengrens).
Reparatie-effectiviteit: Het gebruik van kalibratie-feedback presteert aanzienlijk beter dan zowel "geen feedback" als "unit-test feedback".
- Unit-test feedback is schadelijk: Het vertellen van een LLM dat "alle tests passeren" onderdrukt reparatie, wat vaak resulteert in lagere fix-rates dan het geven van helemaal geen feedback (bijv. Claude: 25% met test feedback versus 75% met geen feedback).
- Kalibratie feedback is effectief: Voor sterke maar nog niet verzadigde modellen verbetert kalibratie-feedback de fix-rates drastisch (bijv. GPT-5.1: 33% $\to$ 92%; Claude: 75% $\to$ 100%).
Real-world Validatie: Op programma's die vanaf nul zijn geschreven op basis van neutrale instructies, is 15–47% van de uitvoerbare programma's statistisch mis gespecificeerd (unit tests vangen niets op). Kalibratie-gestuurde reparatie presteert significant beter dan baselines inclusief LLM-as-judge review, Bayesiaanse checklists en data-summary self-debug.

Resultaten

Detectie: De oracle is bijna perfect voor likelihood-fouten, dispersieproblemen en zero-inflatie. Het heeft lichte moeite met stochastische volatiliteit en specifieke link-fouten die de data-momenten behouden.
Lokalisatie: De oracle kan het type bug lokaliseren met een 75% top-2 nauwkeurigheid, waarbij het onderscheid maakt tussen verkeerde likelihoods, slechte parametrisaties en overgedispergie, hoewel het soms overgedispergie verwart met prior-data conflict.
Niet-monotone Capaciteit: Het voordeel van kalibratie-feedback is niet-monotoon. Het is verwaarloosbaar voor modellen die te zwak zijn om op diagnostiek te reageren en voor modellen die sterk genoeg zijn om blind te repareren. Het is het meest beslissend voor "sterke-maar-niet-verzadigde" modellen.
Statistische Significantie: Gepaarde McNemar-tests bevestigen dat kalibratie-feedback significant beter is dan geen feedback ( $p=4.4 \times 10^{-3}$ ) en unit-test feedback ( $p=6.5 \times 10^{-7}$ ). Unit-test feedback is significant slechter dan geen feedback ( $p=3.4 \times 10^{-3}$ ).

Betekenis en Claims

Het artikel betoogt dat voor probabilistische programma's correctheid kalibratie is, niet compilatie.

Paradigmaverschuiving: De juiste verifieerder voor door LLM's geschreven probabilistische code is de Bayesiaanse workflow zelf, niet een test suite.
Actieve Schade van Tests: Het passeren van unit tests kan capabele modellen actief misleiden door hen te doen geloven dat een mis gespecificeerd model correct is, waardoor het reparatieproces wordt onderdrukt.
Praktische Impact: De kalibratie oracle biedt een principieel, referentie-licht fundament voor betrouwbaar LLM-ondersteunde probabilistische modellering. Het overbrugt de kloof tussen codegeneratie en statistische validiteit, waardoor capabele LLM's "code-onzichtbare" fouten kunnen herstellen die traditionele software engineering tools niet kunnen detecteren.

De auteurs merken de beperkingen op: de oracle is geen universeel certificaat (het kan geen causale structurele fouten detecteren als de predictieve distributie identiek is, en het heeft moeite met hoog-dimensionale SBC-kosten), maar het is een robuuste verifieerder voor de veelvoorkomende statistische fouten die LLM's maken.