RAGパイプラインのパフォーマンスを向上させる方法
Retrieval Augmented Generation(RAG)アプリケーションの人気が高まるにつれ、そのパフォーマンスを向上させることへの関心が高まっています。この記事では、RAGパイプラインを最適化するすべての可能な方法を紹介し、主流のRAG最適化戦略をすばやく理解できるように対応する図解を提供します。
注意すべき点は、これらの戦略とテクニックをRAGシステムにどのように統合するかに焦点を当て、ハイレベルな探索を提供するに過ぎないということです。しかし、複雑な詳細を掘り下げたり、ステップバイステップの実装をガイドすることはありません。
標準的なRAGパイプライン
下図は最も単純なバニラRAGパイプラインを示している。まず、ドキュメントチャンクがベクターストア（Milvusや Zilliz cloudなど）にロードされます。次に、ベクターストアはクエリに関連するTop-Kのチャンクを検索する。これらの関連チャンクはLLMのコンテキストプロンプトに注入され、最終的にLLMは最終的な回答を返す。
様々なタイプのRAG強化技術
RAGパイプラインステージにおける役割に基づいて、様々なRAG強化アプローチを分類することができる。
- クエリ強化：RAG入力のクエリプロセスを変更、操作して、クエリの意図をより適切に表現、処理する。
- インデクシングの強化：マルチチャンキング、ステップワイズインデックス、マルチウェイインデックスなどのテクニックを使ってチャンキングインデックスの作成を最適化する。
- レトリーバーの強化：検索プロセス中に最適化技術や戦略を適用する。
- ジェネレーターの強化：LLMのプロンプトを組み立てる際に、プロンプトを調整・最適化し、より良い応答を提供する。
- RAGパイプラインの強化：RAGパイプラインの主要なステップを最適化するためのエージェントやツールの使用を含め、RAGパイプライン全体のプロセスを動的に切り替える。
次に、それぞれのカテゴリーにおける具体的な手法を紹介する。
クエリの強化
クエリー体験を向上させる4つの効果的な方法を探ってみましょう：仮定の質問、仮定のドキュメント埋め込み、サブクエリ、ステップバックプロンプトです。
仮定の質問の作成
仮定の質問を作成するには、LLMを利用して、各文書チャンク内のコンテンツについてユーザーが質問する可能性のある複数の質問を生成します。ユーザーの実際のクエリがLLMに到達する前に、ベクトルストアは実際のクエリに関連する最も関連性の高い仮定の質問を、対応するドキュメントチャンクとともに取得し、LLMに転送します。
この方法論は、クエリ間の検索に直接関与することで、ベクトル検索プロセスにおけるクロスドメインの非対称性問題を回避し、ベクトル検索の負担を軽減する。しかし、仮想的な質問を生成する際に、さらなるオーバーヘッドと不確実性が発生する。
HyDE (仮説的文書埋め込み)
HyDEはHypothetical Document Embeddingsの略。LLMを活用し、文脈情報のないユーザーからの問い合わせに対して、「仮説文書」または偽の回答を作成します。この偽の回答はベクトル埋め込みに変換され、ベクトルデータベース内の最も関連性の高い文書チャンクにクエリーされる。その後、ベクトルデータベースはトップKの最も関連性の高いドキュメントチャンクを検索し、LLMと元のユーザークエリに送信し、最終的な回答を生成する。
この方法は、ベクトル検索におけるクロスドメインの非対称性に対処するという点で、仮説的質問手法に似ている。しかし、計算コストの増加や偽の回答を生成する不確実性などの欠点もあります。
詳しくはHyDEの論文を参照してください。
サブクエリの作成
ユーザークエリが複雑すぎる場合、LLMを使用して、ベクトルデータベースとLLMに渡す前に、より単純なサブクエリに分解することができます。例を見てみましょう。
MilvusとZilliz Cloudの機能の違いは何ですか？」この質問は非常に複雑で、ナレッジベースの中に簡単な答えがないかもしれません。この問題に取り組むために、2つの単純なサブクエリに分割することができます：
- サブクエリ1："Milvusの特徴は？"
- サブクエリ2："Zilliz Cloudの特徴は？"
これらのサブクエリができたら、それらをすべてベクトル埋め込みに変換してベクトルデータベースに送る。そしてベクトル・データベースは、各サブクエリに最も関連性の高いTop-Kの文書チャンクを見つける。最後に、LLMはこの情報を使ってより良い回答を生成する。
ユーザークエリをサブクエリに分解することで、複雑な質問であっても、システムが関連する情報を見つけやすくし、正確な回答を提供することができる。
ステップバックプロンプトの作成
複雑なユーザークエリを単純化するもう一つの方法は、ステップバックプロンプトを作成することです。この手法では、LLMを使用して、複雑なユーザーからの質問を「ステップバック・クエスチョン」**に抽象化する。次に、ベクトルデータベースはこれらのステップバッククエスチョンを使って、最も関連性の高いドキュメントチャンクを検索する。最後に、LLMはこれらの検索された文書チャンクに基づいて、より正確な回答を生成する。
このテクニックを例で説明しよう。次のクエリを考えてみましょう。このクエリは非常に複雑で、直接答えるのは簡単ではありません：
元のユーザークエリ"100億レコードのデータセットがあり、Milvusに保存してクエリーしたい。可能か？"
このユーザークエリを単純化するために、LLMを使用してより簡単なステップバッククエスチョンを生成することができます：
ステップバック質問"Milvusが扱えるデータセットサイズの上限は？"
この方法は、複雑なクエリに対してより正確な回答を得るのに役立ちます。元の質問をよりシンプルな形に分解することで、システムが関連情報を見つけやすくなり、正確な回答を提供しやすくなります。
インデックスの強化
インデックスの強化は、RAGアプリケーションのパフォーマンスを向上させるもう一つの戦略です。ここでは、3つのインデックス強化テクニックを紹介します。
文書チャンクを自動的にマージする
インデックスを構築する際、子チャンクとそれに対応する親チャンクという2つの粒度レベルを採用することができます。まず、より細かいレベルで子チャンクを検索する。最初のk個の子チャンクから特定の数n個の子チャンクが同じ親チャンクに属する場合、この親チャンクを文脈情報としてLLMに提供する。
この方法はLlamaIndexに実装されている。
階層インデックスの構築
文書に対するインデックスを作成する場合、文書の要約に対するインデックスと、文書のチャンクに対するインデックスの2つのレベルのインデックスを作成することができる。ベクトル検索プロセスは2つの段階からなる。まず、要約に基づいて関連文書をフィルタリングし、その後、これらの関連文書の中だけで対応する文書チャンクを検索する。
このアプローチは、膨大なデータ量や、図書館コレクション内のコンテンツ検索のようにデータが階層化されている場合に有効である。
ハイブリッド検索と再ランク付け
ハイブリッド検索と再ランク付け技術は、1つ以上の補助的な検索手法とベクトル類似度検索を統合する。次に、再ランカーが、ユーザーのクエリとの関連性に基づいて検索結果を再ランクする。
一般的な補助検索アルゴリズムには、BM25のような語彙頻度ベースの手法や、Spladeのようなスパース埋め込みを利用した大きなモデルがある。再順位付けアルゴリズムには、RRFや、BERTのようなアーキテクチャに似たCross-Encoderのような、より洗練されたモデルがある。
このアプローチは、検索品質を向上させ、ベクトル想起における潜在的なギャップに対処するために、多様な検索手法を活用する。
レトリーバの強化
RAGシステム内のレトリーバーコンポーネントを改良することで、RAGアプリケーションを改善することもできる。レトリーバを強化するための効果的な方法をいくつか探ってみよう。
センテンスウィンドウの検索
基本的なRAGシステムでは、LLMに与えられる文書チャンクは、検索された埋め込みチャンクを包含する大きなウィンドウである。これにより、LLMに提供される情報には、より広い範囲の文脈の詳細が含まれるようになり、情報損失が最小限に抑えられる。センテンスウィンドウ検索技術は、埋め込み検索に使われる文書チャンクと、LLMに提供されるチャンクを切り離す。
しかし、ウィンドウサイズを拡大すると、干渉する情報が追加される可能性がある。我々は、特定のビジネスニーズに基づいて、ウィンドウの拡張サイズを調整することができる。
メタデータのフィルタリング
より正確な回答を得るために、LLMに渡す前に、時間やカテゴリーなどのメタデータをフィルタリングすることで、検索された文書を絞り込むことができる。例えば、複数年にわたる財務報告書が検索された場合、希望する年に基づいてフィルタリングすることで、特定の要件を満たすように情報を絞り込むことができます。この方法は、図書館コレクションのコンテンツ検索など、広範なデータと詳細なメタデータがある状況で効果的です。
ジェネレーターの強化
RAGシステム内のジェネレーターを改良することで、RAGを最適化するテクニックをさらに探求してみよう。
LLMプロンプトの圧縮
検索された文書チャンク内のノイズ情報は、RAGの最終的な回答の精度に大きな影響を与える可能性がある。LLMの限られたプロンプトウィンドウもまた、より正確な回答のためのハードルとなる。この課題に対処するために、私たちは無関係な詳細を圧縮し、重要な段落を強調し、検索された文書塊の全体的な文脈の長さを短くすることができる。
このアプローチは、先に述べたハイブリッド検索とリランキング手法に似ており、リランカーを利用して無関係な文書チャンクをふるい落とす。
プロンプト内のチャンク順序の調整
論文"Lost in the middle"において、研究者はLLMが推論プロセスにおいて、与えられた文書の途中の情報をしばしば見落とすことを観察した。その代わりに、彼らは文書の最初と最後に提示された情報に依存する傾向がある。
この観察に基づき、回答品質を向上させるために、検索されるチャンクの順序を調整することができる。複数の知識チャンクを検索する場合、相対的に信頼度の低いチャンクは中央に、相対的に信頼度の高いチャンクは両端に配置される。
RAGパイプラインの強化
RAGパイプライン全体を強化することで、RAGアプリケーションのパフォーマンスを向上させることも可能です。
自己反省
このアプローチは、AIエージェントに自己反省の概念を取り入れています。では、この手法はどのように機能するのでしょうか？
最初に検索されたTop-Kの文書チャンクの中には曖昧なものがあり、ユーザーの質問に直接答えられない場合がある。このような場合、2回目のリフレクションを行い、これらのチャンクが純粋にクエリに対応できるかどうかを検証することができる。
自然言語推論(NLI)モデルのような効率的なリフレクション手法や、検証のためのインターネット検索のような追加ツールを使ってリフレクションを行うことができる。
この自己反省の概念は、Self-RAG、Corrective RAG、LangGraphなど、いくつかの論文やプロジェクトで研究されている。
エージェントによるクエリルーティング
単純な質問に答えるためにRAGシステムを使うことは、誤解を招いたり、誤解を招くような情報から推論されたりする可能性があるため、使う必要がないこともある。そのような場合、問い合わせの段階でエージェントをルーターとして使用することができます。このエージェントは、クエリがRAGパイプラインを通過する必要があるかどうかを評価する。そうでなければ、LLMが直接問い合わせに対応する。
エージェントは、LLM、小さな分類モデル、あるいはルールのセットなど、様々な形態をとることができる。
ユーザーの意図に基づいてクエリをルーティングすることで、クエリの一部をリダイレクトすることができ、レスポンスタイムを大幅に向上させ、不必要なノイズを顕著に減らすことができる。
クエリ・ルーティング技術をRAGシステム内の他のプロセス、例えばウェブ検索のようなツールの利用時期の決定、サブクエリの実施、画像の検索などに拡張することができる。このアプローチは、RAGシステム内の各ステップがクエリの特定の要件に基づいて最適化されることを保証し、より効率的で正確な情報検索につながる。
まとめ
単純なRAGパイプラインはシンプルに見えるかもしれないが、最適なビジネスパフォーマンスを達成するには、より洗練された最適化技術が必要になることが多い。
この記事では、RAG アプリケーションのパフォーマンスを向上させるための一般的なさまざまなアプローチをまとめました。また、これらの概念とテクニックを素早く理解し、実装と最適化を迅速に行えるように、分かりやすい図解も用意しました。
この記事で挙げた主なアプローチの簡単な実装は、GitHubのリンクから入手できます。
