长上下文能取代RAG吗?

人工智能 新闻
LLM的上下文长度卷到了恐怖的1M,RAG还有存在的必要吗?近日,来自英伟达的研究人员给出了新的答案。

曾几何时,LLM还是憨憨的。

脑子里的知识比较混乱,同时上下文窗口长度也有限。

检索增强生成(RAG)的出现在很大程度上提升了模型的性能。

图片

然而,LLM很快变得强大,上下文窗口长度也迅速膨胀。

现役的主流大模型,比如GPT-4o、Claude-3.5、Llama3.1、Phi-3和 Mistral-Large2等,都支持128K长的上下文,Gemini-1.5-pro甚至达到了1M的长度。

图片

于是人们不禁要问:在长上下文LLM时代,RAG还有存在的必要吗?

这样的疑问是有根据的,之前的一项研究就证明了,长上下文(LC)在答案质量方面始终优于RAG:

图片

论文地址:https://www.arxiv.org/pdf/2407.16833

在这勃勃生机、万物竞发的春天里,RAG当真要失宠了么?

近日,来自英伟达的研究人员重新审视了这个问题,他们发现, LLM上下文中检索块的顺序对于答案质量至关重要。

传统的RAG会将检索到的块按照相关性降序排列,但这篇工作表明,保留原始文本中检索块的顺序,能够显著提高RAG的答案质量。

图片

论文地址:https://arxiv.org/pdf/2409.01666

由此,研究人员提出了保序机制——Order-Preserve RAG(OP-RAG)。

在En.QA数据集上的实验中,OP-RAG方法(Llama3.1-70B)仅使用16K检索到的token,就实现了44.43的F1-score。

图片

相比之下,没有RAG的Llama3.1-70B,在充分利用128K上下文的情况下,只达到了34.32的F1-score。

而GPT-4o和Gemini-1.5-Pro则分别为32.36分和43.08分。

图片

上图显示了每组实验平均输入的token数量,可以认为OP-RAG以很少的资源量达到了超越长上下文的效果。

——这也再次证明了RAG的独特价值。

Make RAG Great Again

RAG曾帮助早期的LLM克服了有限上下文的限制,通过访问最新的信息,显著减少LLM的幻觉,提高了事实准确性。

尽管目前长上下文的研究逐渐获得偏爱,但作者认为超长的语境会导致LLM对相关信息的关注度降低,最终使答案质量下降,而本文提出的OP-RAG则能够用更少的token换来更高的答案质量。

OP-RAG

首先通过以下方式表示长上下文:将长文本d切成N个连续且均匀的块c,ci表示第i块 。给定一个查询q,可以得到ci块的相关性得分(通过计算嵌入之间的余弦相似度):

图片

检索出相似度得分最高的前k个块,但保留这些块在原始长上下文d中的顺序。

图片

上图直观展示了普通RAG与OP-RAG之间的差异:一个长文档被切分为13块并计算了相似度分数。

同样是检索相似度得分最高的前4个块,Vanilla RAG按分数降序重排了,而OP-RAG保留了块之间的相对顺序。

实验设置

研究人员选择了专为长上下文QA评估而设计的EN.QA和EN.MC数据集进行实验。

En.QA由351个人工注释的问答对组成,数据集中的长上下文平均包含150,374个单词,这里使用F1-score作为En.QA的评估指标。

EN.MC由224个问答对组成,其注释与En.QA类似,但每个问题提供四个答案供选择。

En.MC中的长上下文平均包含142,622个单词,这里使用准确性作为En.QA评估的指标。

所有数据集上的块大小都设置为128个token,块之间不重叠,使用BGE-large-en-v1.5的默认设置来获得查询和块的嵌入。

消融研究

上下文长度的影响

作者评估了上下文长度对OP-RAG性能的影响。实验中每个块包含128个token,生成答案时检索块数为128。

如下图所示,随着上下文长度的增加,性能最初会提高。这是因为更多的上下文可能有更大的机会覆盖相关的块。

然而,随着上下文长度进一步增加,答案质量会下降,因为更多不相关的块产生了干扰。

图片

实验中的Llama3.1-8B模型,在EN.QA数据集和EN.MC数据集上,上下文长度为16K时达到性能峰值,而Llama3.1-70B模型在EN.QA上的最佳性能点为16K,在EN.MC上为32K。

Llama3.1-70B的峰值点晚于Llama3.1-8B,可能是因为较大规模的模型具有更强的区分相关块和不相关干扰的能力。

这里有两方面的启示,首先是需要在检索更多上下文来提高召回率,和限制干扰来保持准确性之间进行权衡;

其次,引入过多的不相关信息会降低模型的性能,这也是当前长上下文LLM所面临的问题。

OP-RAG和检索块数

如下图所示,当检索到的块的数量较小(比如8)时,本文提出的保留顺序RAG相对于普通RAG的优势并不明显。

而当检索到的块数量很大时,OP-RAG的性能显著优于普通RAG。

图片

在EN.QA数据集上,当检索到的块数为128时, 普通RAG只能实现38.40的F1-score,而OP-RAG获得了44.43分。

在EN.MC数据集上,检索块数为192时,普通RAG的Accuracy为81.22,而OP-RAG达到了88.65。

实验结果

研究人员将OP-RAG与两种类型的基线进行比较。

第一类方法使用没有RAG的长上下文LLM。如下表所示,在没有RAG的情况下,LLM需要大量token作为输入,效率低且成本高。

相比之下,本文的保序RAG不仅显著减少了所需token数量,而且提高了答案质量。

对于Llama3.1-70B模型,没有RAG的方法在EN.QA数据集上,只能实现34.26的F1-score,且平均需要117K个token作为输入。相比之下,OP-RAG以48K个token的输入获得了47.25的分数。

图片

第二类基线采用SELF-ROUTE机制 ,它根据模型自我反思将查询路由到RAG或长上下文LLM 。如上表所示,OP-RAG方法明显优于在LLM的输入中使用更少token的方法。

责任编辑:张燕妮 来源: 新智元
相关推荐

2024-04-03 10:05:00

LLM性能基准测试

2024-06-06 08:42:01

2024-09-05 08:24:09

2024-01-29 08:49:36

RAG模型检索

2017-05-11 14:00:02

Flask请求上下文应用上下文

2024-11-20 09:36:00

2024-02-26 00:00:00

RAGGeminiLLM

2023-12-10 13:37:23

Python编程上下文管理

2012-12-31 10:01:34

SELinuxSELinux安全

2022-09-14 13:13:51

JavaScript上下文

2023-12-08 13:21:00

模型训练

2022-09-15 08:01:14

继承基础设施基础服务

2023-07-11 10:02:23

2023-03-02 15:30:49

2024-10-11 16:20:00

谷歌AI模型

2017-12-17 17:01:23

限界上下文系统模型

2022-10-28 16:24:33

Context上下文鸿蒙

2020-07-24 10:00:00

JavaScript执行上下文前端

2021-07-26 07:47:36

Cpu上下文进程

2023-10-18 09:25:08

模型推理
点赞
收藏

51CTO技术栈公众号