Constrained Decoding
制約付きデコードが、有効なJSON、スキーマ、文法、ツール出力を強制し、AIの応答をより安全で構造化されたものにし、ソフトウェアで解析しやすくする方法について学びます。
制約付きデコードとは、生成モデルが各トークンを生成する際に、有効な出力のみに制限する推論手法です。モデルがボキャブラリー全体から選択できるようにするのではなく、デコーダーは、許可されたラベルのリスト、正規表現、文法、JSON Schemaなどのルールに違反する選択肢を排除します。これにより、特にAIシステムが構造化データを返したり許可されたアクションを選択したりする必要がある場合、モデルの応答をソフトウェアでより簡単かつ安全に解析できるようになります。
制約付きデコードの仕組み#
自己回帰言語モデルは、シーケンスを1回に1トークンずつ生成します。各ステップで、次に続く可能性のあるトークンにロジットと呼ばれるスコアを割り当て、通常はsoftmaxを使用して確率に変換します。制約付きデコードでは、追加のフィルタリングステップが挿入されます。
- すでに生成された出力の部分を追跡します。
- 制約のもとで、次にどのトークンが有効であるかを決定します。
- 無効なトークンの確率がゼロになるようにマスクします。
- 残りの有効なトークンから選択またはサンプリングします。
- 制約の状態を更新し、繰り返します。
有効なセットは動的に変化します。たとえば、{"status": "の生成後、スキーマは"approved"、"rejected"、または"review"を完了できるトークンのみを許可する場合があります。vLLM structured outputsを提供するエンジンは、選択肢、正規表現、文法、JSONスキーマを強制できますが、Outlines JSON generationはスキーマまたは型付きPythonモデルから制約を導出できます。
グラフ制約デコードは、有効なシーケンスをグラフまたはステートマシンを通じたパスとして表現する実装を説明します。生成された各トークンによってデコーダーが別の状態に移行し、その状態の出力エッジが次の有効な選択肢を定義します。このアプローチは、文法、エンティティ関係、およびその他の状態依存のルールに役立ちます。
関連概念と主な違い#
制約付きデコードはいくつかのAI概念と密接に関連していますが、これらは互換性がありません。
- Structured outputs: 必須フィールドやデータ型を持つオブジェクトなどの望ましい結果。制約付きデコードは、その結果を生成するために使用されるメカニズムの1つです。OpenAI Structured Outputs、Claude structured outputs、Gemini structured outputsなどのサービスは、スキーマベースの制御を提供します。
- JSONモード: 通常、有効なJSON構文を保証しますが、特定のキー、型、または許可された値を強制しない場合があります。スキーマ制約付きデコードは、特定の構造をターゲットにします。
- Function calling and tool use: モデルが外部操作を要求する方法を定義します。制約付きデコードは有効な関数名と引数の形状を強制できますが、アプリケーションは引き続きそのツールを実行および承認します。
- Prompt engineering: 指示を通じてフォーマットに従うようにモデルに求めます。動作に影響を与えますが、無効なトークンを機械的に排除することはありません。
- Speculative decoding: トークンの提案と検証によって生成を加速します。その主な目的は速度である一方、制約付きデコードは妥当性を制御します。
型付きシステムは、すべてのルールを手動で記述する代わりに、Pydantic JSON Schemaなどのツールを通じてスキーマを定義できます。
実世界での利用例#
ドキュメント処理: 請求書処理システムは、スキャンされたドキュメントからvendor、invoice_number、total、currencyを抽出する場合があります。制約付きデコードにより、会計ソフトウェアに入る前に、応答に期待されるキーとデータ型が含まれていることが保証されます。抽出された合計が事実上正しいことを保証することはできませんが、不正なペイロードを防ぎます。
ビジョン駆動型安全自動化: システムはUltralytics YOLO26を使用して作業者と保護具を検出し、関連する観測結果を言語モデルに送信できます。デコーダーは、モデルの決定をno_action、manual_review、またはsend_alertに制限する場合があります。Ultralytics Platform Agents workflowでは、ビジョンモデル、条件、言語モデル、およびアクションを接続できるため、適格な画像のみが後続のステップに進むことができます。
実践的なワークフロー例#
コンピュータビジョンの予測は、トークンごとに生成されるのではなく、すでに構造化されています。次のYOLO Predict modeワークフローは、後続の制約付き言語モデルの決定への入力となり得るJSONを生成します。
from ultralytics import YOLO
# Load the recommended object detection model
model = YOLO("yolo26n.pt")
# Run inference and select the first result
results = model("https://ultralytics.com/images/bus.jpg")
result = results[0]
# Serialize detections for a downstream constrained decoder
json_output = result.to_json()
print(json_output)ここで、to_json()は制約付きデコードではなく、決定的シリアル化を実行します。生成モデルがこれらの検出結果をスキーマ制限されたレポートまたはアクションに変換した場合、制約付きステップは後で発生します。
利点、制限、およびベストプラクティス#
制約付きデコードにより、解析の失敗、再試行、予期しないフィールド、および無効なツール引数が削減されます。ただし、構造的な妥当性によってLLM hallucinationsがなくなるわけではありません。完全に形成された応答であっても、誤った事実や不適切なアクションが含まれている可能性があります。
情報が利用できない可能性がある場合は、狭いスキーマ、意味のあるフィールド説明、閉じられた選択肢に対する列挙型、およびNULL許容フィールドを使用してください。生成後にビジネスルールを検証し、拒否や切り捨てられた応答を処理し、各プロバイダーがサポートするスキーマサブセットをテストします。本番環境では、フォーマットの準拠だけでなく、スキーマコンパイルのオーバーヘッド、デコードのレイテンシ、およびセマンティックな精度も測定してください。









