検索拡張生成

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

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

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

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 にお問い合わせください。