次の方法で共有

Azure Databricks 上の取得拡張生成 (RAG)

  • [アーティクル]

この記事では、取得拡張生成 (RAG) の概要と、Azure Databricks での RAG アプリケーションのサポートについて説明します。

Retrieval Augmented Generation (検索により強化された文章生成) とは?

RAG は、大規模言語モデル (LLM) と外部知識検索を組み合わせる生成 AI 設計パターンです。 RAG は、リアルタイム データを生成 AI アプリケーションに接続するために必要です。 これにより、推論時にデータがコンテキストとして LLM に提供されるため、アプリケーションの精度と品質が向上します。

Databricks プラットフォームには、次の RAG シナリオをサポートする統合ツール セットが用意されています。

RAG の種類 説明 ユース ケースの例
非構造化データ ドキュメントの使用 - PDF、Wiki、Web サイト コンテンツ、Google または Microsoft Office ドキュメントなど。 製品ドキュメントに関するチャットボット
構造化データ 表形式データの使用 - 差分テーブル、既存のアプリケーション API のデータ。 注文状態を確認するチャットボット
ツールと関数呼び出し サード パーティまたは内部の API を呼び出して、特定のタスクを実行したり、状態を更新したりします。 たとえば、計算の実行やビジネス ワークフローのトリガーなどです。 注文するチャットボット
エージェント LLM を使って一連のアクションを選ぶことで、ユーザーのクエリに応答する方法を動的に決定します。 カスタマー サービス エージェントを置き換えるチャットボット

RAG アプリケーションのアーキテクチャ

RAG アプリケーションを構成するコンポーネントを次に示します。

RAG application architecture all up

RAG アプリケーションには、次のことを実行するためのパイプラインとチェーン コンポーネントが必要です。

  • インデックス作成: ソースからデータを取り込み、インデックスを作成するパイプライン。 このデータは構造化でも非構造化でもかまいません。
  • 取得と生成: これは実際の RAG チェーンです。 ユーザー クエリを受け取り、インデックスから同様のデータを取得してから、そのデータをクエリと共に LLM モデルに渡します。

次の図は、これらのコア コンポーネントを示しています。

RAG application architecture for just the indexing pipeline and retrieval and generation, the RAG chain, pieces of RAG. The top section shows the RAG chain consuming the query and the subsequent steps of query processing, query expansion, retrieval and re-ranking, prompt engineering, initial response generation and post-processing, all before generating a response to the query. The bottom portion shows the RAG chain connected to separate data pipelines for 1. unstructured data, which includes data parsing, chunking and embedding and storing that data in a vector search database or index. Unstructured data pipelines require interaction with embedding and foundational models to feed into the RAG chain and 2. structured data pipelines, which includes consuming already embedded data chunks and performing ETL tasks and feature engineering before serving this data to the RAG chain

非構造化データ RAG の例

次のセクションでは、非構造化データ RAG の例のコンテキストで、インデックス作成パイプラインと RAG チェーンの詳細について説明します。

RAG アプリのインデックス作成パイプライン

次の手順では、インデックス作成パイプラインについて説明します。

  1. 独自のデータ ソースからデータを取り込みます。
  2. データを、基本的な LLM のコンテキスト ウィンドウに収まるチャンクに分割します。 この手順には、データの解析とメタデータの抽出も含まれます。 このデータは一般にナレッジ ベースと呼ばれ、基本的な LLM のトレーニングに使われます。
  3. 埋め込みモデルを使って、データ チャンクのベクトル埋め込みを作成します。
  4. 埋め込みとメタデータをベクトル データベースに保存して、RAG チェーンによるクエリにアクセスできるようにします。

RAG チェーンを使った取得

インデックスの準備が完了すると、アプリケーションの RAG チェーンで質問に応答できるようになります。 以下の手順と図は、RAG アプリケーションが受信要求にどのように応答するかを示しています。

  1. ナレッジ ベースにデータを埋め込むために使ったものと同じ埋め込みモデルを使って要求を埋め込みます。
  2. ベクトル データベースに対してクエリを実行して、埋め込み要求とベクトル データベース内の埋め込みデータ チャンクの間の類似性検索を実行します。
  3. 要求に最も関連するデータ チャンクを取得します。
  4. 関連するデータ チャンクと要求をカスタマイズされた LLM にフィードします。 データ チャンクは、LLM が適切な応答を生成するのに役立つコンテキストを提供します。 多くの場合、LLM には応答の書式設定方法に関するテンプレートがあります。
  5. 応答を生成します。

このプロセスを説明する図を次に示します。

RAG workflow after a request

Azure Databricks を使って RAG アプリケーションを開発する

Databricks には、RAG アプリケーションの開発に役立つ次の機能があります。

Azure Databricks を使う RAG アーキテクチャ

次のアーキテクチャ図は、どこに各 Azure Databricks 機能が RAG ワークフローに適合するかを示しています。 例については、取得拡張生成を使って LLM チャットボットをデプロイする方法のデモを参照してください。

非構造化データと Databricks で管理される埋め込みを処理する

