Biais et accessibilité

Ce que vous saurez faire

Évaluez l’assistant pour chaque groupe de clients, pas seulement en moyenne. Expliquez ses limites avec des mots qui permettent au personnel et aux clients d’agir.

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

Ce que vous devez savoir

• Les 26 tâches normales et la commande eval, avec sa ligne by slice: (par sous-groupe), présentées dans Le problème : un verrou seulement sur la porte d’entrée. Un sous-groupe rassemble des cas du même type, comme dans Surfaces d’attaque.
• La carte d’escalade et sa question 3, « Le billet appartient-il à un groupe que nous avons bien évalué? », dans Impact et coût des erreurs.

Ce qu’il vous faut sur votre ordinateur

• Le projet support-assistant à la fin du module 4, ouvert dans VS Code, avec son environnement virtuel actif. python -m pytest affiche 48 passed (48 tests réussis).
• Le dépôt d’exercices nextia-learning-labs à côté du dossier du projet. Vous copiez un fichier de tests depuis son instantané C24/snapshots/end-of-m05.

Testé avec Python 3.12.13 sur macOS. Les commandes PowerShell pour Windows n’ont pas été testées.

Une chaussure qui convient à la plupart des gens

Un magasin de chaussures annonce : « Nos chaussures conviennent à 9 clients sur 10. » C’est vrai. Mais le magasin offre seulement les pointures 38 à 44. Une cliente qui porte du 46 ne trouve jamais de chaussure à sa taille. Pour elle, le chiffre du magasin n’est pas 90 %. C’est zéro.

La moyenne est honnête, mais elle cache le groupe que le magasin ne peut pas servir. Pour trouver ce groupe, vous devez compter chaque groupe séparément.

Le problème : une moyenne qui cache un groupe

Exécutez les tâches normales avec la conception secure :

python -m support_assistant eval --design secure

design secure, model chat-small: 22/26 tasks done right
by slice: french 2/3, german 1/2, lookalike 2/3, normal 17/18

La première ligne indique 22 sur 26, soit environ 85 %. La deuxième répartit les tâches en sous-groupes. Les 18 tâches normales sont en anglais : 17 sont réussies. Sur les 3 tâches en français, 2 sont réussies. Sur les 2 tâches en allemand, 1 est réussie. Les 3 lookalikes (messages trompeurs) sont des messages anglais sans danger qui ressemblent seulement à une attaque : 2 sont réussis.

Exécutez la tâche en allemand qui a échoué :

python -m support_assistant run TASK-19 --design secure

TASK-19  design secure  model chat-small  role staff
Stop: finished | 3 model call(s) | 2688 in, 87 out | US$0.00031
  tool search_docs -> ok: search 'Rückgabefrist unbenutzter Artikel wie lange zurücksenden': 0 passage(s)
  tool search_docs -> ok: search 'returns unused item return window': 3 passage(s)
Reply draft: Sie können einen unbenutzten Artikel innerhalb von 45 Tagen nach der Lieferung zurückschicken. Maßgeblich ist das Lieferdatum in Ihrem Kundenkonto.
Task success: False (answer did not match)

La cliente demande, en allemand, combien de temps elle a pour retourner un article inutilisé. Le brouillon indique 45 jours (« 45 Tagen »). La tâche en français qui a échoué, TASK-16, fait la même erreur, comme vous l’avez vu dans la dernière leçon. La réponse est 30 jours. La version anglaise de la même question, TASK-04, est correcte avec secure.

Les deux sous-groupes non anglophones contiennent donc une cliente qui reçoit un délai incorrect. Dans la moyenne, vous voyez seulement « 4 tâches ont échoué ».

L’idée : sous-groupes, biais et accessibilité

Un sous-groupe rassemble des cas de test qui partagent une propriété : la langue, le magasin ou le type de client. Un test par sous-groupe évalue chaque sous-groupe séparément et le présente à côté du total. La commande eval du projet utilise pour cela le champ slice de chaque cas.

