🤖 machine learning

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

Cet article soutient que pour les programmes probabilistes générés par des modèles de langage, la correction statistique est définie par le calibrage plutôt que par la compilation, démontrant que la détection et la réparation basées sur un flux de travail bayésien surpassent de manière significative les méthodes traditionnelles de tests unitaires et d'auto-examen pour identifier et corriger les erreurs de spécification statistique.

Auteurs originaux : Jian Xu, Delu Zeng, John Paisley, Qibin Zhao

Publié 2026-07-01

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Jian Xu, Delu Zeng, John Paisley, Qibin Zhao

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Le problème central : « Exécuter » ne signifie pas « Être juste »

Imaginez que vous demandiez à un robot très intelligent d'écrire une recette de gâteau. Le robot vous donne une liste d'ingrédients et d'étapes. Vous suivez les instructions, le four fonctionne, le gâteau sort du four, et il ressemble bien à un gâteau.

Dans le monde du code informatique, cela s'appelle « compiler et exécuter ». Si le code s'exécute sans planter, les testeurs de logiciels traditionnels disent : « Super ! Le programme fonctionne. »

Mais dans le monde des programmes probabilistes (le code utilisé pour les statistiques et la science des données), c'est dangereux. Un programme peut s'exécuter parfaitement et produire un gâteau, mais si la recette demandait du « sel » au lieu du « sucre », le gâteau aura un goût terrible. Le code n'a pas planté, mais le résultat est statistiquement faux.

Les auteurs appellent cela des « bugs invisibles au code ». Ce sont des erreurs que l'ordinateur ne peut pas voir simplement en regardant le code ou en l'exécutant. Elles ne se manifestent que lorsque vous regardez les données produites par le programme.

L'ancienne méthode vs La nouvelle méthode

L'ancienne méthode (Le test unitaire) :
Traditionnellement, pour vérifier si un code est bon, nous utilisons des « tests unitaires ». C'est comme vérifier si le gâteau a la bonne forme et le bon poids.

Le programme s'exécute-t-il ? Oui.
Produit-il des chiffres ? Oui.
Résultat : « Réussite ! »

Le papier montre que pour les programmes statistiques, cela est inutile. Un programme utilisant une mauvaise mathématique (comme utiliser une ligne droite pour décrire une courbe) réussira quand même ces tests. C'est comme dire qu'un gâteau est parfait parce qu'il rentre dans le moule, même s'il a un goût de savon.

La nouvelle méthode (L'Oracle de Calibration) :
Les auteurs proposent un nouveau vérificateur appelé l'Oracle de Calibration. Au lieu de simplement vérifier si le code s'exécute, il vérifie si l'histoire racontée par le code correspond à la réalité.

Voyez cela comme un test de goût ou une vérification de prévisions météorologiques :

Vérifications prédictives a posteriori (Posterior Predictive Checks) : Le programme prédit à quoi les données devraient ressembler. L'Oracle compare cette prédiction aux données réelles. Si les données réelles présentent de grands pics et que le programme prédit une ligne plate, l'Oracle dit : « Vous avez raté votre cible. »
Diagnostics de l'échantillonneur (Sampler Diagnostics) : Il vérifie si le programme a du mal à trouver la réponse (comme un randonneur qui se perd dans une montagne embrumée). Si le programme est confus, il signale une erreur.
Densité hors échantillon (Held-out Density) : Il teste le programme sur des données qu'il n'a pas encore vues. Si le programme ne parvient pas à prédire avec précision de nouvelles données, c'est qu'il est mal spécifié.

L'expérience : Apprendre au robot à se corriger lui-même

Les chercheurs ont testé cette idée de trois manières principales :

1. Détection (Trouver le bug)
Ils ont créé 200 scénarios fictifs où des robots écrivaient des programmes statistiques avec des erreurs cachées (comme utiliser le mauvais type de mathématiques pour les données).

Le résultat : L'ancien « Test Unitaire » a trouvé 0 % des bugs. Le nouvel « Oracle de Calibration » en a trouvé 88 %. C'était comme avoir un chef étoilé capable de détecter l'erreur de sel, tandis que l'ancienne méthode ne vérifiait que la taille du moule.

2. Réparation (Corriger le bug)
Ils ont laissé des modèles de langage étendus (LLM) essayer de réparer leurs propres programmes défectueux. Ils ont donné aux robots trois types de retours (feedback) :

Aucun feedback : « Réessaie. »
Feedback de Test Unitaire : « Votre code a passé tous les tests. C'est bon. » (Cela a en fait aggravé les choses car le robot pensait qu'il était déjà parfait et a cessé de tenter de corriger les erreurs cachées).
Feedback de Calibration : « Votre code s'exécute, mais vos prédictions ne correspondent pas aux données. L'écart est trop étroit. »
Le résultat : Les robots utilisant le Feedback de Calibration ont bien mieux corrigé leurs erreurs. Pour certains modèles avancés, le taux de réussite est passé de 33 % à 92 %. Le feedback du « Test Unitaire » était nuisible, agissant comme un faux boost de confiance qui empêchait le robot de résoudre le vrai problème.

