💻 computer science

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

Dieses Paper führt einen vereinheitlichten Benchmark für die Erkennung von Halluzinationen auf Span-Ebene über diverse strukturierte Eingaben wie Code und Tool-Outputs hinweg ein und zeigt auf, dass ein fein abgestimmtes Qwen3.5-2B-Modell bestehende Detektoren sowie Zero-Shot-Richter in diesen komplexen Domänen signifikant übertrifft, während es gleichzeitig wettbewerbsfähig auf natürlichen Sprach-RAG-Benchmarks bleibt.

Ursprüngliche Autoren: Ádám Kovács, Bowei He, Xue Liu, István Boros, Szilveszter Tóth, Gábor Recski

Veröffentlicht 2026-07-02

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Ádám Kovács, Bowei He, Xue Liu, István Boros, Szilveszter Tóth, Gábor Recski

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie stellen eine sehr kluge, schnell sprechende Assistentin ein, um einen Bericht für Sie zu schreiben. Sie geben ihr einen Stapel Referenzbücher (den „Kontext“) und eine spezifische Frage. Sie tippt schnell eine Antwort ein.

Das Problem? Manchmal werden selbst die klügsten Assistenten ein wenig kreativ. Sie erfinden einen Fakt, vertauschen eine Zahl oder zitieren eine Seite, die in Ihren Büchern nicht existiert. Das nennt man eine Halluzination.

Lange Zeit haben Forscher „Faktenchecker“ entwickelt, um diese Fehler abzufangen, aber diese funktionierten meist nur, wenn die Assistentin über normale Themen wie Geschichte oder Wissenschaft in einfachem Text schrieb.

Dieses Paper stellt einen neuen, viel anspruchsvolleren Faktenchecker vor, der für die moderne Welt entwickelt wurde, in der Assistenten auch Computercode schreiben, Software-Tool-Logs zusammenfassen und strukturierte Dokumente wie Tabellen und Handbücher lesen.

Hier ist eine Aufschlüsselung dessen, was sie getan haben, unter Verwendung einiger alltäglicher Analogien:

1. Das Problem: Der „Blind Spot“ bei Code und Logs

Stellen Sie sich vor, Ihre Assistentin ist eine Mechanikerin.

Alte Faktenchecker: Gut darin zu prüfen, ob die Mechanikerin sagt: „Das Auto ist rot“, obwohl das Auto eigentlich blau ist.
Die neue Realität: Die Mechanikerin schreibt nun ein komplexes Reparaturhandbuch (Code) oder liest einen digitalen Diagnosebildschirm (Tool-Output). Wenn die Mechanikerin einen einzigen falschen Befehl wie turn_off_engine statt turn_on_engine schreibt, könnte das ganze Auto kaputtgehen. Oder wenn sie eine Teilenummer angibt, die nicht existiert, schlägt die Bestellung fehl.
Die Lücke: Bestehende Faktenchecker waren wie ein Mensch, der einen Roman liest; sie wussten nicht, wie man einen einzelnen falschen Satz in einem Computerprogramm oder einen spezifischen Fehler in einem Software-Log erkennt. Sie konnten nicht zwischen einem echten technischen Begriff und einem erfundenen unterscheiden.

2. Die Lösung: Ein „Such die Differenz“-Spiel

Die Autoren bauten eine massive neue Trainingsumgebung (einen Benchmark), um Computer zu lehren, wie diese spezialisierten Faktenchecker zu sein.

Wie sie die Daten erstellten: Sie begannen mit perfekten, korrekten Antworten (wie ein perfektes Reparaturhandbuch). Dann nutzten sie einen „Halluzinations-Injektor“ (denken Sie an einen schalkhaften Editor), um winzige, lokalisierte Lügen einzuschleusen.
- Beispiel: Sie änderten einen echten Funktionsnamen set_device in einen gefälschten Namen set_active_device.
- Sie sagten nicht nur: „Diese Antwort ist falsch.“ Sie markierten die exakten Zeichen, an denen die Lüge auftrat.
Die Vielfalt: Sie erstellten über 74.000 Beispiele, die Folgendes abdeckten:
- Code: Echte Software-Fixes von GitHub.
- Tool-Output: Logs von Software-Tools (wie Fehlermeldungen oder Suchergebnisse).
- Strukturierte Dokumente: Forschungsarbeiten, README-Dateien und Wikipedia-Seiten mit Tabellen und Listen.
- Normaler Text: Standard-Fragen und Antworten (um sicherzustellen, dass sie nicht verlernten, normalen Text zu prüfen).

