大規模言語モデル（LLM)は強力で多才ですが、予測不可能で潜在的に危険でもあります。これによって堅牢なLLMアプリケーションの展開が困難になっています。本ブログ記事では、LLMの出力にフォーマットの制約を課すことで「手なずける」ことを可能にする、構造化テキスト生成の概念を紹介します。具体的には、以下の内容を取り上げます：

構造化テキスト生成技術で扱える主なフォーマット制約の種類を列挙します
構造化テキスト生成の利点を説明します
構造化テキスト生成方法の概要を提供します
オープンまたはプロプライエタリなモデルで利用可能な一般的な機能を紹介します
様々な落とし穴とそれを回避する実用的な方法を説明します

可能な制約のスペクトラム

構造化テキスト生成の方法は、4つの主要なカテゴリのフォーマット制約に利用できます。最も簡単なのは、LLMの出力を事前定義されたオプションのセットに制限することです。例えば、LLMを判定者として使う場合、1から5までのスコアを生成したいとします。この場合、期待される回答は「1」、「2」、「3」、「4」、「5」の5つだけです。

より一般的な制約は、正規表現を通じて表現できます。最も典型的な例は、特定のJSONスキーマに従うJSONオブジェクトの生成です。例えば、オンラインレビューの感情分析を行う場合、期待されるLLMの応答は2つのプロパティを持つJSONオブジェクトかもしれません：「sentiment」（「positive」、「negative」、「neutral」の3つの可能な値を持つ文字列）と「themes」（文字列のリスト）です。

さらに広い制約のファミリーは形式文法に基づいており、LLMを通じて構文的に正しいコンピューターコードを取得したい場合に特に興味深いものです。

最後に、フォーマット制約はテンプレートの形を取ることができます。これは、LLMによって埋められるべきプレースホルダーを持つ動的な穴埋めテキストです。

LLMのフォーマット制約の4つの重なるカテゴリ

これらの制約のいずれかを適用することで、様々な利点が得られます：

有効性の保証：テキスト分類や重要情報の抽出などの特定のタスクでは、フォーマット制約によって回答が有効であることが保証されます。要求されたすべてのフィールドが存在し、許可された値のみを取り、予期しないフィールドが追加されていないことが確認できます。例えば、マルチモーダルLLMでスキャンした請求書から特定のフィールドを抽出する場合、会社名、合計金額、請求書の日付を必ず取得したいとします。この場合、これらの情報の一部が欠けていると回答は無効となります。有効なフォーマットでも、応答内の値が依然として正しくない可能性があることに注意してください。
パースが容易：LLMの出力には、ユーザーインターフェースやダウンストリームアプリケーションに取り込むために分離する必要がある複数の部分が含まれることがよくあります。JSON、XML、YAMLなどのデータシリアライゼーションフォーマットに従ってテキストを生成できると、このプロセスがはるかに簡単で信頼性の高いものになります。
推論の強化：構造要件を追加することで、より関連性の高い応答が得られることもあります。最も簡単な例はチェーン・オブ・ソート（思考の連鎖）法で、LLMに最終回答の前に正当性の確認を提供するよう促すものです。これによって応答が理解しやすくチェックしやすくなるだけでなく、このアプローチが応答の精度を向上させることが経験的に示されています。

プロンプトエンジニアリングとファインチューニング

LLM開発者は、フォーマット制約を課すためのツールボックスを持っています。最も簡単なアプローチはプロンプトエンジニアリングに依存します。これは、プロンプト内で望ましいフォーマットを明示的に指定したり、例を提供したりすることを含みます。例えば、「JSON形式で回答してください」と書くことや、完全なJSONスキーマを提供することができます

回答に特定のJSONスキーマを指定するシンプルなプロンプトの例

実装は容易ですが、この方法ではフォーマットエラーが多いことがよくあります。さらに、プロンプトに指示を追加するとその長さが増し、コストが高くなり応答時間が長くなります。