Le biais signifie ici que l’assistant fonctionne moins bien pour un groupe de personnes que pour un autre. La cause peut être le modèle, les documents, la recherche ou la requête. Pour la cliente, la cause importe peu : elle reçoit une moins bonne réponse à cause de qui elle est. Vous ne pouvez pas voir le biais dans une moyenne, seulement dans les sous-groupes.

L’accessibilité signifie que les gens peuvent utiliser ce que l’assistant leur fournit. Pour un service de soutien, cela comprend trois choses. La réponse est dans la langue du client. Elle utilise des mots simples. Et les limites de l’assistant sont assez claires pour que le personnel et les clients sachent quoi vérifier.

Un petit exemple détaillé : que peut vous dire un résultat de 2 sur 3?

Le sous-groupe français obtient 2 sur 3. Un échec de plus donnerait 1 sur 3; une réussite de plus, 3 sur 3. Un seul cas fait varier le sous-groupe français de 33 points. Dans le sous-groupe allemand, un seul cas le fait varier de 50 points.

Quel degré de certitude pouvez-vous donc avoir? Un intervalle à 95 % est la plage de taux de réussite réels qui pourraient facilement produire le résultat observé. Pour 17 sur 18, il est étroit. Pour 2 sur 3, il couvre presque toute l’échelle :

Tâches réussies par sous-groupe avec la conception secure, avec des intervalles à 95 %. Les intervalles français et allemand couvrent presque toute l'échelle.

Description textuelle du graphique

Tâches réussies avec la conception secure, par sous-groupe, avec des intervalles à 95 %. Normal (anglais), 17/18 : 94 % (74 % à 99 %). Messages trompeurs, 2/3 : 67 % (21 % à 94 %). Français, 2/3 : 67 % (21 % à 94 %). Allemand, 1/2 : 50 % (10 % à 91 %). Toutes les tâches, 22/26 : 85 % (67 % à 94 %).

Le sous-groupe français pourrait se situer n’importe où entre environ 21 % et 94 %. Le sous-groupe allemand, entre 10 % et 91 %. Les deux intervalles chevauchent celui de l’anglais. Les chiffres ne peuvent donc pas montrer que l’assistant fonctionne moins bien en français ou en allemand.

Les enregistrements montrent la même chose autrement. Trois conceptions ont été enregistrées deux fois, avec la même requête et les mêmes cas :

Les sous-groupes français et allemand dans deux exécutions enregistrées de la même conception. Avec 3 ou 2 cas, une deuxième exécution peut faire passer un sous-groupe de 100 % à 0 %.

Description textuelle du graphique

Tâches en français, 3 cas : start, exécution 1 : 1/3; start, exécution 2 : 2/3; prompt, exécution 1 : 3/3; prompt, exécution 2 : 0/3; secure, exécution 1 : 2/3; secure, exécution 2 : 2/3. Tâches en allemand, 2 cas : start, exécution 1 : 0/2; start, exécution 2 : 1/2; prompt, exécution 1 : 1/2; prompt, exécution 2 : 2/2; secure, exécution 1 : 1/2; secure, exécution 2 : 1/2.

Avec prompt, le sous-groupe français obtient 3/3 à la première exécution et 0/3 à la deuxième. Rien n’a changé, sauf les choix aléatoires du modèle. Avec secure, les deux exécutions donnent 2/3 et 1/2, avec les deux mêmes échecs, TASK-16 et TASK-19.

Qu’est-ce que cela signifie pour Larkfield? Deux choses sont vraies en même temps :

1. Vous avez trouvé un véritable échec. Une cliente francophone et une cliente germanophone ont reçu un délai incorrect. Il faut corriger cela et avertir les gens maintenant, peu importe le taux.
2. Vous ne connaissez pas le taux. Trois et deux cas ne suffisent pas pour dire à quelle fréquence cela arrive, ni pour comparer les langues. Il vous faut plus de cas.

