メインコンテンツへジャンプ

検索拡張生成

検索拡張生成(RAG)とは

検索拡張生成(RAG)は、カスタムデータを活用することで大規模言語モデル(LLM)アプリケーションの有効性を向上させるアーキテクチャアプローチです。質問やタスクに関連するデータや文書を検索し、LLM のコンテキストとして提供することRAG は、最新の情報を維持したり、ドメイン固有の知識にアクセスする必要があるチャットボットや Q&A システムのサポートに活用されています。

Databricks についてさらに詳しく

MLOps のビッグブック

MLOps の改善を追求する ML エンジニアやデータサイエンティスト向けに MLOps のベストプラクティスを解説しています。

eBook をダウンロード

LLM の可能性を引き出す

AI で効率を高め、コストを削減

ダウンロード

生成 AI で業界を変革する

RAG を使用した 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 をチャットボットに組み込むことで、社内文書やナレッジベースから、より正確な回答を自動的に導き出します。チャットボットは、カスタマーサポートやウェブサイトのリードフォローアップを自動化し、質問に回答して問題を迅速に解決するために使用されます。
  2. 検索の拡張:LLM を検索エンジンに組み込み、LLM が生成した回答で検索結果を拡張することで、情報クエリに対する回答が向上し、ユーザーが仕事に必要な情報を見つけやすくなります。
  3. ナレッジエンジン(人事やコンプライアンス文書などのデータに基づいた質問):企業のデータを LLM のコンテキストとして使用でき、福利厚生やポリシーといった人事の質問や、セキュリティやコンプライアンスに関する質問など、従業員は簡単に回答を得られます。

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 つあります。これらの手法の概要は、次のとおりです。また、これらは、相互に排他的なものではありません。むしろ、それぞれの長所を活かすために組み合わせることが可能であり、そうすべきです。

手法定義主なユースケースデータ要件利点考慮事項

プロンプトエンジニアリング

プロンプトエンジニアリング

LLM の動作を導く専門的なプロンプトの作成迅速なオンザフライモデルガイダンスなし迅速、費用対効果、トレーニング不要ファインチューニングよりもコントロール性が劣る

検索拡張生成(RAG)

検索拡張生成(RAG)

LLM と外部ナレッジ検索の組み合わせ動的データセットと外部ナレッジ外部ナレッジベース、またはデータベース(ベクトルデータベースなど)動的に更新されるコンテキスト、精度の向上プロンプトの長さと推論計算が増加

ファインチューニング

ファインチューニング

事前学習された LLM を特定のデータセットやドメインに適応ドメイン、またはタスクの専門化何千ものドメイン固有、またはインストラクションの例きめ細かなコントロール、高い専門性ラベル付きデータが必要、計算コスト

事前トレーニング

事前トレーニング

ゼロからの LLM トレーニング独自のタスク、またはドメイン固有のコーパス大規模データセット(数十億~数兆のトークン)特定のニーズにあわせた最大限のコントロール極めて資源集約的

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

検索拡張生成

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

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

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

  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 コールを行うことになります。これは、複雑さ、潜在的な遅延、およびクレデンシャル管理の別のレイヤーが追加されることに注意する必要があります。対照的に、ファインチューニングされたモデルの例では、モデルとそのモデル環境がデプロイされます。

リソース

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

ジェットブルー航空

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

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

シェブロンフィリップス

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

Thrivent Financial

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

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

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

ブログ

eBook

デモ

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

    用語集に戻る