De pass@k au gate binaire : valider une application générée
Quel que soit le générateur, la preuve finale d'un programme est son exécution. Ce que la recherche dit des tests, de l'auto-réparation — et pourquoi Blueprint Maker a fait d'un critère binaire son seul juge automatisé. Article 3 de la série « La recherche sur le déterminisme ».
Les benchmarks supposent des tests que la vraie vie ne fournit pas
Toute la métrologie du domaine — pass@k en tête — repose sur une hypothèse discrète : chaque problème arrive avec ses tests de correction, écrits par les auteurs du banc d'essai. Le modèle génère, les tests tranchent. Mais dans l'usage réel, l'utilisateur qui décrit une application n'apporte pas de suite de tests : si le système veut trancher, il doit fabriquer lui-même sa preuve.
C'est le déplacement décisif : passer d'une correction estimée sur échantillon (combien de candidats passent des tests fournis) à une vérification opérée sur la sortie livrée (est-ce que CETTE application, celle que vous recevez, fonctionne).
L'auto-réparation aide, mais ne suffit pas
Une piste étudiée de près : demander au modèle de corriger son propre code à partir des erreurs d'exécution. L'étude de référence (ICLR 2024) tempère l'enthousiasme : les gains existent mais sont souvent modestes une fois rapportés au coût des appels supplémentaires, et dépendent fortement de la qualité du diagnostic que le modèle porte sur sa propre erreur — un modèle qui s'est trompé n'est pas le mieux placé pour comprendre pourquoi.
La leçon d'architecture : la boucle de réparation a sa place, mais comme mécanisme encadré par un juge EXTERNE et déterministe — pas comme garantie en soi.
- Olausson et al., Is Self-Repair a Silver Bullet for Code Generation? (ICLR 2024) : arxiv.org/abs/2306.09896
Le choix de Blueprint Maker : un critère binaire, exécuté pour de vrai
Chaque application générée passe, avant livraison, une validation en conditions réelles : le code est compilé, l'application est construite puis réellement démarrée en mode production, la base est peuplée, et la navigation est parcourue automatiquement écran par écran par un navigateur piloté. Le verdict est binaire : l'application tourne, ou elle ne tourne pas. Il n'y a pas de note de plausibilité, pas de score de confiance — un juge qui ne peut pas être charmé par du code qui « a l'air correct ».
Ce gate est doublé dans le temps : chaque nuit, un canari rejoue des générations de référence de bout en bout, et le pourcentage d'applications qui passent l'ensemble des vérifications sur les sept derniers jours est publié, daté, sur la page Fiabilité. La mesure précède l'argument.
Au-delà du démarrage : des valeurs qui ne peuvent pas mentir
Démarrer ne suffit pas : une application peut tourner et afficher des chiffres faux. La couche d'intégrité du produit prolonge la même doctrine jusqu'aux données : les valeurs dérivées — totaux, statuts calculés, agrégats — sont recalculées côté serveur à partir de leurs entrées, pour qu'une valeur affichée ne puisse pas contredire ce dont elle découle. Et en cas d'ambiguïté, l'abstention prime : la couverture ne passe jamais avant la correction.
La série en résumé
Un modèle de langage produit du plausible (article 1) ; on le cantonne donc à une spécification vérifiable (article 2) ; un moteur déterministe construit, et l'exécution réelle tranche (cet article). Trois étages, une seule idée : ne jamais demander à la statistique ce que l'architecture peut garantir.