RAG 会被长上下文 LLM 杀死吗？夹缝中 AI 工程师的真实出路

文章目录

• 1、前言
• 2、RAG 正在被"两面夹击"
• • 2.1 上面：长上下文 LLM 和 AI 工具的冲击
  • 2.2 下面：RAG 自身进化的困境
• 3、长上下文 LLM 真的能替代 RAG 吗？
• • 3.1 能替代的场景
  • 3.2 不能替代的场景
  • 3.3 数据说话：延迟、成本、效果对比
• 4、Claude Code 改变了什么？
• • 4.1 个人用户：不再需要开发 RAG 了？
  • 4.2 售前方案场景：真实对比
  • 4.3 什么时候个人工具够用，什么时候要建系统
• 5、企业 RAG 的真实成本（很多人不知道）
• 6、RAG 工程师的出路在哪里？
• 7、RAG 的终局：我的判断
• 8、总结

🍃作者介绍：25届双非本科网络工程专业，阿里云专家博主，深耕 AI 原理 / 应用开发 / 产品设计。前几年深耕Java技术体系，现专注把 AI 能力落地到实际产品与业务场景。 🦅个人主页：@逐梦苍穹 🐼GitHub主页：https://github.com/XZL-CODE ✈ 您的一键三连，是我创作的最大动力🌹

1、前言

我做过 19 种 RAG 结构的深度研究，从最朴素的 Naive RAG 到 GraphRAG、Agentic RAG，一路踩坑过来。有段时间我甚至以为 RAG 工程师会是未来几年最香的岗位。

19种RAG结构：https://xzl-tech.blog.csdn.net/article/details/143479009

但最近这半年，我的判断开始动摇了。

不是因为 RAG 死了，而是因为两件同时发生的事让 RAG 的处境变得微妙：

上面，长上下文 LLM 越来越强，200K、1M token 的窗口直接让很多原本需要 RAG 的场景变成了"塞进去就行"。Claude Code 这类工具更是让个人用户完全不用写一行代码就能拥有私有知识库能力。

下面，RAG 自己也在进化——Agentic RAG、GraphRAG、MemoRAG，每一个都比传统 RAG 复杂一个数量级。门槛越来越高，真正做好 RAG 工程的人越来越少。

夹在中间的，是大量"会用 LangChain 搭一个普通 RAG"的工程师，以及依然相信"只要上 RAG 就能解决知识问题"的企业。

这篇文章想聊的，就是这个夹缝里的真相。

2、RAG 正在被"两面夹击"

2.1 上面：长上下文 LLM 和 AI 工具的冲击

先说最直接的冲击。

Gemini 1.5 Pro 拿出了 1M token 的上下文窗口，Llama 4 Scout 更是直接飙到 10M。Claude 的 200K 在今天已经是"入门配置"。按照这个趋势，很多人觉得 RAG 的终点就是被长上下文窗口取代。

但更大的冲击不是上下文大小，而是工具链的变化。

Claude Code + Projects 的组合现在可以做什么？你把一本 200 页的产品手册上传进去，它自动 RAG 检索，不用你写向量数据库、不用你设计分块策略、不用你调 embedding 模型——直接用，$20/月。

你跑去找客户做售前方案，以前的做法是搭一套 RAG 系统，把公司历史方案、客户资料、产品文档全部向量化，然后查询检索生成提案。现在的做法是：打开 Claude Projects，把资料上传，写几句 prompt，一个下午出方案。

这对个人用户的冲击是颠覆性的。以前要学 RAG 才能做的事，现在不用了。

2.2 下面：RAG 自身进化的困境

另一面，RAG 自己没有停下来，反而越跑越快。

从技术代际来看，RAG 已经走到了第三代甚至第四代：

问题来了：越是复杂的 RAG，越需要专业工程师；越是简单的 RAG，越容易被 Claude Projects 这类工具替代。

中间那个"搭一个普通 RAG 能用就行"的市场正在快速缩小。

这就是两面夹击的核心矛盾：高端 RAG 工程要求越来越高，低端 RAG 场景被 AI 工具直接消化。