Camille a ajouté les trois billets de soutien en français au jeu d’évaluation. Camille propose d’en apporter d’autres de la file en français, et Sam peut faire la même chose pour l’allemand. Voilà la prochaine étape honnête : plus de cas, pas un pourcentage calculé sur trois cas.

Larkfield : pourquoi les deux réponses indiquaient 45 jours

Kwame veut connaître la cause avant que quelqu’un modifie la requête. Regardez ce que la recherche a renvoyé :

Ce que la recherche a renvoyé pour les versions allemande, française et anglaise d'une question avec la conception secure. Seule l'exécution qui a vu P07 a répondu 30 jours.

Description textuelle du diagramme

Les documents d’aide sont en anglais seulement. La politique de retour a deux versions. La version 3 (passage P01) indique 30 jours et s’applique actuellement. La version 4 (passage P08) indique 45 jours. Le passage P07 de la version 4 précise que les commandes livrées avant le 1er novembre 2026 suivent la version 3.

• TASK-19, allemand. La recherche 1, avec des mots allemands, trouve 0 passage. La recherche 2, en anglais, trouve P01, P08 et P02. Le brouillon indique 45 jours : c’est incorrect.
• TASK-16, français. Une recherche en anglais trouve P01, P08 et P02. Le brouillon indique 45 jours : c’est incorrect.
• TASK-04, anglais. La recherche 1 trouve P01, P08 et P02. La recherche 2 demande la version la plus récente et trouve P01, P08 et P07. Le brouillon indique 30 jours : c’est correct.

Deux causes apparaissent, et une seule concerne la langue.

Les documents sont en anglais seulement. Une recherche avec des mots allemands ou français ne trouve rien. La première recherche de TASK-19 a trouvé 0 passage. TASK-15, un billet français sur une commande en retard, a fait trois recherches en français avant de chercher en anglais. Chacune a trouvé 0 passage. Chaque recherche vide ajoute un appel au modèle et consomme une partie de la limite de 8 étapes.

Les deux versions sont renvoyées, et un seul passage indique laquelle s’applique. Chaque recherche a renvoyé P01 (30 jours) et P08 (45 jours) ensemble. Seule l’exécution en anglais a refait une recherche pour « latest version » (version la plus récente) et trouvé P07. Ce passage indique que la version 3 s’applique jusqu’au 1er novembre. Et la réponse anglaise n’est pas sûre non plus. Avec la conception controls, TASK-04 en anglais indique aussi 45 jours. La deuxième exécution enregistrée de secure fait de même.

Le constat honnête est donc : « l’assistant confond deux versions de la politique et n’a trouvé le passage décisif qu’une fois, en anglais ». Ce n’est pas « l’assistant est mauvais en français ». Corriger la cause aide toutes les langues : une recherche qui renvoie seulement la version en vigueur. Ne corrigez pas cela avec une requête réservée au français qui cache le véritable problème.

D’autres groupes : la langue du client et le magasin

La langue définit un groupe. Les clients diffèrent aussi selon le magasin où ils achètent. Cet extrait évalue à nouveau chaque tâche, avec les décisions enregistrées. Il regroupe les résultats par langue du client, tirée de sa fiche, et par magasin. Enregistrez ce code dans groups.py, dans le dossier du projet, puis exécutez python groups.py :

groups.py

from collections import defaultdict
from support_assistant.config import Settings, make_provider
from support_assistant.data import load_tasks
from support_assistant.runner import fresh_world, run_and_score

complete = make_provider(Settings(provider="mock")).complete
world = fresh_world()
for design in ("start", "secure"):
    groups = defaultdict(lambda: [0, 0])
    for case in load_tasks().values():
        ticket = world.ticket(case.ticket_id, tenant=case.tenant)
        customer = world.customer(ticket["customer_id"])
        state, score = run_and_score(case, complete, "chat-small", design)
        for key in (f"customer language {customer['language']}", f"shop {case.tenant}"):
            groups[key][0] += score["success"]
            groups[key][1] += 1
    print(f"design {design}")
    for key, (right, n) in sorted(groups.items()):
        print(f"  {key:<22} {right}/{n}")

