Jak odhalit AI halucinaci bez přístupu k primárním zdrojům

Nemáte přístup k databázi. Článek je za paywallem. Expert není po ruce. Přesto potřebujete rychle rozhodnout, jestli AI odpověď stojí na pevných základech, nebo si model pravděpodobně vymýšlí.

Tohle je častější situace, než se zdá. A právě tady pomáhá triangulace: neptáte se jednou, ale testujete stabilitu odpovědi přes více formulací, více modelů a více typů opěrných bodů.

Důležité upozornění: cílem není potvrdit pravdu bez zdrojů. Cílem je odhalit vysoké riziko halucinace dřív, než špatné tvrzení použijete dál.

Rámec tvrzení

Co článek tvrdí: Halucinace lze s vysokou pravděpodobností odhalit i bez primárních zdrojů, a to triangulací přes nezávislé formulace, vynucování opěrných bodů a sledování stability odpovědi. Nestabilita napříč formulacemi a modely je diagnostický signál.

Na čem to stojí: Xu et al. (2024) o systémové nevyhnutelnosti halucinací; Dhuliawala et al. (2023) o chain-of-verification; Yao et al. (2023) o ReAct frameworku. Postup vychází z principů verifikace a falsifikace.

Kde je to zjednodušení: Metoda detekuje křehkost odpovědi, nikoli faktickou nepravdivost. Stabilní halucinace (konzistentně opakovaná nepravda) může tímto postupem projít. Článek neuvádí empirická data o účinnosti triangulace.

Co je halucinace v praktickém smyslu (pro tento workflow)

V technických debatách má pojem halucinace různé definice. Pro praktickou práci si vystačíte s jednodušší verzí:

Halucinace je výstup, který zní věrohodně, ale není spolehlivě podložený a model ho nedokáže stabilně obhájit při ověřovacích dotazech.

Tohle vymezení je užitečné, protože se dá testovat i bez okamžitého přístupu k primárnímu zdroji. Nesnažíte se dokázat absolutní nepravdu. Testujete, zda odpověď drží pohromadě pod tlakem.

A protože halucinace jsou systémový jev, ne náhodná závada, dává smysl budovat workflow, které umí riziko odhalit. Přesně to je praktický důsledek argumentu z Halucinace je matematicky nevyhnutelná.

Krok 1: Najděte nejrizikovější část odpovědi

Neověřujte celý text najednou. Vyberte jedno tvrzení (claim), které má nejvyšší dopad, pokud je špatně.

Typicky jde o:

konkrétní číslo,
odkaz na studii,
právní tvrzení,
technický mechanismus,
historický fakt,
kauzální vysvětlení prezentované jako jistota.

Proč je to důležité? Protože široké ověřování generuje šum. Modely začnou řešit vedlejší části a ztratíte signál o kritickém bodu.

Triangulace funguje nejlépe jako skalpel, ne jako síť.

Krok 2: Vytvořte tři nezávislé formulace stejného dotazu

Cílem je otestovat, jestli odpověď drží i při změně formulace (wordingu). Halucinace bývá často křehká: model ji zopakuje v původním rámci, ale rozpadne se při mírně jiné formulaci.

Použijte tři typy promptu:

A. Přímý dotaz

"Je toto tvrzení správné? Pokud nevíš, napiš, co přesně chybí k ověření."

B. Falsifikační dotaz

"Předpokládej, že tvrzení může být chybné. Jaké jsou nejpravděpodobnější důvody, proč by neplatilo?"

C. Mechanistický dotaz

"Vysvětli mechanismus nebo definice, které musí být pravdivé, aby tvrzení platilo."

Třetí varianta je důležitá. Model může zvládnout zopakovat tvrzení, ale selže při vysvětlení mechanismu. To je častý signál, že jen generuje věrohodně znějící povrch.

Krok 3: Vynucujte opěrné body, ne jen odpověď

Pokud dostanete jen "ano/ne", téměř nic jste neotestovali. Potřebujete po modelu opěrné body, které lze později ověřit.

Žádejte alespoň jednu z těchto věcí:

název studie nebo dokumentu,
typ zdroje (např. zákon, standard, paper, release notes),
definici klíčového pojmu,
podmínky, za kterých tvrzení platí,
hlavní výhradu nebo limitaci.

Proč to funguje? Halucinované tvrzení je často snadné prohlásit a těžší ho ukotvit do konzistentní struktury pojmů, zdrojů a podmínek.

Tohle je prakticky stejná logika jako v ověřování AI citací: nestačí, že model něco tvrdí. Musí být schopný ukázat, z čeho to tvrdí a za jakých podmínek.

Krok 4: Sledujte stabilitu odpovědi při malé změně kontextu

Teď udělejte malou změnu. Ne velký pivot. Jen test stability.

Příklady:

změňte pořadí podotázek,
zkraťte tvrzení na jádro,
explicitně vyžádejte definice před odpovědí,
zeptejte se na kontra-příklad,
požádejte o situaci, kde tvrzení neplatí.

