“RAG已死”辩论，诚实解决
从 2024 年到 2025 年，一个反复出现的观点是，长上下文将使检索增强生成变得多余。这个论点很有动力：多模式基础模型提供了超过百万个令牌的上下文窗口，即时缓存降低了重新发送长文档的成本，并且许多长上下文基准（大海捞针变体、LongBench、RULER）显示模型以前所未有的长度回忆事实。
到 2026 年第一季度，现实将比“RAG 已死”更无聊，但也更有用。长上下文确实已经淘汰了一些 RAG 用例——尤其是语料库适合并保持稳定的单文档推理——但企业检索问题的形式并没有从根本上改变。大多数生产知识库都是 TB 级，而不是 GB 级。大多数查询都涉及该语料库的一小部分、不可预测的部分。新鲜度、许可、归属和审核仍然很重要。这些限制使检索保持活力。改变的是良好管道的几何形状。
接下来的框架将介绍长上下文实际上取代了 RAG、RAG 仍然击败长上下文、真正新的检索模式（上下文检索、GraphRAG、混合搜索、重新排名）、代理检索转变、区分生产 RAG 和原型 RAG 的评估规则，以及用于修剪和重建 2026 年检索堆栈的决策树。
长上下文实际上已经取代了 RAG
明确界限会有所帮助。在生产使用中，长上下文和提示缓存在三种狭窄情况下取代了检索：
- 单文档工作流程。总结一份 300 页的合同，从甲板上提取结构化数据，回答特定技术手册的问题 - 整个语料库适合上下文并在各个会话中保持稳定的情况。通过缓存，重新发送文档的成本低于建立和维护专用检索索引的成本。
- 知识库规模小、变化缓慢。每季度更新一次并适合 200-500k 令牌的内部 HR 手册、入职指南或产品规格文档通常通过即时缓存提供比通过完整检索管道更便宜，尤其是在检索基础设施固定成本占主导地位的小查询量下。
- 评估和调试流程。当开发人员迭代模型如何对语料库进行推理时，将语料库推入提示中会删除作为实验变量的检索。一旦推理稳定，检索就会作为生产优化返回。
RAG 仍然胜过长上下文
对于大多数企业工作负载，长上下文是补充而不是替代。四个结构性限制始终促使生产团队重新进行检索：
- 规模。几亿个文档标记超出了任何当前的上下文窗口，并且通过检索推送过滤后的切片比尝试在提示中容纳整个语料库要便宜几个数量级。每个查询的成本（而不是窗口大小）是生产规模的约束约束。
- 新鲜。如果答案取决于昨天编写的文档（支持票证、拉取请求、事件报告、监管文件），则每次摄取时更新的矢量索引（或混合索引）都会击败静态提示。长上下文无法跟上不断更新的知识库。
- 许可和归属。检索允许应用程序在模型看到内容之前过滤 ACL。它还生成每个块的出处，监管团队（金融服务、医疗保健、法律、政府）需要显示审计跟踪。长上下文也没有给应用程序提供任何信息，这从结构上将其排除在几类受监管的部署之外。
- 评价杠杆。检索管道为团队提供了两个不同的旋钮——检索质量和生成质量——以及两个评估循环。将它们折叠成一个提示意味着每一次回归都更难以诊断，每一次质量调查都运行得更慢，并且开发团队失去了隔离哪个组件发生变化的能力。
真正的新内容：上下文检索、GraphRAG、混合搜索、重新排名
检索堆栈在 2024 年至 2026 年期间不断变化，四种模式现已成为重要生产部署中的赌注。运行 2022 年复古架构的团队将保证高质量。
自从引入密集检索本身以来，上下文检索是在生产 RAG 中落地的单一最高杠杆技术。模式：在嵌入每个块并通过 BM25 对其进行索引之前，预先添加一个由 LLM 生成的简短摘要，描述该块在其父文档中的位置。在标准基准上，该技术将失败的检索减少了 35-50%，并通过重新排名获得了进一步的收益。成本适中——通过即时缓存，每块上下文生成的定价以每千块美分来衡量——并且该技术在我们的 2026 年生产基准中提供了任何检索升级中最大的单步质量跳跃。
GraphRAG 解决了另一种主要的 RAG 故障模式：需要对许多相关块进行推理而不是检索单个最佳块的问题。在语料库（实体、关系、分层社区）上构建知识图并通过图路由多跳查询在全局摘要和多实体问题上的性能远远优于仅向量检索。索引成本是真实的，这意味着 GraphRAG 是高价值、低查询量语料库（监管备案、研究文献、并购尽职调查、大型内部知识库）的正确答案，并且对于大多数查询都是单一实体事实的客户支持工作来说是过度杀伤力。
混合搜索——BM25 与密集向量检索相结合，由交叉编码器重新排序——仍然是在我们的基准测试中击败所有单一方法的生产基线。该组合可以处理词汇匹配检索（精确术语、产品名称、代码标识符）和语义检索（释义、概念匹配），而无需在它们之间进行权衡。如果一个团队在 2026 年仍在运行纯向量检索，那么混合是首先要解决的问题，然后再进行更雄心勃勃的事情。
通过交叉编码器重新排名。初始检索（无论是纯向量、混合还是基于图形）后，交叉编码器模型根据查询对每个候选者进行真实相关性评分。与初始检索相比，每个检索到的块的重新排序器的成本要高得多，这就是为什么标准模式是便宜地检索 k=50–200 并使用交叉编码器对顶部 k=5–20 进行重新排序。各个领域的质量提升是一致的。
代理检索转变
更微妙的架构变化是，检索越来越成为代理调用的工具，而不是应用程序确定性运行的预处理步骤。代理不是在模型响应之前进行单一的 top-k 查找，而是决定是否检索、使用什么查询、传递多少次以及何时停止——有时会发出后续检索来澄清或扩展早期结果。
这更适合实际问题的提出方式。用户很少会表达可简单嵌入的查询。将“我们对第三季度定价问题做了什么”重新表述为两个或三个有针对性的检索（针对不同的索引，可能针对不同的时间范围）的代理始终击败单次管道。与生产中错误答案的成本相比，额外的 LLM 呼叫的成本通常相形见绌。
代理检索设计会改变工程投资的方向。索引质量、块元数据（尤其是时间戳、源类型和出处标志）和每次检索的延迟比从单遍重新排序器中挤出最后一个百分点更重要。评估问题从“我们是否检索到了正确的块？”转变为“我们是否检索到了正确的块？”到“代理是否制定了正确的检索计划？” – 大多数 RAG 评估套件尚未对其进行良好测量。
评估仍然是最难的部分
我们审查的大多数生产 RAG 系统都没有得到充分测量。团队从概念验证期间手工制作且从未更新的小型黄金组中提供准确度数据。六个月后，语料库增加了一倍，查询分布发生了变化，没有人相信仪表板上的数字。
2026 年最低可行 RAG 评估分为四个层次：
- 维护的回归集上的仅检索指标。 Recall@k、 precision@k、表示生产查询分布的标记集上的平均倒数排名 (MRR)。回归集每季度刷新一次最小值。
- 生成质量指标。忠实度（答案是否实际使用检索到的上下文？）和答案相关性（答案是否解决了用户的实际问题？）通过法学硕士作为法官的方法计算，并根据人类标记的小切片进行校准。像 RAGAS 这样的开源框架已将此作为操作基线。
- 故障模式目录。幻觉、过度拒绝、过时的答案、权限泄漏、归因错位——随着时间的推移进行分类、跟踪，并用于驱动特定的修复，而不是被视为无差别的“模型错误”。
- 生产样品管道。一小部分实时流量（通常为 0.5-5%）会回滚到每周一次的回归设置中，因此评估分布跟踪实际的生产分布而不是历史分布。
生产 RAG 中的常见故障模式
产生生产 RAG 系统的重复模式在仪表板上看起来很健康，但在面向用户的操作中却失败了：
- 单向量检索，无需重新排序。最常见的 2022 年复古架构，大多数企业仍在生产。质量比混合+重新排序器差很多；升级是可获得的最高单步质量胜利。
- 过时的回归集。最初发布的评估套件并未针对生产查询漂移进行刷新。六个月后，准确度数字并未根据实际用户行为进行校准。
- 无故障模式分段。总体准确性隐藏了哪些类别的问题未通过。每个类别和每个故障模式的报告都会显示重要的具体修复方法。
- 无生产样品循环。该系统在回归集上有所改进，但在生产中却有所下降，因为两个分布已经悄然发生了分歧。
- 检索时不强制执行权限。相反，ACL 过滤是在生成时发生的，这意味着模型看到了它不应该看到的内容，并且应用程序只需一次快速注入就可以避免泄漏它。权限过滤属于索引层。
- 回复中没有注明归属。用户无法验证答案，监管机构无法对其进行审核，团队也无法将特定的用户投诉调试回特定的源块。
- 整体矢量存储。一个矢量商店可满足所有需求。不同的内容类型（产品文档、支持票证、内部 wiki、监管备案）具有不同的新鲜度 SLA、不同的访问模式和不同的最佳检索策略。具有每种类型索引的分层方法始终优于整体方法。
2026 RAG架构的决策框架
对于考虑在 2023 年或 2024 年发货的 RAG 系统的团队来说，明智的修剪和重建顺序是：
- 首先升级到混合+重新排序。大单步以质取胜。
- 在块摄取管道上采用上下文检索。第二大胜利，适度的实施成本。
- 按内容类型和新鲜度 SLA 对矢量存储进行分层。用联合索引模式替换单体。
- 为每一代添加归因+审计跟踪层。受监管的部署所需，在任何地方都很有价值。
- 对于多跳推理失败，请在范围语料库上试用 GraphRAG。建造成本是真实的；仅当语料库和查询配置文件证明其合理性时才大规模提交。
- 将检索模式从确定性预处理迁移到代理工具使用。过渡需要几个发布周期；优质电梯经久耐用。
- 作为一流工程资产进行投资评估。如果没有它，RAG 质量就无法审核，并且质量回归在不受监控的系统中会迅速复合。
接下来要建造什么：建筑的发展方向
除了现有系统的修剪和重建工作之外，三个架构方向值得为新构建进行投资。
具有明确规划的多步骤检索。与代理对每个查询进行即兴检索不同，显式检索计划抽象（分解问题、识别所需信息类型、执行计划、综合）产生的系统比自由形式的工具调用实质上更具可调试性和可评估性。
按租户或按文档微调嵌入。通用嵌入模型的效果出奇的好；特定于租户或特定于域的嵌入微调效果更好。成本已归结为常规生产优化而不是研究项目。
从生产反馈中不断学习。用户信号（点击、停留时间、显式反馈、后续问题模式）以连续循环的形式馈送到检索排序器和回归集。早期构建此系统的团队在 12 个月后比对其进行改造的团队拥有更好的系统。
常见问题
2026年构建或升级生产RAG系统的企业团队提出的常见问题：
- 我应该从头开始重建 RAG 系统还是逐步升级？几乎总是增量。首先是混合+重新排序，其次是上下文检索，然后评估更具侵入性的更改是否合理。重建往往会晚一些，而且并不比严格的升级好多少。
- 我还需要矢量数据库吗？或者我可以直接使用长上下文吗？用于任何超过 1-500 万个令牌的语料库或任何需要许可、新鲜度或归属的部署的矢量数据库。真正小型、稳定、单租户语料库的长上下文。
- 我应该使用哪种嵌入模型？ 7B 及以上范围内的默认良好开放或商业模型在大多数任务上都具有竞争力。特定领域的微调可以在专业语料库上产生可衡量的收益。 “最佳模型”基准每季度变化一次；评估原则比模型选择更重要。
- 我的回归评估集应该有多大？ 200-2,000 个问答对，涵盖生产查询分布，每季度使用实时流量样本进行刷新。较小的集合在统计上是不可靠的；更大的设备在操作上维护成本很高。
- GraphRAG 何时真正证明其成本合理？当语料库价值较高时，查询组合包括有意义的多实体和全局摘要问题，并且查询量适中（每天数千而不是数百万）。对于大批量客户支持类型的工作负载，混合+重新排序通常更具成本效益。
