検索拡張生成（RAG）

RAGの仕組み

RAG は、外部データソースから取得した文脈に応じたリアルタイム情報を注入することで、言語モデルの出力を強化します。ユーザーがクエリを送信すると、システムはまず検索モデルを作動させ、ベクトルデータベースを用いて意味的に類似するドキュメントやデータベース、その他の情報源を特定・取得します。特定された情報は元の入力プロンプトと組み合わされ、生成AIモデルに送られ、新しい情報を統合した応答が生成されます。 これにより、大規模言語モデル（LLM）は学習済みデータだけに依存するのではなく、企業固有のデータや最新のデータに基づいた、より正確で文脈に即した回答を出すことが可能になります。

RAG パイプラインは、ドキュメントの準備と分割（chunking）、ベクトルインデックス化、検索（retrieval）、プロンプト拡張のステップで構成されます。

このプロセスフローにより、開発者はモデルを再学習することなくデータソースを更新でき、カスタマーサポート、ナレッジベース、内部検索といった分野で拡張性が高くコスト効率の良いLLMアプリケーションを構築できるようになります。

検索拡張生成アプローチは、どのような課題を解決するのでしょうか。

問題 1：LLM モデルはユーザー個別のデータを把握していない

LLM は深層学習モデルを使用し、膨大なデータセットで学習することで、新しいコンテンツを理解し、要約し、生成します。ほとんどの LLM は、さまざまな公開データでトレーニングされているため、1 つのモデルで多くの種類のタスクや質問に対応できます。ひとたびトレーニングされると、多くの LLM はトレーニングデータのカットオフポイントを超えるデータにアクセスする能力を持ちません。そのため、LLM は静的な存在となり、トレーニングを受けていないデータについて質問されると間違った回答をしたり、古い回答を返したり、ハルシネーション（幻覚）を起こしたりすることがあります。

問題 2：AI アプリケーションはカスタムデータを活用しなければ効果的ではない

LLM が適切で具体的な回答をするためには、組織がその領域を理解し、大雑把で一般化された回答ではなく、データから回答を提供するモデルが必要です。例えば、企業が LLM を使用してカスタマーサポートボットを構築した場合、そのソリューションは顧客の質問に対して企業固有の回答をしなければなりません。また、社内の人事データに関する従業員の質問に答える社内 Q&A ボットを構築している企業もあります。企業がモデルを再トレーニングすることなく、これらのソリューションを構築するにはどうすればよいのでしょうか。

解決策：検索拡張は今日の業界標準

独自のデータを使用する簡単で一般的な方法は、LLM モデルに問い合わせるプロンプトの一部としてデータを提供することです。これは検索拡張生成（RAG）と呼ばれ、関連データを検索し、LLM の拡張コンテキストとして使用します。RAG ワークフローは、トレーニングデータから得られる知識だけに頼るのではなく、関連する情報を引き出し、静的な LLM をリアルタイムのデータ検索につなげます。

RAG アーキテクチャを使用すると、企業はどんな LLM モデルでも導入できます。モデルのファインチューニング（微調整）や事前トレーニングにコストや時間をかけることなく、少量のデータを与えるだけで組織に関連する結果を返すように LLM モデルを拡張できます。

RAG のユースケース

RAG には、さまざまなユースケースがあります。最も一般的なものは、次のとおりです。

1. Q&A チャットボット: 大規模言語モデル（LLM）をチャットボットに組み込むことで、企業の文書やナレッジベースから自動的により正確な回答を導き出すことが可能になります。チャットボットはカスタマーサポートやウェブサイトでのリード対応を自動化し、質問に答えたり問題を迅速に解決したりするために利用されます。

   例えば、多国籍のデータ仲介・消費者信用調査会社である Experian は、社内外のニーズに応えるチャットボットを構築しようとしました。しかし、従来のチャットボット技術では需要に対応する拡張性が不足していることが判明しました。そこで Databricks Data Intelligence Platform 上に生成AIチャットボット「Latte」を構築することで、プロンプト処理やモデル精度を改善し、さまざまなプロンプトを試し、出力を洗練し、GenAI技術の進化に迅速に適応する柔軟性を獲得しました。

