Évaluation continue : le chaînon manquant des projets IA

L’évaluation continue d’un système d’IA consiste à rejouer des cas métier identifiés après chaque changement, afin de repérer les dégradations de qualité que la disponibilité technique ne révèle pas.

Un service peut continuer à répondre tout en donnant de moins bonnes réponses. Le texte reste fluide, les journaux ne signalent aucune exception, et les utilisateurs perdent confiance avant que l’équipe comprenne pourquoi.

Une recette mesure le système au moment de la livraison. L’évaluation continue répète cette mesure après une modification du prompt, du corpus ou du modèle, et lorsque l’usage évolue.

Un changement de modèle, de prompt, de corpus ou d’usage peut dégrader les réponses sans arrêter le service, ce qui impose de vérifier les résultats métier.

• Le fournisseur met à jour son modèle. Le comportement change sans que rien ne bouge chez vous.
• Quelqu’un retouche un prompt pour corriger un cas particulier, et casse trois cas généraux.
• Le corpus évolue : de nouveaux documents arrivent, d’autres deviennent obsolètes sans être retirés.
• L’usage se déplace : les utilisateurs posent des questions différentes de celles anticipées.

Une dégradation peut rester invisible parce qu’une réponse erronée conserve la forme d’un texte plausible, alors que les indicateurs de disponibilité ne vérifient pas sa justesse.

Exemple générique : un assistant d’achat reçoit une nouvelle procédure sans retrait de l’ancienne. Il cite alternativement les deux versions. Le service demeure disponible, mais les consignes deviennent contradictoires. C’est pourquoi le corpus est le projet autant que le modèle.

Un jeu de tests utile pour l’IA générative est un ensemble versionné de cas réels, chacun avec sa question, le contexte attendu et une réponse de référence validée par le métier. Ce n’est pas un banc d’essai académique.

Trois propriétés le rendent utilisable. Il est stable : on n’ajoute pas de cas sans raison, sinon on ne compare plus rien. Il est représentatif : il contient les cas tordus, pas seulement les cas de démonstration. Et il est rejouable en une commande : si l’exécution demande une demi-journée de préparation, elle ne sera pas faite.

Chaque ligne du jeu gagne à contenir quatre champs simples :

• la question telle qu’un utilisateur l’a réellement posée, fautes comprises ;
• le ou les documents qui doivent être mobilisés pour y répondre ;
• les éléments de réponse obligatoires (un montant, une date, une référence, un refus attendu) ;
• la famille de tâche à laquelle le cas appartient, pour pouvoir lire les résultats par famille.

Le jeu ne vaut que par sa composition. Un jeu rempli de questions faciles donnera toujours un bon score et ne détectera rien. Réservez une place aux cas limites et aux échecs observés. Leur proportion dépend du risque et des tâches couvertes.

On note une réponse d’IA en texte en combinant trois niveaux : des vérifications factuelles automatiques, un jugement par un autre modèle sur critères écrits, et une relecture humaine périodique. C’est la difficulté propre à l’IA générative, et il n’existe pas de solution parfaite.

Le premier niveau est factuel et automatique : la réponse cite-t-elle le bon document, contient-elle le bon montant, la bonne date, la bonne référence. Le critère est explicite et vérifiable, et cela couvre déjà une grande partie des régressions graves.

Le deuxième fait juger la réponse par un autre modèle, sur des critères écrits. C’est utile pour détecter une dérive de ton ou une réponse hors sujet, mais cela ne remplace pas le troisième : une relecture humaine périodique sur un échantillon, dont les désaccords doivent être explicités avec le métier.

L’ordre compte. On commence par le niveau factuel, parce qu’il est fiable et peu coûteux, et on n’ajoute le jugement par modèle que lorsque les vérifications binaires ne suffisent plus à couvrir les régressions observées.

Une évaluation réalisée uniquement à la livraison décrit un état passé du système et ne permet pas de vérifier sa qualité après les changements de données ou d’usage.

Une évaluation faite une fois, à la recette, mesure l’état du système le jour de la recette. Elle ne dit rien de son état trois mois plus tard. Or c’est précisément à ce moment que les décisions se prennent : renouveler, étendre, arrêter.

