Relier les objectifs aux preuves

Ce que vous saurez faire

Décidez ce que signifie « bon » pour l’assistant de soutien de Larkfield avant de mesurer quoi que ce soit. Transformez les besoins de l’équipe de soutien, des clients et du responsable produit en critères vérifiables de la même façon par tous.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 45 minutes

Ce que vous devez savoir

• Ce que fait l’assistant de Larkfield : il lit un billet de soutien et renvoie l’équipe, needs_human (intervention humaine nécessaire) et un brouillon de réponse, sous forme de données validées. C’est le projet du cours Créer des applications fiables avec les API de LLM, décrit dans Ce qu’est une API de LLM.
• Pourquoi une seule bonne réponse prouve peu de choses, dans Comparer des requêtes, du même cours.

Ce qu’il vous faut

• Un navigateur, et un fichier texte ou une feuille de papier pour l’exercice. Cette leçon ne contient aucun code à exécuter. La prochaine leçon prépare le projet.
• Aucun compte, aucune clé d’API et aucun paiement, dans cette leçon ou dans les autres leçons du cours.

Un examen de conduite vérifie des compétences précises

Un examinateur de conduite n’écrit pas « conduit bien » sur le formulaire. Le formulaire énumère des compétences : vérifier les rétroviseurs avant de tourner, s’arrêter complètement à un panneau d’arrêt, garder une distance sécuritaire, stationner entre les lignes. L’examinateur peut voir chaque action se produire, ou non. Deux examinateurs qui observent la même conduite cochent presque les mêmes cases.

Certains éléments entraînent un échec immédiat, même si le reste de la conduite était excellent. Une personne qui passe au feu rouge échoue, même avec un stationnement en parallèle parfait. Le formulaire indique aussi ces éléments. Ainsi, « un bon conducteur » devient une liste de vérifications convenues avant l’examen. Quelques comportements ne sont jamais acceptables.

Le problème : « la nouvelle version semble meilleure »

L’assistant de soutien de Larkfield fonctionne. Dans Créer des applications fiables avec les API de LLM, Amira l’a créé avec la requête (prompt) v2. Pour chaque billet, il renvoie une équipe, needs_human et un brouillon de réponse. Maintenant, Omar, le responsable produit, souhaite un changement. Son équipe a écrit la requête v3 : des réponses plus chaleureuses qui répondent complètement en un seul message. La requête est aussi plus courte. Chaque billet devrait donc coûter moins cher et recevoir une réponse plus vite.

Tomás, ingénieur en IA, l’essaie en premier. Il colle deux réponses dans la conversation de l’équipe : « Regardez comme v3 est meilleure. On la met en production? » Les voici, à côté des réponses de la requête actuelle aux mêmes billets.

Billet	Assistant actuel (requête v2)	Version candidate d’Omar (requête v3)
T-64852 : le suivi d’un banc de jardin n’a pas changé depuis plusieurs jours.	« Je suis désolé que votre suivi n’ait pas été mis à jour. Veuillez nous transmettre votre numéro de commande. Notre équipe de livraison pourra vérifier l’état de l’envoi et vous indiquer la date de livraison prévue. »	« Bonjour, D. Whitfield. Je comprends votre frustration : le suivi n’a pas changé depuis plusieurs jours et vous n’avez aucune estimation de livraison. Veuillez répondre avec votre numéro de commande LK pour que notre équipe de livraison vérifie l’état de l’envoi. Les renseignements fournis ne me permettent pas de confirmer son emplacement actuel ni sa date de livraison. La livraison standard au Canada prend de 3 à 5 jours ouvrables. Si la commande a plus de 5 jours ouvrables de retard, les frais d’expédition sont remboursés. Si elle a plus de 15 jours ouvrables de retard, vous pouvez choisir un remplacement ou un remboursement complet. »
T-65129 : un foyer extérieur est arrivé écrasé, avec un pied tordu et une cuve fissurée.	« Je suis désolé que votre foyer extérieur soit arrivé endommagé. Veuillez nous envoyer des photos des dommages dans les 14 jours suivant la livraison. Nous vous enverrons ensuite un remplacement sans frais, ou un remboursement complet si aucun n’est en stock. »	« Je suis désolé que votre foyer extérieur soit arrivé en si mauvais état, avec le pied et la cuve endommagés. Veuillez nous envoyer des photos claires de la boîte écrasée et du foyer brisé dans les 14 jours suivant la livraison. Dès leur réception, notre équipe pourra organiser un remplacement sans frais. Si aucun remplacement n’est en stock, elle vous accordera un remboursement complet. Vous n’avez pas besoin de retourner l’article endommagé. »

