Model s istotou odpovie na otázku, ktorú správne zodpovedať nevie. Vymyslí citáciu, doplní chýbajúce číslo, potvrdí predpoklad v otázke — a celá odpoveď znie presvedčivo. Toto nazývame halucinácia (z angl. *hallucination*): generovanie vierohodného, ale fakticky nesprávneho výstupu. V experimentálnom nasadení to irituje. V produkcii — pri práci s dokumentáciou, zmluvami, technickými normami alebo zákazníckymi požiadavkami — to spôsobuje reálnu škodu.
Prax ukazuje, že základná miera halucinácií frontier modelov sa pohybuje rádovo v jednotkách až desiatkach percent pri odborných otázkach, kde model nemá dostatočný grounding. Cieľom tohto článku nie je sľubiť bezhalucinačný systém — taký neexistuje. Cieľom je ukázať päť techník, ktoré dokážu tento problém v produkcii výrazne znížiť, a vysvetliť, prečo každá funguje inak a prečo žiadna nestačí sama osebe.
Prečo halucinácie nezmiznú úplne
Skôr než prejdeme k technikám, treba rozumieť koreňovej príčine. LLM nevyhľadávajú fakty — generujú tokeny na základe toho, čo je štatisticky pravdepodobné v danom kontexte. Model nerozlišuje medzi "viem" a "neviem": ak nie je explicitne trénovaný alebo inštruovaný, aby vyjadroval neistotu, predvolene generuje plynulú a vierohodnú odpoveď.
Veľkosť modelu sama osebe problém nerieši — väčší model môže halucinovať sebavedomejšie, lebo jeho jazykové schopnosti sú lepšie a výstupy znejú presvedčivejšie. Bez grounding stratégie teda rast modelu neznižuje riziko, v niektorých prípadoch ho dokonca zvyšuje.
Dôsledok pre produkčné nasadenia: halucinácie treba riadiť architektonicky, nie len vybrať lepší model.
Technika 1: Grounding cez RAG s citovatelnými zdrojmi
RAG (*Retrieval-Augmented Generation*) je dnes najrozšírenejší mechanizmus na zníženie halucinácií pri faktografických otázkach. Princíp je jednoduchý: namiesto toho, aby model odpovedal z parametrickej pamäte (z toho, čo sa naučil pri tréningu), dostane do kontextu relevantné pasáže z overených dokumentov. Odpoveď potom musí vychádzať z tohto kontextu.
Samotné prilepenie dokumentov do promptu nestačí. Kvalitný grounding systém má tri vrstvy:
- Retrieval — vektorové vyhľadávanie (napr. cez
Qdrantalebopgvector) doplnené hybridným vyhľadávaním (BM25 + vektory), aby sa nenašli len sémanticky podobné, ale aj kľúčovosťou relevantné pasáže - Reranking — cross-encoder model prehodnotí poradie výsledkov; bez rerankingu retrieval vráti relevantné aj menej relevantné chunky, reranker výrazne zlepšuje presnosť výberu
- Citovateľnosť — model dostane inštrukciu: každé tvrdenie musí byť podložené konkrétnym zdrojom s odkazom na dokument a stranu; ak zdroj neexistuje, nevymýšľa
Citovateľnosť je kľúčová nie len pre presnosť, ale aj pre overiteľnosť: používateľ vidí, odkiaľ informácia pochádza, a môže ju overiť. V praxi to výrazne zvyšuje dôveru aj odhaľuje prípady, keď model citáciu ignoroval alebo si ju vymyslel. Viac o hodnotení RAG pipeline si môžete prečítať v článku Ako evaluovať RAG (RAGAS), kde opisujeme metriky faithfulness a answer relevance.
Dôležité upozornenie: RAG neerieši všetko. Ak retrieval vráti nesprávne chunky (embedding mismatch, zlé chunkovanie, neaktuálna databáza), model môže halucinovať aj s kontextom — alebo, čo je horšie, halucinovať s falošnou citáciou. RAG je nevyhnutná, nie dostačujúca podmienka.
Technika 2: Štruktúrovaný výstup a programatická validácia
Voľný text je ťažko overiteľný. Ak model vráti odpoveď v presne definovanej štruktúre — JSON schéma, Pydantic model, vymenovanie povolených hodnôt — môžeme výstup strojovo validovať skôr, než sa dostane k používateľovi alebo ďalšiemu systému.
Moderné modely a frameworky podporujú structured outputs (*štruktúrované výstupy*): model je nútený generovať tokeny, ktoré zodpovedajú zadanej schéme. Halucinácia teda nemôže vymyslieť pole, ktoré schéma neobsahuje. Ak je povolené pole risk_level s hodnotami ["low", "medium", "high"], model nemôže vrátiť "critical" alebo nezmysel.
V praxi kombinujeme tri kroky:
- 1.Definovanie výstupnej schémy (napr. JSON schema alebo Pydantic model)
- 2.Použitie
structured outputs/JSON modev API volaní - 3.Programatická validácia výstupu — ak výstup nezodpovedá schéme, volanie sa opakuje alebo sa eskaluje na ľudský review
Tento prístup funguje najlepšie na ohraničených úlohách: extrakcia entít, klasifikácia, vyplnenie formulára, konverzia dokumentu do štruktúry. Pre voľný text (zhrnutie, výklad) je použiteľnosť obmedzená, ale aj tu môžeme validovať aspoň prítomnosť povinných polí (napr. sekcia "Zdroje" alebo "Upozornenia").
Technika 3: Povolenie "neviem" — kalibrácia neistoty
Jeden z najjednoduchších a najúčinnejších krokov je explicitne dovoliť modelu odpovedať "neviem" alebo "na základe dostupných informácií to neviem posúdiť". Toto znejá triviálne, ale väčšina produkčných promptov na to zabudne — a model potom predvolene generuje odpoveď, aj keď informácie nemá.
Konkrétne v systémovom prompte (angl. *system prompt*) odporúčame formuláciu v štýle:
- Ak odpoveď nevyplýva z poskytnutých dokumentov, explicitne uveď, že informácia nie je k dispozícii.
- Nedomýšľaj ani neodvodzuj fakty, ktoré nie sú v kontexte.
- Ak si neistý, vyjadri mieru neistoty slovami ("pravdepodobne", "podľa dostupných informácií").
Dôležité je, že kalibrácia neistoty musí byť aktívna inštrukcia, nie len absence zákazu halucinovať. "Nehalucinuj" nestačí — model tejto inštrukcii rozumie, ale nemá mechanizmus, ako to vykonať bez explicitného rámca pre vyjadrenie neistoty.
V regulovaných oblastiach (právne dokumenty, technická dokumentácia, bezpečnostné normy) odporúčame zároveň definovať eskalačné pravidlo: ak model nie je schopný odpovedať s dostatočnou istotou, odpoveď by mala obsahovať výzvu na overenie u kompetentnej osoby. Toto priamo znižuje riziko tichej chyby — situácie, keď systém odpovie s istotou a chyba zostane neodhalená.
Technika 4: LLM-as-Judge — automatická verifikácia výstupov
LLM-as-Judge (*LLM ako sudca*) je technika, kde druhý jazykový model hodnotí výstup prvého. V produkcii sa používa na automatickú detekciu halucinácií, overenie konzistentnosti s kontextom a hodnotenie kvality odpovede — bez potreby ľudského reviewera pri každej odpovedi.
Typický tok vyzerá takto:
- 1.Primárny model vygeneruje odpoveď
- 2.Verifikačný model dostane trojicu: otázka + zdrojový kontext + vygenerovaná odpoveď
- 3.Verifikačný model hodnotí: obsahuje odpoveď tvrdenia, ktoré nie sú podporené kontextom? Je odpoveď fakticky konzistentná so zdrojmi?
- 4.Na základe skóre sa odpoveď buď doručí, zastaví, alebo odošle na ľudský review
Pre verifikačný model odporúčame použiť rovnaký alebo silnejší model než primárny — slabší verifikátor nedokáže spoľahlivo odhaliť chyby silnejšieho. V praxi vidíme dobré výsledky pri kombinácii lokálne bežiaceho primárneho modelu a frontier verifikátora (napr. Claude Sonnet alebo GPT-4o trieda) pre kritické odpovede.
Frameworky ako Langfuse alebo Arize Phoenix umožňujú tento flow zakomponovať do produkčného pipeline s logovaním, alertovaním a retrospektívnou analýzou. Viac o celkovom prístupe k meraniu kvality nájdete v článku Ako zmerať kvalitu LLM aplikácie (evals).
Obmedzenie: LLM-as-Judge nie je neomylný — aj verifikačný model môže "súhlasiť" s halucinovanou odpoveďou, ak obe sú konzistentné, ale fakticky chybné. Preto ho kombinujeme s groundingom (technika 1) a pravidelným ľudským auditom vzorky výstupov.
Technika 5: Teplota, sampling a prompt engineering
Posledná technika je najlacnejšia na implementáciu, ale má najmenší efekt bez ostatných vrstiev. Napriek tomu je dôležitá.
Teplota (*temperature*) ovplyvňuje náhodnosť generovania. Nízka teplota (napr. 0.0–0.2) produkuje deterministickejšie, konzistentnejšie výstupy — model volí najpravdepodobnejší token, nie náhodný. Pre faktografické úlohy (extrakcia, klasifikácia, odpovede na otázky z dokumentov) odporúčame nízku teplotu. Pre kreatívne alebo generatívne úlohy je vyššia teplota žiaduca, ale zároveň zvyšuje riziko odchýlok.
Prompt engineering pre zníženie halucinácií má niekoľko overených princípov:
- Few-shot príklady — ukáž modelu príklady správneho správania vrátane príkladov, kde odpoveď je "neviem"; model sa ich správanie učí v kontexte
- Explicitná špecifikácia formátu — "odpovedaj iba na základe nasledujúcich dokumentov, každé tvrdenie ukonči číslovanou citáciou"
- Záporné inštrukcie — "neodvodzuj informácie, ktoré nie sú explicitne uvedené v kontexte"
- Chain-of-thought (*reťazenie myšlienok*) — pri komplexných otázkach vyzvať model, aby premyslel odpoveď krok po kroku pred finálnym výstupom; pri citlivých úlohách toto výrazne znižuje "skratovanie" k halucinovanej odpovedi
Upozornenie: prompty sú krehké — fungujú pre konkrétny model a verziu. Pri zmene modelu alebo verzii treba prompty re-evaluovať. Prompt engineering je teda priebežná aktivita, nie jednorazový výstup. Podrobnejšie o tejto téme: Prompt engineering pre produkciu.
Päť techník dohromady
Žiadna z techník nestačí sama. V praxi ich kombinujeme do vrstiev:
- Základná vrstva — RAG s citáciami + povolenie "neviem" v systémovom prompte
- Výstupná vrstva — štruktúrovaný výstup + programatická validácia
- Verifikačná vrstva — LLM-as-Judge pre kritické odpovede
- Kalibračná vrstva — nízka teplota + few-shot prompt pre konzistentnosť
Efekt kombinácie je podstatne väčší ako súčet jednotlivých techník. Produkčné systémy, kde sme implementovali všetky štyri vrstvy, dosahujú výrazne nižšiu mieru faktických chýb ako systémy s jednou vrstvou — rádovo v desiatinstách percenta oproti jednotkám percent pri odborných otázkach. Presné čísla závisia od domény, kvality zdrojových dokumentov a spôsobu evaluácie.
Čo technikám nepomôže
Pre úplnosť: čo halucinácie nespoľahlivo znižuje:
- Väčší model — môže halucinovať sebavedomejšie; bez grounding stratégie nepomôže
- Dlhší kontext — viac dát v kontexte neznamená menej halucinácií; model môže ignorovať relevantný kontext alebo si ho chybne vyložiť
- Jednoduchý zákaz halucinovať v prompte — model nerozumie pojmu "halucinovanie" spôsobom, ktorý by mu umožnil ho aktívne zabrániť; potrebuje pozitívne inštrukcie pre vyjadrenie neistoty
- Benchmarkové skóre modelu — MMLU a podobné benchmarky sú saturované a nemeria produkčné správanie v odborných doménach; výsledok na leaderboarde nekorreluje spoľahlivo s halucinačnou mierou vo vašej konkrétnej aplikácii
Časté otázky
Je možné vytvoriť systém, ktorý nikdy nehalucinuje?
Nie. LLM sú stochastické generatívne modely — vždy existuje nenulová pravdepodobnosť halucinovaného výstupu. Cieľom nie je nulová chybovosť, ale zníženie na akceptovateľnú mieru pre daný use case a zavedenie mechanizmov na detekciu a zachytenie chýb skôr, než spôsobia škodu. Pre kritické rozhodnutia (právne, medicínske, bezpečnostné) ostáva ľudský review nevyhnutný.
Pomôže fine-tuning na firemných dátach znížiť halucinácie?
Len čiastočne a nie priamo. Fine-tuning (*doladenie modelu* na vlastných dátach) zlepšuje štýl odpovede, terminológiu a formát — ale nezlepší faktickú presnosť, ak model pri inferenci nedostáva príslušný kontext. Pre zníženie halucinácií je RAG typicky účinnejší a lacnejší prístup. Fine-tuning a RAG sa navzájom nevylučujú — ich kombinácia dáva zmysel v pokročilejších nasadeniach. Rozhodovanie medzi nimi popisujeme v článku RAG vs fine-tuning — rozhodovanie.
Ako zistiť, koľko naša LLM aplikácia halucinuje?
Systematická evaluácia vyžaduje eval dataset — sadu otázok so správnymi odpoveďami alebo zdrojovými dokumentmi — a evaluačný framework ako RAGAS (pre RAG pipeline) alebo Langfuse (pre všeobecné LLM aplikácie). Automatizovaná evaluácia pomocou LLM-as-Judge môže pokryť veľké objemy, ale treba ju kalibrovať voči ľudskému hodnoteniu aspoň na vzorke. Periodický ľudský audit výstupov v produkcii odporúčame vždy, nie len pri prvom nasadení.
Zvyšuje nízka teplota riziko stereotypných alebo nekompletných odpovedí?
Áno, je to reálny trade-off. Nízka teplota znižuje variabilitu — model konzistentne volí najpravdepodobnejšie tokeny, čo v extrémnych prípadoch môže viesť k opakujúcim sa frázam alebo vynechávaniu menej pravdepodobných, ale relevantných informácií. V praxi odporúčame teplotu 0.1–0.3 pre faktografické úlohy, nie absolútnu nulu, a kombinovať ju s explicitnými inštrukciami pre úplnosť odpovede.
Aká je cena za zavedenie týchto techník?
Náklady sú primárne implementačné a prevádzkové. RAG pipeline vyžaduje vektorovú databázu, embedding model a retrieval logiku — pri self-hosted riešení (napr. Qdrant + open-weight embedding model) ide o jednotky eur mesačne za infraštruktúru. LLM-as-Judge zdvojnásobí počet LLM volaní na kritické výstupy, čo zvyšuje API náklady. Structured outputs sú prakticky bez nákladov navyše. Celková investícia závisí od objemu, ale pri typických firemných aplikáciách (desiatky až stovky dopytov denne) je zvýšenie nákladov zanedbateľné oproti riziku tichej chyby v produkcii.
*Ak plánujete nasadiť LLM v prostredí, kde faktická presnosť priamo ovplyvňuje rozhodnutia — od technickej dokumentácie po zákaznícku podporu alebo compliance — radi vám pomôžeme posúdiť, ktorá kombinácia techník dáva zmysel pre váš konkrétny prípad. MP Industrial Solutions má skúsenosť s produkčnými nasadeniami v priemyselnom aj regulovanom prostredí.*