ケアコストコンパス：Databricksエージェントフレームワークを活用したエージェントシステム

企業向け信頼性の高い生成AIの開発における機会と障害

生成的AIは、ソフトウェアエンジニアの手に高度な自然言語能力を提供することで、エンタープライズアプリケーション開発に変革的な利益を提供します。複雑なタスクを自動化することができ、コンテンツ生成、データ分析、コード提案など、開発時間と運用コストを大幅に削減します。高度なモデルを活用することで、企業はよりパーソナライズされたユーザー体験を作り出し、インテリジェントなデータ洞察を通じて意思決定を改善し、AI駆動のチャットボットを用いてカスタマーサポートのようなプロセスを効率化することができます。

その多くの利点にもかかわらず、企業向けアプリケーション開発における生成AIの使用は大きな課題を提示します。

精度： 主な問題の一つはAIの出力の精度と信頼性で、生成モデルは時折、不正確または偏った結果を生み出すことがあります。

安全性：AIの安全性と倫理的な使用を確保することも懸念事項であり、特に機密データや規制された業界でのアプリケーションを扱う場合には特にそうです。規制遵守とセキュリティ脆弱性への対応は、AIを大規模に展開する際の重要な懸念事項です。

コスト： さらに、AIシステムをエンタープライズ対応にスケーリングするには、堅牢なインフラと専門知識が必要で、リソースを大量に消費します。既存のシステムに生成型AIを統合することは、透明性と説明責任をAI駆動のプロセスで維持することが重要である一方で、互換性の問題を引き起こす可能性があります。

モザイクAIエージェントフレームワークとDatabricksデータインテリジェンスプラットフォーム

モザイクAIエージェントフレームワークは、最先端の生成AIアプリケーションの構築、デプロイ、評価、管理のための包括的なツールスイートを提供します。Databricksデータインテリジェンスプラットフォームによって駆動されるDatabricksは、組織が安全かつコスト効率的に生産準備が整った複雑なAIシステムを開発し、それらをエンタープライズデータとシームレスに統合することを可能にします。

医療費用計算エージェントシステム

医療業界の支払者とは、健康保険プラン提供者やメディケア、メディケイドなど、サービス料金を設定し、支払いを収集し、請求を処理して提供者の請求を支払う組織です。個人がサービスやケアを受ける必要があるとき、ほとんどの人は自分の支払者のカスタマーサービス担当者に電話をかけ、状況を説明して、治療、サービス、または手続きの費用の見積もりを受け取ります。

この計算は非常に標準的で、ユーザーから十分な情報を得ることで決定論的に行うことができます。ユーザー入力から関連情報を特定し、正確にコストを取得できるエージェントアプリケーションを作成することで、カスタマーサービスエージェントがより重要な電話対応に集中できるようになります。

この記事では、Databricksの機能（ベクトル検索、モデル提供、AIゲートウェイ、オンラインテーブル、ユニティカタログなど）を使用して、エージェントGenAIシステムを構築します。また、エージェントアプリケーションを迅速に構築し、モデル品質を反復的に改善するために評価駆動開発手法の使用方法も示します。

アプリケーションの概要

ここで議論するシナリオは、顧客が支払者のポータルにログインし、チャットボット機能を使用して医療手続きの費用を問い合わせる場合です。ここで作成するエージェントアプリケーションは、Databricksのモデルサービングを使用してREST APIとしてデプロイされます。

エージェントが質問を受けると、手続き費用の見積もりに関する一般的なワークフローは以下の通りです：

1. 質問している顧客のclient_idを理解する。
2. 質問に関連する適切な交渉済み利益を取得する。
3. 質問に関連する手続きコードを取得する。
4. 現在のプラン年度における会員の控除額を取得する。
5. 手続きコードに関連する交渉済み手続き費用を取得する。
6. 利益の詳細、手続き費用、現在の控除額を元に、会員に対するネットワーク内およびネットワーク外の費用を計算する。
7. 費用計算を専門的に要約して、ユーザーに送信する。

実際には、このアプリケーションのデータポイントは、複数の複雑なデータエンジニアリングワークフローと計算の結果ですが、この作業の範囲をエージェントアプリケーションの設計、開発、デプロイに限定するため、いくつかの簡略化された仮定を行います。

