Signaux de qualité pour tester une fonctionnalité d’IA

Une fonctionnalité d’IA peut sembler convaincante lors d’une démonstration préparée tout en restant difficile à évaluer en tant que produit. La démonstration montre ce que l’équipe a sélectionné, dans les conditions qu’elle a organisées. L’évaluation pose une autre question : quelles preuves permettraient de décider de lancer, de réviser, de restreindre ou de retirer la fonctionnalité ?

Une évaluation utile commence avant même le choix d’une métrique. L’équipe doit définir la tâche, les limites acceptables et les conséquences d’un échec. Elle peut ensuite réunir des cas représentatifs, combiner des contrôles automatisés avec un examen humain structuré et surveiller le parcours complet du produit plutôt que de considérer un résultat généré comme l’expérience tout entière.

Commencer par la décision concernant le produit

L’évaluation doit préciser la décision qu’elle est censée éclairer. Un objectif général, comme mesurer la qualité, laisse trop de place à l’interprétation. Un objectif pratique indique la tâche, les conditions pertinentes et l’action que l’équipe pourrait entreprendre après avoir examiné les résultats.

• Pertinence pour la décision : Préciser si le résultat guidera le périmètre du lancement, les modifications de l’interface, le choix du modèle ou l’ajout de mesures de protection.
• Tâche prévue : Décrire ce que la fonctionnalité doit aider à accomplir sans dépendre d’une mise en œuvre technique particulière.
• Échec acceptable : Distinguer les désagréments mineurs des erreurs qui exigent un blocage, une correction ou un examen humain explicite.
• Limite opérationnelle : Consigner les langues, les types d’entrées, les domaines et les processus inclus dans l’évaluation.

Ce cadrage empêche un résultat global favorable de masquer un échec qui compte pour le produit. Si, par exemple, des affirmations non étayées sont inacceptables dans un outil d’aide à la recherche, une formulation fluide ne peut pas compenser une faible correspondance avec les sources. L’évaluation correspondante doit donc vérifier si les affirmations générées peuvent être reliées aux éléments fournis, et pas seulement si la réponse semble soignée.

Construire un jeu d’évaluation à partir de conditions réelles

Un jeu d’évaluation est une collection tenue à jour d’entrées, de propriétés attendues et de notes d’examen, utilisée pour tester une fonctionnalité de manière répétée. Il doit inclure des cas courants, des cas difficiles et des entrées situées hors de la limite prévue. L’objectif n’est pas de prédire toutes les demandes possibles, mais de révéler les conditions qui comptent pour la décision actuelle concernant le produit.

Un jeu utile peut s’appuyer sur des exemples internes approuvés, des scénarios construits délibérément et, le cas échéant, des données opérationnelles assainies. Chaque cas doit expliquer sa raison d’être et ce que la personne chargée de l’examen doit vérifier. Si un exemple dépend d’un contexte, ce contexte doit figurer dans la définition du cas plutôt que dans la mémoire de cette personne. Les données sensibles doivent être exclues ou traitées conformément aux règles établies du produit en matière de données.

Utiliser des signaux décrivant différents échecs

Aucun signal ne suffit à lui seul à rendre compte de la qualité du produit. Les contrôles automatisés peuvent repérer des propriétés faciles à définir de manière cohérente, tandis que l’examen humain peut évaluer le sens, l’utilité et l’ambiguïté. L’équipe doit choisir chaque signal parce qu’il correspond à un risque connu du produit, et non parce qu’il est facile à calculer.

• Accomplissement de la tâche : Le résultat a-t-il respecté l’instruction précise et préservé les contraintes requises ?
• Ancrage dans les sources : Les affirmations pertinentes peuvent-elles être reliées aux informations fournies pour ce cas ?
• Respect du format : Le résultat a-t-il suivi la structure nécessaire au processus dans lequel il s’inscrit ?
• Qualité du refus : Lorsque la demande était hors périmètre, la fonctionnalité a-t-elle évité de poursuivre et proposé une prochaine étape appropriée ?
• Performances du système : Le temps de traitement, la gestion des échecs et l’utilisation des ressources sont-ils restés dans les limites opérationnelles définies par l’équipe ?

