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% 左右，加上工程师维护检索流水线的时间。正确的数字应该是针对每个功能的，而不是针对每个架构的，你无法对一个没有指明哪个功能在走哪条路径的预测进行合理性检查。

评估四个维度的结果是一个基于单个功能的决策。一个理性的团队应该预期大约三分之一的功能采用长上下文，三分之一采用 RAG，三分之一采用混合模式。如果你的组合中有 90% 采用单一架构，那么这四个维度实际上并没有被检查——有人只是在回答“使用平台默认值”并在事后为其辩解。

真正落地的混合模式

大多数生产系统最终都会趋向于同一种混合模式：通过检索缩小候选集，再利用长上下文对筛选后的内容进行合成。在向产品经理（PM）解释这一点时，效果最好的表述是：“使用长上下文在有限的证据集上进行推理，并使用检索来决定该证据集应该包含什么。”检索负责它擅长的工作——大规模语料库过滤、难以伪造的引用归因、以及搜索步骤的亚秒级延迟。长上下文则负责它擅长的工作——多文档合成、跨引用推理，以及对精选集合的总结。

反复出现的运行机制通常是：混合检索（并行使用向量检索和 BM25，并利用倒排重排序融合 RRF 进行合并）返回大约一百个文本块（chunks）的候选集，交叉编码重排序器（cross-encoder reranker）将其缩小到十个左右，最后将精选出的 5 万到 30 万个 token 投入到开启了前缀缓存（prefix caching）的长上下文模型中。检索步骤足够便宜，因此你可以在召回阶段表现得更激进；而长上下文步骤足够精确，合成的效果可以媲美清洁且人工精选的上下文。它们的失效模式是互补的：检索可能会遗漏正确的文本块，而长上下文可能会丢失 Prompt 中间的信息，但它们很少针对同一个查询以相同的方式失效，一个合理的评估流程总能捕捉到其中之一。

那种“行不通”的混合版本是：在现有的长上下文功能上生硬地套用 RAG，而不考虑切片粒度、排序信号或缓存契约。混合模式是一种设计选择，而不是一个应急补丁。如果团队是因为长上下文功能出现幻觉而寻求混合模式，那么正确的做法是退回到四个维度（four axes），重新审视该功能最初是否应该采用长上下文方案。当两个部分都在发挥实际作用时，混合模式才是正确答案；而不应该将检索作为一种补偿手段，去弥补一个本不该上线的长上下文方案。

无人提及的工程税

架构评审中几乎从未提及的一个视角是：在检索流水线上的工程投入，无法分摊到不再需要它的长上下文功能上，反之亦然。一旦选错，你将为两个平台付费——一个是当前架构的实时基础设施，另一个是旧架构留下的沉重人力成本和值班轮转。选错架构的代价并不会体现在推理账单上，而是会体现在组织架构图中。

具体来说：一个严肃的 RAG 流水线包括向量存储、嵌入流水线、重排序器、检索质量评估工具，以及负责在语料库漂移时保持所有这些环节处于调优状态的人员。我看到的生产环境 RAG 的数据大约是 4 万到 20 万美元的初期工程投入，外加每月推理支出的 20% 用于重复嵌入（re-embedding）。而一个严肃的长上下文平台包括 Prompt 缓存策略、缓存预热任务、各功能的缓存命中率可观测性、基于实际生产流量分布的评估套件，以及负责跟踪本季度哪些模型版本改变了有效上下文窗口的人员。这两项投资都无法迁移到另一种架构。向量存储对你的长上下文功能毫无帮助，缓存预热任务也无法助力你的 RAG 功能。中途进行的架构切换会同时耗尽这两笔预算。

这就是为什么在设计阶段，针对每个功能的决策至关重要。编写四轴评估报告的成本只有几个小时，而由于架构选错在 18 个月后进行重构的成本则是平台工程团队一整个季度的努力。前者是可以挽回的，而后者则会演变成 PPT 上的尴尬时刻——有人必须向领导层解释，为什么 AI 路线图推迟了两个周期，只为了去做那些对客户来说完全不可见的产出。

作为一种纪律的季度重新评估

最后一项纪律是保持节奏。四轴评估不是一次性的产物。成本曲线一直在变——2025 年 Prompt 缓存定价变动了两次，关于“上下文腐坏”（context-rot）的研究仍在不断发布关于哪些模型在哪些方面性能退化的新发现，检索工具的运行成本也越来越低。六个月前正确的决定在今天未必正确。那些假装现状不变的团队，最终会拥有一系列架构依据早已过时、且成本高于必要水平的功能组合。

我建议的节奏是：每季度进行一次评审，对照四个维度重新检查每个 AI 功能面。大多数功能不会变动。那些发生变动的功能才是需要标记出来的——通常是因为定价变动足以改变成本计算，或者发布了具有不同有效上下文窗口的新模型，亦或是语料库增长超过了检索比长上下文更便宜的临界点。将评审视为一项有预算支持的活动，而不是紧急抢修。每个功能面花费一小时，在权衡文档中写下一行记录，如果架构需要更改则打上标记。总成本很小。而跳过它的代价则是缓慢发生的架构漂移——这种漂移需要一年时间才变得显而易见，却需要一个季度才能修复。

这种纪律与成熟的基础设施团队在选择数据库、云区域和 CDN 路由时所应用的纪律完全一致。长上下文 vs RAG 也应该列入该清单。这是 AI 团队所做的影响最大的平台决策之一，但它却经常被委派给一个从未有人复核过的临时判断。

架构层面的感悟

长上下文（Long-context）与 RAG 之争并非一种信仰，也不是路线图上的承诺。它是一个基于具体功能的决策，涉及四个维度的权衡；在两者都能发挥作用的场景下，采用混合方案是默认选择；此外，由于成本曲线在不断变动，还需要保持每季度重新评估的节奏。过去一年中，在 AI 领域表现出色的团队，并非那些很早就选择了“最聪明”架构的团队，而是那些拒绝绑定单一架构，并培养了根据具体场景（per surface）做决策的能力，同时记录下权衡过程并定期审视的团队。

一个没人提及但最重要的成本维度是：任何一条路径上的工程投入在另一条路径上都是不可复用的。这使得针对每个功能的决策——选对的成本很低，但选错的代价极高。这也是为什么在每个新功能发布前，花一小时在四个维度上进行权衡是极具说服力的理由。技术前沿会不断演进。你的架构图无法跟上变化，但你的决策纪律可以。