非構造化データと Databricks で管理される埋め込みを処理する場合、次の図の手順と図に示すとおりです。

  1. 独自のデータ ソースからのデータ インジェスト。 このデータは、Delta テーブルまたは Unity Catalog ボリュームに保存できます。
  2. その後、データは、基本的な LLM のコンテキスト ウィンドウに収まるチャンクに分割されます。 この手順には、データの解析とメタデータの抽出も含まれます。 Databricks ワークフロー、Databricks ノートブック、Delta ライブ テーブルを使用して、これらのタスクを実行できます。 このデータは一般にナレッジ ベースと呼ばれ、基本的な LLM のトレーニングに使われます。
  3. 解析されてチャンクに分割されたデータは、ベクトル埋め込みを作成するために埋め込みモデルによって使用されます。 このシナリオでは、Model Serving を使用して埋め込みモデルを提供するベクトル検索機能の一部として、Databricks によって埋め込みが計算されます。
  4. 埋め込みはベクトル検索によって計算された後、Databricks によって Delta テーブルに保存されます。
  5. また、ベクトル検索の一部として、埋め込みとメタデータはインデックス付けされてベクトル データベースに保存され、RAG チェーンによるクエリでアクセスできるようになります。 ベクトル検索は、ソース データ テーブルに追加された新しいデータの埋め込みを自動的に計算し、ベクトル検索インデックスを更新します。

RAG indexing pipeline processing unstructured data and Databricks managed embeddings. This diagram shows the RAG application architecture for just the indexing pipeline.

非構造化データとカスタマーマネージド埋め込みを処理する

非構造化データとカスタマーマネージド埋め込みを処理する場合、次の手順と図に示すとおりです。

  1. 独自のデータ ソースからのデータ インジェスト。 このデータは、Delta テーブルまたは Unity Catalog ボリュームに保存できます。
  2. その後、データを、基本的な LLM のコンテキスト ウィンドウに収まるチャンクに分割できます。 この手順には、データの解析とメタデータの抽出も含まれます。 Databricks ワークフロー、Databricks ノートブック、Delta ライブ テーブルを使用して、これらのタスクを実行できます。 このデータは一般にナレッジ ベースと呼ばれ、基本的な LLM のトレーニングに使われます。
  3. 次に、解析されてチャンクに分割されたデータは、ベクトル埋め込みを作成するために埋め込みモデルによって使用されます。 このシナリオでは、埋め込みを自分で計算し、Model Serving を使用して埋め込みモデルを提供できます。
  4. 埋め込みを計算した後は、ベクトル検索と同期できる Delta テーブルに保存できます。
  5. ベクトル検索の一部として、埋め込みとメタデータはインデックス付けされてベクトル データベースに保存され、RAG チェーンによるクエリでアクセスできるようになります。 ベクトル検索は、Delta テーブルに追加された新しい埋め込みを自動的に同期し、ベクトル検索インデックスを更新します。

RAG with Databricks unstructured data and self managed embeddings

構造化データを処理する

構造化データを処理する場合は、次の手順と図に示すとおりです。

  1. 独自のデータ ソースからのデータ インジェスト。 このデータは、Delta テーブルまたは Unity Catalog ボリュームに保存できます。
  2. 特徴エンジニアリングでは、Databricks ノートブック、Databricks ワークフロー、Delta ライブ テーブルを使用できます。
  3. 特徴テーブルを作成します。 特徴テーブルは、主キーを持つ Unity Catalog 内の Delta テーブルです。
  4. オンライン テーブルを作成し、特徴量提供エンドポイントでホストします。 エンドポイントは、特徴テーブルと自動的に同期された状態を維持します。

RAG アプリケーションのオンライン テーブルと機能サービスの使用を説明するノートブックの例については、RAG サンプル ノートブックの Databricks オンライン テーブルと機能サービス エンドポイントに関する記事を参照してください。

RAG with Databricks structured data

RAG チェーン

インデックスの準備が完了すると、アプリケーションの RAG チェーンで質問に応答できるようになります。 次の手順と図は、受信した質問に対する RAG チェーンの動作を示しています。

  1. ナレッジ ベースにデータを埋め込むために使ったものと同じ埋め込みモデルを使って、受信した質問を埋め込みます。 Model Serving は、埋め込みモデルを提供するために使用されます。
  2. 質問が埋め込まれた後、ベクトル検索を使用して、埋め込み質問とベクトル データベース内の埋め込みデータ チャンクの間の類似性検索を実行できます。
  3. ベクトル検索が要求に最も関連するデータ チャンクを取得した後、それらのデータ チャンクと Feature Serving の関連する特徴と埋め込み質問は、応答が生成される前に、後処理のためにカスタマイズされた LLM で使用されます。
  4. データ チャンクと特徴は、LLM が適切な応答を生成するのに役立つコンテキストを提供します。 多くの場合、LLM には応答の書式設定方法に関するテンプレートがあります。 ここでも、Model Serving が LLM の提供に使用されます。 Unity Catalog と Lakehouse Monitoring を使用して、ログを保存し、チェーン ワークフローをそれぞれ監視することもできます。
  5. 応答を生成します。

Running the chain

利用可能なリージョン

Databricks 上で RAG アプリケーション開発をサポートする機能は、サービスを提供するモデルと同じリージョンで使用できます。

RAG アプリケーション開発の一部として Foundation Model API を使う予定の場合は、Foundation Model API でサポートされているリージョンに制限されます。