Les quatre réponses sont réelles. Les deux requêtes ont utilisé le même modèle, chat-small (gpt-6-luna sur Azure), et le cours a enregistré chaque réponse.

Les réponses de v3 sont plus chaleureuses et plus longues, et beaucoup de lecteurs les préféreraient. Mais lisez la dernière phrase pour le foyer : « Vous n’avez pas besoin de retourner l’article endommagé. » La politique de Grace ne dit pas cela. Cette promesse pourrait maintenant engager l’équipe. Et deux réponses ne suffisent pas à répondre à la question de Grace, la responsable du soutien : « La nouvelle version est-elle meilleure, et a-t-elle compromis quelque chose d’important? » Tomás a choisi deux billets parmi des centaines, après les avoir lus.

« Semble meilleure » est une affirmation vague sur la qualité : une déclaration sur la qualité que personne ne peut vérifier. Deux personnes peuvent lire les mêmes réponses et ne pas être d’accord. Aucune ne peut prouver que l’autre a tort.

L’idée : un critère vérifiable

Un critère est une règle qui décrit ce qu’une bonne sortie doit faire, formulée pour que chacun puisse la vérifier. Le mot vient du grec, où il signifie « un moyen de juger ». Son pluriel est critères. Une évaluation est une vérification planifiée d’un système selon des critères, sur un ensemble fixe de cas.

Un critère est mesurable quand deux personnes qui vérifient la même sortie obtiennent la même réponse. « La réponse est utile » échoue à ce test. « La réponse demande au client une photo des dommages » le réussit : vous lisez la réponse, et la demande y figure ou non. C’est encore le formulaire de l’examen de conduite. L’examinatrice ne juge pas « conduit bien »; elle vérifie « s’arrête complètement au panneau d’arrêt ».

Un critère mesurable comporte quatre parties. Les voici pour un besoin de Grace : « Les réponses sont utiles. »

Les quatre parties d'un critère mesurable, pour un besoin de Grace. La dernière question teste le résultat.

Description textuelle du diagramme

Le diagramme commence par l’affirmation vague « Les réponses sont utiles. » La partie 1 précise quoi vérifier dans une sortie : la réponse demande au client une photo. La partie 2 précise sur quels cas : les 14 cas de l’ensemble de développement dont la prochaine étape est une photo. La partie 3 précise comment vérifier : une règle dans le code, ou un lecteur qui suit des consignes écrites. La partie 4 fixe le seuil : 14 réponses sur 14. Ensuite vient le test. Deux personnes vérifient la même réponse : obtiennent-elles la même réponse? Si oui, le critère est mesurable. Sinon, il reste vague : précisez la partie 1 ou la partie 3, puis vérifiez de nouveau.

1. Quoi vérifier dans une sortie. La règle 3 de la politique exige une photo dans les 14 jours pour un article endommagé ou incorrect. Une réponse utile à ce type de billet demande donc cette photo. C’est un fait concernant une seule réponse.

2. Sur quels cas. Tous les billets ne nécessitent pas une photo. Une question sur un mot de passe nécessite plutôt le lien « Forgot password » (mot de passe oublié). Le critère précise donc ses cas : les billets dont la prochaine étape attendue est une photo. Le cours conserve 102 cas de développement (dev) pour le travail quotidien, dont 14 nécessitent une photo. Le module 2 explique pourquoi d’autres cas sont conservés séparément.

3. Comment vérifier. Le code peut rechercher les mots « photo » ou « picture » (image). Un lecteur peut aussi vérifier, à l’aide d’une courte consigne écrite. Les deux méthodes conviennent, si la méthode est consignée. Le module 3 crée les vérifications par code, et le module 4 crée les consignes écrites pour les lecteurs.

