JSONSchemaBench: La complexitat dels esquemes del món real trenca les garanties de sortida estructurada dels LLM
La majoria dels equips tracten la descodificació restringida com un problema resolt: s'afegeix un esquema JSON i s'obté un JSON vàlid. JSONSchemaBench (arXiv:2501.10868) és el primer intent sistemàtic de provar aquesta hipòtesi amb 9.558 esquemes del món real, i els resultats són menys tranquil·litzadors del que suggereix el màrqueting.
L'article
Saibo Geng, Hudson Cooper, Michał Moskal i col·legues de Microsoft Research presenten JSONSchemaBench, una referència de 9.558 esquemes extrets de fonts de producció reals: signatures de crides a funcions de GlaiveAI, repositoris de GitHub estratificats per complexitat des de trivial fins a ultra, configuracions d'API de Kubernetes, esquemes d'anàlisi d'esdeveniments de Snowplow i la col·lecció JSONSchemaStore. Avaluen sis entorns de descodificació restringida —Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs i Gemini— en tres eixos: cobertura (quina fracció d'esquemes pot gestionar l'entorn), eficiència (sobrecost de tokens per segon en comparació amb la generació no restringida) i qualitat (precisió en tasques posteriors). La matriu d'avaluació també inclou la JSON Schema Test Suite oficial, que documenta 45 categories de funcions que qualsevol motor conforme hauria de suportar.
L'afirmació central és que la complexitat de l'esquema és la variable decisiva que separa els entorns capaços dels fràgils, i que cap entorn domina en els tres eixos.
Idees clau
- La cobertura s'enfonsa sota la complexitat de l'esquema. En esquemes simples de GlaiveAI, tots els entorns puntuen per sobre del 86%. Però en els esquemes GitHub-Hard —amb anidament de diversos nivells, definicions recursives i restriccions de patrons complexes— Guidance cau al 41%, Llamacpp al 39%, XGrammar al 28% i Outlines a un catastròfic 3%. OpenAI arriba només al 9% a GitHub-Hard, i Gemini no produeix cap sortida vàlida en esquemes de complexitat mitjana o superior.
- Kubernetes exposa una debilitat específica a XGrammar. Malgrat les promeses de velocitat de XGrammar, només aconsegueix una cobertura del 7% en esquemes de Kubernetes, probablement perquè aquests esquemes depenen de patrons dependents del context que la precomputació independent del context de XGrammar no pot gestionar. La cobertura en una referència que inclou configuracions de Kubernetes no és opcional per als agents de producció.
- Una restricció insuficient és més perillosa que un error de compilació. XGrammar presenta 38 fallades per restricció insuficient en la JSON Schema Test Suite, el que significa que emet JSON que viola l'esquema declarat mentre informa silenciosament d'èxit. Guidance només té una fallada d'aquest tipus. Per a un agent d'escriptura, un error de compilació es detecta en el moment del disseny; una fallada per restricció insuficient corromp les dades en temps d'execució sense cap senyal.
- L'avanç ràpid de Guidance ofereix una acceleració real del 50%. Quan hi ha seqüències deterministes llargues (per exemple, noms de camps en una estructura d'objecte fixa), Guidance pot avançar diversos tokens per cada pas de descodificació. En un Llama-3.1-8B sobre una A100, Guidance funciona a 6–9 ms per token de sortida, mentre que la generació no restringida funciona a 15–16 ms. Outlines és més lent que la generació no restringida, a 30–46 ms, principalment a causa de la compilació prèvia de l'autòmat que triga entre 3 i 8 segons per esquema.
- La descodificació restringida millora modestament la precisió del raonament. A GSM8K (matemàtiques), Guidance eleva la precisió del 80,1% (no restringida) al 83,8%. A Last Letter i Shuffle Objects, els guanys se situen entre 1 i 3 punts. Això contradiu la preocupació sovint citada que forçar el format JSON degrada la qualitat de la resposta, però la magnitud de l'efecte és prou petita com perquè l'elecció del format no hagi de determinar la selecció de l'entorn.
- Cap entorn cobreix les 45 categories de funcions de JSON Schema. Guidance en cobreix 13, Llamacpp i XGrammar en cobreixen 1 cadascun, i Outlines en cobreix 0. La implicació pràctica és que qualsevol esquema que utilitzi
if/then/else,unevaluatedPropertieso definicions recursives$refes comportarà de manera impredictible depenent del motor que hi hagi sota el capó.
Què se sosté — i què no
La contribució més forta de la referència és l'obtenció dels esquemes. Les avaluacions anteriors utilitzaven esquemes de joguina o col·leccions d'una sola font. Incloure configuracions de Kubernetes juntament amb signatures de crides a funcions és el tipus correcte de diversitat adversària. L'estratificació de la complexitat (de trivial a ultra) també ofereix als professionals una corba de calibratge: si els teus esquemes s'assemblen a les crides de funcions de GlaiveAI, tant XGrammar com Guidance estan bé; si s'assemblen a manifests de Kubernetes, les teves opcions es redueixen ràpidament.
La debilitat principal és l'avaluació cobdiciosa (greedy) d'una sola mostra. Mesurar la cobertura amb una sola generació per esquema infravalora la capacitat real: un entorn podria fallar el 20% de les vegades però tenir èxit en un reintent. L'article ho reconeix però no informa de les xifres de pass@k amb mostreig per temperatura, que serien importants per als sistemes de producció que reintenten en cas de fallada.
La comparació també barreja models incomparables. Els entorns de codi obert (Guidance, Outlines, Llamacpp, XGrammar) es proven amb Llama-3.2-1B, mentre que OpenAI i Gemini utilitzen els seus propis models no revelats. La cobertura del 9% d'OpenAI a GitHub-Hard podria reflectir tant la capacitat del model com l'arquitectura de descodificació restringida. Una comparació justa requeriria un accés controlat al model, cosa que els autors, òbviament, no poden imposar als proveïdors propietaris.
Per què això és important per a la IA financera
Cada agent d'escriptura de Beancount genera una sortida estructurada. Si l'agent emet directives de Beancount com a JSON abans de convertir-les a la sintaxi de .beancount, o si crida eines mitjançant esquemes JSON, la fiabilitat d'aquesta generació JSON no és un detall: és tot el joc. L'article FinTrace va demostrar que els models de frontera fallen en el raonament sobre les sortides de les eines; JSONSchemaBench revela un problema ortogonal: fins i tot abans del raonament, la capa de format pot emetre silenciosament una sortida no conforme.
El resultat de Kubernetes és especialment revelador per a Beancount. Els esquemes de llibres majors no són llistes planes de clau-valor. Les jerarquies de comptes, les metadades de les transaccions i les estructures d'etiquetes creen patrons recursius niats similars als objectes de l'API de Kubernetes. Un entorn que puntua un 7% a Kubernetes no està preparat per a esquemes de llibres majors complexos, independentment de la velocitat del seu sobrecost per token.
El mode de fallada per restricció insuficient és el que realment em preocuparia. Un agent de Beancount que utilitzi XGrammar podria emetre una transacció que superi la verificació de validació interna de l'entorn però que violi l'esquema real, i l'agent no tindria cap motiu per reintentar-ho. La corrupció silenciosa és pitjor que una fallada visible.
Què llegir a continuació
- XGrammar (arXiv:2411.15100, Dong et al.): l'article tècnic darrere d'un dels entorns més ràpids provats, que explica la divisió de tokens independent/dependent del context i per què els esquemes de Kubernetes el posen a prova.
- Grammar-Aligned Decoding / ASAp (NeurIPS 2024): mostra que emmascarar tokens en la descodificació restringida pot distorsionar la distribució de probabilitat del model i proposa un algorisme de mostreig corregit; el fonament teòric per a les preocupacions de qualitat que la referència mesura només indirectament.
- XGrammar-2 (arXiv:2601.04426): una continuació que amplia XGrammar a esquemes dinàmics en entorns d'agents on l'esquema mateix canvia durant una sessió de diversos torns, directament rellevant per als agents de Beancount que adapten el seu format de sortida segons quins tipus de comptes estiguin actius.