Co hledáte:

odpověď zůstává konzistentní a přidává výhrady -> dobré znamení,
odpověď dramaticky mění tvrzení bez vysvětlení -> varování,
model začne mlžit a uhýbat k obecným větám -> varování,
model si protiřečí mezi dvěma kroky -> silný signál problému.

Tady se halucinace často prozradí dřív než v samotném "fact check" promptu. Nestabilita je diagnostická informace sama o sobě.

Krok 5: Hledejte bod zlomu neshody mezi modely

Když používáte více modelů, nejdůležitější není počet souhlasných odpovědí. Důležité je místo, kde souhlas končí.

Zapište si:

Na čem se shodnou všichni?
Kde se rozcházejí definice?
Kde se rozcházejí zdroje?
Kdo jako první přizná nejistotu?
Který model přináší konkrétní výhradu, kterou ostatní ignorují?

Tenhle "bod zlomu" je často přesně místo, které musíte později ověřit primárně.

Příklad patternu:

všichni souhlasí na obecném principu,
rozcházejí se na rozsahu platnosti,
nikdo nedá ověřitelný zdroj,
jeden model upozorní na kontextový limit.

To není potvrzený fakt. To je signál, že tvrzení je nejspíš příliš silné nebo špatně formulované.

Krok 6: Klasifikujte výsledek (pracovní verdict, ne finální pravda)

Abyste se neutopili v dotazování, potřebujete pracovní klasifikaci.

A. Pravděpodobně OK pro interní pracovní použití

Odpověď je stabilní napříč formulacemi, modely se shodují na definicích a výhradách a tvrzení je formulované opatrně. Stále ho označte k pozdějšímu ověření, pokud jde do publikace.

B. Nejisté / vyžaduje zpřesnění

Modely se rozcházejí hlavně kvůli neurčité formulaci nebo rozsahu (scope). Tady často stačí tvrzení přepsat a test zopakovat.

C. Pravděpodobná halucinace nebo nepodložené tvrzení

Odpověď je nestabilní, modely si odporují v klíčových bodech, chybí konzistentní opěrné body a tvrzení zní jistěji, než odpovídá evidenci. Nepoužívat bez primárního ověření.

Důležité: tato klasifikace není soud. Je to workflow rozhodnutí o dalším kroku.

Nejčastější chyby při triangulaci

Chcete po AI definitivní verdikt

Triangulace není náhradní soudce. Je to test křehkosti odpovědi.

Testujete příliš mnoho tvrzení najednou

Pak nevíte, který bod selhal. Vraťte se k jednomu nejrizikovějšímu tvrzení.

Přejímáte jistý tón jako důkaz

Plynulost a sebejistota jsou stylové vlastnosti, ne evidence. Přesně proto je třeba vynucovat opěrné body.

Přeskočíte krok "mechanismus / definice"

Bez něj model snadno generuje plausibilní slogan místo skutečně podloženého tvrzení.

Rychlý přehled: 3–5 minutový křížový test bez primárních zdrojů

Vyber nejrizikovější tvrzení.
Zeptej se na něj třemi formulacemi (přímá, falsifikační, mechanistická).
Vyžádej si zdrojový typ, definice a výhrady.
Udělej malý test stability (kontra-příklad / změna wordingu).
Najdi bod zlomu neshody.
Zařaď: OK / nejisté / pravděpodobná halucinace.

Pokud vyjde poslední dvě kategorie, workflow končí a nastupuje primární ověření.

Závěr

Bez primárních zdrojů neověříte pravdu. Můžete ale velmi dobře odhalit, že odpověď je křehká, nepodložená nebo podezřele stabilní jen v jednom framingu.

To je praktická hodnota triangulace: chrání vás před tím, abyste plynulý text zaměnili za poznání. CrossChat tenhle postup zrychlí, protože umí paralelizovat role a porovnat neshodu na jednom místě. Metoda samotná je ale přenositelná do jakéhokoli AI nástroje.

Zdroje

Xu, Z. et al. (2024). Hallucination is Inevitable: An Innate Limitation of Large Language Models. arXiv:2401.11817. DOI: 10.48550/arXiv.2401.11817
Dhuliawala, S. et al. (2023). Chain-of-Verification Reduces Hallucination in Large Language Models. arXiv:2309.11495. DOI: 10.48550/arXiv.2309.11495
Yao, S. et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629. DOI: 10.48550/arXiv.2210.03629

Historie úprav

Koncept: Codex + GPT-5.3-Codex Verze 1: Codex + GPT-5.3-Codex

Jazyková revize (2026-02-25, Codex + GPT-5): zpřesněna stylistika, sjednocena terminologie a omezeny anglicismy; pracovní postup zůstává beze změny. Kvalitativní audit (2026-03-23, Claude Code + Claude Opus 4.6): přidán Rámec tvrzení, ověřeny zdroje, jazyková úprava.