R

E02 长上下文模型 vs RAG 剖解

创建 2026-06-07 更新 2026-06-11 0 条双链 上下文工程 专题 AI 整理

E02 长上下文模型 vs RAG 剖解

当 Gemini 1.5 Pro 在 2024 年 2 月把上下文窗口推到 100 万 token、Anthropic 把 Claude 的 1M 窗口以标准单价计费时，半个行业开始唱衰 RAG:“既然能把整本知识库塞进去,为什么还要维护向量库这套脏管道?”——这是一个框架级误判。本节点要解决的问题是:长上下文窗口的出现,究竟是杀死了 RAG,还是重新划定了二者的边界?判断主轴只有一句:长上下文没有杀死 RAG,它杀死的是”小语料还硬上 RAG”的过度工程;二者在成本、延迟、质量三个轴上是结构性互补,而非替代关系。 谁把它当成单选题,谁就会在选型会上被一个成本数字或一个延迟 SLO 当场打回。

§0 为什么是”三轴互补”框架,而不是”谁替代谁”

业界默认的错误框架是把这件事建模成一场技术代际更替——像 CNN 被 Transformer 取代那样,长上下文取代 RAG 只是时间问题。这个框架错在它假设两者在做同一件事。它们不是。

RAG 解决的是**“从一个无法装进窗口的语料中,只把相关片段调进来”;长上下文解决的是”当所有相关材料已经在窗口里时,模型能不能用好它”。前者是信息流的路由问题**(决定哪些 token 进窗口,正是上下文工程的核心命题),后者是模型的利用率问题。把它们对立起来,等于问”地铁会不会取代地图”——地图告诉你去哪,地铁负责运你过去。

所以正确的框架是三轴权衡:成本、延迟、质量。每一轴上二者的曲线形状不同,交点位置由你的语料规模、查询频率、更新频率、SLO 共同决定。下面逐轴拆。

§1 成本轴:这是 RAG 最硬的护城河

长上下文最容易被忽视的代价是:它对每一个查询都要重新付一遍”把整个语料读一遍”的钱。RAG 只把 Top-K 个片段(通常几千 token)送进模型,长上下文要把几十万 token 全送进去。

以 Claude 当前官方价格为锚(WebFetch platform.claude.com 实查,2026-06-07):Opus 类基础输入约 $5/MTok、Sonnet 类约 $3/MTok。一个把 200K token 知识库整体塞入的查询,光输入侧就是数十美分量级;而 RAG 取 5 个片段,输入侧通常是分以下。第三方工程博客(TianPan.co《Long-Context vs RAG 生产决策框架》,2026-04-09)给出过一个极端估算:RAG 约 $0.00008/查询,长上下文(~160K token)约 $0.20/查询,折算”1,250x 更贵”。

[!warning] 这个 1,250x 不要当确证数字背 它来自特定假设(模型版本、token 数、cache hit rate)下的第三方估算,不是受控实验。实际差距随场景剧烈波动。可安全引用的只是数量级方向:高频查询场景下,长上下文的边际成本比 RAG 高 2-4 个数量级。一旦你的产品是”每天百万次问答”,这个数量级就是生死线。

Prompt Caching 把这条曲线压平了一截,但没抹掉。 Claude 缓存命中读取约为基础价的 0.1x(Opus 约 $0.50/MTok),写入分 5 分钟档(1.25x)和 1 小时档(2x)。如果你的长语料前缀稳定、查询密集,缓存能把长上下文的有效成本拉低近一个数量级——这正是 Prompt Caching 和 KV Cache 在上下文工程里的杠杆点。但缓存只对前缀稳定的场景有效:语料一更新,缓存即失效,长上下文又要重新付全价。RAG 没有这个脆性——它本来就只检索变化的那部分。

Gemini 这边还多一道坎:Gemini 1.5 Pro 采用分级定价,128K token 以下一个价,超过后约翻倍(来源:MindStudio 博客,第三方引用,Google 官方价需 cloud.google.com 实查〔待核实〕)。Anthropic 目前对 1M 窗口统一单价,无门槛——这是 Claude 在超长上下文场景的一个被低估的定价优势。

§2 延迟轴:RAG 的第二条护城河

延迟和成本同源:送进去的 token 越多,prefill 阶段越慢。TianPan.co 同一框架给出的量级(第三方估算,非受控实验):RAG 端到端约 1 秒;长上下文 ~160K token 约 20 秒,~890K token 可达 60+ 秒。