3. Der neue Detektiv: „LettuceDetect“

Sie trainierten ein neues KI-Modell (eine 2-Milliarden-Parameter-Version eines Modells namens Qwen), um als Detektiv zu fungieren.

Der Job: Der Detektiv betrachtet die Anfrage (Request), die Referenzbücher und die Antwort der Assistentin. Er muss mit dem Finger auf die exakte Lüge zeigen und sagen: „Dieses spezifische Wort ist erfunden“ oder „Diese Zahl ist falsch“.
Die Ergebnisse:
- Bei Code und Tools: Der neue Detektiv ist ein Superheld. Er hat 60 % der Lügen in Code und Tool-Logs erkannt.
- Der Wettbewerb: Die alten „Standard“-Faktenchecker (wie LettuceDetect-large) und sogar riesige, intelligente KI-Richter (Zero-shot LLMs) erkannten in Code nur etwa 17 % bis 22 % der Lügen. Sie waren im Grunde blind für technische Fehler.
- Bei normalem Text: Der neue Detektiv ist immer noch sehr gut darin, normalen Text zu prüfen (er erzielt ähnliche Werte wie die besten bestehenden Systeme), was beweist, dass er beim Erlernen des Lesens von Code sein allgemeines Wissen nicht verloren hat.

4. Warum „Span-Level“ wichtig ist

Das Paper betont, dass sie nicht einfach nur sagen: „Lehne diese Antwort ab.“ Sie betreiben „Span-Level Detection“.

Analogie: Stellen Sie sich vor, ein Student schreibt einen 10-seitigen Essay. Ein Satz darin ist eine Lüge.
- Alter Weg: „Die ganze Arbeit durchfallen lassen.“ (Zu hart; die anderen 9 Seiten könnten perfekt sein).
- Neuer Weg: „Hebe den einen Satz hervor, der eine Lüge ist.“ (Präzise und hilfreich).
In Code ist dies entscheidend. Wenn ein Programm 100 Zeilen hat und nur eine Zeile falsch ist, wollen Sie nicht das ganze Programm wegwerfen; Sie wollen nur diese eine Zeile korrigieren.

Zusammenfassung

Dieses Paper präsentiert einen neuen, vereinheitlichten „Wahrheitsdetektor“, der die chaotische, technische Realität moderner KI-Assistenten bewältigen kann. Es geht über das bloße Prüfen von einfachem Text hinaus und erkennt winzige, gefährliche Fehler in Code, Software-Logs und strukturierten Dokumenten.

Ihr neues Modell, LettuceDetect-Qwen-2B, ist deutlich besser darin, diese technischen Lügen zu finden als bisherige Werkzeuge – insbesondere wenn die Assistentin Code schreibt oder Software-Logs liest – während es gleichzeitig ein erstklassiger Faktenchecker für normale Sprache bleibt. Sie haben alle ihre Daten und Modelle veröffentlicht, damit andere dieses „Such die Differenz“-Spiel nutzen können, um bessere, zuverlässigere KI-Systeme zu bauen.

Technisches Resümee: Jenseits der Dokumenten-Grundierung

Problemdefinition

Retrieval-Augmented-Generation (RAG)-Systeme werden zunehmend in strukturierten Umgebungen eingesetzt, die über natürliche Sprache hinausgehen, einschließlich Coding-Agenten, Entwicklertools und Forschungsdokumentationen. Während bestehende Benchmarks zur Halluzinationserkennung und entsprechende Detektoren sich primär auf Belege aus natürlicher Sprache konzentrieren, versäumen sie es, die einzigartigen Verifizierungsherausforderungen zu adressieren, die durch strukturierte Eingaben wie Quellcode, Tool-Ausgaben (z. B. Test-Logs, Befehlsausgaben) und strukturierte Dokumente (z. B. Markdown, Tabellen) entstehen.

