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

Štruktúrované výstupy s JSON Schema sú technika, pri ktorej je LLM nútený vydať svoju odpoveď presne podľa vopred definovanej JSON schémy. Namiesto voľného textu model dodá strojovo čitateľný, validovateľný objekt. To robí agentové pipeline spoľahlivými, pretože následné programové kroky sa môžu spoľahnúť na garantovanú dátovú štruktúru namiesto parsovania náchylného na chyby voľného textu.

• Čo? Model vydáva 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 spracovávať bez krehkej regex alebo string logiky. To je základ spoľahlivých agentov.
• Ako? Prostredníctvom funkcií poskytovateľov ako OpenAI Structured Outputs, Anthropic Tool-Use-Schema alebo 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. To je ideálne pre chatbot, ale pre automatizovanú pipeline je to problém. Akonáhle musí program z odpovede extrahovať hodnotu, napríklad kategóriu, dátum, sumu alebo zoznam, začína krehký proces parsovania. Model raz napíše"Kategória je faktúra.", inokedy"Kategória: faktúra", niekedy pred to pridá vysvetlenie. Každá z týchto variácií zlomí naivnú extrakčnú logiku.

V multi-step agentoch sa to dramaticky zhoršuje, pretože nespoľahlivosť sa cez reťazecná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 len 0,95 na 10, teda približne 60 percent. Ak sa každý krok zlepší štruktúrovanými výstupmi na 99,5 percenta, ten istý reťazec dosiahne približne 95 percent. Z tohto multiplikačného efektu vyplýva centrálna téza tohto článku: Štruktúrované výstupy nie sú komfortná funkcia, ale predpoklad toho, aby sa agentové pipeline vôbec stali produkčne pripravenými.

Tri úrovne záruky v prehľade

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

Prompt-only. Model sa zdvorilo požiada, aby vydal JSON. To často funguje, ale nie vždy. Model môže pridať Markdown codefences, vynechať polia alebo pri neistote predsa len spadnúť späť do plynulého textu. Žiadna záruka.

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

Constrained decoding / Structured Outputs. Tu je proces generovania na úrovni tokenov obmedzený tak, že môžu byť generované len tokeny, ktoré zodpovedajú schéme. Model už nemôže opustiť výsledok konformný so schémou. Povinné polia, typy a povolené enum hodnoty sú garantované. Táto technika je základom OpenAI Structured Outputs (strict režim) a Tool-Use s input_schema pri Anthropic Claude; pri open-weight modeloch preberajú tú istú úlohu knižnice a inference stacky pomocou grammar-constraints.

Metóda, záruka, tradeoff v porovnaní

Rozhodujúce poznanie z tejto tabuľky: Constrained decoding garantujeformu, nieobsah. Model garantovane dodá platný objekt s poľomrechnungsdatum, ale či tam zapísaná hodnota skutočne zodpovedá dátumu na dokumente, nemôže žiadny decoding postup zabezpečiť. Preto zostáva odborná validácia a retry stratégia nevyhnutná.

Realita poskytovateľov stav 2026

Poprední poskytovatelia podporujú štruktúrované výstupy s rôznymi, ale konvergujúcimi prístupmi. Podľa research zdroja (stav 2026) je Claude Opus 4.7 (Pricing 5 US dolárov Input / 25 US dolárov Output na milión tokenov) explicitne pozicionovaný pre agentické workloady a orchestráciu nástrojov; pri Claude beží štruktúrovaný výstup primárne cez Tool-Use s JSON-Schema. OpenAI GPT-5.5 je v tom istom zdroji opísaný ako silno orientovaný na terminálové a agentové workloady. Google Gemini 3.1 Pro (2 US doláre / 12 US dolárov na milión tokenov, stav 2026) dopĺňa pole s veľmi veľkým kontextovým oknom.

Na open-weight strane sú podľa toho istého zdroja (stav 2026) dostupné Mistral Large 3 (Apache 2.0, 0,50 / 1,50 US dolára), DeepSeek V4 ako aj Kimi K2.6, ktoré na agentických a coding benchmarkoch dosahujú blízko k frontier modelom. Praktická výhoda pri open-weight: Kto kontroluje inference stack sám, môže constrained decoding cez grammar-constraints voľne konfigurovať, nezávisle od API poskytovateľa. Tieto modely sú podľa zdroja dodávané cez inference providerov ako Together AI, Fireworks AI, DeepInfra (s Frankfurt regiónmi pre GDPR relevantné workloady) alebo Groq.