对 PM 来说这是个产品形态约束,不是参数调优:任何有交互式 SLO(对话、搜索框、客服)的场景,几十秒的首字延迟直接出局。长上下文的延迟只在离线/异步/可接受长等待(长文档分析、批量报告、深度研究)的场景里可容忍。这条轴上 RAG 几乎单方面占优,除非你的产品本来就是”提交任务、稍后取结果”的形态。

§3 质量轴:长上下文的纸面优势与真实塌方

这是争议最激烈、也最容易被营销 NIAH 数字误导的一轴。

纸面数字很漂亮。 Gemini 1.5 技术报告(arXiv 2403.05530,Google DeepMind,2024)称在 Needle-in-a-Haystack 单事实检索上,文本模态 100% recall 至 530K token、>99.7% recall 至 1M token。这是”塞进去能找到”的证据。

但 NIAH 是一个被业界共识判定为”过于简单”的测试。 真实生产里的查询不是”找一根针”,而是多跳推理、跨段落综合、抗干扰。一旦换上这类任务,长上下文就开始系统性塌方:

  • Lost in the Middle(Liu et al., TACL 2024, arXiv 2307.03172):20 文档多文档问答中,答案在首位约 75% 准确率,挪到第 10 个(中间)降到约 55%,呈 U 形曲线。极端情形下 GPT-3.5-Turbo 给更多上下文反而低于其闭卷表现(56.1%)——“塞得越多越差”。
  • RULER(Hsieh et al., NVIDIA, COLM 2024, arXiv 2404.06654):声称 128K 窗口的模型里,Mixtral 在 128K 时实测得分仅 44.5/100;17 个模型中仅 4 个在 32K 达到 Llama-2-7B 4K 的及格线。
  • NoLiMa(Adobe Research, ICML 2025):问题与”针”无字面重叠、需语义推理。Gemini 1.5 Pro(声称 1M)从 1K 时 92.6% 跌到 64K 时 48.2%;Claude 3.5 Sonnet(声称 200K)从 87.6% 跌到 29.8%。研究结论:GPT-4o 的实际有效上下文约 8K,尽管声称 128K。
  • Context Rot(Chroma Research, 2025-07 系统测评):测了 18 个前沿模型(含 Claude Opus 4、Gemini 2.5 Pro、GPT-4.1、Qwen3-235B),无一例外,全部随输入长度增长而性能单调下降。

把这些放一起,质量轴的真相是:标称窗口 ≠ 有效窗口。开源模型有效上下文通常 ≤ 声称窗口的 50%(An et al. 2024, arXiv 2410.18745,与 RULER 交叉验证)。根因被部分研究归到 Transformer 的 RoPE 长距离衰减,是架构属性而非可训练消除的能力缺陷(详见本专题 A03 Context Window 作为资源·非越大越好 对 context rot 的展开;原子机制见 Attention)。

[!note] 质量轴的结论不是”长上下文不行” 而是:在它的有效窗口内、对它擅长的任务(全局摘要、跨文档推理),长上下文质量确实高于 RAG;一旦超出有效窗口或遇到抗干扰检索,它会塌方,而 RAG 因为只送高相关片段,反而稳。 EMNLP 2024 Industry Track 论文(Li et al., arXiv 2407.16833)的核心结论印证了这点:资源充足时长上下文平均性能持续高于 RAG,但 RAG 成本优势显著——所以最优解是按查询路由。

§4 判断主轴:90% 的人会在这四个点上搞错

这一节是命门。逐点四件套(症状 → 为什么错 → 正确做法 → 真实反例)。

错点一:用 NIAH 跑分给老板演示,就以为长上下文能扛生产。

  • 症状:demo 里”1M token 全塞进去,问什么答什么”,上线后多跳查询大面积答错。
  • 为什么错:NIAH 测的是单事实定位,已被 HELMET(Yen et al., arXiv 2410.02694)证明在 128K 对前沿模型已饱和(全满分),无法区分能力。
  • 正确做法:用 RULER / NoLiMa / 自建的多跳抗干扰集评估你的真实任务,把”有效窗口”而非”标称窗口”写进选型文档。
  • 真实反例:NoLiMa 里 Claude 3.5 Sonnet 在 64K 处只剩 29.8%——标称 200K,实际撑不到声称的三分之一。

