Databricks での Retrieval Augmented Generation (RAG)

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

Retrieval Augmented Generationとは?

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

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

RAGの種類

説明

使用例

非構造化データ

ドキュメントの使用 - PDF、Wiki、Web サイトのコンテンツ、Google または Microsoft Office ドキュメントなど。

製品ドキュメントに対するチャットボット

構造化データ

表形式データの使用 - デルタ テーブル、既存のアプリケーション APIsからのデータ。

注文状況を確認するチャットボット

ツールと関数呼び出し

サードパーティまたは内部 APIs を呼び出して、特定のタスクを実行したり、ステータスを更新したりします。 たとえば、計算を実行したり、ビジネス ワークフローをトリガーしたりします。

注文するチャットボット

エージェント

LLMを使用して一連のアクションを選択することにより、ユーザーのクエリーに応答する方法を動的に決定します。

顧客サービスエージェントに代わるチャットボット

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

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

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

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

  • インデキシング ソースからデータを取り込み、インデックスを作成するパイプライン。 このデータは、構造化データでも非構造化データでもかまいません。

  • 検索と生成 これが実際のRAGチェーンです。 これは、ユーザークエリーを受け取り、インデックスから類似したデータを取得し、クエリーとともにそのデータをLLMモデルに渡します。

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

インデックス作成パイプラインと検索と生成、RAGチェーン、RAGの一部のみのRAGアプリケーションアーキテクチャ。 一番上のセクションには、クエリーを消費するRAGチェーンと、クエリーへの応答を生成する前の、クエリーの処理、クエリーの拡張、検索と再ランク付け、プロンプトエンジニアリング、初期応答の生成と後処理の後続のステップが表示されます。 下部は、1の個別のデータパイプラインに接続されたRAGチェーンを示しています。非構造化データには、データの解析、チャンク化、埋め込み、ベクトル検索データベースまたはインデックスへのデータの保存が含まれます。 非構造化データパイプラインでは、RAGチェーンにフィードするために、埋め込みモデルや基本モデルとの相互作用が必要であり、2.構造化データパイプラインには、すでに埋め込まれているデータチャンクを消費し、このデータをRAGチェーンに提供する前にETLタスクと特徴量エンジニアリングを実行することが含まれます。

非構造化データRAGの例

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

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

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

  1. 独自のデータソースからデータを取り込みます。

  2. データを、基本 LLM のコンテキスト ウィンドウに収まるチャンクに分割します。 このステップには、データの解析とメタデータの抽出も含まれます。 このデータは、一般に、基礎的な LLM がトレーニングされるナレッジ ベースと呼ばれます。

  3. 埋め込みモデルを使用して、データチャンクのベクトル埋め込みを作成します。

  4. 埋め込みとメタデータをベクターデータベースに保存して、RAGチェーンによるクエリからアクセスできるようにします。

RAGチェーンを使用した検索

インデックスが準備されたら、アプリケーションのRAGチェーンを提供して質問に応答できます。 次のステップと図は、RAGアプリケーションが着信要求にどのように応答するかを示しています。

  1. ナレッジ ベースにデータを埋め込むために使用したのと同じ埋め込みモデルを使用して、要求を埋め込みます。

  2. クエリー The Vector Database を使用して、埋め込まれたリクエストと Vector データベース内の埋め込みデータチャンク間の類似性検索を行います。

  3. 要求に最も関連性の高いデータ チャンクを取得します。

  4. 関連するデータチャンクとリクエストをカスタマイズされたLLMにフィードします。 データチャンクは、LLMが適切な応答を生成するのに役立つコンテキストを提供します。 多くの場合、LLMには応答のフォーマット方法のテンプレートがあります。

  5. 応答を生成します。

次の図は、このプロセスを示しています。

RAG ワークフロー after a request

Databricksを使用したRAGアプリケーションの開発

Databricks には、RAG アプリケーションの開発に役立つ次の機能が用意されています。

Databricksを使用したRAGアーキテクチャ

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

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

非構造化データと Databricks で管理される埋め込みを処理する場合、次の図のステップと図は次のように示されています。

  1. 独自のデータソースからデータ取り込み。 このデータは、Delta Table または Unity Catalog ボリュームに格納できます。

  2. その後、データは、基本 LLM のコンテキスト ウィンドウに収まるチャンクに分割されます。 このステップには、データの解析とメタデータの抽出も含まれます。 Databricks Workflows、Databricks ノートブック、Delta Live Tables を使用して、これらのタスクを実行できます。 このデータは、一般に、基礎的な LLM がトレーニングされるナレッジ ベースと呼ばれます。

  3. 解析およびチャンクされたデータは、埋め込みモデルによって消費され、ベクトル埋め込みが作成されます。 このシナリオでは、Databricks は、モデルサービングを使用して埋め込みモデルを提供する Vector Search 機能の一部として、埋め込みをコンピュートします。

  4. コンピュート埋め込み Vector Search 後、Databricks はそれらを Delta テーブルに格納します。

  5. また、 Vector Searchの一部として、埋め込みとメタデータはインデックス化され、ベクターデータベースに保存され、RAGチェーンによるクエリにアクセスできるようになります。 Vector Search 、ソースデータテーブルに追加される新しいデータの埋め込みを自動的にコンピュートし、ベクトル検索インデックスを更新します。

