16. června 2026

Judge: Proč dobrý bot nikdy nevěří své první odpovědi

Většina datových botů stojí na skryté domněnce, a ta domněnka je mylná. Pipeline zní: model napíše dotaz, systém ho spustí, výsledky se vrátí, model je shrne. Čisté, lineární — a tiše to předpokládá, že dotaz byl správný na první pokus.

Nebude. Ne ve skutečném světě, kde se uživatelé ptají na věci, které vaše demo nikdy nepokrylo. Model zvolí levý JOIN tam, kde potřeboval pravý. Filtruje na pohlaví = 3, když byl kód 2. Spojí dvě tabulky přes špatný klíč. I se solidní vrstvou asociací sedí chybovost prvního pokusu někde nepříjemně — řekněme deset procent. Pro systém, na který se mají lidé spoléhat, je deset procent sebevědomě-špatně naprosto nepřijatelných.

A tady je past, která to zhoršuje: dotaz může být dokonale validní a přitom úplně špatně. SELECT 0 proběhne bez chyby. Dotaz s rozbitým filtrem vrátí nula řádků, čistě, a nula řádků vypadá jako skutečná odpověď. Syntaktická validita vám říká, že databáze dotazu rozuměla. Neříká vám nic o tom, jestli dotaz odpověděl na otázku.

Takže přestanete věřit první odpovědi. Postavíte smyčku.

Berte to jako kurzor, ne jako jeden výstřel

Posun myšlení vede od generování k iteraci. Místo abyste po modelu chtěli odpověď, chcete po něm pokus — pak ten pokus zkontrolujete, a pokud je špatný, vrátíte mu selhání a poprosíte znovu a lépe. Přesně tak pracuje pečlivý analytik: něco napíše, spustí, pořádně se podívá na výsledek, opraví, opakuje.

Smyčka má čtyři role:

Plánovač navrhne dotaz spolu s tím, které tabulky si myslí, že používá, a proč.
Vykonavatel ho bezpečně spustí — read-only, s timeoutem a stropem na počet řádků — a zachytí buď výsledky, nebo chybu.
Rozhodčí (judge) rozhodne, jestli je výsledek dost dobrý, a pokud ne, řekne přesně proč.
Krok zpětné vazby předá původní otázku, neúspěšný dotaz a důvod rozhodčího zpět plánovači na další pokus.

Smyčce dáte rozpočet — maximální počet pokusů, maximální čas — a necháte ji iterovat uvnitř něj. Model už nehádá do prázdna. Opravuje se proti konkrétním důkazům.

Rozhodčí posuzuje správnost, ne jen spustitelnost

Rozhodčí je záměrně samostatná komponenta. Samooprava — agent látající vlastní práci ve smyčce — je užitečná, ale je to tatáž mysl, co známkuje svůj vlastní úkol. Rozhodčí je externí kritik s jediným úkolem: rozhodnout, jestli tenhle dotaz opravdu odpovídá na tuhle otázku. Jeho verdikty jsou strohé: přijmout, odmítnout (s důvodem, který jde zpět do smyčky), nebo selhat (rozpočet je vyčerpán; zastav a buď k tomu poctivý).

Co kontroluje? Čtyři věci, od nejlevnější:

Proběhlo to? Syntaktická a běhová validita — podlaha, ne cíl.
Používá skutečné sloupce? Halucinovaný název sloupce se chytí tady, dřív než kdy dorazí k uživateli.
Je to bezpečné? Žádné destruktivní operace, nasazený limit na řádky, nic, co by skenovalo obří tabulku do nekonečna.
Dává výsledek smysl? Tohle je to, na čem záleží. Otázka „kolik" má vrátit jediné číslo. Otázka „vypiš…", která vrátí nula řádků, je podezřelá, pokud k tomu není důvod. Tvar odpovědi má odpovídat tvaru otázky.

Čtvrtá kontrola je místo, kde sebevědomě-špatné odpovědi umírají — ale jen pokud má rozhodčí co srovnávat. A to je ten skutečný trik.

Sampling: dejte rozhodčímu pevnou půdu k uvažování

