Construire l’évaluation à partir des erreurs que le métier doit pouvoir détecter, contenir ou refuser.
Une réponse fluide donne facilement une impression de maîtrise. Pour décider d’un usage professionnel, j’ai besoin d’une autre information : dans quelles circonstances cette réponse devient-elle trompeuse, incomplète ou inutilisable ?
Un cadre plus large que la performance
Le profil du NIST consacré à l’IA générative, publié en juillet 2024, complète son cadre de gestion des risques de l’IA. Il propose d’examiner les risques sur l’ensemble du cycle de vie. Le document aborde notamment les informations erronées produites avec assurance, la confidentialité, la sécurité et les interactions entre humains et systèmes. Il s’agit d’un cadre volontaire, pas d’une certification d’un produit.
Ma lecture : partir du travail réel
Pour un assistant qui aide à retrouver une procédure, je construirais le jeu d’évaluation avec les personnes qui connaissent les documents. Une question facile et bien documentée. Une question ambiguë. Une procédure remplacée par une nouvelle version. Une demande qui n’a pas de réponse dans le corpus. Une pièce à laquelle l’utilisateur ne doit pas accéder.
Ces situations sont des exemples de conception. Elles permettent d’examiner plusieurs qualités qui ne se résument pas à une note moyenne : retrouver la bonne information, citer la bonne source, reconnaître une absence de réponse et respecter le périmètre d’accès.
Définir ce qui permet d’accepter le résultat
Le protocole peut rester simple :
- Décrire le résultat attendu pour chaque situation avant de tester le système.
- Identifier les erreurs bloquantes, même si elles sont rares.
- Conserver les entrées, les versions utiles et les résultats pour comparer les évolutions.
- Prévoir la reprise par un humain et mesurer si elle reste réellement possible.
Une modification du corpus ou d’un connecteur peut changer le comportement autant qu’un nouveau modèle. Le jeu de tests doit donc devenir un outil d’exploitation, et continuer à évoluer avec les erreurs observées.
Le passage en production se discute alors avec des éléments concrets : les usages qui fonctionnent, ceux qui nécessitent une relecture et ceux qui restent hors périmètre. C’est une conversation plus exigeante qu’une démonstration. Elle est aussi beaucoup plus utile.
Lire la version en mots simples
Une démonstration montre qu’une IA sait réussir un exemple. Avant de lui confier un travail régulier, il faut aussi savoir ce qu’elle fait quand la question est ambiguë, quand un document manque ou quand elle ne connaît pas la réponse.
Une réponse assurée n’est pas une preuve
Un texte bien écrit peut contenir une erreur. Il peut aussi s’appuyer sur une ancienne procédure ou donner une réponse alors que les documents disponibles ne permettent pas de conclure. La qualité de la rédaction et la fiabilité de l’information sont deux choses à vérifier.
Le document du NIST cité ici est un cadre de réflexion sur les risques de l’IA générative, publié en juillet 2024. Il aide à organiser cette vérification. Ce n’est pas un label qui certifie qu’un produit est fiable.
Tester avec ceux qui connaissent le travail
Imaginons un assistant qui aide les agents d’une collectivité à retrouver des procédures. Je préparerais les questions de test avec les personnes qui utilisent et mettent à jour ces documents. Elles savent reconnaître une réponse utile et repérer une erreur gênante.
- Une question simple dont la réponse est clairement présente.
- Une question qui peut se comprendre de plusieurs façons.
- Une ancienne procédure qui a été remplacée.
- Une question à laquelle les documents ne répondent pas.
- Une demande d’information que l’utilisateur n’a pas le droit de consulter.
Décider avant le test de ce qui est acceptable
Pour chaque cas, on décrit la réponse attendue et les erreurs qui empêcheraient d’utiliser le service. On garde ensuite les résultats pour comparer les changements. Une amélioration sur les questions faciles ne doit pas masquer une erreur grave ailleurs.
Il faut aussi vérifier qu’un humain peut reprendre le travail lorsqu’il y a un problème. Dire « quelqu’un vérifiera » ne suffit pas si cette personne n’a ni les informations ni le temps nécessaires.
Ce que je recherche, c’est une décision fondée sur des essais concrets : ce que l’on peut utiliser, ce qui demande une relecture et ce qu’il vaut mieux laisser de côté pour le moment.