フォーマット制約をより厳密に遵守するためには、教師ありファインチューニングに目を向けることができます。これは、事前学習済みのLLMをフォーマットが適切な例のデータセットでさらに訓練することを含みます。この方法は高いレベルのコンプライアンスを実現しますが、プロンプトサイズを増やすことはありません。さらに、より小さく効率的なLLMモデルを使用でき、コストとレイテンシーをさらに削減できます。しかし、ファインチューニングにはかなりの初期労力が必要です。専門知識、ベースとなるLLM、適切に準備された訓練データセット、コンピューティングリソース（またはAPIベースのLLMプロバイダーが提供するファインチューニング機能）が必要です。訓練プロセス自体に数時間かかることがあり、LLMが使用可能になるまで時間がかかります。

ファインチューニングは、コンプライアンスと精度（およびより小さなモデルを使用する場合は効率）を向上させることができます。実践的な例については、Dataiku LLMスターターキットのファインチューニング例をご覧ください

ファインチューニングの特別で高度なケースは、ファンクションコーリング（関数呼び出し）です。一部のLLM（GPT-4oやいくつかのオープンウェイトモデルなどの最も有名なプロプライエタリLLMを含む）は、関数を呼び出すように特別に訓練されており、開発者がその能力を拡張できます。例えば、LLMにある都市の現在の天気を提供させたいとします。LLM自体はリアルタイムの天気データにアクセスできませんが、その機能を持つ関数を定義できます。この関数に関する記載をプロンプトに含めることで、LLMはいつこの関数を呼び出すか、正しいJSON形式で必要な入力を提供する方法を認識するように訓練できます。

この機能は通常、関数を実行し、その結果をLLMにフィードバックするために使用されますが、フォーマット制約を強制するために巧みに再利用できます。実際の関数の代わりに、実行されることのないダミー関数を定義し、一方入力パラメータは求めるフォーマットで正確に構造化して定義します。LLMがこの関数を「呼び出す」と、制約に完全に一致するJSONオブジェクトを生成します。このアプローチは、トレーニングデータを必要とせずに高いコンプライアンスを達成しますが、LLMが関数呼び出し用に特別にファインチューニングされている必要があり、フォーマットエラーは依然として起こりうるものの、はるかに可能性が低くなります。

制約付きデコーディング

最も強力な構造化テキスト生成アプローチは、制約付きデコーディングであり、複雑な制約でも100％のコンプライアンスを保証します。これは、テキスト生成プロセス中に適合しないトークンをマスキングすることで動作します。

例えば、LLMに1から5のスケールでスコアを生成するようにプロンプトしたとします。標準的なアプローチでは、プロンプトはトークンのシーケンスに変換されます。これらのトークンはLLMによって取り込まれ、次に生成される可能性のある各トークンの確率を提供するベクトルを返します。次のトークンはこの確率分布をサンプリングすることで得られます。おそらく「1」、「2」、「3」、「4」、または「5」になるでしょうが、これは保証されません。

制約付きデコーディングでは、この制約と適合する各トークン（この例では「1」、「2」、「3」、「4」、「5」）に1を割り当て、他のすべてのトークンに0を割り当てるマスクベクトルを自動的に構築します。確率ベクトルとマスクベクトルを項ごとに乗算し、結果のベクトルを正規化すると、新しい確率分布が得られます。元の確率分布の代わりにこの確率分布でサンプリングすることで、制約を必ず守る次のトークンが得られます。

制約に適合しないトークンをマスクすることで、次のトークンを予測する確率分布を100％のコンプライアンスを確保して得ることができます。

上記の例は、制約がいくつかの潜在的な選択肢に限定され、かつそれぞれの選択肢が単一のトークンに対応しているため、簡単です。幸いなことに、トークンマッチングアプローチは、上記で列挙したすべての制約カテゴリに一般化できます。例えば、正規表現に基づく制約では、正規表現に対応する決定性有限オートマトンを構築し、それを調整して文字ではなくトークンで動作させ、既に生成されたトークンを追跡し、制約によって許可される次のトークンを決定するために使用できます。

正規表現制約の場合、トークンマスクは決定性有限オートマトンで効率的に計算できます。このオートマトンは、既に生成されたすべてのトークンを考慮して、制約と適合するすべてのトークンを直接提供します（「Automata-based constraints for language model decoding」を参照）