2. 検索拡張: LLM を検索エンジンに統合し、検索結果を LLM が生成した回答で補強することで、情報クエリに対する精度を高め、ユーザーが必要な情報をより簡単に見つけられるようにします。

3. ナレッジエンジン: 人事（HR）やコンプライアンス関連文書などの企業データを LLM の文脈として活用することで、従業員が福利厚生や規則に関する質問、セキュリティやコンプライアンスに関する質問に対して容易に回答を得られるようになります。

   この仕組みの導入事例として、東南アジアの大手自動車グループ Cycle & Carriage が挙げられます。彼らは Databricks Mosaic AI を活用して RAG チャットボットを開発し、技術マニュアル、カスタマーサポート記録、業務プロセス文書といった独自のナレッジベースにアクセスすることで、生産性と顧客エンゲージメントを改善しました。これにより、従業員は自然言語による検索で文脈に基づいたリアルタイム回答を得られるようになりました。

RAG のメリット

RAG アプローチには、次のような主な利点があります。

1. 最新かつ正確な回答の提供：RAG は、LLM の回答が静的で古いトレーニングデータのみに基づくものではないことを保証します。むしろ、モデルは最新の外部データソースを使用して回答を提供します。
2. 不正確な応答やハルシネーションの低減：LLM モデルの出力を関連する外部ナレッジに基づかせることで、RAG は不正確な情報や捏造された情報（ハルシネーションとも呼ばれる）で回答するリスクを軽減しようと試みます。出力には原典の引用を含めることができ、人による検証が可能です。
3. ドメインに特化した適切な回答の提供：RAG を使用することで、LLM は組織の専有データやドメイン固有のデータにあわせた、文脈に関連した回答を提供できるようになります。
4. 効率的でコストパフォーマンスが高い：ドメイン固有のデータで LLM をカスタマイズする他のアプローチと比較すると、RAG はシンプルでコスト効率に優れています。組織は、モデルをカスタマイズすることなく RAG を導入できます。これは、モデルを新しいデータで頻繁に更新する必要がある場合に特に有益です。

どのような場合に RAG を使用し、どのような場合にモデルをファインチューニングするのでしょうか？

RAG は導入初期のアプローチとして最適です。簡単で、いくつかのユースケースには十分である可能性があります。ファインチューニング（微調整）は、LLM の挙動を変更したいときや、別の「言語」を学習させたいときなど、異なる状況において最も適切です。これらは、相互に排他的なものではありません。将来のステップとして、ドメイン言語と望ましい出力形式をよりよく理解するために、モデルのファインチューニングを検討することが可能です。

LLM をデータでカスタマイズしたい場合、どのような選択肢があり、どの方法（プロンプトエンジニアリング vs. RAG vs. ファインチューニング vs. 事前学習）がベストなのでしょうか？

組織のデータで LLM アプリケーションをカスタマイズする際に考慮すべきアーキテクチャパターンは、4 つあります。これらの手法の概要は、次のとおりです。また、これらは、相互に排他的なものではありません。むしろ、それぞれの長所を活かすために組み合わせることが可能であり、そうすべきです。

どのような手法を選択するかにかかわらず、適切に構造化され、モジュール化された方法でソリューションを構築することで、組織は反復し、適応するための準備を整えることができます。このアプローチについて詳しくは、MLOps のビッグブックをご覧ください。

RAG 実装における一般的な課題

大規模に RAG を実装する際には、いくつかの技術的・運用的な課題が発生します。

1. 検索品質: どんなに強力な LLM であっても、不適切または低品質な文書を取得すると誤った回答を生成してしまいます。そのため、埋め込みモデルの選定、類似度指標、ランキング戦略を慎重に設計した効果的な検索パイプラインが不可欠です。
2. コンテキストウィンドウの制約: 膨大な文書を参照できる一方で、過剰にコンテンツを注入すると、情報が切り捨てられたり、回答が薄まるリスクがあります。チャンク化の戦略は、意味的な一貫性とトークン効率のバランスを取る必要があります。
3. データの鮮度: RAG の強みは最新情報を取り込める点ですが、文書インデックスは更新されなければすぐに陳腐化します。定期的なインジェスト処理や自動更新を確保することで、幻覚（hallucination）や古い情報の提示を防げます。
4. レイテンシ（遅延）: 大規模データセットや外部 API を扱う際、検索・ランキング・生成処理における遅延が問題となる可能性があります。
5. RAG の評価: RAG はハイブリッド型であるため、従来の AI 評価手法では十分ではありません。出力の正確性を評価するには、人間による判断、関連度スコア、根拠性のチェックを組み合わせる必要があります。
    

