La génération contrainte : obtenir une spécification, pas du texte
Si une IA doit produire quelque chose, autant lui faire produire un objet qu'une machine peut vérifier entièrement. C'est un champ de recherche actif — et le premier étage de l'architecture Blueprint Maker. Article 2 de la série « La recherche sur le déterminisme ».
Contraindre la forme : un problème résolu par la recherche
Un modèle de langage libre peut produire n'importe quelle suite de tokens — y compris du JSON invalide, une propriété inexistante, une énumération inventée. La recherche a montré qu'on peut faire mieux que corriger après coup : contraindre la génération elle-même. Le travail de référence reformule la génération comme des transitions dans un automate à états finis : à chaque pas, seuls les tokens compatibles avec une expression régulière ou une grammaire restent autorisés. La sortie est alors bien formée par construction, avec un surcoût négligeable.
Des travaux ultérieurs ont affiné la question — notamment comment garantir la grammaire sans distordre la distribution du modèle (un décodage trop brutalement contraint peut produire du « bien formé mais improbable »). Le point établi : la validité STRUCTURELLE d'une sortie de LLM est un problème d'ingénierie maîtrisé, plus un pari.
- Willard & Louf, Efficient Guided Generation for Large Language Models (2023) : arxiv.org/abs/2307.09702
- Park et al., Grammar-Aligned Decoding (NeurIPS 2024) : proceedings.neurips.cc
Pourquoi une spécification se vérifie mieux qu'un programme
L'asymétrie fondamentale est là : une spécification est un objet de DONNÉES, un programme est un objet de COMPORTEMENT. On peut vérifier exhaustivement qu'un objet de données respecte un schéma — chaque champ, chaque type, chaque relation, chaque valeur d'énumération. Vérifier exhaustivement le comportement d'un programme arbitraire, en revanche, ne se fait pas par simple inspection : il faut l'exécuter, le tester, et accepter une couverture partielle.
Faire produire au modèle une spécification plutôt qu'un programme déplace donc la sortie de l'IA du côté vérifiable de cette asymétrie. Tout ce qui peut être faux dans une spec bien formée relève du métier (une entité mal comprise, une règle mal déduite) — et cela, un humain peut le lire et le corriger, ce qui est précisément le rôle du plan que vous validez avant la construction.
Chez Blueprint Maker : l'AppSpec et ses portes de validation
Le LLM de Blueprint Maker produit un schéma métier structuré — l'AppSpec — dans un vocabulaire fermé : des entités, des champs typés, des relations, des états, des indicateurs. Cette spec passe ensuite une chaîne de validateurs déterministes : cohérence des clés étrangères, validité des énumérations, contraintes de nommage, validation du schéma de base de données par l'outil officiel — avec, en cas d'échec, des passes de régénération sous contrainte explicite plutôt qu'une correction silencieuse.
La doctrine en cas d'ambiguïté persistante est l'abstention : ne pas produire vaut mieux que produire faux. Une valeur douteuse n'est jamais « rattrapée » par une invention — c'est le même principe fail-safe qui gouverne toute la couche d'intégrité du produit.
La limite honnête : la forme n'est pas le sens
La génération contrainte garantit qu'une spec est bien formée ; elle ne garantit pas qu'elle décrit VOTRE métier. Un schéma peut être structurellement parfait et métier-faux. C'est pourquoi le plan est présenté avant construction : la validation humaine porte exactement sur ce que la machine ne peut pas vérifier — le sens. La répartition est nette : à la machine la conformité, à vous la pertinence.