• **Summary of Benefits（利益の概要）**文書のチャンク処理ロジックは、ほとんどの文書の構造がほぼ同じであると仮定しています。
• 各製品の最終的なSummary of BenefitsはUnity Catalogボリューム内で利用できると仮定しています。
• ほとんどのテーブルのスキーマは、必要なフィールドのみで簡素化されています。
• 各手続きに対する交渉済み価格は、Unity Catalog内のDeltaテーブルにあると仮定しています。
• 実費負担額を計算する方法は、メモをキャプチャするために使用される技術を示すために簡略化されています。
• クライアントアプリケーションには会員IDがリクエストに含まれており、クライアントIDはDeltaテーブルから検索できると仮定しています。

このソリューションアクセラレータのノートブックはここで利用可能です。

アーキテクチャ

このソリューションを構築するために、Databricks Data + AI Platform上でDatabricksエージェントフレームワークを使用します。以下に高レベルのアーキテクチャ図を示します。

私たちは、データ準備から始めて、複数のステップでソリューションを構築します。

データの準備

次のセクションでは、エージェントアプリケーションのためのデータ準備について説明します。

以下のDeltaテーブルには、このエージェントに必要な合成データが含まれます。

• member_enrolment: メンバーの登録情報を含むテーブル（例：client_id、plan_id）
• member_accumulators: メンバーの累積情報（控除額や自己負担額など）を含むテーブル
• cpt_codes: CPTコードとその説明を含むテーブル
• procedure_cost: 各手続きの交渉済み費用を含むテーブル
• sbc_details: Summary of Benefits（利益の概要）PDFから抽出したチャンクを含むテーブル

実装の詳細については、このノートブックを参照できます。

利益文書のパーシングとチャンキングの概要
適切な契約情報を取得するためには、まず各クライアントのSummary of Benefits文書を解析し、デルタテーブルに変換する必要があります。この解析されたデータは、ベクトルインデックスを作成するために使用され、顧客の質問に基づいてセマンティック検索を実行できるようになります。

利益文書は、以下の構造を持っていると仮定します。

私たちの目標は、この表形式のデータをPDFから抽出し、各行項目の全文要約を作成することで、詳細を適切に捉えることです。以下は一例です

下記のラインアイテムについて、以下のように2つのパラグラフを生成したいと考えています。

テストを受ける場合、診断テスト（X線、血液検査）では、ネットワーク内ではテストごとに10ドルのコペイ、ネットワーク外では40%のコインシュランスを支払います。

そして

テストがある場合、画像診断（CT/PETスキャン、MRI）は、ネットワーク内ではテストごとに50ドルの自己負担、ネットワーク外では40％のコインシュランスを支払います。

注意：利益の要約文書の形式が異なる場合、各形式に対してさらにパイプラインと解析ロジックを作成する必要があります。このノートブックでは、チャンク化プロセスの詳細を説明します。

このプロセスの結果、利益の概要文書の各行項目が別々の行として含まれるDelta Tableが作成されます。client_idは、利益の段落のメタデータとしてキャプチャされました。必要であれば、product_idなどのメタデータをさらに取得することができますが、この作業の範囲では、それをシンプルに保つことにします。

実装の詳細については、このノートブックのコードを参照してください。

ベクトルインデックスの作成

モザイクAIベクトル検索は、Databricksデータインテリジェンスプラットフォームに組み込まれ、そのガバナンスと生産性ツールと統合されたベクトルデータベースです。ベクトルデータベースは、埋め込みを保存し取得するために最適化されています。これは、通常はテキストや画像データのセマンティックコンテンツの数学的表現です。

このアプリケーションでは、2つのベクトルインデックスを作成します。

• BenefitsとCoverageのチャンクの解析に対するベクトルインデックス
• CPTコードと説明のためのベクトルインデックス

Databricksでベクトルインデックスを作成するのは二段階のプロセスです。

