Hallucinatiepreventie - Entity Enricher-documentatie

Hallucinatiepreventie

Wanneer LLM's gestructureerde data produceren, kunnen ze plausibel ogende feiten verzinnen. Entity Enricher gebruikt 8 verdedigingslagen om ervoor te zorgen dat je accurate data of geen data krijgt — nooit overtuigend klinkende fictie.

Het probleem met gestructureerde hallucinatie

In vrije tekst is een gehallucineerde zin duidelijk vaag. In gestructureerde uitvoer ziet een gehallucineerd veld als "founded_year": 1987 er gezaghebbend uit en is het bijna onmogelijk te onderscheiden van een correcte waarde. Drie factoren maken dit bijzonder gevaarlijk:

Valse precisie

Een gehallucineerde JSON-waarde ziet er precies uit als een echte. Geen slag om de arm, geen “ongeveer” — gewoon een net, zelfverzekerd gegeven dat toevallig verkeerd is.

Schemadruk

Verplichte velden dwingen het LLM een waarde te produceren, zelfs als het geen kennis heeft. Het model verzint gegevens in plaats van een gat in de structuur te laten.

Stille propagatie

Gestructureerde data stromen rechtstreeks naar databases, analyses en automatiseringen. Een verkeerde waarde verspreidt zich door de pijplijnen zonder menselijke controle.

Veelvoorkomende hallucinatiepatronen

PatroonVoorbeeldOorzaak
Zelfverzekerde verzinsels"ceo": "John Smith"LLM vult verplicht veld in met een plausibele naam
Temporele verwarring"revenue": "$2.3B"Afkappunt van trainingsdata of samenvoeging van periodes
EntiteitsvermengingAttributen van Bedrijf A op Bedrijf BVergelijkbare namen in overlappende trainingsdata
Plausibele standaardwaarden"employees": 500LLM kiest een “redelijk” getal in plaats van toe te geven dat het iets niet weet
Verzonnen relaties"subsidiary_of": "Alphabet"LLM leidt een relatie af die niet bestaat

Een aantal van deze patronen komt voort uit het schema, niet uit het model: een eigenschap als revenue laat de valuta, de periode en de vraag of het om de groep of de entiteit gaat open, en een naam voor iets wat de entiteit simpelweg niet heeft, geeft het model helemaal niets om op te zoeken. De ambiguïteitscontrole signaleert beide gevallen, benoemt de lezingen die de eigenschap toelaat en stelt de hernoeming of beschrijving voor die er precies één van vastlegt.

8 verdedigingslagen

Entity Enricher vertrouwt niet op één enkele techniek. Het stapelt 8 onafhankelijke verdedigingslagen, elk gericht op een andere faalwijze. Als de ene laag een hallucinatie mist, vangt de volgende die op.

1
Pre-flightclassificatie

Voordat de verrijking begint, classificeert een snelle LLM of de entiteit overeenkomt met het schematype. Dit blokkeert hallucinatie van hele entiteiten bij de bron.

Voorbeeld: “Titan” tegen een “Planet”-schema wordt gemarkeerd als maan — verrijkingsmodellen ontvangen deze context en gebruiken null voor planeetspecifieke velden.

2
Verklaarde onbekenden & conservatief prompten

Alle strategieën instrueren de LLM: "Wees nauwkeurig en conservatief — verzin nooit een waarde." Het model verklaart de velden die het niet kon bepalen in plaats van placeholders in te vullen, en die verklaringen worden eerlijke nulls in de uitvoer.

Dit pakt schemadruk direct aan — de belangrijkste oorzaak van gestructureerde hallucinatie. Een verklaarde onbekende maakt echte antwoorden ook eenduidig: een 0 waar het model achter staat is data, een verklaarde 0 niet.

3
Afbakening expertisedomein

Schema-eigenschappen worden gegroepeerd per expertisedomein. Elke LLM-aanroep ziet alleen velden binnen zijn domein, met de instructie zich uitsluitend op dat gebied te richten.

