Pas de valeur sans confiance

Le problème principal

Imagine que tu as développé un chatbot. Le système tourne, les premières démos sont prometteuses, les parties prenantes sont enthousiastes. Trois mois après le lancement, tu regardes les statistiques d’utilisation… et elles sont décevantes. Les gens utilisent à peine le bot et quand c’est le cas, surtout pour des questions triviales.

Que s’est-il passé?

Le problème n’est pas que le bot donne de mauvaises réponses, mais que personne ne lui fait confiance. Un chatbot auquel on ne fait pas confiance ne fait pas gagner du temps, il en fait perdre. Les utilisateur·rice·s doivent vérifier chaque réponse, recouper, chercher ailleurs. Dans ce cas, il est du coup plus simple de fouiller directement dans les documents.

La confiance n’est pas un «nice to have», mais la condition de base pour l’adoption. Et la confiance ne naît pas de grandes promesses ou de jolis screenshots. Elle naît d’une qualité démontrable et mesurable, par l’évaluation.

Le client doit savoir ce qu’il veut

Quand je parle de chatbots avec des client·e·s, j’entends souvent: «nous voulons que le bot donne de bonnes réponses.»

Ça paraît raisonnable, mais comme exigence, c’est beaucoup trop flou. Qu’est-ce que «bon» veut dire, au juste?

• Le bot doit-il plutôt donner une réponse incomplète mais correcte, ou une réponse détaillée avec 95% de justesse?
• A-t-il le droit de dire «Je ne sais pas», ou doit-il toujours essayer de répondre?
• Quel ton est souhaité: factuel-formel ou plutôt chaleureux-personnel?
• Comment gère-t-il des informations contradictoires dans les sources?
• À quel niveau de détail les réponses doivent-elles être: simple résumé ou information complète?

Ces questions, à priori banales, définissent si un chatbot est «bon» ou non. Souvent, les client·e·s ignorent leur besoin, jusqu’au moment de voir de mauvais exemples. C’est pour ça que l’on a besoin d’évaluations humaines.

Évaluations humaines: vraiment comprendre le client

Passons au concret. Les exigences sont clarifiées, le périmètre est défini. Il s’agit maintenant de comprendre ce que «bon» veut dire dans la pratique. Mais comment le découvrir?

La réponse: d’abord manuellement.

Je sais, dans un monde d’IA, de "LLM-as-a-Judge" et de métriques automatisées, ça paraît un peu old school. Mais on ne peut pas construire une évaluation automatisée si l’on ne sait pas ce qu’il faut évaluer. Et ça, on ne le découvre qu’en laissant de vraies personnes évaluer de vraies réponses.

Constituer un jeu d’évaluation et définir les dimensions de qualité
D’abord, il faut des questions représentatives, entre 50 et 200, idéalement de vraies questions d’utilisateur·rice·s. Pas les exemples de démo faciles, mais des questions du quotidien:

• Questions standard fréquentes: «comment puis-je me connecter?», «où se trouve l’urgence?»
• Cas limites: «quand dois-je saisir mes vacances en tant qu’employé·e de l’administration?», «donne-moi une bonne recette de pizza»
• Questions ambiguës: «comment puis-je me connecter?»
• Questions qui ne peuvent pas être répondues à partir des documents: «Berne est-elle meilleure que Bâle?», «Qui est Margaret Thatcher?»

Pour chaque question, une réponse est générée. En parallèle, l’équipe principale (et idéalement d’autres parties prenantes) définit les dimensions d’évaluation, toutes les dimensions n’ayant pas la même importance dans chaque contexte.
En général, nous utilisons les critères suivants:

• Exactitude: l’information est-elle correcte? Existe-t-il seulement un vrai/faux
• Exhaustivité: l’information est-elle complète? Des aspects importants manquent-ils?
• Tonalité: le ton correspond-il à ce que nous voulons? (Pour ça, Textmate peut aussi être très utile.)

Évaluer

Vient ensuite la partie fastidieuse: plusieurs personnes évaluent chaque paire question–réponse selon les dimensions définies.

1. Bon/pas bon: pour chaque dimension, on décide si la réponse est «bonne» ou non.
2. Justification: chaque évaluation doit être justifiée. Ça peut sembler lourd, mais c’est essentiel: c’est comme ça qu’émerge une compréhension commune de ce qui est «bon».
3. Évaluation à l’aveugle: les évaluateur·rice·s ne devraient pas voir ce que les autres ont noté. Si les résultats divergent fortement, c’est que les critères sont trop flous.
4. Discussion: en cas de divergences, une discussion commune aide. Ces échanges sont souvent la partie la plus précieuse du processus.

Après 50 à 100 exemples évalués, on obtient une image claire de la situation de départ et, la plupart du temps, aussi de ce qu’il reste à faire.

Les outils pour passer à l’échelle supérieure

Mais l’évaluation manuelle a ses limites quand il s’agit de passer à l’échelle supérieure. En effet, évaluer 100 questions à la main, c’est faisable. 1'000, c’est pénible. 10'000 en monitoring continu? Mission impossible.
C’est là que les outils entrent en jeu.

"LLM-as-a-Judge": le principe

L’idée est simple: un LLM évalue les réponses du chatbot selon des critères définis. En résumé, il lui faut:

1. La question
2. La réponse de ton système
3. Le gold standard (à quoi la réponse devrait idéalement ressembler)

L’«évaluateur» fournit ensuite un verdict et une justification.

Le plus gros risque: remplacer un problème (évaluer le chatbot) par un autre (évaluer l’évaluateur). C’est pour ça que l’évaluation automatisée doit être calibrée. Pour cela, nous prenons en général 50 à 100 exemples évalués manuellement et les soumettons en plus au LLM. Si les résultats concordent, le Judge fonctionne de manière fiable.

Ensuite commence l’amélioration continue, mais nous en parlerons une autre fois. Au bout de ce cycle d’améliorations vient le grand moment: le go-live.

Go-live et monitoring continu

Nous recommandons de faire le go-live sans grande annonce dans un premier temps. Ainsi, le chatbot peut être encore amélioré au cours des premiers jours, sur la base des vraies questions des utilisateur·rice·s.

Le travail n’est pour autant pas terminé: l’évaluation continue est essentielle. Des métriques particulièrement utiles sont par exemple:

• La part de questions non répondues
• La groundedness (en gros: le bot hallucine-t-il ou les faits proviennent-ils des sources?)
• Des échantillons contrôlés par des humain·e·s, surtout en cas de mauvaise évaluation ou de manque de groundedness
• Et pour finir, mais pas des moindres: le feedback des utilisateur·rice·s.

Avec des métriques faciles à comprendre, il est possible de surveiller sérieusement un chatbot, même avec 10'000 questions ou plus, sans devoir vérifier chaque question individuellement.

L’évaluation n’est pas un «nice to have»

La différence entre un chatbot qui fonctionne et un chatbot qui foire ne réside pas dans le meilleur modèle d’embedding, dans le dernier LLM ou dans l’algorithme de retrieval le plus pertinent.
Elle réside dans la volonté d’investir du temps dans l’évaluation.

Dans des évaluations humaines.
Dans du monitoring automatisé.
Dans une amélioration continue.

C’est seulement ainsi que naît la confiance, à la base de toute adoption.