llm-structured-output

LLM 構造化出力

後続のソフトウェアが確実に解析できる構造化出力のフローを構築します。

このスキルを使う場面

• モデルから JSON または型付きオブジェクトを出力する場合
• データ抽出パイプライン
• 関数またはツールの引数生成
• 後続の自動化に渡すプロンプトの契約
• 不正なモデル出力に対する検証と再試行の戦略

ワークフロー

1. 利用側から始める

• 後続のシステムが必要とする内容を正確に特定します
• 必須フィールド、任意フィールド、列挙値、制限を定義します
• スキーマはできるだけ小さく保ちます

2. 契約を明確にする

• 期待する構造をモデルに提示します
• フィールドの意味と制約を明確に伝えます
• 散文と JSON を混在させた形式より、決定性の高い形式を優先します
• 自由形式のフィールドには、型、長さ、または例による制約を設けます

3. すべてを検証する

• 厳密に解析します
• 正確性が重要な場合は、未知の形式や不正な形式を拒否します
• 列挙値、範囲、配列のサイズ、ネストされたオブジェクトを検証します
• 検証が完了するまで、構造化出力を信頼できない入力として扱います

4. 復旧手順を設計する

• 出力が惜しい場合は、検証エラーを添えて再試行します
• 元のスキーマが複雑すぎる場合は、より小さなスキーマに切り替えます
• 無効な出力を記録し、調査できるようにします
• モデルの誤りが隠れるような、暗黙的な型変換は避けます

5. 信頼性を高める

• 大きなタスクを、小さな構造化ステップに分割します
• 必要に応じて、推論と最終的な機械可読出力を分離します
• キーが安定し、曖昧さの少ないスキーマを優先します
• 実際に役立たない任意フィールドは削除します

ルール

• 利用側で必要とされない限り、JSON を Markdown のコードフェンスで囲むよう求めないでください
• 人間向けの説明を、機械向けのペイロードに混在させないでください
• 自然言語のカテゴリより列挙値を優先します
• エンコードされた文字列より、オブジェクトの配列を優先します
• null 許容は意図的に設定し、偶発的に許容しないでください

よくある失敗例

• タスクに対して広すぎるスキーマ
• モデルが推測できない必須フィールド
• 列挙値にすべき自由記述の値
• 例や制約のないネストされた出力
• 不正なデータを受け入れ、後続のパイプラインで問題を起こすパーサー

出力

このスキルを使用するときは、次の内容を作成します。

• 目標とするスキーマまたは形式
• 生成のためのプロンプト契約
• 検証と再試行の計画
• 信頼性に関するリスクやエッジケース