Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach

Meta info.

• Authors: Zhuowan Li, Cheng Li, Mingyang Zhang, Qiaozhu Mei, Michael Bendersky
• Paper: https://arxiv.org/pdf/2407.16833
• Affiliation: Google DeepMind
• Published: July 23, 2024

TL; DR

(1) RAG vs. Long-context LLM에 대해, 자원만 충분하다면 결과적으로는 LC LLM이 더 좋은 성능을 보였으나, (2) 비용 측면의 효율을 위해 RAG로 routing하는 approach, Self-Route 제안

Problem States

어떤 조건에서 LC가 RAG보다 낫거나 그렇지 않은지 식별

• LC: 검색 없이 문서 전체 입력
• RAG: query 기반으로 관련성 높은 상위 k개(5개) 하위 passage(문서의 하위 단위. 300개 token씩 자름) 검색 결과를 입력으로 사용

Suggestion

1. RAG vs LC Table 1
   • target: Gemini-1.5-Pro, GPT-4o, GPT-3.5-Turbo
     • retriever: Contriever
   • dataset: LongBench, ∞Bench
     • metrics: ROUGE, F1-score, Accuracy 등
   • result: LC LLM이 일관되게 long context 이해 능력이 더 좋음.
     • Gemini-1.5-Pro 7.6%, GPT-4o 13.1%, GPT-3.5-Turbo 3.6% 등
     • 예외: input length가 model input을 초과하는 경우
       • RAG가 GPT-3.5-Turbo에서 더 나은 성능 (계산 비용 측면에서 여전히 유리)
2. Self-Route
   • motivation: Suggestion 1의 결과(LC-LLM이 더 잘한다) + RAG나 LC-LLM이나 60%는 같은 예측 Figure 2
   • process:
     1. RAG-and-Route Step: query에 검색 정보가 불충분하다면 ‘답변 불가’로 답변 거부하도록 옵션 제공하여 RAG먼저 태움
     2. Long-Context Prediction Step: 앞서 답변 불가인 경우만 골라서 LC-LLM 태움
   • result: LC 대비 input token 개수를 최대 65%까지 줄이면서 LC 성능에 근접 Figure 1
     • Gemini-1.5-Pro기준 LC대비 38% token만 써도 거의 비슷한 성능 보이는 등
     • ablation
       • k(retrieve 개수)는 클수록 RAG 성능 좋아지는 건 일반론이지만 비용 고려시 k=5가 최적
       • RAG 실패의 주요 원인은 multi-step reasoning. 복잡하거나 암시적인 query 역시 실패 요인 Figure 4
       • retriever 바꿔도 비슷해 일반화할 수 있겠다고 제안 (Dragon 과 비교)