我要投稿

在长上下文LLM的时代，RAG是否仍然必要？

发布日期：2024-09-20 06:20:53 浏览次数： 1836 来源：AI帝国

一、结论写在前面

论文标题：In Defense of RAG in the Era of Long-Context Language Models

论文链接：https://arxiv.org/pdf/2409.01666

克服早期生成式大型语言模型（LLMs）的有限上下文限制，检索增强生成（RAG）在过去一直是基于上下文的答案生成的可靠解决方案。最近，长上下文LLMs的出现使得模型能够整合更长的文本序列，使得RAG变得不那么吸引人。最近的研究表明，长上下文LLMs在长上下文应用中显著优于RAG。与现有倾向于长上下文LLM而非RAG的工作不同，论文认为LLMs中的极长上下文会导致对相关信息的注意力减弱，并可能导致答案质量的潜在下降。

论文重新审视了RAG在长上下文回答生成中的有效性。论文观察到，在LLM的上下文中，检索到的块的顺序对回答质量至关重要。与传统RAG将检索到的块按相关性降序排列不同，论文提出在原始文本中保留检索到的块的顺序。论文的实验表明，所提出的顺序保留机制显著提高了RAG的回答质量。

与此同时，使用提出的保序RAG，随着检索块数量的增加，答案质量起初上升然后下降。这是因为，随着检索块的增多，模型能够访问到更多潜在相关的信息，从而提高了检索到生成高质量答案所需正确上下文的机会。然而，随着检索块的增多，引入不相关或干扰信息的可能性也增加。这些多余的信息可能会迷惑模型，导致答案质量下降。因此，权衡在于通过检索更多上下文来提高召回率与通过限制干扰来保持精确度之间。最佳点在于相关与不相关信息的平衡最大化答案质量。超过这一点，引入过多不相关信息会降低模型性能。这解释了将整个长上下文作为LLM输入的方法性能较差的原因。

与Li等人（2024）的结论不同，通过提出的保序机制，RAG相比仅依赖长上下文LLM的同类方法，实现了更高的答案质量。如图4a所示，在∞Bench的En.QA数据集上，仅使用16K检索token，论文使用Llama3.1-70B达到了44.43 F1分数。相比之下，不使用RAG，Llama3.1-70B充分利用128K上下文仅达到34.32 F1分数，GPT-40仅达到32.36 F1分数，Gemini-1.5-Pro在Li等人（2024）的评估下仅获得43.08 F1分数。也就是说，RAG即使在输入长度显著减少的情况下，也能实现更高的 F1分数。

二、论文的简单介绍

2.1 论文的背景

由于早期LLM的上下文窗口长度有限（例如，4096），检索增强生成（RAG）是处理大规模上下文语料库不可或缺的选择。由于答案质量在很大程度上依赖于检索模型的性能，因此在设计RAG系统时，大量的努力都投入到提高检索的召回率/精确度上。

最近，最先进的LLMs支持更长的上下文窗口。例如，GPT-40，Claudi-3.5，Llama3.1、Phi-3和Mistral-Large2都支持128K上下文。Gemini-1.5-pro甚至支持1M上下文窗口。长上下文LLM的近期涌现自然引发了一个问题：在长上下文LLM的时代，RAG是否仍然必要？Li et al.（2024）最近系统地比较了RAG与长上下文（LC）LLM（不使用RAG），并证明LC(long-context) LLM在回答质量方面始终优于RAG。

图1：提出的顺序保留检索增强生成（OP-RAG）与使用长上下文LLM但不使用RAG的方法在coBench的En.QA数据集上的比较。论文的OP-RAG使用Llama3.1-70B作为生成器，显著优于不使用RAG的Llama3.1-70B。

图 2 ：普通RAG与提出的顺序保留RAG的对比。如图所示，文档被分割成13个片段。每个片段附有一个相似度分数。论文检索相似度分数最高的4个片段。普通RAG按分数降序排列片段，而提出的顺序保留RAG则根据片段在原始文档中的顺序排列。

2.2 顺序保留RAG

