Š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 zadanej 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 nadväzujúce programové kroky sa môžu spoľahnúť na garantovanú dátovú štruktúru namiesto parsovania chybového 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 spracovať priamo bez krehkej regex alebo string logiky. To je základ spoľahlivých agentov.
• Ako? Cez funkcie poskytovateľov ako OpenAI Structured Outputs, Anthropic Tool-Use schéma 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 pre chatbota ideálne, 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ý biznis parsovania. Model raz napíše "Kategória je faktúra.", inokedy "Kategória: faktúra", inokedy pred to pridá vysvetlenie. Každý z týchto variantov rozbije naivnú extrakčnú logiku.

Pri multi-step agentoch sa to dramaticky zostruje, pretože sa nespoľahlivosť cez reťazec znásobuje. Príklad výpočtu: ak má každý jednotlivý krok úspešnosť parsovania 95 percent, leží end-to-end úspešnosť pri reťazci z desiatich krokov už len na 0,95 na desiatu, teda približne 60 percent. Ak sa každý krok pomocou štruktúrovaných výstupov zvýši na 99,5 percenta, dostane sa ten istý reťazec na 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 zrelými.

Tri úrovne garancie v prehľade

Nie každá metóda, ktorá sľubuje JSON, dodáva rovnakú garanciu. Treba rozlišovať tri úrovne a tento 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 upadnúť do súvislého textu. Žiadna garancia.

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

Constrained decoding / Structured Outputs. Tu sa proces generovania obmedzí na úrovni tokenov tak, že môžu vznikať len tokeny, ktoré zodpovedajú schéme. Model už nemôže výsledok zodpovedajúci schéme vôbec opustiť. 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ú rovnakú úlohu knižnice a inference stacky cez grammar constraints.

Metóda, garancia, tradeoff v porovnaní

Rozhodujúce poznanie z tejto tabuľky: constrained decoding garantuje formu, nie obsah. Model dodá garantovane platný objekt s poľom rechnungsdatum, ale či tam zapísaná hodnota skutočne zodpovedá dátumu na dokumente, nedokáže zabezpečiť žiadny decoding postup. Preto zostávajú odborná validácia a retry stratégia nepostrádateľné.

Realita poskytovateľov k stavu 2026

Vedúci poskytovatelia podporujú štruktúrované výstupy rôznymi, ale konvergujúcimi prístupmi. Podľa výskumného zdroja (k stavu 2026) je Claude Opus 4.7 (pricing 5 amerických dolárov input / 25 amerických dolárov output za milión tokenov) explicitne pozicionovaný pre agentické workloady a orchestráciu toolov; pri Claude prebieha štruktúrovaný výstup primárne cez Tool-Use s JSON schémou. OpenAI GPT-5.5 je v tom istom zdroji opísaný ako silne zameraný na terminálové a agentové workloady. Google Gemini 3.1 Pro (2 americké doláre / 12 amerických dolárov za milión tokenov, k stavu 2026) dopĺňa toto pole veľmi veľkým kontextovým oknom.

Na open-weight strane sú podľa toho istého zdroja (k stavu 2026) dostupné Mistral Large 3 (Apache 2.0, 0,50 / 1,50 amerických dolárov), DeepSeek V4 ako aj Kimi K2.6, ktoré sa na agentických a coding benchmarkoch približujú 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 frankfurtským regiónom pre DSGVO-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 naprieč všetkými providermi identická. Pred rozhodnutím treba overiť, či konkrétny provider strict režim alebo schema constraints skutočne presadzuje, alebo ponúka len JSON-Mode.

Príklad schémy a retry stratégia

Konkrétny príklad robí princíp uchopiteľným. Agent má klasifikovať prichádzajúce support požiadavky a extrahovať najdôležitejšie polia. JSON schéma (zjednodušene) vyzerá takto:

```json
{
"type": "object",
"properties": {
"kategorie": {
"type": "string",
"enum": ["rechnung", "technik", "vertrag", "sonstiges"],
"description": "Hauptkategorie der Anfrage"
},
"dringlichkeit": {
"type": "string",
"enum": ["niedrig", "mittel", "hoch"]
},
"kundennummer": {
"type": ["string", "null"],
"description": "Kundennummer falls im Text genannt, sonst null"
},
"zusammenfassung": {
"type": "string",
"description": "Ein Satz, maximal 200 Zeichen"
}
},
"required": ["kategorie", "dringlichkeit", "kundennummer", "zusammenfassung"],
"additionalProperties": false
}
```

Dve dizajnové rozhodnutia sú tu centrálne. Po prvé enumy namiesto voľného textu pre kategorie a dringlichkeit: tým je vylúčené, že model vymyslí "Rechnungswesen" alebo "sehr hoch", čo by rozbilo nadväzujúcu smerovaciu logiku. Po druhé additionalProperties: false, aby sa neobjavili nechcené dodatočné polia. Polia description pôsobia pritom ako implicitná inštrukcia pre model.

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

```
versuch = 0
while versuch < 3:
antwort = llm.call(prompt, schema=support_schema) # strukturierte Ausgabe
objekt = parse_json(antwort) # Form ist garantiert
fehler = validiere(objekt) # semantische Pruefung
if not fehler:
return objekt
prompt += f"\nKorrigiere: {fehler}" # Fehler-Feedback
versuch += 1
eskaliere_an_mensch(antwort) # Fallback nach 3 Versuchen
```

Pointa: aj s garantovane schéme zodpovedajúcou formou kontroluje validiere() sémantiku, napríklad či kundennummer zodpovedá očakávanému formátu alebo či zusammenfassung dodržiava hranicu dĺžky. Ak to zlyhá, ide konkrétna chyba ako spätná väzba späť do modelu. Tri pokusy sú zmysluplnou hornou hranicou; potom sa eskaluje na človeka namiesto nekonečného slučkovania a spaľovania nákladov.

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

V praxi nikto nepíše JSON schémy ručne. V Pythone sa definuje Pydantic model, v TypeScripte Zod schéma; oba generujú JSON schému 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. Typové chyby, chýbajúce povinné polia alebo porušené rozsahy hodnôt sa pri parsovaní okamžite objavia ako jasná chybová hláška, ktorá sa dá znovu použiť ako retry spätná väzba.

Pre agentové frameworky a multi-provider routing menuje výskumný zdroj (k stavu 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ť na poskytovateľovi a zároveň umožňuje fallback na druhý model, ak provider štruktúrovaný výstup nedodá spoľahlivo.

Časté úskalia

• Príliš komplexné schémy. Hlboko zanorené štruktúry s mnohými voliteľnými poľami zvyšujú chybovosť a latenciu. Tak striktné, ako je potrebné, tak jednoduché, ako je možné.
• Zamieňanie formy s obsahom. Objekt zodpovedajúci schéme nie je automaticky odborne správny. Halucinované, ale platne typované hodnoty sú najnebezpečnejšia trieda chýb, pretože nenápadne prekĺznu.
• Neobmedzené retries. Bez hornej hranice hrozia nekonečné slučky a explózia nákladov. Vždy bounded retries s eskalačným fallbackom.
• Ignorovanie rozdielov medzi providermi. Nie každý OpenAI-kompatibilný endpoint vynucuje schému skutočne striktne. Pred go-live otestovať.

Pre agentúry a B2B rozhodovateľov

Kto vo Viedni alebo v DACH regióne plánuje produkčného agenta alebo RAG aplikáciu, mal by štruktúrované výstupy ukotviť od začiatku ako architektonický princíp, nie ako dodatočnú opravu. Práve tu sa rozhoduje, či sa AI projekt stane spoľahlivým nástrojom, alebo zostane nevyspytateľným demom. Ako agentúra vo Viedni sprevádza Blck Alpaca DACH firmy 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. Ozvite sa nám, ak váš RAG alebo agentový projekt potrebuje spoľahlivé, strojovo čitateľné výstupy namiesto uhádnutého voľného textu.