1. ベクトル検索エンドポイントの作成：ベクトル検索エンドポイントは、ベクトル検索インデックスを提供します。REST APIまたはSDKを使用してエンドポイントをクエリおよび更新できます。エンドポイントは、インデックスのサイズや同時リクエストの数に対応して自動的にスケールします。
2. ベクターインデックスの作成: ベクター検索インデックスはDelta tableから作成され、リアルタイムの近似最近傍検索を最適化するために使用されます。検索の目標は、クエリに似ている文書を特定することです。ベクトル検索インデックスはUnityカタログに表示され、その規則に従います。

このノートブックでは、プロセスの詳細と参照コードを提供しています。

オンラインテーブル

オンラインテーブルは、オンラインアクセスに最適化された行指向フォーマットで保存されたDeltaテーブルの読み取り専用コピーです。オンラインテーブルは、完全にサーバーレスなテーブルで、リクエスト負荷に応じてスループット容量を自動的にスケーリングし、任意のスケールのデータへの低レイテンシーかつ高スループットのアクセスを提供します。オンラインテーブルは、Databricksモデルサービング、フィーチャーサービング、エージェンティックアプリケーションと連携して動作し、これらは高速なデータルックアップに使用されます。

我々は、member_enrolment、member_accumulators、procedure_costのテーブルのためのオンラインテーブルが必要です。

このノートブックでは、プロセスの詳細と必要なコードを説明しています。

エージェントアプリケーションの構築

必要なデータがすべて揃ったので、エージェントアプリケーションの構築を開始できます。評価駆動開発の方法論を迅速にプロトタイプを開発し、その品質を反復的に改善するために使用します。

評価駆動開発

評価駆動型ワークフローは、高品質なRAGアプリケーションを構築し評価するためのDatabricks AI Researchチームの推奨ベストプラクティスに基づいています。 

Databricksは次の評価駆動型のワークフローを推奨します：

• 要件を定義する
• ステークホルダーからの迅速な概念証明（POC）に対するフィードバックを収集します
• POCの品質を評価する
• 反復的に品質問題を診断し、修正する
• 本番環境へのデプロイ
• 本番環境での監視

Databricks AI Cookbookで評価駆動開発について詳しく読む。

ツールの構築と評価

エージェントを構築する際には、特定のアクションを実行するための多くの関数を利用することがあります。私たちのアプリケーションでは、以下の関数を実装する必要があります

• コンテキストからmember_idを取得する
• 質問を分類するための分類器
• メンバー登録テーブルからmember_idを取得するためのルックアップ関数
• RAGモジュールを使用して、client_idの利益の概要インデックスから利益を検索します
• 質問に適切な手続きコードを検索するためのセマンティック検索モジュール
• 手続き費用テーブルから取得したprocedure_codeの手続き費用を取得するためのルックアップ関数
• メンバー累積テーブルからmember_idのメンバー累積を取得するためのルックアップ関数
• 前のステップからの情報を元に自己負担コストを計算するPython関数
• 計算をプロフェッショナルな方法でまとめ、ユーザーに送信するサマライザー

エージェントアプリケーションを開発する際、一般的にはエージェントがユーザーのリクエストを処理するためのツールとして再利用可能な関数を開発します。これらのツールは、自律的または厳格なエージェント実行のどちらでも使用できます。

このノートブックでは、これらの関数をLangChainツールとして開発し、LangChainエージェントや厳格なカスタムPyFuncモデルとして使用する可能性があります。

注：実際のシナリオでは、これらのツールの多くが複雑な関数や他のサービスへのREST API呼び出しになる可能性があります。このノートブックの範囲は、特徴を示すことであり、可能な限り拡張することができます。

評価駆動開発方法論の一つの側面は：

• アプリケーション内の各コンポーネントの品質指標を定義する
• 各コンポーネントを異なるパラメータでメトリクスに対して個別に評価します
• 各コンポーネントに最適な結果をもたらしたパラメーターを選択します

これは、古典的なML開発におけるハイパーパラメータチューニング演習に非常に似ています。

私たちは、私たちのツールでもまさにそれを行います。私たちは各ツールを個別に評価し、各ツールに最適な結果をもたらすパラメータを選択します。このノートブックでは、評価プロセスを説明し、コードを提供しています。ノートブックで提供される評価はあくまでガイドラインであり、必要なパラメーターは何でも含めることができます。

