🤖

RAG vs Long-Context LLMs vs Self-Route どれを使うべきか?Self-Route論文解説!

2024/11/24に公開

はじめに

こんにちは、Yonemotoです。今回は2024年10月にGoogle Deepmindから発表された「Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach」という論文が非常に面白かったので記事にしました。RAG、LC (Long-Context)、そして論文で提示された新たなハイブリッド手法であるSelf-Routeを解説し、ついでにLCの関連技術であるプロンプト圧縮についても取り上げます。

RAG, LC, Self-Routeの概要

RAG: 低コストな従来手法

みなさんお馴染みのRAGは、外部データベースから関連情報をretrieveし、プロンプトと結合してLLMに参照させる手法です。

  • Pros: 長文のコンテキストを直接モデルに提供する必要がないため、計算リソースが大幅に節約できます。また、GPT-3.5 Turboのようにコンテキスト長が限られ中間迷子(忘却?)現象が起きやすいモデルでは特に有効な手法です。
  • Cons: キーワード検索やベクトル検索など非LLM手法による検索の限界が精度のボトルネックになります。具体的には、以下の4つの場合に精度が落ちやすいです。
    • 一般的すぎる質問への対応困難
      質問が漠然としている場合、効果的なクエリを生成するのが難しく、関連情報を的確に取得できないことがあります。例えば、「XXXに対するグループの意見は?」というような質問では、具体的な答えを見つけるための適切な検索条件を定めるのが難しいです。

    • 複雑で長い質問の理解不足
      質問が複雑かつ長文の場合、RAGのリトリーバーがその内容を正確に理解し、適切な文書を検索するのが難しくなります。このような質問に対しては、LLMが文脈を処理して答える能力が強みとなる一方で、RAGの限界が露呈します。

    • 暗黙的な質問への対応困難
      質問が明確に文脈を提示せず、暗黙的な背景知識や文脈全体の理解を要求する場合、RAGはその意図を読み取ることが難しいです。例えば、「宇宙船の後ろに影ができた原因は?」という質問では、文脈全体を繋ぎ合わせる必要があり、明示的なデータがないためRAGの検索では限界があります。

    • 生成するクエリの適切性への依存
      RAGは、質問を適切なクエリに変換する能力に大きく依存しています。しかし、質問が抽象的であったり、特定の言い回しに依存していたりする場合、リトリーバーが効果的なクエリを生成できないため、正確な情報が取得できない可能性があります。

LC: 長いコンテキストをLLMに渡す手法

LCは、膨大なコンテキスト情報を直接プロンプトに埋め込む手法です。近年のGPT-4o (入力可能トークン数128K)やGemini-1.5-Pro (入力可能トークン数2M)は長い入力を受け取ることができるため、精度を出すという点では非常に優れた手法です。

  • Pros: 複雑で詳細な質問にも対応できます。
  • Cons: 入力トークン数が膨大になるので、生成時間と計算コストが高くなります。多くの場合 (Gemini-1.5-Pro の場合は82%)ではRAGとLCでほぼ同じ出力となるので、時間やコストの高さは無駄になりがちです。

Self-Route: ハイブリッドな手法

Self-Routeは、論文で提示されている新しいアプローチです。実装としては非常にシンプルで、まずは通常のRAG同様にコンテキストとプロンプトを与え、そこで与えられたコンテキストの情報だけでプロンプトに回答可能かどうかをLLMに問います。そこで可能と答えた場合は回答を生成させ、不可能と答えた場合はLCの手法に切り替えるというものです。

our method consists of two steps: a RAG-and-Route step and a long-context prediction step. In the first step, we provide the query and the retrieved chunks to the LLM, and prompt it to predict whether the query is answerable and, if so, generate the answer.
(中略)
For the queries deemed unanswerable, we proceed to the second step, providing the full context to the long-context LLMs to obtain the final prediction (i.e., LC).

結果

Gemini-1.5-Pro の場合、パフォーマンスは LC よりも低くなります。一方、OpenAI モデルでは RAG を使用した回答を拒否する可能性が高くなり、LCにルーティングされる割合が高くなるため、全体的な精度も高くなります。これらの違いは、アライメントの違いによるものである可能性があると言われています。


モデルごとの精度とコスト


top-kのkを変化させたときの精度とコスト

結論 - どれを使うべきか?

近年LLM各モデルの入力可能なトークン数がどんどん大きくなっている中で、筆者はRAGはもはや精度面でのボトルネックになりつつあると思います。そこで、LCやSelf-Routeは、特に複雑なタスクが必要とされる状況において有効であると思いました。

雑談

LCに関連する技術: プロンプト圧縮

coming soon...
ref: https://arxiv.org/abs/2310.06839

関連技術:LLMベースのRAG

論文とはあまり関係ありませんが、ある程度広めにRAGでしぼったうえで、さらに絞り込む作業を小さめのLLM (4o-miniなど)でやらせてからLLMに渡すといった手法もあります。

参考

Discussion