仅用于站内搜索，没有排版格式，具体信息请跳转上方微信公众号内链接
来源|思考机器作者|DouweKiela
本文作者DouweKiela，RAG论文（Retrieval-AugmentedGenerationforKnowledge-IntensiveNLPTasks）作者之一。
以下为全文：
每隔几个月，人工智能领域就会经历类似的模式。一个具有更大上下文窗口的新模型问世，社交媒体上便会充斥着“RAG已死”的宣言。Meta最近的突破再次引发了这场讨论——Llama4Scout惊人的1000万（理论上）token上下文窗口代表着一次真正的飞跃。
但这些论断——无论是针对上下文窗口的突破、微调技术的进步，还是模型上下文协议（MCP）的出现——都误解了RAG的目的，以及为何它在人工智能领域将永远占有一席之地。
五年前，我在Meta基础人工智能研究中心（FAIR，前身为Facebook人工智能研究中心）的团队提出了RAG（Retrieval-AugmentedGeneration，检索增强生成）的概念。RAG的目标是利用外部知识来增强模型，创造一种结合了参数化记忆和非参数化记忆的两全其美的解决方案。
简单来说，RAG通过检索语言模型未经训练的数据源中的相关信息，并将其注入模型的上下文中，从而扩展了语言模型的知识库。
这种方法旨在解决生成式语言模型的许多固有缺陷：
无法访问私有（企业内部）数据：模型通常基于公共数据进行训练，但往往需要那些不断变化和扩展的专有信息。
过时的参数知识：即使模型频繁更新，其训练数据截止日期与当前时间之间总会存在差距。
幻觉和归因问题：模型经常编造听起来合理但错误的信息。RAG通过将回答基于真实来源，并提供引文让用户核实信息，解决了这个问题。
听起来耳熟吗？现在已经不是2020年了，但这些同样的问题至今依然存在。甚至可以说，随着组织推动AI系统处理日益复杂和关键的任务，这些问题变得更加突出了。核心挑战依然是：我们如何将强大的生成式模型与公司所依赖的海量知识库连接起来？
高效而精确的检索在人工智能中将始终扮演重要角色。这一点在一个广为流传的LinkedIn帖子中得到了很好的阐述，但我将重申为什么我们不能仅仅将所有数据加载到模型的上下文中：自首个具备大上下文窗口的LLM问世以来，RAG就一直面临“消亡”的论调。
一些值得注意的RAG“死亡宣告”包括：
2023年5月：Anthropic的Claude，上下文窗口达10万token
2024年2月：Google的Gemini1.5，上下文窗口达100万token
2025年3月：模型上下文协议（ModelContextProtocol）让你能直接与你的数据对话(注：原文日期可能是笔误)
但现实情况是：
即使拥有高达200万token这样惊人的上下文窗口，当前的长上下文LLM也只能处理演示性质的数据集（toydatasets）。例如，100万token的上下文窗口（大致）相当于约1500页文档。这对于演示来说很亮眼，但对于生产级别的应用而言是不足够的。
不过，让我们假设我们拥有一个无限token的上下文窗口：
可扩展性与成本：处理数百万token速度缓慢，且在计算和财务上都代价高昂。即使计算成本在下降，延迟对于应用程序来说也可能是一个大问题。
性能下降：LLM仍然受困于“中间丢失”（lostinthemiddle）的问题。这意味着它们无法有效利用长文本中间部分的信息。通过剔除不相关文档并避免“大海捞针”的情况，您将获得更好的结果。
数据隐私：将所有数据提供给基础模型可能引发严重的数据隐私问题。尤其是在医疗保健或金融服务等受到严格监管的行业，您需要对数据强制执行基于角色的访问控制。
底线是：您同时需要长上下文LLM和RAG。
但既然“RAG”这个术语似乎如此具有争议性，那我们不妨这样说：我们不必非得称之为RAG。我们可以就叫它检索(retrieval)。或者叫上下文筛选(contextcuration)。
无论您决定怎么称呼它，能够控制进入上下文窗口的数据质量，将决定最终生成输出的质量。
毕竟，垃圾进，垃圾出。
可扩展性–您的企业知识库是以TB或PB来衡量的，而不是token。即使有1000万token的上下文窗口，您仍然只能看到可用信息的极小一部分。这就是为什么检索技术的创新一直快速发展，混合搜索、查询转换、自我反思、主动检索以及对结构化数据的支持等方面的进步，都在帮助您在知识库中找到正确的信息。
准确性–有效的上下文窗口与产品发布时宣传的大相径庭。研究一致表明，模型在远未达到其官方极限时性能就会下降。在实际测试中，同样的模式也会出现，模型难以准确引用深埋在其上下文中的信息。这种“上下文悬崖”意味着仅仅将更多内容塞入窗口并不会带来更好的结果。
延迟–将所有内容加载到模型上下文中会导致响应时间显著变慢。对于面向用户的应用程序，这会造成糟糕的用户体验，人们会在得到答案前就放弃交互。基于检索的方法可以通过仅添加最相关的信息来提供更快的响应。
效率–你会在需要回答一个简单问题时去读完整本教科书吗？当然不会！RAG提供了相当于直接翻到相关页面的能力。处理更多token不仅更慢，而且极其低效，并且比使用RAG精准定位所需信息要昂贵得多。
在谷歌搜索“RAGvs”，你会看到一长串建议的查询补全——“长上下文”、“微调”、“MCP”。这种框架设定制造了一种人为的选择，并没有反映这些技术实际上如何协同工作的最佳方式。
实际上，这些概念没有一个是相互排斥的，甚至不是相互冲突的——它们都以互补的方式帮助解决前沿模型的局限性：
RAG提供了访问模型知识库之外信息的途径
微调改善了信息处理和应用的方式
更长的上下文允许检索更多信息供模型推理
MCP简化了Agent与RAG系统（及其他工具）的集成
我们在生产环境中看到的最复杂的AI系统结合了这些方法，根据各自的优势来使用每种工具，而不是宣布某一个获胜并将其他工具抛弃。
正如一位Twitter用户最近所说：“声称大型LLM上下文窗口取代了RAG，就像说因为有足够的内存（RAM）就不需要硬盘一样。”正是如此！你的电脑有磁盘、内存和网卡是有原因的。它们服务于不同的目的，并作为一个系统协同工作。RAG、微调和大型上下文窗口在AI中也是如此。
我们不需要在RAG与长上下文窗口、微调或MCP之间做出选择。真正能创造价值的AI解决方案不会固守单一方法；它们会根据要解决的具体问题混合搭配使用工具。
但下一次宣称“RAG已死”的论调出现只是时间问题，所以，如果你将来想引用这篇文章，可以在isragdeadyet.com找到它。这个网站将作为一个活生生的证明，展现检索在AI系统中持久的重要性，并且每当下一波“RAG已死”的帖子不可避免地出现时，它都会更新。
原文链接：https ://contextual.ai/blog/is-rag-dead-yet/
最后推荐一个我正在学习的DeepSeek应用开发课
本课程将会涉及当前业界最主流的AI应用开发思想、套路、工具以及框架，设计的实战项目也会聚焦DeepSeek模型的某个特点。对于AI开发老鸟，可以与时俱进，查漏补缺，掌握业界前沿的开发思想和工具；而对于AI开发新手，则可以绕过过去几年我摸爬滚打的弯路，借力DeepSeek，快速入门AI应用开发领域。
