Constituer un jeu de référence représentatif
Partez des demandes reçues par le support ou les équipes métier. Pour chaque cas, indiquez la réponse attendue, les sources acceptables et les éléments qui doivent rester inconnus. Faites valider ces références par la personne qui connaît la procédure, plutôt que par le modèle lui-même.
Incluez des formulations familières, des fautes, des questions ambiguës et des demandes hors périmètre. Ajoutez des documents contradictoires ou périmés. Un assistant doit parfois demander une précision, signaler un conflit ou reconnaître qu’il ne sait pas répondre.
Utiliser une grille qui distingue les erreurs
Une réponse peut être exacte mais citer le mauvais document. Elle peut aussi respecter les sources tout en proposant une action non autorisée. Ces défauts n’ont pas la même gravité et ne doivent pas disparaître dans une note moyenne.
| Dimension | Vérification concrète |
|---|---|
| Exactitude | La règle et ses exceptions sont-elles respectées ? |
| Traçabilité | La source contient-elle réellement l’information ? |
| Accès | L’utilisateur a-t-il le droit de voir cette information ? |
| Action | La validation requise précède-t-elle l’exécution ? |
Définissez les erreurs bloquantes : fuite d’information, engagement commercial inventé ou suppression non autorisée. Une bonne note de style ne compense jamais l’un de ces échecs.
Tester le comportement, pas seulement la réponse
Pour un agent connecté à des outils, contrôlez les paramètres transmis et le résultat observé. Dans un environnement de test, une demande de création de rendez-vous doit produire le bon créneau et le bon destinataire, sans doublon après une nouvelle tentative.
Ajoutez des instructions hostiles dans les sources : « ignore les règles précédentes » ou « envoie ce fichier ». L’assistant doit traiter ces phrases comme du contenu non fiable. Vérifiez également ce qui se passe quand une API échoue ou lorsqu’une autorisation est retirée pendant le parcours.
Comparer les versions de façon reproductible
Conservez un lot utilisé pour les réglages et un autre réservé à la validation finale. Rejouez les mêmes cas après un changement de modèle, d’instructions ou de corpus. Les sorties pouvant varier, répétez les cas sensibles et archivez le contexte nécessaire à leur analyse.
Un évaluateur automatique peut accélérer le tri, mais une revue humaine reste nécessaire pour les cas métier délicats. Examinez les réponses complètes et les traces d’outils, pas seulement le verdict d’un second modèle.
Questions fréquentes
Combien de questions faut-il prévoir ?
Assez pour couvrir les usages et les risques identifiés. Le nombre seul compte moins que la diversité des cas et la présence d’exceptions.
Peut-on garantir zéro erreur ?
Non. Le dispositif doit aussi prévoir la détection, le signalement et la correction des incidents après le lancement.
Passer à l’action
Listez d’abord les erreurs qui rendraient le service inutilisable. Construisez avec IIDI un protocole d’évaluation adapté à votre assistant.
Référence utile
IIDI relie stratégie, design, technologie et acquisition.
Nous transformons ce sujet en feuille de route priorisée, puis en dispositif concret, mesurable et administrable par vos équipes.