Tester un agent IA : savoir refuser compte autant qu’avoir raison
Feriez-vous confiance à un agent IA qui ne dit jamais « je ne sais pas » ?
EN 30 SECONDES
Une suite d’évals est l’ensemble fixe de tests que lit la barrière de mise en production, et elle note cinq points sur une même exécution. Refuser quand la preuve est mince compte autant qu’avoir raison, et une seule attaque réussie bloque le lancement.
À RETENIR · 3
- Dire « je ne sais pas » quand la preuve est mince compte autant que la justesse.
- Deux agents aussi justes l’un que l’autre peuvent recevoir des verdicts différents.
- Une seule attaque réussie bloque la mise en production, même avec une justesse parfaite.
Sur cette page
Les cinq points que la suite note
EN BREF La suite note cinq points, et savoir refuser au bon moment pèse autant que la justesse.
LES MOTS À CONNAÎTRE
- Ancrage
- Chaque affirmation d’une réponse renvoie à un vrai document source qui la soutient.
- Abstention
- L’agent ne répond pas parce que la preuve est trop mince, et transmet le cas à une personne.
- Red-teaming
- Attaquer exprès son propre agent, par exemple avec des instructions cachées dans un document, pour trouver ses failles.
Voilà les dimensions que j’expliciterais pour un agent qui lit des documents. Leurs seuils et leur couverture appartiennent au déploiement testé, fixés avant les tests avec la personne responsable du risque, pas à cet article.
Les contrôles évidents sont l’Ancrage Chaque affirmation d’une réponse renvoie à un vrai document source qui la soutient. Voir le glossaire et les chiffres. Abstention L’agent ne répond pas parce que la preuve est trop mince, et transmet le cas à une personne. Voir le glossaire s’oublie facilement, et cette barrière la note au même titre que la justesse.
EN CLAIR
L’abstention, c’est ce que produit le système de citations vérifiées pendant que l’agent tourne. Ici, la suite vérifie qu’elle tient bon pendant les tests.
Dans la section suivante : Que se passe-t-il quand deux agents sont aussi justes l’un que l’autre ?
Un exemple concret : un « on y va », un « on attend »
EN BREF Deux candidats sur le même jeu figé : l’un part en production, l’autre attend, alors que ses réponses sont tout aussi justes.
Les valeurs ci-dessous sont fictives. La forme, elle, est bien réelle : un candidat, un jeu figé, cinq notes, un verdict.
UN EXEMPLE CONCRET
Chiffres illustratifs
VALIDÉCandidat A : une nouvelle consigne
ENTRÉE
- Candidat
- agent v1.4, nouvelle consigne
- Jeu d’évals
- figé, le même qu’à la version précédente
- Contient
- des cas de preuve manquante
CE QUI SE PASSE
- Ancrage et chiffres : chaque réponse cite un document qui la soutient, chaque montant colle.
- Abstention : sur les cas de preuve manquante, il dit « je ne sais pas » et les passe à une personne.
- Red-teaming : aucune attaque ne passe. Latence et coût : dans les limites.
SORTIE
- Verdict
- ON Y VA, derrière une revue humaine
ON ATTENDCandidat B : un modèle plus rapide
ENTRÉE
- Candidat
- agent v1.5, modèle plus rapide
- Jeu d’évals
- le même jeu figé
CE QUI SE PASSE
- Ancrage et chiffres : aussi bons que chez le candidat A.
- Abstention : une question demande un bail qui manque. Il répond quand même, à partir d’un bail voisin.
- Red-teaming : aucune attaque ne passe.
SORTIE
- Verdict
- ON ATTEND
- Suite
- resserrer l’abstention, rejouer le même jeu
OBJET OBTENU
Bien refuser, ça se note
Dans la section suivante : Et si quelqu’un attaque l’agent exprès ?
Le red-teaming peut tout bloquer
EN BREF Une seule attaque réussie bloque la mise en production, même quand tous les contrôles de justesse sont passés.
La justesse dit que l’agent a raison sur les cas auxquels vous avez pensé. Le Red-teaming Attaquer exprès son propre agent, par exemple avec des instructions cachées dans un document, pour trouver ses failles. Voir le glossaire montre ce qu’il fait sur ceux d’un attaquant. Dans la barrière, le second peut opposer son veto au premier.
EXEMPLE
Chaque tentative d’attaque est une sonde. Un document tente de réécrire les instructions de l’agent : c’est une injection de prompt. Une question cherche à extraire des données qu’il ne devrait pas montrer.
ÉTAPE PAR ÉTAPE
Étape 1. Candidat. Une nouvelle version de l’agent se présente à la barrière.
- Candidat Une nouvelle version de l’agent se présente à la barrière.
- Justesse validée Ses réponses citent de vraies sources et ses chiffres concordent.
- Attaque réussie : bloqué Un document cache une instruction et l’agent la suit. Bloqué, quel que soit le score de justesse.
- Corriger, puis relancer La brèche est fermée et toute la suite repasse. Si tout passe, il part derrière une revue humaine, réévalué si ses données dérivent.
Ranger les failles du red-teaming parmi les problèmes connus à traiter plus tard, c’est laisser partir un agent avec une faille d’injection ouverte.
ATTENTION
Réussir un red-teaming ne revient pas à contenir une attaque. La barrière vérifie la résistance. Le déploiement a encore besoin du principe du moindre privilège, pour qu’une injection réussie ne puisse pas déplacer d’argent : l’agent n’a que les accès que son rôle exige.
FAQ
En finance régulée, une réponse fausse donnée avec assurance coûte plus cher qu’un refus. Si vous ne mesurez que la justesse, un agent qui répond à tout paraît excellent, jusqu’au jour où il aurait dû dire « je ne sais pas ».
NIVEAU TERMINÉ
Ce que vous savez maintenant
- La suite note les sources, les chiffres, les refus, la résistance aux attaques, la vitesse et le coût, sur une même exécution.
- Répondre sans source est un échec, même si la réponse s’avère juste.
- Résister aux attaques ne suffit pas : il faut encore limiter les accès.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Cas fictif : un candidat fait mieux que la version précédente en justesse, mais une attaque lui a fait montrer des données interdites à l’utilisateur. Quel verdict ?
On bloque. Une attaque réussie bloque le lancement, quelle que soit la justesse. On ferme la fuite, puis on relance.
Ancien CTO d’Integra. Auteur nommé (1 sur 5) d’ERC-3643, premier auteur d’ERC-6960, co-auteur d’ERC-7410 et co-auteur d’ERC-8203, encore à l’état de brouillon. Conçoit des systèmes d’IA en production et des systèmes Web3 régulés.
Un projet à livrer ou un poste à pourvoir ?
Parlons de votre besoinSuivre les notes techniques
Recevez les nouveaux articles sur l’IA en production et les smart contracts par email.