API に Structured Outputs を導入

昨年、当社は DevDay において JSON モード — 当社モデルを使用して信頼性の高いアプリケーションの構築を企図される開発者の方に有用な構成要素 — を発表しました。JSON モードは有効な JSON 出力生成のためのモデルの信頼性を向上させますが、モデルの応答が特定のスキーマに準拠することを保証するものではありません。本日、API に導入される Structured Outputs について発表いたします。この新機能は、モデル生成の出力を開発者の方が指定した JSON スキーマと完全に一致させるために設計されています。

非構造化入力から構造化データを生成することは、現在の AI アプリケーションにおけるコアユースケースの1つです。開発者の方は、OpenAI API を用い、Function Calling⁠（新しいウィンドウで開く） 機能を介してデータを取得し、質問に解答する能力を有する強力なアシスタントを構築します。この機能は、データ入力用の構造化データを抽出し、LLM がアクションを実行できるようにする複数ステップのエージェントワークフローを構築します。長年の間、開発者の方はこの分野の LLM にある制限に対して、モデルの出力をシステムとの相互運用に必要な形式と一致させるためにオープンソースツール利用、プロンプト、リクエスト再試行を繰り返すという調整措置をとってきました。Structured Outputs は、開発者の方が指定したスキーマと一致するように OpenAI モデルを制約すること、および複雑なスキーマをより良く理解するように当社モデルに学習させることで、この問題を解決しました。

複雑な JSON スキーマに対する準拠率を当社が評価したところ、Structured Outputs を導入した当社新モデル gpt-4o-2024-08-06 は完璧な100％というスコアを出しました。これと比較して、gpt-4-0613 のスコアは40％未満です。

Structured Outputs を用いた gpt-4o-2024-08-06 は当社評価においてスキーマに完全に準拠した出力である100％の信頼性を出しました。

Structured Outputs は以下の2形体で API に導入されました。 

1.Function Calling（関数呼び出し）：Structured Outputs は、ツール経由での機能定義内で strict: true を設定することで利用できます。この機能は、ツールをサポートする gpt-4-0613、gpt-3.5-turbo-0613 以降のすべてのモデルで動作します。Structured Outputs が有効化されている場合、指定されたツール定義と一致したモデル出力となります。

2.response_format パラメーターの新しいオプション：開発者の方は、json_schema という response_format パラメーターの新オプションを介して JSON スキーマを指定できるようになりました。これは、モデルがツールを呼び出すのではなく、構造化された方法でユーザーに応答する場合に有用です。この機能は、本日リリースの GPT‑4o 最新モデル gpt-4o-2024-08-06 および gpt-4o-mini-2024-07-18 で動作します。response_format が strict: true と共に指定されると、指定されたスキーマと一致したモデル出力となります。

安全性は OpenAI の最優先事項です。この新機能 Structured Outputs は、当社既存の安全ポリシーを遵守し、安全でないリクエストをモデルが拒否するようにもしています。開発を簡易化するため、API 応答に新たに refusal（拒否）文字列値が追加されました。これにより開発者の方は、モデルがスキーマに一致する出力の代わりに拒否を生成したかをプログラム的に検出できます。応答に拒否が含まれておらず、モデルの応答が途中で中断（finish_reason で表示）されていない場合には、モデルの応答では指定されたスキーマに一致する有効な JSON が確実に生成されます。

OpenAI の Python と Node SDK は、Structured Outputs のネイティブサポートのためにアップデートされました。ツールまたは応答形式としてのスキーマの指定は、Pydantic または Zod のオブジェクトを指定するだけという簡単なことです。SDK は、サポートされている JSON スキーマへのデータ型の変換、JSON 応答の型付きデータ構造への自動的逆シリアル化、および拒否が発生した場合の構文解析を処理します。

Function Calling による Structured Outputs のネイティブサポートの例を下に示します。

Structured Outputs のネイティブサポートは response_format でも利用可能です。

開発者の方には、様々なユースケースにおいて構造化データの生成のために OpenAI のモデルをよくご利用いただいています。その他のユースケースの例：

