バッチおよびエージェントワークフローのための構造化出力の紹介

多くのAIのユースケースは、非構造化入力を構造化データに変換することに依存しています。開発者はますます、LLMを利用して生のドキュメントから構造化データを抽出し、APIソースからデータを取得するアシスタントを構築し、行動を起こすエージェントを作成しています。これらの各ユースケースでは、モデルが構造化された形式に従った出力を生成する必要があります。

 

今日、私たちは Structured OutputsをMosaic AI Model Servingに導入することを発表します。これは、提供されたJSONスキーマにオプションで準拠できるJSONオブジェクトを生成するための統一されたAPIです。この新機能は、LlamaのようなオープンなLLM、ファインチューニングされたモデル、OpenAIのGPT-4oのような外部LLMを含むすべてのタイプのモデルをサポートし、特定のユースケースに最適なモデルを選択する柔軟性を提供します。 Structured Outputsは、新たに導入されたresponse_formatとともにバッチ構造生成にも、関数呼び出しを用いたエージェントアプリケーションの作成にも使用できます。

なぜ構造化出力なのか？

構造化出力により、2つの主要なユースケースで品質と一貫性が大幅に向上します。

構造化出力を使ったバッチ生成（response_format）

バッチ推論による特徴抽出は、時には数百万のデータポイントを対象とするため、厳密なスキーマに準拠した完全なJSONオブジェクトを確実に出力するのは困難です。しかし、構造化出力を使用することで、顧客はデータベース内の各ドキュメントに関連する情報を簡単にJSONオブジェクトに埋め込むことができます。バッチ特徴抽出は、Databricks FMAPIプラットフォーム上のすべてのLLM（ファインチューニングされたモデルも含む）で動作するresponse_format APIフィールドを介して利用可能です。

機能呼び出しを活用したエージェント構築

エージェントワークフローでは、機能呼び出しとツールの利用が成功の鍵を握ります。構造化出力により、LLMが外部APIや内部で定義されたコードへの機能呼び出しを一貫して出力できるようになります。FMAPIにおける関数呼び出し機能は、2024年のData + AI Summitで発表され、その後すぐにMosaic AIエージェントフレームワークが導入されました。関数呼び出し機能はtools APIフィールドを通じてユーザーが利用できます。機能呼び出し品質の評価に関する詳細はこちらのブログをご覧ください。

なお、tools APIフィールドは現在、Llama 3 70BおよびLlama 3 405Bでのみ動作します。

構造化された出力をどのように使用しますか？

response_format を使用すると、モデルの出力をどのような構造に制約するかを詳細に指定できます。サポートされている3つの出力フォーマットは以下の通りです：

1. Text: プロンプトに基づいてモデルが出力する非構造化テキスト。
2. Json_object: モデルがプロンプトから直感的にスキーマを推測して生成するJSONオブジェクト。
3. Json_schema: APIに適用されるJSONスキーマに準拠したJSONオブジェクトを出力。

後者の2つ（Json_object と Json_schema）を使用することで、特定のユースケースに応じた信頼性の高いJSON出力を得ることができます。

response_format フィールドのユースケース例

• 賃貸契約書から法的情報やPOC（Point of Contact）情報を抽出
• 投資家や財務アドバイザーとの会話記録から投資リスクを抽出
• 研究論文を解析してキーワード、トピック、著者の連絡先を抽出

JSONスキーマに準拠したカレンダーイベントの抽出例

以下は、プロンプトからカレンダーイベントを抽出するためにJSONスキーマを適用した例です。OpenAI SDKを使用すると、Pydanticを活用してオブジェクトスキーマを簡単に定義し、それをモデルに渡すことができます。これにより、明示的なJSONスキーマの代わりに柔軟で効率的な方法でスキーマを指定することが可能です。

関数呼び出しを持つエージェントの構築 

tools および tool_choice を使用することで、LLMが関数呼び出しをどのように行うかを詳細に指定できます。tools パラメータを使用すると、LLMが呼び出す可能性のあるツールのリストを指定できます。それぞれのツールは、名前、説明、およびJSONスキーマ形式のパラメータを持つ関数として定義されます。

その後、tool_choice を使用して、ツールがどのように呼び出されるかを決定できます。選択肢は以下の通りです：

• none: ツールリストにあるツールは一切呼び出されません。
• auto: ツールリスト内のツールを呼び出すべきかどうかをモデルが判断します。ツールが呼び出されない場合、モデルは通常通り非構造化テキストを出力します。
• required: 関連性にかかわらず、ツールリストの中から必ず1つのツールが呼び出されます。
• {"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スキーマの使用は避けましょう。 モデルが推論しにくくなるためです。ネストされたスキーマがある場合は、可能な限りフラット化してください！
• JSONスキーマにキーを詰め込みすぎないようにしましょう。 不要なキーは削除し、キーを簡潔に保つことが重要です。
• シンプルで正確なスキーマを使用することで、品質向上に加え、パフォーマンスがわずかに向上し、コストも削減できます。
• 直感を活用しましょう。 JSONスキーマが目視で複雑すぎると感じる場合は、スキーマを最適化することで改善の余地があります。
   

明確で簡潔なパラメータの説明と名前を設定しましょう。

• モデルは、どのような制約を課されているのか、なぜそれが必要なのかを理解すると、推論能力が向上します。これにより、抽出の品質が大幅に向上します。
   

JSONスキーマの機能を活用しましょう。

• プロパティを必須としてマークしたり、enum 機能でフィールドを特定の値のセットに制限することができます。少なくとも1つのプロパティを必須に設定することをお勧めします。

入力データに関連するスキーマを使用して制約を設定しましょう。

• たとえば、Wikipediaの記事から名前やイベントを抽出する場合、ページのHTMLマークアップではなく、実際のテキストを渡すことでデータの範囲を絞り込むと効果的です。
   

システムプロンプトに成功例を追加すると効果があります。

• LLMは、顧客が成功とみなす抽出例を与えられるとパフォーマンスが向上します。ただし、これが常に有効とは限らないため、試行錯誤することが重要です。

以下に例を示します。たとえば、賃貸契約書から法的情報やPOC情報を抽出する際に、次のスキーマを使用する場合を考えます：

上記の制約設定のヒントを活用して、最適なスキーマを設計することができます。まず、不要なキーを削除し、スキーマをフラット化します。例えば、ペットのフィールドの長さをチェックできる場合は、if_pets フィールドは不要です。また、モデルが認識しやすいように、すべての名前をより明確に変更することができます。次に、各プロパティに適切な型を指定し、役立つ説明を追加します。最後に、どのキーが必須であるかをマークし、ユースケースに最適なJSONスキーマを作成します。

以下は、最適化後のスキーマを使用して構造化出力を実行するための完全なコードです。

今後について

今後も構造化出力の利用に関する最新情報をお見逃しなく！構造化出力は間もなく ai_query で利用可能になります。これにより、数百万行のバッチ推論をワンコマンドで簡単に実行できるようになります。