论文用 d 表示长文本上下文，例如一个长文档。论文将 d 顺序且均匀地分割成 N个片段 c_i。索引 i 表示片段 c_i在 d 中的顺序。即， c_i-1表示 c_i之前的片段，而 c_i+1表示 c_i之后的片段。给定一个查询 q ，论文通过计算 q 的嵌入与 c_i的嵌入之间的余弦相似度来获得片段 c_i的相关性分数：

其中 cos(., .) 表示余弦相似度函数，emb(.) 表示嵌入函数。

图3：上下文长度对RAG性能的影响。评估在coBench的En.QA和EN.MC数据集上进行。

论文检索与最高余弦相似度 d 对应的top-k个片段J这些片段在原始长上下文中的顺序，即论文约束

图2展示了vanilla RAG与提出的顺序保留RAG之间的差异。与vanilla RAG按相似度降序排列片段不同，提出的顺序保留RAG保持了片段在原始文档中的顺序。

2.3 实验

2.3.1 数据集

论文在∞Bench基准测试的En.QA和EN.MC数据集上进行实验，这些数据集专门设计用于长上下文问答评估。具体来说，En.QA包含351个人工标注的问答对。平均而言，En.QA中的长上下文包含150,374个单词。论文使用F1-score作为En.QA的评估指标。EN.MC包含224个问答对，其标注方式与En.QA类似，但每个问题提供四个答案选项。平均而言，EN.MC中的长上下文包含142,622个单词。论文使用准确率作为EN.MC的评估指标。论文注意到还有一个名为LongBench的基准测试。然而，LongBench的平均上下文长度低于20K个单词，不足以评估支持128K-token窗口大小的最新长上下文LLMs。

2.3.2 实现细节

论文在所有数据集上将片段大小设置为128个token。片段之间不重叠。论文默认使用BGE-large-en-v1.5来提取查询和片段的嵌入。

2.3.3 消融实验

论文评估了上下文长度对提出的保序RAG性能的影响。由于每个块包含128个token，上下文长度为128 m，其中m是作为生成答案上下文检索块的数量。如图3所示，随着上下文长度的增加，性能最初有所提升。这是因为更多的上下文可能更有机会覆盖相关块。然而，随着上下文长度进一步增加，答案质量下降，因为使用了更多不相关的块作为干扰。

具体来说，Llama3.1-8B模型在EN.QA数据集和EN.MC数据集上的性能峰值出现在上下文长度为16K时，而Llama3.1-70B模型在EN.QA上的最佳性能出现在48K，在EN.MC上为32K。Llama3.1-70B的峰值点晚于Llama3.1-8B模型，这可能是因为更大规模的模型具有更强的能力来区分无关的干扰。

图 4：提出的顺序保留RAG与普通RAG的比较。评估在coBench的En.QA和EN.MC数据集上进行，使用Llama3.1-70B模型

顺序保留RAG与普通RAG的比较。如图4 所示，当检索的块数较少时（例如，8），提出的顺序保留RAG相对于普通RAG的优势并不显著。相反，当检索的块数较多时，论文的顺序保留RAG显著优于普通RAG。具体来说，在EN.QA数据集上，当检索的块数为128时，普通RAG仅达到38.40 F1分数，而论文的顺序保留RAG达到44.43 F1分数。在EN.MC数据集上，检索192个块时，普通RAG仅达到81.22的准确率，而论文的顺序保留RAG达到88.65的准确率。

2.3.4 主要结果

论文将提出的顺序保留RAG与两类基线进行比较。第一类方法使用不带RAG的长上下文LLM。如表1所示，没有RAG时，LLM需要输入大量的token，这既低效又昂贵。

相比之下，提出的顺序保留RAG不仅显著减少了token数量，还显著提高了答案质量。例如，使用Llama3.1-70B模型，没有RAG的方法在EN.QA上仅达到34.26的F1分数，平均输入117K个token。

相比之下，论文的OP-RAG在输入48K个token时达到47.25的F1分数。第二类基线采用SELF-ROUTE机制（Li et al., 2024），该机制根据模型自我反思将查询路由到RAG或长上下文LLM。如表1所示，论文的方法显著优于在LLMs输入中使用少得多的token。

表1：不带RAG的长上下文LLM、SELF-ROUTE机制（Li et al., 2024）与提出的顺序保留（OP）RAG的比较。

