有効な JSON だけでは十分ではありません: 構造化 LLM 出力を評価してください

最近の研究では、書式設定と意味が分離されています

2026 年 6 月のソフトウェア エンジニアリング プレプリントでは、生成された出力の構文、構造、およびセマンティックの欠陥を区別しています。 2026 年 8 月の調査では、スキーマ記述が分類動作にどのような影響を与えるかを調査しています。どちらも、構造化された出力の内容を評価し、プロンプトを使用してスキーマをバージョン管理する動機になります。どちらも普遍的な最適なスキーマ設計を確立しません。

証拠: ソフトウェアエンジニアリングのためのLLMにおける構造化出力制御の実証研究 [1]プロンプトは唯一のプロンプトではありません: LLM は構造化出力スキーマ記述をどの程度重視しますか? [2]

消費者が実際に必要とする契約書を作成する

Rubrex では、許可されるタイプ、必須フィールド、列挙、NULL 動作、およびクロスフィールド ルールを定義することをお勧めします。次に、値を入力にどのように固定する必要があるかを定義します。有効な日付が必ずしも正しい日付であるとは限りません。許可されたステータス コードであっても、証拠としては不適切である可能性があります。

不足している情報をどのように表現するかを指定します。すべてのフィールドが必須であるにもかかわらず、ソースに値が不足している場合、モデルは値を作成するよう圧力を受ける可能性があります。スキーマとアプリケーションでは、欠落、不明、適用不可、および抽出失敗を区別する必要があり、これらの状態は異なる意味を持ちます。

バリデータと意味論的な証拠を組み合わせる

構造要件にはパーサーとスキーマ検証ツールを使用します。可能な場合は、一貫した合計や有効な識別子の関係など、確定的なクロスフィールド チェックを追加します。抽出されたファクトについては、値を注釈付きのソース スパンまたは別の信頼できる参照と比較します。

フィールドごとの結果とすべての必須フィールドの正確性をレポートします。 9 つの正しいフィールドと 1 つの間違った支払い先を持つレコードは、90% 正確であるとだけ説明されても役に立ちません。エラーの重大度と下流への影響を読み取り値に保持します。

実例: 更新日の欠落

契約抽出者は更新日を返さなければなりませんが、文書には通知期間のみが指定されています。モデルは、スキーマを満たす妥当な日付を出力します。構造層が通過します。証拠根拠層は機能しません。

出力コントラクトを改訂して、必要に応じて明示的な不明状態を許可し、レビューに必要なソース証拠を含めます。明示的な更新日が記載されている文書と更新日が記載されていない文書の両方をテストします。修正により、抽出可能な情報を失うことなく、サポートされていない値が回避されるはずです。

プロンプトとスキーマの変更を 1 つのリリース サーフェスとして扱います

フィールドの説明にシステム命令との矛盾がないか確認してください。スキーマ、プロンプト、モデル、およびコンシューマを一緒にバージョン管理します。新旧のドキュメント テンプレート、ネストされたオブジェクト、空のコレクション、部分的な失敗をテストします。スキーマの移行には、既存のレコードとダウンストリーム コードが新しい状態を解釈する方法を含める必要があります。

よくある質問