によって ジェフリー・チェン, ベイ・フォーリー・コックス, アーメッド・ビラル 、 マーガレット・チェン による投稿
Archived. This article has not been updated since the publish date above. The dynamic nature of information means that previously accurate content can become outdated or even obsolete over time. Readers are advised to exercise due diligence and cross-check any information found in this blog post before making decisions or adopting any practices based on said information.
多くのAIのユースケースは、非構造化入力を構造化データに変換することに依存しています。開発者はますます、LLMを利用して生のドキュメントから構造化データを抽出し、APIソースからデータを取得するアシスタントを構築し、行動を起こすエージェントを作成しています。これらの各ユースケースでは、モデルが構造化された形式に従った出力を生成する必要があります。
今日、私たちは Structured OutputsをDatabricks Model Servingに導入することを発表します。これは、提供されたJSONスキーマにオプションで準拠できるJSONオブジェクトを生成するための統一されたAPIです。この新機能は、LlamaのようなオープンなLLM、ファインチューニングされたモデル、OpenAIのGPT-4oのような外部LLMを含むすべてのタイプのモデルをサポートし、特定のユースケースに最適なモデルを選択する柔軟性を提供します。 Structured Outputsは、新たに導入されたresponse_formatとともにバッチ構造生成にも、関数呼び出しを用いたエージェントアプリケーションの作成にも使用できます。
構造化出力により、2つの主要なユースケースで品質と一貫性が大幅に向上します。
バッチ推論による特徴抽出は、時には数百万のデータポイントを対象とするため、厳密なスキーマに準拠した完全なJSONオブジェクトを確実に出力するのは困難です。しかし、構造化出力を使用することで、顧客はデータベース内の各ドキュメントに関連する情報を簡単にJSONオブジェクトに埋め込むことができます。バッチ特徴抽出は、Databricks FMAPIプラットフォーム上のすべてのLLM（ファインチューニングされたモデルも含む）で動作するresponse_format APIフィールドを介して利用可能です。
エージェントワークフローでは、機能呼び出しとツールの利用が成功の鍵を握ります。構造化出力により、LLMが外部APIや内部で定義されたコードへの機能呼び出しを一貫して出力できるようになります。FMAPIにおける関数呼び出し機能は、2024年のData + AI Summitで発表され、その後すぐにDatabricksエージェントフレームワークが導入されました。関数呼び出し機能はtools APIフィールドを通じてユーザーが利用できます。機能呼び出し品質の評価に関する詳細はこちらのブログをご覧ください。
なお 、tools APIフィールドは現在、Llama 3 70BおよびLlama 3 405Bでのみ動作します。
response_format を使用すると、モデルの出力をどのような構造に制約するかを詳細に指定できます。サポートされている3つの出力フォーマットは以下の通りです：
後者の2つ（Json_object と Json_schema）を使用することで、特定のユースケースに応じた信頼性の高いJSON出力を得ることができます。
以下は、プロンプトからカレンダーイベントを抽出するためにJSONスキーマを適用した例です。OpenAI SDKを使用すると、Pydanticを活用してオブジェクトスキーマを簡単に定義し、それをモデルに渡すことができます。これにより、明示的なJSONスキーマの代わりに柔軟で効率的な方法でスキーマを指定することが可能です。
tools および tool_choice を使用することで、LLMが関数呼び出しをどのように行うかを詳細に指定できます。tools パラメータを使用すると、LLMが呼び出す可能性のあるツールのリストを指定できます。それぞれのツールは、名前、説明、およびJSONスキーマ形式のパラメータを持つ関数として定義されます。
その後、tool_choice を使用して、ツールがどのように呼び出されるかを決定できます。選択肢は以下の通りです：
{"type": "function", "function": {"name": "my_function"}}: ツールリスト内に有効な関数名「my_function」があれば、モデルはその関数を強制的に選択します。モデルが get_delivery_date と get_relevant_products という2つのツールを選択する状況を想定します。以下のコードスニペットでは、モデルが get_relevant_products を呼び出すべきケースが示されています。
構造化出力を 実現する鍵となるのが「制約付きデコード」です。制約付きデコードは、モデルがトークンを生成する各ステップで、期待される構造フォーマットに基づいて生成可能なトークンのセットを制限する技術です。例えば、JSONオブジェクトの冒頭部分を考えてみましょう。JSONオブジェクトは常に左中括弧で始まるため、トークン生成時には左中括弧で始まるトークンのみを考慮するように制限をかけます。これは単純な例ですが、この考え方は、必須のキーや特定のキー-値ペアの型など、JSONオブジェクト内の他の構造要素にも適用できます。出力の各位置でスキーマに準拠するトークンのセットを特定し、それに基づいてサンプリングを行います。技術的には、LLMが出力する生のロジットのうちスキーマに合致しないものは、サンプリング前に各タイムステップでマスキングされます。
制約付きデコードを使用することで、十分なトークンが生成される限り、モデルの出力が提供されたJSONスキーマに準拠するJSONオブジェクトになることが保証されます。これにより、構文エラーや型エラーが排除されます。制約付きデコードを活用することで、顧客は一貫性があり信頼性の高いLLMの出力を得ることができ、数百万のデータポイントにもスケール可能です。そのため、カスタムのリトライロジックやパーシングロジックを書く必要がなくなります。
制約付きデコードにはオープンソースでも多くの関心が寄せられており、OutlinesやGuidanceといった人気ライブラリがその例です。Databricksでは、制約付きデコードを大規模に適用する際の品質とパフォーマンスへの影響を調査し、さらに優れた方法を模索しています。
上記の例に加え、バッチ推論作業の品質を最大化するためのヒントとコツを以下に紹介します。
シンプルなJSONスキーマは、複雑なJSONスキーマよりも高品質な出力を生成します。
明確で簡潔なパラメータの説明と名前を設定しましょう。
JSONスキーマの機能を活用しましょう。
enum 機能でフィールドを特定の値のセットに制限することができます。少なくとも1つのプロパティを必須に設定することをお勧めします。
入力データに関連するスキーマを使用して制約を設定しましょう。
システムプロンプトに成功例を追加すると効果があります。
以下に例を示します。たとえば、賃貸契約書から法的情報やPOC情報を抽出する際に、次のスキーマを使用する場合を考えます：
上記の制約設定のヒントを活用して、最適なスキーマを設計することができます。まず、不要なキーを削除し、スキーマをフラット化します。例えば、ペットのフィールドの長さをチェックできる場合は、if_pets フィールドは不要です。また、モデルが認識しやすいように、すべての名前をより明確に変更することができます。次に、各プロパティに適切な型を指定し、役立つ説明を追加します。最後に、どのキーが必須であるかをマークし、ユースケースに最適なJSONスキーマを作成します。
以下は、最適化後のスキーマを使用して構造化出力を実行するための完全なコードです。
今後も構造化出力の利用に関する最新情報をお見逃しなく！構造化出力は間もなく ai_query で利用可能になります。これにより、数百万行のバッチ推論をワンコマンドで簡単に実行できるようになります。
ブログを購読して、最新の投稿を受信トレイにお届けします。