RAG Fusionが思ってたより凄そう
概要
RAG Fusionは単なる「新たな手法」ではなく「革新的な手法」です。
RAG Fusionは、従来の検索技術の制約を克服し、ユーザーのクエリに対してより豊かで文脈に即した結果を生成するために、RAG、Reciprocal Rank Fusion、生成されたクエリを組み合わせた新しいシステムになっています。
このシステムは、検索結果のリランキングと複数のユーザークエリ生成により、検索の正確性とユーザーの意図との一致を向上させることを目指した手法となっています。
RAGの課題
RAGにはHallucinationの軽減など、多くの利点がある一方で課題もあります。
RAG Fusion開発者の1人(?)であるAdrian H. Raudaschlさん(以降、筆者)は主に以下3つの課題を挙げています。
- 現在の検索技術による制約
- RAGはベクトル検索や語彙検索と同様の制限を受ける
- 人的検索の非効率性
- タイプミスや曖昧なクエリなど、人間は検索システムにクエリを投げるのが得意ではない
- RAGはそこを補完するが、完全に解決したわけではない
- 検索の単純化
- 現在多く使われている検索システムは、質問の背後にある複雑さや文脈を十分に理解できず、単純化しすぎてしまっているため、ユーザーが本当に求めている情報を提供するのに失敗することがある
人間が尋ねたものをただ検索するだけでなく、より高度なLLMを必要とせずに、私たちのクエリの背後にあるニュアンスを把握するシステムが必要です。
これらの課題を解決するため、RAG Fusionを開発したと筆者は言っています。
なぜRAG Fusionなのか
- ギャップへの対処
- 複数のユーザークエリを生成し、結果をリランキングすることで、RAG特有の制約に取り組む。
- 検索の強化
- 「Reciprocal Rank Fusion(RRF)」と「custom vector score weighting(TF-IDFやEmbeddingなど)」を利用して、より包括的で正確な検索結果を提供する
ここでいうギャップは「人間が意図した検索内容」と「検索システムが解釈したクエリ」の隔たりを指していると思います。
RAG-Fusionはこれらの、ユーザーが明示的に尋ねることと、彼らが意図して尋ねることのギャップを埋めることで、通常は隠されてしまっているような知識・意図の発見に近づくことを目指しています。
RAG Fusionのメカニズム
RAG Fusionの基本的な3つのキーテクノロジーはRAGに似ています。
- 汎用的なプログラミング言語(多くはPython)
- ElasticsearchやPineconeのような専用のベクトル検索データベースが文書検索を行う
- ChatGPTのような強力な大規模言語モデルがテキストを作成する
RAG-Fusionの流れ
図1がわかりやすいです。
- 複数クエリの生成: LLMを用いて、ユーザーのクエリを似ているが異なるクエリへと変換
- ベクトル検索: 元のクエリと新たに生成されたクエリに対してベクトル検索を実行
- リランキング: Reciprocal Rank Fusionを用いて、すべての結果を集約し、整える
- Outputの生成: 選び抜かれた結果を新しいクエリと組み合わせ、すべてのクエリとリランキングされた結果のリストを考慮しながら、大規模言語モデルを質の高いOutputへ導く
図1: RAG Fusionの全体像 [1]から引用
それぞれを詳細に見ていきます。
複数クエリの生成
なぜ複数クエリを用いるのか?
従来の検索システムでは、ユーザーは情報を見つけるために一つのクエリを入力することが多いが、このアプローチには限界があります。単一のクエリでは、ユーザーが興味を持っていることの全容を把握できないかもしれないですし、範囲が狭すぎて包括的な結果が得られないかもしれないです。そこで、異なる視点から複数のクエリを生成することが重要になります。
Technical Implementation (Prompt Engineering)
当たり前ですが、プロンプトエンジニアリングが重要になります。
上手く元のクエリと類似しているだけでなく、異なる角度や視点を提供する複数のクエリを生成する必要があります。
例えば、「最新のテクノロジートレンド」というクエリが投げられた場合、以下のようなクエリを生成する必要があります(ChatGPTに出力させました)。
2024年のテクノロジートレンド
次世代技術の最新動向
テクノロジー革新 2024 ハイライト
2024年に注目すべきITトレンド
元記事には具体的なプロンプトは記載されていませんが、プロンプトエンジニアリングや使用するLLMの性能はかなり重要になります。
マルチクエリ生成のフロー図:プロンプトエンジニアリングとLMを活用し、検索の視野を広げ、結果の質を高める. [1]から引用
リランキング (RRF)
Reciprocal Rank Fusion (RRF)は、複数の検索結果リストの順位を組み合わせて、単一の統一されたランキングを作成するものです。
RRFが特に効果的なのは、検索エンジンによって割り当てられた絶対的なスコアではなく、相対的なランクに依存するため、スコアのスケールや分布が異なる可能性のあるクエリからの結果を組み合わせるのに適しているからです。
RRFに関してはさまざまな記事があると思うので、詳しく知りたい場合は調べると良いと思います。
RRFの例. [1]から引用
Outputの生成
ユーザーの意図の保存
複数のクエリを使用する際に、ユーザーの本来の意図が希薄になる可能性があります。
これを軽減するため、プロンプトエンジニアリングで、元のクエリをより重視するようモデルに指示します。
技術的実装
最後に、リランキングされた文書とすべてのクエリは、応答や要約を求めるような典型的なRAGの方法で生成出力を生成するために、LLMプロンプトに渡されます。
これらの技術とテクニックを重ねることで、RAG Fusionは検索技術と生成AIの長所を活用し、高品質で信頼性の高い出力を生成します。
課題
当たり前ですが、課題もあります。筆者は主に2点の課題を挙げています。
冗長すぎることのリスク
RAG-Fusionの奥深さは、時に情報の洪水につながることがあります。出力は、圧倒されるほど詳細になるかもしれません。RAG-Fusionは、物事を説明しすぎる友人のようなものだと考えてください。
コンテキストウィンドウのバランス
複数のクエリー入力や多様な文書セットが含まれると、言語モデルのコンテキストウィンドウにストレスがかかります。役者でごった返す舞台を思い浮かべてください。コンテキストの制約が厳しいモデルの場合、これは首尾一貫性のない、あるいは切り詰められた出力につながる可能性があります。
また、倫理的な側面からも言及を行っています。
- 倫理的な懸念
- ユーザーの自律性
- ユーザーのクエリの操作は、本来の意図から逸脱する可能性があります。AIにどの程度のコントロールを委ねるのか、そしてどの程度のコストがかかるのかを検討することが不可欠です。
- 透明性
- より良い結果を得るためだけでなく、自分のクエリがどのように調整されたかをユーザーが認識できるようにする必要があります。この透明性は、信頼を維持し、ユーザーの意図を尊重するために不可欠です。
- ユーザーの自律性
おわりに
RAG Fusionを知った時は「へ〜〜確かに良さそう」くらいに思っていたのですが、この記事を読んだ後は「革命...?」と思ってしまっています(笑)
早く自分のPJTで試してみたいですね。読んでくれてありがとうございました!
参考文献
[1] Forget RAG, the Future is RAG-Fusion
[2] RAG-Fusion: The Next Frontier of Search Technology
[3] Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods
Discussion