RAG アプリケーションのリファレンスアーキテクチャとは

特定のニーズやデータのニュアンスに応じて、検索拡張生成システムを実装するには、さまざまな方法があります。以下は、一般的に採用されているワークフローの 1 つで、プロセスの基本的な理解を提供するものとしてご紹介します。

1. データの準備：文書データはメタデータとともに収集され、PII 処理（検出、フィルタリング、再編集、置換）などの最初の前処理が行われます。RAG アプリケーションで使用するためには、埋め込みモデルの選択と、これらの文書をコンテキストとして使用する下流の LLM アプリケーションに基づいて、文書を適切な長さにチャンクする必要があります。
2. 関連データをインデックス化：文書の埋め込みを作成し、このデータでベクトル検索インデックスを作成します。
3. 関連データの取得：ユーザーのクエリに関連するデータの一部を取得します。テキストデータは、LLM で使用されるプロンプトの一部として提供されます。
4. LLM アプリケーションの構築：プロンプト拡張のコンポーネントをラップし、LLM をエンドポイントにクエリします。このエンドポイントは、シンプルな REST API を介して Q&A チャットボットなどのアプリケーションに公開できます。

また、Databricks は、RAG アーキテクチャの主要なアーキテクチャ要素についても推奨しています。

• ベクトルデータベース：LLM アプリケーションの中には（全てではありませんが）、高速な類似性検索のためにベクトルデータベースを使用するものがあります。ほとんどの場合、LLM クエリでコンテキスト、またはドメインの知識を提供します。デプロイされた言語モデルが最新の情報にアクセスできるように、ベクトルデータベースの定期的な更新をジョブとしてスケジュールすることができます。ベクトルデータベースから情報を取得し、LLM コンテキストに取り込むロジックは、MLflowLangChain または PyFunc モデルフレーバーを使用して MLflow に記録されるモデルアーティファクトにパッケージ化できることに注意してください。
• MLflow LLM Deployments または Model Serving： サードパーティの LLM API が使用されている LLM ベースのアプリケーションでは、外部モデルに対する MLflow LLM Deployments または Model Serving のサポートは、OpenAI や Anthropic などのベンダーからのリクエストをルーティングするための標準化されたインターフェースとして使用できます。エンタープライズグレードの API ゲートウェイを提供することに加え、MLflow LLM Deployments または Model Serving は、API キー管理を一元化し、コスト管理を実施する機能を提供します。
• Model Serving：サードパーティの API を使用する RAG の場合、1 つの重要なアーキテクチャ上の変更は、LLM パイプラインが Model Serving エンドポイントから内部またはサードパーティの LLM API への外部 API コールを行うことになります。これは、複雑さ、潜在的な遅延、およびクレデンシャル管理の別のレイヤーが追加されることに注意する必要があります。対照的に、ファインチューニングされたモデルの例では、モデルとそのモデル環境がデプロイされます。

リソース

• Databricks のブログ
  • MLflow AI Gateway と Llama 2 を使用して生成 AI アプリを構築する
  • RAG アプリケーションにおける LLM 評価のベストプラクティス
• Databricks のデモ
• Databricks eBook — MLOps のビッグブック

RAG を使用している Databricks のお客さま

ジェットブルー航空

ジェットブルー航空は、Databricks が提供する企業データによって補完されたオープンソースの生成 AI モデルを使用するチャットボット「BlueBot」を導入しました。このチャットボットは、ジェットブルー航空の全チームが使用でき、役割ごとに管理されたデータにアクセスできます。例えば、財務チームは SAP や規制当局への提出書類のデータを見ることができますが、オペレーションチームはメンテナンス情報しか見ることができません。

