メインコンテンツまでスキップ

DatabricksのRAG(Retrieval Augmented Generation)

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

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

LLMOpsの簡略図

エージェントフレームワークには、エンドツーエンドのLLMOpsワークフローを使用して、RAG開発のすべてを迅速に反復させられるという利点があります。

必要条件​

  • パートナーが提供する AI 支援機能は、ワークスペースで有効にする必要があります。
  • エージェントアプリケーションのすべてのコンポーネントは、1つのワークスペース内に存在する必要があります。たとえばRAGアプリケーションの場合、サービングモデルとベクトル検索インスタンスは同じワークスペースに存在する必要があります。

RAGとは?​

RAG は大規模言語モデル（LLM）を外部の知識で強化する生成 AI の設計手法です。この手法では、以下の方法でLLMを改善します：

  • 独自の知識： 特定分野の質問に答えるため、LLM の初期学習に使用されていない独自の情報（メモ、メール、文書など）を RAG に含めることができます。
  • 最新情報： RAG アプリケーションは、更新されたデータソースから LLM に情報を提供することができます。
  • 情報源の引用： RAG を利用すると、LLM は特定の情報源を引用することができ、ユーザーが回答の正確さを確認できます。
  • データセキュリティとアクセス制御リスト（ACL）： ユーザー認証情報に基づいて個人情報や専有情報が選択的に取得されるように検索ステップを設計できます。

複合AIシステム​

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

最も単純な形式では、RAG アプリケーションは以下のことを実行します：

  1. 検索： ユーザーのリクエストを使用して、ベクトルストア、テキストキーワード検索、SQLデータベースなどの外部データストアに対してクエリーを実行します。LLM の回答を裏付けるデータを取得することが目標です。
  2. 拡張： 多くの場合、追加の書式設定と指示を含むテンプレートを使用し、取得したデータとユーザーのリクエストを組み合わせてプロンプトを作成します。
  3. 生成： プロンプトが LLM に渡され、クエリーに対する回答が生成されます。

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

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

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

  • PDF
  • Google/Office ドキュメント
  • Wiki
  • 画像
  • 動画

構造化データ： データベースのテーブルなど、特定のスキーマに従って行と列に配置された表形式のデータ。

  • BI またはデータウェアハウスシステムの顧客レコード
  • SQL データベースのトランザクションデータ
  • アプリケーション API（SAP、Salesforce など）から取得したデータ

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

RAG データパイプライン​

RAG データパイプラインは、迅速かつ正確な検索のため、ドキュメントを前処理してインデックス化します。

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

RAGデータパイプライン

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

  2. ドキュメント処理 : これらのタスクは、Databricks ジョブ、Databricks ノートブック、DLT を使用して実行できます。

    • 生ドキュメントの解析： 生データを使用可能な形式に変換します。例えば、PDF のコレクションからテキスト、表、画像を抽出したり、光学文字認識技術を使用して画像からテキストを抽出したりします。
    • メタデータの抽出： 検索ステップのクエリをより正確にするために、ドキュメントのタイトル、ページ番号、URLなどのドキュメントメタデータを抽出します。
    • ドキュメントのチャンク分割： データを LLM のコンテキストウィンドウに収まるチャンクに分割します。文書全体ではなく、これらの焦点を絞ったチャンクを取得することで、回答の生成に役立つ、より的を絞ったコンテンツを LLM に提供します。

  3. チャンクのエンべディング - エンべディングモデルは、チャンクを使用してベクトルエンべディングと呼ばれる情報の数値表現を作成します。ベクトルは表面的なキーワードだけでなく、テキストの意味的な情報を表現します。このシナリオでは、エンべディングを計算し、モデルサービングを使用してエンべディングモデルを提供します。

  4. エンべディングの保存 - ベクトルエンべディングとチャンクのテキストを、ベクトル検索と同期されている Delta テーブルに保存します。

  5. ベクトルデータベース - RAG エージェントが簡単にクエリーできるように、エンべディングとメタデータは、ベクトル検索の一貫としてインデックス化され、ベクトルデータベースに保存されます。ユーザーがクエリーを実行すると、そのリクエストはベクトルにエンベディングされます。その後、データベースはベクトルインデックスを使用して最も類似したチャンクを検索して返します。

各ステップには、RAG アプリケーションの品質に影響を与えるエンジニアリング上の決定が含まれます。たとえば、ステップ3では、適切なチャンクサイズを選択することでLLMがコンテキスト情報を含んだ具体的な情報を受け取れるようになり、ステップ4では、適切なエンベディングモデルを選択することで検索時に返されるチャンクの正確性が決まります。

類似性の計算は、多くの場合計算コストが高くなりますが、Databricks Vector Searchのようなベクトルインデックスは、エンベディングを効率的に整理することでこれを最適化します。Vector Searchでは、各エンベディングをユーザーのクエリーと個別に比較することなく、最も関連性の高い結果を迅速にランク付けします。

Vector Searchは、Delta テーブルに追加された新しいエンベディングを自動的に同期し、ベクトル検索インデックスを更新します。

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エージェント開発​

以下の特性を活用することで、エージェント開発を迅速に反復させることができます。

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

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

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

評価とモニタリング​

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

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

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

利用可能な地域​

Agent Framework の地域別提供状況については、地域限定の機能を参照してください

に最終更新