错点二:小语料也硬上 RAG,陷入过度工程。

  • 症状:一个 5 万字的产品手册问答,搭了向量库 + Embedding 服务 + chunking 管道 + reranker,维护成本高、还引入检索召回失败。
  • 为什么错:把”RAG 是先进的”当信仰。语料能完整装进有效窗口、查询低频时,RAG 这套管道的复杂度是纯负担。
  • 正确做法:语料 < 有效窗口 且 查询低频/可接受延迟 → 直接长上下文塞进去(配 Prompt Caching),省掉整条检索管道。
  • 真实反例:这正是长上下文真正”吃掉”的那部分场景——不是吃掉 RAG,是吃掉对小语料的过度 RAG 化。

错点三:把成本算成”一次性”,忽略乘以 QPS。

  • 症状:选型时只看单次调用 demo 费用觉得”还好”,上线按真实 QPS 一乘,账单爆炸。
  • 为什么错:长上下文成本是每查询都重付全语料,RAG 是每查询只付片段。差距被 QPS 放大。
  • 正确做法:选型公式里把 月成本 = 单查询成本 × QPS × 30天 显式算出来,再决定。高频必走 RAG 或缓存。
  • 真实反例:TianPan 估算的数量级差(2-4 个数量级),在百万 QPS 下就是每月数千 vs 数百万美元的区别。

错点四:以为”长上下文 + RAG”不能共存,二选一。

  • 症状:团队分两派吵谁替代谁,错过最优解。
  • 为什么错:二者正交。RAG 决定调哪些片段进窗口,长窗口决定能容纳多少高相关片段。
  • 正确做法:用 RAG 召回 + 长窗口容纳更多/更完整的 chunk + Self-Route 路由(简单查询走 RAG,复杂多跳走长上下文)。这正是 RAGFlow 2025 年终回顾里”RAG 进化为 Context Engine”的含义。
  • 真实反例:Self-Route(EMNLP 2024)把 Gemini-1.5-Pro 计算成本降 65%、GPT-4o 降 39%,同时维持接近长上下文的质量——共存比单选更优。

§5 产品 PM 视角补盲

工程轴之外,有三个”看走眼”点:

  1. 数据时效性 = 商业风险,不只是技术问题。 长上下文把语料”烤”进单次请求,语料一旧,答案就旧;RAG 检索的是实时索引。做金融、法务、定价类产品,RAG 的”动态数据”属性是合规底线,不是性能优化。
  2. 缓存脆性影响商业模式定价。 如果你按”长上下文统一价”给客户报价,却没算到客户语料频繁更新导致缓存频繁失效,成本模型会失真。Prompt Caching 的回本前提(前缀稳定)要写进 SLA。
  3. “塞进去就行”会喂大幻觉。 Context Rot 研究发现:结构连贯但含相关无关事实的长文档,比随机干草堆更容易触发幻觉(相关性诱导误判)。给用户的产品里,长上下文塌方表现为”自信地答错”,比 RAG 的”检索不到”更难被用户察觉、危害更大。关联 幻觉。

§6 对手框架回应

对手立场一(长上下文派):Google/长上下文阵营主张”窗口够长,RAG 是过渡技术”。 接受:在它的有效窗口内、对全局推理任务,长上下文确实质量更高、工程更简单(EMNLP 2024 数据为证)。边界:这个判断只在”小语料 + 低频 + 可接受延迟/成本”的象限成立。一旦语料超出有效窗口、查询高频、要求低延迟,长上下文的成本和延迟曲线让它在生产里不可行。我赌的是:未来 2-3 年架构层面的 Context Rot 无法根治(RoPE 衰减是架构属性),所以”有效窗口 < 标称窗口”的鸿沟会持续存在,RAG 的位置不会消失。

对手立场二(Cognition《Don’t Build Multi-Agents》, 2025):主张全上下文共享优于切分,隐含”少做检索/隔离、多塞完整 trace”。 接受:对单 agent 决策连续性而言,完整上下文确实减少”上下文割裂”导致的误判,这是对的。边界:Cognition 谈的是 agent 间协作的 trace 共享,与”语料检索 vs 全塞”是不同问题;它不构成对 RAG 的否定——它否定的是过度切分决策历史,而非否定检索外部知识。把两件事混为一谈是常见误读。

