Retrieval Augmented Generation (RAG) on Databricks | Databricks on AWS [2024/1/12時点]の翻訳です。

本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。

本書ではretrieval augmented generation (RAG)の概要を紹介し、DatabricksにおけるRAGアプリケーションのサポートを説明します。

Retrieval Augmented Generationとは何か？

RAGとは、大規模言語モデルと外部の知識収集を組み合わせることに関係する生成AIのデザインパターンです。お使いの生成AIアプリケーションにリアルタイムデータを接続する際にRAGが必要となります。推論時にLLMにコンテキストとしてお使いのデータを与えることで、アプリケーションの精度と品質を改善します。

Databricksプラットフォームでは、以下のRAGシナリオをサポートするためのインテグレーションされたツールセットを提供します。

RAGのタイプ	説明	サンプルユースケース
非構造化データ	ドキュメントの活用 - PDF、wiki、ウェブサイトコンテンツ、Googleや Microsoftオフィスのドキュメントなど	製品ドキュメントに対するチャットbot
構造化データ	表形式データの活用 - Deltaテーブル、既存アプリケーションAPIのデータ	注文ステータスをチェックするチャットbot
ツールや関数の呼び出し	特定のタスクやステータス更新を実行するためにサードパーティや内部のAPIの呼び出し。例えば、計算の実行やビジネスワークフローの起動	注文を行うチャットbot
エージェント	一連のアクションを選択するためにLLMを用いることで、ユーザーのクエリーに対してどのように反応するかを動的に決定	カスタマーサービスエージェントを置き換えるチャットbot

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

以下ではRAGアプリケーションを構成するコンポーネントを説明しています。

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

インデックス作成 ソースからデータを取り込みインデックスを作成するパイプライン。データは構造化、あるいは非構造化となります。
収集および生成 これが実際のRAGチェーンとなります。ユーザーのクエリーを受け取り、インデックスから類似するデータを収集し、LLMモデルにクエリーとデータを引き渡します。

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

非構造化データRAGの例

以下のセクションでは、非構造化データRAGのサンプルの文脈で、インデックス作成パイプラインとRAGチェーンの詳細を説明します。

RAGアプリケーションにおけるインデックス作成パイプライン

以下のステップではインデックス作成パイプラインを説明します:

あなたのプロプライエタリデータソースからデータを取り込みます。
基盤LLMのコンテキストウィドウにフィットするチャンクにデータを分割します。このステップには、データのパースとメタデータの抽出も含まれます。このデータは、基盤LLMがトレーニングする知識ベースとしても参照されます。
データチャンクのベクトルエンべディングを作成するためにエンべディングモデルを使用します。
RAGチェーンのクエリーがアクセスできるように、ベクトルデータベースにエンべディングとメタデータを格納します。

RAGチェーンを用いた収集

インデックスの準備ができると、アプリケーションのRAGチェーンが質問に反応できるようになります。以下のステップと図では、入力されるリクエストにRAGアプリケーションがどのようにレスポンスを出力するのかを説明しています。

知識ベースのデータのエンべディング作成に使用したのと同じエンべディングモデルを用いて、リクエストのエンべディングを作成します。
リクエストのエンべディングとベクトルデータベースのデータチャンクのエンべディングの間で類似検索を行うために、ベクトルデータベースにクエリーを実行します。
リクエストに最も適したデータチャンクを収集します。
カスタマイズしたLLMに対して、適切なデータチャンクとリクエストを入力します。データチャンクは、LLMが適切なレスポンスを生成できる助けとなるコンテキストを提供します。
レスポンスを生成します。

以下の図ではこのプロセスを説明しています。

DatabricksによるRAGアプリケーションの開発

Databricksでは、RAGアプリケーションの開発の助けとなる以下の機能を提供しています。

データ、特徴量、モデル、関数に対するガバナンス、検索、バージョン管理、アクセスコントロールのためのUnity Catalog。
データパイプライン作成およびオーケストレーションのためのノートブックとワークフロー。
構造化データ、非構造化データのチャンク、エンべディング格納のためのDeltaテーブル。
Vector searchは、エンべディングベクトルを格納するクエリー可能なベクトルデータベースを提供し、お使いの知識ベースと自動で同期するように設定可能です。
LLMのデプロイとご自身のRAGチェーンをホスティングするためのDatabricksモデルサービング。Foundation Model APIで最先端のオープンLLMにアクセスする専用モデルサービングエンドポイントを設定したり、外部モデルを用いてサードパーティモデルにアクセスするモデルサービングエンドポイントを設定することができます。
RAGチェーン開発のトラッキングやLLM評価のためのMLflow。
特徴量エンジニアリングおよびサービング。これは特に構造化データのRAGシナリオに当てはまります。
オンラインテーブル。RAGアプリケーションにデータを組み込むために低レーテンシーAPIとしてオンラインテーブルをサービングすることができます。
推論テーブルによる自動ペイロードロギングを用いた、データの監視およびモデル予測品質とドリフトの追跡のためのレイクハウスモニタリング。
AI Playground。LLMをテスト、比較するためのチャットベースのUI。

DatabricksによるRAGアーキテクチャ