Dôležité pre prax: Aj keď väčšina providerov ponúka OpenAI-kompatibilné endpointy, podpora pre štruktúrované výstupy nie je identická naprieč všetkými providermi. Pred rozhodnutím treba overiť, či konkrétny provider skutočne presadzuje strict režim alebo schema-constraints, alebo ponúka len JSON-Mode.

Príklad schémy a retry stratégie

Konkrétny príklad robí princíp hmatateľným. Agent má klasifikovať prichádzajúce support požiadavky a extrahovať najdôležitejšie polia. JSON-Schema (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
}
```

Dve dizajnové rozhodnutia sú tu centrálne. Po prvéEnumy namiesto voľného textu prekategoria analiehavost: Tým je vylúčené, že model vymyslí"Fakturačné oddelenie" alebo"veľmi vysoká", čo by zlomilo následnú logiku smerovania. Po druhéadditionalProperties: false, aby sa neobjavili nechcené dodatočné polia.description-polia pôsobia pritom ako implicitná inštrukcia pre model.

Na túto schému nadväzuje bounded retry stratégia. Pseudokód:

```
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}" # chybová spätná väzba
pokus += 1
eskaluj_na_cloveka(odpoved) # fallback po 3 pokusoch
```

Podstata: Aj s garantovane schéme-konformnou formou kontrolujevaliduj() sémantiku, napríklad čicislo_zakaznika zodpovedá očakávanému formátu alebo čizhrnutie dodržiava limit dĺžky. Ak to zlyhá, konkrétna chyba ide ako feedback späť do modelu. Tri pokusy sú rozumný horný limit; potom sa eskaluje na človeka, namiesto nekonečného cyklovania a spaľovania nákladov.

Validácia s Pydantic a Zod ako praktický štandard

V praxi nikto nepíše JSON-Schemas ručne. V Pythone sa definujePydantic-model, v TypeScripteZod-schéma; obe generujú JSON-Schema pre LLM požiadavku a priamo preberajú validáciu odpovede. To má dvojitý úžitok: Tá istá definícia riadi generovanie a kontroluje výsledok, čo zabraňuje nekonzistenciám. Chyby typov, chýbajúce povinné polia alebo porušené rozsahy hodnôt sa pri parsovaní okamžite objavia ako jasná chybová správa, ktorá sa dá znovu použiť ako retry feedback.

Pre agentové frameworky a multi-provider routing uvádza research zdroj (stav 2026) nástroje ako LiteLLM a OpenRouter. Umožňujú smerovať tú istú štruktúrovanú požiadavku proti rôznym modelom, čo znižuje závislosť od poskytovateľa a umožňuje fallback na druhý model, ak provider nedodá štruktúrovaný výstup spoľahlivo.

Časté úskalia

• Príliš zložité schémy. Hlboko vnorené štruktúry s mnohými voliteľnými poľami zvyšujú mieru chýb a latenciu. Tak prísne ako potrebné, tak jednoduché ako možné.
• Zámena formy s obsahom. Objekt konformný so schémou nie je automaticky odborne správny. Halucinované, ale platne typizované hodnoty sú najnebezpečnejšia trieda chýb, pretože nenápadne preklznú.
• Neobmedzené retry. Bez horného limitu hrozia nekonečné cykly a explózia nákladov. Vždy bounded retries s eskalačným fallbackom.
• Ignorovanie rozdielov medzi providermi. Nie každý OpenAI-kompatibilný endpoint skutočne striktne vynucuje schému. Pred spustením otestovať.

Pre agentúry a B2B rozhodovacie osoby

Kto vo Viedni alebo v DACH regióne plánuje produktívneho agenta alebo RAG aplikáciu, mal by štruktúrované výstupy od začiatku zakotviť ako architektonický princíp, nie ako následnú opravu. Presne tu sa rozhoduje, či sa AI projekt stane spoľahlivým nástrojom alebo nepredvídateľným demom. Ako agentúra vo Viedni sprevádza Blck Alpaca DACH podniky pri budovaní robustných RAG a agentových pipeline, od definície schémy cez validáciu a retry logiku až po rozhodnutie o poskytovateľovi a suverenite. Oslovte nás, ak váš RAG alebo agentový projekt potrebuje spoľahlivé, strojovo čitateľné výstupy namiesto hádaného voľného textu.