Définition
L’évaluation IA consiste à tester un système probabiliste sur un ensemble d’exemples réels dont on connaît les bonnes réponses, à noter les résultats, et à suivre cette note à mesure que les instructions, les modèles et les données changent.
Pourquoi « ça a l’air de marcher » n’est pas une mesure
Le logiciel classique se teste en affirmant qu’une entrée connue produit une sortie connue. On exécute le test, on obtient réussite ou échec. Cela ne se transpose pas à l’IA : une même entrée peut produire des formulations différentes, toutes deux possiblement justes, ou dont l’une est subtilement, coûteusement fausse.
On évalue donc les systèmes d’IA comme on évalue des élèves : un ensemble de questions dont on connaît les bonnes réponses, une grille de correction, et une note qu’on suit dans le temps. Sans cela, impossible de répondre aux deux questions qui comptent. Est-ce assez bon pour être déployé ? Et le changement que nous venons de faire a-t-il amélioré les choses ou brisé quelque chose en silence ?
C’est la seconde qui piège les équipes. Une modification d’instruction n’est pas locale. Réécrire une consigne pour corriger une catégorie d’erreur en dégrade régulièrement une autre, et sans évaluation personne ne l’apprend avant un client.
Quoi mesurer réellement
La mesure dépend de la tâche, et choisir la mauvaise produit un système qui obtient une bonne note et performe mal.
| Tâche | Ce qu’il faut mesurer |
|---|---|
| Extraction | Exactitude par champ, et signalement des erreurs |
| Classification | Précision et rappel par classe, pas l’exactitude globale |
| Récupération (RAG) | Le bon passage est-il seulement revenu |
| Résumé | Fidélité à la source, couverture des points clés |
| Agents | Tâche complétée, et comportement en cas d’échec |
Deux mesures transversales comptent quelle que soit la tâche. L’étalonnage : quand le système doute, le dit-il ? Un modèle exact à 90 % qui sait lesquels des 10 % lui échappent vaut bien mieux qu’un modèle à 93 % uniformément assuré. Le mode d’échec : quand il se trompe, est-ce visiblement faux ou plausiblement faux ? Les erreurs plausibles sont les coûteuses.
Constituer un jeu d’évaluation qui vaut la peine
Prenez de vrais cas tirés de votre travail réel, pas des exemples inventés. Incluez délibérément les cas gênants : la demande ambiguë, le document mal numérisé, le client qui pose trois questions dans une phrase, le dossier sur lequel votre meilleure personne a dû réfléchir. Un jeu composé uniquement de cas faciles vous dira que votre système est excellent, jusqu’à ce qu’il rencontre un mardi ordinaire.
Cinquante à deux cents cas bien choisis suffisent généralement à détecter les régressions. Faites définir la bonne réponse par une personne qui connaît le métier, et notez pourquoi elle est bonne : ce raisonnement est ce qui permettra à quelqu’un d’autre de corriger de façon cohérente six mois plus tard.
Puis exécutez le jeu à chaque changement. Un jeu d’évaluation qui n’est pas lancé automatiquement cesse d’être lancé.
L’approche Automathing
Nous constituons le jeu d’évaluation avant le système, à partir de vrais cas fournis par le client, et nous traitons la première note comme la base honnête plutôt que comme une gêne. Chaque changement d’instruction, de modèle ou de récupération est mesuré contre elle. Un changement qui ne démontre pas une amélioration ne part pas en production. Et si la note indique que le système n’est pas assez bon pour un usage sans surveillance, nous le disons clairement au lieu de le livrer avec un avertissement.
Foire aux questions
Quel niveau d’exactitude un système d’IA doit-il atteindre ?
Il n’existe pas de seuil universel : cela dépend du coût d’une erreur et de votre capacité à la détecter. Un système exact à 85 % qui signale ses cas incertains pour révision peut être parfaitement sûr. Un système à 97 % qui agit en silence sur les 3 % restants peut ne pas l’être. Concevez d’abord le parcours de révision, puis demandez quelle exactitude rend ce parcours abordable.
Peut-on se fier aux scores publiés pour les modèles ?
Ils vous apprennent très peu sur votre cas. Les bancs d’essai publics mesurent une capacité générale sur des tâches normalisées ; la performance de votre système dépend de vos documents, de votre terminologie, de vos cas limites et de l’ingénierie environnante. Un modèle en tête d’un banc d’essai peut être dépassé par un plus petit sur votre travail précis.
À quelle fréquence exécuter l’évaluation ?
À chaque changement d’instruction, de modèle, de dispositif de récupération ou de données : c’est ce qui attrape les régressions. Au-delà, périodiquement sur des cas de production frais, car le monde dérive : nouveaux produits, nouvelles formulations, nouveaux formats de documents. Un système mesuré une fois au lancement et jamais depuis n’est pas mesuré.
Qui devrait définir les bonnes réponses ?
La personne qui fait le travail aujourd’hui, pas l’équipe qui construit le système. Les constructeurs corrigent inconsciemment vers ce que le système produit. C’est au responsable du résultat de définir ce que « juste » veut dire et d’arbitrer les désaccords, puisque son jugement est la norme que le système cherche à atteindre.