こちらの記事もご一読ください。

シェブロンフィリップス

シェブロンフィリップスケミカルは、Databricks を使用して文書プロセスの自動化を含む生成 AI イニシアチブをサポートしています。

Thrivent Financial

Thrivent Financial では、より適切な検索、より要約された利用しやすい知見の作成、エンジニアリングの生産性向上のために生成 AI に注目しています。

検索拡張生成についての参考情報

RAG に関する多くの資料がございます。ぜひご覧ください。

ブログ

• Databricks で高品質の RAG アプリケーションを作成する
• Databricks ベクトル検索パブリックプレビューのご紹介
• リアルタイムの構造化データで RAG アプリケーションの応答品質を向上
• 基盤モデル機能で生成 AI アプリをより速く構築する方法
• RAG アプリケーションにおける LLM 評価のベストプラクティス
• MLflow AI Gateway と Llama 2 を使用した生成 AI アプリの構築（独自データを用いた RAG を使用してより高い精度を達成）

eBook

• MLOps のビッグブック

デモ

• 検索拡張生成（RAG）、Llama2-70B（MosaicML 推論）、ベクトル検索を使用した LLM チャットボットの展開

LLM および検索拡張生成（RAG）プロジェクトについては、Databricks にお問い合わせください。

RAG 技術の未来

RAG は、応急的な仕組みから急速に進化し、エンタープライズ AI アーキテクチャの基盤的コンポーネントになりつつあります。LLM がより強力になるにつれ、RAG の役割も変化し、単に知識の隙間を埋める存在から、構造化され、モジュール化され、より知的なシステムへと進化しています。

RAG の発展の一例は ハイブリッドアーキテクチャ です。ここでは、RAG がツール、構造化データベース、関数呼び出しエージェントと統合されます。これにより、RAG は非構造データの基盤を提供し、構造化データや API が精密なタスクを処理する仕組みが実現します。これらのマルチモーダルアーキテクチャは、より信頼性の高いエンドツーエンドの自動化を可能にします。

もう一つの大きな進展は retriever-generator の共同学習 です。これは、RAG のリトリーバーとジェネレーターを同時に訓練し、互いの回答品質を最適化するモデルです。この仕組みにより、手動のプロンプト設計や微調整の必要性が減り、適応的学習、幻覚（hallucination）の削減、全体的な性能向上が期待されます。

LLM アーキテクチャが成熟するにつれて、RAG はよりシームレスで文脈に応じた仕組みへと進化するでしょう。有限の記憶や情報ストアを超え、リアルタイムデータフロー、複数文書にわたる推論、持続的なメモリを処理できる新しいシステムが登場し、知識豊富で信頼できるアシスタントとして機能するようになります。

よくある質問（FAQ）

Retrieval Augmented Generation（RAG）とは何ですか？
RAG は、関連する文書を検索してプロンプトに組み込み、LLM を強化する AI アーキテクチャです。これにより、モデルを再学習することなく、より正確で最新かつドメイン特化した応答を可能にします。

ファインチューニングの代わりに RAG を使うべきタイミングは？
ファインチューニングのコストや複雑さを避けつつ、動的データを取り込みたいときに RAG を利用します。正確でタイムリーな情報が求められるユースケースに最適です。

RAG は LLM の幻覚（hallucination）を減らせますか？
はい。RAG は取得した最新コンテンツに基づいて応答を生成するため、幻覚の発生を抑えます。特に、医療、法律、エンタープライズサポートのように高い正確性が求められる分野で有効です。

RAG に必要なデータはどのようなものですか？
RAG は非構造化テキストデータ（PDF、メール、社内文書など）を利用します。通常はベクトルデータベースに格納され、適切なインデックス作成と定期的な更新によって関連性を維持します。

RAG システムはどのように評価しますか？
RAG の評価は、人による判断、関連性スコア、根拠の有無の確認、タスク固有の性能指標を組み合わせて行います。さらに、retriever と generator の共同学習により、モデル同士が相互に最適化することで評価の効率化が進む可能性があります。