Mosaic AI エージェント フレームワークとは何ですか?

プレビュー

この機能はパブリックプレビュー段階です。

エージェント フレームワークは、開発者が Retrieval Augmented Generation (RAG) アプリケーションなどの本番運用品質のエージェントを構築、展開、評価できるように設計された、 Databricks上の一連のツールで構成されています。

この記事では、エージェント フレームワークとは何か、また Databricks で RAG アプリケーションを開発する利点について説明します。

LLMOps ダイアグラムの簡略化

エージェント フレームワークを使用すると、開発者はエンドツーエンドの LLMOps ワークフローを使用して、RAG 開発のあらゆる側面を迅速に反復できます。

要件

  • パートナーが提供するAI 支援機能をワークスペースで有効にする必要があります。

  • エージェント アプリケーションのすべてのコンポーネントは、単一のワークスペースに存在する必要があります。 たとえば、RAG アプリケーションの場合、サービング モデルとベクトル検索インスタンスは同じワークスペースに存在する必要があります。

本番運用レベルのRAG開発

次の機能を使用して、エージェント開発を迅速に反復します。

任意のライブラリと MLflow を使用してエージェントを作成し、ログに記録します。 エージェントをパラメータ化して、エージェント開発を迅速に反復し、拡張します。

トークン ストリーミングとリクエスト/レスポンス ログのネイティブ サポートと、エージェントに対するユーザー フィードバックを取得する組み込みレビュー アプリを備えたエージェントを本番運用にデプロイします

エージェント トレース を使用すると、エージェント コード全体のトレースをログに記録、分析、比較して、エージェントが要求に応答する方法をデバッグして理解できます。

RAGとは?

RAGAI は、外部知識を使用して大規模言語モデル (LLM ) を強化する生成 設計手法です。この手法により、LLM は次のように改善されます。

  • 独自の知識: RAG には、メモ、電子メール、ドメイン固有の質問に答えるためのドキュメントなど、 LLMトレーニングに当初は使用されなかった独自の情報が含まれる場合があります。

  • 最新の情報: RAG アプリケーションは、更新されたデータソースからの情報をLLMに提供できます。

  • ソースの引用: RAG により、LLM は特定のソースを引用できるようになり、ユーザーは回答の事実の正確性を確認できます。

  • データ セキュリティとアクセス制御リスト ( ACL ):取得ステップは、ユーザーの資格情報に基づいて個人情報または独自の情報を選択的に取得するように設計できます。

複合AIシステム

RAG アプリケーションは複合 AI システムの一例であり、他のツールや手順と組み合わせることで LLM の言語機能を拡張します。

最も単純な形式では、RAGアプリケーションは次のことを行います。

  1. 取得:ユーザーのリクエストは、ベクター ストア、テキスト キーワード検索、SQL データベースなどの外部データ ストアを照会するために使用されます。 目標は、LLM の応答を裏付けるデータを取得することです。

  2. 増強: 取得したデータはユーザーの要求と組み合わされ、多くの場合、追加の書式設定と指示を含むテンプレートを使用してプロンプトが作成されます。

  3. 生成:プロンプトは LLM に渡され、クエリに対する応答が生成されます。

RAGとgen AIのユースケース

次の表に、RAGのユースケースをいくつか示します。

ユースケース

説明

Q&Aチャットボット

チャットボットでLLMを使用して、会社のドキュメントやナレッジベースから正確な回答を導き出します。 チャットボットは顧客サポートを自動化し、ウェブサイトのリードを追跡して質問に迅速に回答し、問題を解決できます。

検索の拡張

LLM を検索エンジンと併用すると、検索結果に LLM が生成した回答が追加され、ユーザーが必要な情報を見つけやすくなります。

知識エンジン

人事やコンプライアンス文書などの企業データを LLM のコンテキストとして使用し、従業員が福利厚生、ポリシー、セキュリティ、コンプライアンスに関する質問への回答を簡単に得られるようにします。

非構造化RAGデータと構造化RAGデータ

RAGアーキテクチャは、非構造化データまたは構造化サポートデータのいずれかを処理できます。 RAGで使用するデータは、ユースケースによって異なります。

非構造化データ: 特定の構造や組織を持たないデータ。 テキストや画像、またはオーディオやビデオなどのマルチメディアコンテンツを含むドキュメント。

  • PDFファイル

  • Google/Office ドキュメント

  • ウィキ

  • 画像

  • 動画

構造化データ: データベース内のテーブルなど、特定のスキーマを持つ行と列に配置された表形式のデータ。

  • BIまたはデータウェアハウスシステム内の顧客レコード

  • SQL データベースからのトランザクション データ

  • アプリケーションAPIs (SAP、Salesforce など) からのデータ

次のセクションでは、非構造化データ用のRAGアプリケーションについて説明します。

RAG データパイプライン

RAG データパイプラインは、ドキュメントを前処理してインデックスを作成し、高速かつ正確な検索を実現します。

以下の図は、セマンティック検索アルゴリズムを使用した非構造化データセットのサンプル データパイプラインを示しています。 Databricks Workflows各ステップを調整します。

