L'évaluation d'abord : bâtir des systèmes d'IA qui continuent de fonctionner

Pourquoi les entreprises qui réussissent avec l'IA sont celles qui ont défini ce que veut dire « correct » avant de choisir un modèle.

Le problème du sixième mois

Toute entreprise ayant mené un projet pilote d'IA connaît le scénario. La première semaine est un triomphe. Quelqu'un présente un assistant qui répond à des questions qu'on croyait hors de portée d'une machine, la salle est impressionnée, et un budget apparaît. Le sixième mois est plus discret. Le système fonctionne toujours, techniquement. Les gens sont retournés au chiffrier sans le dire. Personne ne peut préciser à quel moment la qualité a baissé, de combien, ni pourquoi.

Le réflexe est de blâmer le modèle. Ce n'est presque jamais le modèle. Un schéma de données a changé en amont. Un fournisseur a livré une nouvelle version d'un service. La personne qui avait ajusté les instructions est passée à une autre équipe. Une règle d'affaires vraie en mars a cessé de l'être en juin. Chacun de ces événements est mineur. Ensemble, ils expliquent pourquoi la plupart des pilotes d'IA ne deviennent jamais des produits.

Ce qui manque n'est pas l'intelligence. C'est un mécanisme qui remarque.

L'évaluation n'est pas un bulletin

Dans la plupart des organisations, l'évaluation arrive à la fin. Le système est construit, puis on demande à quelqu'un de vérifier s'il fonctionne, généralement en cliquant un après midi durant. Si le projet est mature, il existe un tableau de bord. Le tableau de bord est réel, ses chiffres sont réels, et il a quand même la mauvaise forme, parce qu'un tableau de bord est une chose qu'on regarde après qu'une décision a déjà été prise. Le temps qu'une courbe montre une baisse, les mauvaises réponses ont déjà atteint les clients.

L'évaluation d'abord inverse l'ordre. Avant de construire quoi que ce soit, on écrit ce à quoi ressemble une bonne réponse pour cette entreprise, dans ce contexte, maintenant. Pas une aspiration vague du genre « précis et utile ». Un ensemble concret de vraies questions, avec les réponses que votre meilleure personne juge correctes, et les règles qui ne doivent jamais être enfreintes. Cet artefact est la spécification. Le système est ensuite construit pour l'atteindre et, surtout, le système n'a pas le droit d'être mis en production s'il ne l'atteint pas.

L'idée n'est pas nouvelle. C'est le même mouvement que l'industrie du logiciel a déjà fait deux fois. Les systèmes de types ont retiré toute une classe de questions de correction à la revue de code pour en faire une propriété de la compilation. L'intégration continue a retiré la question « est ce que ça compile toujours » des mains du testeur pour en faire une barrière qui bloque une fusion. Les deux ont paru bureaucratiques à leur arrivée. Les deux sont aujourd'hui une infrastructure invisible dont plus personne ne voudrait se passer.

L'IA a besoin du même mouvement, avec une différence qui le rend plus difficile et plus intéressant. Pour du logiciel ordinaire, la correction peut souvent être prouvée. Pour une capacité d'IA, la correction doit être mesurée. On ne peut pas prouver qu'un résumé est fidèle ou qu'une réponse est fondée sur les sources. On peut seulement définir une exigence, échantillonner contre elle, et refuser de promouvoir tout ce qui ne l'atteint pas.

La vraie question n'est donc pas de savoir si votre système d'IA est précis. C'est de savoir si votre organisation possède une exigence qu'un système peut échouer, et la discipline d'agir quand il l'échoue.

Ce que cela rapporte concrètement

Présentée comme une bonne pratique d'ingénierie, l'évaluation d'abord ressemble à quelque chose qu'on fera plus tard, quand il y aura du temps. Présentée correctement, c'est ce qui détermine si l'IA devient un actif ou une dépense récurrente.

Cela rend le changement sécuritaire. C'est le point le plus important et le moins évident. Sans exigence, tout changement significatif est un acte de foi. Faut il passer au modèle moins cher qui vient de sortir ? Personne ne le sait, alors soit vous prenez le risque à l'aveugle, soit vous ne le prenez pas du tout, et les deux réponses coûtent cher. Avec une exigence, cette question devient une expérience qui se termine mardi et qui produit un chiffre. La flexibilité sans évaluation est un passif. La flexibilité avec évaluation est un levier.