3. Test en conditions réelles
Ils ont demandé à des robots d'écrire des programmes de zéro à partir de descriptions simples (sans indices).

Le résultat : Bien que 80 à 90 % des programmes « s'exécutaient », 15 % à 47 % étaient statistiquement faux. Les tests unitaires n'en ont détecté aucun. L'Oracle de Calibration a trouvé les erreurs et a aidé les robots à les corriger, battant même d'autres examinateurs IA avancés.

Points clés à retenir

La justesse est une question de calibration, pas de compilation : Le simple fait qu'un programme statistique s'exécute sans planter ne signifie pas qu'il est correct. Il n'est correct que si ses prédictions sont « calibrées » sur le monde réel.
Les tests peuvent être trompeurs : Dire à un robot intelligent « tous les tests ont réussi » peut en réalité l'empêcher de corriger des erreurs profondes et cachées. Cela crée un faux sentiment de sécurité.
Le point idéal : Cette nouvelle méthode fonctionne mieux pour les robots qui sont déjà assez intelligents mais pas encore parfaits. Elle leur donne le feedback de « test de goût » spécifique dont ils ont besoin pour s'améliorer.

En bref : Si vous voulez qu'un robot écrive un modèle statistique, ne lui demandez pas seulement d'« exécuter le code ». Demandez-lui de « goûter le gâteau » et de s'assurer qu'il correspond à la recette. Le papier prouve que ce « test de goût » (la Calibration) est le seul moyen de détecter et de corriger les erreurs invisibles que les tests de code standards ne voient pas.

Résumé technique : La calibration, pas la compilation

Énoncé du problème

Les grands modèles de langage (LLM) sont de plus en plus utilisés pour rédiger des programmes probabilistes (par exemple, en Stan, Pyro, NumPyro). Bien que ces programmes compilent, s'exécutent et passent les tests unitaires conventionnels, ils peuvent rester statistiquement mal spécifiés. Les erreurs courantes incluent l'utilisation d'une vraisemblance gaussienne pour des données à queues épaisses, d'une distribution de Poisson pour des comptages sur-dispersés, de supports de priors invalides, ou de paramétrages pathologiques (par exemple, un paramétrage centré pour des entonnoirs hiérarchiques).

L'article identifie une lacune critique : la vérification logicielle standard (compilation et tests unitaires) est aveugle à ces erreurs statistiques. Un programme qui « s'exécute et renvoie des échantillons finis » peut néanmoins produire une distribution a posteriori mal calibrée et ne pas correspondre aux données de validation. Les auteurs appellent cela des erreurs de spécification invisibles au code. Le problème central est que l'« oracle de test » standard (le code s'exécute-t-il ?) ne fournit aucune information sur la justesse statistique, ce qui peut induire une fausse confiance et supprimer la nécessité de corrections.

Méthodologie

L'Oracle de Calibration

Les auteurs proposent de remplacer l'oracle de test unitaire par un Oracle de Calibration dérivé du flux de travail bayésien. Cet oracle agrège quatre familles de diagnostics pour vérifier si un modèle ajusté est statistiquement correct :

Vérifications prédictives a posteriori (PPC) : Évalue si le modèle peut reproduire les statistiques clés des données (moyenne, écart-type, maximum, comptes de zéros) via les probabilités de queue.
Calibration basée sur la simulation (SBC) : Vérifie si la procédure d'inférence est auto-cohérente avec le prior du modèle en examinant la distribution des rangs des tirages du prior par rapport aux tirages de l'a posteriori.
Diagnostics de l'échantillonneur : Surveille le $\hat{R}$ divisé, l'effective sample size (ESS) et les divergences pour détecter des paramétrages avec une géométrie a posteriori inaccessible.
Densité prédictive sur données de réserve : Utilise la densité de log-vraisemblance sur des données de réserve comme une règle de score strictement propre pour comparer le modèle à une référence.

L'oracle renvoie un verdict : le modèle n'est accepté que s'il passe tous les seuils (par exemple, $\hat{R} < 1,05$ , faibles divergences, $p$ -values de PPC proches de 0 ou 1, et haute densité sur les données de réserve).

Configuration Expérimentale

