Choisir des cas de test IA au résultat attendu clair
Un petit plan de cas fixe les attentes avant le test IA. L’exemple distingue les entrées courantes, ambiguës et extérieures à la tâche.
Convenir de la tâche et de l’orientation attendue
Une entreprise de logiciels fictive prépare un pilote IA pour les messages de support. L’IA doit proposer une orientation : bug, access, review ou out-of-scope. L’octroi d’accès, les changements de statut et la clôture des tickets restent du ressort de l’équipe de support. L’évaluation porte donc sur la proposition, pas sur un service de support automatiquement accompli.
Fixez la décision attendue avec les responsables métier avant de connaître la sortie du modèle. En cas de désaccord entre responsables, clarifiez d’abord la règle. Le NIST AI RMF recommande de documenter les conditions de test et d’évaluer dans des conditions proches du déploiement.
Choisir des exemples aux objectifs de contrôle différents
La sélection suivante est fictive. Les textes illustrent les cas ; le véritable pilote enregistrera les entrées originales approuvées avec leur langue et leur provenance.
Cas | Exemple de message | Orientation attendue | Motif |
|---|---|---|---|
| L’application plante quand j’enregistre une note de projet. |
| Symptôme d’erreur clairement décrit |
| Merci de me donner accès à mon projet. |
| Demande d’accès claire ; pas encore une autorisation |
| Je n’arrive pas à entrer. |
| Demande d’accès ou problème technique non tranché |
| L’enregistrement produit une erreur ; j’ai aussi besoin d’un accès au projet. |
| Demandes mêlées ; ce pilote prévoit une catégorie par message |
| Inscrivez-vous à notre séminaire promotionnel. |
| Aucune demande de support dans le catalogue convenu |
La dernière étiquette ne provoque aucune suppression dans cet exemple. La sélection rend visibles différentes décisions ; elle ne prouve ni la fréquence des cas ni une taille suffisante du jeu de test. La collecte ultérieure doit aussi couvrir les langues, formats d’entrée et informations manquantes réellement nécessaires.
Séparer les cas de développement du contrôle ultérieur
Les exemples utilisés pour modifier le prompt ou les règles d’orientation sont des cas de développement. Réservez pour un contrôle ultérieur d’autres cas qui n’ont pas déjà servi à optimiser le système. Copies et reformulations proches d’un même message initial ne doivent pas être réparties des deux côtés comme des preuves indépendantes.
Google explique comment réutilisation des données de test et doublons peuvent fausser l’évaluation en apprentissage automatique. Une précaution pratique en découle pour les prompts : les exemples connus aident au diagnostic, mais le contrôle ultérieur doit inclure d’autres cas encore inconnus. Modifier un prompt n’est pas entraîner un modèle.
Consigner les résultats par cas et type d’erreur
Lors du futur test, notez les versions du modèle, du prompt et du jeu de test, l’orientation attendue, la sortie réelle et l’appréciation métier. Une vérification humaine prévue est un résultat approprié pour un cas ambigu. Une affectation définitive trop rapide peut au contraire être une erreur.
Présentez séparément les entrées courantes, ambiguës et hors tâche. Si une erreur sert à adapter la solution, conservez le constat initial dans le rapport ; le cas sert ensuite au développement et au contrôle du retour éventuel de cette erreur connue. Un nouveau contrôle indépendant nécessite d’autres exemples réservés adaptés. Le tableau est un point de départ argumenté pour la sélection, pas un test exécuté ni une preuve d’aptitude à la production.
Sources
Écrit par
- Philipp ReuterRédacteur qualité logiciellePhilipp Reuter écrit chez ASES sur les tests logiciels et la préparation des nouvelles versions. Ses articles portent sur l’analyse des erreurs, les tests de recette et la vérification des modifications apportées aux applications existantes.
À lire aussi
Tous les articles
IA & automatisation avec ASES
Assistants IA et processus automatisés