Tvůrce a kritik: proč AI model neodhalí chyby ve vlastním textu

Požádat AI model, aby zkritizoval vlastní text, je intuitivní. Vypadá to efektivně. V praxi to často selže.

Model opraví styl, zjemní formulace a přidá pár výhrad. Klíčový omyl ale často zůstane. Jakmile stejný text dostane jiný model nebo role se skutečným mandátem hledat chyby, problém se objeví skoro okamžitě.

Důvod není magický. Je metodický. Vlastní revize bez nové perspektivy často jen znovu vzorkuje stejné rámování problému.

Rámec tvrzení

Co článek tvrdí: Vlastní kritika (self-critique) u LLM má systematicky nízkou účinnost při hledání klíčových chyb. Oddělení rolí tvůrce a kritika zvyšuje šanci odhalit konceptuální problémy. Největší efekt přináší kombinace oddělených rolí s různými modely a ověřovacím krokem.

Na čem to stojí: Výzkum Constitutional AI (Bai et al., 2022), Self-Refine (Madaan et al., 2023) a Chain-of-Verification (Dhuliawala et al., 2023); obecné principy alignment tréninku a optimalizace plynulosti textu.

Kde je to zjednodušení: Článek nepředkládá kvantitativní srovnání účinnosti self-critique vs. oddělených rolí. Efekt závisí na typu úlohy a konkrétním modelu. Tvrzení o „korelovaných chybách" je podloženo spíše intuicí než měřením.

Proč je vlastní kritika (self-critique) slabý výchozí režim

Když model napíše odpověď a pak dostane pokyn „zkontroluj se“, pořád pracuje se stejným kontextem, stejným zadáním a často i se stejnou implicitní interpretací problému.

To vede k typickému vzorci chování:

opraví tón,
doplní upozornění a výhrady,
přeformuluje věty,
zvýší opatrnost,
ale nezpochybní premisy, na kterých text stojí.

Je to podobné jako u člověka, který reviduje vlastní argument bez oponenta. Vidí spíš stylistické slabiny než konceptuální chyby. U LLM je ten efekt zesílený tím, že model optimalizuje na plynulý navazující text, ne na nezávislou epistemickou revizi.

To dobře navazuje na závěr článku LLM si neumí sám opravit chyby: bez externí zpětné vazby nebo nové informace má „oprava“ často podobu přeformulování, ne skutečné korekce.

Co dělá oddělení rolí tvůrce a kritika

Oddělení rolí (role separation) není kouzlo. Nevytváří nové znalosti z ničeho. Mění ale cíl a způsob čtení výstupu.

Role tvůrce

Tvůrce má za úkol vytvořit návrh. Jeho optimalizační cíl je produktivita: vytvořit strukturu, odpovědět, dodat směr.

Role kritika

Kritik má jiný mandát: hledat slabiny. Nepsat hezčí verzi. Nevyvažovat. Neobhajovat. Hledat, co je nejasné, nepodložené, vnitřně rozporné nebo nebezpečně zkratkovité.

Tohle oddělení mění výstup i tehdy, když použijete stejný model. Už samotná změna role zvýší šanci, že model projde text jiným filtrem.

Ještě větší efekt ale přichází, když oddělíte i perspektivu, tedy použijete jiný model nebo jiného poskytovatele. Pak už nejde jen o roli. Přidáváte i částečnou nezávislost dat, alignmentu a stylu odpovědi.

Jeden model ve dvou rolích vs. dva modely ve dvou rolích

Není nutné začínat komplexním orkestrovacím systémem. Stačí rozlišit tři úrovně.

Varianta 1: Stejný model, sekvenční role

Model vytvoří draft a pak ho kritizuje podle jasného checklistu. To je lepší než nic a často pomůže zachytit zjevné mezery.

Limitem je vysoká korelace chyb. Model sdílí stejnou interpretaci problému, takže nevidí to, co neviděl poprvé.

Varianta 2: Stejný model, paralelní role-prompty

Místo sekvence spustíte dvě role odděleně ze stejného inputu:

tvůrce,
kritik.

Tím snížíte vliv toho, že kritik jen reaguje na hotový text. Pořád ale jde o stejný model s podobnými zkresleními.

Varianta 3: Dva různé modely, různé role

To je prakticky nejzajímavější výchozí varianta. Jeden model generuje návrh, druhý má mandát na kritiku. Získáte nejen jinou roli, ale i jinou perspektivu.

Právě tady se nejlépe ukazuje, proč neshoda modelů není chyba, ale diagnostický signál. Kritický model někdy nevyhraje stylisticky, ale vyhraje z hlediska poznání (epistemicky).

Proč stejný model často neodhalí vlastní klíčový omyl

Existují minimálně čtyři praktické důvody.

1. Sdílený framing problému

Model si při generování odpovědi vytvoří interpretaci otázky. Pokud je tato interpretace chybná nebo příliš úzká, vlastní kritika (self-critique) ji často převezme jako fakt.

2. Lokální optimalizace textu

Model umí velmi dobře zlepšit lokální kvalitu: jasnost, styl, strukturu. To vytváří iluzi, že "provedl kritiku", i když jen zvýšil čitelnost chybného argumentu.

3. Sycophancy vůči zadání

Model může být příliš ochotný respektovat uživatelovu premisu. Když je premisa chybná, kritik potřebuje odvahu ji rozbít. Vlastní kritika (self-critique) často místo toho napíše opatrnější verzi téhož omylu.