53AI，企业落地应用大模型首选服务商

产品：大模型应用平台+智能体定制开发+落地咨询服务

承诺：先做场景POC验证，看到效果再签署服务协议。零风险落地应用大模型，已交付160+中大型企业

160+中大型企业正在使用53AI

立即咨询预约演示

百度智能云邀53AI：共创AI新纪元，启航智能新时代

2024-05-27

钉钉恒星计划：53AI与百余位企业家及钉钉生态伙伴，共议“AI 浪潮下的新机遇”

2024-05-22

热点资讯

GraphRAG+Ollama 本地部署，保姆教程，踩坑无数，闭坑大法

2024-07-18

RAGFlow：基于OCR和文档解析的下一代 RAG 引擎

2024-05-05

微软开源的GraphRAG解读

2024-07-09

基于Llama 3 构建RAG语音助手：将本地 RAG 与 Qdrant、Whisper 和 LangChain 集成

2024-05-19

深入解析 Graph RAG：提升语言模型问答能力的创新策略

2024-07-09

RAG框架，都在这了!

2024-06-20

Prompt工程师必备：复旦重磅 | 最佳RAG实践长什么样的？

2024-07-07

下一代 RAG 技术来了！微软正式开源 GraphRAG：大模型行业将迎来新的升级？

2024-07-07

GraphRAG：终极 RAG 引擎 - 语义搜索、嵌入、矢量搜索等等！

2024-07-08

【文档智能 & RAG】RAG增强之路：增强PDF解析并结构化技术路线方案及思路

2024-07-09

大家都在问

RAG vs ICL：AI大模型的记忆术和临场发挥，谁才是最强辅助？

2024-11-06

企业如何从0到1构建RAG系统？

2024-11-06

RAG 系统的分块难题：小型语言模型如何找到最佳断点？

2024-11-05

实操｜如何优雅的实现RAG与GraphRAG应用中的知识文档增量更新？

2024-11-04

全网最全国内Agent平台深度测评：扣子、Dify、FastGPT，谁是你的Agent开发首选？

2024-10-27

微软研究院新突破：如何让AI在专业领域更靠谱？

2024-10-25

语义分块真的有效吗？

2024-10-21

突破传统RAG局限：GraphRAG如何提升大模型问答能力？

2024-10-21

开箱即用的企业大模型应用平台

工作+AI

业务+AI

AIx业务

大模型咨询

大模型定制

相关资讯

160+中大型企业正在使用53AI

百度智能云邀53AI：共创AI新纪元，启航智能新时代

钉钉恒星计划：53AI与百余位企业家及钉钉生态伙伴，共议“AI 浪潮下的新机遇”

热点资讯

GraphRAG+Ollama 本地部署，保姆教程，踩坑无数，闭坑大法

RAGFlow：基于OCR和文档解析的下一代 RAG 引擎

微软开源的GraphRAG解读

基于Llama 3 构建RAG语音助手：将本地 RAG 与 Qdrant、Whisper 和 LangChain 集成

深入解析 Graph RAG：提升语言模型问答能力的创新策略

RAG框架，都在这了!

Prompt工程师必备：复旦重磅 | 最佳RAG实践长什么样的？

下一代 RAG 技术来了！微软正式开源 GraphRAG：大模型行业将迎来新的升级？

GraphRAG：终极 RAG 引擎 - 语义搜索、嵌入、矢量搜索等等！

【文档智能 & RAG】RAG增强之路：增强PDF解析并结构化技术路线方案及思路

大家都在问

RAG vs ICL：AI大模型的记忆术和临场发挥，谁才是最强辅助？

企业如何从0到1构建RAG系统？

RAG 系统的分块难题：小型语言模型如何找到最佳断点？

实操｜如何优雅的实现RAG与GraphRAG应用中的知识文档增量更新？

全网最全国内Agent平台深度测评：扣子、Dify、FastGPT，谁是你的Agent开发首选？

微软研究院新突破：如何让AI在专业领域更靠谱？

语义分块真的有效吗？

突破传统RAG局限：GraphRAG如何提升大模型问答能力？

热门标签