全体として、制約付きデコーディングは完全なコンプライアンスを保証し、トレーニングデータを必要とせず、非制約デコーディングと比較してテキスト生成を高速化することさえできます。初期のオーバーヘッド（例えば、正規表現の場合はオートマトンを構築するなど）を導入しますが、ほとんどのユースケースでは無視できる程度です。制約付きデコーディングの欠点は、プロプライエタリなAPIベースのLLMの場合、提供者がこの機能を提供していない限り、使用できないことです。また、制約付きデコーディングにはいくつかの以下で説明する落とし穴があります。

実践における構造化テキスト生成

実際にオープンソースのパッケージやプロプライエタリなLLM APIの機能を通じて利用可能な最も人気のある構造化テキスト生成技術は次のとおりです：

Structured Output（構造化出力）は特定のJSONスキーマと100％のコンプライアンスを持つ制約付きデコーディングに対応します。具体的なユースケースで最も有用な技術です。
ファンクションコーリング（関数呼び出し）はJSONスキーマを使用しますが、完全なコンプライアンスを保証しません。
JSONモードは有効なJSON出力を保証する制約付きデコーディングの一形態です（ただし、特定のJSONスキーマは指定できません）。

これらの機能は非常にシンプルで便利ですが、潜在的な落とし穴を見過ごすのは簡単です。制約付きデコーディングでのトラブルの主な原因は、次のトークンの確率（トークンマスキングの前の計算）が制約に依存しないという事実です。ある意味で、LLMは制約を「認識していない」のです。

制約が回答に与える影響の例

上記の最初の例では、LLMに「ゲーム・オブ・スローンズ」の第2シーズンでの王の手は誰かを尋ねます。制約なしでは、LLMは「王の手」という言葉で始まり、正しい答えである「ティリオン」を含む段落を書く可能性が高いです。しかし、潜在的な選択肢を「ティリオン」または「シオン」に制限すると、回答は誤って「シオン」になります。制限なしの応答ではLLMが正しい答えを「知っている」ことを示唆していたで、これは奇妙に思えるかもしれません。しかし、この動作は実際には制約付きデコーディングの動作方法から説明可能です。

「The」は一般的な最初のトークンであり、「The」は制約と適合するため（「The」は「Theon」の接頭辞であるため）、トークンマスクによって検閲されず、再び最初のトークンとして選択される可能性が高くなります。しかし、その後、「Theon」は制約と適合する唯一の許可された回答になります。制約を強制することで、この特定の名前が一般的な英単語を接頭辞として持っているため、意図せずに「シオン」の確率を高めてしまいました。

2番目の例では、日付を取得するために制約を追加すると、最初のトークンとして「1」が選択される可能性があります。この最初のトークンは、「DD/MM/YYYY」または「MM/DD/YYYY」フォーマットのどちらでも互換性があるため、いずれの制約でもマスクされません。そして、LLMは「14」で始まる可能性の高い回答を持っているため、「1」に高い確率を割り当てます。しかし、「MM/DD/YYYY」フォーマットでは、2番目のトークンとしては「0」、「1」、または「2」のみが許可されているため、この時点で正しい回答を生成することが不可能になってしまいます。

3番目の例でも、意図せずにLLMを失敗に導いています。トークンは一つずつ生成され、LLMは次のトークンの確率を計算する際に制約を考慮しないため、「Absolutely」を生成する確率は、制約が「『Absolutely not』または『Definitely』のいずれか」であるか「『Absolutely』または『Definitely not』のいずれか」であるかに依存しません。最初のトークンが生成されると、選択の余地はなくなり、「Absolutely」を最初のトークンとして選択すると、制約によって異なる2つの反対の回答につながります。

この問題の最善の対策は、制約付きデコーディングを活用する場合でも、プロンプトで制約を指定することです。これにより、無制約と制約付きの場合の次のトークン確率分布のギャップが縮まり、回答がLLMの内部知識を反映する可能性が高まります。

他のいくつかの落とし穴とそれに関連する緩和策は次のとおりです：