4. Chybějící verifikační krok

Kritika bez důkazů je stále jen další text. Pokud workflow nekončí ověřením tvrzení, citací nebo výpočtů, ani dobrý kritik nezaručí správnost.

To je důvod, proč role tvůrce a kritika dává největší smysl až v kombinaci s verifikátorem nebo krokem křížové kontroly.

Jak vybírat model pro roli tvůrce a pro roli kritika

Nejlepší generátor nápadů nemusí být nejlepší kritik. To je hlavní pointa článku.

Co chcete od tvůrce

Tvůrce má být rychlý, produktivní a ochotný generovat varianty. Užitečné vlastnosti:

dobrá práce s nejasným briefem,
schopnost vytvořit strukturu,
rozumná diverzita návrhů,
nízká tendence zablokovat se na první interpretaci.

Co chcete od kritika

Kritik má být přísný a auditovatelný. Užitečné vlastnosti:

explicitní pojmenování slabiny,
práce s checklistem,
ochota říct "nevím" nebo "nepodloženo",
sklon oddělovat tvrzení od evidence.

Kritik nemusí psát krásně. Musí být užitečný.

Právě proto dává smysl vybírat modely podle role, ne podle prestiže. Produktově se to promítá i do průvodce výběrem modelu podle role v CrossChat.

Praktický workflow: draft → critique → revision → verification

Tady je jednoduchý protokol, který funguje pro text, analýzu i část workflow pro revizi kódu.

1. Draft (tvůrce)

Zadejte úkol a požádejte o první návrh. Uveďte cílové publikum a formát. Nechtějte současně i kritiku.

2. Critique (kritik)

Pošlete draft kritikovi s explicitním checklistem. Například:

Kde jsou nepodložená tvrzení?
Které premisy nejsou vyslovené?
Co je nejpravděpodobnější chyba, pokud autor špatně pochopil zadání?
Co chybí pro rozhodnutí?

3. Revision (tvůrce)

Tvůrce dostane kritiku a opraví text. Důležité je vynutit, aby reagoval na konkrétní výtky, ne jen přepsal odstavec.

4. Verification (verifikátor nebo křížová kontrola)

Vyberte 1-3 nejrizikovější tvrzení a ověřte je samostatně. Právě tady se rozhoduje, jestli workflow zvyšuje kvalitu, nebo jen produkuje hezčí text.

Tenhle čtvrtý krok bývá nejčastěji vynechán. A přesně proto mnoho týmů přeceňuje hodnotu vlastní revize.

Limity oddělení rolí (role separation): kdy kritik selže stejně jako tvůrce

Oddělení rolí není univerzální lék.

Korelované chyby

Dva modely mohou sdílet stejnou slepou skvrnu kvůli podobným datům nebo podobnému alignmentu. Pak kritik potvrdí chybu tvůrce jen jinými slovy.

Stejný vstupní framing

Když obě role dostanou špatně položenou otázku, problém se přenese do celého workflow. Oddělení rolí zlepšuje čtení odpovědi, ale nenahradí dobrou definici úkolu.

Kritika bez mandátu

Pokud kritik dostane prompt typu „zlepši text“, často sklouzne ke copyeditingu. Kritika potřebuje explicitní mandát hledat chyby a důkazy.

Chybějící rozhodovací pravidlo

Týmy někdy sbírají draft a kritiku, ale nemají pravidlo, co se s neshodou stane. Bez toho je workflow delší, ne lepší.

Oddělení rolí tedy řeší důležitou část problému, ale jen v rámci širšího návrhu pracovního postupu.

Závěr

AI není jedna homogenní „inteligence“, kterou stačí přepnout do režimu self-check. V praxi funguje lépe, když ji rozdělíte na role s různým cílem: tvůrce, kritik, verifikátor.

Vlastní revize má své místo jako rychlý hygienický krok. Pokud ale chcete odhalovat skutečné chyby, potřebujete novou perspektivu a ideálně i ověřovací vrstvu. CrossChat tento princip balí do workflow. Stejný princip ale můžete zavést i ručně: oddělte tvorbu od kritiky a přestaňte čekat, že autor spolehlivě odhalí vlastní slepou skvrnu.

Zdroje

Bai, Y. et al. (2022). Constitutional AI: Harmlessness from AI Feedback. arXiv:2212.08073. DOI: 10.48550/arXiv.2212.08073
Madaan, A. et al. (2023). Self-Refine: Iterative Refinement with Self-Feedback. arXiv:2303.17651. DOI: 10.48550/arXiv.2303.17651
Dhuliawala, S. et al. (2023). Chain-of-Verification Reduces Hallucination in Large Language Models. arXiv:2309.11495. DOI: 10.48550/arXiv.2309.11495
Ouyang, L. et al. (2022). Training language models to follow instructions with human feedback. arXiv:2203.02155. DOI: 10.48550/arXiv.2203.02155

Historie úprav

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

Jazyková revize (2026-02-25, Codex + GPT-5): opraveny mluvnické vazby, zpřesněna stylistika a omezeny zbytečné anglicismy; význam textu zachován. Kvalitativní audit (2026-03-23, Claude Code + Claude Opus 4.6): přidán Rámec tvrzení, ověřeny zdroje, jazyková úprava.