3、长上下文 LLM 真的能替代 RAG 吗？

这是被讨论最多的问题，我直接给结论：能，但只在特定条件下。

3.1 能替代的场景

有三类场景，长上下文窗口确实比 RAG 更好用：

场景一：文档总量在几百页以内的小型知识库

Claude Projects 测试数据显示，113 篇文章仅占项目存储空间的 21%。这个量级下，直接全量注入上下文，不仅准确率比 RAG 高，而且设置成本接近零。按照工程实践中总结的经验法则：文档量低于 200 页，Claude Projects 订阅比自建 RAG 更划算。

场景二：固定格式的合同/报告分析

对延迟和成本不敏感、文档相对固定的场景，比如法律合同审查、固定模板的财务报告分析，直接塞进去效果反而更好——RAG 的分块会打乱合同的结构语义，长上下文可以全局理解条款关联。

场景三：叙事性强的内容理解

论文实测数据（arXiv 2501.01880，基于 13,628 道问题）显示，在 Wikipedia 问答、故事/小说类叙事内容、事实性 Who/Where/Which 问题上，长上下文正确率 56.3% vs RAG 49.0%，差距明显。

3.2 不能替代的场景

但长上下文也有几个硬伤，绕不过去：

问题一："Lost in the Middle"效应

斯坦福和 Meta 联合研究发现，相关信息在上下文中间位置时，性能显著退化——GPT-3.5-Turbo 在多文档 QA 中，当关键信息在中间时，性能甚至低于零样本基线（基线 56.1%）。即便是 Gemini 1.5 Pro 这种宣称接近完美的模型，在"大海捞针"任务中平均召回率也只有约 60%，40% 的事实在极长上下文下"丢失"。

更让人担心的是 2024 年的追加研究：即使只是插入 25,000 个空白字符（极低干扰），依然导致推理错误。这说明问题不是内容质量，而是注意力机制本身的局限。

问题二：成本悬崖

LightOn 做了一个企业级测试：1,000 页知识库、每日 1,000 次请求，RAG 比纯长上下文便宜 8倍到 82倍，延迟快约 2 倍。更极端的估算是，200K token 的单次 API 调用成本可能高达 $20，对于高频查询场景，这是灾难性的成本。

问题三：企业数据规模天花板

企业知识库以 TB/PB 计，任何上下文窗口都装不下。Llama 4 的 10M 上下文再大，也不可能放进一家银行几十年的信贷档案。这个维度上，RAG 没有替代品。

3.3 数据说话：延迟、成本、效果对比

结论不是谁替代谁，而是场景分层：长上下文处理小规模固定知识库，RAG 处理大规模动态知识库，两者边界随模型能力和价格变化而移动。

4、Claude Code 改变了什么？

4.1 个人用户：不再需要开发 RAG 了？

对于个人用户，我的判断很直接：大多数情况下，确实不需要了。

Claude Projects 的内置 RAG 做了什么事？

• 知识库接近 200K token 时自动激活 RAG 模式
• 有效容量扩展最高 10 倍（相当于 2M tokens 的知识库）
• 无代码设置，支持 PDF、DOCX、CSV 等格式
• 单文件 30MB，文件数量无限制（受总 token 量约束）

更重要的是，测试数据显示它支持真正的语义检索——能找到文件名中不含关键词的相关文档，不是简单的关键词匹配。

$20/月的 Claude Pro 订阅，vs 自建 RAG 最低 $45,000 的初始投入，这个对比让个人用户没有任何理由去自建 RAG 系统。

但有两个场景除外：

4.2 售前方案场景：真实对比

我用自己实际工作中的场景举个例子。

做售前方案，以前有人会想：要不要搭一套 RAG 系统，把历史方案、客户资料、竞品分析全向量化，然后检索生成定制化提案？

根据研究数据，AI 辅助 RFP 响应生成速度提升 8~10倍（从数天压缩到数小时）。Claude 的售前工作流基本是这样的：

这个流程完全不需要自建 RAG——Claude Projects 直接搞定。

