ローカルLLMの出力が有効なJSONスキーマに適合しなくなる原因は何ですか？

ローカルLLMの出力が有効なJSONスキーマを壊すのは、生成、制約処理、停止ルール、検証が同じ契約を適用していない場合です。

セルフホスト型のワークフローでは、ファイルメタデータ、スマートホームのアクション、文書抽出、ツール引数などに標準準拠のスキーマを指定しても、形式不正または拒否される出力を受け取ることがあります。「有効なスキーマ」とはスキーマ文書の状態を示すものであり、実行経路全体を示すものではありません。モデルはタスクを理解し、デコーダーは関連するスキーマ機能に対応し、停止条件で打ち切られる前に生成を完了し、パーサーは完全なJSON値を復元し、アプリケーションのバリデーターは想定されたドラフトと型変換のルールを適用する必要があります。

有効なJSONとスキーマに適合したJSONは異なる結果です

オブジェクトは正常に解析できても、必須フィールド、型、列挙値、配列の制限、条件分岐に違反することがあります。また、正しいフィールド名を含んでいても、スキーマで禁止されているプロパティを追加する場合があります。

PythonのJSONモジュールは、JSON文書のデコードにおける構文レイヤーを定義しますが、解析によって別個のJSON Schema契約が適用されるわけではありません。

この原因は、構文エラーなしで出力を読み込めるものの、スキーマ検証後にのみ失敗する場合に見分けられます。閉じ括弧の欠落や末尾の説明文はシリアライズの失敗であり、整数が必要な場所に文字列があるのは契約違反です。

スキーマの合成によって満たしにくい分岐が生じることがあります

allOf、anyOf、oneOf、notなどのキーワードは制約を組み合わせます。ある分岐は単独では有効でも、組み合わせたオブジェクトが許可された選択肢のどれにも適合しなかったり、複数に適合したりすることがあります。

JSON Schemaのガイドでは、スキーマの合成キーワードによって、1つまたは複数のサブスキーマへの適合要件がどのように変わるかを説明しています。

ローカルモデルは、複雑な条件分岐が入れ子になっている場合よりも、プロパティの単純な一覧を安定して処理できることが多いです。共用体や相互排他的なオブジェクト形状の周辺で失敗が集中するなら、主な負荷は基本的なJSONの句読法ではなく、分岐の選択にあります。

制約付きデコーダーがスキーマの一部にしか対応していない場合があります

構造化出力エンジンは、スキーマをトークン制約、文法、正規表現、またはバックエンド固有のルールに変換します。すべてのエンジンが、あらゆるJSON Schemaドラフトやキーワードを実装しているわけではありません。

vLLMは複数の構造化出力バックエンドを公開しており、JSONスキーマ、文法、正規表現、固定された選択肢による制約が、それぞれ別の実行モードであることを示しています。

この原因は、標準準拠のバリデーターでは同じスキーマが正常に検証できるのに、特定の推論バックエンドでのみ失敗する場合に現れます。未対応の再帰、参照、パターン、条件キーワードは、モデルが何も生成する前に簡略化、無視、または拒否されることがあります。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

プロンプトの指示がスキーマと競合することがあります

ユーザープロンプトが解説、引用、説明、任意項目の省略、自然言語による不確実性を求める一方で、スキーマは固定フィールドを持つ単一のオブジェクトだけを要求することがあります。

するとモデルには、ユーザーに会話形式で答えることと、機械的な契約で許可されたトークンだけを出力することという、2つの相反する成功条件が生じます。小規模なローカルモデルは、両方を調整するよりも、より新しい指示や目立つ指示に従うことがあります。

このような失敗では、前置き、Markdownのコードフェンス、オブジェクトの後に続く説明、または文章による要求は満たしていても宣言された列挙値には違反する値が追加されることがよくあります。スキーマは有効でも、指示の優先順位が一貫していないのです。

切り捨てによって正しい計画が無効な出力になることがあります

入れ子になった配列やオブジェクトでは、すべての構造を閉じるために十分な生成トークンが必要です。トークン制限、停止文字列、キャンセルされたリクエスト、中断されたストリームによって、最後の区切り記号が届く前に応答が終了することがあります。

Transformersは、生成の終了タイミングを決める最大トークン数と停止制御を公開しています。

この根本原因は、特に大きな配列や長い文字列フィールドで、正しい途中までの出力が突然終わることで見分けられます。冒頭付近で型違反が繰り返される場合は別の原因を示しますが、出力上限付近で閉じ括弧が欠落しているなら、生成が不完全だったことを示しています。

バリデーターの意味論によって、モデルが同等と考えた値が拒否されることがあります

モデルが整数に対して"3"を出力したり、省略されたフィールドの代わりにnullを出力したり、小文字の列挙値を出力したり、アプリケーションが別の形式を想定するISO日付を出力したりすることがあります。

Pydanticは、欠落した値、無効なJSON、列挙値の不一致、禁止された追加フィールド、互換性のない型について、明確に区別された検証エラーのカテゴリを文書化しています。

すべての失敗が、解析可能ではあるものの拒否された値として同じフィールドに到達するなら、原因はランダムなスキーマ破損ではありません。型変換、厳格性、null許容、大文字と小文字の区別、またはアプリケーションレベルの形式について、認識が一致していないのです。

文法による制約は構文を維持できても、ビジネス上の意味までは保証しません

文法によって不正な括弧やキーを防げても、終了日が開始日より前である、存在しないファイルパスであるといった、意味的に不可能な組み合わせを許してしまうことがあります。

llama-cpp-pythonは推論制御として文法制約付き生成を提供しますが、文法が制御するのは許可されたトークン構造であり、外部の事実ではありません。

フィールド間のルールが原因のスキーマ失敗は、2段目の検証レイヤーで初めて現れることがあります。出力が構文的にも構造的にも有効であっても、ホームサーバーのワークフローでは利用できない場合があります。

後処理によって、本来は有効なモデル出力が壊れることがあります

アプリケーションは、Markdownの除去、最初の波括弧で囲まれたブロックの抽出、ストリーミングチャンクの結合、カンマの修復、検証前の値の変換などを行うことがあります。

ストリームチャンクが重複したり、Unicodeのデコードに失敗したり、エスケープシーケンスが削除されたり、修復関数が入れ子になった内容を編集したりすると、有効なモデル応答が無効になることがあります。逆に、修復処理によって、元のモデル出力が無効だった事実が隠されることもあります。

ZimaSpaceによる小規模なローカルモデルがJSON出力中に幻覚を起こす理由の解説は、関連する境界を示しています。スキーマへの適合性と事実の正確性は別々に測定する必要があり、アプリケーションで変換する前に生の応答を保持すべきです。

よくある質問

有効なJSONなら、出力がスキーマに一致していると証明できますか？

いいえ。JSONの解析で確認できるのは構文です。スキーマ検証では、必須プロパティ、型、列挙値、分岐、制限、その他の宣言された制約を別途確認します。

温度をゼロにすればスキーマ違反を防げますか？

いいえ。1つのデコード経路をより再現しやすくすることはできますが、未対応のスキーマ機能を追加したり、切り捨てを防いだり、競合する指示を解決したりすることはできません。

制約付きデコードによって、利用可能な自動化レコードを保証できますか？

いいえ。対応している構造上の制約は保証できますが、ビジネスルール、情報源との整合性、ファイルの存在、権限、フィールド間の一貫性については、引き続きアプリケーションによる検証が必要です。