コードまたは UI を生成するアプリケーションを作成するための Structured Outputs の利用などです。以下の例は、すべて同じ response_format を用いており、ユーザーの入力に基づいて様々な UI の生成が可能になっています。

思考の連鎖のための別のフィールドをモデルに与えると、最終的解答の質の向上に役立ちます。

会議メモから ToDo リスト、期限、割り当てなどを抽出するためのモデルへの指示などです。

JSON スキーマに一致するようモデル出力の信頼性を向上させるために、2パートから成るアプローチをとりました。まず、当社最新モデルの gpt-4o-2024-08-06 に複雑なスキーマの理解と、それに一致する出力生成のために最適な方法を学習させました。しかし、モデルの挙動は本質的に非決定論的なものでした。モデルのパフォーマンスは向上しました（当社ベンチマークで93％でした）が、ロバストなアプリケーション構築のために開発者の方が必要とする信頼性を満たすものではありませんでした。そこで、モデルの出力に制約を加えて100%の信頼性を達成するために、エンジニアリングベースの決定論的アプローチも用いることにしました。

当社がとったアプローチは、制約付きサンプリングや制約付きデコードと呼ばれる技術に基づくものです。デフォルトでは、出力生成のためにサンプリングを行う場合にモデルには全く制約がなく、次の出力として語彙から任意のトークンを選択できます。この柔軟性のために、モデルは間違いを犯しやすくなってしまいます。例えば、有効な JSON が生成されない場合であっても、通常では中括弧トークンを自由にサンプリングしてしまうのです。有効な出力を確保するために、利用可能なすべてのトークンではなく、指定されたスキーマに基づいて有効となるトークンのみをサンプリングするようにモデルに制約を与えました。

モデルの出力の全体においてでは有効となるトークンが異なってくるため、実際にこの制約を実装するのは難しい場合があります。例として、以下のスキーマを見てみましょう。