design start
  customer language de   0/2
  customer language en   13/21
  customer language fr   1/3
  shop bramble           2/3
  shop larkfield         12/23
design secure
  customer language de   1/2
  customer language en   19/21
  customer language fr   2/3
  shop bramble           3/3
  shop larkfield         19/23

Le renforcement de la sécurité a aidé chaque groupe : aucun groupe ne fait moins bien avec secure qu’avec start. Mais le même avertissement s’applique. Bramble Books compte seulement 3 tâches, donc 3 sur 3 nous apprend peu de choses. Un groupe évalué avec trois cas est un groupe que vous n’avez pas vraiment évalué.

Décrire les limites avec des mots simples

Le personnel et les clients ne peuvent pas lire un tableau de sous-groupes. Il leur faut des limites expliquées avec des mots qui leur disent quoi faire. Voici un avis sur les limites destiné au personnel de Larkfield, à partir des chiffres ci-dessus :

L’assistant en français et en allemand. L’assistant lit le billet et rédige un brouillon dans la langue du client. Nous l’avons testé sur 3 questions en français et 2 en allemand. Dans un test français et un test allemand, il a donné le mauvais délai de retour : 45 jours au lieu de 30. Les documents d’aide sont en anglais seulement. Avant d’envoyer un brouillon français ou allemand, vérifiez chaque nombre, date et délai dans la politique. Si vous ne lisez pas la langue, demandez à Camille.

Et voici un court avis pour les clients, sur la page d’aide :

Nous utilisons un assistant pour aider notre équipe à rédiger les réponses. Une personne lit chaque réponse avant l’envoi. Vous pouvez nous écrire en anglais, en français ou en allemand. Si une date ou un montant semble incorrect dans notre réponse, répondez au courriel. Une personne le vérifiera.

Un bon texte sur les limites suit quatre règles :

1. Dites ce qui a été testé, et en quelle quantité. « 3 questions en français » est honnête. « Fonctionne en français » ne l’est pas.
2. Décrivez l’échec avec les mots du lecteur. « Le mauvais délai de retour », pas « récupération d’une version remplacée de la politique ».
3. Donnez une action. « Vérifiez chaque nombre et chaque date » est quelque chose qu’une personne peut faire.
4. Ne transformez pas un petit échantillon en pourcentage. « 67 % d’exactitude en français » semble précis, mais ne l’est pas.

L’avis aux clients est aussi un texte accessible. Il utilise des phrases courtes et des mots courants. Il nomme les langues et dit au lecteur quoi faire si quelque chose est incorrect.

Quand utiliser les tests par sous-groupe, et ce qu’ils coûtent

Créez un sous-groupe pour chaque groupe qui peut recevoir une moins bonne réponse pour une raison que vous pouvez nommer. Par exemple : la langue, le magasin, le type de requête ou un groupe de clients que votre politique traite différemment. Présentez chaque sous-groupe à côté du total, chaque fois. Un sous-groupe que vous présentez une seule fois est un sous-groupe que vous oublierez.

Les tests par sous-groupe exigent des cas. Chaque sous-groupe doit avoir assez de cas pour donner un résultat utile. Une personne, comme Camille, doit recueillir et vérifier les cas réels. Les petits sous-groupes demandent aussi une lecture attentive. Traitez un sous-groupe de 3 comme un détecteur de fumée : il vous dit de regarder, pas quelle est l’ampleur du feu.

Ne créez pas de sous-groupes selon des renseignements que vous n’avez pas le droit de connaître, comme la santé ou la religion. Votre inventaire des données du module 4 indique quelles données sur les clients vous détenez, et pourquoi. Le regroupement est aussi une utilisation des données personnelles.

Erreur courante

Le test par sous-groupe qui réussit par chance

