Halluzinationsprävention – Entity Enricher Dokumentation

Halluzinationsprävention

Wenn LLMs strukturierte Daten erzeugen, können sie plausibel wirkende Fakten erfinden. Entity Enricher nutzt 8 Verteidigungsebenen, um sicherzustellen, dass Sie korrekte Daten oder keine Daten erhalten – niemals überzeugend klingende Fiktion.

Das Problem der strukturierten Halluzination

In Freitext ist ein halluzinierter Satz offensichtlich vage. In strukturierter Ausgabe wirkt ein halluziniertes Feld wie "founded_year": 1987 maßgeblich und ist von einem korrekten Wert kaum zu unterscheiden. Drei Faktoren machen dies besonders gefährlich:

Falsche Präzision

Ein halluzinierter JSON-Wert sieht genauso aus wie ein echter. Es gibt keine Einschränkung, kein „ungefähr“ – nur einen sauberen, überzeugend wirkenden Datenpunkt, der zufällig falsch ist.

Schemadruck

Pflichtfelder zwingen das LLM, einen Wert zu erzeugen, selbst wenn es kein Wissen dazu hat. Das Modell erfindet Daten, anstatt eine Lücke in der Struktur zu lassen.

Stille Weitergabe

Strukturierte Daten fließen direkt in Datenbanken, Analysen und Automatisierungen ein. Ein falscher Wert verbreitet sich durch die Pipelines ohne menschliche Prüfung.

Häufige Halluzinationsmuster

MusterBeispielUrsache
Selbstsichere Erfindung"ceo": "John Smith"Das LLM füllt ein Pflichtfeld mit einem plausiblen Namen
Zeitliche Verwirrung"revenue": "$2.3B"Stichtag der Trainingsdaten oder Vermischung von Zeiträumen
EntitätszusammenführungAttribute von Unternehmen A bei Unternehmen BÄhnliche Namen in überlappenden Trainingsdaten
Plausible Standardwerte"employees": 500Das LLM wählt eine „vernünftige“ Zahl, statt Unwissenheit einzugestehen
Erfundene Beziehungen"subsidiary_of": "Alphabet"Das LLM leitet eine Beziehung ab, die nicht existiert

8 Verteidigungsebenen

Entity Enricher verlässt sich nicht auf eine einzige Technik. Es kombiniert 8 unabhängige Schutzschichten, die jeweils auf einen anderen Fehlermodus abzielen. Übersieht eine Schicht eine Halluzination, fängt die nächste sie ab.

1
Pre-Flight-Klassifizierung

Bevor die Anreicherung beginnt, klassifiziert ein schnelles LLM, ob die Entität zum Schematyp passt. Dies verhindert Halluzinationen ganzer Entitäten bereits an der Quelle.

Beispiel: „Titan“ wird gegen ein „Planet“-Schema als Mond gekennzeichnet — Anreicherungsmodelle erhalten diesen Kontext und verwenden null für planetenspezifische Felder.

2
Nullable-Felder & konservatives Prompting

Alle Strategien weisen das LLM an: „Seien Sie genau und konservativ – bevorzugen Sie null gegenüber Raten.“ Nullbare Schema-Felder geben dem Modell die ausdrückliche Erlaubnis zu sagen: „Ich weiß es nicht.“

Dies adressiert direkt den Schema-Druck – die Ursache Nr. 1 für strukturierte Halluzinationen.

3
Eingrenzung auf Expertisebereiche

Die Schemaeigenschaften werden nach Fachbereich gruppiert. Jeder LLM-Aufruf sieht nur Felder innerhalb seines Fachbereichs, mit der Anweisung, sich ausschließlich auf diesen Bereich zu konzentrieren.

Ein engerer Fokus bietet weniger Gelegenheit zum Halluzinieren. Ein Finanzexperte rät niemals bei regulatorischen Daten.

4
Suchschlüssel-Fokussierung

Schlüsseleigenschaften (markiert mit is_key: true) werden in Prompts hervorgehoben, um den LLM auf identifizierende Informationen auszurichten, bevor andere Felder ausgefüllt werden.

Dies verankert das Modell an bekannten Fakten und reduziert die Abweichung hin zu erfundenen Details.

5
Schema-Validierung & Selbstkorrektur

8 Validierungsregeln prüfen die LLM-Ausgabe auf Typkonflikte, ungültige Referenzen und Strukturfehler. Eine fehlgeschlagene Validierung löst ModelRetry aus – die Fehler werden zur Korrektur an das LLM zurückgesendet.

Bis zu 6 automatische Korrekturversuche innerhalb eines einzelnen Agentendurchlaufs. Das LLM behebt seine eigenen Fehler.

6
Logik beibehalten

Felder mit der Markierung preserve: true (IDs, SKUs, Zeitstempel) werden nach der Anreicherung auf ihre ursprünglichen Eingabewerte zurückgesetzt. Das LLM kann die gesicherten Ausgangsdaten nicht überschreiben.

Geschützte Felder: Entitäts-IDs, Systemcodes (EAN, SKU), Import-Kennungen, Erstellungszeitstempel.

7
Multi-Modell-Konsens

Dieselbe Entität durch 2 oder mehr unabhängige Modelle laufen lassen und die Ausgaben Feld für Feld vergleichen. Abweichungen werden als potenzielle Halluzinationen markiert.

Wenn Claude einen Umsatz von 2,3 Mrd. $ angibt und GPT-4 1,8 Mrd. $ – wird dieser Konflikt erkannt und angezeigt.

8
Konfliktlösung & Arbitrierung

Erkannte Konflikte werden durch regelbasierte Abstimmung (Mehrheit, Median, Vereinigung) oder durch einen dedizierten LLM-Arbitrator gelöst, der Genauigkeit, Vollständigkeit und Konsistenz bewertet.

Jede Arbitration-Entscheidung enthält eine Begründung und ein Konfidenzniveau — vollständige Transparenz darüber, wie Konflikte aufgelöst wurden.

Abwehr-Pipeline

1Pre-flight-KlassifizierungFalsche Entitätstypen blockieren
2Nullable + konservative PromptsSchema-Belastung reduzieren
3Eingrenzung auf ExpertisebereicheEingrenzen, was das LLM beantworten muss
4Suchschlüssel-FokusAn Bezeichnern verankern
5Validierung & SelbstkorrekturStrukturfehler beheben
6Logik beibehaltenGround Truth schützen
7Multi-Modell-KonsensMeinungsverschiedenheiten erkennen
8KonfliktarbitrierungMit Begründung auflösen
Vor der Anreicherung
Während der Enrichment
Nach der Anreicherung

Designphilosophie

Grundprinzip

Fehlende Daten sind immer besser als falsche Daten. Jede Ebene verstärkt dieses Prinzip – das System ist darauf ausgelegt, null zurückzugeben, statt eine plausibel klingende Erfindung zu liefern.

Was Entity Enricher leistet
  • Erlaubt LLMs ausdrücklich, null zurückzugeben
  • Führt eine Kreuzvalidierung mit mehreren unabhängigen Modellen durch
  • Schützt bekannt gute Daten vor dem Überschreiben
  • Bietet volle Transparenz bei der Konfliktlösung
Was typische Tools tun
  • LLMs zwingen, jedes Feld auszufüllen, egal was passiert
  • Verlassen Sie sich auf ein einzelnes Modell ohne Kreuzvalidierung
  • Dem LLM erlauben, Eingabedaten frei zu überschreiben
  • Ergebnisse als Blackbox ohne Prüfprotokoll zurückgeben