D'où viennent vraiment les erreurs.
Un score de prototype ne dit pas quoi corriger. Le geste utile consiste à reprendre les échecs un par un et à décider, pour chacun, s'il vient du système ou de ce qu'on lui a donné à appliquer. Sur un cas réel, la réponse a réorienté la mission.
Un score ne dit pas quoi corriger
Un prototype documentaire finit toujours par produire un pourcentage. Le système traite correctement une certaine proportion des cas, et l'équipe se met aussitôt à discuter du modèle : faut-il en prendre un plus gros, ajuster les instructions, enrichir la recherche.
Cette discussion est prématurée, parce que le score ne dit rien de l'endroit où se trouve le défaut. Un système peut échouer parce qu'il a mal compris la demande, parce qu'il a ramené le mauvais document, ou parce que la réponse attendue n'existe nulle part dans le référentiel qu'on lui a confié. Ces trois échecs se ressemblent dans un tableau de résultats et n'appellent pas du tout le même travail.
Le seul geste qui les sépare est fastidieux et ne s'automatise pas : reprendre les échecs un par un et décider, pour chacun, où se situe la cause.
Imputer chaque échec, un par un
Sur un prototype récent, nous avons repris l'intégralité des cas en échec et attribué chacun à une cause unique. Le résultat a réorienté la mission.
| Origine de l'échec | Part des cas en échec |
|---|---|
| Le référentiel écrit ne traite pas la situation | 52,1 % |
| Notre système | 12,5 % |
| Autres causes, dont données d'entrée incomplètes | le reste |
Plus de la moitié des échecs ne venaient pas du système. Ils venaient de ce qu'on lui demandait d'appliquer une règle qui n'était écrite nulle part. Aucun réglage, aucun modèle plus performant, aucune amélioration de la recherche n'y change quoi que ce soit : la bonne réponse n'existe pas dans le corpus.
Ce que le plafond change à un projet
Annoncer ce plafond à un client est inconfortable, et c'est la conversation la plus utile de la mission. Elle déplace le projet d'un chantier technique vers un chantier de doctrine : ce qu'il faut produire n'est pas une meilleure intelligence artificielle, ce sont les règles manquantes, écrites, validées, opposables.
Elle a aussi une conséquence pratique. Chaque règle manquante devient une ligne identifiée, avec le nombre de cas qu'elle débloquerait. La liste des trous se hiérarchise donc par volume, et la décision d'écrire ou non telle règle s'appuie sur un chiffre plutôt que sur une impression.
Il faut ajouter une vérification qui a son importance : une version enrichie du référentiel nous a été fournie en cours de mission, et nous l'avons repassée sur le même échantillon plutôt que de la croire sur parole. Elle n'a comblé aucun des trous identifiés, et son effet mesuré se comptait en une poignée de cas. Un enrichissement qui paraît substantiel à la lecture peut ne rien changer là où ça compte.
Les règles déterministes d'abord, le modèle en rattrapage
Le réflexe consiste à faire traiter tous les cas par le modèle. C'est le plus rapide à construire et le plus difficile à défendre ensuite.
Nous procédons dans l'ordre inverse. Un jeu de règles déterministes, écrites en code, traite d'abord ce qui est décidable sans interprétation. Sur ce prototype, ces règles ont absorbé plus de la moitié du volume sans aucun appel au modèle, à justesse égale. Le modèle n'intervient qu'en rattrapage, sur ce que les règles n'ont pas su trancher.
Trois bénéfices, dans cet ordre d'importance. La partie déterministe est testable : elle se couvre par des tests unitaires, et une régression se voit. Elle est explicable à un auditeur, ce qu'aucune sortie de modèle n'est réellement. Et elle ne consomme rien, ce qui déplace la question du coût hors du débat.
Le corollaire vaut d'être dit : la proportion de cas traités sans modèle est un indicateur de maturité du référentiel. Plus il est précis, plus la part déterministe grandit. Un corpus flou pousse tout vers l'interprétation.
Appeler par identifiant, jamais par ressemblance
Une objection nous a été faite en cours de mission, et elle était fondée. Le dispositif présentait un rapprochement entre le cas traité et des cas comparables, ce qui donnait l'impression d'un bouton magique : le système trouverait la réponse en cherchant ce qui ressemble.
La réponse tient en une phrase, et c'est un point d'architecture. La réponse est récupérée dans le référentiel par identifiant, de façon déterministe. La ressemblance ne sert qu'à compléter l'affichage, jamais à décider. Le test qui le prouve est simple : on peut supprimer entièrement le rapprochement par similarité sans changer une virgule au document produit.
Ne rien générer de ce qui engage
Sur un document qui produit un effet juridique ou contractuel, la règle est absolue : le modèle ne rédige pas. Le texte de référence est reproduit mot pour mot depuis le corpus validé, et le modèle ne fait qu'assembler et personnaliser ce qui doit l'être.
Cette contrainte est plus facile à tenir qu'il n'y paraît, parce qu'elle correspond à ce que fait déjà un professionnel : il ne réinvente pas une clause, il prend le modèle validé et l'adapte. Un système qui génère du contenu engageant ne fait pas mieux qu'un humain, il fait quelque chose que personne n'a le droit de faire.
Rendre le trou visible, pas seulement l'échec
Le dispositif qui a permis l'imputation mérite d'être décrit, parce qu'il est transposable. Nous avons constitué un second corpus de référence, indépendant de celui du client, et il n'est consulté que lorsque le référentiel principal reste muet sur la situation.
Ce déclenchement conditionnel fait toute la différence. Si les deux corpus étaient interrogés ensemble, le système répondrait mieux et personne ne verrait que le référentiel du client était insuffisant : le trou serait comblé silencieusement. En n'appelant le second qu'en cas de silence du premier, chaque recours devient un signal, comptable et imputable à l'écran.
C'est un choix contre-intuitif : nous dégradons volontairement la performance apparente du système pour rendre une information visible. Cette information vaut plus que les points de score qu'elle coûte.
L'erreur qu'aucun meilleur modèle ne réduira
Une catégorie d'échec résiste à toutes les améliorations, et c'est celle sur laquelle nous travaillons ensuite. Le système identifie correctement la catégorie du cas, récupère le document prévu pour cette catégorie, et ce document ne traite pourtant pas la situation particulière du dossier.
Rien n'est faux dans la chaîne. La classification est juste, la récupération est juste, et le résultat est inadéquat. Aucun modèle plus performant ne corrige cela, parce qu'il n'y a pas d'erreur de compréhension à corriger : il manque une vérification, qui consiste à confronter le contenu du document retenu au contenu réel de la demande, et à refuser plutôt que de livrer quand la confrontation échoue.
Cette catégorie est la raison pour laquelle nous nous méfions des tableaux de performance par étape. Une chaîne dont chaque maillon affiche un bon score peut produire un résultat inutilisable, et seule une évaluation de bout en bout, sur des cas jamais vus pendant la construction, le révèle.
Ce qui se transpose
Quatre gestes, applicables à n'importe quel système qui applique un référentiel écrit à des cas particuliers.
Évaluer sur des cas jamais vus pendant la construction, sans quoi le score mesure la mémoire du système et non sa capacité. Imputer chaque échec à une cause unique, ce qui coûte des heures et redirige des semaines. Calculer le plafond à référentiel constant, pour savoir combien de l'écart restant relève de l'informatique et combien relève de l'écriture. Et instrumenter le silence du référentiel, pour que ce qui manque apparaisse au lieu d'être comblé sans bruit.
Le résultat de cette démarche n'est pas seulement un système. C'est une liste de règles manquantes, hiérarchisée par le nombre de cas qu'elles débloqueraient, que le client conserve même s'il change de prestataire.