RAG与Long-Context之争—没必要争

大家好，我是刘聪NLP。

随着大模型可以支持的上下文(Context)长度越来越长，网上（好几个群里都在聊这个话题，也来聊几句）竟然出现了RAG与Long-Context之争，是真没必要。。。主要是两者不冲突，并不是非A即B、非B即A的关系。

个人观点：如果类比做检索系统的话，RAG应该算作粗排，而Long-Context可以算是精排。 RAG的本质是通过用户问题从数据库/知识库中找到相关片段内容，再利用大模型查找或总结出答案。Long-Context的本质是将所有文本内容全部灌入到大模型中，用户问一个问题，再利用大模型查找或总结出答案。

本质区别在于外部知识如何给到大模型，以及给多少到大模型。

这也是大家的所“争”之处，因为大模型可以接受的长度越长，那么检索的重要性就会降低，对检索效果的依赖就会降低，也就是为什么有人持观点，未来没有RAG，只有Long-Context。但大模型随着输入长度越长，KV Cache所占资源就越多，成本也会剧增，这也是为什么有人持观点，未来也会有RAG。

那么未来是多远呢？如果未来只是5年，我觉得RAG一定会存在；如果未来是AGI，那么也许不需要RAG。

为什么RAG是粗排，Long-Context是精排

从计算量角度来看，目前RAG是靠检索系统来进行相关内容过滤，一般采用ES、向量匹配等方法，可以理解计算量较小，也就是文本之间交互较少；而Long-Context相当于用户Query与文本交互时，利用了整个大模型参数，即通过Transformer的每一层Attention来定位相关文本片段。

从文本选择角度来看，Long-Context可以类比成人为已经确定了问题的相关内容，而RAG需要借助检索手段来确定问题所涉及的相关内容，有一定的信息损失。

大模型上下文支持的越长，对RAG越友好

RAG是目前大模型落地最快速、最有效、最安全的方式。但RAG依然存在很多问题，例如：文档在切段的过程中会将文本原始语义切割、检索匹配存在准确率的问题。但当大模型Context可以支持更长时，RAG可以对文档不切割甚至少切割，检索可以召回更多内容，Top10不够用我们就来Top100。

• 如果你站边RAG，那么大模型即使支持了Long-Context，它也是大模型；
• 如果你站边Long-Context，那么RAG就是在大模型支持无限Context前的过滤手段。

争与不争的核心问题在于数据库/知识库中内容长度是否会超出大模型所能支持的最大长度。

但检索越好、大模型支持长度越长，对于目前大模型落地、大模型可持续发展都是必不可少的，we are famlily！！！

Long-Context会打击到一些RAG的场景，但不是全部

不可否认，Long-Context会打击到一些RAG的场景。

主要就是数据库/知识库内容不超过大模型最大长度的场景，例如：涉及场景中仅有几篇文档作为参考资料，完全不需要检索，直接暴力解法都给大模型就完事儿了。

但如果超出大模型最大长度的内容，不用检索过滤，请问阁下如何应对。

很多极端的人说可能就不存在领域大模型了，但仔细想想，即使Gemini支持1M Token、Kimi-Chat支持200w字，也就是400多个PDF(假设一个PDF平均有5k字)，垂直领域(不抬杠，这里特指一些大领域)数据何至于此呀。

还有，在场景中针对权限的判定，没必要用大模型来判断，完全可以进行域隔离就行，那么也无需将所有文本给到大模型（节省计算资源）。

PS: 说个题外话，貌似人一辈子也就产生0.3B左右的Tokens（之前群友讨论过这个话题），是不是当模型支持最大长度达到300M时，可以快速复制一个人了。不用微调，直接给库。

你能部署1M Token的大模型服务吗

KV Cache的计算方式是4*Batch Size*模型层数L*注意力维度H*KV Cache长度，要硬支持1M长度的话，确实有些可怕。

当然目前有一些优化方法，滑动窗口、Cache量化等等等（欢迎大家补充），但即使这样由于大模型参数规模较大，显存占用也是很可怕的。并且滑动窗口貌似与感觉与retrieval差不多，都是有损失的。那么若可以接受损失，那么为什么不能接受retrieval。

当然前面聊的内容都没有考虑成本问题，但回归现实，请问有哪些厂家有能力部署支持1M Token的大模型模型服务，或者说部署这样一个模型的性价比如何？

对于ToC，大模型服务由大模型公司进行部署，成本由大模型公司承担，那么考虑的就是如何盈利的问题（当然可以为了梦想不考虑）。

对于ToB，会遇到一个很现实的问题，用了这么多显卡，能来什么？Long-Context相较于RAG来说，能否带来精度的提高，可以带来多少提高，是否会增加延迟，相同显卡情况下部署更大的模型+RAG是否更有性价比。

如果你遇到一个1张T4部署大模型的需求，就知道显示是多么残酷。并不是抬杠，只是我在路上走，目标活下去。

如果你相信AGI，Cache所有文本就不是梦

在技术飞速发展的时代，那么未来有一天，用较小的代价来Cache所有的文本也许不是梦。

但真的有必要吗？

Long-Context和RAG本质是都是让大模型找到更好的答案，真正智能还是要靠模型本身。接受更长的上下文可以侧面反应模型的智能，但模型的智能并不仅仅是接受更长的上下文。

做人不用太极端，世界上也并非是非黑即白，条条大路都通AGI。

---

欢迎多多关注公众号「NLP工作站」，加入交流群，交个朋友吧，一起学习，一起进步！

我们的口号是“生命不止，学习不停”！

往期回顾

刘聪NLP：自我蒸馏方法-减轻大模型微调过程中的灾难性遗忘

刘聪NLP：Yi技术报告细节分享
刘聪NLP：大模型增量预训练新技巧-防止模型灾难性遗忘
刘聪NLP：如何提高LLMs的文本表征(Text Embedding)能力?
刘聪NLP：DEITA-大模型指令微调的数据高效筛选方法
刘聪NLP：1-2B参数规模大模型使用心得及模型汇总
刘聪NLP：大模型微调技巧 | 高质量指令数据筛选方法-MoDS
刘聪NLP：大模型下载使我痛苦
刘聪NLP：大模型微调技巧-在Embedding上加入噪音提高指令微调效果
刘聪NLP：通义千问-Qwen技术报告细节分享
刘聪NLP：如何从数据集中自动识别高质量的指令数据-IFD指标的使用
刘聪NLP：BaiChuan2技术报告细节分享&个人想法
刘聪NLP：领域大模型-训练Trick&落地思考
刘聪NLP：千Star-大模型LLM微调项目-更新
刘聪NLP：Llama2技术细节&开源影响
刘聪NLP：垂直领域大模型的一些思考及开源模型汇总
刘聪NLP：如何评估大模型-LLMs的好坏？
刘聪NLP：大模型流水线并行（Pipeline）实战
刘聪NLP：支持多模态的ChatGLM模型-VisualGLM-6B
刘聪NLP：大模型时代-不进则退
刘聪NLP：大模型LLM-微调经验分享&总结
刘聪NLP：ChatGPT-所见、所闻、所感
刘聪NLP：ACL2022 | DCSR：一种面向开放域段落检索的句子感知的对比学习方法
刘聪NLP：ACL2022 | NoisyTune：微调前加入少量噪音可能会有意想不到的效果
刘聪NLP：总结|Prompt在NER场景的应用
刘聪NLP：PERT：一种基于乱序语言模型的预训练模型
刘聪NLP：常用预训练语言模型（PTMs）总结