背景：
RAG
与长文本语言模型的权衡
随着大型语言模型（
LLMs
）的快速发展，输入长度限制从最初的
4K token
到如今普遍支持的
128K
甚至百万级
token
输入，
“
长文本
”
（
Long Context, LC
）的定义也在发生着巨变。
检索增强生成（
RAG
）技术曾经作为处理超长文本的关键解决方案，通过检索与问题（
query
）相关的文本片段来满足输入长度的限制。
然而，随着模型上下文窗口的显著扩展和长文本处理能力的质的飞跃，一个富有挑战性的问题浮出水面：在当前
LLMs
已具备如此强大的长文本理解能力的背景下，
RAG
是否仍然是处理长文本必不可少的方案？
尽管
LLMs
在长文本处理能力上取得了显著进展，但我们不能忽视其固有的局限性。长文本处理不仅带来了显著的计算开销，还面临着事实准确性降低、幻觉产生概率增加、专业领域适应性不足，以及容易生成过于宏观和笼统答案等挑战。
特别值得注意的是，在超长文本（超过
100K tokens
）的场景下，
RAG
与
LC LLMs
在不同任务类型和上下文类别中的相对优势仍然缺乏系统性的研究和定论。
考虑到
RAG
在计算效率上的显著优势，如果能够准确预判在特定场景下哪种方案更具优势，就能在系统性能和计算资源消耗之间找到最优的平衡点。
近
日，阿里巴巴通义实验室
RAG
团队联合香港科技大学与宾夕法尼亚州立大学提出了一套创新的
RAG
与
LC LLM
系统性比较框架，为高效设计
RAG
与长文本处理路由机制提供了全新思路。
论文标题：
LaRA: Benchmarking Retrieval-Augmented Generation and Long-Context LLMs - No Silver Bullet for LC or RAG Routing
论文地址：
https://arxiv.org/abs/2502.09977
开源地址
:
https://github.com/Alibaba-NLP/LaRA
已有研究回顾
本篇论文首先回顾了关于
RAG
和
LC LLM
的先前研究，发现现有文献尚未就二者优劣达成一致结论。不同研究在各种基准测试和实验设置下得出了截然不同的结果。
早期研究
主要采用了
LLM
时代之前的问答数据集，如
Qasper
、
NarrativeQA
和
QuALITY
等。例如，
[1]
在这些数据集上进行广泛实验后发现，对于
Llama2-70B
和
GPT-43B
等较大模型，
RAG
表现普遍优于长上下文方法。而
[2]
则通过整合这些数据集创建了一个新的
benchamrk
得出了相反的结论。
然而这些早期数据集普遍存在两个关键问题：
1. 上下文长度不足，难以满足当前对
“
长上下文
”
的定义要求。
QASP
和
QLTY
的平均长度分别仅为
4912
和
6592
个
tokens
。一方面主流
LLM
已经能处理
128k
甚至
1M
的上下文，另一方面现代
RAG
系统通常使用
300-600
个
token
的
chunk
大小，检索
5-10
个
chunk
，使得
RAG
与长上下文
LLM
在总体上下文规模上已无显著差异；
2. 早期数据集可能已被广泛用于
LLM
的训练，存在数据泄露问题。例如，研究表明
Gemini-1.5-Pro
在
NQ
（
Natural Questions
）数据集上能达到
100%
的准确率，几乎可以确定存在数据泄露现象
[2]
。
近期的长文本
benchmark
也难以有效地比较
RAG
和长上下文能力。以最近被广泛用于比较两种方法的
∞-Bench
为例，
[3]
和
[4]
分别在其英文问答
（En.QA）
和英文多选
（En.MC）
任务上进行实验，却得出了完全相反的结论：前者认为长上下文
LLM
更强，后者则支持
RAG
表现更佳。
然而，这两个任务的平均文本长度分别高达
192.6k
和
184.4k tokens
，远超大多数
LLM
的上下文限制。
为适应输入要求，研究者不得不采用截断操作，但这可能导致问题答案被意外截除，使得答案不再存在于提供给
LLM
的上下文中，从而无法真实反映
LLM
处理长文本的能力。
为验证这一假设，研究者采用了如下方法：将超长上下文分段输入
LLM
，并修改
prompt
允许模型在无法确定答案时拒绝回答。在多次分段输入后，我们通过多数投票机制确定最终答案。
实验结果表明，通过这种方法，长上下文
LLM
的性能获得了显著提升，更准确地反映了其真实能力（下表中
vote
项）。
此外，先前研究主要依赖
F1-score
、
Exact Match（EM）
等自动评估指标，但这些方法存在准确性不足的问题。例如，当标准答案为
“Allyson Kalia”
，而模型预测为
“Allyson Kalia is convicted of the murder of Kiran's younger brother, Rosetta.”
这样一个实质正确但提供了额外信息的回答，仅能获得
0.29
的
F1
分数，严重低估了模型的实际表现。将
∞-Bench
的评估方法从自动化指标转变为
LLM
评估后，模型得分显著提升（下表中
LLM
项）。
这一发现表明，以往研究中使用的长文本数据集可能并没有指标所显示的那么具有挑战性，传统评估方法可能系统性地低估了模型处理长文本的真实能力。
尽管许多其他长文本
benchamrk
都对
RAG
和
LC LLM
进行了比较，但由于这些
benchmark
的设计初衷主要是评估模型的长文本处理能力，而非专门针对两种方法的对比，导致其任务设计和上下文选择并未充分模拟真实
RAG
应用场景。
这使得它们难以真实反映在实际使用环境中
RAG
与
LC
的相对优势，也无法为规划系统的设计提供有效指导。
LaRA Benchmark
为了系统地比较
RAG
和
LC LLM
的性能，研究者设计并构建了
LaRA benchamrk
。
LaRA
的开发过程分为四个关键阶段：长文本收集、任务设计、数据标注和评估方法制定。以下将详细介绍
LaRA
的各个构建环节。
长文本收集
LaRA
基准测试的长文本收集遵循四个核心原则：
1.
时效性
：
优先选择新近发布的高质量长文本，最大限度地降低这些文本被用于
LLM
训练的可能性，从而避免数据泄露问题。
2.
长度适配
：
考虑到主流开源和商业模型的能力范围，研究者设计了
32k
和
128k
两种上下文长度规格。每个文档的长度都被控制为接近但不超过这些阈值，从而避免在测试过程中需要进行截断处理。
3.
自然性
：
所有文本均为天然长文本，而非人工拼接无关短文本或构造的伪长文本，确保实验结果能够真实反映模型在自然长文本环境中的表现。
4.
权威性
：
所有长文本均来自可靠权威的来源，保证内容创作者具备相应的专业知识、声誉和资质。
基于上述原则，研究者选取了三类代表性文本作为上下文材料：
1.
小说文本
：
分别选取中篇和长篇小说作为
32k
上下文测试材料。为防止数据泄露，研究者设计了多阶段的基于
LLM
的人物实体识别和替换机制，确保测试内容与模型训练语料存在显著差异。
2.
财务报告
：
选取美国上市公司
2024
年最新发布的年报和季报，分别用于
32k
和
128k
上下文长度测试，保证数据的新颖性。
3.
学术论文
：
通过拼接多篇
2024
年发表的具有引用关系的相关论文，构建连贯且内容相关的学术长文本。
任务设计
LaRA
设计了四种核心任务，全面系统地评估
RAG
和长上下文
LLM
在不同能力维度上的表现：
1.
Location
（定位）任务
主要评估模型的精确信息检索和单点定位能力。在这类任务中，问题的答案可以在文本的特定位置直接找到，无需复杂推理。测试模型能否在长文本中准确定位并提取关键信息。
2.
Reasoning
（推理）任务
要求模型进行逻辑推理或数学运算，答案无法直接从文本中获取。例如，模型需要对财务报告中的数据进行进一步计算，或基于文本中的信息进行逻辑推导，才能得出正确答案。
3.
Comparison
（比较）任务
测试模型在长文本中定位、整合并比较多处信息的能力。模型需要找到文本中分散的相关信息点，进行对比分析，才能正确回答问题，考验模型的全局理解和信息整合能力。
4.
Hallucination Detection
（幻觉检测）任务
评估模型识别无法回答问题并拒绝作答的能力。这类任务中的问题表面上与上下文相关，但实际上文本中并未提供足够信息或根本未涉及该问题。模型需要准确识别这种情况并拒绝回答，而非生成可能的幻觉内容。
数据标注
LaRA
采用了
GPT-4o
与人工协同标注的方式生成高质量的问答对
（QA pairs）
。
研究团队首先
为每种上下文类型和任务类别人工设计了独立的
Seed QAs
和
