JSONSchemaBench: Сложността на реалните схеми нарушава гаранциите за структуриран изход при LLM

Повечето екипи разглеждат ограниченото декодиране като решен проблем — добавяте JSON схема и получавате валиден JSON обратно. JSONSchemaBench (arXiv:2501.10868) е първият систематичен опит за тестване на това предположение спрямо 9 558 реални схеми и резултатите са по-малко успокояващи, отколкото маркетингът би ни убедил.

Документът

Сайбо Генг, Хъдсън Купър, Михал Москал и колеги от Microsoft Research представят JSONSchemaBench, бенчмарк от 9 558 схеми, извлечени от реални производствени източници: сигнатури за извикване на функции от GlaiveAI, GitHub хранилища, стратифицирани по сложност от тривиални до ултра, API конфигурации на Kubernetes, схеми за анализи на събития на Snowplow и колекцията JSONSchemaStore. Те оценяват шест рамки за ограничено декодиране — Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs и Gemini — по три оси: покритие (каква част от схемите може изобщо да обработи рамката), ефективност (преразход на токени в секунда спрямо неограниченото генериране) и качество (точност на задачите по веригата). Мрежата за оценка включва също и официалния JSON Schema Test Suite, който документира 45 категории функции, които всяка съвместима машина трябва да поддържа.

Основното твърдение е, че сложността на схемата е решаващата променлива, която отделя способните рамки от крехките, и че нито една рамка не доминира и по трите оси.

Ключови идеи

• Покритието се срива под тежестта на сложността на схемите. При прости схеми от GlaiveAI всички рамки отбелязват над 86%. Но при схемите GitHub-Hard — многостепенно влагане, рекурсивни дефиниции, сложни ограничения на шаблони — Guidance пада до 41%, Llamacpp до 39%, XGrammar до 28%, а Outlines до катастрофалните 3%. OpenAI достига само 9% при GitHub-Hard, а Gemini не произвежда никакви валидни изходи при схеми със средна сложност или по-висока.
• Kubernetes разкрива специфична слабост в XGrammar. Въпреки твърденията за скорост на XGrammar, тя постига само 7% покритие на схеми на Kubernetes, вероятно защото тези схеми разчитат на зависими от контекста модели, които независимото от контекста предварително изчисление на XGrammar не може да обработи. Покритието срещу бенчмарк, който включва Kubernetes конфигурации, не е опция, а задължително условие за производствени агенти.
• Недостатъчното ограничаване е по-опасно от грешка при компилация. XGrammar показва 38 грешки от тип „под-ограничаване“ (under-constrained) спрямо JSON Schema Test Suite — което означава, че тя излъчва JSON, който нарушава декларираната схема, докато мълчаливо докладва успех. Guidance има само 1 такъв провал. За агент, който пише обратно в базата, грешката при компилация се улавя по време на разработка; провалът на ограничаването корумпира данни в реално време без никакъв сигнал.
• Функцията за „бързо превъртане“ (fast-forwarding) на Guidance осигурява реално 50% ускорение. Когато са налични дълги детерминистични последователности (напр. имена на полета във фиксирана структура на обект), Guidance може да прескочи няколко токена на една стъпка от декодирането. На Llama-3.1-8B на A100, Guidance работи с 6–9 ms на изходен токен, докато неограниченото генериране работи с 15–16 ms. Outlines е по-бавна от неограниченото генериране с 30–46 ms, до голяма степен поради предварителната компилация на автомати, която отнема 3–8 секунди на схема.
• Ограниченото декодиране скромно подобрява точността на разсъжденията. В GSM8K (математика), Guidance повишава точността от 80,1% (неограничено) до 83,8%. При Last Letter и Shuffle Objects подобренията са в рамките на 1–3 пункта. Това противоречи на широко цитираното опасение, че форсирането на JSON формат влошава качеството на отговора — но размерът на ефекта е достатъчно малък, за да не бъде изборът на формат водещ при избора на рамка.
• Нито една рамка не покрива всички 45 категории функции на JSON Schema. Guidance покрива 13, Llamacpp и XGrammar покриват по 1, а Outlines покрива 0. Практическото значение е, че всяка схема, използваща if/then/else, unevaluatedProperties или рекурсивни дефиниции $ref, ще се държи непредсказуемо в зависимост от това кой двигател стои „под капака“.