Rozhodčí nepozná, jestli je „nula řádků" správně, nebo katastrofa, zíráním na dotaz. Potřebuje osahat data. Takže před hlavním dotazem — nebo souběžně s ním — agent vystřelí malé, levné průzkumné dotazy proti zapojeným tabulkám.

Učebnicový příklad říká vše. Uživatel se ptá, kolik žen pracuje v určitém oddělení, a dotaz vrátí nulu. Je to správně? Agent samploval: počet žen celkem vrátí 500. počet řádků v tom oddělení vrátí zdravé číslo. Takže ženy existují, oddělení existuje, a přesto je průnik prázdný. To je podezřelé — skoro jistě rozbitý JOIN nebo špatný filtr, ne skutečná odpověď. Agent má teď důvod odmítnout a zkusit znovu, a konkrétní stopu, kde udělal chybu.

Tohle je ta hluboká myšlenka: berte složitý dotaz jako kompozit datových toků a validujte jeho části nezávisle levnými heuristikami. Zkontroluj JOIN izolovaně. Zkontroluj každý filtr proti surovému počtu. Ověř, že hodnota z číselníku odpovídá skutečnému řádku. Neptáte se jen „proběhne to celé" — vyslýcháte každý přítok dřív, než uvěříte řece. Takhle dramaticky snížíte chyby, protože většina selhání je lokální: jeden špatný JOIN, jeden špatný kód, v jinak zdravém dotazu.

Můžete si zvolit, jak dychtivě sondovat. Důkladná strategie pálí samplovací dotazy paralelně s generováním, takže důkazy čekají ve chvíli, kdy návrh dorazí — vyplatí se u složitých otázek. Spořivá strategie samplíruje, až když už něco vypadá špatně — levnější, v pořádku u jednoduchých. Tak či tak je cena triviální: COUNT(*) není nic vedle hodnoty zachycení špatné odpovědi dřív, než se odešle.

Ve zpětné vazbě se inteligence násobí

Smyčka funguje jen tehdy, když je zpětná vazba konkrétní. „Zkus to znovu" model nenaučí nic. Zpětná vazba, která s chybovostí skutečně hne, je specifická a ukotvená:

Původní otázka. Přesný dotaz, který jsi naposled zkusil. Doslovná chyba databáze — nebo „vrátil 0 řádků, ale oddělení má 240 zaměstnanců, takže je to nejspíš špatně". Cílená nápověda: „filtr na pohlaví neodpovídá žádnému řádku; zkontroluj hodnotu kódu."

Předejte modelu tohle a nehádá nový dotaz — uvažuje o konkrétním selhání a opraví skutečný problém. To je rozdíl mezi systémem, který mlátí kolem sebe, a tím, který konverguje. V praxi je právě tahle smyčka to, co stáhne reálnou chybovost z nepříjemných deseti procent do nízkých jednotek procent, protože model přestane sázet a začne ladit.

Co jste vlastně postavili

Setřete mechaniku a smyčka rozhodčího je jedna věc: ukotvení (grounding). Každou odpověď kotvíte v ověřitelných důkazech ze samotných dat a odmítáte nechat plynulý, věrohodný, neotestovaný dotaz dojít k člověku. Bot postavený takhle je kalibrovaný — sebevědomý, když ho důkazy podpoří, opatrný, když ne, a ochotný říct „tohle jsem nedokázal ověřit", když dojde rozpočet, místo aby si vymyslel číslo.

To poslední chování je celá pointa. Selhání, proti kterému navrhujete, nikdy nebylo „bot neumí odpovědět". Bylo to „bot odpoví špatně a zní u toho jistě". Smyčka rozhodčího je způsob, jak tohle vyřešit inženýrsky — ne nadějí na lepší první návrh, ale odmítnutím věřit jakémukoli návrhu, dokud s ním data nesouhlasí.

Bojíte se, že váš bot zní sebevědomě, i když nemá pravdu? Přesně tohle selhání je smyčka rozhodčího postavena chytit. Pojďme zmapovat, jak by „ověřeno, než se odešle" vypadalo pro vaše data.