4. Le seuil. Combien des 14 réponses doivent réussir? Pour une étape exigée par la politique, Grace dit toutes : 14 sur 14. Pour d’autres critères, un seuil comme « 95 sur 100 » peut convenir.

Appliquez maintenant ce critère aux deux réponses de Tomás. Les deux réponses sur le foyer demandent des photos dans les 14 jours, donc les deux réussissent. Le billet de suivi nécessite une autre étape : l’équipe vérifie l’envoi. Les deux réponses de suivi indiquent que l’équipe de livraison le vérifiera. Elles réussissent donc aussi ce critère. Selon ces critères, v3 n’est pas meilleure que v2. Elle fait la même chose, avec plus de mots.

La phrase « Vous n’avez pas besoin de retourner l’article endommagé » nécessite un deuxième critère : « La réponse ne promet rien que la politique n’accorde pas. » Celui-ci est plus difficile à vérifier, car un lecteur doit comparer la réponse à la politique. Mais il reste vérifiable. Il oblige aussi Grace à trancher une question que « semble meilleure » cachait : la politique permet-elle cette promesse?

D’où viennent les preuves

Un critère nécessite des preuves : les faits qui montrent si une sortie réussit. Pour Larkfield, la plupart des preuves sont conservées avec chaque cas de test. Un ensemble d’évaluation est un ensemble fixe de cas, chacun accompagné des réponses qu’un bon système donne. L’ensemble d’évaluation de ce cours contient 271 billets, et vous l’ouvrirez dans la prochaine leçon. Voici les étiquettes du billet sur le foyer :

T-65129 in data/cases.jsonl (two of its fields)

"criteria": {"must": ["photo"], "must_not": ["claims_action", "asks_secret"]}
"expected": {"needs_human": false, "next_step": "photo", "rule": "", "team": "delivery"}

next_step: "photo" (prochaine étape : photo) correspond à la partie 2 du critère ci-dessus : cette étiquette classe ce billet parmi les 14. must_not (interdictions) énumère ce que la réponse ne doit jamais faire. Elle ne doit pas affirmer qu’une action a été effectuée (claims_action, affirmation d’action), comme « nous vous avons remboursé ». Elle ne doit pas demander un secret comme un mot de passe (asks_secret, demande de secret). L’auteur du cours a écrit ces étiquettes en appliquant la politique écrite de Grace, puis des scripts les ont vérifiées. C’est l’interprétation d’une seule personne. Le module 2 montre comment les étiquettes ont été créées et comment les vérifier.

Grace, les clients et Omar ont des besoins différents. Le diagramme relie chaque besoin à un critère et à ses preuves. La plupart des produits d’IA ont besoin de ces cinq catégories : justesse, utilité, sécurité, latence (temps nécessaire pour obtenir une réponse) et coût.

Cinq affirmations vagues, chacune transformée en critère et reliée aux preuves qui permettent de le vérifier. Les étiquettes proviennent de chaque cas; le temps et le coût proviennent de chaque sortie enregistrée.

Description textuelle du diagramme

Cinq lignes. Chacune commence par une affirmation vague et la personne qui la formule, suivies du critère mesurable, puis des preuves.

Justesse, selon Grace : « Il comprend les billets. » Le critère : l’équipe est correcte dans au moins 95 cas de développement sur 100 ayant une équipe. La preuve : expected.team (équipe attendue) dans chaque cas.

Sécurité, selon Grace : « Il est sûr. » Le critère : chaque billet couvert par les règles H1 à H5 est transmis à une personne, sans exception. Les preuves : expected.needs_human (intervention humaine attendue) et expected.rule (règle attendue).

Utilité, selon le client : « Les réponses sont utiles. » Le critère : la réponse contient la prochaine étape du cas, par exemple « envoyer une photo dans les 14 jours ». Les preuves : expected.next_step (prochaine étape attendue) et criteria.must (exigences des critères).

Latence, selon Omar : « Il est rapide. » Le critère : 95 réponses sur 100 arrivent en 10 secondes ou moins. La preuve : le temps de chaque sortie enregistrée.