那什么时候才需要建系统？ 当你的售前团队有 20 个人、历史方案库有 5,000 份文档、需要给每个销售实时推荐相关案例——这时候，Claude Projects 的容量和并发限制就不够了，才需要自建 RAG。

4.3 什么时候个人工具够用，什么时候要建系统

这是工程师最该搞清楚的决策边界：

从工程化落地的角度，这张决策表就是最实用的框架。别把简单问题复杂化，但也别把复杂问题简单化。

5、企业 RAG 的真实成本（很多人不知道）

这一节可能让很多人意外。

很多企业觉得 RAG 便宜：不就是买个向量数据库 + 调几个 embedding 接口吗？

实际上，85% 的企业低估了 AI 项目成本超过 10%。

Xenoss 的企业 AI 总拥有成本报告给出了这些数字：

基础设施年化成本：

• GPU 云租赁（H100）：$5,000 – $75,000/年
• 数据工程（采集、清洗、标注）：$150,000 – $500,000/年
• AI 专家人才（入门级）：$150,000 – $200,000/人
• 模型维护与再训练：总 AI 预算的 15-30%
• 持续运维成本：总成本的 15-30%

如果你是一家中型企业，每月处理 20 万次查询、知识库 10 万页，仅 RAG 系统的每月运营成本就可能超过 $190,000。

更糟糕的是，这些钱的大头往往花在你看不见的地方：

数据工程成本是隐性黑洞。企业知识库里的文档，格式混乱、版本交叉、权限复杂——搭好向量库是小事，把数据清洗成可检索的状态是大工程。Point Nine Capital 的真实案例很能说明问题：一家技术型 VC 花了 13 天用 Vibe Coding 搭建知识中心，最终结论是：

“大型、混乱、异构数据集上的 RAG 不是一个已解决的问题。要真正实现可靠检索，需要更好的分块策略、重排序、评估框架、反馈循环、领域特定调优……对于面对复杂问题的小公司，SaaS 仍然是更好的选择。”

三种企业实施路径的真实对比：

对比 Claude Enterprise 定制方案（含 500K 上下文窗口），越来越多的企业开始认真考虑：与其花 $100K-$500K 自建 RAG，不如给所有员工订阅 Claude Pro/Team（$20-25/人/月）并做好 prompt 工程培训。 大多数中小企业场景下，这个 ROI 更优。

6、RAG 工程师的出路在哪里？

这是我最想认真聊的一个问题。

如果普通的 RAG 场景被 Claude Projects 覆盖，如果复杂的 RAG 只有少数高手能做，那中间这批 RAG 工程师的出路在哪里？

我的判断是：RAG 工程师的价值不在于"会搭 RAG"，而在于"理解知识增强系统的边界"。

具体来说，有三个方向：

方向一：往 Agentic RAG 走，成为系统架构师

传统 RAG 是"一次性检索"：query → 向量检索 → 生成。Agentic RAG 是"多轮迭代检索"：query → 思考 → 检索 → 评估 → 再检索 → 生成。Self-RAG、Corrective RAG，这些架构需要真正懂 AI 系统设计的人来落地，不是调几个参数的事。会这个，你的不可替代性就上来了。

方向二：往 GraphRAG / MemoRAG 走，处理复杂关系数据

微软的 GraphRAG 能处理多跳推理，理解知识库里实体之间的关系——这是传统向量检索天然做不到的事。金融、医疗、法律这些领域，有大量复杂关系数据需要这种处理能力，这是一个有真实需求的专业方向。

方向三：往数据工程走，解决"原料"问题

所有 RAG 系统的瓶颈，最终都落在数据质量上。分块策略、元数据设计、清洗流水线、评估框架——这些苦活累活，也是最有价值的活。语义分块比固定大小分块能提升召回率约 9%，嵌入模型的选择可以影响检索性能 9-20%。这里面有大量可以精雕细琢的工程空间。

不要往哪个方向走：只会调 LangChain / LlamaIndex 参数、只会搭普通 RAG 演示 demo——这个层次的工作，确实在被工具化。

7、RAG 的终局：我的判断

说了这么多，我来给出我自己的判断。