エージェントの組み立て

すべてのツールが定義されたので、これらをすべてエージェントシステムに組み合わせる時が来ました。

私たちのコンポーネントをLangChainツールとして作成したので、AgentExecutorを使用してプロセスを実行することができます。

しかし、非常に直接的なプロセスなので、応答遅延を減らし、精度を向上させるために、カスタムPyFuncモデルを使用してエージェントアプリケーションを構築し、Databricksモデルサービングにデプロイすることができます。

MLflow Python Function
MLflowのPython function、pyfuncは、任意のPythonコードやPythonモデルをデプロイする柔軟性を提供します。以下は、これを使用したいと思うかもしれない例のシナリオです。

• あなたのモデルは、入力をモデルのpredict関数に渡す前に前処理が必要です。
• あなたのモデルフレームワークは、MLflowによってネイティブにサポートされていません。
• あなたのアプリケーションは、モデルの生の出力を消費するために後処理する必要があります。
• モデル自体にはリクエストごとの分岐ロジックがあります。
• モデルとして完全にカスタムコードをデプロイすることを考えています。

PythonコードのModel Servingによるデプロイについてはここで詳しく読むことができます

CareCostCompassAgent

CareCostCompassAgentは、エージェントに必要なロジックを実装するPython関数です。完全な実装については、このノートブックを参照してください。

実装する必要がある2つの関数があります:

• load_context - モデルが動作するために一度だけロードする必要があるものは、この関数で定義します。これは重要です。なぜなら、システムが予測機能中にロードするアーティファクトの数を最小限に抑えることで、推論の速度が向上するからです。このメソッドですべてのツールをインスタンス化します
• predict - この関数は、入力リクエストが行われるたびにすべてのロジックを実行します。ここでアプリケーションロジックを実装します。

モデルの入力と出力
私たちのモデルはチャットエージェントとして構築されており、それが私たちが使用するモデルのシグネチャを決定します。したがって、リクエストはChatCompletionRequestになります

pyfuncモデルへのデータ入力は、Pandas DataFrame、Pandas Series、Numpy Array、List、またはDictionaryであることができます。私たちの実装では、Pandas DataFrameを入力として期待します。チャットエージェントであるため、mlflow.models.rag_signatures.Messageのスキーマを持つことになります。

私たちの応答は、ただのmlflow.models.rag_signatures.StringResponseになります

ワークフロー
私たちは、pyfuncモデルの予測メソッドで以下のワークフローを実装します。下記の3つのフローは、レスポンスの遅延を改善するために並行して実行することができます。

1. メンバーIDを使用してclient_idを取得し、適切な利益条項を取得します
2. member_idを使用してメンバーアキュムレータを取得します。
3. 手続きコードを取得し、手続きコードを参照します

並行IO操作にはasyncioライブラリを使用します。コードはこのノートブックで利用可能です。

エージェントの評価

今や、エージェントアプリケーションはMLflow互換のPythonクラスとして開発されているので、モデルをブラックボックスシステムとしてテストし、評価することができます。ツールを個別に評価してきましたが、エージェント全体が望む出力を生成していることを確認するために、全体を評価することが重要です。モデルの評価方法は、個々のツールに対して行ったのとほぼ同じです。

• 評価データフレームを定義する
• モデルの品質を測定するために使用する品質指標を定義します。
• databricks-agentsを使用したMLflow評価を実行して評価を行います。
• モデルの品質を評価するための評価指標を研究する
• トレースと評価結果を調査し、改善の機会を特定します

このノートブックでは、これまでに説明した手順を示しています。

これで、モデルのパフォーマンスの初期メトリクスがあり、これが今後の反復のベンチマークになります。私たちは評価駆動開発のワークフローに従い、このモデルをデプロイして、選択したビジネスステークホルダーに公開し、キュレーションされたフィードバックを収集し、次のイテレーションでその情報を使用できるようにします。

モデルを登録し、デプロイします。

Databricksデータインテリジェンスプラットフォームでは、Unityカタログでモデルのライフサイクル全体を管理することができます。Databricksは、Unityカタログ内でホストされたバージョンのMLflowモデルレジストリを提供しています。詳しくはこちら