以下のアーキテクチャ図では、Databricksの機能がRAGワークフローにどのように当てはまるのかを説明します。サンプルに関しては、Deploy Your LLM Chatbot With Retrieval Augmented Generation (RAG) demoをご覧ください。

非構造化データとDatabricksマネージドのエンべディングの処理

非構造化データとDatabricksマネージドのエンべディングを処理するには以下の図のステップを踏みます。図では以下を示しています:

あなたのプロプライエタリデータソースからのデータ取り込み。このデータはDeltaテーブルやUnity Catalogのボリュームに格納することができます。
データは、基盤LLMのコンテキストウィンドウにフィットするようにチャンクに分割されます。これらのタスクを実行するために、Databricksワークフロー、Databricksノートブック、Delta Live Tablesを活用することができます。このデータは、多くの場合、基盤LLMをトレーニングする知識ベースとして参照されます。
パースされチャンクに分割されたデータは、ベクトルエンべディングを作成するためにエンべディングモデルによって処理されます。このシナリオでは、エンべディングモデルを提供するモデルサービングを使用するVector Searchの機能の一部として、Databricksがエンべディングを計算します。
Vector Searchがエンベディングを計算すると、DatabricksはDeltaテーブルに格納します。
また、Vector Searchの一部として、RAGチェーンによってクエリーできるように、ベクトルデータベースにエンべディングとメタデータのインデックスが作成され、格納されます。Vector Searchはソースのデータテーブルに新規データが追加されると自動でエンべディングを計算し、Vector Searchのインデックスを更新します。

非構造化データと顧客管理エンべディングの処理

非構造化データと顧客管理のエンべディングを処理するには以下の図のステップを踏みます。図では以下を示しています:

あなたのプロプライエタリデータソースからのデータ取り込み。このデータはDeltaテーブルやUnity Catalogのボリュームに格納することができます。
データは、基盤LLMのコンテキストウィンドウにフィットするようにチャンクに分割されます。これらのタスクを実行するために、Databricksワークフロー、Databricksノートブック、Delta Live Tablesを活用することができます。このデータは、多くの場合、基盤LLMをトレーニングする知識ベースとして参照されます。
パースされチャンクに分割されたデータは、ベクトルエンべディングを作成するためにエンべディングモデルによって処理されます。このシナリオでは、ご自身でエンべディングを計算し、エンべディングモデルをサービングするためにモデルサービングを活用することができます。
Vector Searchがエンベディングを計算するると、DatabricksはDeltaテーブルに格納します。
また、Vector Searchの一部として、RAGチェーンによってクエリーできるように、ベクトルデータベースにエンべディングとメタデータのインデックスが作成され、格納されます。Vector Searchはソースのデータテーブルに新規データが追加されると自動でエンべディングを計算し、Vector Searchのインデックスを更新します。

構造化データの処理

構造化データを処理するには、以下の図のステップを踏みます。図では以下を示しています:

あなたのプロプライエタリデータソースからのデータ取り込み。このデータはDeltaテーブルやUnity Catalogのボリュームに格納することができます。
特徴量エンジニアリングには、Databricksワークフロー、Databricksノートブック、Delta Live Tablesを活用することができます。
特徴量テーブルの作成。特徴量テーブルは主キーを持つUnity Catalog上のDeltaテーブルです。
オンラインテーブルを作成し、特徴量サービングエンドポイントに干す手イングします。このエンドポイントは、特徴量テーブルと自動で同期し続けます。

サンプルノートブックでは、RAGアプリケーションにおけるオンラインテーブルと特徴量サービングの使い方を説明していますので、Databricks online tables and feature serving endpoints for RAG example notebookをご覧ください。

RAGチェーン

インデックスの準備ができると、アプリケーションのRAGチェーンは質問に回答するためにサービングすることができます。以下のステップと図では、入力される質問にRAGチェーンがどのように動作するのかを説明しています。

入力される質問は、知識ベースのデータのエンべディング作成に使用したのと同じエンべディングモデルを用いてエンべディングに変換されます。エンべディングモデルのサービングにはモデルサービングが使用されます。
質問がエンべディングに変換されると、質問のエンべディングとベクトルデータベースのデータチャンクのエンべディングの間で類似検索を行うためにVector Searchを使用します。
Vector Searchがリクエストに最も適したデータチャンクを収集し、これらのデータチャンクとFeature Servingの適切な特徴量、エンべディングされた質問は、レスポンスの生成の前の後処理のためにカスタマイズされたLLMに入力されます。
データチャンクと特徴量は、LLMが適切なレスポンスを生成できる助けとなるコンテキストを提供します。多くの場合、LLMにはレスポンスをどのようにフォーマッティングするのかを示すテンプレートがあります。ここでも、LLMのサービングにモデルサービングが使用されます。また、ログを格納し、チェーンワークフローを監視するためにはUnity Catalogとレイクハウスモニタリングを活用することができます。
レスポンスを生成します。

利用できるリージョン

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

RAGアプリケーション開発の一部でFoundation Model APIの利用を計画している場合、Foundation Model APIをサポートしているリージョンに限定されます。

はじめてのDatabricks

はじめてのDatabricks

Databricks無料トライアル

Databricks無料トライアル