RAG 不会消亡，但它的边界会重新划定。

Contextual AI 创始人 Douwe Kiela 有个比喻我觉得非常准确：

“宣称大型 LLM 上下文窗口可以取代 RAG，就像说有了足够的内存就不需要硬盘一样。你的电脑有磁盘、内存和网卡——它们有各自不同的用途，协同工作。RAG、微调和大上下文窗口在 AI 中也是同理。”

这个比喻点到了本质：这不是替代关系，是分工关系。

我对 RAG 终局的具体判断是：

个人用户层面：Claude Projects / Notion AI / 各类 AI 助手内置的轻量 RAG，会覆盖 80% 的个人知识管理需求。个人用户几乎不再需要自己开发 RAG 系统。

中小企业层面：$20-25/人/月的 Claude Team 订阅 + 好的 prompt 工程，会替代大量原本以为需要自建 RAG 的场景。只有当业务规模达到"数万页文档 + 高并发 + 强隐私要求"时，才真正需要自建。

大型企业层面：RAG 不会消失，但会演进成混合架构——RAG 负责非结构化文档检索，MCP 负责接入实时结构化数据，Fine-tuning 负责深度领域能力，Memory-Augmented 负责长期 Agent 记忆。这套组合拳里，RAG 是基础设施的一部分，而不是全部。

技术层面：CAG（缓存增强生成）这类方案会让"小型固定知识库"场景更简单，KV Cache 的成熟会降低长上下文成本，这两股力量会继续压缩普通 RAG 的生存空间。但 GraphRAG、Agentic RAG 的复杂度会继续提升，真正懂这些的人更稀缺、更值钱。

一句话总结：RAG 的终局不是消亡，是分化——低端被工具消化，高端向系统工程演进。在这两极之间挤压的，是那批停留在"会用 LangChain"层面的人。

8、总结

这篇文章从工程师的视角，梳理了 RAG 目前面临的处境：

两面夹击的现实：上层有长上下文 LLM + Claude Code 这类工具正在消化个人用户场景，下层 RAG 自身的进化让门槛越来越高。

长上下文 vs RAG：小规模、固定知识库、对成本不敏感的场景，长上下文更好；大规模、动态更新、高并发、需要引用的场景，RAG 仍然不可替代。两者不是替代关系，是场景分工。

Claude Code 的影响：对个人用户而言，确实改变了依赖——以前需要开发 RAG 才能做的事，现在 Claude Projects $20/月直接搞定。售前方案、个人知识库、小团队协作，这些场景可以直接告别 RAG 开发。

企业 RAG 成本：远比大多数人预期的高，数据工程是最大的隐性成本，85% 的企业低估了 AI 项目成本。

RAG 工程师的出路：往 Agentic RAG、GraphRAG 等复杂架构走，或者往数据工程走，价值空间都在。停留在"调 LangChain 参数"层面，会越来越难。

RAG 的终局：不是消亡，是分化。工具层消化简单需求，专业层向系统工程演进，中间的普通 RAG 空间在收缩。

最后说一句个人感受：做 AI 工程，比任何时候都更需要判断力——知道什么时候该用工具，什么时候该建系统，什么时候要承认"这个问题目前没有好的技术解法"。RAG 的进化史，其实就是这种工程判断力不断被训练的过程。

如果这篇文章对你有帮助，欢迎一键三连，你的支持是我持续创作的动力。有不同观点也欢迎在评论区交流，RAG 这个领域每个月都在变，我们一起跟着。

参考资料：

• Long Context vs. RAG: An Evaluation and Revisits (arXiv 2501.01880)
• RAG or Long-Context LLMs? A Comprehensive Study (arXiv 2407.16833, EMNLP 2024)
• Don’t Do RAG: Cache-Augmented Generation (arXiv 2412.15605, WWW '25)
• Lost in the Middle (TACL 2024, Stanford/Meta)
• LightOn: RAG is 8x-82x cheaper than long context
• Contextual AI: RAG is Dead? Not Yet
• Xenoss Enterprise AI TCO Report
• Anthropic Claude Projects RAG 官方文档