Een beperktere scope betekent minder kans op hallucinatie. Een financieel expert gokt nooit over reguleringsdata.

4
Zoeksleutel focussen

Sleuteleigenschappen (gemarkeerd met is_key: true) worden in prompts gemarkeerd om de LLM te verankeren op identificerende informatie voordat andere velden worden ingevuld.

Dit gronddt het model op bekende feiten, waardoor de afdrijving naar verzonnen details vermindert.

5
Schemavalidatie & zelfcorrectie

De uitvoer van de verrijking wordt gevalideerd tegen de types, formaten en structuur van het schema. Een fout activeert ModelRetry — de specifieke fout wordt ter correctie teruggestuurd naar het LLM, en de reparatie is chirurgisch: alleen de bladeren die verkeerd terugkwamen worden opnieuw opgevraagd, niet het hele antwoord.

Maximaal 5 automatische correctiepogingen binnen één agentrun. (Schemageneratie corrigeert zichzelf anders — per stap, met deterministische terugvalopties.)

6
Logica behouden

Velden gemarkeerd met preserve: true (ID's, SKU's, importidentifiers) worden na de enrichment hersteld naar hun oorspronkelijke invoerwaarden — de LLM kan ground-truth-gegevens niet overschrijven. Enrichment-verzoeken moeten voor elk preserved veld een waarde aanleveren, zodat niets ooit op null wordt gezet of wordt verzonnen.

Binnen arrays worden verrijkte items op basis van hun key-velden teruggekoppeld aan je invoeritems; items die de AI ontdekt krijgen null in plaats van een verzonnen identifier.

7
Multi-modelconsensus

Dezelfde entiteit door 2 of meer onafhankelijke modellen halen en de outputs veld voor veld vergelijken. Meningsverschillen worden gemarkeerd als mogelijke hallucinaties.

Als Claude zegt dat de omzet $2,3 mld is en GPT-4 zegt $1,8 mld — dan wordt dat conflict gedetecteerd en zichtbaar gemaakt.

8
Conflictoplossing en arbitrage

Gedetecteerde conflicten worden opgelost via op regels gebaseerde stemming (meerderheid, mediaan, unie) of door een speciale LLM-arbiter die nauwkeurigheid, volledigheid en consistentie beoordeelt.

Elke arbitration-beslissing bevat een onderbouwing en een betrouwbaarheidsniveau — volledige transparantie over hoe conflicten zijn opgelost.

Verdedigingspipeline

1Pre-flightclassificatieBlokkeer verkeerde entiteittypen
2Nullable + conservatieve promptsSchemadruk verminderen
3Afbakening expertisedomeinBeperk waarop de LLM moet antwoorden
4Focus van zoeksleutelAnker op identifiers
5Validatie & zelfcorrectieStructurele fouten herstellen
6Logica behoudenBescherm de ground truth
7Multi-modelconsensusMeningsverschillen detecteren
8ConflictarbitrageResolven met redenering
Vóór verrijking
Tijdens enrichment
Na verrijking

Ontwerpfilosofie

Kernprincipe

Ontbrekende data is altijd beter dan verkeerde data. Elke laag versterkt dit principe — het systeem is ontworpen om null terug te geven in plaats van een plausibel klinkende verzinsel.

Wat Entity Enricher doet
  • Geeft LLM's expliciet toestemming om null terug te geven
  • Kruisvalideert met meerdere onafhankelijke modellen
  • Beschermt bekende, goede data tegen overschrijven
  • Biedt volledige transparantie in conflictoplossing
Wat typische tools doen
  • LLM's dwingen om elk veld in te vullen, wat er ook gebeurt
  • Vertrouw op één enkel model zonder kruisvalidatie
  • Laat de LLM invoergegevens vrij overschrijven
  • Resultaten teruggeven als een black box zonder audittrail