RAGによる社内ナレッジを活用したチャットボットの構築 #AI

はじめに

LLM（大規模言語モデル）は企業が内外の情報を効果的に扱う方法を急速に進化させています。ChatGPTはLLMを基にして、チャットボットを広く利用できるようにしました。そして近年では非常に多くの企業でLLMの導入を検討しています。しかしながらLLMの導入と継続的な運用を行うためには解決すべき様々な課題があります。
本ブログではLLMの活用を検討されている方を対象に、AIフレームワークとして注目を集めているRAG(Retrieval Augmented Generation）を使用したリアルタイムQAチャットボットの構築の例をもとにして、LLMプラットフォームとしてのDatabricksの機能のご紹介とLLM導入の課題をDatabricksでどのように解決できるかをご紹介します。

本ブログの内容は弊社で提供しているRAGチャットボットのデモNotebookを日本語データで検証した内容を元に執筆しており、実機での動作検証も可能です。ぜひお試しください。
Deploy Your LLM Chatbot With Retrieval Augmented Generation (RAG), Foundation Models and Vector Search

LLM導入における課題

実際にLLMをプロダクション環境で利用するには、ビジネス上の様々な課題に対処する必要があるでしょう。
代表的なものを挙げてみます。

ハルシネーション（不正確な情報提供）の防止
企業が保有している独自データの活用によるモデル精度の向上
ユーザー要件に特化した動作の実現
プライバシーと機密情報の保護
LLM環境の開発と運用とコストの最適化

これらのビジネス上の課題を解決するためには、パブリックなLLMの利用では十分ではなく、各企業で蓄積したナレッジをセキュアな環境で活用するためのカスタムLLMの導入を検討する必要があります。しかし、カスタムLLMの導入と継続的な運用を大規模に行うのは簡単ではありません。
以下に示すようなLLM運用に必要となるシステム要件を効率的に実装できるプラットフォームが必要となってきます。

大量のデータの取り込みと変換処理
データパイプライン全体のプライバシーとセキュリティの確保
データのベクター表現を保存し、リアルタイムで類似検索が可能なデータベースの実装
カスタムモデルのトレーニング及びプライベートなインフラ上へのLLMモデルのデプロイ
様々なモデルをサービング可能なGPU環境の提供
プロダクションにおけるモデルの品質と安全性の保証

これらの課題はDatabricksにより解決することができます。Databricksは、データ収集と準備から、モデル開発と LLMOps、サービス提供と監視に至るまで、LLM開発と評価に対する統合環境を提供します。
こうしてカスタムLLMの運用に必要な全てのステップが簡素化され、最適なコストパフォーマンスを提供することでLLMの構築に集中できるようにします。

LLM導入における成熟曲線

参考ドキュメント:Databricks 上の生成 AI と大規模言語モデル (LLM)

LLMの導入には複数のアプローチがあり、図の右側に行くほどより細かなモデルの品質コントロールが可能ですが、難易度とコストが上がります。

以下はそれぞれの特徴をまとめたものです。

商用LLM or OSS LLM +プロンプトエンジニアリング
必要なLLMトレーニングに必要な技術力は最も少なく、LLMモデルを使用したアプリの市場投入までのリスクを軽減しながら、市場で最もパフォーマンスの高いLLMを活用できます。一方で上に挙げたようなセキュリティ上の課題やインターネット上に公開されている情報を元に回答を生成するため特定の業務には商用LLMサービスが利用できない場合もあります。OSS LLMを使用する場合は社内で管理するインフラ上にLLMをデプロイすることで厳しいセキュリティ要件にも対応が可能ですが、商用モデルと比較すると数ヶ月から数年単位で性能が遅れている場合がありますのでOSSモデルの選定は注意が必要です。
商用LLM or OSS LLM + RAG(Retrieval Augmented Generation)
LLMと外部ナレッジ検索の組み合わせでモデルを特定の分野に特化させます （このブログで注力するのはここです）。　ユーザからの問い合わせに企業に固有のカスタム情報をLLMにコンテキストとして付与することでより高度なプロンプトエンジニリングを行います。回答作成までのコンピュート時間は通常のプロンプトエンジニアリングのみの場合と比較すると増加しますが、ハルシネーションを削減し、元のLLMに変更を加えることなく非常に短いリードタイムでLLMが最新の企業固有のデータを活用した回答を生成できるようになります。OSS LLMを使用する場合は社内で管理するインフラ上にLLMをデプロイすることで厳しいセキュリティ要件にも対応が可能です。
商用LLM or OSS LLM ＋ファインチューニング
カスタムデータを使用して追加トレーニングを行い、LLMに対し特定のタスクに対する細かなカスタマイズを行います。RAGと同様に学習済みのLLMを活用できるため、ゼロからLLMを構築する場合もよりもデータセット、トレーニング時間、トレーニング環境などのコストを大幅に削減できセキュリティ要件にも対応が可能ですが、LLMに関する専門的な知識が必要となり、再トレーニングしたモデルの市場投入や最新データをモデルへ適用するまでの時間もかかります。また商用LLMをファインチューニングする場合は機能が限られている場合や追加コストが発生する場合があります。

独自LLMのトレーニング
モデルの基礎となるデータセットとコードなどを独自で選定し、モデルを開発することで、既存モデルのバイアス、ハルシネーションなどのモデルの品質を完全にコントロールすることが可能です(その他の方法ではモデルの品質を完全にコントロールすることはできません)。しかしながら、このアプローチはゼロからモデルを開発するため、非常に高コストでリスクも高く、RAGやファインチューニングで開発する場合よりも、LLMに関する専門的な知識とより大きな投資が必要となります。またモデルが汎化性能を獲得するまでには大量の高品質データが必要となるため、通常は開発するLLMが企業のビジネス戦略の中核となるようなユースケースで検討されるアプローチとなります。

方法	データ要件	トレーニング時間	メリット	考慮点
プロンプトエンジニアリング	なし	なし	迅速、費用対効果、トレーニング不要	モデルの専門性、コントロール性が低い
RAG	独自データをベクトル化したデータ	小-中(Enbeddingによるデータのベクトル化)	独自データの動的更新により、追加トレーニング不要で精度向上が可能	プロンプトの増加による推論時間の増加
ファインチューニング	追加トレーニング用データセット	中-長（データサイズによる）	きめ細かなモデルコントロール、高い専門性	ラベル付きデータが必要、追加トレーニング及びチューニングのコスト
独自LLMの開発	大規模データセット（数十億から数兆トークン）	長（数日から数週間）	特定のニーズに合わせた完全なモデルコントロール	開発には極めて多くのリソースが必要

Databricksでは上記いずれのアプローチを選択した場合でも、効率的にLLMを開発・運用するための機能を提供可能ですが、本ブログではDatabricksのLLMプラットフォームとしての優位性をより具体的にご理解いただくため、元のモデルに対する追加トレーニングなしで最新のデータを活用可能であることから注目を集めている、RAG(Retrieval Augmented Generation）によるチャットボットのユースケースにフォーカスしてご説明します。

RAG(Retrieval Augmented Generation）のアーキテクチャ

参考ドキュメント:Databricks での Retrieval Augmented Generation (RAG)

RAGは強力で効率的な生成AI技術であり、ドメイン固有の知識にアクセスする必要があるチャットボットやQ&Aシステムでの活用において多くの成功を示しています。
元のLLMに変更を加えることなく、独自データ（例えば、ビジネスに特化した文書）をプロンプトのコンテキストとして提供することによってモデルのカスタマイズを実現しており、ハルシネーションを減らし、最新の企業固有のデータを元にした回答を生成することでモデルのパフォーマンスを向上させることができます。

ハイレベルのアーキテクチャと主要コンポーネント

RAGチャットボット構築に必要な機能を理解するため、ここではハイレベルの基本アーキテクチャと主要なコンポーネントを説明します。
これらは全てDatabricksの提供する機能で実装可能です。

①レイクハウス（ストレージ＆ガバナンス）

Delta Lakeは、オープンフォーマットを自動的かつ瞬時に変換できる唯一のオープンフォーマットストレージレイヤーです。Delta Lakeは、トランザクション、分析、AIのユースケースのためにあらゆるデータタイプを統合し、ストリーミングとバッチ処理をサポートします。Unity Catalogを利用することで、企業はあらゆるクラウドやプラットフォーム上で、構造化データ、非構造化データ、機械学習モデル、ノートブック、ダッシュボード、ファイルをシームレスにガバナンスすることができます。
Delta Lakeは業界をリードするパフォーマンスを提供し、費用対効果が高く、拡張性の高いレイクハウスの基盤となります。

②データのベクター化処理(ベクターサーチインデックスの作成）

ベクターサーチインデックスを作成/メンテナンスするためにソースドキュメントデータを取り込み、変換処理を行うETLプロセスレイヤです。

Databricksの各種のデータエンジニアリング機能を使ってドキュメントページを取り込み、適切なサイズに分割します。
LangchainフレームワークやLLMトークナイザー等を使用し、ベクトル化が可能なデータを生成します。
Databricks基盤モデルもしくは外部モデルを使用してデータをエンベッディング（数値型の配列データへ変換処理）によりベクトル表現に変換し、ベクターサーチインデックスを作成します。

Databricksは複数のタイプのベクターサーチインデックスをサポートしています。

フルマネージド・ベクターサーチインデックス
ソーステーブルとベクターサーチのエンドポイント名を指定するとDatabricksがソースデータのDeltaテーブルのデータを自動でベクトル化し、ベクターサーチインデックスを自動で作成しデータ同期をします。内部的にDLT(DeltaLiveTables)のパイプラインが実行され、triggeredとcontinuousの2つの更新モードがサポートされています。
セルフマネージド・ベクターサーチインデックス
ソースデータを格納するデルタテーブルのカラムにベクター表現を保存するプロセスをユーザータスクとして実行し、任意のタイミングでベクターサーチインデックスを作成しデータ同期をします。同期処理では内部的にDLT(DeltaLiveTables)のパイプラインが実行され、triggeredとcontinuousの2つの更新モードがサポートされています。
ダイレクト・ベクトル・アクセス・インデックス
Databricks の外部に既存のパイプラインがある場合、または既にベクターデータベースを使用している場合は、そのデータを直接参照させることもあ可能です。この場合、ソースデータからのベクターサーチインデックスの更新を管理するのはユーザーのタスクとなります。

尚、今回の検証ではDatabricksの公式ドキュメントページ（日本語）のコンテンツをスクレイピングで取得し、ETLプロセスによりセルフマネージド・ベクターサーチインデックスとしてDeltaテーブルに格納しています。

③ベクターサービング

参考ドキュメント：Databricksベクターサーチ
メタデータを含むデータのベクター表現を保存しているベクターサーチインデックスに対し類似検索を実行する類似検索エンジンであるDatabricksベクターサーチにより、プロンプトの補完に使用されるコンテンツを返却するレイヤです。Databricksサーバレスコンピュート環境にエンドポイントとして提供され、Databricksベクターサーチやベクターサーチインデックスなどの Vector Search コンポーネントは、UI、 Python SDK、REST API を使用して作成および管理できます。RAG以外のユースケースにも利用可能です。

④モデル(モデルサービング)

参考ドキュメント：Databricksによるモデルサービング
各種LLM、RAGチェーンをホストし管理するレイヤとなり、Databricksサーバレスコンピュート環境で提供されます。Databricksでホストされているか外部でホストされているかに関係なく、すべてのモデルを1つの場所で管理し、1つのAPIでクエリを実行できる統合インターフェイスを提供することで、さまざまなクラウドやプロバイダー間で本番運用のモデルを使用したエクスペリメント、カスタマイズ、およびデプロイのプロセスが簡素化されます。また需要の変化に応じて自動的にスケールアップまたはスケールダウンし、インフラストラクチャのコストを節約しながらパフォーマンスを最適化します。

モデルサービングは、次のモデルをホストするエンドポイントとして機能します

カスタムモデル
MLflow形式でパッケージ化されたPythonモデルです。これらはUnity Catalog またはワークスペースモデルレジストリに登録することでカスタムモデルとしてサービングすることできます。例としては、先にご紹介したRAGチェーンモデルやScikit-Learn、XGBoost、PyTorch、HuggingFaceトランスフォーマーモデルなどがあります。
Databricks基盤モデルとして提供される最新のOSSモデル
Databricksでは人気のあるLlamaやMPTモデルファミリーを含むフルマネージドのLLMモデルセットをFoundation Model APIsとしてすぐに利用できる状態で提供しています。Foundation Model APIsには Llama-2-70B-chat、BGE-Large、Mistral-7B などの最新のOSSモデルがDatabricksのサーバレスインフラストラクチャ内でエンドポイントとして提供されているので、センシティブなデータがサードパーティのサービスを経由する必要がありません。エンドポイントに送信されるトークンあたりの課金で使用することができるので、劇的にコストを削減し、柔軟性を高めます。
外部モデル
商用モデルを含むDatabricksの外部でホストされているモデルです。例としては、OpenAIのGPT-4、AnthropicのClaudeがあります。Databricks環境にホストされているモデル同様にDatabricks上のエンドポイント経由でこれらの外部モデルにアクセスすることにより、レート制限とアクセス制御などの一元管理が可能となります。

⑤RAGチェーン

参考ドキュメント:RAGチェーンを使用した検索
RAGチェーンはユーザークエリーを受け取り、ベクターインデックスから類似したデータを取得し、クエリーとともにそのデータをLLMモデルに送信し回答を取得します。Databricksモデルサービング上にMLflow形式でパッケージ化されたPythonモデルとしてサーバレスコンピュート環境にホストされます。
Langchainフレームワークを使用して実装される以下の処理を実行します。

Databricks Vector Searchからのデータ取得
エンベッディングの取得とベクターインデックスに格納されている独自データ内の類似文書を検索し、回答を作成するためのコンテンツを付与することで問い合わせのプロンプトを補強します。
モデルサービング環境でホストされているLLMモデルへの推論の実行
Databricksモデルサービング環境にデプロイされているLLMに補強されたプロンプトを用いて問い合わせを行い回答を取得します。

⑥モニタリング

参考ドキュメント：Databricks レイクハウスモニタリングの概要
RAGアプリケーションの実稼働ワークフローにおけるデータとモデルのモニタリングを実行するレイヤです。Lakehouse Monitoringは、Databricksモデルサービング環境のエンドポイントからのサービングリクエストの入力と応答 (予測結果) 、レスポンス時間、リソース使用量等を継続的にログに記録し、デルタテーブルに保存することでモデルのモニタリングと診断を簡素化し、ダッシュボード、出力結果に対するアラートなどのプロアクティブな監視が可能なソリューションを提供します。

⑦チャットアプリケーション

任意のツール、言語を使用してユーザが作成するアプリケーションレイヤです。REST-APIを使用してDatabricks上にエンドポイントとしてホストされるRAGチェーンにユーザーリクエストを送信します。
Databrick外部のWebアプリケーションや近日公開予定のLakehouse AppsでDatabricks環境に構築することも可能です。

RAGチャットボットへのQA実行

参考ドキュメント:RAGチェーンを使用した検索

RAGアーキテクチャで必要な機能を実装したLLM環境構築後、ユーザーチャットアプリケーションからチェーンオーケストラーターとしてサーバレスコンピュート環境で起動しているRAGチェーンのエンドポイントに問い合わせを発行できます。
今回はDatabricksの公式ドキュメントページ（日本語）のコンテンツを独自ドキュメントとしてベクターサーチインデックスに格納していますので、RAGチャットボットによる効果確認としてDatabricks製品に特化した質問に正しい回答を生成することができるか確認してみます。

以下が質問文です。Databricksの最新ドキュメントの記載を理解していないと回答できない内容です。

Databricksの新機能であるDatabricks Lakehouse モニタリングの機能概要及び現在利用できるリージョンを教えてください。

ちなみに、ChatGPT3.5では以下の回答でした。昨年プレビューが開始された新機能ですのでChatGPT3.5は回答できませんでした。

RAGチャットボットによるモデル精度向上の確認と処理フロー

では、RAGを使用してDatabaricks上に作成したチャットボットに同じ質問をしてみます。
QA実行の結果と処理フローを以下に示します。

①ユーザー問い合わせテキストをベクトル表現に変換（エンベッディング）

独自データを格納するベクトルデータベースを作成する際に使用したエンベッディング用モデルに対し、ユーザの問い合わせテキストを送信し問い合わせテキストをベクトル表現に変換します。
エンベッディング用モデルはDatabricks基盤モデルとして提供されているBGE Largeを使用しましたが日本語データに対しても問題なく使用できました。
以下はベクトル化された問い合わせテキストの例です。

[-0.0224609375, 0.021240234375, -0.005825042724609375, -0.00814056396484375, -0.0291900634765625, -0.01355743408203125, 0.04510498046875, 0.0401611328125, 0.0168304443359375, 0.038177490234375, 0.00943756103515625, 0.005016326904296875, 0.03338623046875, -0.051025390625, -0.02264404296875, -0.020843505859375, -0.0222015380859375, -0.0200958251953125, -0.03790283203125, 0.0180206298828125]...

②ベクターサーチで類似検索の実行

ベクトルデータベースにクエリを実行し、独自コンテンツに対して類似性検索を実行します。
ベクトル化されたDatabricksの公式ドキュメントページ（日本語）のコンテンツのデータから、問い合わせ内容に近い情報を検索します。

③ユーザの問い合わせに最も関連する独自コンテンツを取得

類似性検索の結果から、ユーザの問い合わせに最も関連する独自コンテンツを取得します。
ここで取得した独自データテキストがオリジナルの質問への回答に使用されます。
以下はベクターサーチの類似検索で取得されたテキストコンテンツの例です。正しい回答の生成に必要なレイクハウスモニタリングに関する情報が含まれているようです。

Databricks レイクハウスモニタリングの概要 \nプレビュー \nこの機能は、 eu-central-1、 eu-west-1、 us-east-1、 us-east-2、 us-west-2、 ap-southeast-2の各リージョンでパブリックプレビュー段階にあります。・・・（中略）・・・\nDatabricks レイクハウスモニタリングを使用すると、アカウント内のすべてのテーブルのデータの統計プロパティと品質を監視できます。また、これを使用して、モデルの入力と予測を含む推論テーブルを監視することで、機械学習モデルとモデルサービングエンドポイントのパフォーマンスを追跡することもできます。

④独自コンテンツを付与したプロンプトエンジニアリング

回答生成に必要なデータを取得後、チャット応答フォーマットに関するテンプレートを使用してプロンプトエンジニアリングを行います。ここで先ほど取得した独自データテキストでオリジナルの質問を補完します。そして補完された問い合わせを回答を行うLLMエンドポイントに送信します。以下はデバックモードで最終的にLLMに送信される質問を確認した際の出力例です。
”質問に答えるために、以下の文脈を使用してください。”に続いて赤文字の部分に先の類似検索でヒットした独自コンテンツが、回答を生成するために必要な情報としてプロンプトに自動的に付与されているのがわかります。

"prompts": ["Human: あなたはDatabricksユーザーのアシスタントです。あなたはDatabricksに関する python、コーディング、SQL、データエンジニアリング、スパーク、データサイエンス、DW、プラットフォーム、API、インフラ管理などの質問に回答してください。答えは必ず日本語で答えてください。質問に答えるために、以下の文脈を使用してください。:\nDatabricks レイクハウスモニタリングの概要 \nプレビュー \nこの機能は、 eu-central-1、 eu-west-1、 us-east-1、 us-east-2、 us-west-2、 ap-southeast-2の各リージョンでパブリックプレビュー段階にあります。・・・（中略）・・・\nDatabricks レイクハウスモニタリングを使用すると、アカウント内のすべてのテーブルのデータの統計プロパティと品質を監視できます。また、これを使用して、モデルの入力と予測を含む推論テーブルを監視することで、機械学習モデルとモデルサービングエンドポイントのパフォーマンスを追跡することもできます。Question: 現在、Databricksの新機能であるDatabricks Lakehouse モニタリングの機能概要及び利用できるリージョンを教えてください。]

⑤回答の生成

LLMで回答を生成しユーザーに送信します。
今回、回答を生成するためのLLMは商用利用可能な日本語LLMであるELYZA-japanese-Llama-2-13b-instructを使用しました。これはMetaがオープンソースとして公開している「Llama 2 13B」をベースに、約180億トークンの日本語テキストで追加事前学習を行った日本語向けLLMモデルで、OSSでありながらGPT3.5を性能を上回るスコアを達成しています。
以下が生成された回答です。

Databricks Lakehouse モニタリングは、現在のデータ完全性、統計分布、ドリフト、機械学習モデルのパフォーマンスの変化をモニタリングできる機能です。現在、eu-central-1、eu-west-1、us-east-1、us-east-2、us-west-2、ap-southeast-2の各リージョンでパブリックプレビュー段階にあります。

今回の例では非常に簡単な質問による動作確認でしたが、Databricks上に作成したRAGチャットボット環境により商用LLMでは回答ができない問い合わせに対し、最新の情報を使用した正確な回答を生成できることが確認できました。

おまけ

上で述べたように今回のRAGチャットボットにおいて回答を生成するためのLLMにはELYZA-japanese-Llama-2-13b-instructを使用して検証を行いました。ダウンロードしたELYZA-japanese-Llama-2-13b-instructをUnityCatalogに登録し、カスタムモデル・サービング・エンドポイントを作成してみましたが問題なく動作しました。

もう少し高度なリクエストを実行してみました。リクエストはこちらです。

クマとアザラシがRetrieval　Augmented Generation(RAG)チャットボットの構築基盤としてDatabricksを選択した理由を語り合う短編小説を400文字以内で書いてください。

生成された短編小説はこちらです。内容、文章とも想像以上のクオリティです！

クマとアザラシは、Retrieval　Augmented Generation(RAG)チャットボットの構築基盤としてDatabricksを選択するに至った理由を語り合いました。クマは、RAGチャットボットを構築する上で、大量のデータを取り扱う必要があると話します。その際、クマは様々なクラウドサービスを検討しましたが、Databricksの性能と機能性に惹かれて選択しました。一方、アザラシは、RAGチャットボットを構築する上で、セキュリティが重要であると話します。アザラシは、Databricksのセキュリティ機能に優れていることに加え、AWSやAzureなどの主要なクラウドサービスと連携している点に魅力を感じ、Databricksを選択しました。クマとアザラシは、RAGチャットボットをDatabricks上で成功裏に構築することができ、満足した表情を浮かべていました。

最後に

Databricksを使用して、LLM導入の課題を解決する方法をRAGチャットボットの構築例を元に確認しました。

RAGアプリケーションで高い品質を達成するには、独自データの品質やモデルのアウトプットを理解するためのツールと、RAGプロセスにおける全てのコンポーネントを組み合わせ、最適化できるプラットフォームが必要となります。
またデータ準備、商用モデルやOSSモデルを含む様々な言語モデルのサポート、継続的に最新データを反映するための処理パイプライン、プロンプトエンジニアリング、カスタムの企業データに対するトレーニング実行環境、スケールアウト可能なモデルサービング環境のように数多くのコンポーネントが関係します。Databricksはデータガバナンスとこれら最先端のML技術を統合したLLM環境を提供します。

データの取り込みと準備は、Databricksのエンジニアリング機能を活かすことで驚くほどシンプルになります。
マネージドインデックスを駆使し、ベクトルサーチを同期させ、最新データを効率的に有効活用します。
Databricksの基盤モデルエンドポイントを使うことで、LLM環境を迅速に構築することが可能です。
サーバレスGPUコンピュート環境を導入し、コストとパフォーマンスを最適化させます。
カスタムモデルのDatabricks環境へのデプロイは、柔軟性とセキュリティを一層向上させます。

Databricksは、迅速かつ効果的な生成AIの導入をサポートする理想的なプラットフォームです。是非、ご検討ください。