Štruktúrované výstupy s JSON Schema: Ako vynútiť spoľahlivé odpovede agentov

Štruktúrované výstupy s JSON Schema sú technika, ktorá LLM núti vrátiť odpoveď presne podľa vopred zadanej JSON schémy. Namiesto voľného textu model dodá strojovo čitateľný objekt, ktorý sa dá validovať. Agentové pipeline sú vďaka tomu spoľahlivé, pretože nadväzujúce kroky programu sa môžu spoľahnúť na garantovanú dátovú štruktúru a nemusia parsovať voľný text náchylný na chyby.

• Čo? Model vracia JSON podľa pevnej schémy, nie voľný text. Polia, typy a povolené hodnoty sú definované.
• Prečo? Programy môžu výsledok priamo ďalej spracovať bez krehkej logiky s regulárnymi výrazmi alebo reťazcami. To je základ spoľahlivých agentov.
• Ako? Cez funkcie poskytovateľov, napríklad Structured Outputs od OpenAI a Anthropic, alebo cez constrained decoding pri open-weight modeloch, doplnené o validáciu a retry.

Prečo parsovanie voľného textu v agentových pipeline zlyháva

Jazykový model štandardne generuje text pre ľudských čitateľov. Pre chatbota je to ideálne, pre automatizovanú pipeline je to však problém. Len čo musí program z odpovede vytiahnuť hodnotu, napríklad kategóriu, dátum, sumu alebo zoznam, začína krehké parsovanie. Model raz napíše "Kategória je faktúra.", inokedy "Kategória: faktúra" a niekedy pred to pridá vysvetlenie. Každý z týchto variantov rozbije naivnú logiku extrakcie.

Pri viackrokových agentoch sa problém dramaticky zhoršuje, pretože nespoľahlivosť sa v reťazci násobí. Príklad výpočtu: ak má každý jednotlivý krok úspešnosť parsovania 95 percent, end-to-end úspešnosť reťazca z desiatich krokov je už len 0,95 umocnené na 10, teda približne 60 percent. Ak štruktúrované výstupy zvýšia úspešnosť každého kroku na 99,5 percenta, ten istý reťazec skončí približne na 95 percentách. Z tohto multiplikačného efektu vyplýva hlavná téza článku: štruktúrované výstupy nie sú funkcia pre pohodlie, ale predpoklad toho, aby agentové pipeline vôbec dosiahli produkčnú kvalitu.

Tri úrovne záruky v prehľade

Nie každá metóda, ktorá sľubuje JSON, dáva rovnakú záruku. Treba rozlišovať tri úrovne a rozdiel medzi nimi rozhoduje o spoľahlivosti.

Prompt-only. Model zdvorilo požiadaš, aby vrátil JSON. Často to funguje, ale nie vždy. Model môže pridať markdownové ohraničenie kódu (code fences), vynechať polia alebo sa pri neistote predsa len vrátiť k súvislému textu. Žiadna záruka.

JSON mode. Poskytovateľ garantuje, že výstup je syntakticky platný JSON. Tým odpadnú syntaktické chyby, o štruktúre to však nehovorí nič: polia môžu chýbať, mať nesprávne typy alebo sa objaviť navyše. Čiastočná záruka.

Constrained decoding / Structured Outputs. Tu sa generovanie na úrovni tokenov obmedzí tak, že model môže vytvoriť len tokeny, ktoré zodpovedajú schéme. Z rámca schémy už model nemôže vybočiť. Povinné polia, typy a povolené hodnoty enumov sú garantované. Na tejto technike stoja OpenAI Structured Outputs (režim strict) a Structured Outputs od Anthropic, teda JSON outputs cez output_config.format a Strict Tool Use so strict: true. Bežný tool use bez strict schému negarantuje. Pri open-weight modeloch rovnakú úlohu preberajú knižnice a inference stacky pomocou gramatických obmedzení (grammar constraints).

Metóda, záruka a kompromis v porovnaní

Rozhodujúci poznatok z tejto tabuľky: constrained decoding garantuje formu, nie obsah. Model určite dodá platný objekt s poľom datum_faktury, ale či hodnota v ňom naozaj zodpovedá dátumu na dokumente, nezabezpečí žiadna metóda dekódovania. Preto sú odborná validácia a stratégia retry naďalej nevyhnutné.

Realita poskytovateľov v roku 2026

Veľkí poskytovatelia dnes viažu odpoveď na JSON schému, líšia sa však v parametroch a obmedzeniach.

• OpenAI: Structured Outputs so strict: true, buď ako formát odpovede typu json_schema, alebo pri function callingu. JSON mode (json_object) naproti tomu dodá len platný JSON bez dodržania schémy.
• Anthropic Claude: JSON outputs cez output_config.format alebo Strict Tool Use so strict: true, oba spôsoby fungujú cez sampling obmedzený gramatikou. Bez strict môže Claude pri tool use vrátiť nesprávne typy ("2" namiesto 2) alebo vynechať povinné polia. Rekurzívne schémy a obmedzenia ako minimum alebo maxLength API nepodporuje. Limity dĺžky, aké používa príklad nižšie, preto patria do description a do validácie.
• Google Gemini: API prijme JSON schému spolu s MIME typom application/json ako formát odpovede. Google sám odporúča hodnoty aj tak skontrolovať v aplikácii.
• Open-weight modely: Tu schému vynucuje inference stack pomocou gramatiky. vLLM prijme JSON schému priamo vo svojom serveri kompatibilnom s OpenAI, llama.cpp prekladá časť JSON Schema do gramatík GBNF. Ak prevádzkuješ stack sám, nastavíš constrained decoding nezávisle od API poskytovateľa.