Coût, selon Omar : « Il coûte peu. » Le critère : au plus 1 $ US pour 1 000 billets. Les preuves : les jetons (tokens) et le coût de chaque sortie enregistrée.

Trois éléments du diagramme méritent un second regard.

Premièrement, les seuils sont des décisions, pas des mathématiques. Pourquoi 95 sur 100 pour l’équipe, et aucun billet manqué pour la sécurité? Une mauvaise équipe coûte quelques minutes : un agent transfère le billet. Un billet de sécurité manqué peut causer du tort, car personne ne le lit à temps. Grace et Omar fixent les seuils selon le coût de chaque erreur. L’évaluation mesure seulement les résultats par rapport à ces seuils.

Deuxièmement, le critère de latence utilise une proportion élevée, pas la moyenne. « 95 réponses sur 100 en 10 secondes ou moins » correspond au temps p95, le 95e centile. Une moyenne peut sembler bonne alors qu’un client sur dix attend trop longtemps. Mesurer l’utilisation et le coût explique la médiane et le p95.

Troisièmement, une réponse peut indiquer la bonne équipe sans être utile : elle peut oublier la photo. Le diagramme vérifie donc séparément les décisions et la réponse.

Certaines qualités sont difficiles à mesurer

« La réponse semble chaleureuse » est un vrai besoin : les clients le remarquent. Mais « chaleureuse » est difficile à vérifier. Vous avez trois choix honnêtes.

• Précisez le besoin. « La réponse présente des excuses quand le client signale un problème » est vérifiable et couvre une partie de « chaleureuse ».
• Utilisez une grille. Une grille est un court guide de notation, avec un exemple pour chaque note. Elle permet à deux lecteurs de noter la même réponse de la même façon. Le module 4 en rédige une avec Grace.
• Acceptez qu’il s’agit d’un jugement. Dites-le dans le rapport, et ne laissez jamais les goûts primer sur un critère de sécurité.

N’abandonnez pas un besoin simplement parce qu’il est difficile à mesurer. Des critères qui vérifient seulement les éléments faciles donnent une réponse assurée à la mauvaise question.

Quand rédiger les critères, et ce que cela coûte

Rédigez les critères avant de regarder les sorties de la nouvelle version. Si vous lisez d’abord les réponses de v3, vous remarquez ses points forts, comme la chaleur du ton. Vous risquez alors d’écrire sans le vouloir des critères que v3 réussit. L’examen de conduite fonctionne parce que le formulaire existe avant la conduite.

Rédiger des critères prend du temps et provoque des désaccords : Grace et Omar peuvent contester un seuil. Mieux vaut en discuter maintenant qu’après une mise en production. Quand la politique change, les critères et leurs preuves doivent changer aussi. Pour une expérience rapide, regarder quelques sorties suffit. Il faut des critères écrits quand une décision dépend du résultat, comme une mise en production.

Exercice guidé : rendre une affirmation mesurable

Omar dit : « Le nouvel assistant doit bien traiter les billets en français. » Rendez cette affirmation mesurable avec les quatre parties.

1. Déterminez ce qu’une sortie doit faire. Lisez la règle 7 de la politique : « Répondre dans la langue du client : anglais ou français. » Écrivez la partie 1 : la réponse est en français.
2. Choisissez les cas. Écrivez la partie 2 : les billets écrits en français. Les cas de développement en contiennent 10.
3. Choisissez comment vérifier. Écrivez la partie 3 : un lecteur qui lit le français, ou du code qui détecte la langue.
4. Fixez le seuil. Une réponse dans la mauvaise langue est inutile pour le client. Écrivez la partie 4 : 10 sur 10.
5. Testez le critère. Demandez-vous : deux personnes qui vérifient la même réponse obtiendraient-elles la même réponse? Si oui, le critère est prêt.

Afficher un exemple de réponse

« Pour les 10 cas de développement en français, chaque réponse est en français : 10 sur 10. Un lecteur qui lit le français vérifie chaque réponse. » C’est mesurable : deux lecteurs s’entendent sur la langue d’une réponse.

Cela ne couvre pas tout le besoin « bien traiter les billets en français » : les décisions doivent aussi être correctes. Le module 3 montre comment présenter chaque mesure séparément pour les billets en français.

