Jak zabránit halucinacím AI: RAG, Elasticsearch a validace výstupů v praxi

Co jsou halucinace a proč vznikají

Halucinace je situace, kdy jazykový model (LLM) vygeneruje odpověď, která vypadá přesvědčivě, ale je fakticky nesprávná. Model si „vymyslí" data, odkazy, čísla nebo produkty, které neexistují. Nejedná se o záměrnou lež — model nemá koncept pravdy. Predikuje statisticky nejpravděpodobnější sekvenci tokenů na základě trénovacích dat.

V kontextu e-commerce je to obzvlášť nebezpečné. Představte si, že zákazníkovi doporučíte příslušenství s odkazem na produkt, který ve vašem katalogu neexistuje. Nebo model tvrdí, že objektiv X je kompatibilní s fotoaparátem Y, přestože mají jiný bajonet. Výsledek? Ztráta důvěry, zbytečné reklamace a poškozená reputace e-shopu.

Reálný problém: Gemini doporučovalo neexistující produkty

V jednom z našich e-shopových projektů jsme nasadili Google Gemini pro dvě úlohy: doporučování kompatibilního příslušenství (např. baterie, objektivy, paměťové karty k fotoaparátům) a vyhledávání podobných produktů (alternativy ve stejné kategorii). Naivní přístup — zeptat se Gemini „Jaké příslušenství se hodí k Sony Alpha A7V?" — selhal okamžitě.

Model generoval produktové názvy a URL, které vypadaly věrohodně, ale neodpovídaly žádnému reálnému produktu v katalogu. Vymýšlel katalogová čísla, odkazoval na neexistující stránky a kombinoval reálné značky s fiktivními modely. Klasická halucinace — statisticky pravděpodobný, ale fakticky nesmyslný výstup.

Řešení: RAG architektura s Elasticsearch

Problém jsme vyřešili architekturou RAG (Retrieval-Augmented Generation) — vzorem, kdy model nedostává otevřený dotaz, ale pracuje výhradně s daty, která mu předložíme. Klíčový princip: model nevyhledává — model vybírá.

Celý systém má tři vrstvy:

1. Elasticsearch vrstva — vyhledá reálné kandidáty z databáze produktů
2. LLM vrstva (Gemini) — z kandidátů vybere nejvhodnější na základě technické kompatibility
3. Validační vrstva — ověří, že výstup modelu obsahuje pouze produkty z původního seznamu

Krok 1: Elasticsearch hledá kandidáty

Než se vůbec obrátíme na LLM, Elasticsearch najde 30–50 reálných produktů, které by mohly být relevantní. Používáme tři vyhledávací strategie a výsledky kombinujeme:

Strategie A: Zmínka modelu v popisu

Hledáme produkty, které v popisu, parametrech nebo názvu zmiňují zdrojový produkt. Například pokud hledáme příslušenství k „Sony Alpha A7V", najdeme baterie, které mají v popisu „kompatibilní se Sony Alpha A7V".

Pole body (popis produktu) má nejvyšší váhu (^5), protože výrobci příslušenství většinou uvádí kompatibilitu právě v popisu. Parametry (params) mají váhu ^3, název a nefiltrovaný text nižší.

Strategie B: Kompatibilní parametry

Ze zdrojového produktu extrahujeme klíčové technické parametry — typ baterie, bajonet objektivu, formát paměťové karty, rozměry filtrů — a hledáme produkty, které tyto hodnoty obsahují.

Strategie C: Značka + kategorie (fallback)

Pokud první dvě strategie nenajdou dostatek kandidátů, hledáme obecné příslušenství od stejné značky v jiné kategorii. Výsledky řadíme podle „karmy" produktu — interní metriky kvality a obliby.

Krok 2: Gemini vybírá ze seznamu kandidátů

Kandidáty z Elasticsearch předáme Gemini jako strukturovaný seznam s ID. To je klíčový rozdíl oproti naivnímu přístupu — model nedostává otevřenou otázku, ale konkrétní „menu", ze kterého může vybírat.

Každý kandidát obsahuje: ID z databáze, název, katalogové číslo, značku, kategorii, klíčové parametry a případně cenu a skladovou dostupnost. Model dostane systémovou instrukci, která ho striktně omezuje:

