Construire une taxonomie des modes d'échec avant de choisir vos métriques d'eval

En bref

• Le problème : beaucoup d'équipes choisissent des métriques génériques ("utilité", "qualité") avant même de savoir comment leur feature IA échoue concrètement.
• L'idée clé : lire ses propres sorties pour en faire émerger une taxonomie d'échecs, puis traduire chaque catégorie en axe de rubrique mesurable.
• Ce que vous pouvez réutiliser : une procédure de session d'analyse et une grille catégorie d'erreur vers axe d'eval vers décision.

Pourquoi commencer par les échecs, pas par les métriques

Quand on déploie une feature IA, la tentation est d'attraper une métrique toute faite et de la brancher. Le problème, c'est qu'une métrique générique mesure une idée de la qualité, pas la façon dont votre application échoue. La documentation d'eval de Langfuse formule la règle simplement : faire l'analyse d'erreurs avant de concevoir les évaluateurs, pour que ce soient les traces réelles qui définissent quoi mesurer, et non un critère générique comme "helpfulness".

Cette inversion n'est pas un détail méthodologique. Une analyse de 83 modèles sur 35 jeux de données, publiée sous le nom ErrorAtlas, montre que plus de 40 % des erreurs sur des benchmarks de raisonnement réputés (MMLU-Pro, Omni-MATH, GPQA) viennent de problèmes techniques comme des violations de format ou des omissions, pas d'un raisonnement déficient. Autrement dit, une métrique d'exactitude globale agrège des échecs de natures très différentes et masque ce qui casse vraiment. On ne peut pas corriger ce qu'on n'a pas nommé.

Construire une taxonomie des modes d'échec, c'est donc poser la question "quoi mesurer ?" avant la question "comment mesurer ?". L'ordre compte : la taxonomie devient la liste des axes que vos évaluateurs surveilleront ensuite.

La démarche en quatre étapes

La construction d'une taxonomie tient dans une session de revue structurée, pas dans un projet de plusieurs semaines. Le processus décrit par Hamel Husain emprunte ses étapes à la recherche qualitative.

Voici comment chaque étape fonctionne.

1. Rassembler les traces. On part d'un échantillon représentatif de sorties réelles ou de logs. La règle empirique est de viser au moins 100 traces pour commencer.
2. Open coding. Un annotateur humain, idéalement un expert du domaine, lit chaque trace et écrit une note libre sur le premier échec observé, sans catégorie prédéfinie. On laisse les défaillances se nommer elles-mêmes.
3. Axial coding. On regroupe ensuite ces notes en catégories distinctes, et on compte le nombre de cas par catégorie. Un LLM peut aider à proposer un premier regroupement, mais la validation des libellés reste humaine.
4. Décider. Pour chaque catégorie, on tranche : ce qui se corrige par un changement de prompt ou un bug fix, et ce qui devient un évaluateur permanent.

Le critère d'arrêt s'appelle la saturation : on continue d'examiner des traces tant qu'elles révèlent de nouvelles catégories. L'heuristique proposée est de s'arrêter quand environ 20 traces consécutives n'ajoutent plus rien, après avoir revu au moins 100 cas. L'objectif n'est pas d'attraper chaque échec possible, mais de prioriser ceux qui surviennent le plus souvent.

Des catégories d'erreur aux axes de rubrique

Une taxonomie n'a de valeur que si elle se traduit en évaluation. C'est la bascule centrale : comme le note la démarche Langfuse citée plus haut, les catégories corrigeables directement deviennent des mises à jour de prompt ou des correctifs, tandis que les autres deviennent des évaluateurs appliqués aux futures traces.

Reste à transformer une catégorie en rubrique exploitable. Le guide de Galtea sur les juges LLM identifie les quatre critères dont la plupart des pipelines ont besoin en premier : fidélité au contexte (faithfulness), pertinence (relevance), conformité de format et justesse des appels d'outils pour les agents. Le passage de la catégorie à l'axe obéit à trois règles concrètes.

D'abord, définir le critère dans le vocabulaire du métier. "La réponse est de haute qualité" n'est pas une définition : c'est un espace vide que le juge remplira avec ses propres a priori. Un axe utile décrit la procédure qu'un évaluateur humain suivrait pour trancher.

Ensuite, une rubrique par dimension. Un même prompt qui note la fidélité, la pertinence et le format en une passe produit des scores corrélés, et on perd la capacité d'attribuer une régression à une dimension précise.

