Si vous faites vérifier les résultats de l’IA, sachez ce que votre outil ne trouve pas
Cette page est une traduction. La version anglaise fait autorité.
Les administrations, les écoles et les bureaux confient désormais à des logiciels la rédaction de projets de textes : décisions, devis, rapports, résumés de contrats. Le résultat est généralement vérifié à nouveau, souvent par un second programme et, à la fin, par un vérificateur formé. Quiconque met en place cette vérification se trouve face à une question très concrète : que faut-il réellement rechercher ?
Cette mesure repose sur un ensemble de textes administratifs et de bureau en allemand contenant des erreurs délibérément insérées : sommes et pourcentages erronés, délais incorrects, règles inventées, phrases qui contredisent le chiffre qu’elles donnent dans le même paragraphe — et informations manquantes : des éléments présents dans les documents sources qui n’apparaissent tout simplement plus dans le résultat vérifié. Cet ensemble contient également des passages et des tâches entières sans aucune erreur ; c’est la seule façon de compter combien de fois un programme signale à tort un élément correct. La même version, délibérément difficile, a été soumise à deux catégories : cinq modèles de langage peu coûteux et quatre modèles actuels de premier plan provenant de quatre fournisseurs différents. Un seul passage par programme.
- Erreurs délibérément insérées détectées : cinq modèles peu coûteux, 126 sur 150 (84,0 %) — quatre modèles de premier plan, 116 sur 120 (96,7 %)
- Informations manquantes aux trois endroits les plus difficiles : 4 sur 15 (26,7 %) — 10 sur 12 (83,3 %)
- Fausses alertes par passage : huit en moyenne — un peu moins de trois
Les informations manquantes — des conditions qui n’apparaissent pas du tout dans le résultat vérifié — sont le type d’erreur sur lequel les programmes de vérification diffèrent le plus dans cette comparaison : les programmes plus performants en repèrent la plupart, les programmes moins performants en laissent régulièrement passer. Ce schéma observé chez les programmes moins performants porte un nom : la cécité au contre-chiffre.
Une somme erronée se remarque au plus tard à la facture suivante. Une condition qui n’a jamais figuré dans le texte ne retient l’attention de personne — jusqu’à ce que quelqu’un l’exige. Et, de l’extérieur, presque aucun bureau ne peut voir quel modèle fonctionne dans son outil. L’interface est la même, le ton est tout aussi assuré.
Deux questions fixes à chaque validation finale
- Qu’y a-t-il dans les documents sources qui est absent du résultat ?
- Quels signalements de la machine ne sont pas du tout des erreurs ?
Un seul passage par programme, conçu comme un point de départ et non comme un jugement sur des outils particuliers. Il n’existe pas encore de base de comparaison indépendante et reproductible pour cette question ; c’est précisément ce qui doit voir le jour.