Le pilote a répondu avec aisance, le comité a hoché la tête, et trois semaines plus tard quelqu’un a vérifié un chiffre contre le grand livre. Il était faux. Il l’était déjà le jour de la démonstration. On a accusé le modèle, on a changé de fournisseur, et le pilote suivant a été bâti sur la même fondation que le premier : une copie de l’entreprise, prise un mardi, interrogée un vendredi.
Le pilote est un rituel
L’Europe est championne du monde de la preuve de concept. Chaque grande organisation du continent tient un portefeuille de pilotes qui ne passeront jamais en production, supervisés par une direction de la transformation qui sera réorganisée avant que quiconque ait à dire pourquoi.[1] Ce n’est pas de l’incompétence. Un pilote confère tous les bénéfices politiques de l’action et aucune de ses expositions. Passer en production exige qu’une personne nommée porte une conséquence, et le pilote est conçu pour que personne ne la porte.
Alors quand un pilote échoue, le diagnostic est choisi pour son confort. « Le modèle a halluciné » arrange tout le monde : le fournisseur, dont le produit était simplement en avance ; l’acheteur, qui a simplement été prudent ; l’intégrateur, qui essaiera simplement un modèle plus gros le trimestre prochain.
La copie était fausse
Regardez sur quoi le pilote a été construit. Un extract. Un chargement d’entrepôt. Un index vectoriel rafraîchi chaque nuit, ou chaque semaine, ou une fois, en mars, par le stagiaire. Chacun de ces objets est une copie de l’entreprise, et une copie est périmée par construction : elle est juste à l’instant où on la prend et dérive à partir de là. Le contrat a été renouvelé jeudi ; la copie dit qu’il a expiré. La pièce a été reclassée ; la copie garde l’ancien code. Le modèle a lu la copie et répondu correctement sur un monde qui avait déjà bougé.
Une large part de ce qu’on classe en hallucination est exactement cela : des sources incohérentes, périmées ou partiellement répliquées qui alimentent le système avec un mauvais contexte.[2] La phrase était fluide parce que le modèle excelle en fluidité. Le chiffre était faux parce que rien, entre la question et la réponse, n’a jamais touché l’enregistrement.
La plausibilité est l’adversaire
Une réponse fausse qui a l’air fausse est un désagrément mineur, attrapé par le relecteur le moins attentif. Une réponse fausse qui a l’air juste est un danger structurel, et les systèmes génératifs sont optimisés, précisément et par conception, pour avoir l’air juste.[3] Savoir a toujours consisté à pouvoir exhiber, à la demande et devant un examinateur hostile, la chaîne par laquelle on est arrivé à une proposition. Retirez la chaîne et il reste une opinion bien écrite.
C’est pour cela que les courbes de capacité ne prédisent plus l’adoption. Les institutions qui refusent de déployer n’attendent pas un meilleur modèle. Elles attendent quelque chose qu’on puisse tenir.[4]
Ce qu’un pilote qui passe en production fait autrement
Quatre conditions, et une feuille de route qui les range parmi ses fonctionnalités les a déjà mal lues.[5]
Il va aux données. Le logiciel lit à travers les systèmes que l’organisation exploite déjà et calcule sur ce qu’il lit. Rien n’est migré, donc il n’y a pas de copie qui puisse être périmée. Le chiffre de la réponse est le chiffre du système de référence, à l’instant où la question a été posée.
Le modèle traduit ; il ne calcule pas. La même question, posée deux fois, rend la même réponse, au caractère près et à chaque fois. C’est atteignable, et la méthode n’a rien de mystérieux : le modèle est confiné à transformer une intention en un plan exprimé dans le vocabulaire de l’ontologie, et le plan s’exécute sans lui.[5:1] Un chiffre produit par un modèle est une probabilité. Un chiffre produit par un plan est un fait que vous pouvez rejouer.
Chaque chiffre remonte à l’enregistrement dont il vient. La provenance n’est pas une fonctionnalité. C’est la condition sous laquelle quelqu’un agira sur la réponse en sachant qu’on lui demandera plus tard de justifier l’action.
Un humain nommé porte la décision. La machine propose. Une personne, nommée et horodatée, approuve, et une erreur avant cette approbation est un brouillon, jeté. Une décision sans nom au bas de la page, c’est de la météo.[5:2]
Les questions à poser avant le prochain pilote
Posez-les au fournisseur, par écrit, avant la démonstration.
- D’où vient ce chiffre, et puis-je le suivre jusqu’à la ligne ?
- Si je pose la même question demain avec les mêmes paramètres, ai-je la même réponse, octet pour octet ?
- Que se passe-t-il entre la réponse et la modification de mon système ? Qui la voit en premier ?
- Quel nom figure sur la décision ?
- Y a-t-il là une copie de mes données, et de quand date-t-elle ?
Un fournisseur qui répond aux cinq par un mécanisme que vous pouvez vérifier depuis votre propre réseau a construit une machine de conséquence. Un fournisseur qui répond par une feuille de route a construit un pilote.
Monarch est construit sur les quatre conditions ci-dessus, dans votre infrastructure, sur les systèmes que vous exploitez déjà. Voyez-le sur vos données.