每次上下文窗口扩容，都会有人宣布 RAG 已死。这个论断把两件不同的事混为一谈了：窗口大小是一个能力上限，RAG 是一种知识组织架构。前者变大并不会让后者失去意义，就像硬盘变大不会让数据库失去意义。
但反过来说，「凡是外部知识都上 RAG」同样是错的，而且这个方向的错误在实践中更常见——团队为一个只有 20 篇文档的场景搭了完整的向量检索流水线，引入了切分、embedding、索引更新、召回调优五个新的故障点，只为了解决一个「把 20 篇文档拼进 prompt」就能解决的问题。
所以正确的问题不是「谁取代谁」，而是：对这一块具体的知识，把它放进上下文和放进索引，各自的成本与风险是什么？
「塞进去就行」隐含了三个常被忽略的代价：
① 成本随长度超线性增长。1.1 讲过，prefill 阶段的 attention 计算量约为 O(n²)，KV cache 显存为 O(n)。把 100K token 全塞进去，每次调用都要为这 100K 付费和付延迟——而其中真正相关的可能只有 2K。RAG 只送相关的部分，成本可以差出一到两个数量级。
② 长上下文里的信息定位能力会衰减。这一现象常被称为 lost in the middle（中间迷失）——这是下面案例的主题，也是最容易被低估的一条：内容在上下文里，不等于模型能用上它。
③ 知识库通常远大于任何窗口。企业文档动辄几十万页，且每天都在增加。窗口再大也装不下，且这个差距不会缩小——文档增长的速度通常快于窗口增长的速度。
① 它引入了一整条新的故障链。3.1 列过：入库 → 切分 → 向量化 → 召回 → 排序 → 生成，六个环节各自会独立出错，且需要各自的监控与调优。
② 它会丢失全局视野。这是 RAG 的结构性弱点：它按相似度取回局部片段。凡是需要「通读全文才能回答」的问题——「这份合同里有几处互相矛盾的条款」「这份报告整体的论证逻辑是什么」——检索天然无能为力，因为答案不在任何单个片段里，而在片段之间的关系里。
③ 冷启动成本高。要跑通并调好一条 RAG 流水线，通常是数周的工作。而把文档拼进 prompt 是一个下午的事。
讨论「RAG 还是长上下文」时，经常漏掉一个更重要的问题：这块知识是不是根本不该以文本形式提供？
如果知识是结构化且实时的（库存、订单状态、账户余额、今天的排班），正确答案既不是 RAG 也不是长上下文，而是工具调用（4.1）。把数据库里的数据同步到向量索引，等于给自己造了一份必然过期的副本，还牺牲了精确查询能力。
如果需要改变的是模型的行为而非它掌握的事实——输出风格、领域推理方式、特定格式——那三个选项都不对，应该看 5.1 的升级路径。
Liu 等人设计了一个干净的实验：在多文档问答与键值检索任务中，把包含正确答案的那份材料放到上下文的不同位置，其余材料保持不变，然后观察准确率如何变化。这个设计的巧妙之处在于——信息始终都在上下文里，唯一变化的只有位置。
论文的结论是：当前的语言模型并不能稳健地利用长输入上下文中的信息。
三个直接的工程含义：
① 「上下文窗口 128K」是容量指标，不是能力承诺。能装下和能用好是两件事。任何基于「反正窗口够大」的架构决策，都需要在自己的任务上验证有效利用率。
② 排序在 RAG 里比你以为的更重要。既然位置影响利用率，那么 rerank（3.3）的价值就不只是「让好的排前面以免被截断」，还包括让最相关的材料落在模型最容易利用的位置。一个实用技巧是把最相关的片段放在上下文的开头或结尾，而不是按相关性顺序一路排下去。
③ 少即是多。召回 20 个片段不一定比召回 5 个好——多出来的 15 个不仅增加成本，还会把关键信息挤到中间位置去。这与直觉相反，也是许多 RAG 系统「召回数量调大后效果反而变差」的原因。
需要注意的边界：这项研究测的是特定模型与特定任务，具体模型的表现会随架构与训练方式演进而变化。可迁移的不是「中间一定差」这个结论，而是「必须实测有效利用率，不能假设窗口内均匀可用」这个方法。做法很简单：把已知答案的材料放在不同位置各测一轮，看准确率是否稳定。
长上下文的成本已被 prompt caching 大幅改变：若同一份长文档会被反复提问（如「上传一份合同后连续追问十个问题」），开启缓存后除首次外的调用只需为增量部分付费（2.2）。这类「一份文档、多轮追问」的场景，长上下文的经济性往往优于 RAG——而这一点在缓存普及前是不成立的，是近年少数真正改变了架构选择的变化。
反过来，「一次性提问一份新文档」的场景缓存帮不上忙（写入了也没人复用），长上下文的成本劣势依然明显。
长上下文评测：不要只看厂商标称的窗口大小。可参考公开的长上下文评测（如 RULER、HELMET 等工作），它们衡量的是有效利用长度而非标称长度，两者常有明显差距。更可靠的做法仍是在自己的任务上做位置敏感性测试。
混合形态越来越常见：先用检索粗筛到几万 token，再让长上下文模型在其中做全局推理——这个组合避免了纯 RAG 的碎片化，也避免了纯长上下文的成本爆炸，是当前工程上较优的默认形态。
A 退款政策 → RAG。理由不是「知识多」，而是三个硬性属性：会变（政策更新频繁，微调跟不上）、需溯源（客服场景必须能给出制度原文）、可能需要权限区分（不同渠道政策不同）。这三条任何一条成立，都指向检索。
补充：若政策只有寥寥几条且很少变，直接写进 system prompt 比 RAG 更简单可靠——别忘了这个更便宜的选项。
B 稳定 JSON → 都不是，用 constrained decoding（约束解码）。这是本题的关键陷阱。格式遵循是一个可以在解码层强制保证的问题：通过语法/schema 约束采样空间，让模型在结构上不可能输出非法 JSON。用微调去「教」格式，既费钱又只能提高概率而无法保证；用 RAG 更是完全不相干——格式不是知识。
工程上：先用约束解码保证结构合法，再用 schema 校验兜底，最后才考虑用少量样本微调来改善字段内容的质量。
C 专家推理风格 → fine-tune。这是微调真正的适用场景：要改变的是行为方式（怎么组织论证、用什么措辞、关注哪些要点），而不是掌握哪些事实。这类隐性风格无法通过 prompt 完整描述，也无法从检索到的文档中现学。
但仍应遵循 5.1 的升级路径：先试 few-shot，如果几个精选示例就能带出风格，就不必微调。
这道题的通用判断法：先问「要改的是事实还是行为？」——事实走 RAG 或工具调用，行为走 prompt / few-shot / 微调。再问「有没有更底层的确定性手段？」——格式这类问题，解码层的约束永远优于概率层的训练。
先判断查询类型：合同审查中大量问题是全局性的——「有没有互相矛盾的条款」「责任分配是否对等」「与我方标准模板有哪些偏离」。这类问题的答案不在任何单个片段里，RAG 在结构上就无法回答。这一条基本已经定了方向。
再算成本：8 万 token 全文，30 轮提问。
• 无缓存：30 × 80,000 = 240 万输入 token，成本高且每轮 TTFT 都很长。
• 有 prompt caching：合同全文作为稳定前缀只需首次完整付费，后续 29 轮命中缓存，按 1/10 折扣估算 ≈ 80,000 × (1 + 29 × 0.1) ≈ 31 万 token 当量，成本降到约 1/8，TTFT 也大幅改善。
• RAG：每轮送 3K，30 轮 = 9 万 token，绝对值最低——但它答不对全局性问题。
结论：长上下文 + prompt caching。这正是「一份文档、多轮追问」的典型形态，缓存把长上下文的成本劣势基本抹平，而 RAG 的质量劣势无法弥补。
注意前提：需确认缓存 TTL 覆盖用户的提问节奏（若用户思考几十分钟才问下一个问题，缓存可能已过期），以及模型对 8 万 token 的有效利用率——建议先做一次位置敏感性测试。
需要区分三个不同的论断，因为它们的答案不同：
① 「窗口变大会减少 RAG 的使用场景」——对。中小规模知识库（几十万 token 以内）确实正在从 RAG 迁回直接塞上下文，prompt caching 加速了这个趋势。这是真实发生的变化。
② 「窗口变大会让 RAG 消失」——不对，有四个理由与窗口大小无关：成本——为 1000 万 token 付费去回答一个问题，经济上不成立，稀疏访问必然需要索引；权限——不同用户可见范围不同，必须在检索层过滤，无法靠一个共享上下文实现；溯源——需要指明答案出自哪份文档哪一段；实时性——数据每秒在变，总不能每次重塞全量。
③ 「RAG 的形态会变」——这才是最可能的答案。它正在从「切碎 + 向量召回」演化为「更粗的粒度 + 更强的筛选 + 交给长上下文做全局推理」。检索的角色从「找到那句话」变成「圈定相关范围」。检索作为一个架构层不会消失，但它的实现会持续变化。
加分：指出「塞进去 ≠ 用得上」——Lost in the Middle 一类研究表明长上下文中的信息利用率并不均匀，所以窗口增大带来的收益不是线性的，这本身就限制了「全塞进去」路线的上限。