JSONSchemaBench: Komplexita schém v reálnom svete narúša garancie štruktúrovaného výstupu LLM

Väčšina tímov považuje obmedzené dekódovanie za vyriešený problém – stačí pridať JSON schému a získate platný JSON. JSONSchemaBench (arXiv:2501.10868) je prvým systematickým pokusom o otestovanie tohto predpokladu na 9 558 reálnych schémach a výsledky sú menej upokojujúce, než by naznačoval marketing.

Práca

Saibo Geng, Hudson Cooper, Michał Moskal a kolegovia z Microsoft Research predstavujú JSONSchemaBench, benchmark 9 558 schém čerpaných z reálnych produkčných zdrojov: signatúr volaní funkcií GlaiveAI, repozitárov GitHub rozvrstvených podľa zložitosti od triviálnych po ultra, konfigurácií Kubernetes API, schém analýzy udalostí Snowplow a kolekcie JSONSchemaStore. Hodnotia šesť frameworkov pre obmedzené dekódovanie – Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs a Gemini – v troch osiach: pokrytie (akú časť schém framework vôbec zvládne), efektívnosť (réžia v počte tokenov za sekundu oproti neobmedzenému generovaniu) a kvalita (presnosť následných úloh). Hodnotiaca mriežka zahŕňa aj oficiálnu testovaciu sadu JSON Schema Test Suite, ktorá dokumentuje 45 kategórií funkcií, ktoré by mal podporovať každý vyhovujúci engine.

Hlavným tvrdením je, že komplexita schémy je rozhodujúcou premennou, ktorá oddeľuje schopné frameworky od tých krehkých, a že žiadny framework nedominuje vo všetkých troch osiach.

Kľúčové myšlienky

• Pokrytie kolabuje pod komplexitou schém. Pri jednoduchých schémach GlaiveAI dosahujú všetky frameworky skóre nad 86 %. Ale pri schémach GitHub-Hard – viacúrovňové vnorenie, rekurzívne definície, komplexné obmedzenia vzorov – Guidance klesá na 41 %, Llamacpp na 39 %, XGrammar na 28 % a Outlines na katastrofálne 3 %. OpenAI dosahuje len 9 % na GitHub-Hard a Gemini neprodukuje žiadne platné výstupy pri schémach strednej alebo vyššej zložitosti.
• Kubernetes odhaľuje špecifickú slabinu v XGrammar. Napriek tvrdeniam o rýchlosti XGrammar dosahuje len 7 % pokrytie pri schémach Kubernetes, pravdepodobne preto, že tieto schémy sa spoliehajú na vzory závislé od kontextu, ktoré nezávislá predbežná kalkulácia kontextu v XGrammar nedokáže spracovať. Pokrytie voči benchmarku, ktorý zahŕňa konfigurácie Kubernetes, nie je pre produkčných agentov voliteľné.
• Nedostatočné obmedzenie (under-constrained) je nebezpečnejšie ako zlyhanie kompilácie. XGrammar vykazuje 38 zlyhaní z dôvodu nedostatočného obmedzenia voči JSON Schema Test Suite – čo znamená, že vygeneruje JSON, ktorý porušuje deklarovanú schému, pričom ticho hlási úspech. Guidance má len 1 takéto zlyhanie. Pre agenta so spätným zápisom je chyba kompilácie zachytená v čase návrhu; zlyhanie z dôvodu nedostatočného obmedzenia poškodí dáta za behu bez akéhokoľvek signálu.
• Rýchly posun vpred (fast-forwarding) v Guidance prináša skutočné 50 % zrýchlenie. Ak sú prítomné dlhé deterministické sekvencie (napr. názvy polí v pevnej štruktúre objektu), Guidance môže postúpiť o viacero tokenov v jednom kroku dekódovania. Na Llama-3.1-8B na A100 beží Guidance rýchlosťou 6–9 ms na výstupný token, zatiaľ čo neobmedzené generovanie trvá 15–16 ms. Outlines je pomalší ako neobmedzené generovanie s 30–46 ms, hlavne kvôli počiatočnej kompilácii automatu, ktorá trvá 3–8 sekúnd na schému.
• Obmedzené dekódovanie mierne zlepšuje presnosť uvažovania. Na GSM8K (matematika) Guidance zvyšuje presnosť z 80,1 % (neobmedzené) na 83,8 %. Pri úlohách Last Letter a Shuffle Objects sú zisky v rozmedzí 1–3 bodov. To odporuje často uvádzanej obave, že vynútenie formátu JSON znižuje kvalitu odpovede – efekt je však dostatočne malý na to, aby výber formátu nebol hlavným kritériom pri voľbe frameworku.
• Žiadny framework nepokrýva všetkých 45 kategórií funkcií JSON Schema. Guidance pokrýva 13, Llamacpp a XGrammar každý po 1 a Outlines pokrýva 0. Praktickým dôsledkom je, že akákoľvek schéma používajúca if/then/else, unevaluatedProperties alebo rekurzívne definície $ref, sa bude správať nepredvídateľne v závislosti od toho, aký engine sa nachádza "pod kapotou".

