Proč AI odpovídá lépe, když nejdřív analyzuje otázku

Rychlá odpověď působí chytře. U složitějších dotazů ale často znamená, že systém přeskočil nejdražší část práce: pochopení toho, co se vlastně řeší.

Mnoho AI chyb nevzniká až ve formulaci věty. Vzniká dřív. Model si potichu zvolí interpretaci otázky, doplní chybějící předpoklady a rozběhne řešení, které vypadá plynule, ale míří vedle.

Pre-solving analýza je pokus tento moment zpomalit a udělat ho viditelným. Ne proto, aby AI „víc přemýšlela”, ale aby nejdřív upřesnila problém, rizika a vhodný postup.

Rámec tvrzení

Co článek tvrdí: Většina chyb AI nevzniká ve formulaci odpovědi, ale v tiché, neověřené interpretaci otázky. Strukturovaný pre-solving krok (přepis cíle, předpoklady, chybějící data, volba metody) snižuje riziko sebejistých chybných odpovědí. Pre-solving není univerzální povinný krok, ale disciplína vhodná pro úlohy s vysokou cenou chyby.

Na čem to stojí: ReAct (Yao et al., 2022), Least-to-Most Prompting (Zhou et al., 2022), Plan-and-Solve (Wang et al., 2023), Tree of Thoughts (Yao et al., 2023), Chain-of-Verification (Dhuliawala et al., 2023); obecné principy dekompozice problémů a rozhodovacích procesů.

Kde je to zjednodušení: Článek nepředkládá kvantitativní data o tom, o kolik pre-solving snižuje chybovost. Doporučení vycházejí z analogie s lidskými rozhodovacími procesy a z konceptuální blízkosti k citovaným technikám, nikoli z přímého experimentu s pre-solving krokem jako celkem.

1) Kde se chyba rodí: špatně rozbalená otázka

Když uživatel napíše: “Jaký model máme použít pro interní audit?”, může tím myslet několik různých věcí:

model pro první průzkum,
model pro finální report,
model pro právně citlivou část,
nebo model pro levný prototyp.

LLM ale často neřekne: “Tady jsou čtyři možné interpretace.” Místo toho jednu vybere a začne odpovídat. Výsledek může být jazykově kvalitní a přesto prakticky nepoužitelný, protože řeší jinou otázku, než jakou jste potřebovali.

Tohle není jen problém AI. Stejný typ selhání (failure mode) zná každý, kdo někdy dostal vágní zadání od klienta nebo produktový ticket s větou „udělejte to robustně“. Rozdíl je v tom, že člověk se častěji doptá. Model častěji improvizuje.

Pre-solving krok je v podstatě institucionalizované doptání. Nutí systém přerušit automatickou syntézu a nejdřív udělat mapu problému.

2) Co je pre-solving analýza (a co není)

Pre-solving analýza není totéž co „delší odpověď“. Není to ani nutně skryté uvažování modelu. Prakticky jde o strukturovaný mezikrok, který vytváří několik explicitních artefaktů před samotným řešením.

Typicky obsahuje:

přepis cíle vlastními slovy (co je rozhodnutí / výstup),
rozklad otázky na dílčí části,
identifikaci předpokladů,
seznam chybějících dat nebo nejasností,
návrh metody (jeden model, debata, ověření, nástroj, iterace).

Klíčová myšlenka je jednoduchá: první kvalitativní skok často nepřijde z „lepší odpovědi“, ale z lepší volby postupu.

Proto je pre-solving blízký technikám jako Plan-and-Solve nebo Tree of Thoughts jen částečně. Sdílí s nimi důraz na strukturu a plán. Ale v produktovém workflow má navíc operativní roli: rozhoduje, zda je potřeba doptání, jiný workflow, nebo externí ověření.

3) Mechanismus: proč to snižuje sebejisté chyby

Sebejistě chybná odpověď (confident wrong answer) obvykle potřebuje dvě věci:

nejasně zadaný problém,
plynulou syntézu bez checkpointu.

Pre-solving zasahuje oba body.

Nejdřív oddělí “co víme” od “co si jen domýšlíme”. Jakmile je systém nucen napsat předpoklady, náhle je vidět, kde stojí na nejistém základu. To samo o sobě často stačí, aby místo kategorického tvrzení vznikla podmíněná odpověď nebo žádost o doplnění.