Klíčová slova v promptu: „POUZE", „z předloženého seznamu", „validním JSON". Model nemá prostor pro kreativitu — může pouze vybírat ID z předloženého seznamu a zdůvodnit výběr.

Krok 3: Validace výstupu

I s perfektním promptem může model občas vrátit neočekávaný výstup. Proto je třetí vrstva — serverová validace — nezbytná. Každé ID z Gemini odpovědi ověřujeme proti původnímu seznamu kandidátů:

Všimněte si dvou klíčových principů:

• Neznámá ID jsou tiše zahozena — pokud model vymyslí ID, které nebylo v kandidátním seznamu, jednoduše se ignoruje. Žádná chyba, žádný fallback, prostě se nepoužije.
• HTML se generuje z databáze, ne z modelu — názvy, URL, ceny, obrázky — vše pochází z ověřených databázových dat. Model pouze určil, které produkty vybrat, nikoli jak je zobrazit.

Proč je RAG tak účinný

RAG (Retrieval-Augmented Generation) není jen buzzword — je to fundamentální změna v tom, co od modelu požadujeme. Porovnejme dva přístupy:

Rozdíl je v tom, že RAG přesouvá úlohu modelu z generování faktů na reasoning nad fakty. Model nemusí „vědět" — musí pouze „rozhodnout". A rozhodování nad strukturovanými daty je přesně to, v čem LLM modely excelují.

Další techniky proti halucinacím

RAG s Elasticsearch je základ, ale existuje celá řada dalších technik, které můžete kombinovat. Projdeme si sedm nejúčinnějších.

1. Constrained output — JSON schéma a strukturované odpovědi

Místo volného textu vyžadujte od modelu striktně definovaný formát odpovědi. Moderní LLM API (Gemini, Claude, GPT-4o) podporují JSON mode nebo response schemas, které model nutí odpovídat v přesně definované struktuře.

Když model musí vrátit JSON s předdefinovanou strukturou, nemůže „odbočit" do volného textu a vymýšlet narativní odpovědi. Pole id s typem integer ho nutí vrátit číslo, ne vymyšlený URL.

2. Google Search Grounding

Gemini API nabízí vestavěnou funkci Google Search grounding — model si může ověřit fakta proti živým výsledkům z Google vyhledávání. Aktivujete ji jedním parametrem:

V našem projektu jsme tuto metodu použili jako alternativní přístup — Gemini generoval doporučení a současně si ověřoval existenci produktů přes Google. Ale i s touto funkcí jsme museli přidat post-processingovou vrstvu, která ověřovala vygenerované URL proti skutečné databázi a odstraňovala neexistující odkazy pomocí DOM manipulace.

Search grounding je užitečný jako doplňková vrstva, ale sám o sobě nestačí. Model může najít reálnou URL z Google, která ale neodpovídá vašemu katalogu — třeba produkt, který jste přestali prodávat nebo který je u konkurence.

3. Chain-of-Verification (CoVe)

Technika, kdy model sám sebe kontroluje ve vícekrokovém procesu:

1. Generování — model vytvoří odpověď
2. Generování ověřovacích otázek — model sám navrhne otázky, kterými lze odpověď zkontrolovat
3. Odpovědi na ověřovací otázky — model odpovídá na každou otázku nezávisle (bez kontextu původní odpovědi)
4. Oprava — model porovná původní odpověď s ověřovacími odpověďmi a opraví nesrovnalosti

CoVe neeliminuje halucinace úplně, ale výrazně je redukuje — model si často sám odhalí slabá místa. Hodí se zejména pro úlohy, kde nemáte strukturovaná zdrojová data pro plnohodnotný RAG.

4. Temperature a sampling parametry

Parametr temperature ovlivňuje „kreativitu" modelu. Pro faktické úlohy, kde nechcete žádnou kreativitu, nastavte temperature na minimum:

• Temperature 0.0–0.2 — deterministický výstup, model volí nejpravděpodobnější tokeny. Ideální pro klasifikaci, extrakci dat a výběr z předložených možností.
• Temperature 0.5–0.7 — mírná variabilita. Vhodné pro generování popisů nebo marketingových textů.
• Temperature 0.8–1.0+ — vysoká kreativita. Vhodné pro brainstorming, ale zvyšuje riziko halucinací.

