Kas yra haliucinacijos ir kodėl jos atsiranda
LLM haliucinacija yra informacijos generavimas, kuri skamba patikimai, bet faktikai nėra tikra ar pagrista. Tai nėra „klaida” sistemos gedimo prasme — tai kalbos modelių veikimo būdo pasekmė. LLM „neižino” taip kaip duomenų bazė — prognozuoja labiausiai tikėtiną kitą tokeną, pagal mokymosi statistiką. Kai prompte yra klausimas, kuriam modelis neturi gero padengimo mokymo duomenyse, generuoja „labiausiai tikėtinai skambantį” atsakymą. Dažnai šis atsakymas yra teisingas. Kartais — ne.
Tipiniai haliucinacijų scenarijai verslo taikymuose:
- Neegzistuojančių teismo sprendimų ar įstatymų paragrafų citavimas teisinėje konsultacijoje
- Funkcijų, klasių ar bibliotekų pavadinimų sugalvojimas generuojant kodą
- Neteisingų statistikų ar datų pateikimas ataskaitose
- Kontaktų, adresų, telefono numerių sugalvojimas
- Skirtingų įmonių ar žmonių panašiais pavadinimais faktų maišymas
1 sluoksnis — Grounding (RAG)
Veiksmingiausia atskira haliucinacijų mažinimo technika yra grounding — konkrečių dokumentų ar duomenų pateikimas modeliui kaip kontekstas, iš kurio jis turi semti atsakymus. Klasikinis RAG (Retrieval-Augmented Generation):
- Vartotojo klausimas → atitinkamiausių dokumentų fragmentų paieška (vector search pgvector / Qdrant / Milvus duomenų bazėje)
- Fragmentai + klausimas → promptas su nurodymu „atsakyk išskirtinai pagal žemiau pateiktus dokumentus”
- Modelio atsakymas → patikrinimas, kad yra citatos/nuorodos į šaltinius
RAG sumažina haliucinacijas paprastai 60-80% taikymuose tipo „atsakyk į klausimus apie mūsų žinių bazę”. Visiškai jų nepašalina — modelis vis dar gali „interpretuoti” dokumentus neleistinai. Iš čia reikalingi kiti sluoksniai.
2 sluoksnis — Self-consistency ir ensemble
Self-consistency yra technika, susidedanti iš to paties klausimo uždavimo kelis kartus (arba keliems skirtingiems modeliams) ir atsakymų palyginimo. Kai atsakymai nuoseklus — aukštas pasitikėjimas. Kai skiriasi — signalas, kad tema yra neapibrėžta.
Praktinis variantas: paklausk Claude Sonnet, Llama 70B ir Bielik to paties klausimo. Jei visi trys gražina tą patį skaičių, datą, faktą — tikėtina, kad teisinga. Jei skiriasi — eskalavimas žmogui ar brangesnei modeliui (Opus). Šis šablonas, įdiegtas 8 lygių LLM routing, sujungia sąnaudų sumainimą su patikimumo gerinimu.
3 sluoksnis — Evaluation pipelines
Produkcinis LLM diegimas be evaluation pipeline yra kaip kodo rašymas be testų. Konkrečios metrikos:
- Faithfulness — ar atsakymas kyla iš pateiktų dokumentų. Matuojama antru DI modeliu (LLM-as-judge) ar bibliotekomis tipo RAGAS, deepeval.
- Answer relevance — ar atsakymas adresuoja vartotojo klausimą.
- Context precision — ar geriausi fragmentai gražinti retrieval (vector search kokybė).
- Groundedness score — atsakymo teiginių, kuriems galima nurodyti šaltinį kontekste, procentas.
Kiekvienas naujas LLM pagrįstos aplikacijos build turėtų pereiti 50-500 vertinimo klausimų rinkinį su žinomu ground truth. Jei faithfulness nukrenta žemiau 90% — deployment blokuojamas.
4 sluoksnis — Guardrails ir output validacija
Guardrails yra taisyklės, validuojančios LLM output prieš pateikiant vartotojui. Pavyzdžiai:
- Schema validation — output turi atitikti konkrečią schemą (JSON Schema, Pydantic). Haliucinacijos tipo „sugalvoti laukai” aptinkamos mechanikai.
- Forbidden patterns — nepriimtinų šablonų aptikimas ir blokavimas (PII be maskavimo, finansiniai duomenys ne kontekste, potencialiai žalingas turinys).
- Citation enforcement — kiekvienas faktinis teigimas turi turėti šaltinio citatą. Jei modelis nenurodo — atsakymas atmetamas.
- Numeric range validation — output skaičiai tikrinami prasme (pvz., kaina > 0, data ≤ šiandien, procentas intervale 0-100).
- Cross-reference check — output palyginimas su faktų baze (pvz., KRS, įstatymų citatų žodynas).
Bibliotekos: Guardrails AI, NeMo Guardrails, instructor (schema enforcement). Nuosavas įgyvendinimas dažnai paprastesnis ir pigiau priiūrimas.
5 sluoksnis — Human-in-the-loop
Aukštos rizikos aplikacijoms (teisiniai, medicininiai, finansiniai, personalo sprendimai) human-in-the-loop sluoksnis yra būtinas. DI modeliai nepriima galutinio sprendimo — padeda žmogui. Konkretūs šablonai:
- Draft + review — DI generuoja pirmą dokumento/atsakymo versiją, žmogus patikrina ir priima prieš išsiųsdamas.
- Confidence threshold — žemo confidence atsakymai (iš self-consistency ar explicit confidence asking) automatiškai eskaluojami žmogui.
- Random sampling QA — 5-10% visų LLM atsakymų auditavo manualiai, nepriklausomai nuo confidence — bazinė kokybės metrika laikui bėgant.
- Feedback loop — vartotojas gali pažymėti klaidingą atsakymą; sistema mokosi ir gerina retrieval, prompts, parametrus.
Matavimas — kaip žinoti, kad mažinimas veikia
Konkrečios produkcinės metrikos, kurias verta stebėti:
- Halucinacijų dažnis — atsakymų, klasifikuojamų kaip haliucinacijos manualiniame vertinime (sampling), procentas. Tikslas: žemiau 2% business-critical aplikacijoms.
- User feedback rate — vartotojų, pažymėjusių atsakymą kaip klaidingą, procentas.
- Escalation rate — užklausų, eskaluotų žmogui, procentas. Per žemas (žemiau 5%) — sistema tikėtina, kad praleidžia neapibrėžtus atvejus. Per aukštas (aukščiau 30%) — sistema neteikia automatizavimo vertės.
- Faithfulness score regresiniuose testuose — mėnesinė tendencija.
- Time-to-correction — nuo haliucinacijos aptikimo iki pataisos įdiegimo (geresnis retrieval, naujas guardrail, fine-tuning).
Išvados sprendėjams
Haliucinacijos yra valdomos — reikia investicijos į gynybinę architektūrą keliuose sluoksniuose. Įmonės, kurios įdiegia LLM be šios architektūros, anksčiau ar vėliau susidurs su rimtu incidentu (klaidingos informacijos paskelbimas klientui, klaidingas sprendimas pagal haliucinuotus duomenis, reputacinė žala). Visos gynybinės steko statybos kaina (RAG + evaluation + guardrails + human-in-the-loop) paprastai yra 15-30% paties LLM diegimo kainos — ir tai absoliučiai būtina investicija produkciniams taikymams. Praleidimo pasekmės yra asimetriškos: žema praleidimo kaina 95% atvejų, katastrofinė 5%.