【RAG 深度修炼】番外篇：长上下文时代，RAG 还需要吗？—

专栏简介：本专栏第 1~9 期已收官（全景诊断→分块→嵌入→混合检索→向量库→重排→生成侧→评测闭环→安全清单）。这是番外篇，回应 2025 年被问得最多的一个问题。

"模型上下文都 200K token 了，还有必要做 RAG 吗？把整个知识库塞进上下文不就行了？"这个问题几乎每个团队都遇到过，答案不是简单的"要"或"不要"。本篇用一场完整的实测给答案：同一个知识库、同一批问题，分别用长上下文直塞、RAG、两者混合跑一遍，把成本、延迟、准确率、召回上限四个维度全部拉出来对比。结论先行：长上下文和 RAG 不是替代关系，是分工关系——而且分工的边界比大多数人想象的更清晰。

番 1. 问题的由来：200K 上下文改变了什么
番 2. 实测设计：同一知识库的四种方案
番 3. 四个维度的实测结果
番 4. 深层原因：长上下文为什么"注意力不平等"
番 5. 分工边界：什么场景用长上下文，什么场景用 RAG
番 6. 混合架构：长上下文 + RAG 的正确组合
番 7. 结论与行动建议

番 1. 问题的由来：200K 上下文改变了什么

先承认这个问题的合理性——长上下文确实改变了三件事：

能力	128K 时代	200K~1M 时代
单文档处理	长文档要切块	中小文档整篇直塞
知识库规模	必须 RAG	小知识库（<10 万 token）可直塞
多文档对比	逐个检索再拼接	几十个文档可同屏对比

"10 万 token 以内的知识库直接塞"在 2025 年确实成立了——这就是问题让所有 RAG 工程师焦虑的原因。但"塞得下"和"答得好"是两回事，"塞得下"和"塞得起"更是两回事。下面用实测把这两回事量出来。

番 2. 实测设计：同一知识库的四种方案

实测环境：企业知识库 180 万 token（约 200 份文档）、200 条评测问题（第 8 期方法构建：120 有答案 + 50 无答案 + 30 多轮）。四种方案：

方案 A：纯长上下文（Naive Long Context）
每次提问把全部 180 万 token 塞进上下文
（截断到模型上限 200K，超出部分丢弃 ⚠️）
→ 实际上 180 万 > 200K，根本塞不下，只塞核心文档 190K

方案 B：纯 RAG（专栏第 1~9 期的完整链路）
结构分块 + 混合检索 + 重排 + Top 6 + 分位排序

方案 C：长上下文 + RAG 混合
RAG 召回 Top 6 + 核心文档全文（10 万 token 常驻）

方案 D：RAG 召回 + 超长上下文扩展
RAG Top 6 + 命中块的"邻块扩展"（父块全文，约 15K token）

四种方案跑同一批问题、同一个 Judge（第 8 期的校准过裁判），四个维度对比。

番 3. 四个维度的实测结果

维度	A 纯长上下文	B 纯 RAG	C 混合	D RAG+父块
端到端正确率	71%	89%	88%	90%
忠实度	0.82	0.92	0.90	0.93
负例拒答率	58% ⚠️	92%	85%	92%
单次成本（相对）	×12	×1	×7	×1.6
P99 延迟	8.4s	1.9s	5.2s	2.3s
知识库上限	~200K token	无硬上限	~210K	无硬上限

四行关键读数：

正确率：纯长上下文反而输给 RAG 18 个点——这是本期最重要的实测发现，原因见番 4。方案 D（RAG+父块）最高：RAG 的精准召回 + 父块的完整语境，两头的好处都拿了。
负例拒答率 58% vs 92%：长上下文塞了大量内容后，模型对"知识库里没有的问题"更爱硬答——噪音越多，幻觉越多。这直接验证了第 7 期的"信号密度"理论。
成本 ×12：每次请求都带 190K 输入 token，成本是 RAG（约 15K）的 12 倍。日请求 5 万次的场景，这个差值就是一个月几十万 vs 几万。
知识库上限是长上下文的死刑线：180 万 token 的知识库连塞都塞不进 200K 窗口——而企业知识库过 200 万 token 是常态。

一句话结论：塞得下的（<100K）长上下文也答不好，答得好的塞不起，塞得起的（RAG）不受限——分工而不是替代。

番 4. 深层原因：长上下文为什么"注意力不平等"

番 4.1 三个物理原因

原因一：注意力稀释。190K token 的上下文里，真正相关的可能只有 2K——模型对每 token 的注意力被稀释 100 倍。第 7 期 lost in the middle 的极端版：不只中间是洼地，整片大海都是洼地，只有少数岛屿有信号。

长上下文的注意力分布（示意）：

190K token 直塞：
高 ┤ ▂▄▂ ▂▄▂
│ ████▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂ ████
低 ┤ ↑开头结尾↑
└──────────────────────────────────────→ 位置
两头有信号，中间 180K token 都是"注意力荒原"
真正相关的 2K token 若落在荒原里 → 模型看不见

RAG 的 15K 上下文：
高 ┤ ▂▄█▄▂▂▄█▄▂▂▄█▄▂▂▄█▄▂
│ 全程信号密度高（每条资料都相关）
└──────────────────────→ 位置

原因二：检索是"显式"的，长上下文是"隐式"的。RAG 的检索阶段（嵌入+BM25+重排）用专门的算法把最相关的 6 条挑出来——这是一次"有监督的注意力"。长上下文把这个筛选工作完全丢给模型内部的注意力机制——而注意力机制不是为"百万 token 里找 6 条"设计的，它为"理解当前这段话"设计。

