Tester des agents IA : un jeu d'évaluation qui vaut son coût
La question qui sépare les agents qui sortent de ceux qui pourrissent en pilote est simple : comment savez-vous si le changement d'hier a amélioré les choses ? Sans réponse, chaque retouche de prompt est un pari et chaque régression est découverte par un client.
Un jeu d'évaluation est la réponse, et il ne demande pas de plateforme. Cinquante cas dans un fichier, un script qui les exécute et une règle de notation par cas en disent plus que n'importe quel classement public, parce que ce sont vos cas.
À quoi ressemble un cas#
Un cas, c'est une entrée, l'état initial du monde et une attente vérifiable. L'attente n'est presque jamais une chaîne exacte : un agent peut avoir raison en plusieurs formulations. Notez le résultat : a-t-il appelé l'outil de remboursement avec la commande 4471 ? la réponse contient-elle la bonne date ? a-t-il refusé et posé une question, comme il le devait ? Là où la qualité rédactionnelle compte, une grille notée par un modèle convient si elle reste courte et vérifiée à la main de temps en temps.
Stockez l'état nécessaire au cas avec le cas. Un test qui ne passe que le mardi à cause de données live n'est pas un test.
Cinquante cas et leur provenance#
| Source | Combien | Pourquoi |
|---|---|---|
| Demandes réelles fréquentes | 20 | Protège le chemin quotidien |
| Pannes passées connues | 10 | Empêche le retour des régressions |
| Entrées ambiguës | 8 | Doit demander, pas deviner |
| Cas à refuser | 6 | Hors périmètre, non autorisé, dangereux |
| Résultats d'outil vides ou cassés | 6 | L'incident réel le plus courant |
Notez les résultats, pas les chemins#
Deux exécutions qui atteignent le même bon résultat par des chemins différents sont toutes deux correctes ; une suite qui exige une transcription échouera sans raison. Vérifiez ce qui a changé et ce qui a été dit : les appels à effets, les faits clés de la réponse, la demande éventuelle de porte humaine. Conservez la trace complète pour déboguer, sans l'affirmer dans les tests.
Quatre chiffres à suivre#
- Taux de réussite global et séparément sur le sous-ensemble à refuser.
- Taux d'affirmations non étayées : réponses contenant des faits absents des preuves.
- Médiane et 95e centile du coût et de la latence par exécution.
- Taux d'intervention humaine : combien de fois quelqu'un a dû reprendre la main, et pourquoi.
Dans la chaîne et après la mise en ligne#
Lancez le jeu à chaque changement de prompts, d'outils, de version de modèle ou de configuration de recherche : seules ces quatre choses modifient le comportement, et toutes changent plus souvent qu'on ne le pense. Après la mise en ligne, continuez d'échantillonner le trafic réel : quelques exécutions par jour notées à la main, et tout ce qui surprend rejoint le jeu. Un jeu qui cesse de croître cesse de représenter vos utilisateurs en un trimestre.
Questions fréquentes
Avec combien de cas commencer ?
Cinquante attrapent les vraies régressions et s'écrivent en deux jours. Vingt suffisent pour démarrer. Ce qui compte davantage, c'est de couvrir les catégories inconfortables : ambiguës, refus et résultats vides.
Peut-on noter avec un modèle ?
Oui, avec soin. Donnez des critères explicites plutôt que de demander si la réponse est bonne, gardez la grille courte et vérifiez régulièrement un échantillon. Les modèles-juges dérivent, et un juge qui a dérivé valide les régressions.
L'évaluation doit-elle bloquer les déploiements ?
Bloquez sur le sous-ensemble critique — refus et tout ce qui est irréversible. Pour la qualité générale, suivez la tendance et exigez une décision humaine en cas de baisse ; un petit mouvement peut être du bruit.
évaluer des agents iatests d'agentsjeu d'évaluation llmtests de non-régression llmmétriques de qualité
