Combien de cas de test faut-il ?.
Essayer une douzaine d’exemples avant de lancer une fonctionnalité IA, ça suffit ? Pas du tout. Combien de cas il faut vraiment, et lesquels.
Par Nizar Oukhchi, Architecte solution
Publié le · 8 min de lecture
Quelqu’un dans l’équipe essaie une douzaine d’exemples. Les réponses ont l’air bonnes. La fonctionnalité IA part en production.
Quelques semaines plus tard, un client trouve le cas que personne n’avait essayé.
Qu’est-ce qui a raté ? On a envie de dire que l’équipe n’a pas testé. Mais si ! Elle a testé. Le problème, c’est qu’une douzaine d’exemples ne disent pas grand-chose, et je pense que ça vaut la peine de savoir exactement à quel point.
Un score est une estimation
Imaginons que vous lanciez votre fonctionnalité IA sur un ensemble de cas de test, et que 90 % des réponses soient correctes.
Que veulent dire ces 90 % ?
On a tendance à y voir une propriété du système. Ce n’en est pas une. C’est une estimation, fondée sur un échantillon, de son comportement face aux entrées qu’il rencontrera en production. Et comme toute estimation, elle vient avec une marge d’erreur. Cette marge dépend surtout d’une chose : le nombre de cas testés.
Voici à quoi ça ressemble :
| 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 %. C’est énorme.
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.
Vous voyez la logique ? La marge diminue avec la racine carrée du nombre de cas. Pour la diviser par deux, il faut donc quatre fois plus de cas.
Un score sans le nombre de cas qui le soutient ne dit pas grand-chose.
Ça change ma façon de regarder une démo. 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.
Ce n’est pas rien. Mais ce n’est pas la même chose.
Comparer deux versions, c’est plus dur
En pratique, la question qu’on pose le plus souvent n’est pas « est-ce que c’est bon ? ».
C’est « est-ce que la nouvelle version est meilleure ? ».
Vous essayez un nouveau modèle, vous retouchez le prompt, ou vous changez la configuration de recherche documentaire. Vous obtenez un nouveau score. La tentation, c’est de garder le chiffre le plus élevé. Je la connais bien, cette tentation.
Pas si vite.
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 grimpe vite :
Une amélioration de dix points se voit 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, plusieurs milliers.
Maintenant, imaginez que votre jeu compte cinquante cas.
La plupart des écarts que vous verrez entre deux versions relèvent du bruit. Si vous vous y fiez, vous finirez par alterner entre des changements qui ne changent rien. On a l’impression d’avancer. Ce n’est pas le cas.
Alors, que faire ? Deux choses :
- Évaluez chaque version sur les mêmes cas. La comparaison devient appariée, ce qui retire une grande partie du bruit et réduit le nombre de cas nécessaires.
- Décidez à l’avance quelle taille d’amélioration justifie d’agir. Puis dimensionnez le jeu d’évaluation en conséquence.
Que mettre dans le jeu d’évaluation
Une fois qu’on a assez de cas, c’est fini ? Eh bien, non !
Le nombre compte, mais ce que les cas couvrent compte aussi. Un jeu fait uniquement de questions simples et typiques vous donnera un score élevé. Ce score ne dira rien des cas qui provoquent des incidents.
Je trouve utile de mélanger quatre types de cas. Voici à quoi peut ressembler un premier jeu :
- Des cas courants, tirés de vraies données. Échantillonnez-les 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 comme ça que le jeu s’enrichit, et ça 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. Ici, la bonne réponse est 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. C’est rapide, peu coûteux et constant. C’est par là que je commencerais.
Mais pour les réponses ouvertes, comme des résumés ou des brouillons de réponse ?
Là, écrivez une grille 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.
Pourquoi s’embêter ? Parce qu’un correcteur automatique non vérifié ajoute ses propres erreurs à la mesure. C’est un peu comme mesurer avec une règle que personne n’a jamais vérifiée.
L’intégrer à la livraison
Un jeu d’évaluation est le plus utile quand personne n’a besoin de penser à le lancer.
Lancez-le automatiquement à chaque modification : du prompt, du modèle, de la recherche documentaire ou du code qui l’entoure. Bloquez une mise en production quand le score baisse au-delà de la marge que vous avez jugée significative.
Et présentez le score avec sa marge, pas comme un chiffre isolé. Sinon, quelqu’un (moi compris, certains jours) finira par célébrer un gain d’un point mesuré sur cinquante cas.
Et après le lancement, c’est terminé ? Pas tout à fait.
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. 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.
Voici ce que je ferais :
- Rassemblez cent à deux cents exemples réels.
- Notez à quoi ressemble une bonne réponse pour chacun.
- Ajoutez les cas limites et les échecs que vous connaissez déjà.
Ce jeu vous en apprendra plus que n’importe quelle démo. Et il grandira avec chaque problème trouvé.
Voilà, c’est tout. Commencez petit, et restez honnête.
Nos projets d’IA appliquée commencent justement par cette étape. Si vous préparez une fonctionnalité, j’aimerais beaucoup que vous m’en parliez.