Co prozradí AI model, když dostane záměrně nejasnou otázku

Víceznačný prompt se obvykle bere jako chyba uživatele. A často to chyba opravdu je.

Právě proto je ale tak užitečný.

Reakce modelu na nejasnou otázku ukáže něco, co z čistě „dobře napsaného“ promptu často neuvidíte: jak model zachází s nejistotou. Zeptá se na upřesnění? Vybere jednu interpretaci a přizná předpoklad? Nebo plynule doplní chybějící kontext, jako by mu byl zadán?

Tohle není drobný UX detail. V praxi je to diagnostika vhodnosti modelu pro různé role. Jiný styl chování chcete od rychlého chat asistenta, jiný od kritika, syntetika nebo role, která má hlídat rozhodnutí s vysokými důsledky.

Rámec tvrzení

Co článek tvrdí: Reakce modelu na záměrně nejasnou otázku je diagnostický nástroj pro posouzení vhodnosti modelu k dané roli ve workflow. Existují tři základní režimy reakce na nejednoznačnost (upřesnit, předpokládat, maskovat) a správný režim závisí na roli a ceně chyby. Ambiguitu lze využít jako strukturovaný benchmark.

Na čem to stojí: Obecné principy kognitivní psychologie (Heuer, 1999; Tversky a Kahneman, 1981), holistická evaluace modelů (Liang et al., 2022), NIST AI Risk Management Framework (2023); praktické zkušenosti s chováním LLM.

Kde je to zjednodušení: Článek nepředkládá kvantitativní výsledky z ambiguity benchmarku. Tři režimy jsou zjednodušující taxonomie; reálné chování modelů je plynulejší. Závěry o vhodnosti modelů pro role vycházejí z pozorování, nikoli z kontrolovaných experimentů.

Proč má smysl zkoumat ambiguitu místo jen "lepšího promptu"

Rada "napiš lepší prompt" je správná, ale neúplná.

V reálném provozu lidé často pokládají otázky:

bez kontextu,
se smíchanými cíli,
s nejasnou terminologií,
s implicitními předpoklady, které si sami neuvědomují.

To neplatí jen pro začátečníky. Platí to i pro zkušené uživatele, když spěchají, řeší nový problém nebo teprve formulují, co vlastně chtějí.

Model proto musí udělat první interpretaci. A právě ta je často rozhodující. Pokud se vydá špatným směrem, může napsat výborně strukturovanou odpověď na špatně pochopenou otázku.

Z pohledu návrhu workflow je tedy užitečnější ptát se: „Jak model reaguje na nejasnost?“
než jen: „Jak dobře odpovídá na precizní prompt?“

Téma navazuje na A09, kde je neshoda modelů diagnostickým signálem. Tady sledujeme signál ještě o krok dřív: první tah modelu při interpretaci zadání.

Ne každá ambiguita je stejná

Častá zkratka je říct, že prompt byl „nejasný“. To je příliš hrubá diagnóza.

Pro praxi je užitečné rozlišit alespoň tři typy ambiguity.

1. Lexikální ambiguita

Jedno slovo nebo pojem má více významů.

Příklad:

"model" může znamenat AI model, statistický model, obchodní model
"audit" může být bezpečnostní audit, finanční audit nebo procesní revize

Tady dobrý model buď:

identifikuje více interpretací,
nebo zvolí jednu a explicitně řekne, jak ji pochopil.

Rizikový režim je, když interpretaci zvolí skrytě a pokračuje, jako by nejednoznačnost neexistovala.

2. Pragmatická ambiguita

Pojmy jsou jasné, ale chybí účel otázky.

Například: "Jak použít AI debatu?"

To může znamenat:

edukativní vysvětlení principu,
návrh workflow pro konkrétní firmu,
kritiku metody,
srovnání s jinou technikou.

Model, který neumí pracovat s pragmatickou nejasností, často vyrobí obecný text, který zní správně, ale netrefí skutečný cíl uživatele.