Un score doit conserver assez de détails pour expliquer ce qui a échoué. L’ancrage dans les sources, par exemple, ne doit pas être fusionné avec la qualité rédactionnelle si ces signaux conduisent à des corrections différentes. Si une mise en œuvre affiche une valeur de confiance, l’équipe doit vérifier ce que cette valeur représente avant de l’utiliser. Cette valeur ne doit pas être considérée comme un substitut aux preuves liées à la tâche.

Rendre l’examen humain reproductible

L’examen humain devient plus utile lorsque les personnes qui l’effectuent appliquent les mêmes critères écrits aux mêmes éléments. Une grille d’évaluation est un ensemble de catégories de jugement définies, accompagnées d’exemples de résultats acceptables et inacceptables. Elle doit décrire des propriétés observables plutôt que demander simplement si une réponse semble bonne.

1. Rédiger un critère bref pour chaque risque du produit, en précisant les preuves que la personne chargée de l’examen doit étudier.
2. Tester la grille sur un échantillon commun et discuter des cas dans lesquels les personnes chargées de l’examen l’interprètent différemment.
3. Réviser les formulations ambiguës, puis consigner le raisonnement qui sous-tend les jugements difficiles afin de pouvoir s’y référer ultérieurement.
4. Examiner les cas sans étiquettes de mise en œuvre superflues lorsque ces étiquettes pourraient influencer le jugement.
5. Faire remonter les désaccords ayant des conséquences afin qu’ils donnent lieu à une décision produit explicitement désignée, plutôt que de les effacer en établissant une moyenne.

Une taxonomie des échecs, c’est-à-dire un ensemble cohérent de catégories d’échecs, aide à relier les conclusions de l’examen au travail sur le produit. Les catégories peuvent distinguer les informations manquantes, les contenus non étayés, les instructions ignorées et les problèmes de rétablissement de l’interface. Les libellés exacts doivent correspondre à la fonctionnalité. Ils ne sont utiles que si l’équipe peut les relier à un responsable, à une enquête ou à une décision sur le périmètre.

Évaluer la boucle complète du produit

Le texte, l’image ou l’action générés ne constituent qu’une partie de la fonctionnalité. L’évaluation doit aussi couvrir la préparation des entrées, la récupération des éléments justificatifs, les contrôles de l’interface, la communication de l’état, la reprise après erreur et toute étape d’approbation humaine. Les composants pertinents dépendent de la mise en œuvre et doivent être vérifiés dans le cadre du plan de test.

• Les contrôles des entrées doivent couvrir l’absence de contexte, les instructions contradictoires et les éléments situés hors de la limite prise en charge.
• Les contrôles de l’état doivent confirmer que l’interface représente l’attente, l’échec et l’achèvement conformément au parcours prévu.
• Les dispositifs de contrôle humain doivent permettre de vérifier si l’examen, la correction, l’annulation et le retour en arrière sont disponibles lorsque le produit les exige.
• Les contrôles des modifications doivent rechercher les régressions, c’est-à-dire les cas auparavant acceptables qui deviennent inacceptables après une mise à jour.

Cette vue d’ensemble du système précise également où appliquer une correction. Un résultat médiocre peut exiger des consignes d’entrée plus claires, une meilleure sélection des sources, un périmètre plus restreint ou une étape d’approbation supplémentaire plutôt qu’une modification du modèle. Consigner la couche suspectée empêche l’évaluation de réduire tous les problèmes à un score unique portant sur le résultat.

Transformer les conclusions en limites de lancement

L’examen final doit relier les preuves à des choix explicites concernant le produit. L’équipe peut déterminer quels cas doivent réussir, quels échecs exigent un contrôle humain et quelles conditions restent hors du périmètre pris en charge. Les résultats doivent être conservés avec les définitions des cas, la grille d’évaluation et la configuration pertinente de la mise en œuvre afin que les évaluations ultérieures restent interprétables.

Un cadre pratique associe donc une décision définie, un jeu d’évaluation tenu à jour, des signaux de qualité distincts, un examen humain reproductible et des contrôles portant sur la boucle complète du produit. L’objectif n’est pas d’obtenir un score parfait. Il est de rendre la prochaine décision lisible : lancer la fonctionnalité dans une limite déclarée, réviser une couche précise, ajouter un dispositif de contrôle ou ne pas proposer la fonctionnalité tant qu’un échec substantiel n’est pas compris.