Cela survit aux départs. Une capacité validée par une conversation vit dans la tête de la personne qui a eu la conversation. Quand elle change de rôle, le savoir part avec elle et le système commence à pourrir en silence. Une capacité validée par une exigence explicite et exécutable appartient à l'entreprise.

Cela rend l'IA gouvernable. Tout acheteur sérieux, tout auditeur et tout organisme de réglementation converge vers la même question : comment savez vous que ça fonctionne encore ? « Notre équipe garde un œil dessus » n'est pas une réponse qui survit à une revue d'approvisionnement. Une exigence qui s'exécute à chaque changement, avec une trace de ce qui a passé et de ce qui a échoué, oui.

Cela change ce que vous accumulez. C'est la partie que j'afficherais au mur. Quand on construit ainsi, l'actif durable n'est pas le modèle, et ce ne sont pas les instructions. C'est le jeu d'évaluation : la définition encodée, testée et durement acquise de ce que « correct » veut dire à l'intérieur de votre entreprise précise. Les modèles deviennent meilleurs et moins chers tous les quelques mois, et tout ce que vous aviez bâti par dessus l'ancien est jeté. Votre définition du correct, elle, n'expire pas. C'est la seule partie d'un investissement en IA qui compose.

Le volant d'inertie

La plupart des programmes d'IA sont structurés de façon linéaire. Quelqu'un construit la capacité numéro un. Puis quelqu'un construit la capacité numéro deux, qui coûte à peu près autant que la première. Pendant ce temps, la première se dégrade, parce que rien ne la surveille. Ajoutez assez de capacités et toute l'équipe est absorbée par l'entretien. C'est le modèle derrière presque toutes les initiatives d'IA d'entreprise qui échouent, et aucun ajout de personnel ne le corrige, puisque le personnel est précisément ce qu'il consomme.

Un volant d'inertie se comporte autrement. Chaque tour rend le suivant moins coûteux.

Livrer étroit, avec une exigence explicite. Une capacité, une tâche claire, un ensemble modeste de vrais cas qu'elle doit réussir. Assez petit pour qu'un expert du domaine puisse examiner tout le jeu de tests en une seule séance.

Laisser la réalité trouver les échecs. Elle trouvera des échecs que votre jeu de tests n'avait pas imaginés, parce que les vrais utilisateurs posent leurs questions dans un ordre et une formulation que personne ne conçoit d'avance.

Transformer chaque échec réel en cas permanent. C'est la charnière de toute la boucle. Un échec corrigé puis oublié reviendra. Un échec devenu cas de test ne peut plus se produire deux fois sans que quelqu'un en soit averti.

Laisser l'exigence monter d'un cran. La barre s'élève à mesure que le système apprend ce qu'il a raté. Surtout, elle ne redescend jamais en silence. Un changement qui l'abaisserait est bloqué, et non fusionné puis regretté plus tard.

Réutiliser la machinerie. Rendu à la troisième capacité, l'infrastructure de tests existe, l'habitude de revue existe, les experts savent à quoi ressemble un bon cas, et la définition du correct pour les concepts partagés comme « client » ou « livraison en retard » est déjà écrite. Le coût marginal de la capacité suivante baisse au lieu de stagner.

C'est là toute la différence entre un programme d'IA qui coûte plus cher chaque trimestre et un qui coûte moins cher. Pas le talent, pas l'outillage. La présence ou l'absence d'une boucle qui capture les échecs au lieu de les jeter.

Où l'humain se situe vraiment

L'expression « humain dans la boucle » a été diluée jusqu'à ne plus vouloir dire que « une personne vérifie la sortie ». Cette version ne passe pas à l'échelle, et c'est une taxe qui grandit proportionnellement à l'usage du système. Si chaque réponse doit être révisée, vous n'avez rien automatisé. Vous avez embauché des réviseurs.

La version utile place l'humain ailleurs. Pas sur le trajet de chaque sortie, mais au point où le jugement se crée plutôt qu'il ne se répète.

