Construire un jeu de test

Pourquoi un jeu de test ?

Un système à base de modèle de langage ne se teste pas comme une fonction classique : la même question peut recevoir des formulations différentes, et un changement de prompt qui améliore un cas peut en dégrader dix autres. Essayer trois questions à la main avant de mettre en production donne une impression trompeuse de qualité.

La base de toute évaluation est un jeu de test (on parle aussi de golden dataset) : une liste versionnée de cas, chacun avec une entrée et ce qui est attendu. Il joue pour l’IA le rôle des tests unitaires pour le code.

Structure d’un cas

CASES = [
    {"id": "T01", "categorie": "frequent", "input": "Où est ma facture de mars ?", "expected": "facturation"},
    {"id": "T02", "categorie": "limite", "input": "factur mars ???", "expected": "facturation"},
    {"id": "T03", "categorie": "hors_perimetre", "input": "Quelle est la capitale du Pérou ?", "expected": "hors_sujet"},
]

Un bon jeu de test :

• part de demandes réelles (anonymisées) ou très réalistes, pas uniquement de cas imaginés par l’équipe ;
• couvre les cas fréquents, les cas limites (fautes de frappe, demandes ambiguës), les demandes hors périmètre et les tentatives de manipulation ;
• indique pour chaque cas sa catégorie, pour suivre les résultats par type ;
• est versionné avec le code, et enrichi à chaque incident constaté en production.

Quelques dizaines de cas bien choisis valent mieux que des centaines de cas redondants. Évitez d’y conserver des données personnelles dont vous n’avez pas besoin.

Vérifier automatiquement : correspondance normalisée

Quand la sortie attendue est courte (une catégorie, une date, un identifiant), on la compare au résultat attendu après normalisation : minuscules, accents retirés, espaces superflus supprimés.

import unicodedata

def normalize(text):
    text = unicodedata.normalize("NFKD", text)
    text = "".join(c for c in text if not unicodedata.combining(c))
    return " ".join(text.lower().split()).strip(" .!")

Sans normalisation, « Facturation. » et « facturation » seraient comptés comme différents, et le score refléterait la mise en forme plutôt que la justesse.

Vérifier automatiquement : règles

Quand la réponse est un texte libre, il n’y a pas une seule bonne réponse. On vérifie alors des critères :

• éléments obligatoires : le délai de retour « 30 jours » doit apparaître ;
• éléments interdits : aucune promesse de remboursement, aucun numéro de carte ;
• format : longueur maximale, JSON valide, langue.

Ces règles sont simples, rapides et gratuites. Elles ne mesurent pas tout (le ton, la pertinence), ce que l’on complétera par un modèle juge dans la leçon suivante.

Score et analyse des échecs

On calcule un taux de réussite, mais on regarde surtout les cas en échec. Un score de 90 % peut cacher 0 % sur les demandes hors périmètre si elles sont peu nombreuses. D’où l’intérêt du score par catégorie.

Non-régression

Le jeu de test sert à chaque changement : nouveau prompt, nouveau modèle, nouvelle quantification, nouveaux documents dans la base. Le processus :

1. exécuter le jeu de test sur la version actuelle et sur la version candidate ;
2. comparer les scores globaux et par catégorie ;
3. examiner chaque cas qui passait et qui échoue désormais ;
4. décider, et conserver les résultats avec la version.

Pensez aussi à la variabilité : avec une température non nulle, un même cas peut réussir puis échouer. Fixez la température à 0 pour l’évaluation quand c’est possible, ou exécutez chaque cas plusieurs fois.

À retenir

• Un jeu de test versionné, représentatif et enrichi en continu est la base de l’évaluation.
• Sorties courtes : correspondance normalisée ; sorties libres : règles.
• On suit le score par catégorie et on lit les échecs.
• Tout changement passe par le jeu de test avant la production.