3. Procedurální ambiguita

Uživatel chce výsledek, ale neupřesní formát nebo kritérium úspěchu.

Například: "Porovnej tyto modely."

Podle čeho?

ceny,
latence,
kvality odpovědí,
role-fit pro workflow,
compliance rizik?

Bez procedurálního rámce model snadno odpoví "nějak". To je často použitelné v chatu, ale riskantní ve workflow, kde potřebujete auditovat, proč byl výsledek vyhodnocen jako dobrý.

Praktický závěr: „špatný prompt“ není jedna kategorie. Každý typ ambiguity vyvolává jiný typ selhání (failure mode) a jiný typ opravného kroku.

Tři první tahy modelu: upřesnit, předpokládat, maskovat nejistotu

Když model dostane nejasné zadání, první reakce bývá velmi informativní. Často více než samotná finální odpověď.

V praxi se opakují tři základní režimy.

Režim 1: Clarify-first (nejdřív upřesnit)

Model nejprve identifikuje nejednoznačnost a položí doplňující otázku nebo nabídne několik interpretací.

Výhody:

snižuje riziko chybného směru,
dobře funguje v analytických úlohách a v úlohách s vysokou cenou chyby,
zvyšuje auditovatelnost (je vidět, co bylo nejasné).

Nevýhody:

zpomaluje konverzaci,
může působit "méně užitečně" v low-stakes chatu,
při přehnaném používání zhoršuje UX.

Tohle je často dobré chování pro role typu kritik, reviewer nebo pre-solving krok.

Režim 2: Assume-and-answer (zvol předpoklad a pokračuj)

Model vybere nejpravděpodobnější interpretaci a odpoví. Lepší verze tohoto režimu předpoklad explicitně pojmenuje.

Například: "Budu předpokládat, že vám jde o porovnání podle ceny a latence..."

Tohle je velmi užitečný kompromis:

zachová tempo,
přizná nejistotu,
umožní uživateli rychlou korekci.

V mnoha běžných scénářích je to nejpraktičtější chování.

Režim 3: Confident fill-in (maskovaná nejistota)

Model tichým předpokladem doplní chybějící kontext a prezentuje odpověď, jako by otázce rozuměl jednoznačně.

To je nejrizikovější režim.

Ne proto, že odpověď musí být nutně chybná. Někdy trefí správnou interpretaci. Problém je jiný: uživatel nevidí, že odpověď stojí na domněnce.

Ve workflow s vysokými důsledky je to nebezpečné, protože chyba vzniká na úrovni interpretace zadání, ale navenek vypadá jako „normální“ odpověď. Pozdější verifikace pak řeší fakta, ne špatný rámec otázky.

Právě tady se ukazuje rozdíl mezi plynulostí a porozuměním. Plynulá odpověď může maskovat nejistotu lépe než špatná odpověď.

Co chování vůči ambiguitě říká o tréninku a produktové optimalizaci

Je lákavé číst reakci na nejasnost jako čistý test "inteligence". To je nepřesné.

Chování modelu vůči ambiguitě bývá směs:

architektury a schopností modelu,
preference tuningu,
bezpečnostních vrstev,
produktových cílů (rychlost, plynulost, spokojenost uživatele).

Reward na helpfulness vs. opatrnost

Pokud je systém silně optimalizovaný na to, aby "pomohl" a nezasekl konverzaci, může preferovat odpověď i tam, kde by byl lepší clarifying dotaz.

To není nutně chyba tréninku. Je to designová volba. V běžném chatu může být výhodná. V analytickém workflow může zvyšovat riziko skrytých předpokladů.

Produktový tlak na plynulost

Z pohledu produktu je plynulá konverzace silný signál kvality. Uživatel má pocit, že systém rozumí.

Jenže plynulost a správně zvolený rámec problému nejsou totéž. Model může plynule pokračovat ve špatně zvolené interpretaci. Proto je užitečné mít v některých workflow rolích model nebo prompt, který smí "brzdit" a ptát se.

