Le pilote a répondu avec aisance, le comité a approuvé, et trois semaines plus tard quelqu’un a comparé un chiffre au grand livre. Il était faux, et il l’était déjà le jour de la démonstration. On a accusé le modèle, changé de fournisseur, et construit le pilote suivant sur la même base : une copie du métier, prise un mardi et interrogée un vendredi.
Le pilote comme rituel
L’Europe mène plus de preuves de concept que quiconque. La plupart des grandes organisations détiennent un portefeuille de pilotes qui n’arriveront jamais en production, supervisés par une direction de la transformation qui sera réorganisée avant que quiconque n’ait à expliquer pourquoi.[1] Ce n’est pas de l’incompétence. Un pilote apporte les bénéfices politiques de l’action sans l’exposition. Passer en production exige qu’une personne nommée en prenne la responsabilité, et un pilote est conçu pour que personne n’ait à le faire.
Quand un pilote échoue, on choisit donc le diagnostic le plus confortable. « Le modèle a halluciné » arrange tout le monde : l’éditeur, dont le produit était en avance sur son temps ; l’acheteur, qui a été prudent ; l’intégrateur, qui essaiera un plus gros modèle au prochain trimestre.
La copie était fausse
Regardez sur quoi le pilote reposait : une extraction, un chargement d’entrepôt, un index vectoriel rafraîchi chaque nuit, chaque semaine, ou une seule fois en mars. Chacun est une copie du métier, et une copie commence à se périmer dès qu’elle est faite. 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 a répondu correctement sur une situation qui avait déjà changé.
Une grande part de ce qu’on qualifie d’hallucination relève exactement de cela : des sources incohérentes, périmées ou partiellement répliquées qui donnent au système le mauvais contexte.[2] La réponse était fluide parce que le modèle est doué pour la fluidité. Le chiffre était faux parce que rien, entre la question et la réponse, n’a vérifié l’enregistrement réel.
Le danger, c’est la vraisemblance
Une réponse fausse qui a l’air fausse est repérée par le relecteur le moins attentif. Une réponse fausse qui a l’air juste est un risque structurel, et les modèles génératifs sont conçus pour produire des réponses qui ont l’air justes.[3] Savoir quelque chose a toujours voulu dire pouvoir montrer, à la demande et devant un examinateur sceptique, comment on y est arrivé. Sans ce raisonnement, une réponse n’est qu’une opinion bien rédigée.
C’est pourquoi de meilleurs modèles ne font plus progresser l’adoption. Les institutions qui refusent de déployer n’attendent pas un modèle plus intelligent. Elles attendent des réponses qu’elles peuvent assumer.[4]
Ce que fait autrement un pilote qui arrive en production
Quatre conditions.[5]
Il interroge la donnée là où elle est. Le logiciel lit à travers les systèmes que l’organisation exploite déjà. Rien n’est migré, donc aucune copie ne se périme. Le chiffre de la réponse est celui du système de référence au moment de la question.
Le modèle traduit, il ne calcule pas. La même question, posée deux fois, rend la même réponse, mot pour mot. La méthode est simple : le modèle se contente de traduire une demande en un plan écrit 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 qu’on peut recalculer.
Chaque chiffre remonte à son enregistrement source. Sans cela, personne qui pourrait avoir à justifier une décision n’agira sur la réponse.
Une personne nommée porte la décision. Le système propose. Une personne nommée valide, avec un horodatage, et une erreur repérée avant la validation n’est qu’un brouillon jeté.[5:2]
Les questions à poser avant le prochain pilote
Envoyez-les au fournisseur par écrit, avant la démonstration.
- D’où vient ce chiffre, et puis-je remonter jusqu’à la ligne source ?
- Si je pose la même question demain avec les mêmes paramètres, obtiendrai-je exactement la même réponse ?
- Que se passe-t-il entre la réponse et une modification de mon système ? Qui la voit en premier ?
- Quel nom figure sur la décision ?
- Une partie de tout cela est-elle une copie de mes données, et de quand date-t-elle ?
Un fournisseur qui répond aux cinq questions par des éléments vérifiables depuis votre propre réseau a construit un système que vous pouvez mettre en production.
Monarch repose sur ces quatre conditions, dans votre infrastructure, sur les systèmes que vous exploitez déjà. Voyez-le sur vos données.