Définir l'exigence. Un expert du domaine est la seule personne capable de dire à quoi ressemble une bonne réponse pour son entreprise. Cela ne veut pas dire qu'il doit rédiger des cas de test à partir d'une page blanche pendant trois semaines. Cela veut dire que son temps doit servir au jugement, pas à la transcription : montrez lui des cas candidats tirés de ses vraies données et laissez le accepter, corriger ou rejeter. C'est une tâche qui se mesure en minutes, et c'est le travail humain de plus grande valeur dans tout le système.

Porter les vétos. Certaines règles ne sont pas des scores. Prenez un système qui répond correctement à quatre vingt dix pour cent des questions de tarification et qui, à l'occasion, invente une clause contractuelle qui n'existe pas. Il est tentant de qualifier cela de quatre vingt dix pour cent bon. Ce n'est pas le cas. C'est dangereux à mettre en production, et n'importe quelle moyenne cachera exactement cela, parce qu'une bonne moyenne est très douée pour enterrer un échec rare et catastrophique. Quelqu'un doit nommer les échecs qu'aucun agrégat n'a le droit de faire taire, et ce quelqu'un est un humain qui comprend les conséquences.

Approuver ce qui compte, et seulement cela. Tous les changements ne méritent pas une approbation. Un changement à un outil de recherche interne et un changement à un système qui déplace de l'argent ne méritent pas la même cérémonie. Décider quelles capacités portent un risque réel est un jugement humain, posé une fois, qui détermine ensuite pendant des années la friction appliquée par la machinerie.

Remarquez le motif. Dans chaque cas, l'humain fournit un jugement une seule fois et le système l'applique indéfiniment. C'est l'échange qui rend l'IA digne d'être construite : non pas remplacer l'expertise, mais la capturer sous une forme qui fonctionne encore un mardi dans dix huit mois, quand l'expert occupe un autre poste.

Construisez la barrière avant l'atelier

S'il y avait une seule règle de séquence à donner à une entreprise qui démarre, ce serait celle là.

Il est tentant de construire d'abord l'outil qui permet aux gens de créer rapidement des capacités d'IA, et d'ajouter la mesure plus tard, une fois qu'il y aura quelque chose à mesurer. Cet ordre est inversé, et l'échec qu'il produit est pire que de n'avoir aucun produit. Un moyen rapide de livrer des capacités sans moyen de les mesurer est une machine à produire des passifs non mesurés, à grande vitesse.

La version pratique, pour une entreprise sans aucune infrastructure d'IA, est plus modeste qu'il n'y paraît. Avant de choisir un modèle, avant de choisir un cadre logiciel, avant d'écrire une ligne d'orchestration : asseyez vous avec la personne qui connaît le métier et écrivez trente à cinquante vraies questions, avec les réponses qu'elle juge correctes, et les deux ou trois choses que le système ne doit jamais faire. Passez cet ensemble à la main contre ce que vous construisez. Ce n'est pas glorieux et cela prend quelques jours.

C'est aussi le moyen le plus rapide de découvrir si vous avez un projet. Si personne dans l'entreprise ne s'entend sur ce à quoi ressemble une bonne réponse, vous n'avez pas encore un problème d'IA. Vous avez une question d'affaires non résolue, et aucun modèle ne la résoudra à votre place.

Ce que je construis

C'est la thèse derrière Aulë, le système que je développe actuellement. Il part du principe que l'évaluation n'est pas une fonctionnalité d'une plateforme d'IA mais sa raison d'être, et qu'une capacité ne devrait pas pouvoir atteindre la production tant qu'elle n'a pas satisfait une exigence que quelqu'un a délibérément écrite. C'est très largement en cours, et j'en dirai davantage lorsque ce sera quelque chose que je peux montrer plutôt que décrire.

L'argument plus large tient debout tout seul, cela dit, et il ne dépend ni de mon système ni de celui de quiconque. Le marché a passé plusieurs années à enseigner aux entreprises que les démonstrations d'IA sont faciles et que les produits d'IA sont difficiles. La distance entre les deux n'est pas un modèle, un cadre logiciel ou une ligne budgétaire. C'est une exigence qu'un système peut échouer, une boucle qui transforme chaque échec en leçon permanente, et un humain dont le jugement est capturé une fois plutôt que consommé indéfiniment.

Commencez par ce que « correct » veut dire. Tout le reste en découle.