Mettre en place une évaluation continue tient en cinq étapes : collecter des cas réels, fixer les références avec le métier, automatiser l’exécution, brancher les déclencheurs, puis lire les résultats par famille. Aucune ne demande d’outillage sophistiqué.

1. Collecter les cas. Partir des questions réellement posées pendant le prototype ou le pilote, et des réponses qui ont été signalées comme fausses. Viser trente cas pour commencer.
2. Fixer les références. Faire valider par une personne du métier, pour chaque cas, ce qu’une bonne réponse doit contenir. C’est l’étape qui demande le plus de temps humain, et celle qu’on ne peut pas déléguer.
3. Automatiser l’exécution. Écrire un script qui envoie chaque question au système, récupère la réponse et applique les vérifications factuelles. Le résultat doit tenir sur une page.
4. Brancher les déclencheurs. Relancer le jeu à chaque modification du prompt, à chaque changement de version du modèle, à chaque réindexation du corpus, et à intervalle fixe.
5. Lire par famille. Un score global masque les régressions locales. Une baisse nette sur une seule famille de questions est un signal ; noyée dans la moyenne, elle disparaît.

Ce dispositif s’appuie sur un prompt système versionné, comme décrit dans écrire un prompt système qui tient six mois : on ne peut comparer deux résultats que si l’on sait exactement ce qui a changé entre eux.

Le coût d’une évaluation continue dépend du nombre de tâches, de la disponibilité des références et de la difficulté des contrôles, plutôt que d’une durée universelle de mise en place.

Séparez la constitution des cas, l’automatisation et la revue humaine récurrente. Les références métier demandent une validation ; un script ne remplace pas cette étape.

Je considère qu’un système sans mesure répétée reste une démonstration prolongée. La mesure est l’un des cinq verrous qui empêchent de sortir du prototype.

Un jeu de tests permet de comparer un changement de modèle, une baisse de palier ou une modification du prompt, à condition de conserver des critères identiques entre les essais.

La décision porte sur les erreurs, les délais et le coût par résultat accepté. Une amélioration moyenne ne compense pas un défaut sur une tâche critique. Le protocole de comparaison apparaît dans choisir le palier, pas le modèle.

Un jeu de tests reste vivant lorsque les erreurs signalées sont qualifiées, reliées à une référence métier et ajoutées à une version identifiable du jeu.

Ajoutez le cas après avoir vérifié le signalement et retiré les données inutiles. Un test détecte une régression couverte ; il ne garantit pas l’absence d’autres erreurs. Si le jeu devient trop lent, scindez-le par tâche et conservez une campagne complète. Lecture complémentaire : construire un jeu de tests en une journée.

Les erreurs fréquentes en évaluation d’un système d’IA sont d’évaluer une seule fois, de tester des cas trop faciles, de changer le jeu à chaque exécution et de ne regarder qu’un score moyen. Chacune rend la mesure inutile sans que l’équipe s’en aperçoive.

• Évaluer une fois. La recette devient la seule mesure, et plus personne ne sait ce que fait le système six mois plus tard.
• Tester la démonstration. Les cas choisis sont ceux qui marchent ; le score est flatteur et ne protège de rien.
• Faire bouger le jeu en permanence. Si les cas changent entre deux exécutions, on ne compare plus le système, on compare deux jeux.
• Lire la moyenne. Une régression sur une famille de questions sensibles se dilue dans un score global stable.
• Laisser l’IT seule juge. Une équipe technique peut automatiser les vérifications, pas décider de ce qu’est une bonne réponse métier.

Ces travers sont exactement ceux qu’on retrouve dans l’anatomie d’un PoC qui ne passe jamais. Lorsqu’il faut reprendre un système déjà en place, un audit IA commence souvent par reconstituer ce jeu de tests manquant.

Une réponse difficile à vérifier automatiquement peut être évaluée par une grille métier et une relecture humaine, dont la durée et la reproductibilité doivent être mesurées.

Automatisez les contrôles objectifs : document cité, champ obligatoire, refus attendu. Pour une synthèse, définissez les faits indispensables et les omissions qui changeraient la décision. Faites relire certains cas par deux personnes afin d’identifier les critères ambigus.

Le cadre volontaire du NIST, publié en 2023, relie la gestion des risques au cycle de vie. Lecture complémentaire sur l’entretien : ce qui occupe l’équipe la deuxième année.