Pak přidá rozhodnutí o metodě. Některé otázky jsou vhodné pro rychlou syntézu jedním modelem. Jiné potřebují více perspektiv. Jiné potřebují nástroj nebo ověření. Bez pre-solving kroku se tahle volba děje implicitně. S pre-solving krokem se děje explicitně.

Jinými slovy: pre-solving neslibuje pravdu. Slibuje menší pravděpodobnost, že systém začne sebejistě odpovídat na špatně pochopenou otázku špatnou metodou.

Jak poznat, že pre-solving krok nefunguje (diagnostika)

Paradoxně i workflow, které “má pre-solving”, může selhávat úplně stejně jako workflow bez něj. Důvod je jednoduchý: mezikrok existuje formálně, ale nepřináší nový signál.

Typické varovné signály:

restatement jen parafrázuje původní otázku bez zpřesnění cíle,
seznam předpokladů je prázdný nebo triviální (“uživatel chce dobrou odpověď”),
chybějící data nejsou pojmenovaná, i když zadání je zjevně neúplné,
volba metody je vždy stejná bez ohledu na typ úlohy,
další krok je jen “odpověz”.

Tohle je důležité, protože pre-solving se může snadno proměnit v rituál. Vypadá to procesně správně, ale ve skutečnosti jen přidává mezititulky. Kvalitní pre-solving musí měnit rozhodnutí o tom, co se bude dít dál.

Praktický test je jednoduchý: zkuste porovnat dvě verze workflow na stejném zadání. Pokud verze s pre-solving krokem nevede k jiné formulaci cíle, jinému seznamu rizik nebo jiné volbě metody, je pravděpodobné, že krok nepřidává hodnotu a potřebuje redesign.

4) Čtyři artefakty dobrého pre-solving kroku

Pre-solving je užitečný tehdy, když po něm zůstane něco auditovatelného. Nejpraktičtější jsou čtyři výstupy (artefakty).

1) Restatement cíle

Krátké přepsání otázky: jaké rozhodnutí má výstup podpořit, v jakém kontextu a pro koho. Tohle je nejlepší obrana proti tomu, aby se z dotazu “poradíš mi?” stal esej místo doporučení.

2) Seznam předpokladů

Co systém předpokládá o datech, rozpočtu, časovém limitu, definici úspěchu nebo toleranci rizika. Předpoklady nejsou chyba. Chyba je nechat je skryté.

3) Chybějící data / nejasnosti

Jaké informace chybí k dobré odpovědi. Sem patří i rozhodnutí, jestli pokračovat i bez nich. Užitečný systém umí říct: „Můžu dát rámec, ale ne finální verdikt.“

4) Návrh postupu

Jaká technika dává smysl:

rychlá odpověď jedním modelem,
multi-model panel,
ReAct styl s nástrojem,
CoVe styl ověřovacích otázek,
nebo iterativní workflow.

Tenhle výstup je klíčový pro týmovou práci. Místo sporu o to, „jestli je odpověď dobrá“, se dá diskutovat už volba procesu.

Mini scénář: stejná otázka, jiný výsledek díky viditelným artefaktům

Vezměte otázku: „Máme nasadit nový model do zákaznické podpory?“

Bez pre-solving kroku často dostanete rozumně znějící odpověď typu „ano, ale nejdřív udělejte pilot“. To není nutně špatně. Jen to často obchází skutečné rozhodnutí. Jaký kanál podpory? Jaká cena chyby? Jde o interní asistenci agentům, nebo o automatickou komunikaci se zákazníky? Optimalizujete rychlost, kvalitu, nebo compliance?

Jakmile stejnou otázku projdete přes čtyři artefakty, změní se kvalita dalšího kroku:

Restatement cíle: nerozhodujeme „nasadit model“, ale „kde a za jakých podmínek model doplní člověka“.
Předpoklady: existuje eskalace na člověka, máme historické tickety, máme definované kritické případy.
Chybějící data: nevíme podíl high-risk ticketů a limity pro automatizaci.
Návrh postupu: segmentace ticketů -> pilot na low-risk kategorii -> kontrola chyb a eskalací.