Enfin, savoir quand l'eval LLM n'est pas le bon outil. Si la sortie doit être un JSON valide contre un schéma, un contrôle déterministe avec pydantic ou jsonschema est plus fiable et moins coûteux qu'un juge. On réserve le juge aux cas que le schéma ne peut pas trancher.

Des taxonomies par cas d'usage

La même méthode produit des taxonomies différentes selon la feature. Deux cas sont bien documentés dans la littérature d'eval.

Génération de code. ErrorAtlas, cité plus haut, couvre explicitement la génération de code (jeux HumanEval et MBPP) parmi ses 17 catégories de haut niveau. Les plus fréquentes, tous domaines confondus, sont l'élément requis manquant (15,56 %), la mauvaise interprétation de la spécification (11,50 %), l'erreur de raisonnement logique (9,09 %), l'identification incorrecte (8,98 %) et l'erreur de calcul (8,45 %). Pour du code, une catégorie d'échec ne se limite pas à "ça compile ou pas". L'exemple donné par Planit est parlant : une fonction de paiement qui compile et passe ses tests unitaires, mais qui journalise les numéros de carte en clair et viole ainsi PCI DSS. Le modèle n'a pas halluciné, il a ignoré une contrainte métier. C'est une catégorie à part entière dans une taxonomie de code.

Applications RAG et agents. Planit propose une lecture architecturale en quatre couches : la génération (ce que le modèle produit), l'information (ce qu'il consomme via le retrieval), l'interaction (l'orchestration et les appels d'outils), et l'interprétation (la façon dont l'humain agit sur la sortie). Cette grille aide à localiser un échec : une réponse fausse peut venir d'un document mal récupéré (couche information) autant que du modèle lui-même (couche génération). Les quatre critères de Galtea se cartographient directement sur ces couches.

Pour le résumé et la traduction, le carnet de sources ne fournit pas de taxonomie dédiée. La démarche reste identique, mais les catégories doivent émerger de vos propres traces plutôt que d'être copiées d'un modèle générique.

Points de vigilance

La granularité de l'échelle. Il est tentant de noter de 1 à 5 pour avoir de la finesse. Le guide Galtea cité plus haut rappelle qu'un juge binaire s'aligne plus fidèlement sur les humains qu'un juge à 5 points sur la même tâche, comme l'a montré MT-Bench. Une échelle trop fine invite le juge à inventer des distinctions qu'il ne sait pas défendre. On choisit l'échelle la moins précise qui capture quand même la distinction qui compte.

Le biais de longueur. Sans clause explicite de neutralité, un juge favorise les réponses plus longues. Tout critère de "complétude" ou de "profondeur" a besoin d'une borne haute, sinon la longueur devient un proxy involontaire de la qualité.

La taxonomie n'est jamais finie. Deux raisons. D'une part, la démarche Langfuse rappelle qu'il faut relancer l'analyse à chaque évolution de l'application, car les distributions d'échecs se déplacent. D'autre part, une étude sur la dérive des critères (Shankar et al., 2024) montre que les évaluateurs humains révisent leurs critères après avoir vu les sorties : une rubrique écrite en amont est une hypothèse, pas un livrable définitif.

La propagation. Planit, cité plus haut, observe que les défaillances remontent les couches : plus on monte vers l'interprétation humaine, moins l'échec est visible et plus son impact métier est élevé. Une taxonomie qui ne regarde que la couche modèle laisse passer les échecs les plus coûteux.

Ce que vous pouvez réutiliser

Avant d'écrire la moindre métrique, faites tourner cette grille sur 100 sorties réelles.

1. Quel est le premier échec visible dans cette trace, formulé en une phrase, sans catégorie imposée ?
2. À quelle couche appartient-il : génération, information, interaction, interprétation ?
3. Cette catégorie se corrige-t-elle par un changement de prompt, ou doit-elle devenir un évaluateur permanent ?
4. Quel axe mesurable et quel verdict (binaire de préférence) traduisent cette catégorie ?
5. Un contrôle déterministe suffirait-il, rendant le juge LLM inutile ici ?

La taxonomie obtenue n'est pas un livrable de plus : c'est la spécification de vos évaluateurs. Tant qu'elle n'existe pas, les métriques mesurent une qualité supposée plutôt que les échecs réels de votre feature.