Strukturované výstupy AI chatbota: JSON Schema, validace a bezpečná záložní řešení

AI chatbot dokáže formulovat přesvědčivou odpověď, a přesto poškodit následný proces. Chybějící pole, vymyslená kategorie nebo neověřený odkaz stačí k tomu, aby CRM, ticketovací systém nebo frontend webu zpracovaly špatná data. Strukturované výstupy AI chatbota toto riziko snižují tím, že závazně popisují formu a datové typy. Spolehlivými se však stávají až tehdy, když se schéma, věcný význam, oprávnění a chybové stavy prověřují odděleně.

Tento průvodce je určen webovým, produktovým a provozním týmům, které strojově zpracovávají výstupy modelů. Ukazuje, co dokáže JSON Schema, kde leží jeho limity a jak vybudovat bezpečnou cestu od odpovědi modelu až po skutečnou akci.

Platný JSON ještě neznamená spolehlivou smlouvu

Starší režim JSON u mnoha modelových API zajišťuje především to, že odpověď lze parsovat jako JSON. Negarantuje však, že jsou přítomna očekávaná pole nebo že jsou dodrženy dohodnuté typy. Oficiální dokumentace OpenAI k Structured Outputs proto výslovně rozlišuje mezi platným JSONem a dodržením schématu. Také Microsoft Foundry popisuje Structured Outputs jako provázání odpovědi s přiloženým JSON Schema.

To je důležitý krok vpřed: namísto dodatečného hádání měnících se názvů polí získává aplikace předvídatelnou strukturu. Přesto poskytovatelé často podporují pouze část úplné specifikace. Dokumentace Gemini pro strukturované výstupy uvádí podporované typy a vlastnosti, ale zároveň poukazuje na omezení podmnožin a složitosti. Schéma proto musí být otestováno pro konkrétně nasazený model a konkrétní API cestu.

Schéma popisuje formu, nikoli pravdu

JSON Schema je deklarativní jazyk pro popis struktury a omezení dat JSON. Pole může být definováno například jako povinné, číslo, výčet nebo pole hodnot (array). Z toho však neplyne, že je hodnota věcně správná. Řetězec 2026-02-31 může formálně odpovídat textu, přestože takové datum neexistuje. Povolené ID produktu může být syntakticky správné, ale v aktuálním tenantovi neznámé.

Pro produkční chatboty je proto zapotřebí několik kontrolních vrstev:

Kontrolní vrstva	Typická otázka	Příklad
Transportní	Je odpověď úplná a parsovatelná?	Žádné přerušení uprostřed JSONu
Schéma	Odpovídají pole, typy a povolené hodnoty?	priority je pouze low, medium nebo high
Sémantika	Je obsah věcně logický a vnitřně konzistentní?	Datum ukončení není před datem zahájení
Pravidla a přístup	Smí tento uživatel tuto hodnotu vidět nebo použít?	Ticket patří k autentizovanému zákaznickému účtu
Kontext výstupu	Rendruje nebo předává se hodnota bezpečně?	Text je kódován pro HTML, neinterpretuje se jako skript

Toto oddělení zabraňuje zaměňování dodržení schématu s věcným schválením. Pro měření a regresní testy jej lze propojit s Golden Setem pro kvalitu odpovědí AI chatbota.

Navrhujte malá schémata specifická pro daný úkol

Jediný univerzální objekt odpovědi se rychle stane hluboce zanořeným, nepřehledným a drahým na údržbu. Lepší je malé schéma pro každý jasně vymezený úkol, například klasifikaci zpětné vazby, předřazení požadavku na podporu nebo označení chybějících údajů pro doplňující dotaz. Název a popis každého pole by měly vysvětlovat jeho věcný význam.