Rozdíl není jen stylistický. Pre-solving z neurčité otázky vytvoří rozhodovací rámec. A i když finální doporučení zůstane podobné, tým ví, proč k němu došel a co ještě chybí ověřit.

5) Kdy pre-solving pomáhá nejvíc (a kdy ne)

Pre-solving není univerzální povinný krok. Největší přínos má tam, kde je levná odpověď draze chybná.

Kde pomáhá hodně

Nejasné zadání: otázka má více legitimních interpretací.
Vícekriteriální rozhodnutí: rychlost, cena, kvalita, riziko se navzájem perou.
Domény s vysokými důsledky: právní, bezpečnostní, compliance, finance, audit.
Týmové workflow: více lidí potřebuje rozumět, proč byl zvolen právě tento postup.

V těchto případech není pre-solving “luxus”. Je to způsob, jak zmenšit počet kol oprav, protože se chyby zachytí dřív.

V praxi má navíc největší návratnost u opakovaných typů úloh. U jednorázového dotazu může působit jako režie. U opakovaných workflow se ale mění v šablonu, která snižuje chaos napříč session a mezi členy týmu.

Kde je často zbytečný

jednoduchý low-stakes dotaz,
jednorázový brainstorming bez ceny chyby,
úloha, kde člověk stejně rychle ověří výstup ručně.

Tady bývá lepší použít jednoduchý postup a až při problému přidat strukturu. To dobře navazuje na rozhodovací logiku “jeden model vs workflow” z B08.

Užitečný kompromis v praxi: začít lehkým pre-solvingem jako default a teprve při signálu rizika (nejasnost, neshoda modelů, vysoká cena chyby) přepnout do plného režimu. Tím zůstane workflow rychlé, ale nebude slepé k momentům, kdy jednoduchý postup přestává stačit.

Dobré pravidlo pro tým: pokud se po první odpovědi objeví zásadní otázka typu „co přesně tím myslíme?“ nebo „na jakém předpokladu to stojí?“, nebyl pre-solving dostatečný. Místo další iterace finálního textu je často levnější vrátit se o krok zpět a zpřesnit framing.

6) Kontraargument: kdy se z pre-solving stane overthinking

Silná myšlenka se dá snadno přehnat. Pre-solving má své typické způsoby selhání (failure modes).

První je odkládání rozhodnutí. Systém produkuje stále jemnější analýzu otázky, ale neposouvá se k odpovědi. Vypadá to rigorózně, ale prakticky jde o prokrastinaci v elegantním balení.

Druhý je falešná jistota. To, že máte sepsané předpoklady a kroky, ještě neznamená, že jsou správné. Špatně zvolený rámec může působit profesionálněji než improvizace, a právě proto je zrádný.

Třetí je neadekvátní cena procesu. Když pre-solving krok sežere většinu času u triviální otázky, ztrácí smysl.

Proto potřebuje disciplínu:

časový limit (time-box) (např. krátká analýza před odpovědí),
práh podle ceny chyby (víc struktury jen tam, kde se vyplatí),
stop podmínku („dost na to, abychom bezpečně začali“).

Pre-solving není cíl. Je to filtr, který má zlepšit další krok.

Pomáhá také rozlišit dvě hloubky pre-solvingu:

Lehký režim: rychlé upřesnění cíle, předpokladů a dalšího kroku.
Plný režim: dekompozice, role, ověřovací větev a stop podmínky.

Tím se vyhnete falešnému dilematu „buď nic, nebo složitá analýza“. Většina úloh potřebuje lehký režim. Hlubší režim má smysl zapnout až tam, kde je vyšší cena chyby nebo víc nejasností.

7) Jak to navrhnout v praxi: pravidla a prompt kontrakty

Aby pre-solving fungoval opakovatelně, nestačí napsat „nejdřív analyzuj otázku“. Systém potřebuje konkrétní kontrakt, co má mezikrok dodat.

Praktický základ může vypadat takto:

Restate goal: Co je rozhodnutí, komu slouží výstup, jaká je cena chyby.
List assumptions: Jaké předpoklady používáš.
List missing info: Co chybí a jak to ovlivňuje jistotu.
Choose method: Jednomodel / panel / nástroj / ověření / iterace.
Set next step: Co uděláš hned teď a co odložíš.

