长上下文 vs RAG：一套以证据为中心的架构决策框架

核心结论

真正有用的问题不是“RAG 是否已死”，而是：

对这类工作负载，哪条证据链路能在延迟、成本与运维约束内，生成最好、已授权且可追溯的答案？

四种架构都值得公平测试：

1. 直接长上下文：每次请求都发送完整的已授权证据集合。
2. 带缓存的长上下文：按供应商缓存规则复用稳定的提示词前缀。
3. 检索增强生成：生成前先选择较小的证据集合。
4. 检索 + 长上下文混合架构：召回更广的候选证据，再统一综合推理。

没有通用赢家。上下文窗口容量是输入上限，不是质量保证；检索是一种过滤机制，不等于已经找到正确证据；提示词缓存改变的是重复输入的成本结构，不会替你解决证据更新与授权。决策必须来自版本化评测，而不是一句语料规模口号。

长上下文时代到底改变了什么

大窗口消除了过去使用 RAG 的一个原因：很多文档集合现在确实可以装进一次模型请求。这让“直接阅读全部材料”成为可信基线，也常常能简化早期原型。

但知识系统可能承担的其他职责并未消失：

• 从大于活动窗口的语料中选择证据；
• 在模型披露前执行租户、用户、地域或记录级访问控制；
• 单独更新变化的文档，而不是重建一个巨大提示词；
• 附带稳定的来源标识、版本和时间戳；
• 减少无关证据；
• 控制重复输入成本与首字延迟；
• 证明答案到底由哪些证据支持。

Lost in the Middle 等研究表明，相关信息在长输入中的位置可能影响模型表现。这个结论提醒我们测试证据位置和干扰项，但不能把某篇旧研究中的准确率表直接套用到新模型、新任务和不同上下文长度上。

先判断证据形态

讨论向量数据库或窗口大小前，先给工作负载分类。

不要把这张表变成新的固定阈值。一份十页合同可能需要全文推理；一千万条短记录可能只需要一次精确查询。任务的证据分布比原始 Token 数更重要。

四种架构画像

1. 直接长上下文

应用组装已授权文档，并与问题一起发送。

优势

• 检索基础设施最少；
• 保留文档顺序和广泛关系；
• 适合作为摘要、对比和跨章节推理的强基线；
• 避免分块边界和嵌入检索召回失败。

失败模式

• 相关证据要与大量干扰项竞争；
• 请求耗时与输入用量随证据集合增长；
• 权限变化可能改变整个提示词；
• 如果没有明确的文档 ID 与边界，来源归因会很弱；
• 截断可能静默删除必要证据。

直接长上下文并不等于“没有架构”。它仍需要文档归一化、确定性排序、来源标签、访问控制、大小限制和评测。

2. 带缓存的长上下文

提示词缓存可以让重复的稳定前缀更便宜或更快，但各家实现不同。

• Anthropic 文档描述了基于前缀的缓存断点、随模型变化的最小长度与有限保留期。
• OpenAI 文档描述了符合条件的相同前缀自动缓存，并在用量中暴露缓存 Token 数。
• Gemini 文档描述了受支持模型的隐式缓存，并建议把大型公共前缀放在提示词开头。

可迁移的结论只有一个：相同且可复用的前缀可能受益于缓存。不要把某一家供应商的折扣、保留时间或最低长度写成架构常量。

应测量：

cache_hit_rate        = 命中缓存的请求数 / 符合缓存条件的请求数
cached_input_share    = 缓存输入 Token / 总输入 Token
invalidation_rate     = 发生变化的前缀数 / 前缀构建总数
cost_per_good_answer  = 模型与系统总成本 / 合格答案数

缓存命中不会校验答案、刷新过期内容或授权某份文档。供应商规则允许时，把频繁变化或用户专属内容放在稳定前缀之后，并记录真实缓存用量，而不是假设复用成立。

3. RAG

检索增强生成会依次解析、索引、过滤、召回、可选重排，再把选中的证据发送给模型。

它在长上下文时代的核心价值是证据选择：

• 在模型披露前按访问策略过滤；
• 减少无关上下文；
• 单独更新记录；
• 保留文档与文本块标识；
• 支持大于单次活动请求的语料。

但 RAG 会引入一条多阶段召回链。即使模型阅读原文时能够答对，答案也可能在前置阶段丢失：

文档解析 -> 文本分块 -> 索引 -> 候选召回
         -> 权限过滤 -> 重排 -> 提示词组装 -> 生成

图中候选召回仍位于可信检索边界内；也可以在召回时直接做权限预过滤。无论采用哪种方式，无权披露的原文都不能进入外部重排服务、模型或面向用户的日志。权限撤销后，应用缓存和供应商缓存中的材料也要按数据留存规则处理。

每一段都要评测。仅看端到端答案准确率，无法判断一次失败来自检索还是生成。

4. 检索 + 长上下文混合架构

混合架构不等于“随便召回 Top 50”。它应使用检索构建一个有界证据包：既足以完成综合推理，又保留最终任务所需关系。

一个稳健的证据包可以包含：

• 召回片段及其相邻章节；
• 文档标题、版本、时间戳和权限标签；
• 上级摘要或目录路径；
• 相互冲突的证据，而不只是最高分片段；
• 覆盖不完整时的明确声明。

当完整语料太宽，而答案又需要比少数孤立文本块更丰富的上下文时，混合架构很有价值。但它也同时继承两类失败：检索可能漏证据，模型也可能误用更大的证据包。

构建决策实验

第一步：建立代表性查询集

对真实问题分层，不要只抽简单事实查询：

