Constrained Decoding

制約付きデコーディングは、各ステップで言語モデルが生成できるトークンを制限するテキスト生成の手法です。これにより、完成した出力が、固定されたラベルの集合、正規表現、文法、JSON Schemaのいずれかという、指定された形式に必ず一致します。モデルは引き続き、語彙に含まれるすべてのトークンをスコアリングします。トークンを選ぶ前に、デコーダーは形式を崩す選択肢をすべて除外します。APIバックエンド、AIエージェント、データ抽出パイプラインなど、モデル出力をパースするアプリケーションでは、すべての応答を初回からパースできるように制約付きデコーディングを使用します。

無効なトークンのマスキング#

大規模言語モデルは、トークンを1つずつ生成します。各ステップで、語彙内の各トークンに対するスコア（ロジット）を出力し、softmaxがそれらのスコアを確率に変換します。制約付きデコーディングでは、サンプリングの前に1つの処理を追加します。有効な出力につながらないトークンのロジットを負の無限大に設定して確率をゼロにし、残りの確率を有効なトークン間で再正規化します。

import torch

# Raw next-token scores from a model over a toy vocabulary
vocab = ["approved", "rejected", "review", "maybe", "{", "}"]
logits = torch.tensor([1.2, 0.4, 0.9, 2.5, 0.1, 0.3])

# The schema allows only the three status labels at this position
allowed = torch.tensor([True, True, True, False, False, False])
masked_logits = logits.masked_fill(~allowed, float("-inf"))

# Softmax renormalizes probability over the valid tokens only
for name, raw, masked in zip(vocab, logits.softmax(-1), masked_logits.softmax(-1)):
    print(f"{name:>9}: {raw:.2f} -> {masked:.2f}")

制約を適用しないモデルは、「maybe」に確率の56%を割り当てます。マスクを適用すると、「maybe」の確率はゼロになり、許可された3つのラベルが元のスコアに比例して確率を分け合うため、「approved」の確率は15%から46%に上がります。

本番環境の推論エンジンは、生成の進行に合わせて制約状態を追跡します。固定された選択肢のリストや正規表現は、有限状態機械にコンパイルされます。JSONなどの入れ子構造を持つ形式ではスタックを備えた文法が必要です。閉じ波括弧が有効なのは、対応する開き波括弧の後だけだからです。トークンごとにデコーダーは状態を進め、許可されるトークンの集合を再計算します。トークン化では長さの異なるサブワードが生成されるため、"},のような1つのトークンが複数の文法ステップを一度に担うことがあります。そのため、ライブラリは各状態で有効な語彙項目を事前計算し、語彙が10万トークンを超えてもトークンごとのコストを小さく保ちます。Brandon WillardとRémi Loufは2023年に、正規表現と文脈自由文法に対するこのインデックス手法を大規模言語モデルのための効率的なガイド付き生成で説明しました。この論文はOutlinesライブラリの基礎となっています。

制約の選び方#

適切な制約は、アプリケーションが実際に利用する出力に一致します。選択肢リストは、回答を少数の文字列のいずれかに限定する分類やルーティングに適しています。正規表現は、日付、ID、電話番号など、短い構造化値を扱えます。文脈自由文法は、SQL、コード、ドメイン固有言語を記述します。llama.cppのGBNF文法形式は、広く使われている例です。名前付きフィールドを持つレコードには、JSON Schemaを使って必須キー、型、列挙値、入れ子構造を指定します。OpenAI Structured Outputsなどのホスト型APIはスキーマを受け取り、通常はJSON Schema仕様全体のうち、文書化されたサブセットをサポートしながら生成中に適用します。

制約付きデコーディングは、関連する次の手法と混同されることがよくあります。

• 構造化出力: 機械可読な応答を実現するという、より広い目標です。生成時の制約付きデコーディング、または生成後に出力を検証して失敗時に再試行する方法で実現します。
• JSONモード: どのような構造でも構文的に有効なJSONになるよう出力を制約しますが、キー、型、値の検証は引き続き必要です。
• プロンプトエンジニアリング: 指示文で形式を指定します。モデルはほとんどの場合その指示に従います。スキーマで制約するリクエストでも、通常はプロンプト内でフィールドを説明し、各フィールドの意味をモデルに伝えます。
• 関数呼び出し: 呼び出し側のコードが正確なフィールド名を必要とするため、ツール名と引数はスキーマ制約の対象として特によく使われます。

実運用でのトレードオフ#

形式を保証しても、内容まで保証されるわけではありません。スキーマで{"total": 1290.00}を数値に限定できても、その数値が正しいとは限りません。また、制約付きモデルは有効なフィールド内で流暢にハルシネーションを起こすことがあります。アプリケーションでは、生成後もビジネスルールを検証する必要があります。

制約によってモデルが自然に生成する文章から遠ざかると、回答品質が低下することもあります。最終回答を最初のフィールドに要求するスキーマでは、中間推論を行う余地がありません。そのため、スキーマでは自由記述の推論フィールドやメモ用フィールドを回答フィールドより前に置くことがよくあります。出力長にも注意が必要です。オブジェクトの途中でトークン上限に達すると、制約の有無にかかわらず結果は無効になるため、構造全体を生成できる余裕を持たせた最大長を構造化リクエストで設定します。非常に大きいスキーマや再帰が深いスキーマはコンパイルに時間がかかるため、リクエストごとに新しいスキーマを構築するシステムでは重要です。

マルチモーダルモデルが画像に関するフィールドを返す必要がある場合、ビジョンアプリケーションでも同じ仕組みを使います。Ultralytics LLMインターフェースはリクエスト引数を変更せずにOpenAI互換APIへ転送するため、画像リクエストに渡したJSON Schemaで、ビジョン言語モデルの回答をhazardやseverityなどのフィールドに制限できます。同じフレームから得たYOLO26の検出結果とすぐに組み合わせられます。