Évaluations de classification

Pourquoi la classification est un cas privilégié

La classification est l’un des cas d’usage les plus courants et les plus faciles à évaluer. La sortie attendue est une catégorie prise dans un ensemble fini — BUG ou FACTURATION, POSITIF ou NÉGATIF, urgent ou non urgent — ce qui rend la notation programmatique triviale : il suffit de comparer une chaîne à une autre. Là où l’évaluation d’un résumé demande du jugement, celle d’un classificateur se résume à compter les bonnes réponses.

Cette simplicité apparente cache pourtant les questions les plus intéressantes du métier. Savoir qu’un classificateur atteint 84 % ne vous dit ni quelles catégories il rate, ni pourquoi. C’est en décomposant le score qu’on apprend quelque chose.

Trois niveaux de mesure

La précision globale, ou accuracy, est le point de départ : le pourcentage de prédictions correctes sur l’ensemble du jeu de test.

accuracy = correct_predictions / total_predictions

Ce chiffre unique a un défaut connu. Si 80 % de vos tickets relèvent de la catégorie QUESTION, un modèle qui répondrait « QUESTION » à tout afficherait 80 % de précision tout en étant parfaitement inutile. D’où le deuxième niveau : la précision par classe. Certaines catégories sont intrinsèquement plus difficiles que d’autres, et il faut mesurer chacune séparément.

from collections import defaultdict

class_correct = defaultdict(int)
class_total = defaultdict(int)

for test in test_cases:
    # ... exécuter le modèle ...
    class_total[test["expected"]] += 1
    if output == test["expected"]:
        class_correct[test["expected"]] += 1

for cls in class_total:
    print(f"{cls}: {class_correct[cls]}/{class_total[cls]}")

La sortie de cette boucle révèle immédiatement le déséquilibre : vous découvrez par exemple que FACTURATION est reconnue neuf fois sur dix mais que FEATURE ne l’est qu’une fois sur deux, ce qui oriente très précisément votre travail sur le prompt.

Reste à comprendre comment le modèle se trompe, c’est-à-dire quelle classe il confond avec quelle autre. C’est le rôle de la matrice de confusion.

from collections import defaultdict

confusion = defaultdict(lambda: defaultdict(int))
for test in test_cases:
    # ... exécuter le modèle ...
    confusion[test["expected"]][output] += 1

Cette structure vous apprend, par exemple, que les demandes de fonctionnalité mal classées finissent presque toutes en QUESTION. L’information est actionnable : le problème n’est pas que le modèle ne comprend pas FEATURE, c’est que la frontière entre les deux définitions est floue dans votre prompt.

Les erreurs qui reviennent toujours

Trois pièges expliquent la majorité des scores anormalement bas, et aucun ne concerne réellement les capacités du modèle. Le premier est l’extraction du label : Claude peut entourer la catégorie de texte superflu — « Ce ticket relève de la catégorie BUG. » — et votre comparaison exacte échoue sur une réponse pourtant juste. Une regex ou un prefill règlent le problème en extrayant proprement l’étiquette. Le deuxième est celui des labels proches : « POSITIF », « Positif » et « positif » désignent la même chose pour un humain et trois valeurs différentes pour Python. Normalisez systématiquement avant de comparer. Le troisième tient aux classes ambiguës : certains cas sont légitimement à cheval sur deux catégories, et pénaliser le modèle sur ces exemples ne mesure rien d’utile. Acceptez alors plusieurs réponses valides pour ces cas précis.

Remonter le score

Quand la précision reste insuffisante après avoir écarté ces trois causes, quatre leviers restent disponibles, et il vaut mieux les actionner en commençant par le moins coûteux.

Ajoutez d’abord des exemples (few-shot) pour les classes problématiques : deux ou trois exemples bien choisis de la catégorie qui échoue suffisent souvent à débloquer la situation, pour un temps de rédaction dérisoire. Clarifiez ensuite les définitions de chaque classe dans le prompt, et c’est là que la matrice de confusion se révèle précieuse, puisqu’elle a déjà désigné la frontière exacte qu’il faut expliciter. Si les cas subtils résistent encore, ajoutez un champ « raisonnement » qui oblige Claude à réfléchir avant de classifier : le modèle justifie avant de trancher, au prix de quelques tokens supplémentaires. Subdiviser les classes ambiguës vient en dernier, car c’est le geste le plus lourd — il oblige à réétiqueter le jeu de test et ne se justifie que lorsqu’une catégorie recouvre en réalité deux réalités métier distinctes.

Un jeu de test qui tient debout

La fiabilité de tout ce qui précède dépend de la qualité du jeu de test. Comptez au moins vingt à trente exemples par classe : en dessous, une seule erreur fait bouger le score par classe de plusieurs points et vous poursuivez du bruit. Incluez les cas limites et ambigus plutôt que de les écarter, puisque ce sont eux que la production vous enverra. Faites valider les étiquettes par plusieurs annotateurs quand c’est possible : si deux collègues ne s’accordent pas sur la bonne catégorie, aucun prompt ne trouvera la réponse « juste ». Enfin, mettez le jeu de test à jour dès que de nouvelles catégories apparaissent : un jeu figé note une taxonomie que votre produit a déjà abandonnée.

Points clés à retenir

• La sortie d’un classificateur étant une catégorie parmi un ensemble fini, la notation par code y est immédiate.
• La précision globale masque les déséquilibres : mesurez toujours la précision par classe.
• La matrice de confusion indique quelle catégorie est prise pour quelle autre, et donc quelle définition clarifier.
• Extraction du label, variations de casse et cas légitimement ambigus expliquent la plupart des faux échecs.
• Visez vingt à trente exemples par classe, cas limites inclus, et faites évoluer le jeu de test avec le produit.