In diesen strukturierten Settings kann ein einziger nicht gestützter Substring – wie ein erfundener Methodenname, ein falscher Feldwert oder eine falsch berichtete Tool-Beobachtung – das Programmverhalten verändern oder einen Nutzer irreführen, selbst wenn der Rest der Antwort korrekt ist. Aktuelle Evaluierungsframeworks lassen eine vereinheitlichte, span-basierte Formulierung vermissen, die generierten Code, Tool-Beobachtungen und strukturierte Dokumente neben traditionellen RAG-Aufgaben der natürlichen Sprache abdeckt.

Methodik

Konstruktion eines vereinheitlichten Benchmarks

Die Autoren führen einen vereinheitlichten Benchmark ein, der 74.285 neu konstruierte Beispiele aus fünf Quellen umfasst, ergänzt durch konvertierte Beispiele aus bestehenden RAG-Datensätzen der natürlichen Sprache (RAGTruth und PsiloQA). Die Quellen umfassen:

Code: Abgeleitet von SWE-bench, mit repository-gestützten Korrekturen (fixes).
Tool-Output: Abgeleitet von Squeez, enthaltend Abfragen und ausführliche Tool-Beobachtungen.
Strukturierte Dokumente: ACL-Paper-Abschnitte, GitHub READMEs und Wikipedia-Markdown.
Natürliche Sprache: RAGTruth und PsiloQA (14 Sprachen).

Pipeline zur Datenerstellung:

Grundierung (Grounding): Beginn mit einer als korrekt bekannten, gestützten Antwort, die aus der Quelle abgeleitet wurde (z. B. ein Gold-SWE-bench-Patch).
Injektion: Einsatz eines quellspezifischen „Injektionsmodells“ (Gemma 4 31B für Code; Qwen 3.6 35B für andere), um lokalisierte, strukturierte Ersetzung-Edits vorzuschlagen. Diese Edits führen lokalisierte Halluzinationen ein, kategorisiert als Widerspruch (falsche Logik/Werte), Nicht gestützte Ergänzung (zusätzliches Verhalten) oder Erfundener Bezug (erfundene Methoden/Identifikatoren).
Span-Labeling: Anwendung der Edits deterministisch, um exakte Zeichen-Offsets für die halluzinierten Spans zu extrahieren, wodurch die Mehrdeutigkeit beim Diffing von gemischten Natural-Language-/Code-Antworten vermieden wird.
Referenz-Grundierung: Um zu verhindern, dass korrekte Antworten bestraft werden, die auf externe Bibliotheken oder Geschwister-Methoden verweisen, die nicht in den gekürzten Kontexten enthalten sind, hängt die Pipeline aufgelöste Definitionen aus dem Base-Commit des Repositories sowie reale API-Signaturen aus Context7 an.
Verifizierung: Der Code-Agent-Testdatensatz wurde einer menschlichen Überprüfung und Schlichtung unterzogen, wobei nach Filterung auf Validität und Grenzgüte 2.015 Beispiele verblieben.

Modellarchitektur

Zwei Detektor-Familien wurden auf dem vereinheitlichten Datensatz trainiert:

LettuceDetect-Qwen-2B: Ein feinabgestimmter generativer Detektor (Qwen3.5-2B) mit einem Kontextfenster von 32.768 Token. Er gibt JSON aus, das Zeichen-Spans, Kategorien und Unterkategorien enthält.
LettuceDetect-mmBERT-base: Ein 307-Millionen-Parameter-Token-Klassifikations-Encoder (basierend auf mmBERT), trainiert mit einer maximalen Sequenzlänge von 8.192 Token.

Beide Modelle werden mit einem datenagnostischen Prompt trainiert, der die Halluzinations-Taxonomie definiert und die Anfrage, den Kontext sowie die Antwort zur Verifizierung bereitstellt.

Zentrale Beiträge

