Combien de cas de test faut-il pour lancer une fonctionnalité IA ?.
Une douzaine de bons exemples ne prouvent presque rien. Comment la taille de l'échantillon fixe la précision d'un score, et comment bâtir un jeu d'évaluation utile.
Publié le · 8 min de lecture
La plupart des fonctionnalités IA sont validées de la même manière : quelqu'un essaie une douzaine d'exemples, les réponses semblent bonnes, et la fonctionnalité est mise en ligne. Quelques semaines plus tard, un client trouve le cas que personne n'avait essayé. Le problème n'est pas que l'équipe a sauté les tests. C'est qu'une douzaine d'exemples ne disent pas grand-chose, et il vaut la peine de savoir exactement à quel point.
Un score est une estimation
Quand une fonctionnalité IA répond correctement à 90 % d'un ensemble de cas de test, ces 90 % ne sont pas une propriété du système. C'est une estimation, fondée sur un échantillon, de son comportement face aux entrées qu'il rencontrera en production. Comme toute estimation, elle s'accompagne d'une marge d'erreur, et cette marge dépend surtout du nombre de cas testés.
| Nombre de cas de test | Score autour de 50 % | Score autour de 90 % |
|---|---|---|
| 20 | ±22 | ±13 |
| 40 | ±15 | ±9 |
| 60 | ±13 | ±8 |
| 80 | ±11 | ±7 |
| 100 | ±10 | ±6 |
| 120 | ±9 | ±5 |
| 140 | ±8 | ±5 |
| 160 | ±8 | ±5 |
| 180 | ±7 | ±4 |
| 200 | ±7 | ±4 |
| 220 | ±7 | ±4 |
| 240 | ±6 | ±4 |
| 260 | ±6 | ±4 |
| 280 | ±6 | ±4 |
| 300 | ±6 | ±3 |
| 320 | ±5 | ±3 |
| 340 | ±5 | ±3 |
| 360 | ±5 | ±3 |
| 380 | ±5 | ±3 |
| 400 | ±5 | ±3 |
| 420 | ±5 | ±3 |
| 440 | ±5 | ±3 |
| 460 | ±5 | ±3 |
| 480 | ±4 | ±3 |
| 500 | ±4 | ±3 |
| 520 | ±4 | ±3 |
| 540 | ±4 | ±3 |
| 560 | ±4 | ±2 |
| 580 | ±4 | ±2 |
| 600 | ±4 | ±2 |
| 620 | ±4 | ±2 |
| 640 | ±4 | ±2 |
| 660 | ±4 | ±2 |
| 680 | ±4 | ±2 |
| 700 | ±4 | ±2 |
| 720 | ±4 | ±2 |
| 740 | ±4 | ±2 |
| 760 | ±4 | ±2 |
| 780 | ±4 | ±2 |
| 800 | ±3 | ±2 |
| 820 | ±3 | ±2 |
| 840 | ±3 | ±2 |
| 860 | ±3 | ±2 |
| 880 | ±3 | ±2 |
| 900 | ±3 | ±2 |
| 920 | ±3 | ±2 |
| 940 | ±3 | ±2 |
| 960 | ±3 | ±2 |
| 980 | ±3 | ±2 |
| 1 000 | ±3 | ±2 |
Avec vingt cas, un score mesuré de 90 % est compatible avec un taux réel allant de près de 77 % à 100 %. Avec cent cas, la marge se réduit à environ six points de part et d'autre. Il faut près de quatre cents cas pour descendre à trois points. Comme la marge diminue avec la racine carrée du nombre de cas, la diviser par deux demande quatre fois plus de cas.
Cela change la lecture d'une démonstration. Une fonctionnalité qui répond juste à dix questions sur dix n'a pas montré qu'elle est fiable. Elle a montré qu'elle n'est pas manifestement cassée.
Comparer deux versions est plus difficile
La question que les équipes posent le plus souvent n'est pas « est-ce bon ? » mais « la nouvelle version est-elle meilleure ? ». Un nouveau modèle, un prompt révisé ou une autre configuration de recherche documentaire produit un nouveau score, et la tentation est de garder le chiffre le plus élevé.
Détecter une différence demande beaucoup plus de cas que mesurer un seul score. Plus l'amélioration est petite, plus il faut de cas, et le besoin augmente vite.
Une amélioration de dix points apparaît clairement avec environ deux cents cas par version. Une amélioration de cinq points en demande près de sept cents. Une amélioration de deux points en demande plusieurs milliers. Avec un ensemble de cinquante cas, la plupart des écarts observés entre deux versions relèvent du bruit, et les équipes qui s'y fient finissent par alterner entre des changements qui ne changent rien.
Deux conséquences pratiques en découlent. D'abord, évaluez chaque version sur les mêmes cas, pour que la comparaison soit appariée. Cela retire une grande partie du bruit et réduit le nombre de cas nécessaires. Ensuite, décidez à l'avance quelle taille d'amélioration justifie d'agir, et dimensionnez le jeu d'évaluation en conséquence.
Que mettre dans le jeu d'évaluation
Le nombre de cas compte, mais ce qu'ils couvrent compte aussi. Un jeu fait uniquement de questions simples et typiques donnera un score élevé qui ne dit rien des cas qui provoquent des incidents. Un bon jeu mélange quatre types de cas.
- Des cas courants, tirés de vraies données. Échantillonnés parmi de vraies demandes, de vrais documents ou de vrais tickets, pour que le score reflète ce que les utilisateurs envoient réellement. Anonymisez-les d'abord.
- Des cas limites. Entrées longues, informations manquantes, formulations ambiguës, autres langues, formats inhabituels. C'est là que le comportement change, et là que les utilisateurs perdent confiance.
- Les échecs passés. Chaque incident et chaque mauvaise réponse signalée par un utilisateur devient un cas de test. C'est ainsi que le jeu s'enrichit, et cela garantit qu'un problème corrigé le reste.
- Des demandes hors périmètre ou malveillantes. Des questions que la fonctionnalité doit refuser, et des tentatives pour lui faire révéler des données ou ignorer ses instructions. La bonne réponse est alors souvent un refus.
Comment noter les réponses
Chaque cas a besoin d'une règle pour décider si la réponse est juste. Quand c'est possible, utilisez des contrôles que le code peut exécuter : une valeur exacte, une catégorie, un schéma valide, une citation qui renvoie au bon document source. Ils sont rapides, peu coûteux et constants.
Pour les réponses ouvertes, comme des résumés ou des brouillons de réponse, utilisez une grille écrite avec un petit nombre de critères explicites, et faites noter un échantillon par des personnes. Un second modèle peut appliquer la même grille à grande échelle, mais seulement après avoir vérifié, sur quelques dizaines de cas, que ses notes concordent avec celles de vos relecteurs. Un correcteur automatique non vérifié ajoute ses propres erreurs à la mesure.
L'intégrer à la livraison
Un jeu d'évaluation est le plus utile quand il s'exécute automatiquement. Lancez-le à chaque modification du prompt, du modèle, de la recherche documentaire ou du code qui l'entoure, et bloquez une mise en production quand le score baisse au-delà de la marge que vous avez jugée significative. Présentez le score avec sa marge, pas comme un chiffre isolé, pour que personne ne célèbre un gain d'un point mesuré sur cinquante cas.
Après le lancement, continuez à mesurer. Échantillonnez le trafic de production, faites-le relire régulièrement, et ajoutez au jeu ce que vous apprenez. Les entrées évoluent, les modèles sont mis à jour, et une fonctionnalité bien notée au lancement peut se dégrader sans aucun changement de votre côté.
Par où commencer
Inutile d'avoir des milliers de cas dès le premier jour. Rassemblez cent à deux cents exemples réels, notez à quoi ressemble une bonne réponse pour chacun, et ajoutez les cas limites et les échecs que vous connaissez déjà. Ce jeu vous en apprendra plus que n'importe quelle démonstration, et il grandira avec chaque problème trouvé. Nos projets d'IA appliquée commencent par cette étape, et vous pouvez nous parler de la fonctionnalité que vous préparez.