Agents IA

Pourquoi un agent doit savoir dire « je ne sais pas »

C'est la propriété la moins spectaculaire d'un agent IA, et la plus importante en production. Un système qui invente une réponse plausible est plus dangereux qu'un système qui n'en donne pas.

Pourquoi un agent doit savoir dire « je ne sais pas » — AI MONITORING

Le problème de fond

Un modèle de langage produit du texte vraisemblable. Ce n'est pas la même chose que du texte vrai.

Face à une question dont la réponse n'est pas dans sa matière, un modèle brut ne s'arrête pas : il complète. Il produit une phrase bien construite, cohérente, souvent convaincante — et fausse. C'est ce qu'on appelle une hallucination, et le terme est trompeur parce qu'il suggère un dysfonctionnement. Ce n'en est pas un : le modèle fait exactement ce pour quoi il est conçu.

En production, c'est le principal risque. Un client à qui on annonce un délai inexistant, un opérateur à qui on donne une tolérance erronée, un comptable à qui on propose une écriture fausse : le coût dépasse largement celui d'une absence de réponse.

Les trois mécanismes qui l'évitent

Ce n'est pas un réglage, c'est une architecture.

1 · La réponse est puisée, pas produite. Le système ne demande pas au modèle « que sais-tu sur ce sujet ». Il cherche d'abord dans votre documentation les passages pertinents, puis demande au modèle de formuler une réponse à partir de ces passages. Si rien n'est trouvé, il n'y a rien à formuler.

2 · Chaque réponse cite sa source. Le passage exact et le document d'origine sont rattachés à la réponse. Cela permet la vérification, et cela révèle immédiatement les cas où la source ne correspond pas vraiment à la question.

3 · Un seuil de confiance déclenche la transmission. Chaque réponse porte un indice. En dessous du seuil que vous fixez, l'agent ne répond pas : il transmet à un humain, avec le contexte déjà rassemblé.

Le seuil de confiance n'est pas un réglage technique

C'est un arbitrage économique, et c'est vous qui le faites.

Il met en balance le coût d'une vérification humaine et le coût d'une erreur.

Sur une facture de faible montant, une vérification systématique coûte plus cher que l'erreur occasionnelle : le seuil peut être bas. Sur un montant élevé, sur une donnée médicale, sur une tolérance de production, l'erreur coûte cher : le seuil monte, quitte à ce que l'agent transmette souvent.

Un prestataire qui fixe ce seuil sans vous consulter décide à votre place d'un arbitrage qui vous appartient.

Comment mesurer que ça marche

Le taux de transmission. Trop bas, l'agent répond à des choses qu'il ne maîtrise pas. Trop haut, il ne sert à rien. La bonne valeur dépend de votre activité et se règle pendant le pilote.

Le taux de réponse correcte sur les cas traités. Mesuré sur des cas que vous avez choisis, pas sur des exemples fournis par le prestataire.

Le taux d'erreur non détectée. Le plus important et le plus difficile : les cas où l'agent a répondu avec confiance et s'est trompé. C'est ce que l'on cherche à éliminer, pas simplement à réduire.

Ce qu'il faut exiger d'un prestataire

« Que se passe-t-il quand l'agent ne sait pas ? » Si la réponse est floue, le mécanisme n'existe probablement pas.

« Puis-je voir la source de chaque réponse ? » Si non, vous ne pourrez ni vérifier ni corriger.

« Qui fixe le seuil de confiance ? » La bonne réponse est : vous, au cadrage.

« Que montre le journal ? » Un agent dont les décisions ne sont pas tracées est un agent qu'on ne peut pas améliorer.

Le paradoxe utile

Un agent qui transmet souvent au début est un bon signe. Cela veut dire que le seuil est prudent et que la matière est encore incomplète. À mesure que la documentation s'enrichit, le taux de transmission baisse naturellement.

L'inverse — un agent qui répond à tout dès le premier jour — devrait inquiéter.

Conclusion

La qualité d'un agent ne se mesure pas à sa capacité à répondre, mais à sa capacité à reconnaître les limites de ce qu'il sait. C'est ce qui sépare un outil déployable d'une démonstration.

Parlons de votre projet.

Trente minutes, gratuit et sans engagement, sur vos données réelles.

Écrit par les ingénieurs qui déploient.