これまでに行ったことの簡単なまとめ：

• エージェントアプリケーションで使用されるツールを構築しました。
• ツールを評価し、個々のツールに最適なパラメーターを選択しました
• ロジックを実装したカスタムPython関数モデルを作成しました
• エージェントアプリケーションを評価して、予備的なベンチマークを取得しました。
• 上記のすべての実行をMLflow Experimentsで追跡しました

今度は、モデルをUnityカタログに登録し、モデルの最初のバージョンを作成する時です。

Unityカタログは、Databricks上のすべてのデータとAIアセットに対する統一されたガバナンスソリューションを提供します。ユニットカタログについてはこちらをご覧ください。Unity Catalogのモデルは、Unity Catalogの利点をMLモデルに拡張し、ワークスペース全体での一元化されたアクセス制御、監査、系統、モデル発見を含みます。Unityカタログのモデルは、オープンソースのMLflow Pythonクライアントと互換性があります。

モデルをUnity Catalogにログするときは、モデルをパッケージ化し、スタンドアロンの環境で実行するためのすべての必要な情報を含めることを確認する必要があります。以下の詳細をすべて提供します：

• model_config: モデル設定—これには、ツールとモデルが必要とするすべてのパラメータ、エンドポイント名、ベクトル検索インデックス情報が含まれます。モデル設定を使用してパラメータを指定することで、モデルをログに記録し、新しいバージョンを作成するたびにパラメータが自動的にMLflowにキャプチャされることも保証します。
• python_model: モデルソースコードパス - レガシーなシリアライゼーション技術の代わりに、MLFlowのコードからのモデル機能を使用してモデルをログに記録します。レガシーなアプローチでは、モデルオブジェクトに対してcloudpickle（カスタムpyfuncとLangChain）またはカスタムシリアライザ（LlamaIndexの場合）を使用してシリアライゼーションが行われますが、これは基礎となるパッケージ内のすべての機能をカバーしていません。コードからのモデルでは、サポートされているモデルタイプについては、カスタムpyfuncまたはフレーバーのインターフェース（つまり、LangChainの場合、スクリプト内でLCELチェーンを直接モデルとして定義し、マークすることができます）の定義が含まれたシンプルなスクリプトが保存されます。これははるかにクリーンで、依存ライブラリーに対するシリアライゼーションエラーをすべて解消します。
• artifacts: 依存するアーティファクト - 私たちのモデルにはありません
• pip_requirements: PyPiからの依存ライブラリ - ここで私たちのすべてのpip依存関係を指定することもできます。これにより、これらの依存関係はデプロイメント中に読み取られ、モデルのデプロイメント用に構築されたコンテナに追加されることを確認します。
• input_example： サンプルリクエスト - このモデルを使用するユーザーにガイダンスとしてサンプル入力を提供することもできます
• 署名：モデル署名
• registered_model_name: Unityカタログの三層ネームスペース内でモデルの一意の名前
• resources: このモデルからアクセスされる他のエンドポイントのリスト。この情報は、デプロイメント時にこれらのエンドポイントへのアクセスのための認証トークンを作成するために使用されます。

これからmlflow.pyfunc.log_modelを使用しますモデルをUnityカタログにログ記録し、登録する方法。コードを見るにはこのノートブックを参照してください。

モデルがMLflowにログされると、それをDatabricks Model Servingにデプロイすることができます。エージェントの実装は、LLMコールを実行するための他のエンドポイントを呼び出す単純なPython関数であるため、このアプリケーションをCPUエンドポイントにデプロイすることができます。モザイクAIエージェントフレームワークを使用して

• CPUモデル提供エンドポイントを作成してモデルをデプロイします
• モデルの入力とレスポンス、エージェントが生成するトレースを追跡する推論テーブルを設定します
• エージェントが使用するすべてのリソースの認証情報を作成し、設定します
• フィードバックモデルを作成し、同じサービングエンドポイントにレビューアプリケーションをデプロイします。

DatabricksエージェントAPIを使用したエージェントアプリケーションのデプロイについては、ここで詳しく読むことができます。

