Frontière probabiliste

COADF P-1 énonce le minimum : un composant probabiliste renvoie une valeur accompagnée d'une confiance et de la méthode par laquelle la valeur a été obtenue, jamais une valeur nue, et il n'atteint jamais directement une sortie. Ce pattern porte sur la seconde moitié, celle que les mises en œuvre perdent. La réponse d'un modèle peut entrer dans le système. Ce qu'elle ne peut pas faire, c'est devenir, par quelque chemin que ce soit, ce que le système traite comme établi.

Trois conditions doivent tenir à la fois :

• La sortie a un type qui lui est propre. Une proposition et un enregistrement faisant autorité sont des types différents, des tables différentes ou des messages différents. Le code qui détient l'un ne peut pas le passer là où l'autre est attendu sans une étape explicite que quelqu'un peut relire.
• La frontière valide à l'exécution. Le contrat est vérifié à l'arrivée de la réponse, dans le processus qui la reçoit, quoi que l'expéditeur dise avoir vérifié.
• La provenance voyage avec la valeur. La méthode, le modèle et sa révision, la révision du prompt et l'emplacement dans la source restent attachés à travers chaque étape, sérialisation comprise. Sans eux, P-4 ne peut pas reconstruire et P-5 ne peut pas déclarer.

P-1 demande aussi au composant d'indiquer une confiance. La façon dont la confiance est exprimée, attribuée et utilisée relève de P-2, que COADF publie seulement comme principe. Ce Companion ne la décrit pas, et rien de ce qui suit n'en dépend.

La sortie d'un modèle provient d'un processus qu'on ne peut pas reproduire à partir de ses entrées comme on reproduit la sortie d'un parseur : l'échantillonnage, les mises à jour du modèle et les changements de prompt la font tous varier. C'est acceptable pour une proposition et inacceptable pour un fait. Le risque n'est pas qu'un modèle se trompe parfois ; tout se trompe parfois. Le risque est de perdre la capacité de dire quelles valeurs viennent d'où, parce que chaque contrôle ultérieur en dépend. Une barrière n'arrête que ce qu'elle voit, une déclaration ne nomme que ce qui est marqué, et une personne qui vérifie ne contrôle que ce qui pointe encore vers sa source.

La perte est rarement une décision. Elle survient sur une ligne de code ordinaire : une entité ORM remplie à partir du JSON du modèle parce que les noms de champs se trouvaient correspondre, un modèle de réponse qui laisse tomber la provenance parce que personne ne l'y a ajoutée, un import par lots qui contourne le formulaire où vivait la validation. Le pattern existe pour qu'on ne puisse pas écrire cette ligne sans s'en apercevoir.

L'isolation est architecturale, pas nécessairement physique

Les microservices ne sont pas nécessaires. La propriété tient quand aucun chemin de code ne permet au côté probabiliste de produire un objet faisant autorité, et un seul processus peut la tenir aussi bien qu'un réseau. La topologie se choisit pour ses propres raisons (mettre à l'échelle séparément une charge d'inférence, isoler la bibliothèque cliente d'un fournisseur, déployer indépendamment), puis la frontière se construit dans la forme choisie. Les quatre figures ci-dessous tiennent la même propriété sous quatre formes.

Les quatre mêmes éléments dans chaque topologie

• Des types distincts. Le côté probabiliste peut construire une proposition et rien d'autre. L'enregistrement faisant autorité n'est construit que par le code du domaine, à partir d'une proposition et de quelque chose que le côté probabiliste ne peut pas produire.
• Une validation à l'exécution sur chaque côté récepteur. Un schéma strict : champs non déclarés rejetés, aucune coercition de type, vocabulaires fermés pour les valeurs catégorielles, longueurs bornées. Dans une topologie distribuée, chaque récepteur valide, côté domaine compris quand l'expéditeur est un service maison : « nous avons validé avant l'envoi » est une affirmation sur un autre déployable, peut-être sur une version plus ancienne de celui-ci.
• La provenance dans le contrat. Déclarée, obligatoire, et préservée par chaque mapper et chaque sérialiseur en sortie.
• Une étape de promotion explicite. La seule voie d'une proposition vers un enregistrement faisant autorité est une fonction, un endpoint ou une commande qui exige ce que le côté probabiliste ne peut pas fournir. Pour les valeurs dérivées par un modèle de langue, le fence public F-03 de COADF exige une vérification humaine avant qu'elles n'atteignent une sortie publiée. La promotion est elle-même consignée dans la piste d'audit.

Une validation déterministe autour d'une sortie stochastique

Les contrôles qui ne lisent que la valeur (sa forme, son vocabulaire, son unité, les plages que le domaine définit lui-même) s'exécutent avant que quiconque la regarde. Ils ne rendent pas une valeur vraie. Ils rendent impossible une valeur impossible, et ils le font chaque fois de la même façon, ce sur quoi la personne qui vérifie la valeur peut compter.

Options d'application, de la plus faible à la plus forte

La plupart des systèmes veulent toujours les trois premiers, et les deux derniers quand le composant probabiliste est déployé à part. Le profil Python et FastAPI met en œuvre les trois premiers ; le profil Cloud-native ajoute les deux derniers.

• Des interfaces de suggestion seule. La sortie du modèle est montrée à une personne comme une suggestion et n'est jamais stockée comme valeur. Simple et solide ; on renonce à la traçabilité de ce qui a été suggéré, à moins de consigner aussi les suggestions.
• Un contrat partagé, neutre vis-à-vis du langage (JSON Schema, Protocol Buffers), au lieu de modèles natifs du langage. Mieux entre langages ; la question de la rigueur se déplace dans le schéma, où les propriétés supplémentaires et les formats doivent être décidés explicitement.
• Les modes de sortie structurée des API de modèles. Ils réduisent les réponses mal formées côté producteur. Ils ne dispensent pas le consommateur de valider, parce que le consommateur ne peut pas vérifier comment le producteur a été configuré.
• Un stockage séparé pour les propositions et les enregistrements, deux tables ou deux stockages plutôt qu'une table avec un statut. Plus lourd, et la séparation devient visible dans chaque requête que quiconque écrit.

• La frontière contrôle où la sortie d'un modèle peut aller. Elle ne rend pas cette sortie correcte, et une valeur bien formée mais fausse passe chaque contrôle de ce pattern.
• La séparation des types arrête les accidents, pas l'intention. Un développeur disposant d'un accès en écriture au domaine peut construire à la main un objet faisant autorité ; ce sont la revue de code et la piste d'audit qui rendent cela visible.
• Ce pattern ne dit pas quand une proposition a besoin d'une personne, ni comment la confiance est exprimée. Cela relève de P-2 et de P-3, que COADF publie seulement comme principes.
• La validation ne vaut que ce que vaut le contrat. Un schéma permissif, validé strictement, reste permissif.