Un vendredi après-midi, un ajustement d’une seule phrase dans le prompt système d’un module de classification de commentaires a fait chuter silencieusement la précision de la détection de spam sur le site d’un client, sans que personne ne s’en aperçoive avant plusieurs jours. Ce type de régression, invisible tant qu’on ne teste pas activement les sorties du modèle, nous a poussés à traiter nos prompts comme n’importe quel autre code : avec des tests.
Ce tutoriel ne traite pas des tests PHPUnit classiques, déjà largement documentés, mais du sujet plus récent des évaluations de prompt, spécifiquement pensées pour mesurer la qualité d’une sortie de modèle de langage plutôt qu’une simple égalité de valeurs.
Pourquoi un test PHPUnit classique ne suffit pas
Un test unitaire traditionnel vérifie qu’une fonction renvoie exactement la valeur attendue. Un appel à un modèle de langage ne renvoie jamais deux fois exactement le même texte, même avec une température basse et un prompt identique. Une évaluation de prompt doit donc mesurer des propriétés du résultat plutôt qu’une égalité stricte : la catégorie choisie est-elle correcte, la longueur respecte-t-elle la contrainte, le ton correspond-il à ce qui était demandé.
Constituer un premier jeu de cas de test
Le jeu d’évaluation part de cas réels, pas de cas inventés a priori. Sur le module de classification de commentaires évoqué plus haut, nous avons constitué le jeu de test à partir de cinquante commentaires réellement reçus sur le site, classés manuellement une fois pour servir de référence.
[
{
"id": "cas_01",
"entree": "Super article, merci pour ce partage !",
"attendu": "legitime"
},
{
"id": "cas_02",
"entree": "Achetez des followers pas chers ici : http://exemple-spam.test",
"attendu": "spam"
},
{
"id": "cas_03",
"entree": "Je ne suis pas du tout d'accord avec votre point de vue sur ce sujet.",
"attendu": "legitime"
}
]
Définir des critères de réussite objectifs
Pour chaque cas, le critère de réussite doit être vérifiable par du code, pas par une impression subjective. Sur la classification, c’est simple : la catégorie renvoyée correspond-elle à la catégorie attendue. Sur des tâches plus ouvertes, comme la génération d’un résumé, on définit des critères plus fins et cumulables.
- Le résumé respecte-t-il la contrainte de longueur maximale fixée dans le prompt.
- Le résumé contient-il bien les mots-clés jugés indispensables, vérifiés par une recherche simple.
- Le résumé ne contient-il aucune des expressions interdites définies par la charte éditoriale.
Le script d’exécution des évaluations
Le script parcourt chaque cas du jeu de test, appelle la fonction qui interroge le modèle, applique les critères de réussite et produit un rapport global. Il s’exécute en dehors de la requête WordPress classique, en ligne de commande, pour ne jamais ralentir le site en production.
function wpm_executer_evaluations( $chemin_json ) {
$cas_de_test = json_decode( file_get_contents( $chemin_json ), true );
$reussites = 0;
foreach ( $cas_de_test as $cas ) {
$resultat = wpm_classifier_commentaire( $cas['entree'] );
if ( $resultat === $cas['attendu'] ) {
$reussites++;
} else {
WP_CLI::log( sprintf(
'ÉCHEC %s : attendu "%s", obtenu "%s"',
$cas['id'], $cas['attendu'], $resultat
) );
}
}
$taux = round( ( $reussites / count( $cas_de_test ) ) * 100, 1 );
WP_CLI::log( sprintf( 'Taux de réussite : %s%% (%d/%d)', $taux, $reussites, count( $cas_de_test ) ) );
return $taux;
}Fixer un seuil d’acceptation, pas une exigence de perfection
Un modèle de langage n’atteindra jamais 100 % de réussite sur un jeu de test suffisamment varié, et viser ce chiffre pousse à sur-ajuster le prompt sur les cas de test au détriment de la généralisation. Nous fixons plutôt un seuil d’acceptation, par exemple 90 %, en dessous duquel la modification de prompt est rejetée avant fusion.
Intégrer l’évaluation dans le flux de développement
Le script d’évaluation s’exécute à chaque modification du fichier de prompt, via une commande WP-CLI dédiée intégrée à la chaîne d’intégration continue du projet. Toute modification qui fait chuter le taux de réussite sous le seuil fixé bloque la fusion de la branche, exactement comme le ferait un test unitaire classique qui échoue.
Un prompt qui n’est jamais testé est un prompt dont on découvre la régression en production, généralement au pire moment.
Pour aller plus loin
Ce premier jeu de vingt à cinquante cas ne couvre jamais tous les scénarios possibles. Nous recommandons de l’enrichir progressivement à chaque incident réel constaté en production, en ajoutant systématiquement comme nouveau cas de test tout exemple qui a mis en défaut le prompt en conditions réelles.