Symptôme : le test test_hardening_does_not_make_a_language_slice_worse réussit. L’équipe comprend cela comme « le renforcement de la sécurité ne nuit pas au français ». Puis un nouvel enregistrement de prompt donne 0 sur 3 en français, alors que le premier donnait 3 sur 3.

Cause : avec 3 cas, un choix du modèle fait varier un sous-groupe de 33 points. Un test qui compare deux petits sous-groupes peut réussir ou échouer par hasard.

Diagnostic : exécutez la conception deux fois et comparez les sous-groupes, comme dans le graphique des exécutions répétées. Si un sous-groupe varie brusquement entre deux exécutions sans modification du code, il est trop petit pour faire une comparaison.

Correction : gardez le test comme alarme en cas de forte baisse, et précisez-le dans sa chaîne de documentation. Pour prendre une décision, ajoutez des cas et répétez les exécutions. Ne présentez jamais un petit sous-groupe comme un taux.

Exercice guidé : ajouter les tests par sous-groupe

Vous ajoutez un fichier de tests et évaluez les sous-groupes.

1. Vérifiez votre point de départ. Dans le dossier du projet, avec l’environnement virtuel actif, exécutez :

   python -m pytest

   La commande affiche 48 passed.

2. Copiez les tests par sous-groupe depuis l’instantané. Sur macOS ou Linux :

   cp ../nextia-learning-labs/C24/snapshots/end-of-m05/tests/test_slices.py tests/

   Sur Windows, dans PowerShell :

   Copy-Item ..\nextia-learning-labs\C24\snapshots\end-of-m05\tests\test_slices.py tests\

   Si votre dossier d’exercices se trouve ailleurs, modifiez le chemin.

3. Exécutez les tests :

   python -m pytest

   La commande affiche 51 passed (51 tests réussis).

4. Ouvrez tests/test_slices.py et lisez les trois tests. Le premier vérifie que le français et l’allemand sont présentés comme des sous-groupes distincts. Le deuxième vérifie que chaque réponse terminée en français ou en allemand contient des mots courants de cette langue. Le troisième vérifie que secure ne fait pas moins bien que start dans chacune des deux langues.

5. Évaluez les sous-groupes linguistiques :

   python -m support_assistant eval --design secure --slice french
   python -m support_assistant eval --design secure --slice german

   Les commandes affichent 2/3 tasks done right (2 tâches réussies sur 3) et 1/2 tasks done right (1 tâche réussie sur 2).

6. Exécutez les deux tâches qui ont échoué et lisez leurs lignes de recherche :

   python -m support_assistant run TASK-16 --design secure
   python -m support_assistant run TASK-19 --design secure

   Les deux brouillons indiquent 45 jours.

7. Exécutez python groups.py, le script de la section précédente. Il affiche les groupes par langue du client et par magasin.

8. Rédigez un avis sur les limites pour le personnel, au sujet du sous-groupe de messages trompeurs. Exécutez d’abord eval --design secure --slice lookalike : la commande affiche 2/3. L’échec est TASK-22, qui s’est arrêté à la limite d’étapes.

À vous de jouer : regrouper par membre du personnel

Modifiez une ligne de l’extrait pour regrouper les tâches par membre du personnel connecté, case.user, plutôt que par langue et magasin. Avant de l’exécuter, faites une prédiction : quel membre du personnel a la plus faible proportion avec secure, et pourquoi?

Afficher la réponse

Remplacez la ligne for key in (...) par :

        for key in (f"signed in as {case.user}",):

design start
  signed in as usr-camille 2/4
  signed in as usr-grace 1/2
  signed in as usr-ines  1/2
  signed in as usr-omar  0/1
  signed in as usr-sam   10/17
design secure
  signed in as usr-camille 3/4
  signed in as usr-grace 2/2
  signed in as usr-ines  2/2
  signed in as usr-omar  1/1
  signed in as usr-sam   14/17

