Care Cost Compass: An Agent System Using Mosaic AI Agent Framework | Databricks Blogの翻訳です。
本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
サマリー
本書では、Vector Search、Model Serving、AI Gateway、Online Tables、Unity Catalogのようなプラットフォームの機能を用いて、Databricksデータインテリジェンスプラットフォーム上に(複数の異なるAI、生成AIモデルの連携を通じて複雑なタスクを実行する)プロダクションレベルのエージェントシステムをどのように開発するのかの詳細を議論します。また、エージェントアプリケーションを迅速に構築し、繰り返しモデルを品質を改善するための評価ドリブンの方法論の活用方法についても説明します。
企業において信頼できる生成AIの開発の機会と障害
生成AIはソフトウェアエンジニアの手に高度な自然言語能力を提供することで、企業アプリケーション開発に革新的なメリットをもたらします。コンテンツ生成、データ分析、コード提案のような複雑なタスクを自動化することができ、開発期間や運用コストを劇的に削減します。高度なモデルを活用することで、企業はよりパーソナライズされたユーザー体験を生み出し、インテリジェントなデータ洞察を通じて意思決定を改善し、AIドリブンのチャットbotによるカスタマーサポートのようなプロセスを円滑にします。
数多くの利点にもかかわらず、企業アプリケーション開発における生成AIの活用は大きな課題を突きつけます。
精度: 生成AIは時に不正確でバイアスのある結果を出すことがあるため、大きな問題の一つはAIのアウトプットの精度と信頼性となります。
安全性: 特に規制のある業界において機微なデータやアプリケーションを取り扱う際には、AIの安全性と倫理的な使用を確実にすることも懸念点となります。規制のコンプライアンスやセキュリティ脆弱性への対応は、大規模にAIをデプロイする際にも依然として重大な懸念事項となります。
コスト: さらに、AIシステムを企業で利用可能できるようにスケールさせるには、膨大なリソースを要することのある堅牢なインフラストラクチャと専門性を必要とします。また、生成AIを既存システムに組み込むことで、互換性の課題が発生する可能性があり、AIドリブンのプロセスにおける透明性と説明可能性は重要ですが達成は困難です。
Mosaic AIエージェントフレームワークとDatabricksデータインテリジェンスプラットフォーム
Mosaic AIエージェントフレームワークは、最先端の生成AIアプリケーションの構築、デプロイ、評価、管理のための包括的なツールスイートを提供します。Databricksデータインテリジェンスプラットフォームを活用することで、Mosaic AIによって企業は自分たちの企業データにシームレスに連携されるプロダクションレベルの複雑なAIシステムをセキュアかつコスト効率高く開発を行えるようになります。
すぐに利用できるコスト計算のためのヘルスケアエージェント
ヘルスケア業界における支払人は、サービス費用を設定し、支払いを徴収し、主訴を処理し、プロバイバーの主訴への支払いを行うヘルスプランプロバイダーやメディケア、メディケイドのような企業となります。個人がサービスや治療を必要とした際、多くの人は電話で自分の支払人のカスタマーサービスに連絡をとり、自分たちの治療の見積もりを、サービス、手続きを利用するために自分の状況を説明します。
この計算は非常に標準的なものであり、ユーザーの十分な情報を入手したら決定論的に計算できるものです。ユーザーの入力から適切な情報を特定でき、精度良く正しいコストを取得できるエージェントアプリケーションを作成することで、カスタマーサービスのエージェントがより重要な電話対応ができるように開放できるようになります。
本書では、Vector Search、モデルサービング、AIゲートウェイ、オンラインテーブル、Unity CatalogのようなMosaic AIの機能を用いてエージェント生成AIシステムを構築します。また、迅速にエージェントアプリケーションを構築し、モデル品質を繰り返し改善するために評価ドリブン開発の方法論の活用方法を説明します。
アプリケーションの概要
ここで議論するシナリオは、ユーザーが支払い者ポータルにログインした際に、医療行為のコストに関する問い合わせにチャットbotを使用するというものです。ここで作成するエージェントアプリケーションはMosaic AI Model Servingを用いてREST APIとしてデプロイされます。
エージェントが質問を受け取ると、コスト見積もり手続きの典型的なワークフローは以下のようになります:
- 質問をした顧客の
client_idを理解する。 - 質問に関連して適切な福祉手当を取得する。
- 質問に関連する手続きコードを取得する。
- 原稿の計画年度における現在のメンバーの自己負担額を取得する。
- 手続きコードに対して交渉された手続きコストを取得する。
- 福祉手当の詳細、手続きコスト、現在の自己負担額からメンバーの手続きに対するネットワーク内、ネットワーク外のコストを計算する。
- 専門家のようにコスト計算を要約しユーザーに送信する。
実際にはこのアプリケーションのデータポイントは、複雑なデータエンジニアリングワークフローや計算の結果となるでしょうが、この取り組みのスコープをエージェントアプリケーションの設計、開発、デプロイに保つように、いくつかの簡素化のための前提を置いています。
- 福祉手当ドキュメントのサマリーのためのチャンキングは、構造はほとんどのドキュメントと同じ出ると仮定します。また、すべてのクライアントにおけるそれぞれの商品に対する福祉手当ドキュメントのサマリーはUnity Catalogのボリュームにあるものとします。
- ほとんどのテーブルのスキーマは必要な数フィールドに簡素化します。
- それぞれの手続きの価格はUnity CatalogのDeltaテーブルにあるものとします。
- ノートを細くするために用いるテクニックを説明するために、自己負担額を決定する計算は簡素化します。
- また、クライアントアプリケーションではリクエストにメンバーIDが含まれており、クライアントIDはDeltaテーブルで検索できるものとします。
このソリューションアクセラレーターのノートブックはこちらから利用できます。
アーキテクチャ
このソリューションを構築するために、DatabricksデータインテリジェンスプラットフォームのMosaic AIエージェントフレームワークを活用します。
データ準備からスタートする複数のステップでこのソリューションを構築します。
データの準備
以降の数セクションでは、我々のエージェントアプリケーションのためのデータの準備についてお話しします。
以下のDeltaテーブルには、このエージェントで必要とされる合成データが含まれています。
member_enrolment: クライアントとplan_idのようなメンバー登録情報を格納するテーブル
member_accumulators: 福祉手当や自己負担額のようなメンバーの積算値を含むテーブル
cpt_codes: CPTコードと説明文を含むテーブル
procedure_cost: それぞれの手続きのコストを含むテーブル
sbc_details: 福祉手当ドキュメントのサマリーPDFから作られたチャンクを含むテーブル
実装の詳細はこちらのノートブックで確認することができます。
福祉手当ドキュメントのサマリーのパーシングとチャンキング
質問に関連する適切な契約を取得するために、まず初めにそれぞれのクライアントの福祉手当ドキュメントのサマリーをDeltaテーブルにパースする必要があります。顧客の質問を用いてこのデータに対して意味を踏まえた検索を実行できるように、このパースされたデータはベクトルインデックスの作成に使用されます。
福祉手当ドキュメントのサマリーは以下の構造を持つものと仮定します。
我々の狙いは、詳細を適切にキャプチャするように、PDFからこの表データを抽出し、それぞれのラインのアイテムのフルテキストの要約を作成することです。
以下のアイテムについては、以下の2つの段落を作成したいと考えています。
検査を受ける場合、診断検査(X線、血液検査)ならネットワーク内であれば検査あたり$10の自己負担、ネットワーク外なら40%の共同保険。
と
検査を受ける場合、画像診断(CT/PETスキャン、MRI)ならネットワーク内であれば検査あたり$50の自己負担、ネットワーク外なら40%の共同保険。
注意
福祉手当ドキュメントのサマリーのフォーマットが異なる場合、それぞれのフォーマットに対して追加のパイプラインとパーシングのロジックを作成する必要があります。
このプロセスによって、それぞれの行ごとに福祉手当ドキュメントのサマリーのラインアイテムを含むDeltaテーブルが作成されます。福祉手当の段落のメタデータとしてclient_idがキャプチャされています。必要であれば、product_idのような追加のメタデータをキャプチャすることができますが、ここでの取り組みのスコープ外です。シンプルさを保ちましょう。
実装の詳細はこちらのノートブックをご覧ください。
ベクトルインデックスの作成
Mosaic AI Vector SearchはDatabricksデータインテリジェンスプラットフォームに組み込まれたベクトルデータベースであり、ガバナンスや生産性ツールとインテグレーションされています。ベクトルデータベースは、通常テキストや画像データの意味的なコンテンツの数学的表現であるエンべディングの格納と検索に最適化されています。
このアプリケーションでは、2つのベクトルインデックスを作成します:
- パースされた福祉手当のサマリーとカバレッジのチャンクのためのベクトルインデックス
- CPTコードと説明文のベクトルインデックス
Mosaic AIにおけるベクトルインデックスの作成は2ステップのプロセスです。
- Vector Searchエンドポイントの作成: Vector SearchエンドポイントはVector Searchインデックスを提供します。REST APIやSDKを用いてエンドポイントをクエリー、更新することができます。エンドポイントはインデックスのサイズや同時実行リクエストの数をサポートするために自動的にスケールします。
- ベクトルインデックスの作成: Vector SearchインデックスはDeltaテーブルから作成され、リアルタイム近似最近傍検索を行うように最適化されています。この検索のゴールは、クエリーに類似したドキュメントを特定することです。Vector Searchインデックスは、Unity Catalogで表示、管理されます。
このプロセスの詳細と参照コードについてはこちらのノートブックをご覧ください。
オンラインテーブル
オンラインテーブルは、オンラインアクセスに最適化された行指向フォーマットで格納されるDeltaテーブルの読み取り専用コピーです。オンラインテーブルは、リクエストの負荷に応じてスループットキャパシティをオートスケールさせる完全サーバレスのテーブルであり、任意のスケールにおいてのデータアクセスに低レイテンシーと高いスループットを提供します。オンラインテーブルは高速なデータ検索のために用いられるMosaic AIモデルサービング、Feature Serving、エージェントアプリケーションと連携するように設計されています。
我々はmember_enrolment、member_accumulators、procedure_costテーブルに対するオンラインテーブルを必要とします。
このプロセスの詳細と参照コードについてはこちらのノートブックをご覧ください。
エージェントアプリケーションの構築
これで必要なすべてのデータを手に入れたので、エージェントアプリケーションの構築をスタートすることができます。プロトタイプを迅速に開発し品質を繰り返し改善できるように、評価ドリブン開発の方法論に従います。
評価ドリブン開発
評価ドリブンワークフローは、Mosaic AIチームによる高品質RAGアプリケーションの構築、評価の推奨ベストプラクティスをベースにしています。
Databricksでは、以下の評価ドリブンワークフローをお勧めしています:
- 要件を定義する
- 迅速なPoCにおいてステークホルダーのフィードバックを収集する
- PoCの品質を評価する
- 繰り返し診断し、品質問題を修正する
- プロダクションにデプロイする
- プロダクションで監視する
ツールの構築と評価
エージェント構築する過程で、我々は特定のアクションを実行する数多くの関数を活用するかもしれません。我々のアプリケーションでは、以下の関数を実装する必要があります。
- コンテキストから
member_idを取得する - 質問をカテゴリ分けするための分類器
- メンバー登録情報テーブルの
member_idからclient_idを取得する検索関数 -
client_idの福祉手当サマリーインデックスから福祉手当を検索するRAGモジュール - 質問に対して適した手続きを検索する意味論的検索モジュール
- 手続きコストテーブルから得られた
procedure_codeの手続コストを取得する検索関数 - メンバーの積算値テーブルから
member_idのメンバーの積算値を取得する検索関数 - 上のステップから得られた情報から自己負担コストを計算するPython関数
- 専門家のように計算結果を要約し、ユーザーに送信するサマライザー
エージェントアプリケーションを開発している過程では、ユーザーのリクエストを処理する際にエージェントが利用できるように、ツールとして再利用可能な関数を開発することが一般的なプラクティスとなります。これらのツールは自律的あるいは、エージェントに実行を限定させるために使うことができます。
このノートブックでは、LangChainエージェントとして活用できるようにするためにこれらの関数をLangChainのツールや厳密なカスタムPyFuncモデルとして開発しています。
注意
現実のシナリオにおいては、これらのツールの多くは複雑な関数や他のサービスに対するREST APIコールになるかもしれません。このノートブックのスコープは昨日の説明のためのものであり、いかようにも拡張することができます。
評価ドリブン開発の方法論の側面の一つは:
- アプリケーションのそれぞれのコンポーネントに対する品質メトリクスを定義する
- 異なるパラメーターでメトリクスに対して個々のそれぞれのコンポーネントを評価する
- それぞれのコンポーネントでベストな結果を出したパラメーターを選択する
これは、従来のML開発におけるハイパーパラメータチューニングに非常に似ています。
我々のツールに対しても同じことを行います。それぞれのツールを個別にひょかし、それぞれのツールでベストな結果を出したパラメーターを選択します。このノートブックでは、評価プロセスを説明しており、コードを提供しています。繰り返しになります、このノートブックの評価は単なるガイドラインであり、好きな数だけ必要なパラメーターを追加して拡張することができます。
エージェントの組み立て
これですべてのツールを手に入れたので、エージェントシステムに全てを組み合わせましょう。
LangChainツールとしてコンポーネントを作成したので、プロセスを実行するためにAgentExecutorを使うことができます。
しかし、これは非常にわかりやすいプロセスなので、レスポンスのレイテンシーを削減し、精度を改善するために、エージェントアプリケーションを構築し、DatabricksモデルサービングにデプロイするためにカスタムのPyFuncモデルを使うことができます。
MLflow Python関数
MLflowのPython関数であるpyfuncは、任意のPythonコードやPythonモデルをデプロイする柔軟性を提供します。この機能を使いたいと考えるであろうシナリオの例を以下に示します。
- あなたのモデルは入力がモデルの
predict関数に渡す前に前処理を必要とする。 - あなたのモデルのフレームワークはMLflowでネイティブサポートされていない。
- あなたのアプリケーションは、結果を利用するためにモデルの生の出力を後処理する必要がある。
- モデル自身にリクエストごとに分岐するロジックがある。
- モデルとして完全にカスタムのコードをデプロイしようとしている。
こちらからモデルサービングによるPythonコードのデプロイについて学ぶことができます。
CareCostCompassAgent
CareCostCompassAgentは我々のエージェントに必要なロジックを実装するPython関数です。完全な実装についてはこちらのノートブックをご覧ください。
実装する必要がある2つの関数があります:
-
load_context- 運用するモデルに対して一度だけロードされる必要があるすべてのことは、この関数に定義しなくてはなりません。推論を高速化するようにpredict関数においてロードされるアーティファクトの数をシステムが最小化するように、これは重要なものとなります。このメソッドですべてのツールのインスタンスを作成します。 -
predict- この関数は入力リクエストが発生するたびに実行されるすべてのロジックを提供します。アプリケーションロジックをここで実装します。
モデルの入出力
我々のモデルはChatエージェントとして構築されており、使用することになるモデルシグネチャを表現しています。このため、リクエストはChatCompletionRequestとなります。
pyfuncモデルに入力されるデータには、Pandasデータフレーム、Pandasシリーズ、Numpy Array、List、Dictionaryを使うことができます。我々の実装では、入力としてPandasデータフレームを期待します。Chatエージェントなので、mlflow.models.rag_signatures.Messageのスキーマを持ちます。レスポンスはmlflow.models.rag_signatures.StringResponseとなります。
ワークフロー
pyfuncモデルのpredictメソッドに以下のワークフローを実装します。レスポンスのレイテンシーを改善するために、以下の3つのフローを並列に実行することができます。
-
member_idを用いてclient_idを取得し、適切な手当を取得する -
member_idを用いてメンバーの積算値を取得する - 手続コードを取得し、手続コストを取得する
並列IOオペレーションのためにasyncioライブラリを使います。コードはこちらのノートブックです。
エージェントの評価
我々のエージェントアプリケーションがMLflow互換のPythonクラスとして開発されたので、ブラックボックスシステムとしてモデルをテスト、評価することができます。我々はツールを個別に評価しましたが、期待したアウトプットが生成されることを確実にするために、エージェントを全体として評価することが重要となります。このモデルの評価に対するアプローチは、個々のツールに対して行なったものとほぼ同じです。
- 評価データフレームを定義する
- モデルの品質を計測するために使う品質メトリクスを定義する
- 評価を実行するために
databricks-agentsを用いたMLflow評価を活用する - モデルの品質を評価するために評価メトリクスを調査する
- 改善可能性を特定するためにトレースと評価結果を検証する
ここでカバーしたステップはこのノートブックで説明されています。
これで、今後のイテレーションのためのベンチマークとなりうるモデルパフォーマンスの予備的なな幾つかのメトリクスを手に入れいました。我々は依然として評価ドリブン開発ワークフローに従い、次のイテレーションで利用できる情報を取得するために、モデルを選抜されたビジネスステークホルダーがアクセスできるようにして、洗練されたフィードバックを収集します。
モデルの登録とデプロイ
Databricksデータインテリジェンスプラットフォームにおいては、Unity Catalogでモデルの完全なライフサイクルを管理することができます。Databricksでは、Unity CatalogでMLfowモデルレジストリのホストされたバージョンを提供しています。詳細はこちらをご覧ください。
ここまでやってきたことを振り返ってみましょう:
- 我々のエージェントアプリケーションで使うツールの構築
- ツールを評価し、個々のツールでベストな結果を出すパラメーターを選択
- ロジックを実装したカスタムPython関数モデルを作成
- 準備的なベンチマークを得るためにエージェントアプリケーションを評価
- MLflowエクスペリメントで上のすべてのランのすべてを追跡
それでは、モデルをUnity Catalogに登録し、モデルの最初のバージョンを作成する時間です。
Unity CatalogはDatabricksにおけるすべてのデータとAIの資産に対する統合されたガバナンスソリューションを提供します。Unity Catalogの詳細についてはこちらをご覧ください。Unity Catalogにおけるモデルは、集中管理のアクセスコントロール、監査、リネージ、ワークスペース横断でのモデル検索のようなUnity CatalogによるメリットをMLモデルに拡張します。Unity CatalogのモデルはオープンソースMLflowのPythonクライアントと互換性があります。
Unity Catalogにモデルを記録する際には、モデルをパッケージングし、スタンドアローン環境で動作するのに必要なすべての情報を含めるようにする必要があります。以下ですべての詳細を提供します:
- model_config: モデルの設定 - これには、ツールとモデルによって必要とされるすべてのパラメーター、エンドポイント名、ベクトルサーチインデックス情報が含まれます。パラメーターを指定するためにモデル設定を用いることで、モデルを記録し新規バージョンを作成するたびに、MLflowによってそのパラメーターが自動的に捕捉されるようにします。
- python_model: モデルのソースコードのパス - 我々はレガシーなシリアライゼーションテクニックではなく、MLflowのModels from Code機能を用いてモデルを記録します。レガシーなアプローチでは、cloudpickle(カスタムpyfuncやLangChain)や(LlamaIndexの場合)背後のパッケージのすべての機能に対する不完全なカバレッジを持つカスタムのシリアライザーを用いてモデルオブジェクトのシリアライゼーションを行なっていました。Models from Codeでは、サポートされるモデルタイプに対して、カスタムpyfuncやフレーバーのインタフェースを用いてシンプルなスクリプトが保存されます(LangChainの場合、スクリプト内に直接LCELを定義、モデルとしてマークすることができます)。これは、非常にクリーンであり、依存するライブラリによって一度は遭遇するであろうシリアライゼーションのすべてのエラーを排除します。
- artifacts: 依存するすべてのライブラリ - 我々のモデルでは存在しません
- pip_requirements: PyPiの依存ライブラリ - ここですべてのpip依存関係を指定することができます。これによって、デプロイメントの際にこれらの依存関係が読み込まれ、モデルのデプロイに構築されるコンテナに追加されるようにします。
- input_example: サンプルのリクエスト - ユーザーがこのモデルを使う際のガイドとして入力サンプルを提供することができます。
- signature: モデルのシグネチャ
- registered_model_name: Unity Catalogの3レベル名前空間におけるモデルのユニークな名称
- resources: モデルからアクセスされる他のエンドポイントのリスト。この情報は、これらのエンドポイントにアクセスするための認証トークンを作成するためにデプロイ時に用いられます。
これで、Unity Catalogにモデルを記録、登録するためにmlflow.pyfunc.log_modelメソッドを使えるようになりました。コードに関してはこちらのノートブックをご覧ください。
モデルがMLflowに記録されると、Mosaic AI Model Servingにデプロイできるようになります。エージェントの実装は、LLMコールを実行するために他のエンドポイントを呼び出すシンプルなPython関数なので、CPUエンドポイントにこのアプリケーションをデプロイすることができます。以下を行うためにMosaic AIエージェントフレームワークを使用します:
- CPUモデルサービングエンドポイントを作成することでモデルをデプロイする
- モデルの入出力とエージェントによって生成されるトレースを追跡するための推論テーブルをセットアップする
- エージェントで使用されるすべてのリソースに対する認証情報を作成、設定する
- フィードバックモデルを作成し、同じサービングエンドポイントにレビューアプリケーションをデプロイする
DatabricksエージェントAPIを用いたエージェントアプリケーションデプロイの詳細に関してはこちらをご覧ください。
デプロイが完了したら、2つURLが利用できることが表示されます: 1つはモデル推論のためのもので、2つ目がビジネスステークホルダーに共有できるレビューアプリのものです。
人間によるフィードバックの収集
モデルの最初の評価に用いた評価データフレームは、予備的なモデル品質を計測し、ベンチマークを確立するためのベストエフォートとして開発チームによって一緒に配置されました。ビジネス要件通りにモデルが実行されることを確実にするためには、内部開発ループの次のイテレーションの前にビジネスステークホルダーからのフィードバックを得ることは良いアイデアです。それを行うためにレビューアプリを使うことができます。
レビューアプリ経由で収集されたフィードバックは推論テーブルとともにDeltaテーブルに保存されます。詳細についてはこちらをご覧ください。
改善された評価データによる内部ループ
これで、クイックに繰り返してモデルの品質を迅速に改善するために活用できるエージェントのパフォーマンス関する重要な情報を入手しました。
- 適切な質問、期待する回答、どのようにエージェントが実行されたのかに関する詳細なフィードバックからなるビジネスステークホルダーからの品質に関するフィードんバック。
- 捕捉されたMLflow Tracesによる内部動作に対する洞察。
- 生成と収集の品質に関するメトリクスとDatabricks LLMジャッジによるフィードバックでの以前のエージェントに対する評価からの洞察。
次のイテレーションのためにレビューアプリから新たな評価データフレームを作成することもできます。こちらのノートブックで実装例を確認することができます。
複数の相互作用するコンポーネントを組み合わせることで、エージェントシステムがAIのタスクに取り組むことを見てきました。これらのコンポーネントにはモデル、リトリーバー、外部ツールに対する複数の呼び出しを含めることができます。エージェントシステムとしてAIアプリケーションを構築することで、いくつかのメリットが生まれます:
- 再利用性を持って構築: 再利用可能なコンポーネントはUnity Catalogのツールとして管理し、複数のエージェントアプリケーションで利用することができます。そして、どのツールを使うのか、いつ使うのかをそれぞれ決定する自律的論理的思考システムに簡単に提供することができます。
- 動的かつ柔軟なシステム: エージェントの機能は複数のサブシステムに分割できるので、これらのコンポーネントの開発、テスト、デプロイ、維持、最適化が容易となります。
- より良いコントロール: すべてにアクセスする大規模なシステムを持つのではなく、それぞれのコンポーネントのレスポンスの品質やセキュリティのパラメーターをコントロールする方が容易です。
- より多くのコスト/品質の選択肢: 小規模の調整されたモデル/コンポーネントの組み合わせは、さまざまなアプリケーションのための大規模なモデルよりも低いコストにつながります。
エージェントシステムは生成AIアプリケーションにおいて依然として進化を続けているカテゴリーであり、以下のようにこのようなアプリケーションを開発、本番運用する際のいくつかの課題を引き起こしています:
- 複数のハイパーパラメーターを持つ複数のコンポーネントの最適化
- 適切なメトリクスの定義、客観的な計測と追跡
- システムの品質とパフォーマンスを改善するための迅速な繰り返し
- 必要に応じてスケールする能力を持ったコスト効率の高いデプロイメント
- データとその他の資産のガバナンスとリネージ
- モデルの挙動に対するガードレイル
- モデルのレスポンスのコスト、品質、安全性の監視
Mosaic AIエージェントフレームは、正確、安全、管理されるように定常的に計測、評価される高品質エージェントアプリケーションを開発、デプロイするために開発者を支援するツールスイートを提供します。Mosaic AIエージェントフレームによって、開発者は自分のRAGアプリケーションの品質を評価し、自身の仮説をテストを行うことをクイックに繰り返し、容易にアプリケーションを再デプロイし、継続的に品質を保証するための適切なガバナンスやガードレイルを手に入れることができます。
Mosaic AIエージェントフレームは、Databricksデータインテリジェンスプラットフォームの残りの部分とシームレスに連携されています。これは、セキュリティやガバナンスからデータレ連携、ベクトルデータベース、品質評価、1クリックの最適化されたデプロイメントに至る、エンドツーエンドのエージェント生成AIシステムのデプロイに必要なすべてが揃っていることを意味します。ガバナンスとガードレイルを手にすることで、有害なレスポンスを防ぎ、アプリケーションがあなたの組織のポリシーに沿うことを確実にします