• Povinná pole volte uvážlivě: Vyžadujte pouze hodnoty, které proces skutečně potřebuje. Neznámé hodnoty explicitně vyjádřete jako null nebo vlastní stav, než abyste je nechali model vymýšlet.
• Používejte výčty místo volného textu: Krátký, verzovaný seznam zabrání variantám zápisu u stavu, kategorie nebo dalšího kroku.
• Odmítejte dodatečná pole: Tam, kde to poskytovatel podporuje, zabraňuje additionalProperties: false překvapivým klíčům.
• Opakujte omezení v kódu aplikace: Délky, rozsahy hodnot, hostitele URL a vzájemné vztahy nenechávejte pouze na modelu nebo na specifické podmnožině schématu daného poskytovatele.
• Verzujte schéma: Stabilní identifikátor a hash zviditelňují, která smlouva vygenerovala a zkontrolovala odpověď.

Neznámý stav je samostatný stav

Prázdné pole, chybějící pole a explicitně neznámá hodnota neznamenají totéž. Pokud informace ve zdroji chybí, mělo by pro ni schéma předvídat přípustný stav. Jinak smlouva nepřímým způsobem odměňuje model za to, že dosadí pravděpodobně vypadající řetězec. Pro kritické hodnoty je kombinace value, status a volitelného reason často spolehlivější než jediné volné textové pole.

Dokládejte verzi a hash společně

K odpovědi proto patří nejen verze modelu a promptu, ale také verze schématu a verze validátoru. Hash skutečně odeslaného schématu chráni před nenápadným posunem (driftem) způsobeným změnami v sestavení nebo konfiguraci. Při migraci lze stejný výstup modelu nejprve ověřit vůči oběma verzím smlouvy. Zápis probíhá nadále pouze přes aktivní cestu; rozdíly skončí jako srovnávací data v QA.

Prompty by neměly do schématu přenášet žádná tajemství ani interní rozhodnutí o oprávněních. Model může například klasifikovat požadovaný další krok. O tom, zda je tento krok povolen, rozhoduje následně server na základě aktuální identity a pravidel.

Přerušení a odmítnutí ošetřujte jako samostatné stavy

Přísně formátovaná odpověď se nemusí dostavit. Limity výstupu, timeaouty, filtry obsahu, chyby poskytovatele nebo vědomé odmítnutí modelem jsou běžné provozní stavy. OpenAI dokumentuje u Structured Outputs jak neúplné odpovědi, tak vlastní cestu odmítnutí (refusal), která nemusí nutně sledovat požadované schéma. Aplikace proto nesmí slepě přistupovat k prvnímu očekávanému poli.

Interní obálka nezávislá na poskytovateli rozlišuje minimálně success, refused, incomplete, provider_error a validation_failed. Teprve při stavu success se strukturovaný obsah předá do další kontrolní vrstvy. U ostatních stavů uvidí uživatelé krátkou, upřímnou zpětnou vazbu nebo bezpečné předání, ale žádná vymyslená náhradní data.

Sémantická pravidla kontrolujte na straně serveru

Po kontrole schématu začíná věcná validace. Měla by být deterministická a pokud možno nezávislá na modelu. Identifikátory produktů se ověřují vůči aktuálnímu datovému zdroji, URL vůči povoleným protokolům a hostitelům, kódové označení jazyků (locale) vůči skutečně podporovaným jazykům. Součty, časové úseky a přechody stavů vyžadují křížové kontroly. U odpovědí RAG musí uvedený zdroj skutečně existovat ve schváleném výsledku vyhledávání.

To platí i pro zdánlivě neškodná textová pole. Projekt OWASP GenAI Security Project varuje před nedostatečně zkontrolovanými výstupy modelů, pokud jsou předávány do prohlížeče, databáze, souborového systému nebo dalších nástrojů. Pro HTML se provádí kódování odpovídající kontextu, přístup k databázi zůstává parametrizovaný a systémové příkazy se nikdy neskládají z volně vygenerovaného textu. Strukturovaný výstup je vstupem z nedůvěryhodného zdroje, nikoli privilegovaným interním objektem.

Bezpečný fallback neopravuje za každou cenu

Při chybné odpovědi je okamžitý identický opakovaný pokus (retry) zřídkakdy nejlepší standardní reakcí. Může zvýšit náklady a zopakovat stejnou chybu. Omezená cesta záložního řešení (fallback) rozlišuje příčinu:

1. Technické přerušení: Při jednoznačně přechodné chybě poskytovatele opakujte pokus s přísným omezením a použijte stejné Idempotency ID.
2. Příliš složité schéma: Rozdělte úkol na menší, samostatně validovatelné kroky. To je plánovaná změna produktu, nikoli spontánní vynechání povinných polí.
3. Sémantická chyba: Spouštějte žádnou automatickou akci. Cíleně se doplňte na chybějící údaje nebo předejte případ k lidské kontrole.
4. Odmítnutí nebo limit pravidel (policy): Respektujte odmítnutí a nabídněte povolenou informační cestu nebo předání operátorovi.
5. Nejasný stav po zápisu: Nejprve načtěte cílový systém pomocí Idempotency ID, než zahájíte druhý pokus o zápis.

Pro větší změny se doporučuje testování v Shadow Mode před spuštěním webu. Nová strukturovaná cesta při něm již generuje výsledky, ale zatím neřídí žádné uživatelské akce.

Smluvní testy pokrývají více než jen vzorové dialogy

Dobrá testovací sada neobsahuje pouze ideální dotazy. Prázdné vstupy, velmi dlouhé texty, rozporuplné údaje, neznámé kategorie, více jazyků, pokusy o prompt injection, odmítnutí ze strany poskytovatele a úmyslně těsné limity tokenů sem patří rovněž. Pro každý případ se očekávaný provozní stav, výsledek schématu a věcné rozhodnutí zaznamenávají odděleně.

Při změnách schématu by měl tým validovat staré uložené příklady vůči nové verzi. Během migrace může aplikace dočasně provádět kontrolu vůči staré i nové verzi, aniž by spouštěla dvě akce. Teprve když jsou úspěšnost, sémantická odmítnutí a latence stabilní, stává se nová smlouva zapisovací cestou. Chyby lze díky ucelené observabilitě AI chatbota přiřadit k použité verzi modelu, promptu a schématu, aniž by bylo nutné logovat kompletní důvěrné odpovědi.

Metriky pro běžný provoz

Nejdůležitější metrikou není pouze podíl syntakticky platných odpovědí. Užitečné jsou: úspěšnost schématu na první pokus, míra sémantických odmítnutí, podíl neúplných odpovědí, odmítnutí, omezené pokusy o opravu, předání člověku a také latence a náklady na úspěšně validovaný výsledek. Hodnoty se posuzují odděleně podle verze modelu, promptu, schématu, případu užití a jazyka (locale).

Náhlý nárůst sémantických chyb při nezměněném podílu platných schémat je zvláště výpovědní: forma nadále odpovídá, ale obsah nebo datové vazby se odchylují. V takovém případě by měl proces přejít do bezpečného režimu. Stávající průvodce pro Degraded Mode a rollback u AI chatbotů ukazuje, jak takovou záložní cestu připravit.

Kontrolní seznam před první automatickou akcí

• Je konkrétní API a cesta modelu otestována s tímto přesným schématem?
• Jsou neúplné odpovědi, odmítnutí a chyby poskytovatele rozpoznány ještě před parsováním?
• Validuje server schéma a věcná pravidla nezávisle na modelu?
• Kontrolují se identita, tenant a oprávnění znovu bezprostředně před každou akcí?
• Jsou HTML, URL, hodnoty v databázi a parametry nástrojů kontextově zabezpečeny?
• Zabraňují idempotence a zpětné čtení (readback) dvojitým zápisům?
• Existují testy typu Golden Set, útoky, testy jazykových verzí a migrací?
• Jsou verze schématu, třída chyby a metriky kvality sledovatelné (observable)?
• Může tým bez ztráty dat přepnout do bezpečného informačního režimu nebo režimu předání operátorovi?

Strukturované výstupy usnadňují integraci AI chatbotů, ale nepřenášejí na model žádnou autoritu. Kdo přistupuje k formě, sémantice, přístupům a kontextu výstupu jako k odděleným branám (gates), získá sledovatelnou smlouvu namísto zdánlivě bezpečné fasády JSONu. Pro nový workflow na webu se vyplatí začít přesně s jedním vymezeným případem užití, malým verzovaným schématem a měřitelným testem v Shadow Mode.