Pro naši úlohu doporučování příslušenství používáme temperature: 0.1 — model by měl vybírat kompatibilní produkty konzistentně, ne „kreativně". Kombinace s topP a topK dále zužuje distribuci pravděpodobností a eliminuje dlouhý ocas nepravděpodobných tokenů.

5. Prompt engineering — explicitní omezení

Způsob, jakým formulujete prompt, má obrovský vliv na míru halucinací. Několik osvědčených technik:

Říct modelu, že může říct „nevím"

Modely mají tendenci vždy odpovědět — i když odpověď neznají. Explicitně jim dejte svolení říct „nevím":

Vyžadovat zdůvodnění (reasoning)

Když model musí ke každému výběru uvést důvod, kvalita výrazně stoupá — model si „uvědomí" slabá místa ve svém reasoning:

Negativní instrukce

Explicitně zakázat nežádoucí chování:

6. Post-processing a sanitizace výstupu

I se všemi výše uvedenými technikami je serverová validace nutná. Nikdy nespoléhejte na to, že model vrátí 100% korektní výstup. Implementujte tyto kontroly:

• ID validace — každé ID z odpovědi ověřit proti whitelist množině kandidátů
• JSON parsing s fallbackem — model občas vrátí JSON s extra textem; parsujte robustně pomocí regex extrakce JSON bloku
• URL sanitizace — pokud model přece jen vrátí URL, generujte je na serveru z databázového slugu, nikdy nepoužívejte URL z modelu
• Duplicity — model může stejný produkt doporučit vícekrát; deduplikujte podle ID
• Limit výstupů — omezte maximální počet doporučení (v našem případě max 12 produktů)

7. Cachování a human-in-the-loop

Dvě doplňkové strategie, které v praxi významně pomohou:

Cachování výsledků

Výsledky LLM doporučení ukládáme do cache (databáze) s TTL několik dní. Výhody:

• Konzistence — stejný zákazník vidí stejná doporučení při opakované návštěvě
• Rychlost — odpadá latence API volání (200–2000 ms)
• Náklady — eliminace zbytečných API volání šetří tokeny
• Kontrola — cachovaná doporučení lze manuálně revidovat a opravit

Human-in-the-loop

Pro kritické případy přidejte možnost lidské kontroly:

• Admin rozhraní, kde produktový manažer vidí AI doporučení a může je schválit/zamítnout
• Tlačítko „Špatné doporučení" pro zákazníky — feedback, který se loguje pro pozdější analýzu
• Pravidelný audit — náhodný vzorek doporučení procházený člověkem

Celkový přehled technik

Shrňme si všechny techniky a jejich účinnost:

Žádná technika sama o sobě nestačí. V produkčním systému je ideální kombinovat minimálně 3–4 z nich. V našem e-shopovém projektu používáme všech sedm vrstev současně.

Praktický checklist pro vývojáře

Pokud implementujete LLM do systému, kde záleží na faktické správnosti, projděte tento checklist:

1. Máte strukturovaná zdrojová data? → Implementujte RAG. Elasticsearch, Meilisearch, pgvector — cokoliv, co vám vrátí reálné kandidáty z vaší databáze.
2. Předáváte modelu data s unikátními ID? → Model musí vracet ID, ne volný text. ID validujete na serveru.
3. Vyžadujete JSON output? → Použijte responseMimeType: application/json a response schema, pokud to API podporuje.
4. Máte nízkou temperature? → Pro faktické úlohy 0.0–0.2. Kreativita je nepřítel přesnosti.
5. Říkáte modelu, že může říct „nevím"? → Explicitně. Jinak bude vždy generovat odpověď.
6. Validujete výstup na serveru? → Nikdy nezobrazujte surový LLM výstup uživateli bez validace.
7. Generujete URL a metadata na serveru? → Nikdy nepoužívejte URL z modelu. Vždy generujte z databáze.
8. Cachujete výsledky? → Šetří náklady, zvyšuje konzistenci, umožňuje audit.
9. Logujete vstupy i výstupy? → Bez logů nedokážete diagnostikovat problémy ani měřit kvalitu.
10. Máte fallback pro případ selhání? → Co se stane, když API neodpoví? Zobrazíte „žádná doporučení", ne rozbitou stránku.