💻 computer science

Beyond Document Grounding: Span-Level Hallucination Detection over Code, Tool Output, and Documents

Cet article introduit un benchmark unifié pour la détection d'hallucinations au niveau des segments (span-level) à travers divers entrées structurées telles que le code et les sorties d'outils, démontrant qu'un modèle Qwen3.5-2B affiné surpasse significativement les détecteurs existants et les juges zero-shot sur ces domaines complexes tout en restant compétitif sur les benchmarks RAG en langage naturel.

Auteurs originaux : Ádám Kovács, Bowei He, Xue Liu, István Boros, Szilveszter Tóth, Gábor Recski

Publié 2026-07-02

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Ádám Kovács, Bowei He, Xue Liu, István Boros, Szilveszter Tóth, Gábor Recski

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous embauchiez un assistant très intelligent et qui parle vite pour rédiger un rapport pour vous. Vous lui donnez une pile de livres de référence (le « contexte ») et une question spécifique. Il tape rapidement une réponse.

Le problème ? Parfois, même les assistants les plus intelligents peuvent se montrer un peu créatifs. Ils peuvent inventer un fait, mélanger un chiffre ou citer une page qui n'existe pas dans vos livres. C'est ce qu'on appelle une hallucination.

Pendant longtemps, des chercheurs ont construit des « vérificateurs de faits » pour attraper ces erreurs, mais ils ne fonctionnaient principalement que lorsque l'assistant écrivait sur des sujets normaux comme l'histoire ou la science en utilisant du texte brut.

Ce document présente un nouveau vérificateur de faits beaucoup plus exigeant, conçu pour le monde moderne, où les assistants écrivent également du code informatique, résument des journaux d'outils logiciels (logs) et lisent des documents structurés comme des tableaux et des manuels.

Voici une décomposition de ce qu'ils ont fait, en utilisant quelques analogies de la vie quotidienne :

1. Le Problème : L'angle mort du « Code » et des « Logs »

Imaginez que votre assistant soit un mécanicien.

Les anciens vérificateurs de faits : Excellents pour vérifier si le mécanicien dit « La voiture est rouge » alors que la voiture est bleue.
La nouvelle réalité : Le mécanicien écrit maintenant un manuel de réparation complexe (code) ou lit un écran de diagnostic numérique (sortie d'outil). Si le mécanicien écrit une seule commande erronée comme turn_off_engine au lieu de turn_on_engine, toute la voiture pourrait tomber en panne. Ou s'il liste un numéro de pièce qui n'existe pas, la commande échoue.
L'écart : Les vérificateurs de faits existants étaient comme un humain lisant un roman ; ils ne savaient pas comment repérer une seule ligne erronée dans un programme informatique ou une erreur spécifique dans un journal de logiciels. Ils ne pouvaient pas faire la différence entre un terme technique réel et un terme inventé.

2. La Solution : Un jeu de « Trouvez l'erreur »

Les auteurs ont construit un nouveau terrain d'entraînement massif (un benchmark) pour apprendre aux ordinateurs à être ces vérificateurs de faits spécialisés.

Comment ils ont créé les données : Ils sont partis de réponses parfaites et correctes (comme un manuel de réparation parfait). Ensuite, ils ont utilisé un « injecteur d'hallucinations » (imaginez un éditeur malicieux) pour glisser discrètement de petits mensonges localisés.
- Exemple : Ils ont changé un nom de fonction réel set_device en un faux nommé set_active_device.
- Ils n'ont pas seulement dit « Cette réponse est fausse ». Ils ont marqué les caractères exacts où le mensonge s'est produit.
La Variété : Ils ont créé plus de 74 000 exemples couvrant :
- Le Code : De vraies corrections de logiciels provenant de GitHub.
- La Sortie d'Outil (Tool Output) : Des journaux de logiciels (comme des messages d'erreur ou des résultats de recherche).
- Des Documents Structurés : Des articles de recherche, des fichiers README et des pages Wikipédia avec des tableaux et des listes.
- Du Texte Normal : Des questions et réponses standards (pour s'assurer qu'ils n'oublient pas comment vérifier le texte normal).

3. Le Nouveau Détective : « LettuceDetect »

Ils ont entraîné un nouveau modèle d'IA (une version de 2 milliards de paramètres d'un modèle appelé Qwen) pour agir comme le détective.

La Mission : Le détective examine la Requête, les Livres de Référence et la Réponse de l'Assistant. Il doit pointer du doigt le mensonge exact et dire : « Ce mot spécifique est inventé » ou « Ce nombre est faux ».
Les Résultats :
- Sur le Code et les Outils : Le nouveau détective est un super-héros. Il a attrapé 60 % des mensonges dans le code et les journaux d'outils.
- La Compétition : Les anciens vérificateurs de faits « prêts à l'emploi » (comme LettuceDetect-large) et même les géants juges IA très intelligents (LLM Zero-shot) n'ont attrapé que 17 % à 22 % des mensonges dans le code. Ils étaient essentiellement aveugles aux erreurs techniques.
- Sur le Texte Normal : Le nouveau détective est toujours très bon pour vérifier le texte normal (obtenant des scores similaires aux meilleurs systèmes existants), prouvant qu'il n'a pas perdu ses connaissances générales en apprenant à lire le code.