原因三：位置编码的外推失真。模型在长上下文下的位置编码外推（从训练长度外推到 200K）会带来精度损失——距离越远的 token 对，注意力计算越失真。这是"宣称支持 200K"和"200K 下质量良好"的差距来源。

番 4.2 但长上下文有三个 RAG 给不了的能力

公平起见，长上下文也有 RAG 做不到的：

长上下文的独有能力	RAG 为什么做不到
全局推理（"这 50 份合同里哪份的违约条款最宽松"）	需要同屏看到全部 50 份，检索只能给 6 条
跨文档对比（"对比 A 和 B 方案的差异"）	对比需要两份全文同屏
文档结构理解（"这份合同的整体逻辑是什么"）	分块破坏了文档结构

这三个能力的共同点：需要"全部同屏"。这就是分工边界的第一性原理——需要"找几条"的用 RAG，需要"看全部"的用长上下文。

番 5. 分工边界：什么场景用长上下文，什么场景用 RAG

把实测结论整理成一张场景分工表：

场景	正确方案	原因
企业知识库问答（>200K）	RAG	塞不下，且塞得下的部分也答不好
中小知识库问答（<50K）	长上下文可直塞	但实测仍建议 RAG（成本+拒答率）
单文档精读（合同/论文审阅）	长上下文	全文同屏，结构理解
多文档对比（≤20 份）	长上下文	全局推理是独有能力
全局统计（"50 份合同哪份最宽松"）	长上下文 + 地图归约	RAG 的 Top 6 无法回答
精确事实查询（"错误码 E-4021 什么意思"）	RAG	检索+重排的精准度无可替代
多轮对话助手	RAG（+对话内长上下文）	知识检索靠 RAG，会话历史靠窗口
实时性知识（工单/今日数据）	RAG	长上下文的"常驻内容"更新不了

一条总原则："找"用 RAG，"读"用长上下文。找是"从海量里挑几条"（检索问题），读是"把眼前的读透"（理解问题）。两类问题物理上就不同，工具自然不同。

番 6. 混合架构：长上下文 + RAG 的正确组合

实测里表现最好的是方案 D（RAG+父块），和方案 C（混合常驻）。给出两个生产可用的组合模式：

模式一：RAG 为主 + 父块扩展（默认推荐，方案 D）

模式一架构（专栏链路的自然延伸）：

查询 → RAG 链路（第 1~9 期）→ Top 6 子块
↓
取父块（第 2 期父子块）
↓
上下文 = 父块全文（~15K）
↓
模型：既有精准又有语境 ✓

这就是第 2 期"父子块"和第 7 期"检索快照"的自然组合——长上下文的价值不在"塞整个知识库"，而在"把 RAG 召回的块换成更完整的语境"。成本只涨 60%，正确率再涨 1 个点，是性价比最高的"长上下文用法"。

模式二：核心常驻 + RAG 补充（超高频场景）

模式二架构（高频核心文档场景）：

常驻层：核心制度/高频文档全文（~30K，每请求都带）
检索层：长尾知识库走 RAG（动态补充 Top 4）
↓
上下文 = 常驻 30K + RAG 10K = 40K
↓
核心问题秒答（不检索），长尾问题精准召回

适用：知识库访问高度倾斜（20% 文档占 80% 查询，第 5 期冷热分层的 RAG 版）。代价是每次请求固定多 30K 输入成本——只有"核心文档命中率 > 70%"时才划算，先查日志验证再上。

两个模式的决策树：

知识库 > 200K？
├ 是 → 模式一（RAG+父块），或模式二（若访问高度倾斜）
└ 否（<200K）
├ 需要全局推理/多文档对比 → 纯长上下文
├ 需要精确事实查询 → RAG（小知识库可直塞+RAG 混合）
└ 混合需求 → 模式一

番 7. 结论与行动建议

五句话收束番外篇：

"塞得下"不等于"答得好"：190K 直塞正确率 71%，输给 RAG 18 个点——注意力稀释、隐式检索、位置编码失真，三个物理原因。
"答得好"不等于"塞得起"：成本 ×12、P99 8.4s——长上下文直塞在成本和延迟上都不构成 RAG 的替代。
分工原则："找"用 RAG，"读"用长上下文——检索问题（从海量挑几条）和理解问题（把眼前读透）物理上不同。
长上下文真正正确的用法是"RAG+父块"——把召回的块换成完整语境，成本 +60%、正确率再 +1，专栏第 2 期父子块的回报日。
别拆你建好的 RAG——长上下文改变的是"块可以更大、语境可以更完整"，不是"检索不需要了"。

给三类读者的行动建议：

正在犹豫要不要建 RAG 的团队：建。知识库 >100K token 就没有悬念；<50K 可以先直塞跑着，但把第 8 期评测集建起来——数据会告诉你什么时候该切换。
已经建好 RAG 的团队：别拆。把第 2 期父块用起来（方案 D），这是长上下文时代你能白拿的 1 个点。
有全局推理需求的场景（合同对比、文档统计）：这是长上下文的主场，RAG 帮不了你——单独为这类需求建"地图归约"管线，不要试图让 RAG 兼任。

这篇番外篇回应了 2025 年 RAG 工程师被问得最多的问题。一句话总结：长上下文没有杀死 RAG，它改变了 RAG 的块该多大、语境该多全——专栏第 2 期的父子块和第 5 期的冷热分层，在长上下文时代反而更有用了。如果你的实测数据和本篇不一致，欢迎评论区贴出来对表——实测永远是专栏的第一信条。

参考与延伸阅读：