RAGインデックス作成パイプライン処理、非構造化データ、Databricksマネージド埋め込み。 この図は、インデックス作成パイプラインのみのRAGアプリケーションアーキテクチャを示しています。

非構造化データと顧客管理の埋め込みを処理する

非構造化データと顧客管理の埋め込みを処理する場合、次のステップと図は次のように示しています。

  1. 独自のデータソースからデータ取り込み。 このデータは、Delta テーブルまたは Unity Catalog ボリュームに格納できます。

  2. その後、基本 LLM のコンテキスト ウィンドウに収まるチャンクにデータを分割できます。 このステップには、データの解析とメタデータの抽出も含まれます。 これらのタスクは、Databricks Workflows、Databricks ノートブック、Delta Live Tables を使用して実行できます。 このデータは、一般に、基礎的な LLM がトレーニングされるナレッジ ベースと呼ばれます。

  3. 次に、解析およびチャンクされたデータを埋め込みモデルで使用して、ベクトル埋め込みを作成できます。 このシナリオでは、埋め込みを自分でコンピュートし、モデルサービングを使用して埋め込みモデルを提供できます。

  4. 埋め込みをコンピュートした後、それらを Delta テーブルに格納し、 Vector Search.

  5. Vector Searchの一部として、埋め込みとメタデータはインデックス化され、ベクトルデータベースに保存され、RAGチェーンによるクエリにアクセスできるようになります。Vector Search は、 Delta テーブルに追加された新しい埋め込みを自動的に同期し、ベクトル検索インデックスを更新します。

Databricksの非構造化データと自己管理型埋め込みを使用したRAG

構造化データの処理

構造化データの処理については、次のステップと図で示します。

  1. 独自のデータソースからデータ取り込み。 このデータは、Delta テーブルまたは Unity Catalog ボリュームに格納できます。

  2. 特徴エンジニアリングには、Databricks ノートブック、Databricks ワークフロー、Delta Live Tables を使用できます。

  3. 特徴量テーブルを作成します。 特徴量テーブルは、主キーを持つ Unity Catalog の Delta テーブルです。

  4. オンライン テーブルを作成し、特徴量サービングエンドポイントでホストします。 エンドポイントは、特徴量テーブルと自動的に同期されたままになります。

RAG アプリケーションでのオンライン テーブルと特徴量サービングの使用を示すノートブックの例については、 RAG の Databricks オンライン テーブルと特徴量サービングエンドポイントのノートブックの例を参照してください。

Databricks構造化データを使用したRAG

ラグチェーン

インデックスが準備されたら、アプリケーションのRAGチェーンを提供して質問に応答できます。 次のステップと図は、RAGチェーンが受信した質問に対してどのように動作するかを示しています。

  1. 受信した質問は、ナレッジベースにデータを埋め込むために使用されたのと同じ埋め込みモデルを使用して埋め込まれます。 モデルサービングは、埋め込みモデルを提供するために使用されます。

  2. 質問を埋め込んだ後、 Vector Search を使用して、埋め込まれた質問とベクターデータベース内の埋め込みデータチャンクの間の類似性検索を行うことができます。

  3. Vector Search が要求に最も関連性の高いデータ チャンクを取得した後、それらのデータ チャンクは、特徴量サービングからの関連機能および埋め込まれた質問と共に、応答が生成される前に後処理のためにカスタマイズされた LLM で使用されます。

  4. データのチャンクと特徴は、LLMが適切な応答を生成するのに役立つコンテキストを提供します。 多くの場合、LLMには応答のフォーマット方法のテンプレートがあります。 ここでも、モデルサービングはLLMを提供するために使用されます。 また、Unity Catalog とレイクハウスモニタリングを使用して、ログを格納し、チェーン ワークフローをそれぞれ監視することもできます。

  5. 応答を生成します。

チェーンの実行

利用可能なリージョン

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

RAGアプリケーション開発の一環として基盤モデルAPIsを使用する予定がある場合は、基盤モデルAPIsでサポートされているリージョンに限定されます。