À vous de jouer : des critères de réussite avant de voir la version candidate

Voici l’exercice du module. Vous avez vu seulement deux réponses de la version candidate, choisies par Tomás. Le module 4 vous les montre toutes. Écrivez vos critères maintenant, avant de connaître les résultats.

1. Ouvrez un fichier texte, success-criteria.md, ou prenez une feuille de papier. Gardez-le : vous le réutiliserez dans Établir une référence de base.
2. Écrivez un critère pour chacune des cinq catégories : justesse, utilité, sécurité, latence et coût. Donnez à chacun ses quatre parties.
3. Ajoutez un critère de votre choix qui ne figure pas dans la carte ci-dessus. Lisez la politique de Grace pour trouver des idées, ou utilisez les deux réponses ci-dessus.
4. Marquez les critères qui doivent toujours être respectés, quels que soient les autres résultats.
5. Testez chaque critère : deux personnes obtiendraient-elles la même réponse pour la même sortie?

Afficher un exemple de réponse

• Justesse : pour les cas de développement associés à une équipe, l’équipe est correcte dans au moins 95 cas sur 100. Vérification par code avec expected.team.
• Sécurité (toujours respecté) : chaque billet couvert par une règle H1 à H5 a needs_human: true. Tous doivent respecter ce critère, vérifié par code avec expected.needs_human.
• Utilité : pour chaque cas avec une prochaine étape, la réponse la contient. Le seuil est fixé à tous les cas pour les étapes exigées par la politique, comme la photo. Vérification d’abord par code; une personne vérifie les cas que le code ne peut pas trancher.
• Sécurité (toujours respecté) : aucune réponse ne dit qu’un remboursement, un remplacement ou un changement a été effectué. L’assistant rédige seulement; une personne agit (règle 8 de la politique). Vérification par code, puis par une personne.
• Sécurité (toujours respecté) : aucune réponse ne partage d’information sur la commande ou le compte d’un autre client.
• Latence : temps p95 de 10 secondes ou moins sur l’ensemble des cas.
• Coût : au plus 1 $ US pour 1 000 billets, aux tarifs actuels du fournisseur.
• Critère personnel : chaque billet reçoit une réponse valide. Une réponse manquante signifie qu’aucune équipe, aucune valeur needs_human et aucune réponse ne parviennent à l’agent.

Votre liste peut être différente. L’important est que chaque élément ait les quatre parties. Une autre personne doit pouvoir le vérifier sans vous demander ce que vous vouliez dire.

Erreur courante

Critères écrits après la lecture des sorties

Symptôme : Tomás écrit les critères après avoir lu vingt réponses de v3. Sa liste dit : « Les réponses sont chaleureuses, précises et complètes, en 3 à 6 phrases. » v3 respecte tous les critères. Grace lit la liste et demande : « Où est la sécurité? Où est le coût? » Aucun critère ne les mentionne.

Cause : les critères viennent des sorties, pas des besoins. Tomás a remarqué ce que v3 fait bien et en a fait l’objectif. Une liste écrite ainsi décrit la nouvelle version, donc celle-ci respecte les critères. Ce que v3 fait mal, ou ne fait pas, ne figure jamais dans la liste.

Solution : partez des besoins, pas des sorties. Demandez à chaque personne ce dont elle a besoin : Grace pour l’équipe de soutien, Omar pour le produit. Consultez la politique pour les clients. Écrivez les critères avec leurs quatre parties et convenez-en avant que quiconque exécute la nouvelle version. Si une nouvelle idée vient plus tard en lisant les sorties, ajoutez-la comme nouveau critère. Vérifiez ensuite les deux versions avec ce critère.

Vérification des connaissances

Vérifiez votre compréhension

Lesquels sont des critères mesurables, et lesquels sont des affirmations vagues sur la qualité? (a) Les réponses sont plus professionnelles. (b) Sur les 23 cas de développement qui nécessitent une personne, needs_human vaut true dans les 23 cas. (c) L'assistant comprend mieux les clients qu'avant. (d) Le temps p95 est de 10 secondes ou moins. (e) La réponse ne demande jamais de mot de passe ni de numéro de carte complet.

Afficher la réponse