4. Pourquoi le « Niveau de Segment » (Span-Level) est important

Le document souligne qu'ils ne se contentent pas de dire « Rejetez cette réponse ». Ils font de la Détection au niveau du segment (Span-Level Detection).

Analogie : Imaginez qu'un étudiant écrive une dissertation de 10 pages. Une phrase est un mensonge.
- L'ancienne méthode : « Échouez toute la dissertation. » (Trop sévère, les 9 autres pages peuvent être parfaites).
- La nouvelle méthode : « Surlignez la phrase exacte qui est un mensonge. » (Précis et utile).
Dans le code, cela est crucial. Si un programme comporte 100 lignes et qu'une seule ligne est fausse, vous ne voulez pas jeter tout le programme ; vous voulez juste corriger cette ligne précise.

Résumé

Ce document présente un nouveau « détecteur de vérité » unifié, capable de gérer la réalité technique et désordonnée des assistants IA modernes. Il va au-delà de la simple vérification de texte simple pour repérer des erreurs minuscules et dangereuses dans le code, les journaux de logiciels et les documents structurés.

Leur nouveau modèle, LettuceDetect-Qwen-2B, est nettement meilleur pour trouver ces mensonges techniques que les outils précédents, surtout lorsque l'assistant écrit du code ou lit des journaux de logiciels, tout en restant un vérificateur de faits de premier rang pour le langage normal. Ils ont publié toutes leurs données et leurs modèles afin que d'autres puissent utiliser ce jeu de « trouvez l'erreur » pour construire des systèmes d'IA plus fiables et plus performants.

Résumé Technique : Au-delà de l'ancrage documentaire

Définition du Problème

Les systèmes de génération augmentée par récupération (RAG) sont de plus en plus déployés dans des environnements structurés au-delà du langage naturel, notamment pour les agents de codage, les outils de développement et la documentation de recherche. Bien que les benchmarks et détecteurs d'hallucinations existants se concentrent principalement sur les preuves en langage naturel, ils ne parviennent pas à traiter les défis de vérification uniques posés par les entrées structurées telles que le code source, les sorties d'outils (ex: journaux de tests, sorties de commandes) et les documents structurés (ex: markdown, tableaux).

Dans ces contextes structurés, une seule sous-chaîne non supportée — comme un nom de méthode fabriqué, une valeur de champ incorrecte ou une observation d'outil mal rapportée — peut altérer le comportement d'un programme ou induire un utilisateur en erreur, même si le reste de la réponse est correct. Les cadres d'évaluation actuels manquent d'une formulation unifiée au niveau des segments (span-level) capable de couvrir le code généré, les observations d'outils et les documents structurés aux côtés des tâches RAG traditionnelles en langage naturel.

Méthodologie

Construction d'un Benchmark Unifié

Les auteurs introduisent un benchmark unifié comprenant 74 285 exemples nouvellement construits à partir de cinq sources, complétés par des exemples convertis de jeux de données RAG en langage naturel existants (RAGTruth et PsiloQA). Les sources incluent :

Code : Dérivé de SWE-bench, présentant des correctifs ancrés dans des dépôts.
Sortie d'Outil : Dérivé de Squeez, contenant des requêtes et des observations d'outils verbeuses.
Documents Structurés : Fragments d'articles ACL, README GitHub et Wikipedia en markdown.
Langage Naturel : RAGTruth et PsiloQA (14 langues).

Pipeline de Construction des Données :

Ancrage (Grounding) : Partir d'une réponse correcte et ancrée dérivée de la source (ex: un patch gold de SWE-bench).
Injection : Utiliser un modèle "injecteur" spécifique à la source (Gemma 4 31B pour le code ; Qwen 3.6 35B pour les autres) pour proposer des éditions de remplacement localisées et structurées. Ces éditions introduisent des hallucinations localisées catégorisées comme Contradiction (logique/valeurs erronées), Ajout Non Supporté (comportement supplémentaire) ou Référence Fabriquée (méthodes/identifiants inventés).
Étiquetage de Segment (Span Labeling) : Appliquer les éditions de manière déterministe pour extraire les décalages de caractères exacts pour les segments hallucinés, évitant ainsi l'ambiguïté de la comparaison (diffing) entre réponses de code et de langage naturel.
Ancrage de Référence : Pour éviter de pénaliser les réponses correctes qui font référence à des bibliothèques externes ou des méthodes sœurs non présentes dans les contextes tronqués, le pipeline ajoute les définitions résolues du commit de base du dépôt et les signatures d'API réelles de Context7.
Vérification : Le jeu de test de l'agent de code a subi une revue humaine et un arbitrage, conservant 2 015 exemples après filtrage de la validité et de la précision des limites.