Bezpečnostní vrstvy nejsou totéž co ambiguity handling

Bezpečnostní pravidla mohou přidat opatrnost v citlivých tématech. To ale automaticky neřeší běžnou pragmatickou nebo procedurální nejasnost.

Model může být bezpečný a zároveň příliš ochotný domýšlet kontext u pracovních úloh. Proto je lepší ambiguity handling testovat přímo, ne usuzovat z obecného dojmu "zní opatrně".

Praktický důsledek: dva velmi silné modely mohou na stejném nejasném promptu působit úplně jinak a oba mohou být "správná" volba pro jinou roli workflow.

Jak použít záměrně nejasné otázky jako diagnostický benchmark

Tady je největší praktická hodnota článku.

Místo jednorázového dojmu z několika chatů si můžete vytvořit malý benchmark pro práci s nejednoznačností (ambiguity handling). Nemusí být akademický. Stačí, aby byl konzistentní.

Princip: stejná otázka ve třech variantách

Vyberte několik promptů a každý otestujte ve třech verzích:

Bez kontextu Čistě nejasná verze.
S minimálním kontextem Doplníte jen účel nebo doménu.
S explicitním cílem a formátem Téměř produkční zadání.

Tím uvidíte, jestli model:

správně detekuje nejasnost,
přestane zbytečně improvizovat po doplnění minima,
nebo se chová stejně bez ohledu na kvalitu zadání.

Co logovat (a proč)

Mnoho lidí hodnotí jen finální kvalitu odpovědi. Pro ambiguity benchmark je důležitější logovat první tah modelu.

Prakticky si pište:

požádal o upřesnění? (ano/ne)
pojmenoval předpoklad explicitně?
zvolil interpretaci skrytě?
jak kvalitní byly doplňující otázky?
změnila se odpověď po doplnění minima kontextu?

Tohle vám dá profil chování modelu, ne jen jednu známku kvality.

Benchmark pro role, ne jen pro "model obecně"

Ještě užitečnější je testovat stejný model v různých role-promptech:

scout,
kritik,
syntetik.

Někdy zjistíte, že model je výborný scout (rychle předpokládá a pokračuje), ale špatný kritik (málo se ptá a málo zpochybňuje rámec). To je přesně informace, kterou potřebujete pro role assignment a výběr workflow.

Tento typ testu dobře navazuje na D01, protože práce s nejednoznačností často rozhoduje, zda má workflow začít krokem upřesnění (clarifying krokem) místo okamžité odpovědi.

Kdy ambiguitu využít a kdy ji naopak rozpustit už v zadání

Po přečtení předchozí části může vzniknout dojem, že nejlepší strategie je nechávat prompty nejasné a sledovat reakce modelu. To by byla chyba.

Ambiguita je užitečná hlavně ve dvou situacích:

při evaluaci modelů,
při odhalování skrytých předpokladů na začátku procesu.

V produkčním workflow je většinou lepší ambiguitu explicitně zpracovat:

doplnit účel,
publikum,
kritérium úspěchu,
formát výstupu,
omezení.

Proč? Protože tím zvyšujete:

reprodukovatelnost výsledku,
auditovatelnost procesu,
srovnatelnost mezi modely,
kvalitu handoff mezi rolemi.

Praktické pravidlo:

Ambiguitu testuj záměrně
Ambiguitu v produkci pojmenuj

To neznamená, že uživatel musí psát perfektní prompt. Znamená to, že workflow má mít místo, kde se nejasnost buď využije jako diagnostika, nebo se převede na explicitní vstup.

Mini benchmark walkthrough: jak to udělat bez laboratoře

Hodně týmů se ambiguity benchmarku vyhne, protože to zní jako výzkumný projekt. Ve skutečnosti stačí malá sada promptů a disciplinovaný log.