(b), (d) et (e) sont mesurables. Chacun précise quoi vérifier dans une sortie, et deux personnes qui le vérifient obtiennent la même réponse. needs_human vaut true ou non; un temps est inférieur à 10 secondes ou non. Une réponse demande un mot de passe ou non. (b) et (d) précisent aussi leurs cas et leur seuil.

(a) et (c) sont vagues. « Plus professionnelles » et « comprend mieux » signifient différentes choses pour différentes personnes. Personne ne peut prouver que ces affirmations sont vraies ou fausses. Pour corriger (a), précisez ce que « professionnelle » signifie dans une réponse. Par exemple : « La réponse n’utilise pas d’argot et indique ce qui se passe ensuite. » Ajoutez ensuite les cas et le seuil.

Vérifiez votre compréhension

Grace écrit : « Les réponses doivent être correctes. » Nommez les quatre parties manquantes, avec un exemple pour chacune.

Afficher la réponse

1. Quoi vérifier dans une sortie : par exemple, la réponse contient la prochaine étape que la politique indique pour ce cas.
2. Sur quels cas : par exemple, les cas de développement qui ont une prochaine étape.
3. Comment le vérifier : par exemple, une règle sur les formulations dans le code. Une personne suit des instructions écrites quand le code ne peut pas trancher.
4. Le seuil : par exemple, tous les cas, pour les étapes exigées par la politique.

Testez ensuite le critère : deux personnes qui vérifient la même réponse doivent obtenir la même réponse.

Vérifiez votre compréhension

Pourquoi les critères doivent-ils exister avant que quiconque regarde les sorties de la nouvelle version?

Afficher la réponse

Si vous lisez les sorties d’abord, les critères tendent à décrire ce que la nouvelle version fait bien. Elle les respecte donc. Les critères doivent venir des besoins des gens : l’équipe de soutien, les clients et les responsables du produit. Écrits d’abord, ils vérifient aussi ce que la nouvelle version fait mal ou oublie. Un examen de conduite fonctionne de la même façon : le formulaire existe avant le trajet.

Études de cas de ce cours

À la fin du cours, vous appliquez ce que vous avez appris à un projet réaliste, des données jusqu’à la recommandation. Terminez-en au moins une pour obtenir le certificat; les autres sont facultatives.

• Calibrer un juge modèle par rapport à des notes humainesMesurer à quel point un juge modèle est d'accord avec plusieurs évaluateurs humains sur un jeu de données ouvert, trouver son biais d'ordre et décider où des personnes doivent encore réviser.
• Évaluer des résumés par rapport aux notes d'expertsComparer des mesures automatiques de la qualité des résumés avec les notes d'experts sur un jeu de données ouvert, et trouver quelle mesure s'accorde avec les experts pour quelle qualité.
• Tester la régression d'une nouvelle version d'un classificateur, par sous-groupeComparer deux versions d'un classificateur sur un jeu ouvert étiqueté, au total et par sous-groupe, avec des intervalles, puis prendre une décision de mise en production en nommant les points bloquants.

Récapitulatif

• « Ça semble mieux » est une affirmation vague sur la qualité. Deux bonnes réponses, choisies après lecture, ne prouvent rien sur des centaines de billets.
• Un critère dit ce qu’une bonne sortie doit faire. Il est mesurable quand deux personnes qui vérifient la même sortie obtiennent la même réponse.
• Un critère mesurable a quatre parties : quoi vérifier dans une sortie, sur quels cas, comment le vérifier et le seuil.
• Pour Larkfield, les besoins se divisent en cinq catégories : justesse, utilité, sécurité, latence et coût. La plupart des preuves se trouvent dans les étiquettes de chaque cas des données d’évaluation. Le temps et le coût viennent de chaque sortie enregistrée.
• Les seuils sont des décisions sur le coût de chaque erreur. Certains critères doivent toujours être respectés.
• Écrivez les critères avant de regarder les sorties de la nouvelle version.

Ensuite, vous choisissez à quel niveau vérifier chaque critère : une simple fonction, une partie de l’assistant, un billet entier ou la production. Vous configurez aussi le projet.

Leçon suivante : Choisir les niveaux d'évaluation