Rick 未读的对手框架(破 echo chamber):

  • RAGFlow 的”RAG 即 Context Engine”论(2025 年终回顾):它跳出”检索 vs 生成”的旧框,主张 RAG 的终态是为 agent 做跨多源的智能信息组装层。这逼问我本节点的盲点:我把 RAG 当”片段调取器”可能太窄,它正在长成上下文工程的编排中枢。
  • Almond AI《Context is not all you need》(对 Anthropic Contextual Retrieval 的回应):指出 Anthropic 官方的 67% 失败率降低是内部测试集,外部独立复现少,chunk 质量与检索架构同样关键。这提醒我:不要把任一方的官方 benchmark 当普适结论。

failure scenario 显式标注: 本节点”RAG 成本恒低”的结论,在超长 reranker 链 + 高 Top-K + 大 chunk 配置下会失效——此时 RAG 的检索+精排+大片段输入成本可能逼近中等长上下文。

§7 跨域呼应

调度 Kuhn 的”范式不可通约” 概念(范式,入口 0114认识论)。

唱衰 RAG 的叙事,本质是把长上下文与 RAG 放进同一个可通约的标尺(“谁的性能更强”)去比,然后宣布胜负。但 Kuhn 的洞见是:当两个东西解决的根本问题不同时(一个是信息路由,一个是窗口利用),用单一标尺排序本身就是范畴错误。“长上下文更强所以 RAG 该死”这个推理,错的不是结论而是前提——它假设了一个并不存在的公度尺。这改变了我对整个争论的判断:正确的提问不是”哪个更强”,而是”我的查询落在哪个象限”,这是一个路由问题,不是一个排序问题。这也呼应了 0114认识论 里”先问问题对不对,再问答案对不对”的元立场。

§8 PM 决策启示

  • 面试怎么用: 被问”长上下文出来了,RAG 是不是要淘汰”,别接二选一的框。回答模板:“先拆三轴——成本上 RAG 高频场景便宜 2-4 个数量级,延迟上 RAG 约 1s vs 长上下文几十秒,质量上长上下文标称窗口远大于有效窗口(NoLiMa:Claude 3.5 Sonnet 64K 处只剩 29.8%)。所以不是替代,是按查询象限路由,Self-Route 这类混合方案才是终态。” 一句话亮出判断密度。
  • 选型怎么用: 把决策表打印出来贴墙上。语料规模 / 查询频率 / 延迟 SLO / 更新频率 / 查询类型五维,落到象限再选,别凭”哪个先进”拍脑袋。先用 RULER/NoLiMa 测出你任务上的有效窗口,再决定语料是否真能”塞进去”。
  • 复现怎么用: 起步做 Self-Route——一个轻量分类器判断查询复杂度,简单事实检索路由到 RAG,跨文档综合路由到长上下文;成本敏感处叠 Prompt Caching。这套比纯长上下文省 39-65% 算力(EMNLP 2024)。

§9 与已有节点的关系

  • 对照 c09 - RAG 架构:c09 已论证过长上下文 vs RAG 的 O(N²) 成本与 Lost in the Middle,并给出 Chunking/检索范式/Reranker/评估矩阵。本节点不复述这些基础,而是做升级对照:把 c09 的”RAG 架构内部如何做”上升为”RAG 与长上下文之间如何选”,补入 2024-2026 的硬基准(RULER/NoLiMa/Context Rot 18 模型测评)、当前官方定价、Self-Route 路由证据,完成从”怎么搭 RAG”到”何时不搭 RAG”的抽象层跃迁。Anthropic Contextual Retrieval(2024-09-19,失败率 -49% 至 -67%)的细节属 c09/m204 - RAG 生产环境：Chunking 与范式演进 范围,此处只作指针,不展开。
  • 对照 m209 - 推理成本控制手册:m209 给出推理成本的通用控制框架(批处理/缓存/模型分级)。本节点把其中”长上下文的每查询全语料重付”这一具体成本结构实例化到 RAG 选型决策,并补 Prompt Caching 的脆性边界(前缀稳定才回本)——是 m209 成本原则在”检索 vs 全塞”这一具体决策上的落地,不重述其通用方法。

§10 关联节点

核心(必读):

延伸(可选):

修订日志

  • R0(2026-06-07):首稿。建立三轴互补框架,落地四错点判断主轴,接入长上下文/Cognition 两个对手立场 + RAGFlow/Almond 两个未读框架,Kuhn 跨域呼应,与 c09/m209 升级对照。硬基准(Lost in the Middle/RULER/NoLiMa/Context Rot/EMNLP Self-Route)与官方定价均已接地,Google Gemini 分级定价标〔待核实〕。