Důležité je i pravidlo pro eskalaci. Když pre-solving odhalí faktickou nejistotu, workflow by mělo přepnout do režimu ověření (např. tool-first nebo CoVe otázky), ne pokračovat stejnou rétorikou.

V CrossChatu je to důležité hlavně proto, že pre-solving může fungovat jako uzel, který rozhodne o celé trase workflow. Ale stejný princip jde použít i mimo produkt: v prompt template, v interním guideline nebo v checklistu pro tým.

Praktická šablona pre-solving kroku (přenositelná i mimo CrossChat)

Pokud chcete princip zavést hned, nepotřebujete složitý framework. Potřebujete konzistentní minimum. Použitelná šablona může být:

Co přesně máme rozhodnout nebo vytvořit?
Pro koho a v jakém kontextu?
Jaká je cena chyby a co je nepřijatelné selhání?
Jaké předpoklady právě děláme?
Co nevíme a co musíme ověřit?
Jaký workflow zvolíme a proč?
Jaký je nejbližší další krok?

Tohle je zároveň rychlý test kvality zadání. Když nejde rozumně vyplnit ani první tři body, problém obvykle není v modelu. Problém je v tom, že vstup není dostatečně specifický pro dobré rozhodnutí.

A v tom je hlavní přínos pre-solvingu: zvyšuje kvalitu práce dřív, než vznikne finální odpověď.

Proto je užitečné hodnotit pre-solving ne podle délky, ale podle dopadu: změnil volbu workflow, odhalil chybějící data, nebo zpřesnil definici úspěchu? Pokud ano, splnil účel.

V tomhle smyslu je pre-solving blíž dobrému briefingu než “AI triku”. Kvalita odpovědi nezačíná u formulace závěru. Začíná u toho, jestli systém správně pochopil problém, který má řešit, a jestli si zvolil adekvátní cestu k řešení. A právě proto pre-solving dobře funguje i ve chvíli, kdy nakonec použijete jen jeden model: největší zlepšení někdy nepřijde z větší “inteligence”, ale z lepší definice úkolu. To je důvod, proč se vyplatí brát ho jako standard pracovního postupu, ne jen jako volitelnou kosmetiku.

8) Závěr: pre-solving jako disciplína, ne kosmetika

Když AI odpoví špatně, často hledáme problém až v samotné odpovědi. Jenže část chyb vzniká mnohem dřív: v tichém, neověřeném výkladu otázky.

Pre-solving analýza nepřidává kouzelnou inteligenci. Přidává viditelnost, checkpointy a lepší volbu metody. Tím snižuje prostor pro sebejisté odpovědi, které řeší jiný problém, než jste skutečně měli.

Praktický závěr: Pokud chcete tenhle princip používat systematicky, CrossChat dává smysl právě tehdy, když z pre-solving kroku uděláte explicitní součást workflow a navážete na něj ověření nebo panel založený na rolích (role-based panel).

Zdroje

Yao, S. et al. (2022/2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. arXiv:2210.03629. DOI: 10.48550/arXiv.2210.03629
Zhou, D. et al. (2022). Least-to-Most Prompting Enables Complex Reasoning in Large Language Models. arXiv:2205.10625. DOI: 10.48550/arXiv.2205.10625
Wang, L. et al. (2023). Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models. arXiv:2305.04091. DOI: 10.48550/arXiv.2305.04091
Yao, S. et al. (2023). Tree of Thoughts: Deliberate Problem Solving with Large Language Models. arXiv:2305.10601. DOI: 10.48550/arXiv.2305.10601
Dhuliawala, S. et al. (2023). Chain-of-Verification Reduces Hallucination in Large Language Models. arXiv:2309.11495. DOI: 10.48550/arXiv.2309.11495

Historie úprav

Koncept: Codex CLI + GPT-5.2 Verze 1: Codex CLI + GPT-5.2 Kvalitativní audit (2026-03-23, Claude Code + Claude Opus 4.6): přidán Rámec tvrzení, ověřeny zdroje, jazyková úprava.