Une IA qui sait dire qu'elle ne sait pas.
Promettre l'absence d'erreur ne survit pas au premier contre-exemple. Ce qui se défend, c'est une erreur bornée, tracée et mesurée. Voici l'architecture que cela impose, et ce que vous pouvez exiger d'un prestataire.
La promesse qu'il ne faut jamais faire
« Notre intelligence artificielle n'hallucine pas. » La phrase se vend bien, et elle ne survit pas à sa première mise à l'épreuve. Il suffit d'un contre-exemple, un seul, pour que le client cesse de croire tout le reste : le taux de disponibilité, le calendrier, la sécurité. Une promesse absolue transforme n'importe quel incident mineur en preuve de mensonge.
Le problème n'est pas commercial, il est technique. Un modèle de langage produit toujours une réponse. Il n'a aucun mécanisme interne qui lui permette de constater qu'il ne sait pas : il enchaîne des mots plausibles, et le plausible est exactement ce qui ressemble à du vrai. Promettre l'absence d'erreur revient à promettre qu'un outil se comportera contre sa nature.
Ce qu'on peut promettre à la place
La promesse défendable ne porte pas sur l'absence d'erreur. Elle porte sur les bornes qu'on met autour de l'erreur possible, et sur le fait qu'on la mesure.
Concrètement, cela donne quatre engagements qui se vérifient tous les quatre. Le système ne peut rien affirmer qui ne soit dans vos données. Chaque phrase cite sa source. Chaque chiffre est calculé et non produit par le modèle. Le taux de fidélité est mesuré en continu sur un jeu de test, pas annoncé une fois dans une plaquette. Et ce qui passe sous le seuil part en validation humaine au lieu d'être livré.
La différence avec la promesse absolue est qu'un client peut demander à voir. Un jeu de test s'inspecte, un score se recalcule, un seuil se déplace. Rien de tout cela n'est une question de confiance.
L'architecture qui rend la promesse vraie
Une doctrine qui ne change pas la construction ne vaut rien. Celle-ci a des conséquences précises sur la façon dont le système est assemblé, et la principale consiste à retirer au modèle de langage tout ce qu'il fait mal.
Les faits, les identifiants et les montants viennent de votre base ou de vos documents, jamais de la mémoire du modèle. Les calculs, les scores et les règles de criticité sont écrits en code, donc testables, donc corrigeables. Le modèle n'intervient qu'en fin de chaîne, pour mettre en forme ce qu'on lui a fourni.
Le reste tient à trois règles de construction. La recherche documentaire vient avant la génération, ce qui interdit de déverser un dossier entier dans le contexte en espérant que le modèle s'y retrouve. Les instructions sont atomiques : une tâche par appel, avec une sortie au format strictement défini, plutôt qu'une instruction fleuve qui demande huit choses à la fois. Et la confiance se mesure champ par champ, pas globalement, parce qu'un document peut être parfaitement lu sur neuf champs et illisible sur le dixième.
Les risques qui restent, et ils restent
Une doctrine honnête nomme ce qu'elle ne couvre pas. Quatre risques subsistent dans cette architecture, et nous préférons les écrire que les découvrir avec vous.
La recherche documentaire peut remonter la mauvaise source : le système est alors fidèle, mais fidèle au faux. La mise en forme peut trahir le contenu, plus rarement, mais le risque n'est pas nul même quand le modèle ne fait qu'empaqueter. La classification de la demande peut se tromper et orienter vers la mauvaise procédure. Enfin une donnée peut être sûre et périmée, ce qu'aucun mécanisme de fidélité ne détecte.
Ces quatre risques se traitent par les mêmes moyens : citer les sources pour qu'un humain puisse vérifier, poser des seuils qui déclenchent une relecture, et mesurer en continu au lieu de supposer que ce qui marchait le mois dernier marche encore. Aucun ne se traite par une affirmation.
Le très grand contexte est un argument de vente
Un argument revient dans presque toutes les offres : la fenêtre de contexte géante, présentée comme la solution au problème de la fiabilité. Il suffirait de tout donner au modèle pour qu'il trouve.
La recherche publiée sur le sujet dit l'inverse. La capacité d'un modèle à utiliser une information se dégrade selon la position de cette information dans un contexte chargé : ce qui se trouve au milieu d'un très long document est nettement moins bien exploité que ce qui se trouve aux extrémités. Charger davantage ne rend pas plus fiable, cela déplace le problème.
Une offre qui vante la taille de sa fenêtre sans montrer son architecture d'instructions vend une caractéristique de son fournisseur de modèle, pas une propriété de son système.
Apprendre à un système à se taire
Le travail le plus utile que nous faisons sur nos propres produits ne consiste pas à améliorer les réponses. Il consiste à obtenir des silences aux bons endroits.
Un extrait dont la pertinence est sous un seuil mesuré n'entre pas dans la réponse. Et surtout, il n'entre pas non plus dans les éléments transmis au modèle, ce qui n'est pas la même chose : un extrait qu'on retire seulement de l'affichage continue d'influencer la réponse, et le système paraît alors citer proprement des sources qui ne fondent rien. Si plus aucun extrait ne passe le seuil, le système dit que le point n'est pas couvert, au lieu de meubler.
C'est une exigence coûteuse. Un système qui répond toujours fait meilleure impression en démonstration, et l'écart ne se voit qu'en production, le jour où quelqu'un s'appuie sur une réponse qui n'aurait pas dû exister.
Ce que vous pouvez exiger
Si vous évaluez une offre d'intelligence artificielle, quatre demandes suffisent à séparer ceux qui ont mesuré de ceux qui affirment.
Demandez le taux d'erreur par champ, sur un jeu de test que vous pouvez inspecter. Demandez ce que le système fait quand il ne sait pas, et faites-en la démonstration sur une question hors périmètre. Demandez quels chiffres sont calculés et lesquels sont produits par le modèle. Demandez enfin quels risques subsistent, en sachant qu'une réponse du type « aucun » disqualifie l'offre plus sûrement que n'importe quelle limite avouée.
Nous appliquons ces quatre questions à nos propres systèmes avant de les proposer, et nous publions les défauts que nous y trouvons. C'est la seule manière que nous connaissons de rendre une promesse vérifiable plutôt que crédible.
Sur la dégradation de l'exploitation d'une information selon sa position dans un contexte chargé, voir les travaux publiés sous le nom de « lost in the middle » (Liang et coll.).