Benchmark : Un ensemble de données de 200 instances réparties sur 10 familles de modèles et 14 types de spécifications erronées. Toutes les instances compilent et s'exécutent.
Taxonomie des bugs :
- Visibles au code : Erreurs détectables par l'inspection du code source sous un brief neutre (ex: bruit minuscule codé en dur).
- Invisibles au code : Erreurs où le code est une implémentation fidèle du brief mais incorrecte pour les données spécifiques (ex: mauvais choix de vraisemblance). C'est l'objectif principal car les oracles de test échouent ici.
Boucle de réparation : Un processus itératif où un LLM rédige un programme, l'oracle l'évalue, et si le modèle est mal calibré, un diagnostic structuré (ex: « l'étalement des données se situe dans la queue extrême ») est renvoyé au LLM pour réparation.
Modèles : Évalués à travers 15 rédacteurs (Open source : DeepSeek, Qwen, Llama, Phi ; API : GPT, Claude, Gemini).

Principales Contributions

Capacité de détection : L'oracle de calibration détecte la spécification erronée avec un AUC de 0,97. Sur les bugs invisibles au code, il signale les erreurs dans 93 % des cas avec un taux de faux positifs de 2 %, alors qu'un oracle de test unitaire détecte 0 %.
Fonctionnement sans référence : Le système ne nécessite pas de programme correct écrit à la main. Une version sans référence (PPC + échantillonneur + SBC) détecte 62 % des bugs. L'ajout d'une ligne de base GLM classique porte ce chiffre à 68 %, et une recherche de modèle automatisée (LOO sur une petite bibliothèque) atteint 78 %. Le chiffre de 88 % cité dans l'abstract suppose une référence correcte connue (une limite supérieure).
Efficacité de la réparation : L'utilisation de feedbacks de calibration surpasse nettement les options « sans feedback » et « feedback de test unitaire ».
- Le feedback de test unitaire est nuisible : Dire à un LLM que « tous les tests passent » supprime la réparation, entraînant souvent des taux de correction inférieurs à ceux d'un feedback nul (ex: Claude : 25 % avec feedback de test contre 75 % sans feedback).
- Le feedback de calibration est efficace : Pour les modèles forts mais non saturés, le feedback de calibration améliore considérablement les taux de réparation (ex: GPT-5.1 : 33 % $\to$ 92 % ; Claude : 75 % $\to$ 100 %).
Validation en conditions réelles : Sur des programmes écrits de zéro à partir de briefs neutres, 15 à 47 % des programmes exécutables sont statistiquement mal spécifiés (les tests unitaires n'en détectent aucun). La réparation guidée par la calibration surpasse significativement les bases, y compris l'examen par LLM-as-judge, les checklists bayésiennes et l'auto-débogage par résumé de données.

Résultats

Détection : L'oracle est presque parfait pour les erreurs de vraisemblance, les problèmes de dispersion et la sur-inflation de zéros. Il peine légèrement avec la volatilité stochastique et certains types d'erreurs de lien qui préservent les moments des données.
Localisation : L'oracle peut localiser le type de bug avec une précision top-2 de 75 %, distinguant entre mauvaises vraisemblances, mauvais paramétrages et sur-dispersion, bien qu'il confonde parfois la sur-dispersion avec un conflit prior-données.
Capacité non monotone : Le bénéfice du feedback de calibration est non monotone. Il est négligeable pour les modèles trop faibles pour agir sur les diagnostics et pour les modèles assez puissants pour réparer aveuglément. Il est plus décisif pour les modèles « forts mais non saturés ».
Signification statistique : Les tests de McNemar appariés confirment que le feedback de calibration est nettement meilleur que l'absence de feedback ( $p = 4,4 \times 10^{-3}$ ) et que le feedback de test unitaire ( $p = 6,5 \times 10^{-7}$ ). Le feedback de test unitaire est nettement pire que l'absence de feedback ( $p = 3,4 \times 10^{-3}$ ).

Signification et Revendications

L'article soutient que pour les programmes probabilistes, la justesse est une question de calibration, pas de compilation.

Changement de paradigide : Le bon vérificateur pour le code probabiliste écrit par un LLM est le flux de travail bayésien lui-même, et non une suite de tests.
Préjudice actif des tests : La réussite des tests unitaires peut activement induire en erreur des modèles capables en leur faisant croire qu'un modèle mal spécifié est correct, supprimant ainsi le processus de réparation.
Impact pratique : L'oracle de calibration fournit une base principielle, légère en références, pour une modélisation assistée par LLM digne de confiance. Il comble le fossé entre la génération de code et la validité statistique, permettant aux LLM capables de corriger les erreurs « invisibles au code » que les outils traditionaux de génie logiciel ne peuvent détecter.

Les auteurs notent des limites : l'oracle n'est pas un certificat universel (il ne peut détecter les erreurs de structure causale si la distribution prédictive est identique, et il peine avec les coûts élevés de la SBC en haute dimension), mais c'est un vérificateur robuste pour les erreurs statistiques courantes commises par les LLM.