Évaluer les fonctionnalités d’IA au-delà d’une démo soignée

Une démo soignée répond à une question précise : une fonctionnalité d’IA peut-elle produire un résultat convaincant dans des conditions choisies ? Elle n’établit pas comment la fonctionnalité traite les demandes ambiguës, les sources de mauvaise qualité, les entrées inhabituelles ou les tâches pour lesquelles une réponse incorrecte entraîne des conséquences notables.

Une évaluation utile commence par la décision ou la tâche que la fonctionnalité est censée faciliter. Les équipes produit peuvent ensuite rassembler des cas de test représentatifs, définir des signaux de qualité observables et décider où le jugement humain reste nécessaire. Le but n’est pas de prouver qu’un modèle est doté d’une intelligence générale. Il s’agit de déterminer si une conception de produit précise se comporte de manière acceptable dans des limites déclarées.

Définir la mission avant de juger le résultat

Commencez par décrire concrètement la mission de la fonctionnalité. « Générer un résumé » est trop général pour permettre une évaluation cohérente. « Produire un résumé pouvant être examiné, qui conserve les décisions mentionnées, les questions non résolues et les références aux sources » fournit des critères plus clairs aux personnes chargées de l’examen. La description doit également indiquer ce que la fonctionnalité ne doit pas déduire, omettre ou présenter comme résolu.

• La décision ou l’action que le résultat est destiné à faciliter
• Les informations qui doivent rester visibles, traçables ou inchangées
• Les erreurs qui exigeraient une correction, un rejet ou une transmission à un niveau supérieur
• Les conditions dans lesquelles la fonctionnalité devrait refuser de poursuivre ou demander des précisions

Ces limites font de l’évaluation une question de produit plutôt qu’une démonstration spectaculaire de performances. Elles indiquent également si le composant d’IA est essentiel à la tâche ou s’il est simplement pratique. Si les personnes chargées de l’examen ne peuvent pas décrire un résultat acceptable sans évoquer l’impression qu’il produit, l’équipe doit définir la mission plus précisément.

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

Un jeu d’évaluation est une collection tenue à jour d’entrées servant à examiner une fonctionnalité de façon répétée. Chaque cas de test doit inclure l’entrée, le contexte pertinent, les caractéristiques acceptables et les motifs de préoccupation connus. Le jeu peut comprendre des exemples courants, des éléments incomplets, des instructions contradictoires et des cas proches de la limite proposée pour le produit.

Une matrice d’évaluation, c’est-à-dire une vue structurée qui relie les conditions d’entrée aux critères d’examen, peut révéler des lacunes dans la couverture. Pour les intégrations avec des systèmes externes, l’équipe doit vérifier les interfaces disponibles, les formats de données, les autorisations et les réponses aux défaillances, au lieu de supposer un comportement stable. Les évaluateurs humains peuvent alors étudier l’ensemble du parcours, de l’entrée au résultat, dans des conditions documentées.

Choisir des signaux qui révèlent des différences utiles

Un signal de qualité est une propriété observable qui aide une équipe à comparer les résultats ou à détecter un risque. Les signaux doivent correspondre à la mission définie de la fonctionnalité. Un assistant de rédaction peut nécessiter le respect des instructions et la possibilité de modifier facilement le résultat, tandis qu’une fonctionnalité de classification peut nécessiter des limites de catégories claires et une procédure pour les cas incertains.

• Adéquation à la tâche : le résultat facilite-t-il la décision ou l’action prévue ?
• Alignement sur les preuves : les affirmations importantes peuvent-elles être vérifiées à partir des éléments fournis ?
• Respect des contraintes : le format, le périmètre et les exclusions obligatoires sont-ils respectés ?
• Qualité de la reprise : une correction ou une précision permet-elle d’obtenir un état suivant utilisable ?
• Délai de réponse : la durée de traitement reste-t-elle acceptable pour le flux de travail prévu ?

Tous les signaux ne doivent pas nécessairement devenir des indicateurs automatisés. Certaines qualités nécessitent un examen humain structuré, surtout lorsque plusieurs résultats peuvent tous être acceptables. Un guide d’examen peut définir les éléments à contrôler et la manière de consigner les préoccupations, sans prétendre que les jugements subjectifs sont parfaitement interchangeables. Des signaux distincts permettent généralement un meilleur diagnostic qu’une étiquette de qualité globale.

Distinguer la qualité du modèle, du système et de l’interaction

Le résultat du modèle n’est qu’une couche d’une fonctionnalité d’IA. La couche système peut inclure un prompt, c’est-à-dire les instructions et le contexte envoyés au modèle, ainsi que la récupération, qui consiste à sélectionner les sources à inclure. La logique du produit peut également valider des formats, limiter des actions ou transmettre un résultat pour examen. Dans la mesure du possible, chaque couche doit être examinée séparément.

La couche d’interaction détermine le contexte qu’une personne peut fournir, l’état qui lui est visible et la manière dont les corrections sont effectuées. Un résultat médiocre peut provenir d’une entrée incomplète, de contrôles peu clairs, d’une sélection de sources inadaptée ou du modèle choisi. Retracer le résultat à travers ces différentes couches aide l’équipe à modifier le bon composant, au lieu d’ajuster constamment les prompts sans comprendre la défaillance.

Exécuter une boucle d’évaluation contrôlée

Une boucle contrôlée permet de garder visibles les entrées, les règles d’examen et les détails de mise en œuvre pendant l’évaluation des changements. Si la mise en œuvre choisie peut produire des résultats différents lors d’exécutions répétées, l’évaluation doit consigner cette condition et déterminer si la variation affecte la tâche. Les comparaisons ne sont utiles que lorsque l’équipe sait ce qui a changé entre elles.

1. Figez un jeu d’évaluation nommé et documentez la couverture prévue de ce jeu.
2. Exécutez la mise en œuvre actuelle en consignant la configuration pertinente et les conditions des sources.
3. Examinez chaque résultat selon les signaux définis et attribuez-lui un statut permettant d’agir.
4. Analysez les défaillances au niveau du modèle, du système et de l’interaction avant de proposer un changement.
5. Répétez les cas concernés et vérifiez si le changement crée des problèmes ailleurs.

Des statuts tels que « validé », « à examiner » et « bloqué » peuvent relier l’évaluation aux décisions produit sans impliquer une certitude mathématique. Les contrôles humains doivent préciser qui peut approuver les résultats sensibles, de quelles preuves les personnes chargées de l’examen ont besoin et comment les résultats rejetés sont traités. Des vérifications automatisées peuvent faciliter ce processus lorsque leurs règles sont explicites et que leurs limites restent visibles.

Définir les limites de lancement à partir des preuves

L’évaluation doit aboutir à une décision délimitée, et non à une déclaration générale selon laquelle l’IA est bonne. Les preuves peuvent justifier une tâche limitée, un éventail d’entrées plus restreint, un examen obligatoire ou une conception qui demande des précisions avant le traitement. Les cas non résolus doivent rester explicitement nommés au lieu d’être absorbés dans une évaluation moyenne.

La séquence pratique est simple : définir la mission, réunir des conditions représentatives, choisir des signaux de diagnostic, examiner chaque couche du produit et tester les changements au moyen d’une boucle contrôlée. Les limites de lancement peuvent alors refléter ce que l’équipe a réellement examiné. À mesure que la fonctionnalité ou ses dépendances évoluent, le même cadre fournit une méthode stable pour décider ce qui doit être vérifié de nouveau.