Architecture du Modèle

Deux familles de détecteurs ont été entraînées sur le jeu de données unifié :

LettuceDetect-Qwen-2B : Un détecteur génératif Qwen3.5-2B affiné avec une fenêtre de contexte de 32 768 jetons. Il produit un JSON contenant les segments de caractères, les catégories et les sous-catégories.
LettuceDetect-mmBERT-base : Un encodeur de classification de jetons à 307 millions de paramètres (basé sur mmBERT) entraîné avec une longueur de séquence maximale de 8 192 jetons.

Les deux modèles sont entraînés à l'aide d'un prompt agnostique de la donnée qui définit la taxonomie des hallucinations et fournit la requête, le contexte et la réponse à vérifier.

Principales Contributions

Formulation de la Tâche : Une formulation de tâche au niveau du segment (span-level) pour la détection d'hallucinations post-génération, spécifiquement conçue pour les contextes de génération ancrée structurés (code, sortie d'outil, documents structurés).
Benchmark Unifié : Un ensemble de données complet de 74 285 nouveaux exemples couvrant diverses modalités, plus des exemples convertis de benchmarks RAG établis, permettant une évaluation trans-domaine.
Performance du Détecteur : Démonstration qu'un détecteur génératif affiné (LettuceDetect-Qwen-2B) surpasse substantiellement les détecteurs prêts à l'emploi et les juges LLM zero-shot sur les segments de code-agent et de sortie d'outil, tout en restant compétitif sur les benchmarks RAG en langage naturel.

Résultats Expérimentaux

Principales Conclusions

Sur le jeu de test unifié, LettuceDetect-Qwen-2B a atteint un span-F1 de 0,689.

Performance Code-Agent : Le modèle a atteint un span-F1 de 0,602 sur le segment code-agent, surpassant de manière significative LettuceDetect-large (0,17) et les juges LLM zero-shot les plus performants évalués (Nemotron-3-Ultra et gpt-oss-120b, tous deux $\le$ 0,22).
Performance Langage Naturel : Le modèle est resté compétitif sur les benchmarks établis, atteignant un example-F1 de 81,8 sur RAGTruth et un IoU de 0,724 sur l'anglais de PsiloQA (dépassant le mmBERT-base affiné des auteurs du benchmark à 0,707).
Capacité Multilingue : À travers 14 langues dans PsiloQA, le modèle a atteint un IoU moyen de 0,689, surpassant le juge Qwen2.5-32B (0,383).

Comparaison avec les Baselines

Juges Zero-Shot : Les grands LLM zero-shot (ex: Nemotron-3-Ultra, gpt-oss-120b) ont eu des difficultés avec le code et les sorties d'outils, signalant souvent à tort du code correctement écrit comme non supporté ou échouant à distinguer les éditions valides des hallucinations.
Détecteurs Spécialisés : Les détecteurs existants entraînés uniquement sur le langage naturel (ex: LettuceDetect-large) ont mal performé sur les données structurées (0,17 span-F1 sur le code).
Encodeur vs Générateur : Le détecteur génératif (Qwen-2B) a systématiquement surpassé l'encodeur de classification de jetons (mmBERT-base) sur toutes les sources (0,689 contre 0,642 de span-F1 global).

Signification et Revendications

L'article affirme que le benchmark et le détecteur proposés comblent une lacune critique dans l'évaluation RAG : l'absence de vérification au niveau du segment pour les sorties structurées et non linguistiques. Les auteurs soulignent que :

La Vérification Structurée est Distincte : La vérification du code et des sorties d'outils nécessite un raisonnement différent du langage naturel, particulièrement concernant les erreurs d'intention et la validité structurelle.
Les Détecteurs Génératifs sont Supérieurs : Les modèles génératifs affinés avec de larges fenêtres de contexte sont mieux adaptés à cette tâche que les encodeurs traditionnels ou les juges zero-shot, particulièrement lorsqu'ils traitent de longs contextes de dépôts et de dépendances complexes.
Évaluation Unifiée : Un seul modèle peut gérer efficacement diverses modalités (code, sortie d'outil, documents) sans sacrifier les performances sur les tâches de langage naturel.

Les auteurs notent des limites, notamment la dépendance à l'injection synthétique pour la plupart des étiquettes (bien que le jeu de test de code ait été revu par des humains) et le focus sur la vérification de la réponse finale plutôt que sur l'intégralité des trajectoires d'agents. Ils concluent que leur travail fournit une fondation nécessaire au développement de systèmes de vérification robustes pour la prochaine génération d'agents de génération ancrée.