Pour évaluer un assistant IA, commencez par lire ses réponses avec les informations qu’il avait à disposition. Notez les erreurs précises, choisissez celles qui comptent pour vos utilisateurs, puis construisez les tests capables de les détecter. Un score global ne vous dira pas, à lui seul, quoi corriger.
Je développe Nelmie, un assistant IA pour les hôtels, chambres d’hôtes et gîtes. Dans ce contexte, une réponse peut être claire, polie et commercialement problématique.
Imaginons un établissement dont la documentation indique : « Petit-déjeuner servi de 7 h à 10 h. » Un voyageur demande les horaires. L’assistant répond : « Le petit-déjeuner est servi tous les jours de 7 h à 10 h. »
L’horaire est correct. Mais « tous les jours » ajoute une information absente de la source.
Cet exemple est fictif. Il illustre le niveau de précision nécessaire pour évaluer un produit : une petite addition dans une phrase peut devenir une promesse faite au client.
Une mauvaise note ne donne pas une priorité
Supposons que cette réponse obtienne une bonne note de clarté et une note moyenne d’exactitude. Que doit faire l’équipe avec ce résultat ?
Changer le modèle ? Modifier les instructions ? Compléter la documentation ?
Le score ne permet pas de trancher. Il faut revenir à la réponse et nommer le problème : l’assistant a ajouté une fréquence que les informations disponibles ne permettaient pas d’affirmer.
La différence est pratique. « Améliorer l’exactitude » laisse tout le travail de diagnostic à faire. « Empêcher l’ajout de conditions absentes des sources » définit un comportement à examiner.
Une eval associe des cas de test à une manière de juger le résultat. Son intérêt dépend donc de ce qu’elle vérifie.
Un benchmark général peut aider à comparer des modèles. Il ne suffit pas à savoir si votre assistant respecte les informations de chaque établissement.
Lire les interactions avant de choisir les critères
La première étape consiste à réunir des interactions suffisamment variées : questions simples, demandes ambiguës, échanges en plusieurs langues, informations manquantes.
La réponse finale ne suffit pas toujours. Pour comprendre ce qui s’est passé, il faut également voir la question, l’historique utile, les documents récupérés et les résultats des outils. Cet ensemble constitue la trace de l’interaction.
Dans notre exemple, une autre source précisait-elle les jours d’ouverture ? Le système avait-il récupéré la documentation du bon établissement ? L’information était-elle contradictoire ?
Commencez par noter ce qui semble incorrect, sans imposer une grille trop tôt. Les catégories viendront en regroupant les observations proches.
Hamel Husain et Shreya Shankar proposent de commencer avec environ 100 traces diversifiées, puis de poursuivre tant que la lecture apporte de nouvelles catégories d’échec. Ce nombre est un repère de travail, pas une certification de qualité. Leur méthode d’analyse des erreurs.
Pour Nelmie, les situations à examiner pourraient notamment être :
| Situation illustrative | Erreur à rechercher |
|---|---|
| La documentation donne un horaire sans préciser les jours | Ajout d’une fréquence non documentée |
| Le voyageur pose sa question en allemand | Réponse dans une autre langue |
| Deux sources se contredisent | Réponse affirmative sans signaler l’incertitude |
| Une demande de réservation a été enregistrée | Présentation de la réservation comme confirmée |
Ces formulations décrivent ce que l’utilisateur subit. Elles permettent ensuite de construire des contrôles distincts.
La personne qui connaît le métier doit participer à cette lecture. Un développeur peut vérifier un format. Un hôtelier peut reconnaître une formulation qui engage l’établissement au-delà de ses conditions réelles.
Prioriser avant d’automatiser
Toutes les erreurs n’ont pas la même conséquence.
Une formule de politesse maladroite mérite peut-être une correction. Une réservation annoncée comme confirmée alors qu’elle reste en attente peut provoquer un déplacement inutile, un conflit à l’accueil ou une perte de confiance.
Je regarderais d’abord la gravité pour l’utilisateur, puis la fréquence observée et le coût de traitement. Une erreur rare peut passer avant une maladresse fréquente si ses conséquences sont plus lourdes.
Il faut aussi distinguer découverte et mesure. Si vous sélectionnez volontairement beaucoup de conversations difficiles, leur taux d’échec ne représente pas celui de l’ensemble des utilisateurs. Vous avez constitué un échantillon pour trouver des problèmes.
À ce stade, certaines corrections seront évidentes. Une page obsolète doit être mise à jour. Une information essentielle manque peut-être dans le profil de l’établissement. Un message de confirmation peut provenir du code de l’interface.
Découvrir une erreur ne signifie pas automatiquement qu’il faut modifier le modèle ou construire un juge IA.
Choisir le contrôle qui correspond à l’erreur
Lorsqu’une règle permet de trancher, le code constitue un bon point de départ.
Prenons la réservation. Si le système connaît son statut, l’interface peut distinguer une demande enregistrée d’une réservation confirmée. Cette différence doit être conservée jusqu’au message présenté au voyageur.
D’autres vérifications sont également explicites : présence des champs obligatoires, validité d’un identifiant, correspondance entre l’établissement demandé et celui des documents récupérés.
Le contrôle doit lui-même être vérifié avec des cas corrects, des erreurs et des situations limites.
L’ajout « tous les jours » pose une autre difficulté. Comparer le sens d’une réponse avec celui des sources peut demander une interprétation. Un modèle évaluateur peut alors aider, avec une mission étroite :
Déterminer si la réponse ajoute une information sur les horaires ou les jours d’ouverture que les sources fournies ne permettent pas d’affirmer.
Il reçoit les sources, la réponse et des exemples déjà jugés. Son verdict porte sur ce critère précis.
Un résultat binaire, conforme ou non conforme, oblige à clarifier la limite. Une courte justification permet de voir ce qui motive le verdict. Cela rend le contrôle plus facile à discuter qu’une note globale d’exactitude.
Vérifier l’évaluateur avant de lui faire confiance
Le modèle qui juge les réponses peut lui aussi accepter une invention ou rejeter une formulation correcte.
Comparez donc ses décisions à celles d’un humain sur des exemples corrects et incorrects. Gardez des cas distincts pour lui montrer les critères, ajuster ses instructions et effectuer la vérification finale.
Examinez les deux directions de l’erreur : les mauvaises réponses qu’il laisse passer et les bonnes réponses qu’il refuse. Un évaluateur trop indulgent masque les problèmes. Un évaluateur trop strict multiplie les alertes et peut pousser l’équipe à dégrader des réponses utiles.
Cette validation demande une attention particulière lorsque les erreurs sont rares. Un juge qui répond presque toujours « conforme » peut sembler performant tout en manquant les cas qui vous préoccupent.
L’objectif est de connaître suffisamment ses limites pour décider à quoi ses résultats peuvent servir.
Corriger, puis vérifier ce que la correction change
Revenons au petit-déjeuner.
Si les jours d’ouverture existent dans la documentation mais ne sont jamais récupérés, le travail porte d’abord sur la recherche des sources. Si les bons passages sont présents et que l’assistant ajoute malgré tout une fréquence, il faut examiner la génération de la réponse.
Si l’information manque partout, l’établissement doit soit la préciser, soit accepter que l’assistant indique qu’une confirmation est nécessaire.
Ces situations peuvent produire la même réponse incorrecte. Elles ne demandent pas la même intervention.
Après une correction, rejouez le cas concerné, puis les autres cas importants. Vérifiez notamment que l’assistant répond encore lorsque la documentation contient une information complète. Une modification qui empêche toute invention en refusant systématiquement de répondre serait difficilement utile.
Conservez les cas pour les changements suivants, tout en continuant à lire de nouvelles interactions. Les évaluations automatiques, le suivi en production et la revue humaine apportent des informations complémentaires. Anthropic décrit cette combinaison dans sa méthode d’évaluation des agents.
Ce qu’il faut retenir
L’analyse des erreurs transforme une impression de qualité en problèmes que l’équipe peut traiter. Elle permet de choisir les contrôles utiles et de vérifier les effets d’une modification.
Pour un produit comme Nelmie, le travail consiste à relier chaque réponse aux informations de l’établissement, à la demande du voyageur et aux actions réellement effectuées. C’est à ce niveau que l’on peut définir ce qui est acceptable.
Questions fréquentes
Comment commencer sans interactions réelles ?
Construisez des scénarios fictifs à partir des risques du produit : langue différente, information absente, sources contradictoires, demande ambiguë. Faites-les relire par une personne du métier, puis exécutez-les dans le système complet. Ils servent à explorer des erreurs possibles, sans renseigner leur fréquence chez de futurs utilisateurs.
Faut-il attendre cette analyse pour écrire le moindre test ?
Les exigences connues peuvent être testées dès le départ : format attendu, permissions ou statut nécessaire à une confirmation. La lecture des traces complète ce cadre en révélant les problèmes que l’équipe n’avait pas anticipés.
Conclusion
Avant de demander un meilleur score, choisissez une erreur que vous voulez voir disparaître. Retrouvez les informations disponibles au moment de la réponse, définissez ce qui aurait été acceptable, puis vérifiez la correction sur plusieurs cas.
Si votre équipe ne sait pas encore expliquer pourquoi une réponse passe ou échoue, commencez par cette lecture. Et si vous avez besoin de structurer ce travail sur votre produit, prenons 30 minutes pour cadrer la première évaluation.