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チェーンです。 これは、ユーザークエリーを受け取り、インデックスから類似したデータを取得し、クエリーとともにそのデータをLLMモデルに渡します。
以下の図は、これらのコアコンポーネントを示しています。
非構造化データRAGの例
次のセクションでは、非構造化データRAGの例のコンテキストで、インデックス作成パイプラインとRAGチェーンの詳細について説明します。
RAGアプリでのインデックス作成パイプライン
次のステップでは、インデックス作成パイプラインについて説明します。
独自のデータソースからデータを取り込みます。
データを、基本 LLM のコンテキスト ウィンドウに収まるチャンクに分割します。 このステップには、データの解析とメタデータの抽出も含まれます。 このデータは、一般に、基礎的な LLM がトレーニングされるナレッジ ベースと呼ばれます。
埋め込みモデルを使用して、データチャンクのベクトル埋め込みを作成します。
埋め込みとメタデータをベクターデータベースに保存して、RAGチェーンによるクエリからアクセスできるようにします。
RAGチェーンを使用した検索
インデックスが準備されたら、アプリケーションのRAGチェーンを提供して質問に応答できます。 次のステップと図は、RAGアプリケーションが着信要求にどのように応答するかを示しています。
ナレッジ ベースにデータを埋め込むために使用したのと同じ埋め込みモデルを使用して、要求を埋め込みます。
クエリー The Vector Database を使用して、埋め込まれたリクエストと Vector データベース内の埋め込みデータチャンク間の類似性検索を行います。
要求に最も関連性の高いデータ チャンクを取得します。
関連するデータチャンクとリクエストをカスタマイズされたLLMにフィードします。 データチャンクは、LLMが適切な応答を生成するのに役立つコンテキストを提供します。 多くの場合、LLMには応答のフォーマット方法のテンプレートがあります。
応答を生成します。
次の図は、このプロセスを示しています。
Databricksを使用したRAGアプリケーションの開発
Databricks には、RAG アプリケーションの開発に役立つ次の機能が用意されています。
データ、特徴、モデル、関数のガバナンス、検出、バージョン管理、アクセス制御のための Unity Catalog。
構造化データ、非構造化データのチャンクと埋め込みを格納するためのDeltaテーブル。
ベクトル検索は、埋め込みベクトルを格納するクエリ可能なベクトルデータベースを提供し、ナレッジベースに自動的に同期するように設定できます。
Databricks モデルサービング は、LLMをデプロイし、RAGチェーンをホストします。 基盤モデル APIs で最先端のオープン LLM にアクセスしたり、外部モデルでサードパーティモデルにアクセスしたりするために、専用のモデルサービングエンドポイントを設定できます。
RAGチェーン開発の追跡と LLM評価 のための MLflow 。
特徴量エンジニアリングとサービング。 これは通常、構造化データのRAGシナリオに適用されます。
オンラインテーブル。 オンラインテーブルを低レイテンシのAPIとして提供し、RAGアプリケーションにデータを含めることができます。
Lakehouse Monitoring : 推論テーブルによる自動ペイロードロギングを使用して、データモニタリングとモデルの予測品質とドリフトの追跡を行います。
AI Playground 。 LLM をテストおよび比較するためのチャットベースの UI。
Databricksを使用したRAGアーキテクチャ
次のアーキテクチャ図は、Databricks の各機能が RAG ワークフローのどこに適合するかを示しています。 例については、 「取得拡張生成を使用して LLM チャットボットを展開する」デモを参照してください。
非構造化データと Databricks で管理される埋め込みを処理する
非構造化データと Databricks で管理される埋め込みを処理する場合、次の図のステップと図は次のように示されています。
独自のデータソースからデータ取り込み。 このデータは、Delta Table または Unity Catalog ボリュームに格納できます。
その後、データは、基本 LLM のコンテキスト ウィンドウに収まるチャンクに分割されます。 このステップには、データの解析とメタデータの抽出も含まれます。 Databricks Workflows、Databricks ノートブック、Delta Live Tables を使用して、これらのタスクを実行できます。 このデータは、一般に、基礎的な LLM がトレーニングされるナレッジ ベースと呼ばれます。
解析およびチャンクされたデータは、埋め込みモデルによって消費され、ベクトル埋め込みが作成されます。 このシナリオでは、Databricks は、モデルサービングを使用して埋め込みモデルを提供する Vector Search 機能の一部として、埋め込みをコンピュートします。
コンピュート埋め込み Vector Search 後、Databricks はそれらを Delta テーブルに格納します。
また、 Vector Searchの一部として、埋め込みとメタデータはインデックス化され、ベクターデータベースに保存され、RAGチェーンによるクエリにアクセスできるようになります。 Vector Search 、ソースデータテーブルに追加される新しいデータの埋め込みを自動的にコンピュートし、ベクトル検索インデックスを更新します。
非構造化データと顧客管理の埋め込みを処理する
非構造化データと顧客管理の埋め込みを処理する場合、次のステップと図は次のように示しています。
独自のデータソースからデータ取り込み。 このデータは、Delta テーブルまたは Unity Catalog ボリュームに格納できます。
その後、基本 LLM のコンテキスト ウィンドウに収まるチャンクにデータを分割できます。 このステップには、データの解析とメタデータの抽出も含まれます。 これらのタスクは、Databricks Workflows、Databricks ノートブック、Delta Live Tables を使用して実行できます。 このデータは、一般に、基礎的な LLM がトレーニングされるナレッジ ベースと呼ばれます。
次に、解析およびチャンクされたデータを埋め込みモデルで使用して、ベクトル埋め込みを作成できます。 このシナリオでは、埋め込みを自分でコンピュートし、モデルサービングを使用して埋め込みモデルを提供できます。
埋め込みをコンピュートした後、それらを Delta テーブルに格納し、 Vector Search.
Vector Searchの一部として、埋め込みとメタデータはインデックス化され、ベクトルデータベースに保存され、RAGチェーンによるクエリにアクセスできるようになります。Vector Search は、 Delta テーブルに追加された新しい埋め込みを自動的に同期し、ベクトル検索インデックスを更新します。
構造化データの処理
構造化データの処理については、次のステップと図で示します。
独自のデータソースからデータ取り込み。 このデータは、Delta テーブルまたは Unity Catalog ボリュームに格納できます。
特徴エンジニアリングには、Databricks ノートブック、Databricks ワークフロー、Delta Live Tables を使用できます。
特徴量テーブルを作成します。 特徴量テーブルは、主キーを持つ Unity Catalog の Delta テーブルです。
オンライン テーブルを作成し、特徴量サービングエンドポイントでホストします。 エンドポイントは、特徴量テーブルと自動的に同期されたままになります。
RAG アプリケーションでのオンライン テーブルと特徴量サービングの使用を示すノートブックの例については、 RAG の Databricks オンライン テーブルと特徴量サービングエンドポイントのノートブックの例を参照してください。
ラグチェーン
インデックスが準備されたら、アプリケーションのRAGチェーンを提供して質問に応答できます。 次のステップと図は、RAGチェーンが受信した質問に対してどのように動作するかを示しています。
受信した質問は、ナレッジベースにデータを埋め込むために使用されたのと同じ埋め込みモデルを使用して埋め込まれます。 モデルサービングは、埋め込みモデルを提供するために使用されます。
質問を埋め込んだ後、 Vector Search を使用して、埋め込まれた質問とベクターデータベース内の埋め込みデータチャンクの間の類似性検索を行うことができます。
Vector Search が要求に最も関連性の高いデータ チャンクを取得した後、それらのデータ チャンクは、特徴量サービングからの関連機能および埋め込まれた質問と共に、応答が生成される前に後処理のためにカスタマイズされた LLM で使用されます。
データのチャンクと特徴は、LLMが適切な応答を生成するのに役立つコンテキストを提供します。 多くの場合、LLMには応答のフォーマット方法のテンプレートがあります。 ここでも、モデルサービングはLLMを提供するために使用されます。 また、Unity Catalog とレイクハウスモニタリングを使用して、ログを格納し、チェーン ワークフローをそれぞれ監視することもできます。
応答を生成します。
利用可能なリージョン
DatabricksでのRAGアプリケーション開発をサポートする機能は、 モデルサービングと同じリージョンで利用できます。
RAGアプリケーション開発の一環として基盤モデルAPIsを使用する予定がある場合は、基盤モデルAPIsでサポートされているリージョンに限定されます。