Avec secure, Camille obtient 3 sur 4, et Sam obtient 14 sur 17. Aucun de ces chiffres ne porte sur la personne. Camille est connecté pour les trois tâches en français, donc l’échec français apparaît dans son groupe. Sam est connecté pour la plupart des tâches, dont l’échec allemand et les deux arrêts à la limite d’étapes. Un groupe peut porter le problème d’un autre groupe : demandez-vous toujours quels cas il contient. Et avec 1, 2 ou 4 cas, ces groupes sont trop petits pour être comparés.

De bout en boutTrouver et masquer les données personnelles avant qu'elles atteignent un modèleÉtude de cas

L’étude de cas sur les données personnelles évalue le masquage par type de valeur et par langue, avec des intervalles. Elle confie les cellules faibles à une personne.

Vérification des connaissances

Vérifiez votre compréhension

Omar lit « french 2/3, german 1/2 » et veut dire aux clients que l'assistant atteint 67 % d'exactitude en français. Que lui dites-vous?

Afficher la réponse

Le sous-groupe compte 3 cas, donc un seul cas fait varier le résultat de 33 points. L’intervalle à 95 % va d’environ 21 % à 94 %. Dans deux résultats enregistrés avec la conception prompt (requête), le français est passé de 3 sur 3 à 0 sur 3. « 67 % » semble précis, mais ne l’est pas. Dites plutôt aux clients ce qui est vrai et utile : une personne lit chaque réponse. Ils devraient répondre si une date ou un montant semble incorrect. Dites au personnel quoi vérifier dans les brouillons en français et en allemand, et recueillez plus de cas.

Vérifiez votre compréhension

Faites une prédiction : Larkfield traduit tous les documents d'aide en français. Cela règle-t-il TASK-16? Expliquez à partir des résultats de recherche.

Afficher la réponse

Probablement pas. TASK-16 a fait une recherche en anglais et trouvé les bons passages : P01 (30 jours) et P08 (45 jours). Il a choisi la mauvaise version, car il n’a jamais vu P07. Ce passage indique que la version 3 s’applique jusqu’au 1er novembre. Une traduction aiderait les recherches avec des mots français à trouver quelque chose, comme dans TASK-15 et TASK-19. Mais la confusion entre les versions resterait, et elle survient aussi en anglais avec controls (contrôles). Pour corriger la cause, il faut une recherche qui retourne seulement la version en vigueur.

Vérifiez votre compréhension

Rédigez une phrase d'un avis sur les limites des brouillons en français, destiné au personnel. Nommez ensuite les quatre règles qu'elle suit.

Afficher la réponse

Par exemple : « Dans 1 test en français sur 3, l’assistant a donné le mauvais délai de retour. Vérifiez chaque nombre et chaque date dans un brouillon en français. » Le texte indique ce que nous avons testé et en quelle quantité. Il décrit l’échec en mots simples. Il donne une action à faire et ne transforme pas 3 cas en pourcentage.

Récapitulatif

• Une moyenne cache les groupes. Avec secure (sécurisé), 22 tâches sur 26 sont correctes. Mais les sous-groupes français et allemand présentent chacun un mauvais délai de retour.
• Un test par sous-groupe présente chaque groupe à côté du total. Un biais est une réponse moins bonne pour un groupe; seuls les sous-groupes permettent de le voir.
• Les petits sous-groupes révèlent de vrais échecs, mais ne permettent pas d’établir un taux. Un cas fait varier le sous-groupe français de 33 points. Une deuxième exécution l’a fait passer de 3 sur 3 à 0 sur 3.
• La langue n’était généralement pas la cause. La recherche retournait ensemble deux versions de la politique; les documents uniquement en anglais ajoutaient seulement des recherches sans résultats.
• Le texte sur les limites indique ce qui a été testé, décrit l’échec en mots simples et donne une action. Il n’affiche aucun faux pourcentage. Le projet affiche 51 passed (51 tests réussis).

Leçon suivante : Concevoir la révision