Aufgabenformulierung: Eine Span-basierte Aufgabenformulierung für die Halluzinationserkennung nach der Generierung, die speziell für strukturierte, fundierte Generierungskontexte (Code, Tool-Output, strukturierte Dokumente) entwickelt wurde.
Vereinheitlichter Benchmark: Ein umfassender Datensatz von 74.285 neuen Beispielen, der diverse Modalitäten abdeckt, plus konvertierte Beispiele aus etablierten RAG-Benchmarks, was eine domänenübergreifende Evaluierung ermöglicht.
Detektor-Leistung: Nachweis, dass ein feinabgestimmter generativer Detektor (LettuceDetect-Qwen-2B) spezialisierte Code-Agent- und Tool-Output-Splits signifikant besser als fertige Off-the-shelf-Detektoren und Zero-Shot-LLM-Judges abschneidet, während er bei Natural-Language-RAG-Benchmarks konkurrenzfähig bleibt.

Experimentelle Ergebnisse

Haupterkenntnisse

Auf dem vereinheitlichten Testset erreichte LettuceDetect-Qwen-2B einen Span-F1 von 0,689.

Code-Agent-Leistung: Das Modell erreichte einen Span-F1 von 0,602 im Code-Agent-Split und übertraf damit signifikant LettuceDetect-large (0,17) sowie die stärksten evaluierten Zero-Shot-LLM-Judges (Nemotron-3-Ultra und gpt-oss-120b, beide $\le$ 0,22).
Leistung in natürlicher Sprache: Das Modell blieb auf etablierten Benchmarks konkurrenzfähig und erreichte eine Beispiel-F1 von 81,8 auf RAGTruth sowie ein IoU von 0,724 auf Englisch-PsiloQA (wobei es den Benchmark-Autoren mit ihrem feinabgestimmten mmBERT-base von 0,707 übertraf).
Mehrsprachige Fähigkeit: Über 14 Sprachen in PsiloQA hinweg erreichte das Modell ein mittleres IoU von 0,689 und übertraf damit den Qwen2.5-32B Judge (0,383).

Vergleich mit Baselines

Zero-Shot-Judges: Große Zero-Shot-LLMs (z. B. Nemotron-3-Ultra, gpt-oss-120b) hatten Schwierigkeiten mit Code und Tool-Outputs; sie markierten oft korrekten, neu geschriebenen Code als ungestützt oder scheiterten daran, zwischen validen Edits und Halluzinationen zu unterscheiden.
Spezialisierte Detektoren: Bestehende Detektoren, die rein auf natürlicher Sprache trainiert wurden (z. B. LettuceDetect-large), schnitten bei strukturierten Daten schlecht ab (0,17 Span-F1 bei Code).
Encoder vs. Generator: Der generative Detektor (Qwen-2B) war über alle Quellen hinweg konsistent besser als der Token-Klassifikations-Encoder (mmBERT-base) (0,689 vs. 0,642 Gesamt-Span-F1).

Bedeutung und Behauptungen

Das Paper behauptet, dass der vorgeschlagene Benchmark und Detektor eine kritische Lücke in der RAG-Evaluierung schließen: das Fehlen einer Span-basierten Verifizierung für strukturierte, nicht-natürlichsprachliche Outputs. Die Autoren betonen:

Strukturierte Verifizierung ist distinkt: Die Verifizierung in Code und Tool-Outputs erfordert anderes Reasoning als in natürlicher Sprache, insbesondere hinsichtlich der Intention-Fehler und der strukturellen Validität.
Generative Detektoren sind überlegen: Feinabgestimmte generative Modelle mit langen Kontextfenstern eignen sich besser für diese Aufgabe als traditionelle Encoder oder Zero-Shot-Judges, insbesondere beim Umgang mit langen Repository-Kontexten und komplexen Abhängigkeiten.
Vereinheitlichte Evaluierung: Ein einzelnes Modell kann effektiv diverse Modalitäten (Code, Tool-Output, Dokumente) handhaben, ohne die Leistung bei Aufgaben der natürlichen Sprache zu opfern.

Die Autoren weisen auf Limitationen hin, darunter die Abhängigkeit von synthetischer Injektion für die meisten Labels (obwohl der Code-Testdatensatz menschlich überprüft wurde) und der Fokus auf der Verifizierung der finalen Antwort statt auf vollständigen Agenten-Trajektorien. Sie kommen zu dem Schluss, dass ihre Arbeit eine notwendige Grundlage für die Entwicklung robuster Verifizierungssysteme für die nächste Generation von fundierten Generierungs-Agenten bildet.