Co jsou halucinace a proč se objevují
Halucinace v LLM je generování informace, která zní věrohodně, ale je fakticky nepravdivá nebo neoprávněná. Není to „chyba” ve smyslu selhání systému — je to důsledek způsobu fungování jazykových modelů. LLM „neví” tak, jak ví databáze — předpovídá nejpravděpodobnější další token na základě statistiky učení. Když se v promptu objeví otázka, na kterou model nemá dobré pokrytí v tréninkových datech, generuje „nejpravděpodobněji znějící” odpověď. Často je tato odpověď správná. Někdy — ne.
Typické scénáře halucinací v podnikových aplikacích:
- Citování neexistujících soudních rozhodnutí nebo paragrafů zákonů při právním poradenství
- Vymýšlení názvů funkcí, tříd nebo knihoven při generování kódu
- Uvádění nesprávných statistik nebo dat v reportech
- Vymýšlení kontaktů, adres, telefonních čísel
- Míchání faktů týkajících se různých firem nebo osob s podobnými jmény
Vrstva 1 — Grounding (RAG)
Nejúčinnější jednotlivou technikou redukce halucinací je grounding — poskytnutí modelu konkrétních dokumentů nebo dat jako kontextu, ze kterého má čerpat odpovědi. Klasický RAG (Retrieval-Augmented Generation):
- Otázka uživatele → vyhledání nejrelevantnějších fragmentů dokumentů (vector search v databázi pgvector / Qdrant / Milvus)
- Fragmenty + otázka → prompt s instrukcí „odpověz výhradně na základě následujících dokumentů”
- Odpověď modelu → ověření, že obsahuje citace/odkazy na zdroje
RAG redukuje halucinace typicky o 60-80 % v aplikacích typu „odpovídej na otázky o naší znalostní bázi”. Neeliminuje je úplně — model může stále „interpretovat” dokumenty neoprávněným způsobem. Proto jsou potřebné další vrstvy.
Vrstva 2 — Self-consistency a ensemble
Self-consistency je technika spočívající v položení stejné otázky vícekrát (nebo několika různým modelům) a porovnání odpovědí. Když jsou odpovědi konzistentní — vysoká důvěra. Když se liší — signál, že téma je nejisté.
Praktická varianta: zeptejte se Claude Sonnet, Llama 70B a Bielika na stejnou otázku. Pokud všechny tři vrátí stejné číslo, datum, fakt — pravděpodobně správně. Pokud se liší — eskalace k člověku nebo k dražšímu modelu (Opus). Tento vzor, implementovaný v 8-úrovňovém LLM routingu, kombinuje redukci nákladů se zlepšením spolehlivosti.
Vrstva 3 — Evaluation pipelines
Produkční nasazení LLM bez evaluation pipeline je jako psaní kódu bez testů. Konkrétní metriky:
- Faithfulness — zda odpověď vyplývá z poskytnutých dokumentů. Měřeno druhým AI modelem (LLM-as-judge) nebo knihovnou typu RAGAS, deepeval.
- Answer relevance — zda odpověď adresuje otázku uživatele.
- Context precision — zda nejlepší fragmenty byly vráceny retrievalem (kvalita vector search).
- Groundedness score — procento tvrzení v odpovědi, pro která lze označit zdroj v kontextu.
Každý nový build aplikace založené na LLM by měl projít sadou 50-500 evaluačních otázek se známým ground truth. Pokud faithfulness klesne pod 90 % — deployment blocked.
Vrstva 4 — Guardrails a validace outputu
Guardrails jsou pravidla validující output LLM před dodáním uživateli. Příklady:
- Schema validation — output musí splňovat konkrétní schéma (JSON Schema, Pydantic). Halucinace typu „vymyšlená pole” jsou detekovány mechanicky.
- Forbidden patterns — detekce a blokování nepřípustných vzorů (PII bez maskování, finanční data mimo kontext, potenciálně škodlivý obsah).
- Citation enforcement — každé faktické tvrzení musí mít citaci zdroje. Pokud model necituje — odpověď je odmítnuta.
- Numeric range validation — čísla v outputu jsou kontrolována z hlediska smyslu (např. cena > 0, datum ≤ dnes, procento v rozsahu 0-100).
- Cross-reference check — porovnání outputu s bází faktů (např. KRS, slovník citací zákonů).
Knihovny: Guardrails AI, NeMo Guardrails, instructor (pro schema enforcement). Vlastní implementace je často jednodušší a levnější na údržbu.
Vrstva 5 — Human-in-the-loop
Pro aplikace s vysokým rizikem (právní, lékařská, finanční, HR rozhodnutí) je vrstva human-in-the-loop nepostradatelná. AI modely nedělají finální rozhodnutí — podporují člověka. Konkrétní vzory:
- Draft + review — AI generuje první verzi dokumentu/odpovědi, člověk ověřuje a akceptuje před odesláním.
- Confidence threshold — odpovědi s nízkým confidence (ze self-consistency nebo explicit confidence asking) se automaticky eskalují k člověku.
- Random sampling QA — 5-10 % všech LLM odpovědí je manuálně auditováno, nezávisle na confidence — bazální metrika kvality v čase.
- Feedback loop — uživatel může označit chybnou odpověď; systém se učí a vylepšuje retrieval, prompty, parametry.
Měření — jak vědět, že redukce funguje
Konkrétní produkční metriky, které stojí za sledování:
- Hallucination rate — procento odpovědí klasifikovaných jako halucinace v manuální evaluaci (sampling). Cíl: pod 2 % pro business-critical aplikace.
- User feedback rate — procento uživatelů, kteří označili odpověď jako chybnou.
- Escalation rate — procento dotazů eskalovaných k člověku. Příliš nízká (pod 5 %) — systém pravděpodobně přehlíží nejisté případy. Příliš vysoká (nad 30 %) — systém nedodává automatizační hodnotu.
- Faithfulness score v regresních testech — měsíční trend.
- Time-to-correction — od detekce halucinace po nasazení opravy (lepší retrieval, nový guardrail, fine-tuning).
Závěry pro rozhodující osoby
Halucinace jsou zvládnutelné — vyžadují investici do obranné architektury na mnoha vrstvách. Firmy, které nasazují LLM bez této architektury, dříve nebo později narazí na vážný incident (publikace chybné informace klientovi, chybné rozhodnutí na základě halucinovaných dat, reputační poškození). Náklad na vybudování plného obranného stacku (RAG + evaluation + guardrails + human-in-the-loop) je typicky 15-30 % nákladu samotného nasazení LLM — a je to investice absolutně nutná pro produkční aplikace. Důsledky vynechání jsou asymetrické: nízké náklady nečinnosti v 95 % případů, katastrofální v 5 %.