Sintesi Tecnica: Calibrazione, non Compilazione

Definizione del Problema

I Large Language Models (LLM) sono sempre più utilizzati per redigere programmi probabilistici (ad esempio in Stan, Pyro, NumPyro). Sebbene tali programmi spesso compilino, eseguano e superino i test unitari convenzionali, possono rimanere statisticamente mal specificati. Gli errori comuni includono l'uso di una verosimiglianza gaussiana per dati con code pesanti, una distribuzione di Poisson per conteggi sovradispersi, supporti dei priori non validi o parametrizzazioni patologiche (ad esempio, la parametrizzazione centrata per i funnel gerarchici).

Il documento identifica una lacuna critica: la verifica del software standard (compilazione e test unitari) è cieca rispetto a questi errori statistici. Un programma che "esegue e restituisce campioni finiti" può comunque produrre una distribuzione a posteriori scarsamente calibrata e fallire nel corrispondere ai dati osservati. Gli autori definiscono questi errori come mal specicificazioni invisibili al codice. Il problema centrale è che lo standard "oracolo di test" (il codice viene eseguito?) non fornisce alcuna informazione sulla correttezza statistica, inducendo potenzialmente una falsa fiducia che sopprime le riparazioni necessarie.

Metodologia

L'Oracolo di Calibrazione

Gli autori propongono di sostituire l'oracolo dei test unitari con un Oracolo di Calibrazione derivato dal workflow bayesiano. Questo oracolo aggrega quattro famiglie di diagnostica per verificare se un modello adattato è statisticamente corretto:

1. Posterior Predictive Checks (PPC): Valuta se il modello può riprodurre le statistiche chiave dei dati (media, deviazione standard, massimo, conteggi degli zeri) tramite probabilità di coda.
2. Simulation-Based Calibration (SBC): Verifica se la procedura di inferenza è autoconsistente con il prior del modello esaminando la distribuzione dei ranghi dei disegni dal prior rispetto ai disegni dalla posterior.
3. Diagnostica del Campionatore: Monitora split-$\hat{R}$, dimensione del campione efficace (ESS) e transizioni divergenti per rilevare parametrizzazioni con geometrie della posterior irraggiungibili.
4. Densità Predittiva su Dati Non Utilizzati (Held-out): Utilizza la densità log-predittiva su dati tenuti fuori dal modello come una regola di punteggio strettamente propria per confrontare il modello con un riferimento.

L'oracolo restituisce un verdetto: il modello è accettato solo se supera tutte le soglie (ad esempio, $\hat{R} < 1.05$, basse divergenze, $p$-value PPC non vicini a 0 o 1 e alta densità sui dati tenuti fuori).

Configurazione Sperimentale

• Benchmark: Un dataset di 200 istanze attraverso 10 famiglie di modelli e 14 tipi di mal specificazione. Tutte le istanze compilano ed eseguono.
• Tassonomia dei Bug:
  • Visibili al codice: Errori rilevabili ispezionando il codice sorgente sotto un brief neutro (ad esempio, rumore minimo codificato).
  • Invisibili al codice: Errori in cui il codice è un'implementazione fedele del brief ma errata per i dati specifici (ad esempio, scelta errata della verosimiglianza). Questo è il focus principale poiché gli oracoli di test falliscono qui.
• Ciclo di Riparazione: Un processo iterativo in cui un LLM redige un programma, l'oracolo lo valuta e, se non calibrato, una diagnostica strutturata (ad esempio, "la dispersione dei dati si trova nella coda estrema") viene fornita all'LLM per la riparazione.
• Modelli: Valutati attraverso 15 scrittori (Open source: DeepSeek, Qwen, Llama, Phi; API: GPT, Claude, Gemini).

Contributi Chiave