RAG データパイプライン
  1. データ取り込み- 独自のソースからデータを取り込みます。 このデータをDeltaテーブルまたはUnity Catalogボリュームに保存します。

  2. ドキュメント処理: Databricks Workflows 、 Databricksダッシュボード、 Delta Live Tablesを使用してこれらのタスクを実行できます。

    • 生のドキュメントを解析する:生データを使用可能な形式に変換します。 例えば、PDF のコレクションからテキスト、表、画像を抽出したり、光学式文字認識技術を使用して画像からテキストを抽出したりします。

    • メタデータの抽出:ドキュメントのタイトル、ページ番号、URL などのドキュメント メタデータを抽出して、検索ステップのクエリをより正確に実行できるようにします。

    • チャンクドキュメント:データを LLM コンテキスト ウィンドウに収まるチャンクに分割します。 ドキュメント全体ではなく、これらの焦点を絞ったチャンクを取得することで、LLM は応答を生成するためのよりターゲットを絞ったコンテンツを取得できます。

  3. 埋め込みチャンク- 埋め込みモデルはチャンクを使用して、ベクトル埋め込みと呼ばれる情報の数値表現を作成します。 ベクトルは、表面的なキーワードだけでなく、テキストのセマンティックな意味を表します。 このシナリオでは、埋め込みをコンピュートし、モデルサーバーを使用して埋め込みモデルを提供します。

  4. 埋め込みストレージ- 検索と同期されたDeltaテーブルにベクトル埋め込みとチャンクのテキストを保存します。

  5. ベクター データベース- 検索の一環として、埋め込みとメタデータはインデックス化され、RAG エージェントによるクエリが容易になるようにベクター データベースに保存されます。 ユーザーがクエリを行うと、その要求はベクトルに埋め込まれます。 次に、データベースはベクトルインデックスを使用して、最も類似したチャンクを見つけて返します。

各ステップには、RAG アプリケーションの品質に影響を与えるエンジニアリング上の決定が含まれます。 たとえば、ステップ(3)で適切なチャンクサイズを選択すると、LLMは特定のコンテキスト情報を確実に受信できるようになります。一方、ステップ(4)で適切な埋め込みモデルを選択すると、検索中に返されるチャンクの精度が決まります。

RAGエージェントとは何ですか?

検索拡張生成 (RAG) エージェントは、外部データ検索を統合することで大規模言語モデル (LLM) の機能を強化する RAG アプリケーションの重要な部分です。 RAG エージェントは、ユーザー クエリを処理し、ベクター データベースから関連データを取得し、このデータを LLM に渡して応答を生成します。

LangChain や Pyfunc などのツールは、入力と出力を接続することでこれらのステップをリンクします。

下の図は、チャットボットの RAG エージェントと、各エージェントの構築に使用される Databricks 機能を示しています。

RAG チャットボット アーキテクチャ ワークフロー
  1. クエリの前処理 - ユーザーがクエリを送信すると、そのクエリはベクターデータベースのクエリに適したように前処理されます。 これには、テンプレートにリクエストを配置したり、キーワードを抽出したりすることが含まれる場合があります。

  2. クエリのベクトル化- データパイプラインにチャンクを埋め込むために使用したのと同じ埋め込みモデルを使用して、リクエストを埋め込むためにモデルサービングを使用します。 これらの埋め込みにより、要求と前処理されたチャンクの間のセマンティック類似性を比較できます。

  3. 検索フェーズ- 関連情報を取得するアプリケーションであるリトリーバーは、ベクトル化されたクエリを受け取り、ベクトル検索を使用してベクトル類似性検索を実行します。 最も関連性の高いデータチャンクは、クエリとの類似性に基づいてランク付けされ、取得されます。

  4. プロンプト拡張- リトリーバーは取得したデータ チャンクを元のクエリと組み合わせて、LLM に追加のコンテキストを提供します。 プロンプトは、LLM がクエリのコンテキストを理解できるように慎重に構成されています。 多くの場合、LLM には応答をフォーマットするためのテンプレートがあります。 プロンプトを調整するこのプロセスは、プロンプト エンジニアリングと呼ばれます。

  5. LLM 生成フェーズ- LLM は、検索結果によって強化された拡張クエリを使用して応答を生成します。 LLMカスタム モデルまたは基盤モデルにすることができます。

  6. 後処理- LLM の応答は、追加のビジネス ロジックを適用したり、引用を追加したり、事前に定義されたルールや制約に基づいて生成されたテキストを調整したりするために処理される場合があります。

企業ポリシーとの整合性を確保するために、このプロセス全体にわたってさまざまなガードレールを適用できます。 これには、適切なリクエストのフィルタリング、データソースにアクセスする前のユーザー権限の確認、生成された応答に対するコンテンツ モデレーション手法の使用が含まれる場合があります。

評価とモニタリング

評価とモニタリングは、RAG アプリケーションが品質、コスト、レイテンシの要件を満たしているかどうかを判断するのに役立ちます。 評価は開発中に行われ、モニタリングはアプリケーションが本番運用にデプロイされた後に行われます。

非構造化データに対するRAGには、品質に影響を与える多くのコンポーネントがあります。 たとえば、データ形式の変更は、取得されたチャンクと、関連する応答を生成する LLM の能力に影響を与える可能性があります。 そのため、アプリケーション全体に加えて、個々のコンポーネントを評価することが重要です。

詳細については、 Mosaic AIエージェント評価の概要」を参照してください。

利用可能なリージョン

RAG アプリケーション開発をサポートし、Databricks でエージェント評価を実行する機能は、次のリージョンで利用できます。

地域限定で利用できる機能の詳細については、地域限定で利用できる機能を参照してください。