JSONSchemaBench: 現実世界のスキーマの複雑さがLLMの構造化出力の保証を破壊する
多くのチームは、制約付きデコードを解決済みの問題として扱っています。つまり、JSONスキーマを追加すれば、有効なJSONが返ってくるというものです。JSONSchemaBench (arXiv:2501.10868) は、9,558個の現実世界のスキーマに対してその前提をテストする最初の体系的な試みであり、その結果はマーケティングが示唆するものほど安心できるものではありませんでした。
論文の概要
Saibo Geng、Hudson Cooper、Michał Moskal、およびMicrosoft Researchの同僚たちは、実際の生産ソースから抽出された9,558個のスキーマのベンチマークであるJSONSchemaBenchを発表しました。これには、GlaiveAIの関数呼び出しシグネチャ、難易度（TrivialからUltraまで）で層別化さ れたGitHubリポジトリ、Kubernetes API設定、Snowplowイベント分析スキーマ、およびJSONSchemaStoreコレクションが含まれます。彼らは、Guidance、Outlines、Llamacpp、XGrammar、OpenAI Structured Outputs、Geminiの6つの制約付きデコードフレームワークを、カバレッジ（フレームワークが処理できるスキーマの割合）、効率（制約なし生成と比較した1秒あたりのトークンのオーバーヘッド）、品質（下流タスクの精度）の3つの軸で評価しました。評価グリッドには、準拠するエンジンがサポートすべき45の機能カテゴリを文書化した公式のJSON Schema Test Suiteも含まれています。
核心となる主張は、スキーマの複雑さが、能力のあるフレームワークと脆弱なフレームワークを分ける決定的な変数であり、3つの軸すべてにおいて支配的なフレームワークは存在しないということです。
主なアイデア
- スキーマの複雑さによってカバレッジが崩壊する。 単純なGlaiveAIスキーマでは、すべてのフレームワークが86%以上のスコアを記録しました。しかし、多層のネスト、再帰的定義、複雑なパターン制約を持つGitHub-Hardスキーマでは、Guidanceは41%、Llamacppは39%、XGrammarは28%、Outlinesは壊滅的な3%まで低下しました。OpenAIはGitHub-Hardでわずか9%にしか達せず、Geminiは中程度の複雑さ以上のスキーマでは有効な出力をまったく生成できませんでした。
- KubernetesはXGrammarの特定の弱点を露呈させる。 XGrammarの速度の主張にも かかわらず、Kubernetesスキーマでのカバレッジはわずか7%でした。これは、これらのスキーマが文脈依存のパターンに依存しており、XGrammarの文脈自由な事前計算では処理できないためと考えられます。Kubernetes設定を含むベンチマークに対するカバレッジは、プロダクション用エージェントにとって不可欠です。
- 制約不足はコンパイルの失敗よりも危険である。 XGrammarは、JSON Schema Test Suiteに対して38件の制約不足の失敗を示しました。つまり、宣言されたスキーマに違反するJSONを出力しながら、成功を黙って報告するということです。Guidanceのこのような失敗はわずか1件でした。書き戻しエージェント（write-back agent）にとって、コンパイルエラーは設計時にキャッチされますが、制約不足の失敗は実行時にシグナルなしでデータを破損させます。
- Guidanceのファストフォワーディングは真の50%の高速化を実現する。 長い決定論的なシーケンス（固定されたオブジェクト構造内のフィールド名など）が存在する場合、Guidanceはデコードステップごとに複数のトークンを進めることができます。A100上のLlama-3.1-8Bでは、制約なし生成が15〜16ミリ秒であるのに対し、Guidanceは出力トークンあたり6〜9ミリ秒で動作します。Outlinesは30〜46ミリ秒と制約なし生成よりも遅く、これは主にスキーマあたり3〜8秒かかる事前のオートマトンコンパイルが原因です。
- 制約付きデコードは推論精度をわずかに向上させる。 GSM8K（数学）では、Guidanceによって精度が80.1%（制約なし）から83.8%に向上しました。Last LetterやShuffle Objectsでは、向上は1〜3ポイントの範囲でし た。これは、JSON形式を強制すると回答の品質が低下するという広く引用されている懸念とは対照的ですが、その効果は、形式の選択がフレームワーク選定の主な動機になるほど大きくはありません。
- すべての45のJSONスキーマ機能カテゴリをカバーするフレームワークは存在しない。 Guidanceは13をカバーし、LlamacppとXGrammarはそれぞれ1つ、Outlinesは0でした。実用的な意味合いとしては、
if/then/else、unevaluatedProperties、または再帰的な$ref定義を使用するスキーマは、内部のエンジンに応じて予測不可能な動作をすることになります。
評価できる点とそうでない点
このベンチマークの最大の貢献は、スキーマの調達元にあります。これまでの評価では、おもちゃのようなスキーマや単一ソースのコレクションが使用されていました。関数呼び出しシグネチャと並んでKubernetes設定を含めることは、適切な種類の対抗的な多様性です。また、複雑さの層別化（TrivialからUltraまで）により、実務者にキャリブレーション曲線を提供します。スキーマがGlaiveAIの関数呼び出しのようであれば、XGrammarもGuidanceも問題ありません。しかし、Kubernetesのマニフェストのようであれば、選択肢は急速に狭まります。
主な弱点は、シングルサンプルのグリーディ評価である点です。スキーマごとに1回の生成でカバレッジを測定することは、真の能力を過小評価する可能性があります。フレームワークが20%の確率で失敗しても、再試行すれば成功するかもしれないからです。論文はこの点を認めていますが、失敗時に再試行するプロダクションシステムにとって重要な、温度サンプリングによるpass@kの結果は報告されていません。
また、比較において比較不可能なモデルが混在しています。オープンソースのフレームワーク（Guidance、Outlines、Llamacpp、XGrammar）はLlama-3.2-1Bでテストされていますが、OpenAIとGeminiは独自の非公開モデルを実行しています。OpenAIのGitHub-Hardにおける9%のカバレッジは、制約付きデコードのアーキテクチャだけでなく、モデルの能力を反映している可能性があります。公平な比較には、制御されたモデルへのアクセスが必要ですが、著者がプロプライエタリなプロバイダーにそれを強制することは当然不可能です。
なぜこれが財務AIにとって重要なのか
すべてのBeancount書き戻しエージェントは、構造化された出力を生成します。エージェントが.beancount構文に変換する前にJSONとしてBeancountディレクティブを出力する場合、あるいはJSONスキーマを介してツールを呼び出す場合、そのJSON生成の信頼性は些細なことではなく、システム全体の成否を左右します。FinTraceの論文は、フロンティアモデルがツールの出力に対する推 論に失敗することを示しました。JSONSchemaBenchは、それとは別の問題、すなわち推論の前段階であるフォーマットレイヤーが、非準拠の出力を黙って生成する可能性があることを明らかにしています。
Kubernetesの結果は、Beancountにとって特に示唆に富んでいます。元帳（ledger）のスキーマは、単純なキーと値の集まりではありません。勘定科目の階層、トランザクションのメタデータ、およびタグ構造は、Kubernetes APIオブジェクトに似た、ネストされた再帰的パターンを作成します。Kubernetesで7%のスコアしか出せないフレームワークは、トークンあたりのオーバーヘッドがいかに高速であっても、複雑な元帳スキーマに対応する準備ができていません。
特に懸念されるのは、制約不足の失敗モードです。XGrammarを使用しているBeancountエージェントは、フレームワーク内部の検証チェックには合格するものの、実際のスキーマには違反するトランザクションを出力する可能性があり、エージェントが再試行する理由もなくなります。目に見える失敗よりも、サイレントな破損の方がはるかに深刻です。
次に読むべきもの
- XGrammar (arXiv:2411.15100, Dong et al.) — テストされた中で最も高速なフレームワークの一つに関する技術論文。文脈依存/非依存のトークン分割と、なぜKubernetesスキーマがそれに負荷をかけるのかを説明しています。
- Grammar-Aligned Decoding / ASAp (NeurIPS 2024) — 制約付きデコードにおけるトークンマスキングがモデルの確率分布を歪める可能性があることを示し、修正されたサンプリングアルゴリズムを提案しています。これは、ベンチマークが間接的にのみ測定している品質に関する懸念の理論的基礎となります。
- XGrammar-2 (arXiv:2601.04426) — マルチターンのセッション中にスキーマ自体が変化するエージェント環境において、XGrammarを動的スキーマに拡張するフォローアップ論文。アクティブな勘定科目の種類に基づいて出力形式を適応させるBeancountエージェントに直接関連します。