品質への悪影響：逸話的な証拠では、制約を課すことで、論理的推論や数学的問題解決を含むタスクでLLMの出力の品質が低下することがあると示唆されています。これが発生し、プロンプトエンジニアリングや制約の調整で解決できない場合、タスクを2つの部分に分解するのが良いアプローチです。最初のステップでは、フォーマット制約なしで回答を生成し、2番目のステップで、この回答を適切にフォーマットされた応答に変換します。
フィードバックが遮断：フォーマット制約により、LLMが重要な情報を伝えることを妨げる可能性があります。制約がなければ、LLMは回答の限界やなぜ回答しないかを説明するかもしれません。例えば、LLMはその回答の制限がトレーニングコーパスのカットオフ日によるものであることから、回答を控えるかもしれません。これらの有用な情報は、フォーマット制約を課すことで隠される可能性があります。奇妙な動作が観察された場合、問題を診断し解決するために一時的に制約をオフにし、その後制約を再度有効にすることが有用です。
JSONキー値ペアの順序の影響：JSONオブジェクトのキー値ペアの順序は、データの観点からは無関係ですが、LLMはこの順序に敏感になる可能性があります。これは、生成プロセスが逐次的に展開し、出力の初期部分が後の部分に影響を与える可能性があるためです。したがって、LLMの推論プロセス（例えば、回答の正当性確認）に対応する内容が、結果の推論プロセスに対応する内容の前に生成されるように、JSONオブジェクトを構成することをお勧めします。
JSONスキーマサポートの制限：さまざまな制約付きデコーディングの実装は、JSONスキーマ仕様のすべての機能をサポートしていません。例えば、OpenAI APIのStructured Output（構造化出力）機能はオプションのフィールドを許可していません。特にJSONスキーマが複雑な場合、関連するドキュメントを参照して予期せぬ挙動を避けることが重要です。
ファインチューニングの過小評価：制約付きデコーディングが既にコンプライアンスを保証している一方で、ファインチューニングは依然として価値のあるツールです。上記の最初の落とし穴に関して、ファインチューニングは、プロンプトを長くすることなく、モデルの制約なし出力と制約付き出力の動作の不一致を減らす方法となり得ます。また、LLMがターゲットフォーマットの意味の微妙さを理解するのにも役立ちます。例えば、3つの潜在的なクラス（「positive」、「neutral」、「negative」）を持つ感情分析タスクの場合、制約付きデコーディングはこれらの応答のみが生成されることを保証するのに十分ですが、LLMが「neutral」と「positive」または「neutral」と「negative」の間のやや主観的で任意の区別を把握することはできません。

結論

構造化テキスト生成はもはや選択肢ではなく、堅牢で信頼性の高いLLMアプリケーションを構築する上での基盤です。

特に、制約付きデコーディング技術は100％のコンプライアンスを保証します。強力でシンプルな実装が、オープンウェイトLLMとプロプライエタリなAPIベースのLLMの両方で利用可能です。制約付きデコーディングはいくつかのリスクを生み出しますが、開発者はこれらの技術の基本を理解していれば、適切に管理できます。

Dataikuは、LLMの強力で予測不可能な性質を安全かつ正確に制御することで、実践者を支援します。Dataikuは、トップクラスのLLMサービスとセルフホスト型モデルの両方へのシームレスなアクセスを提供し、ファンクションコーリング、JSONモード、そして近日中には構造化出力などのツールを提供します。オープンソースツールや最新のAPIを活用するかに関わらず、これらの機能により、LLMの可能性をエンタープライズグレードのアプリケーション向けの構造化された影響力のあるコンテンツに変えることができます。

私たちのウェビナー「100％適切にフォーマットされたLLM応答を取得する方法」で、構造化テキスト生成の必須事項をより深く掘り下げ、現実世界のアプリケーション向けにLLMの出力を制御および最適化する方法を直接学びましょう。

構造化テキスト生成の必須事項をより深く掘り下げる

Dataikuのウェビナー「100％適切にフォーマットされたLLM応答を取得する方法」で、現実世界のアプリケーション向けにLLMの出力を制御および最適化する方法を直接学びましょう。

→GenAIブートキャンプエピソードを見る

原文:Taming LLM Outputs: Your Guide to Structured Text Generation