Dôležité pre prax: mnohí inference provideri ponúkajú endpointy kompatibilné s OpenAI, štruktúrované výstupy však implementujú rôzne. Skôr než sa rozhodneš, over, či konkrétny provider režim strict alebo obmedzenia schémy naozaj presadzuje, alebo ponúka len JSON mode.

Príklad schémy a stratégia retry

Princíp najlepšie ukáže konkrétny príklad. Agent má klasifikovať prichádzajúce požiadavky na podporu a vytiahnuť z nich najdôležitejšie polia. JSON schéma (zjednodušená) vyzerá takto:

```json
{
"type": "object",
"properties": {
"kategoria": {
"type": "string",
"enum": ["faktura", "technika", "zmluva", "ostatne"],
"description": "Hlavná kategória požiadavky"
},
"naliehavost": {
"type": "string",
"enum": ["nizka", "stredna", "vysoka"]
},
"cislo_zakaznika": {
"type": ["string", "null"],
"description": "Číslo zákazníka, ak je uvedené v texte, inak null"
},
"zhrnutie": {
"type": "string",
"description": "Jedna veta, maximálne 200 znakov"
}
},
"required": ["kategoria", "naliehavost", "cislo_zakaznika", "zhrnutie"],
"additionalProperties": false
}
```

Kľúčové sú tu dve rozhodnutia v návrhu. Po prvé enumy namiesto voľného textu pre kategoria a naliehavost: model tak nemôže vymyslieť "Fakturačné oddelenie" alebo "veľmi vysoká", čo by rozbilo nadväzujúcu logiku smerovania. Po druhé additionalProperties: false, aby sa neobjavili nechcené polia navyše. Polia description pritom pôsobia ako implicitný pokyn pre model.

Na túto schému nadväzuje stratégia s obmedzeným počtom opakovaní (bounded retry). Pseudokód volá LLM najviac trikrát:

```
pokus = 0
while pokus < 3:
odpoved = llm.call(prompt, schema=support_schema) # štruktúrovaný výstup
objekt = parse_json(odpoved) # forma je garantovaná
chyby = validuj(objekt) # sémantická kontrola
if not chyby:
return objekt
prompt += f"\nOprav: {chyby}" # spätná väzba o chybe
pokus += 1
eskaluj_na_cloveka(odpoved) # fallback po 3 pokusoch
```

Podstatné je toto: aj keď je forma garantovane v súlade so schémou, validuj() kontroluje sémantiku, napríklad či cislo_zakaznika zodpovedá očakávanému formátu alebo či zhrnutie dodržiava limit dĺžky. Ak kontrola zlyhá, konkrétna chyba ide ako spätná väzba späť do modelu. Tri pokusy sú rozumný horný limit; potom sa požiadavka eskaluje na človeka, namiesto nekonečnej slučky, ktorá len páli náklady.

Validácia cez Pydantic a Zod ako štandard v praxi

V praxi nikto nepíše JSON schémy ručne. V Pythone si definuješ model v Pydantic, v TypeScripte schému v Zod; oba vygenerujú JSON schému pre požiadavku na LLM a rovno validujú odpoveď. Prínos je dvojitý: tá istá definícia riadi generovanie aj kontroluje výsledok, takže nevznikajú nekonzistencie. Chyby typov, chýbajúce povinné polia alebo porušené rozsahy hodnôt sa pri parsovaní hneď ukážu ako jasná chybová správa, ktorú môžeš znovu použiť ako spätnú väzbu pre retry.

Frameworky ako Pydantic AI majú túto slučku už zabudovanú: odpoveď skontrolujú voči modelu Pydantic a pri chybe validácie vyzvú model na nový pokus, s nastaviteľným horným limitom. Na smerovanie medzi viacerými poskytovateľmi slúžia nástroje ako LiteLLM a OpenRouter. Tá istá štruktúrovaná požiadavka tak môže ísť na rôzne modely. To znižuje závislosť od jedného poskytovateľa a umožňuje fallback na druhý model, ak provider štruktúrovaný výstup nedodáva spoľahlivo.

Časté úskalia

• Príliš zložité schémy. Hlboko vnorené štruktúry s mnohými voliteľnými poľami zvyšujú chybovosť aj latenciu. Tak prísne, ako je nutné, tak jednoducho, ako sa dá.
• Zámena formy s obsahom. Objekt v súlade so schémou nie je automaticky vecne správny. Halucinované, ale platne typované hodnoty sú najnebezpečnejšia trieda chýb, pretože nenápadne prekĺznu.
• Neobmedzené retry. Bez horného limitu hrozia nekonečné slučky a explózia nákladov. Vždy obmedz počet pokusov a maj pripravený fallback s eskaláciou.
• Ignorovanie rozdielov medzi providermi. Nie každý endpoint kompatibilný s OpenAI vynucuje schému naozaj striktne. Pred spustením do produkcie to otestuj.

Pre agentúry a B2B rozhodovateľov

Ak vo Viedni alebo v regióne DACH plánuješ produkčného agenta alebo RAG aplikáciu, ukotvi štruktúrované výstupy od začiatku ako princíp architektúry, nie ako dodatočnú opravu. Práve tu sa rozhoduje, či sa z AI projektu stane spoľahlivý nástroj, alebo zostane nevyspytateľným demom. Ako agentúra vo Viedni sprevádza Blck Alpaca firmy z regiónu DACH pri budovaní odolných RAG a agentových pipeline, od definície schémy cez validáciu a logiku retry až po rozhodnutie o poskytovateľovi a suverenite. Ozvi sa nám, ak tvoj RAG alebo agentový projekt potrebuje spoľahlivé, strojovo čitateľné výstupy namiesto hádaného voľného textu.