Vous avez plusieurs milliers d’articles à classer, des catégories métier et un traitement qui fonctionne déjà plutôt bien. Un nouveau modèle arrive. Il promet un coût plus bas ou des réponses plus rapides. La difficulté commence au moment de décider s’il peut remplacer le précédent sans dégrader les résultats utiles.
Dans notre article sur Jev de TypeSafe AI, j’évoquais un cas de 10 000 articles à classifier sur plusieurs thèmes, avec un golden dataset et plusieurs LLM déjà essayés. Jev reste une piste à tester sur ce cas. Cet article ne présente aucun résultat de comparaison entre Jev et ces LLM. Il propose une méthode pour mener cette comparaison correctement.
Le principe : définir les réponses attendues, comparer les configurations sur les mêmes documents et mesurer ce qui reste à traiter par une personne. Un tarif par appel et quelques exemples convaincants ne suffisent pas pour prendre une décision de migration.
Qu’est-ce qu’un golden dataset pour la classification de texte ?
Un golden dataset est un jeu de référence dont les réponses ont été annotées puis vérifiées selon des règles explicites. Pour classifier des textes, chaque ligne associe un document, un identifiant et les catégories attendues. Votre programme compare ensuite les sorties du modèle à ces réponses.
Ce jeu ne sert pas nécessairement à entraîner un modèle. Il peut évaluer un LLM utilisé avec un prompt, un modèle spécialisé comme Jev, un classifieur entraîné en interne ou même des règles déterministes. Ce qui compte est de tester le traitement réellement envisagé pour la production.
Le mot « golden » ne garantit pas que les annotations soient parfaites. Une catégorie mal définie, un désaccord non arbitré ou un échantillon composé uniquement de cas faciles rendent la référence fragile. Il faut conserver sa version, ses règles et ses limites.
Prenons un exemple fictif : « Tester la qualité des tables qui alimentent un modèle de prévision ». Avec notre taxonomie pédagogique, le texte reçoit data et IA. Il s’agit d’une classification multilabel : plusieurs étiquettes peuvent être correctes simultanément. Un choix unique forcé ne répondrait pas au même besoin.
Avec un LLM ou avec Jev, la référence reste la même
Un LLM peut recevoir le texte et la définition des thèmes, puis produire une liste structurée. Avec Jev, on peut formuler une question indépendante par thème et exploiter les valeurs renvoyées pour décider des étiquettes. TypeSafe présente cette approche comme une évaluation spécialisée, distincte de la génération libre. Présentation de System One.
Les interfaces diffèrent, mais le résultat métier peut être ramené au même format : identifiant du document, liste de thèmes, statut du traitement. Une petite couche d’adaptation suffit alors pour alimenter un évaluateur commun.
Comparer des configurations complètes évite une fausse équivalence : modèle, version, consignes, contexte transmis, découpage des textes longs et règles de décision. Donnez aux deux candidats le même contenu utile et les mêmes définitions. Chacun peut avoir une intégration adaptée, développée sur des données distinctes du test final.
Conservez aussi une référence simple quand elle est crédible : règles existantes ou petit classifieur. Le choix ne se limite pas aux deux dernières API disponibles. Pour un nouveau projet, ce protocole aide à choisir. Pour un workflow installé, il doit aussi justifier le travail de migration.
Construire une référence qui représente votre besoin
1. Écrire les règles d’annotation avant de multiplier les exemples
Pour chaque thème, décrivez ce qui entre dans la catégorie, ce qui en sort et quelques cas limites. Dans notre exemple, citer le mot « données » ne suffit pas à recevoir l’étiquette data : le texte doit traiter substantiellement de stockage, de qualité, de modélisation ou de circulation des données.
Définissez aussi la différence entre aucun thème applicable, document incomplet et désaccord à arbitrer. Une liste vide peut être une réponse parfaitement correcte. Elle ne doit pas servir à masquer une annotation manquante.
Faites annoter indépendamment un premier lot par deux personnes qui connaissent le besoin. Relisez les désaccords, modifiez les règles et réannotez les cas concernés. L’objectif est d’obtenir une décision explicable avant de reprocher au modèle de ne pas la retrouver. Un LLM peut proposer des préannotations ; sa sortie seule ne constitue pas une référence validée.
2. Séparer le flux courant des cas difficiles
Prélevez des documents dans le flux réel : sources différentes, textes longs et courts, périodes pertinentes, langues effectivement rencontrées. Gardez un échantillon représentatif pour estimer les performances attendues sur ce flux.
Ajoutez séparément un lot de cas difficiles : thème rare, plusieurs thèmes, vocabulaire ambigu, texte sans catégorie pertinente. Si vous surreprésentez ces cas, ne présentez pas la moyenne du lot comme une estimation de votre trafic habituel. Rapportez les deux résultats et les effectifs par thème.
Il n’existe pas de taille universelle suffisante. Un thème présent dans trois documents ne permet pas une décision solide, même si les trois sont bien classés. Dimensionnez le test selon les erreurs que vous devez détecter et l’incertitude acceptable. Pour une décision importante, estimez cette incertitude, en respectant les groupes de documents liés dans le rééchantillonnage.
3. Réserver le test final
Séparez les documents utilisés pour écrire les prompts, ceux qui servent à choisir les seuils et ceux qui servent au test final. Regroupez les doublons et versions d’un même article dans un seul ensemble. Pour prédire un futur flux, une séparation temporelle peut être plus pertinente qu’un tirage aléatoire.
La documentation scikit-learn explique pourquoi l’utilisation des données de test pendant les réglages produit une estimation trop optimiste, et propose des séparations par groupe. Appliquez ce principe aussi aux exemples fournis dans un prompt. Fuite de données et validation par groupes.
Une fois le test examiné, ses erreurs peuvent enrichir le développement suivant. Il faut alors une nouvelle référence réservée pour confirmer les améliorations, plutôt que d’optimiser indéfiniment sur le même examen.
Mesurer les erreurs et la part réellement automatisée
Pour chaque thème, la précision indique quelle part des étiquettes proposées est correcte ; le rappel, quelle part des documents réellement concernés est retrouvée. Le F1 combine les deux. Conservez les effectifs derrière ces ratios. Les formules et leurs cas indéfinis sont documentés dans scikit-learn.
En multilabel, regardez aussi la liste complète : a-t-on trouvé tous les thèmes, sans en ajouter ? C’est l’exact match, appelé subset accuracy dans la documentation. Un document avec deux thèmes dont un seul est retrouvé échoue à ce contrôle strict.
Ajoutez trois indicateurs opérationnels :
- La couverture automatique : documents ayant reçu une décision exploitable, divisés par tous les documents attendus.
- Les documents entièrement justes et automatisés : correspondances exactes rapportées au lot complet.
- Les cas non traités : abstentions, erreurs techniques et résultats absents, comptés séparément.
Un modèle qui évite les documents difficiles peut améliorer ses scores sur les seules décisions rendues. Cela ne dit pas combien de travail il laisse à l’équipe. Comparez les candidats à couverture similaire lorsque c’est possible, avec leurs résultats par catégorie et la capacité réelle de revue humaine.
Un score élevé ne fixe pas tout seul un seuil
Ne traitez pas automatiquement un score de 0,9 comme une certitude de 90 %. Cette interprétation dépend de sa calibration sur des données pertinentes. Un score déclaré par un LLM et une probabilité calculée par un classifieur ne sont pas interchangeables. Calibration des probabilités.
Choisissez les seuils sur le lot de réglage, selon les erreurs acceptables pour chaque thème. Vous pouvez prévoir une zone d’abstention, voire des seuils différents par catégorie. Figez cette politique avant le test final. Le tutoriel ci-dessous évalue des décisions déjà prises ; il ne choisit pas les seuils à votre place.
Trois applications concrètes pour une équipe data et IA
Classer un fonds documentaire. Les entrées sont des articles complets, les sorties plusieurs thèmes pour la recherche et la veille interne. Contrôlez surtout les thèmes oubliés et les erreurs de découpage des textes longs. Le critère de réussite associe rappel par thème et volume de documents à revoir. C’est le prolongement naturel du cas des 10 000 articles.
Analyser les avis clients. Un avis peut féliciter le produit et critiquer la livraison. Séparez les thèmes du sentiment, et annotez les deux dimensions si vous les utilisez. Sinon, une bonne détection de « livraison » peut cacher une mauvaise lecture de ce que le client en dit. Vérifiez les avis mixtes et la stabilité des agrégats utilisés par les équipes métier.
Orienter les tickets de support. Le service destinataire peut être un choix unique, tandis que les motifs restent multiples. Évaluez ces sorties séparément. Une mauvaise affectation crée une réassignation et du délai ; une abstention crée une revue. Le bon indicateur associe qualité du routage et charge supplémentaire, pas seulement le nombre de tickets traités par l’API.
Tutoriel : comparer deux sorties de classification en local
L’atelier contient douze courts textes fictifs et deux séries de prédictions fabriquées pour montrer les calculs. Le script a été exécuté localement. Aucun appel à Jev ou à un LLM n’a été effectué ; les résultats ne sont pas un benchmark de modèles.
Étape 1 : récupérer les fichiers
Prérequis : Python 3.10 ou plus récent. Aucune bibliothèque externe, clé API ou donnée client n’est nécessaire. Téléchargez dans un même dossier :
La référence contient id, group_id, split, texte et labels. Toutes ses lignes appartiennent au test pédagogique ; elle ne démontre pas une vraie séparation développement/test.
Les prédictions utilisent trois colonnes :
id,status,labels
a01,ok,data
a04,ok,data|ia
a11,abstain,
ok signifie qu’une décision a été rendue, pas qu’elle est correcte. abstain signifie absence volontaire de décision ; error, échec technique ou sortie inutilisable. Une ligne absente est détectée comme missing. Avec ok, une cellule d’étiquettes vide signifie « aucun de ces thèmes ».
Étape 2 : exécuter la comparaison
Ouvrez un terminal dans le dossier des fichiers :
python3 evaluer.py reference.csv predictions-a.csv > resultat-a.json
python3 evaluer.py reference.csv predictions-b.csv > resultat-b.json
Le script refuse les identifiants dupliqués, les prédictions hors corpus, les étiquettes inconnues et les statuts incohérents. Une valeur indéfinie reste null. Les résultats sont enregistrés dans les deux fichiers JSON.
Étape 3 : interpréter les résultats attendus
La série A traite automatiquement 10 documents sur 12, dont 7 ont exactement les bons thèmes. Sa couverture est donc de 83,3 %, et son exactitude sur les seules décisions automatiques de 70 %.
La série B traite 9 documents sur 12, tous exacts. Elle affiche 100 % d’exactitude sur ce sous-ensemble, mais seulement 75 % de couverture. Elle comporte deux abstentions et une ligne volontairement manquante. Ces trois documents restent dans le dénominateur du lot.
Ces chiffres servent à vérifier le script, pas à déclarer B meilleur en production. Les deux configurations ne répondent pas sur les mêmes documents. Il faut examiner les cas laissés à l’équipe, les catégories concernées et le coût de leur reprise.
Dans le JSON, by_label_auto donne précision, rappel et F1 sur les documents ok. support_auto indique combien de références positives sont dans ce sous-ensemble ; support_total les compte sur tout le lot. exact_auto_over_total mesure les documents entièrement justes et automatisés sur l’ensemble attendu. Ce dernier ratio ne représente pas la qualité après correction humaine.
Étape 4 : passer à votre corpus
Utilisez le gabarit d’annotation pour conserver les deux avis, l’arbitrage et sa raison. Exportez les réponses arbitrées du test dans une référence séparée. Donnez aux modèles les textes et les consignes, jamais les étiquettes attendues.
Exportez ensuite chaque exécution dans le format commun. Conservez versions du modèle, du prompt et de la taxonomie, empreinte du corpus et date d’exécution. Pour les systèmes variables, répétez sur un budget défini et rapportez la variabilité, sans sélectionner uniquement la meilleure tentative.
Le script vérifie les imports et calcule les métriques. Il ne valide ni la représentativité, ni les annotations, ni l’absence de fuite entre vos lots. Après l’essai, archivez les résultats puis supprimez le dossier local si vous n’en avez plus besoin.
Décider si le changement vaut son coût
Renseignez le gabarit de coût avec les montants réellement facturés et le temps de revue. Une cellule vide signifie inconnu. Additionnez inférence, reprises facturées, revue humaine et effort d’intégration amorti sur le volume prévu. Comparez à devise, périmètre et période identiques, en intégrant les remises dont bénéficie déjà votre solution.
Fixez avant le test les conditions de passage : qualité minimale sur les catégories importantes, couverture compatible avec l’équipe, coût total acceptable et absence de régression critique. Si le seul gain est une petite économie d’API, le changement peut ne pas compenser la migration et la maintenance supplémentaire.
Pour les nouveaux flux, cette méthode permet de choisir dès le départ entre règles, modèle spécialisé, LLM ou combinaison des trois. Pour un flux existant, commencez par une exécution parallèle sans remplacer ses résultats, puis un périmètre limité avec retour arrière possible. Continuez ensuite à revoir des échantillons, y compris parmi les décisions automatiques.
Le livrable utile est une décision argumentée : quelle configuration retenir, sur quels documents, avec quelles erreurs connues et quelle charge restante. Le golden dataset rend cette décision vérifiable.