Krok A: Vyberte 3-5 promptů z vlastní práce

Ideální mix:

jeden faktický dotaz, kde hrozí záměna významu,
jeden strategický dotaz s nejasným cílem,
jeden procesní dotaz bez definovaného formátu výstupu.

Neberte demo prompty. Vezměte otázky, které se vám v týmu skutečně vrací.

Krok B: Každý prompt napište ve třech verzích

Například:

verze 1: nejasná (původní formulace)
verze 2: s minimálním kontextem ("jde mi o interní rozhodnutí")
verze 3: s explicitním cílem a formátem ("chci 5 bodů, rizika, doporučení")

Tím otestujete nejen "jak odpovídá", ale "jak citlivě reaguje na zlepšení zadání".

Krok C: Hodnoťte první reakci, ne dojem z finálního textu

Praktický zápis může mít jednoduché sloupce:

model / role
typ první reakce (clarify / assume-explicit / assume-silent)
kvalita doplňující otázky
změna po doplnění kontextu
poznámka k riziku (např. skrytý předpoklad)

Tohle je důležité, protože jinak vás snadno okouzlí kvalita finálního textu a přehlédnete, že model došel ke správné odpovědi přes neviditelně špatný rámec.

Krok D: Závěr převádějte do přiřazení rolí (role assignmentu)

Výstup benchmarku nemá být "model X je nejlepší". Lepší závěr je:

model A je vhodný pro rychlého scouta (rychlé předpoklady, dobrá plynulost)
model B je vhodný pro kritika (častěji žádá upřesnění)
model C potřebuje explicitní pre-solving krok, jinak příliš domýšlí

To je operativně užitečnější než obecné pořadí modelů.

Navrhněte ambiguity policy podle role workflow

Ambiguity handling se dá řídit i bez výměny modelu. Často stačí role-specific pravidlo.

1. Scout / generátor

U scouta bývá rozumné povolit více předpokladů, protože cílem je rychlá explorace. Důležité ale je, aby model předpoklady označil.

Praktické pravidlo: "Pokud je zadání nejasné, uveď 2-3 interpretace a zvol jednu pracovní variantu."

2. Kritik / reviewer

U kritika je naopak žádoucí vyšší citlivost na nejasnost. Kritik má často upozornit právě na to, že zadání skrývá předpoklad nebo konflikt cílů.

Praktické pravidlo: "Pokud je otázka nejednoznačná, nejprve pojmenuj, co nelze bezpečně vyhodnotit bez upřesnění."

3. Syntetik

Syntetik by neměl bez varování sjednocovat nejasné vstupy do jedné verze reality. Jeho role je oddělit, co je jisté, co sporné a co závisí na interpretaci.

Praktické pravidlo: "Uveď, které závěry platí napříč interpretacemi a které závisejí na konkrétním předpokladu."

4. Pre-solving / routing krok

Pokud workflow obsahuje pre-solving fázi, ambiguity handling se z ní stává explicitní gate:

identifikuj nejasnost,
navrhni minimální doplnění,
rozhodni, zda pokračovat nebo zastavit.

To je v praxi velmi silné, protože se chyba interpretace řeší dřív, než se rozběhne dražší část workflow (debata, verifikace, syntéza).

Právě tady se ambiguita mění z problému na návrhový vstup do architektury workflow.

Tři chyby při vyhodnocování ambiguity testu

I dobře navržený mini benchmark můžete špatně interpretovat. V praxi se opakují tři chyby.

Chyba 1: Zaměníte "odpověděl správně" za "zacházel dobře s nejasností"

Model může trefit správnou interpretaci náhodou nebo díky tomu, že váš tým používá typické formulace. To ještě neznamená, že ambiguity handling je robustní.

Proto sledujte i procesní signál:

přiznal předpoklad?
nabídl alternativní interpretaci?
položil kvalitní doplňující otázku?

Bez toho hodnotíte jen výsledek, ne behaviorální vlastnost, kterou chcete měřit.