• 精确事实检索；
• 跨文档多跳问题；
• 全文摘要；
• 对比与矛盾识别；
• 最近更新问题；
• 无权限或部分授权请求；
• 应当拒答的不可回答问题；
• 带干扰项与冲突版本的对抗问题。

为每个用例冻结文档、权限、期望证据和评分标准。另留一份不参与调优的测试集，检测过拟合。

第二步：运行等价变体

统一模型版本、答案格式、授权身份、输出预算、重试策略和评测集。

记录精确的模型、索引、嵌入模型、重排器、分块器、提示词与语料版本。缺少这些固定项，未来重跑的就是另一场实验。

第三步：分层评分质量

使用相互独立的指标：

1. 答案正确性：响应是否满足问题？
2. 引用正确性：每条引用是否真的支持对应结论？
3. 引用覆盖率：重要结论是否都有证据？
4. 拒答质量：缺乏证据或无权限时能否拒绝？
5. 检索召回：对 RAG 与 Hybrid，生成前是否已包含必要证据？
6. 稳健性：改变文档顺序、干扰项或过期版本后，表现是否变化？

不要只依赖一个未经人工校准的模型评分。高影响领域应抽样，并由人工裁决分歧。

第四步：测量完整链路

采集：

• 端到端 p50 与 p95 延迟；
• 首个输出时间与完成时间；
• 输入、缓存输入和输出用量；
• 分别记录检索、重排、权限与生成耗时；
• 缓存命中率与失效率；
• 索引新鲜度延迟；
• 超时、重试与错误类别；
• 每个合格答案的成本，而不只是单次模型调用成本。

系统边界很重要。模型调用便宜，但索引昂贵或人工审查负担很重，并不等于产品更便宜。

以工作负载为中心的决策矩阵

最后一行很重要：RAG 与长上下文不是仅有选项。如果答案就是结构化记录查询，带类型约束的 API 往往比两者都可靠。

常见决策错误

把上下文窗口大小当成可用容量

指令、工具定义、会话历史、证据和输出共享预算。应保留余量，并用目标模型的分词器检查最坏输入。技术上装得下的请求，仍可能太慢、噪声太大或无法可靠引用。

复制固定成本或延迟倍数

供应商价格、缓存规则、硬件、费率层级、批处理、载荷和模型版本都会变化。应公开用量公式和带日期输入，而不是写“RAG 便宜 100 倍”。

把检索当成自动准确

糟糕的解析、分块、元数据、过滤或重排，都可能在模型看到答案前就删掉证据。应跟踪必要证据召回，并检查失败样本。

把缓存当成知识更新策略

缓存只复用匹配前缀的计算，不判断前缀是否最新。应用仍然负责失效、版本与访问策略。

只评测答案是否流畅

流畅的答案也可能没有支持。应分别评分证据、引用和拒答。

生产上线方法

1. 从最简单且可信的基线开始，通常是对有界授权集合使用直接长上下文。
2. 为证据 ID、权限决策、用量、缓存行为和延迟增加链路记录。
3. 在调优前先建立代表性查询集。
4. 只有实验表明确有覆盖、规模、新鲜度、归因或成本需求时，再增加检索。
5. 对新链路做影子流量测试，对比合格答案结果。
6. 明确回退行为：权限不确定时拒绝访问，证据不完整时如实说明。
7. 模型、供应商缓存策略、语料、索引或提示词变化后重新评测。

常见问题

百万级上下文会让 RAG 过时吗？

不会。窗口容量不能保证模型可靠利用全部信息，也不解决证据更新、访问权限、成本和延迟。应对同一组代表性查询比较四种架构的合格答案结果。

什么时候先用直接长上下文？

当材料集合有界、已经授权，多数问题确实需要广泛阅读，且链路满足质量、延迟和成本目标时。不要把某个固定 Token 数当作切换架构的阈值。

提示词缓存会改变选择吗？

会，但前提是请求真的复用符合供应商规则的前缀。必须实测命中率、缓存 Token 占比和失效频率；低复用率的大上下文仍然会产生大量未缓存输入。

全部文档能放进窗口，RAG 还有什么价值？

检索仍可筛选相关且已授权的证据、保留来源标识并支持增量更新。但分块、召回和重排也可能漏掉答案，所以需要证明收益超过新增失败和运维成本。

对比实验至少应报告什么？

答案与引用正确性、引用覆盖、拒答、必要证据召回、p50/p95、缓存用量、新鲜度、权限失败和错误类别，并按合格答案计算总成本。只报告模型调用价格无法支持架构结论。

总结

长上下文没有杀死 RAG，而是让架构选择变得可以实验验证。

当有界、已授权集合中的广泛阅读有价值，且能满足服务目标时，使用直接长上下文；当稳定前缀确实重复时，利用缓存；当证据选择、新鲜度、归因、访问控制或语料规模值得承担复杂度时，使用 RAG；当检索需要缩小搜索空间、但任务又不能被压缩成孤立片段时，使用混合架构。

真正持久的决策产物不是一个 Token 阈值，而是一份版本化工作负载、证据集合、测量协议和结果，证明哪条路径能为用户提供最佳的有据答案。

一手来源

• Lost in the Middle：长上下文中的信息利用研究
• Anthropic Prompt Caching 文档
• Google Gemini Context Caching 文档
• OpenAI Prompt Caching 文档

相关资源

• RAG 检索增强生成架构解析与实战
• 高级 RAG 分块策略
• 解决 RAG 幻觉的工程化策略
• 长上下文与 Lost in the Middle
• 术语：上下文窗口