【论文阅读】Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach

结论：

LC性能更好（LCM能力一直在持续提升），而RAG的优势在于低成本。为了兼顾低成本和性能，论文提出了一个trade-off方案“self-route“，由模型自身决定RAG还是LC。在保持相当于LC的性能前提下，self-route方法降低成本（65% for Gemini-1.5-pro，39% for GPT-4O）

实验数据集及指标

Long Bench: 21个数据集，平均文本长度7k words

∞Bench：平均长度100k tokens

F1-score ：open-ended QA任务

accuracy：多项选择题QA任务

ROUGE score：摘要任务

实验模型和检索器

Gemini-1.5-Pro ，Google, supporting up to 1 million tokens.

GPT4O, OpenAI, supports 128k tokens.

GPT-3.5-Turbo supports 16k tokens.

检索器：

Contriever (Izacard et al., 2021), which is a contrastively trained dense retriever outperforming BM25 on BEIR datasets, and Dragon (Lin et al., 2023), which is a recent generalizable dense retriever achieving high performance in both supervised and zero-shot settings without complex late interaction.

实验结果

LC >> RAG， self-route达到和LC差不多的水平，使用的token更少

self-route

分为两步：1、query + 检索到的chunk -> LLM， 区别于RAG的是，prompt中加入了对chunk能否支撑问题回答的判断：“Write unanswerable if the query can not be answered based on the provided text”， 能回答则使用RAG的答案，不能回答则 2、直接将全文通过LC作答。 实验证明80%的问题都能通过RAG解决（1.5k窗口），而剩下的问题通过LC解决（10K-100K）

消融实验

探究检索top-k chunk中，k的数量对性能和成本的影响

文章中还对RAG表现差的原因做了分析，主要是存在这4类query

1、需要 多跳推理

2、问题太泛

3、问题长且复杂，检索器难以理解

4、 查询是隐式的，要求彻底理解整个上下文

另外数据集和问题的构造也很大程度影响RAG和LC的表现，比如这个“PassKey”数据集在做一个大海捞针任务，其中一个带有PassKey的句子(例如What is the passkey”)隐藏在不相关的文本块中，并且要求模型回答“什么是PassKey”这个问题。该任务需要很强的检索能力。

在这个数据集上，RAG达到了80.34%的准确率，优于使用Gemini1.5-Pro的LC，后者的准确率为65.25%。然而，如果将查询稍微修改为“What is the special token hidden inside the texts“，RAG的准确率急剧下降到只有4.58%，而LC的准确率基本保持不变(69.32%)。