Une IA produit ce qui est plausible, pas ce qui est vrai
Un modèle de langage n'a pas de « base de faits » qu'il consulte. Il a appris, sur des milliards de textes, quelle suite de mots est probable après une question donnée. Quand vous lui demandez le couple de serrage d'une bride, il ne cherche pas la valeur : il produit la phrase la plus vraisemblable. Souvent, c'est la bonne. Parfois, c'est une valeur inventée, écrite sur le même ton.
C'est ce qu'on appelle une hallucination. Le mot est trompeur, parce qu'il suggère une panne rare. C'est le fonctionnement normal d'un système conçu pour produire du texte plausible.
Elle se trompe sans le signaler, sur le même ton que ses bonnes réponses.
Un outil qui se trompe sur des cas connus reste utilisable. Un outil dont on ne sait pas quand il se trompe ne l'est pas.
Ce que ça change dans une entreprise
Pour rédiger un mail, ce n'est pas grave, vous relisez. Pour une procédure de maintenance, une référence de pièce ou une valeur de réglage, c'est un autre sujet. La personne qui pose la question le fait parce qu'elle ne connaît pas la réponse. Elle n'est donc pas en position de repérer l'erreur.
Brancher l'outil sur vos propres documents règle une partie du problème, pas tout. La documentation est parfois obsolète ou contradictoire, et l'outil ne le sait pas. Une question qui suppose une information que personne n'a écrite le pousse à combler le vide. Et une réponse à moitié juste passe la relecture plus facilement qu'une réponse fausse.
Les trois conditions pour s'en servir quand même
- Elle lit vos documents et dit d'où vient chaque réponse. Le document, la page, le passage. La personne qui utilise l'outil peut vérifier en un clic.
- On a décidé de ce qu'elle fait seule et de ce qui passe par quelqu'un. Quand aucun document ne couvre la question, elle le dit.
- On sait sur quoi elle se trompe avant de la mettre en service. Mesuré sur les questions que vos équipes posent, pas estimé.
Comment on le mesure
La méthode vient de l'ingénierie des systèmes critiques, où l'on ne met rien en service sans l'avoir fait passer par une campagne d'essais. Appliquée à un outil d'IA, elle tient en quatre étapes.
On construit avec vos équipes une liste de vraies questions, avec la bonne réponse et le document qui la contient. On fait passer cette liste à l'outil et on compte, type de question par type de question : procédures standard, références produit, pannes rares, questions mal formulées. On dresse la liste des cas où il se trompe, et on cherche pourquoi. Et on refait passer le même examen à chaque mise à jour, pour vérifier que ce qui marchait marche encore.
Le résultat est un rapport avec des pourcentages par type de question. Le plus bas est le plus utile : il dit où une relecture reste nécessaire. La méthode complète est décrite ici, avec un exemple de rapport.
C'est ce que 7Seven IA livre avec chaque outil construit, et ce qu'on peut aussi faire sur un outil que vous avez déjà.