Chyba 2: Testujete jen jednu doménu

Model může být velmi dobrý v nejasných technických dotazech a slabší v business nebo procesních zadáních, protože používá jinou sadu implicitních předpokladů.

Stačí malá diverzita:

technický prompt,
rozhodovací prompt,
komunikační prompt.

Tím získáte realističtější obraz, jak model reaguje na různé typy nejasnosti.

Chyba 3: Z výsledku uděláte univerzální reputační soud

Výsledek benchmarku by neměl znít: "Tento model je špatný."

Lepší závěr je: "Tento model je riskantní bez pre-solving kroku" nebo "Tento model je vhodný pro scout roli, ale ne pro kritika."

Tohle je důležité, protože ambiguity handling je role-dependent vlastnost. Stejné chování může být výhoda v jednom workflow a slabina v jiném.

Právě takový styl vyhodnocení zvyšuje šanci, že benchmark povede k lepšímu návrhu procesu místo nekonečných debat o značkách modelů.

Krátký provozní checklist pro tým

Pokud chcete ambiguity test zavést prakticky, stačí malý režim:

Vyberte 3-5 reálných nejasných promptů z práce týmu.
Otestujte je na kandidátních modelech nebo rolích.
Logujte první reakci, ne jen finální kvalitu textu.
Vyhodnoťte závěry jako "vhodné pro roli", ne jako absolutní pořadí.
Upravte pre-solving nebo role prompty tam, kde modely příliš domýšlí.

Tohle je lehký proces, který přinese víc signálu než další náhodné porovnávání modelů na dobře připravených demo otázkách a marketingových ukázkových promptech. Navíc se snadno opakuje v interních revizních cyklech bez velké dlouhodobé režie.

Kontraargument: příliš mnoho upřesňování kazí UX

Tohle je validní námitka.

Pokud model na každou drobnou nejasnost reaguje sérií dotazů, běžný chat se stane nepoužitelný. U low-stakes úloh může být plynulé "assume-and-answer" chování lepší volba než opatrná, ale pomalá interakce.

Smysl článku proto není prosadit „clarify-first“ jako univerzální normu. Smysl je ukázat, že správná strategie závisí na roli workflow a ceně chyby. To, co je výborné pro chat asistenta, může být špatné pro kritika nebo compliance revizi.

Závěr

Záměrně nejasná otázka není jen špatný prompt. Je to užitečný rentgen modelového chování.

Reakce na ambiguitu ukáže, jak model zachází s nejistotou: zda brzdí, přizná předpoklad, nebo plynule vyplní mezery. A právě to je praktická informace pro výběr modelu do role, návrh pre-solving kroku i interpretaci chyb ve workflow.

V CrossChat dává podobný test smysl hlavně při výběru modelů do různých rolí. Stejnou diagnostiku ale můžete použít i ručně, pokud si vytvoříte malou sadu záměrně nejasných promptů a budete logovat první reakci modelu.

Zdroje

Heuer, R. J. (1999). Psychology of Intelligence Analysis. CIA Center for the Study of Intelligence. https://www.cia.gov/resources/csi/books-and-monographs/psychology-of-intelligence-analysis-2/
Tversky, A. & Kahneman, D. (1981). The Framing of Decisions and the Psychology of Choice. Science. DOI: 10.1126/science.7455683.
Liang, P. et al. (2022). Holistic Evaluation of Language Models. arXiv:2211.09110. DOI: 10.48550/arXiv.2211.09110.
NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. https://www.nist.gov/itl/ai-risk-management-framework

Historie úprav

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

Jazyková revize (2026-02-25, Codex + GPT-5): upravena stylistika, sjednoceny formulace a omezeny zbytečné anglicismy; věcný obsah zůstává zachován. Kvalitativní audit (2026-03-23, Claude Code + Claude Opus 4.6): přidán Rámec tvrzení, ověřeny zdroje, jazyková úprava.