Какво се потвърждава — и какво не

Най-силният принос на бенчмарка е източникът на схеми. Предишни оценки са използвали схеми-играчки или колекции от един източник. Включването на конфигурации на Kubernetes заедно със сигнатури за извикване на функции е правилният вид състезателно многообразие. Стратификацията на сложността (от тривиална до ултра) също дава на практиците крива за калибриране: ако вашите схеми приличат на извиквания на функции на GlaiveAI, XGrammar или Guidance са еднакво добри; ако приличат на Kubernetes манифести, опциите ви бързо намаляват.

Основната слабост е оценката с една извадка (single-sample greedy evaluation). Измерването на покритието с едно генериране на схема подценява истинските възможности — дадена рамка може да се провали в 20% от случаите, но да успее при повторен опит. Документът признава това, но не съобщава pass@k числа с температурно семплиране, които биха били от значение за производствени системи, които повтарят опитите при неуспех.

Сравнението също така смесва несъпоставими модели. Рамките с отворен код (Guidance, Outlines, Llamacpp, XGrammar) са тествани на Llama-3.2-1B, докато OpenAI и Gemini работят със собствени неразкрити модели. 9-процентното покритие на OpenAI при GitHub-Hard може да отразява способностите на модела толкова, колкото и архитектурата за ограничено декодиране. Справедливо сравнение би изисквало контролиран достъп до моделите — нещо, което авторите очевидно не могат да наложат на собственическите доставчици.

Защо това е важно за финансовия изкуствен интелект

Всеки Beancount агент за обратно записване генерира структуриран изход. Ако агентът излъчва Beancount директиви като JSON преди конвертиране в .beancount синтаксис, или ако извиква инструменти чрез JSON схеми, надеждността на това генериране на JSON не е подробност — тя е в основата на всичко. Документът FinTrace показа, че водещите модели се провалят при разсъждения върху изходите на инструментите; JSONSchemaBench разкрива ортогонален проблем: дори преди разсъжденията, форматиращият слой може мълчаливо да генерира несъответстващ изход.

Резултатът с Kubernetes е особено показателен за Beancount. Счетоводните схеми не са плоски структури от ключове и стойности. Йерархиите на сметките, метаданните на трансакциите и структурите на таговете създават вложени рекурсивни модели, подобни на API обектите на Kubernetes. Рамка, която отбелязва 7% при Kubernetes, не е готова за сложни счетоводни схеми, независимо колко малък е нейният преразход на токен.

Режимът на провал с под-ограничаване е този, който би ме тревожил най-много. Агент на Beancount, използващ XGrammar, може да излъчи трансакция, която преминава вътрешната проверка за валидиране на рамката, но нарушава действителната схема — и агентът няма да има причина да опита отново. Тихото повреждане на данни е по-лошо от видимия провал.

Какво да прочетете след това

• XGrammar (arXiv:2411.15100, Dong et al.) — техническият документ зад една от най-бързите тествани рамки, обясняващ разделянето на токените на независими и зависими от контекста и защо схемите на Kubernetes ги натоварват.
• Grammar-Aligned Decoding / ASAp (NeurIPS 2024) — показва, че маскирането на токени при ограничено декодиране може да изкриви разпределението на вероятностите на модела и предлага коригиран алгоритъм за семплиране; теоретичната основа за притесненията относно качеството, които бенчмаркът измерва само индиректно.
• XGrammar-2 (arXiv:2601.04426) — продължение, което разширява XGrammar до динамични схеми в агентски настройки, където самата схема се променя по време на сесия с множество ходове, пряко релевантно за Beancount агенти, които адаптират своя изходен формат въз основа на това кои типове сметки са активни.