デプロイメントが完了すると、モデル推論用のURLとレビューアプリ用のURLの2つが利用可能になり、これをビジネスステークホルダーと共有することができます。

人間のフィードバックの収集

モデルの最初の評価に使用した評価データフレームは、開発チームが予備的なモデル品質を測定し、ベンチマークを設定するための最善の努力としてまとめられました。モデルがビジネス要件に従って動作するようにするために、内部開発ループの次の反復前にビジネスステークホルダーからフィードバックを得ることが良いアイデアになるでしょう。それを行うために、レビューアプリを使用することができます。

レビューアプリを通じて収集されたフィードバックは、推論テーブルとともにデルタテーブルに保存されます。詳細はこちらをご覧ください。

改善された評価データを持つ内部ループ

今、エージェントのパフォーマンスについての重要な情報を持っており、これを使用して迅速に反復し、モデルの品質を急速に改善することができます。

1. ビジネスステークホルダーからの品質フィードバック、適切な質問、期待される回答、エージェントのパフォーマンスについての詳細なフィードバック。
2. MLflowトレースからキャプチャされたモデルの内部動作についての洞察。
3. Databricks LLMの審査員からのフィードバックと生成および取得品質の指標に基づいて、以前にエージェントに対して行われた評価からの洞察。

また、レビューアプリの出力から新しい評価データフレームを作成することもできます。このノートブックで実装例を見ることができます。

エージェントシステムが複数の相互作用するコンポーネントを組み合わせてAIタスクに取り組むことを見ました。これらのコンポーネントには、複数のモデルへの呼び出し、データ取得システム、外部ツールなどが含まれる場合があります。AIアプリケーションをエージェントシステムとして構築することにはいくつかの利点があります：

• 再利用性を持って構築する： 再利用可能なコンポーネントは、Unityカタログで管理できるツールとして開発でき、複数のエージェントアプリケーションで使用できます。その後、ツールは自律的な推論システムに簡単に供給することができ、それらは何をいつ使用するかを決定し、それに応じてそれらを使用します。
• 動的で柔軟なシステム：エージェントの機能が複数のサブシステムに分割されているため、これらのコンポーネントを簡単に開発、テスト、デプロイ、維持、最適化することができます。
• より良いコントロール：大規模なシステムがすべてのアクセスを持つのではなく、各コンポーネントの応答品質とセキュリティパラメータを個別に簡単に制御することができます。
• より多くのコスト/品質オプション: 小さなチューニングされたモデル/コンポーネントの組み合わせは、広範なアプリケーションのために構築された大きなモデルよりも、より良い結果を低コストで提供します。

エージェントシステムはまだGenAIアプリケーションの進化中のカテゴリであり、そのようなアプリケーションの開発と製品化にはいくつかの課題をもたらします。例えば：

• 複数のコンポーネントをいくつかのハイパーパラメータで最適化します
• 適切な指標を定義し、客観的に測定し追跡する
• システムの品質とパフォーマンスを迅速に改善するために反復します
• 必要に応じてスケールする能力を持つコスト効率的なデプロイメント
• データとその他の資産のガバナンスと系統
• モデルの振る舞いに対するガードレール
• モデルの応答のコスト、品質、安全性の監視

モザイクAIエージェントフレームワークは、開発者が一貫して測定され、評価されて正確で、安全で、管理されていると判断される高品質のエージェントアプリケーションを構築し、デプロイするのを支援するように設計されたツールスイートを提供します。また、Databricks エージェントフレームワークは、開発者が RAG アプリケーションの品質を容易に評価し、仮説をテストして迅速に反復を行い、アプリケーションを容易に再デプロイメントし、品質を継続的に確保するための適切なガバナンスとガードレールを提供します。

モザイクAIエージェントフレームワークは、Databricksデータインテリジェンスプラットフォームの残りの部分とシームレスに統合されています。これは、セキュリティとガバナンスからデータ統合、ベクトルデータベース、品質評価、ワンクリックでの最適化デプロイまで、エージェント型GenAIシステムをエンドツーエンドでデプロイするために必要なすべてを持っていることを意味します。ガバナンスとガードレールを設けることで、有害なレスポンスを防ぎ、アプリケーションが組織のポリシーに従うことを確保します。