Un jeu de données versionné

Une PR change le prompt de tri, et, « tant qu'on y est », corrige trois priorités attendues que le relecteur jugeait fausses. Le score de priorité passe de 0,80 à 0,93. Personne ne peut dire quelle part vient du prompt et quelle part vient des étiquettes. Un jeu de données qui bouge en même temps que le système qu'il mesure ne mesure plus rien.

Le mécanisme : un cas, une empreinte, un manifeste

Un cas est une ligne JSON : un identifiant stable, l'entrée passée à la cible, les valeurs attendues et des étiquettes libres pour filtrer le rapport.

{"id": "T19",
 "input": {"ticket": "J'ai deux commandes, CMD-121100 et CMD-121101, seule la première est concernée : il manque un article dans le colis."},
 "expected": {"categorie": "livraison", "priorite": "normale", "numero_commande": "CMD-121100",
              "montant_eur": null, "reference_reponse": "Bonjour, merci de nous indiquer l'article manquant..."},
 "tags": ["deux-numeros"]}

L'empreinte du jeu est un SHA-256 calculé sur le JSON canonique de chaque cas (clés triées, sans espaces), cas triés par identifiant. Reformater le fichier ou réordonner les lignes ne la change pas ; modifier un seul caractère d'une valeur attendue, si.

def canonical(obj: Any) -> str:
    return json.dumps(obj, sort_keys=True, ensure_ascii=False, separators=(",", ":"))

def fingerprint(cases: list[Case]) -> str:
    return sha256("\n".join(canonical(c.raw) for c in sorted(cases, key=lambda c: c.id)))

Le manifeste data/MANIFEST.json enregistre l'empreinte attendue de chaque fichier. Le runner refuse un jeu qui ne correspond pas à son manifeste, et la comparaison refuse deux exécutions faites sur des empreintes différentes.

flowchart LR
  I["Incident ou ticket réel"] --> AN["Anonymisation"]
  AN --> C["Nouveau cas + étiquettes"]
  C --> M["make dataset-hash"]
  M --> PR1["PR dédiée au jeu de données, relue par le métier"]
  PR1 --> MAIN["main : nouvelle référence"]
  MAIN --> PR2["PR de prompt ou de modèle, comparée sur ce jeu"]

La mise en œuvre : 30 cas qui discriminent

Trente tickets faciles ne servent à rien : les deux modèles les réussissent tous. Le jeu du projet (tickets.jsonl) répartit les 6 catégories et place volontairement des pièges, chacun étiqueté :

Chaque cas porte aussi une reference_reponse, utilisée par le scorer de similarité (leçon 2.3). Le jeu de l'agent (trajectoires.jsonl, 8 cas) et celui de calibration du juge (calibration_juge.jsonl, 22 réponses annotées) suivent le même format.

make dataset-hash

Résultat obtenu (2026-10-15)

tickets.jsonl : 30 cas, sha256 d4812b340335
trajectoires.jsonl : 8 cas, sha256 5c7e9a942ce0
calibration_juge.jsonl : 22 cas, sha256 6981f1831c2d

Modifiez une seule priorité attendue (T30, normale devient basse) sans régénérer le manifeste :

$ .venv/bin/python -m evalh dataset-hash --check data/tickets.jsonl
Erreur : tickets.jsonl a changé sans mise à jour du manifeste (attendu d4812b340335, obtenu 1774b7b8dc03). Lancez : make dataset-hash
exit=2

make test échoue aussi (3 tests), ce qui empêche la modification d'arriver discrètement dans une PR.

Ce qui casse en production

• Étiquettes ambiguës. Sur les 4 erreurs de priorité de gemini-3.8-flash (T16, T23, T24, T26), le modèle répond basse là où l'étiquette dit normale. Pour T24 (« reçu il y a 45 jours, c'est encore possible ? »), basse se défend. Avant d'accuser le modèle, faites étiqueter 20 cas par une seconde personne et mesurez leur accord (le kappa de la leçon 2.3) : si deux humains ne s'accordent pas, aucun modèle ne fera mieux que ce plafond.
• Saturation. Dans la démonstration, commande, montant et contrat_json valent 1,000 pour les deux modèles. Ces métriques protègent contre une régression, mais ne départagent plus rien. Ajoutez des cas plus durs dès qu'une métrique sature sur toutes les versions.
• Surapprentissage du prompt. Si vous ajustez le prompt en regardant les échecs du jeu, le jeu devient un jeu d'entraînement. Gardez 20 à 30 % des cas hors de vue (un second fichier que seule la CI exécute).
• Données personnelles. Un ticket réel copié tel quel dans un dépôt Git, c'est une donnée personnelle conservée sans base légale. Anonymisez (noms, adresses, e-mails, numéros réels) avant l'ajout, et gardez la trace de l'origine dans tags, pas le contenu.

La règle de décision

Un jeu de données change dans une PR qui ne change que lui. Il contient au moins 5 cas par catégorie importante et au moins un cas par incident connu. Sa taille se calcule à partir de l'écart que vous voulez détecter (leçon 3.1) : 30 cas suffisent pour voir une chute de 20 points, pas une chute de 5. Surveillez la part de métriques saturées à 1,000 sur les deux versions : au-delà de la moitié, le jeu est trop facile.

Pratique

Exercice. Ajoutez un cas T31 : un client écrit en majuscules et cite un montant de 1 250 € pour un cadre carbone fissuré, sans numéro de commande. Donnez la ligne JSONL et la commande qui rend make test de nouveau vert.

{"id": "T31", "input": {"ticket": "MON CADRE CARBONE À 1 250 € EST FISSURÉ APRÈS UNE SEMAINE, C'EST INADMISSIBLE"}, "expected": {"categorie": "produit_technique", "priorite": "haute", "numero_commande": null, "montant_eur": 1250, "reference_reponse": "Bonjour, ne roulez pas avec ce cadre. Envoyez-nous des photos de la fissure et votre numéro de commande : nous traitons votre dossier en priorité."}, "tags": ["securite", "montant-eleve", "majuscules"]}

• Je sais pourquoi l'empreinte est calculée sur du JSON canonique trié par identifiant.
• Je modifie le jeu de données dans une PR séparée, puis je régénère le manifeste.
• Je sais repérer une métrique saturée et une étiquette ambiguë.
• J'anonymise un ticket réel avant de l'ajouter.