この出力の始めでは、{、{“、{
などが有効なトークンとなっています。しかし、モデルが{“valをサンプリングした後には、{は有効なトークンではなくなってしまいます。そこで、動的な制約付きデコードを実装し、予め応答の開始時に判断しておくのではなく、各トークンの生成後にそれが有効であるかを判断する必要があります。

これを行うため、指定の JSON スキーマを文脈自由文法（CFG）に変換しました。文法とは言語を定義する一連の規則であり、文脈自由文法は特定の規則に従う文法です。JSON および JSON スキーマは、言語内で有効なものを定義する規則を持つ文法と考えることができます。英語において動詞がないと文として成り立たない（有効でない）ように、JSON においては末尾にコンマがあることは有効ではありません。

そのため各々の JSON スキーマに対して、それを規定する文法を計算して、モデルのサンプリング中に簡単にアクセスできるようにコンポーネントを前処理します。これが、新しいスキーマを使用した最初のリクエストで遅延ペナルティが発生する理由です。サンプリング中に効率的に使用できるアーティファクトを生成するためには、スキーマを前処理しなければなりません。

サンプリング中、当社の推論エンジンは以前に生成されたトークンおよび文法内の規則（次に有効なトークンを規定）に基づいて、各トークンの生成後に、それが有効であるかを判断します。次に、このトークンのリストを使用して次のサンプリングステップをマスクします。これにより無効なトークンの生成率が結果的に下がって、0になります。スキーマを前処理しているため、キャッシュされたデータ構造を使用したマスキングが効率的に実行可能となり、遅延オーバーヘッドを最小限に抑えられます。

この問題に対する代替アプローチでは、制約付きデコードのために有限状態機械（FSM）や Regex（通常、FSM に実装）がよく用いられます。これらのアプローチは、各トークンの生成後にそのトークンの有効性を動的に更新するという点では同様に機能しますが、CFG アプローチとはいくつか重要な違いがあります。とりわけ、CFG は FSM よりも幅広いクラスの言語を表現できることが挙げられます。実際に、これは上述の value スキーマのようなごく単純なスキーマでは問題となりません。しかし、ネストされたデータ構造や再帰的データ構造などのもっと複雑なスキーマにおいては、この違いが意味を持ちます。例えば、通常、FSM は再帰的データ構造を表現できないため、FSM ベースのアプローチでは深くネストされた JSON の括弧を一致させるのが難しい場合があります。下記は、Structured Outputs が導入された OpenAI API ではサポートされているけれども、FSM では表現できない再帰的スキーマの例です。

なお、各 UI 要素には、ルートスキーマを再帰的に参照する任意の子要素を含めることができます。CFG アプローチが可能にするものが、この柔軟性なのです。

Structured Outputs をご利用いただく際は、以下の制限事項にご留意ください。

• Structured Outputs は、当社ドキュメント⁠（新しいウィンドウで開く）に説明されている JSON スキーマのサブセットに対して利用した場合にのみ、可能な限り最高のパフォーマンスが確保されます。
• 新しいスキーマを使用した際の API の最初の応答には追加の遅延が発生しますが、その後は遅延ペナルティのない高速な応答になります。これは、上述のように最初のリクエスト中にスキーマを処理して、後で高速に再利用できるようにアーティファクトがキャッシュされるためです。最初のリクエストにおける処理時間は、一般的なスキーマでは10秒未満ですが、より複雑なスキーマでは最大1分となる場合があります。
• 安全でないリクエストに対してモデルが拒否を選択した場合には、モデルがスキーマに従わないことがあり得ます。拒否が選択された場合、それを示す refusal ブール値が true に設定された返答メッセージとなります。 
• 生成が完了する前に max_tokens などの停止条件に達した場合には、モデルがスキーマに従わないことがあり得ます。 
• Structured Outputs は、モデルのすべてのタイプの間違いを防げるわけではありません。例えば、JSON オブジェクトの値において間違いを犯す（数学の方程式でステップを間違えるなど）可能性が依然としてあります。間違いが見つかった場合、システムの指示に例を提供するか、より単純なサブタスクにタスクを分割することが開発者の方には推奨されます。
• Structured Outputs は、並列関数呼び出しとは互換性がありません。並列関数呼び出しが生成されると、指定されたスキーマと一致しない可能性があります。並列関数呼び出しを無効にするには、parallel_tool_calls: false を設定してください。
• Structured Outputs で指定された JSON スキーマはゼロデータ保持⁠（新しいウィンドウで開く）（ZDR）の対象ではありません。

現在、Structured Outputs は API で公開されており、利用可能です。 

Function Calling（関数呼び出し）での Structured Outputs の利用は、API で Function Calling をサポートするすべてのモデルで可能です。これには、最新モデル（gpt-4o、gpt-4o-mini）、gpt-4-0613 と gpt-3.5-turbo-0613 以降のすべてのモデル、および Function Calling をサポートするファインチューニングがされたモデルが含まれます。本機能は Chat Completions API、Assistants API、Batch API で利用可能です。また、Function Calling での Structured Outputs 利用は、Vision 入力とも互換性があります。

response_format での Structured Outputs の利用は、gpt-4o-mini、gpt-4o-2024-08-06 およびこれらに基づくファインチューニングモデルで可能です。本機能は Chat Completions API、Assistants API、Batch API で利用可能です。また、response_format での Structured Outputs 利用は、Vision 入力とも互換性があります。 

開発者の方は、新モデルの gpt-4o-2024-08-06 に切り替えることで、gpt-4o-2024-05-13 と比較して、入力で50％（$2.50/100万入力トークン）、出力で33%％（$10.00/100万出力トークン）のコスト節減となります。

Structured Outputs の利用開始には、当社ドキュメント⁠（新しいウィンドウで開く）をご確認ください。 

Structured Outputs は、オープンソースコミュニティの優れた研究、具体的には outlines⁠（新しいウィンドウで開く）、jsonformer⁠（新しいウィンドウで開く）、instructor⁠（新しいウィンドウで開く）、guidance⁠（新しいウィンドウで開く）、lark⁠（新しいウィンドウで開く） ライブラリからインスピレーションを得ています。