Záměr na prvním místě: Jak bot pozná, na co se vlastně ptáte

Nejdražší chyba datového bota se dělá v první půlvteřině, dřív než se stáhne jediná tabulka: zacházet s každou zprávou stejně. Uživatel řekne „díky, přesně tohle" a bot to poslušně zkouší převést na SQL. Někdo chce porovnat dvě oddělení a bot spustí jediný lookup, který porovnání neumí vyjádřit. Otázka na „minulý měsíc" se předá databázi se slovy „minulý měsíc" pořád uvnitř. Nic z toho není selhání modelu. Je to absence prvního kroku.

Tím prvním krokem je pochopit otázku dřív, než na ni odpovíš — a rozpadá se na tři levné, rozhodné tahy: klasifikuj záměr, vytáhni entity, vyřeš čas. Udělejte je dopředu a všechno za nimi se zjednoduší, protože každá pozdější fáze je teď specializovaná na otázku, které už rozumí.

Záměr: vyber cestu, než vyjedeš

Většina pipeline má nanejvýš hrubou vidličku — „je tohle datová otázka, ano, nebo ne?". To je málo rozlišení. Skutečné otázky přicházejí v druzích a každý druh chce jinou strategii:

• Agregace („kolik…", „jaký je průměr…") → cesta počítání/seskupování.
• Výpis („ukaž mi…", „kteří zaměstnanci…") → cesta vyhledávání s rozumnými limity na řádky.
• Porovnání („porovnej A a B", „jaký je rozdíl…") → rozlož na paralelní podotázky a pak sluč výsledky.
• Vysvětlení („jak jsi k tomu došel?", „co tenhle dotaz dělá?") → popiš uvažování nebo původ dat; žádný nový dotaz není potřeba.
• Schéma / meta („jaké máš tabulky?", „co je v záznamu zaměstnance?") → odpověz o struktuře, ne o datech.
• Chitchat („ahoj", „díky") → jednoduchá odpověď, která se databáze nikdy nedotkne.

Zařazení do jedné z těchto kategorií je ten nejmocnější bod větvení v celém systému, a je levný — udělá ho rychlý, laciný model jedním voláním. Zisk se násobí: porovnání dostane rozklad, který potřebuje, požadavek na vysvětlení přestane zbytečně znovu dotazovat databázi a chitchat přestane spouštět cestu k datům. Každá trasa se snáz staví a spolehlivěji běží, protože musí zvládnout jen jeden tvar otázky.

Je to taky přirozený domov pro pojistku. Tentýž první průchod, který rozliší „chitchat vs. datový dotaz", je místo, kde zachytíte vstup mimo doménu nebo nepřátelský vstup — prompt injection, „ignoruj své instrukce", požadavek, který nemá u vašich dat co dělat. Odmítněte ho tady, u dveří, dřív než se rozjede jakékoli soukolí.

Entity: vytáhni a normalizuj, o čem otázka je

Jakmile znáte druh otázky, vytáhněte věci, o které jde. Tohle je rozpoznávání pojmenovaných entit (NER), naladěné na vaši doménu, a dělá víc než jen označování slov — normalizuje je a ukazuje na data.

Vezměte „mame zamestnance holkky?" — překlepem prošpikovaný, hovorový způsob, jak se zeptat, jestli jsou v evidenci ženy. Dobrý extrakční krok vyprodukuje něco strukturovaného:

• zamestnance → typ PERSON, normalizováno „zaměstnanec", navrhuje tabulky pro osoby.
• holkky → typ GENDER, normalizováno „žena", s konkrétní hodnotou filtru, navrhuje číselník pohlaví.

Právě se staly tři věci, které se později nesmírně vyplatí. Překlep a slang se vstřebaly — z „holkky" se stal čistý, kanonický pojem. Hodnota filtru se vyřešila — „žena" je teď navázána na skutečnou kódovanou hodnotu, ne ponechána SQL kroku k hádání. A každá entita nominovala vlastní kandidátní tabulky, takže ve chvíli, kdy běží vyhledávání, už má náskok. Předsunutí téhle práce promění mlhavou větu na typovaný, normalizovaný, tabulek si vědomý požadavek dřív, než se dotkne jediného řádku.

Čas: převeď „minulý měsíc" na skutečný rozsah

Relativní čas je tichá demoliční koule. „Minulý kvartál", „letos", „za poslední měsíc" — pro člověka triviální, pro model zrádné, protože odpověď závisí čistě na dnešním datu a jazykové modely jsou v počítání s daty nespolehlivé. Předejte „minulý měsíc" rovnou do SQL a sázíte na to, že si model vymyslí správné hranice.

Tak ho vyřešíte deterministicky, jednou, před generováním. „Minulý kvartál" se stane explicitním rozsahem mezi dvěma daty. „Letos" se stane konkrétním filtrem na rok. Bot pak generuje SQL proti skutečnému, jednoznačnému intervalu — a celá kategorie subtilních, těžko odhalitelných chyb v datech prostě přestane vznikat. Je to tentýž instinkt jako vyřešit kódovanou hodnotu v samostatném zaostřeném kroku místo nechat generátor hádat: cokoli lze přesně ukotvit, má se ukotvit mimo tvůrčí krok.

Proč tohle patří úplně dopředu

Je lákavé nacpat tohle všechno do promptu pro generování SQL a nechat to jeden velký model přebrat. Nedělejte to. Každý z těchto tahů odebírá nejednoznačnost, která by se jinak níže v řetězci násobila — a odebírá ji levně, většinou rychlými modely dělajícími úzké, dobře tvarované úkoly.

Berte to jako první pevnou fázi pipeline, tu, která si své místo zaslouží tím, že každou další fázi usnadní. Záměr vybere strategii, takže zbytek systému není univerzální cesta předstírající, že porovnání a pozdrav jsou tentýž problém. Entity nasypou semínka do vyhledávání a předvyřeší filtry, takže generátor začíná s kandidáty a čistými hodnotami místo se surovým textem. Temporal resolution smaže třídu chyb dřív, než mohou vzniknout. Bot utratí trochu inteligence dopředu, aby otázce porozuměl — a ušetří jí spoustu, i spoustu špatných odpovědí, na všem, co následuje.

Bot, který odpovídá dřív, než rozumí, je jen rychlý způsob, jak se sebevědomě mýlit. Porozumět nejdřív je to, co dělá všechno po tom hodným důvěry.

---

Žene váš bot každou otázku stejnou cestou? Vrstva záměru a entit je obvykle nejlevnější výhra v přesnosti, jaká je k mání — a základ, na kterém stojí všechno ostatní. Pojďme zmapovat, čemu má váš bot rozumět, než odpoví.