Čo obstojí — a čo nie

Najsilnejším prínosom benchmarku je výber zdrojov schém. Predchádzajúce hodnotenia používali triviálne schémy alebo kolekcie z jedného zdroja. Zahrnutie konfigurácií Kubernetes popri signatúrach volaní funkcií je správnym druhom kontradiktórnej diverzity. Stratifikácia zložitosti (od triviálnej po ultra) tiež poskytuje odborníkom kalibračnú krivku: ak vaše schémy vyzerajú ako volania funkcií GlaiveAI, XGrammar aj Guidance sú v poriadku; ak vyzerajú ako manifesty Kubernetes, vaše možnosti sa rýchlo zužujú.

Hlavnou slabinou je hodnotenie na základe jednej vzorky s využitím greedy dekódovania. Meranie pokrytia jednou generáciou na schému podhodnocuje skutočné schopnosti – framework môže zlyhať v 20 % prípadov, ale uspieť pri opakovanom pokuse. Práca to priznáva, ale neuvádza čísla pass@k pri vzorkovaní s teplotou (temperature sampling), čo by bolo dôležité pre produkčné systémy, ktoré pri zlyhaní vykonávajú opakované pokusy.

Porovnanie tiež mieša neporovnateľné modely. Open-source frameworky (Guidance, Outlines, Llamacpp, XGrammar) sú testované na Llama-3.2-1B, zatiaľ čo OpenAI a Gemini bežia na vlastných nezverejnených modeloch. 9 % pokrytie OpenAI na GitHub-Hard môže odrážať schopnosti modelu rovnako ako architektúru obmedzeného dekódovania. Spravodlivé porovnanie by si vyžadovalo kontrolovaný prístup k modelu – čo autori od proprietárnych poskytovateľov samozrejme nemôžu vynútiť.

Prečo je to dôležité pre finančnú AI

Každý agent so spätným zápisom v Beancounte generuje štruktúrovaný výstup. Ak agent generuje direktívy Beancount ako JSON pred ich konverziou na syntax .beancount, alebo ak volá nástroje cez JSON schémy, spoľahlivosť tejto generácie JSON nie je detail – je to základ celého procesu. Práca FinTrace ukázala, že špičkové modely zlyhávajú pri uvažovaní nad výstupmi nástrojov; JSONSchemaBench odhaľuje iný problém: ešte pred samotným uvažovaním môže formátovacia vrstva ticho vyprodukovať nevyhovujúci výstup.

Výsledok s Kubernetes je obzvlášť príznačný pre Beancount. Schémy účtovných kníh nie sú len ploché sady kľúčov a hodnôt. Hierarchie účtov, metadáta transakcií a štruktúry tagov vytvárajú vnorené rekurzívne vzory podobné objektom Kubernetes API. Framework, ktorý dosahuje 7 % v Kubernetes, nie je pripravený na komplexné schémy účtovných kníh bez ohľadu na to, aká nízka je jeho réžia na token.

Režim zlyhania z dôvodu nedostatočného obmedzenia (under-constrained) je to, čo by mi nedalo spať. Beancount agent používajúci XGrammar by mohol vygenerovať transakciu, ktorá prejde internou kontrolou validácie frameworku, ale poruší skutočnú schému – a agent by nemal dôvod na opakovaný pokus. Tiché poškodenie dát je horšie ako viditeľné zlyhanie.

Čo si prečítať ďalej

• XGrammar (arXiv:2411.15100, Dong et al.) – technická práca v pozadí jedného z najrýchlejších testovaných frameworkov, vysvetľujúca rozdelenie tokenov na nezávislé a závislé od kontextu a prečo ho schémy Kubernetes zaťažujú.
• Grammar-Aligned Decoding / ASAp (NeurIPS 2024) – ukazuje, že maskovanie tokenov v obmedzenom dekódovaní môže skresliť pravdepodobnostné rozdelenie modelu a navrhuje opravený algoritmus vzorkovania; teoretický základ pre obavy o kvalitu, ktoré benchmark meria len nepriamo.
• XGrammar-2 (arXiv:2601.04426) – nadväzujúca práca, ktorá rozširuje XGrammar na dynamické schémy v agentických prostrediach, kde sa samotná schéma mení počas relácie s viacerými kolami, čo je priamo relevantné pre agentov Beancount, ktorí prispôsobujú formát výstupu podľa toho, ktoré typy účtov sú aktívne.