1. Capacità di Rilevamento: L'oracolo di calibrazione rileva la mal specificazione con un AUC di 0,97. Sui bug invisibili al codice, segnala gli errori nel 93% dei casi con un tasso di falsi positivi del 2%, mentre un oracolo di test unitari rileva lo 0%.
2. Operatività Reference-Free: Il sistema non richiede un programma corretto scritto a mano. Una versione reference-free (PPC + sampler + SBC) rileva il 62% dei bug. Aggiungendo un baseline GLM classico, questa cifra sale al 68%, e una ricerca automatica del modello (LOO su una piccola libreria) raggiunge il 78%. La cifra dell'88% citata nell'abstract assume un riferimento corretto noto (un limite superiore).
3. Efficacia della Riparazione: L'uso del feedback di calibrazione supera significativamente sia l'assenza di feedback che il feedback dei test unitari.
   • Il feedback dei test unitari è dannoso: Dire a un LLM che "tutti i test passano" sopprime la riparazione, risultando spesso in tassi di correzione inferiori rispetto al fornire nessun feedback (ad esempio, Claude: 25% con feedback dei test vs 75% senza feedback).
   • Il feedback di calibrazione è efficace: Per modelli forti ma non ancora saturi, il feedback di calibrazione migliora drasticamente i tassi di correzione (ad esempio, GPT-5.1: 33% $\to$ 92%; Claude: 75% $\to$ 100%).
4. Validazione nel Mondo Reale: Su programmi scritti da zero partendo da brief neutri, il 15–47% dei programmi eseguibili è statisticamente mal specificato (i test unitari non ne colgono nessuno). La riparazione guidata dalla calibrazione supera significativamente i baseline, inclusi la revisione LLM-as-judge, le checklist bayesiane e il self-debug basato su riepilogo dati.

Risultati

• Rilevamento: L'oracolo è quasi perfetto per errori di verosimiglianza, problemi di dispersione e zero-inflazione. Fatica leggermente con la volatilità stocastica e specifici errori di link che preservano i momenti dei dati.
• Localizzazione: L'oracolo può localizzare il tipo di bug con una precisione top-2 del 75%, distinguendo tra verosimiglianze errate, cattive parametrizzazioni e sovradispersione, sebbene talvolta confonda la sovradispersione con il conflitto prior-dati.
• Capacità Non Monotona: Il beneficio del feedback di calibrazione è non monotono. È trascurabile per modelli troppo deboli per agire sulle diagnostiche e per modelli abbastanza forti da riparare alla cieca. È più decisivo per i modelli "forti ma non saturi".
• Significatività Statistica: I test di McNemar accoppiati confermano che il feedback di calibrazione è significativamente migliore di nessun feedback ($p=4.4 \times 10^{-3}$) e del feedback dei test unitari ($p=6.5 \times 10^{-7}$). Il feedback dei test unitari è significativamente peggiore rispetto a nessun feedback ($p=3.4 \times 10^{-3}$).

Significato e Rivendicazioni

Il documento sostiene che per i programmi probabilistici, la correttezza è calibrazione, non compilazione.

• Cambio di Paradigma: Il verificatore corretto per il codice probabilistico scritto da LLM è il workflow bayesiano stesso, non una suite di test.
• Danno Attivo dei Test: Il superamento dei test unitari può indurre erroneamente modelli capaci a credere che un modello mal specificato sia corretto, sopprimendo così il processo di riparazione.
• Impatto Pratico: L'oracolo di calibrazione fornisce una base rigorosa e "leggera" (senza necessità di riferimenti) per la modellazione affidabile assistita da LLM. Colma il divario tra generazione di codice e validità statistica, consentendo agli LLM capaci di correggere errori "invisibili al codice" che gli strumenti tradizionali di ingegneria del software non possono rilevare.

Gli autori notano i limiti: l'oracolo non è un certificato universale (non può rilevare errori strutturali causali se la distribuzione predittiva è identica e fatica con i costi SBC ad alta dimensionalità), ma è un verificatore robusto per i comuni errori statistici commessi dagli LLM.