2026 年的长上下文 vs RAG：为什么它是基于功能的决策，而非架构信仰

长上下文与 RAG 的经济学在两年内翻转了两次，而在那两个窗口期中选择了某种架构的团队，现在正处处支付着错误的代价。在 2024 年，趋势是将一切都塞进上下文窗口，因为窗口在不断扩大，而每 token 的价格在持续下降，因此检索流水线被斥为过时的繁琐工作。在 2025 年，共识发生了反转：关于“上下文腐烂”的研究表明，在百万级 token 的提示词中，窗口中部的有效召回率大幅下降，全窗口调用的延迟变成了用户体验问题，且账单变得非常惊人，于是检索技术重新得到了重用。到 2026 年，正确的答案不再是任何一种口号。它是一个在设计阶段做出的基于单个功能的决策，并记录下四个维度的权衡，因为为整个产品选择单一架构，是让每个功能同时出错的低成本方式。

一直困扰着团队的思维模型是将长上下文 vs RAG 视为路线图上的承诺，而不是针对每个界面的选择。你阅读了一篇有影响力的博客，选边站队，雇佣了擅长那一边的工程师，编写了一份将其规范化的平台文档，现在每个新功能无论是否合适，都采用了相同的架构。需要新鲜数据的功能忍受着陈旧的上下文。需要可扩展语料库的功能为他们永远不会使用的检索基础设施买单。需要引用来源的功能在发布时却缺失了这一项。这些都不是 bug。它们是将功能级决策视为产品级决策所带来的必然代价。

这篇文章讨论了驱动每个界面选择的四个维度——新鲜度、归因、尾部风险和成本——以及当选择出错时，没有人会摆到台面上的工程代价。我想留给你的框架是：长上下文 vs RAG 并不是一种信仰。它是一个基于功能的决策，必须每六个月重新审视一次，因为底层经济学的变化速度总是快于你的架构图。

数学规律翻转了两次，而每个人都在错误的时刻进行了标准化

看看舆论是如何演变的。在 2024 年初，头条新闻是 Gemini 1.5 Pro 在一百万 token 的单事实“大海捞针”测试中达到了 99.7% 的准确率。流传最广的解释是“上下文窗口问题已解决，RAG 已死，直接把语料库倒进去就行”。基于这一基准测试的强度，一波平台团队拆除了向量数据库或搁置了检索项目。到 2025 年中期，另一组基准测试变得不容忽视：在长上下文中进行现实的多事实检索，召回率下降到约 60%，性能在仅增加一百个 token 的干扰项时就会下降，而“中间遗忘”问题让大型提示词中间 40% 的内容变得像抛硬币一样不可靠。百万 token 调用的延迟比优化后的 RAG 流水线慢 30 到 60 倍，且每次查询的成本约为其千倍。第二波团队急忙转回检索，往往是在重新构建他们刚刚弃用的基础设施。

在那两个时刻进行标准化的团队，在接下来的十八个月里都为错误的架构付出了代价。教训并不是说哪一方是正确的，而是在快速变化的成本和质量前沿上押注平台决策是一件糟糕的事情。当你完成迁移时，数学规律已经再次发生了变化。Chroma 的“上下文腐烂”研究让这一点变得具体：模型性能随输入长度的增加呈现非均匀退化，干扰项的影响并不均衡，甚至简单的重复任务在大规模下也会失败。百万级 token 窗口是真实的。但有效上下文窗口大约在其中的 30% 到 60% 之间，具体取决于任务。价格在下降，但缓存的 TTL（生存时间）变短了，所以你六个月前做的计算到今天已经过时了。

如果在架构图完成之前前沿技术就已发生变化，那么唯一稳定的策略就是停止绘制单一架构图。针对每个功能做决定。写下权衡。定期重新审视问题。

驱动每个功能的四个维度

当一个新的 AI 界面出现时，工作负载的四个属性决定了长上下文、RAG 或混合模式是否为正确的工具。大多数团队对其中的一两个有直觉。而这里的纪律是在设计时明确这四个属性，使选择是可审计的，而非凭感觉驱动。

新鲜度 (Freshness)。什么样的陈旧度是可以接受的？RAG 索引可以通过流式流水线吸收分钟级的新数据；而更新长上下文功能的提示词则需要重新输入整个文档并破坏前缀缓存。一个必须了解二十分钟前政策更新的支持助手是一个 RAG 型问题；一个语料库即合同本身的合同审查工具则是一个长上下文型问题。新鲜度维度最容易出错，因为在演示中一切都是新鲜的——成本只有在生产环境中语料库发生漂移且长上下文缓存开始自信地撒谎时才会显现。

归因 (Attribution)。用户是否需要可引用的来源？RAG 返回你可以展示、链接和审计的代码块。长上下文返回的是一个综合结果，除非你单独构建，否则没有来源追踪。对于面向消费者的界面，这通常并不重要。对于受监管的工作流程、法律纠纷中使用的内部知识工具，或者任何用户会问“那是从哪里来的”的产品，缺乏溯源是一个功能缺陷，而不仅仅是 UI 的加分项。关于 RAG vs 长上下文的研究不断表明，长上下文吸收的文本更多，但 RAG 在展示引用方面仍然更胜一筹。一旦在发布时没有归因，后期补救通常不值得；让引用变得廉价的数据结构必须从第一天起就到位。

尾部风险 (Tail-risk)。当模型漏掉正确事实时会发生什么？长上下文会默默失败——它会产生一个自信的答案，但忽略或矛盾了埋藏的证据，只有当用户投诉或你的评估足够精确以检测到遗漏时，你才会发现。对于低风险的摘要，静默失败模式是可以接受的。对于任何错误答案会带来实际成本（医疗、法律、财务，或者任何会因投诉而产生费用的领域）的场景，RAG 可检测的失败模式是一个特性，而不是局限。请注意，这与通常的“RAG 更可靠”的说法相反——RAG 并非更准确，它只是错得更诚实。

成本 (Cost)。每项任务的总拥有成本 (TCO)，包括缓存命中率、检索索引维护以及多步流水线的延迟税。长上下文的经济性高度依赖于前缀缓存：在最近的 Anthropic 模型上，缓存输入的运行费用约为标准费率的 10%，但在 2026 年初，缓存 TTL 下降到了五分钟，这使得许多生产工作负载的有效成本默默增加了 30% 到 60%。RAG 的经济性取决于索引维护：重新嵌入和重新索引的预算通常占每月推理支出的 20% 左右，加上工程师维护检索流水线的时间。正确的数字应该是针对每个功能的，而不是针对每个架构的，你无法对一个没有指明哪个功能在走哪条路径的预测进行合理性检查。

加载中…