长上下文能替代检索增强吗：先算缓存命中率

窗口大不等于更省事。决定长上下文是否比检索便宜的不是窗口大小，而是每次请求真正需要多少语料，以及同一份前缀在一小时内被复用几次。

缓存价格表说的其实是两件事

各家定价页把缓存写成一行很干净的折扣：读取按输入价的百分之十计价，写入按一点二五倍（五分钟）或两倍（一小时）。这句话被引用得太多，以至于很多人只记住了前半句。

后半句才是常驻方案的账单来源。把语料放进窗口不是一次性买断，它是一个按窗口重复发生的写入。五分钟的缓存窗口一小时要重写十二次，一小时的窗口一小时写一次，价格翻倍但次数降到十二分之一。这两个数字一起决定了常驻方案的下限成本，而它跟你的请求量无关。

还有第三行常常被跳过：长上下文在很多厂商那里是加价档而不是标准档。超过一定长度之后输入按更高单价计费，同时模型会对超长历史做自动压缩。厂商自己把这些动作设成默认值这件事，本身就是它对可靠上下文的判断。如果窗口真的可以被用满，压缩和加价都没有必要存在。

把这三行放在一起看，得到的结论跟直觉相反：缓存折扣降低的是读取成本，而常驻方案的成败由写入成本和读取的重复次数共同决定。折扣越大，越说明厂商预期你会在同一个前缀上反复读。

交叉点由三个数字决定

把两种架构写成成本函数，交叉点是能直接算出来的。设语料为 N 个 token，输入单价为 P（每百万 token），每次请求实际需要的语料为 K，某个缓存窗口内到达 r 次请求。

• 常驻一个窗口：写入花掉 N 乘以写倍数，每次读取再花掉 0.1N。
• 检索一个窗口：每次只把 K 送进窗口，花掉 r 乘以 K。

两者相等时可以得到 r 的临界值：写倍数乘以 N 除以 K 减 0.1N。这个式子先给出一个否决条件，再给出一个数量条件。

否决条件在分母上。如果 K 小于 0.1N，也就是每次请求需要的语料不到整份语料的百分之十，分母为负，常驻方案在任何复用率下都不会赢。原因很直观：检索只为你真正用到的那一片付费，而缓存读取按整份语料的百分之十付费。语料越大、查询越窄，这个差距越大。

举一个具体的例子。四千万 token 的知识库，中档模型输入单价每百万美元两点五，检索每次取八千 token。检索侧每次请求零点零二美元；常驻侧每次读取零点一乘以四千万 token，也就是十美元。差五百倍，而这个差距不会因为请求变多而消失，请求越多差距越大。

数量条件在分子上。当 K 超过 0.1N 之后，临界复用次数等于写倍数除以 K 占 N 的比例减去零点一。三种典型语料落点差异很大。

• 四十万 token 的一份合同集，每次推理需要其中三十万 token（占七成五）：一小时缓存的临界复用约为每小时三次。合同审查场景里一个小时内对同一份文件问上十几次很常见，常驻成立。
• 一百万 token 的产品资料库，每次请求需要二十万 token（占两成）：临界复用正好每小时二十次。这个数字对多数内部工具来说是偏高的门槛，夜间批处理能过，白天零散问答过不了。
• 四千万 token 的工单加手册库，每次请求需要八千 token（占万分之二）：除非把检索层整个删掉、改成每次塞几十万 token 进去，否则常驻在数学上不成立。

这两种缓存的比较还有一个反直觉之处。五分钟缓存的写倍数更低（一点二五对二），但窗口只有十二分之一长，维持同样一个前缀常驻的成本是一小时缓存的一百五十倍。低价档的缓存是为高频短前缀设计的，不是为语料常驻设计的。

把复用次数除以窗口长度，会得到第三种常见的误判。二十次每小时听起来不高，但它是平均值，不是峰值。请求如果集中在夜间批处理里，一小时窗口可以覆盖整批，门槛轻松过。请求如果在白天均匀散开，比如每三分钟一次，一小时只有二十次左右，刚好压线，而五分钟窗口下同样的分布折算到每小时是十二次，远达不到一百五十次的要求。同一套架构在批处理场景成立，在均匀到达场景不成立，差别不在语料也不在模型，而在到达分布。这就是为什么测量那一节把请求时间分布排在第一位。

写入成本还有一层不容易被算进去：语料更新。缓存要求前缀逐字节一致，任何一次语料变更都会让整个前缀失效并重写。一个每天更新上千条记录的知识库，如果更新发生在白天，那么每一个窗口都可能要重写一遍，写入成本按窗口数乘语料规模增长，跟请求量完全脱钩。检索层面对同样的情况只需要重建受影响的那一小片索引，这也解释了为什么更新频繁的语料很少是常驻方案的好候选。

算得过账不等于答得对

成本交叉点只回答了一半问题。另一半是：把语料全部塞进窗口之后，模型还能不能找到你要的那一段。

Chroma 的上下文腐化报告测出的现象是，性能在窗口被填满之前就开始下降，而不是在触顶时才断崖。公开的顺序检索基准把这个问题量化得更细：在八万到十二点八万 token 的区间里，六款模型的最优成绩是百分之六十三点五，也就是说连最好的那一个也有三分之一强的顺序检索任务做不对。厂商侧的多针测试给出的是同一方向的数字，单针能过九成五的任务，换成多针会掉到六成上下。

这不是一个等下一代模型就能解决的问题。它是注意力机制在长序列上的性质，改善是渐进的，不是阶跃的。第三方分析给出的实践区间是十二点八万到二十万 token，超过之后多数模型在多针任务上不再可靠。厂商的默认动作也印证这一点：一分钟级别参数量的模型把自动压缩的触发点设在十五万 token，另外两家在超过二十万到二十七万 token 之后开始按更高单价计费。

所以真正可用的常驻上限不是产品页上的窗口大小，是你自己的语料和任务测出来的安全预算。这个数字只能自己测，因为腐化的速度和任务的检索难度直接相关。同一份语料，改成多跳或多针提问，安全预算会明显收缩。

删掉检索层会顺手删掉两样东西

成本表上，检索层是纯支出。实际运作里它是两个基础设施：一个是证据出处，一个是权限边界。

证据出处这一项在受监管行业里不是可选项。走检索链路时，答案可以回指到被判定的那几段原文，审计需要追溯时可以复现输入。改成常驻之后，输入是整份语料，回指的精度会下降到你只能回答模型看过什么，而不是答案具体依据哪一段。这个变化在事故复盘时很难补齐，因为事后无法重建当时的注意力分布。

权限边界这一项更常被忽略。检索层天然是一个过滤器：谁可以看哪一段，在进入窗口之前就被执行。常驻方案把语料整体放进前缀，权限只能在上游做隔离，也就是说每一组可见范围需要自己的一份缓存前缀。这会直接乘进写入成本，而这一点几乎从不出现在常驻方案的成本对比里。

三种架构各自的判据

到这里可以把选型压缩成三个可测的问题，而不是一个风格之争。

我们的判断

长上下文与检索增强之间的取舍被算错了层。讨论通常落在这两个词谁更先进，而成本函数里真正起作用的是每次请求需要语料的比例，以及同一份前缀在一个缓存窗口里的复用次数。窗口大小既不是分子也不是分母。

第二个判断是，缓存折扣被普遍误读为常驻方案近乎免费。读取确实便宜，但常驻的账单主要来自写入，而写入按窗口重复发生。把语料的正常更新也算进去，写入成本会更高，因为任何一次语料变更都要重写整个前缀。

基于这两个判断，我会把默认动作定成不迁移、先测量。绝大多数企业语料的查询是窄的，也就是 K 除 N 很小，这一类场景里常驻在数学上就没有胜算，争论本身是浪费。反过来，如果量出来的复用次数很高、查询需要的语料比例很大，那迁移的理由跟窗口大小无关，而是检索层在这类任务上本来就在做无用功。

最后一个判断与合规有关：检索层在多数架构成熟的组织里同时是证据层。删掉它省下的检索成本，会以审计可追溯性的形式重新出现。这一点在推销常驻方案的材料里通常不提，但它是采购评审时最容易被问到、也最难临时补齐的一项。

两周能做完的三次测量

上面所有结论都可以用现有数据验证，不需要先做架构迁移。

1. 把过去三十天的请求时间打出来，算每天每小时到达次数的中位数和九十五分位。这个分布决定了复用上限，也决定了五分钟缓存和一小时缓存哪个值得谈。
2. 在自己的语料上跑一次多针检索测试，不用外部榜单，只记录准确率开始下降的长度。得到的是你自己的安全预算，它通常会明显小于产品页上的窗口。
3. 在现有链路加一个缓存指标，分别记录写入和读取的 token 数。手上有了真实命中率，有效输入单价就能算出来，与检索侧的单次成本直接可比。

三次测量做完，交叉点公式里的三个数字就齐了。结论要么是常驻成立、迁移有账可算，要么是检索层的成本被证明远低于常驻，两种结果都比现在争论窗口大小更有用。

参考来源

• Anthropic 缓存写入与读取的价格倍数（写入一点二五倍或两倍，读取百分之十）：anthropic.com/pricing
• 缓存倍数与批量折扣的第三方汇总，含各家缓存单价对照：flexera.com/blog/ai/prompt-caching-breakdown
• 上下文腐化报告，性能在窗口填满前开始下降：research.trychroma.com/context-rot
• 顺序检索基准，六款模型在八万到十二点八万 token 区间最优成绩百分之六十三点五：arxiv.org/abs/2504.04713
• 厂商默认压缩点与长上下文加价档位的汇总，含多针准确率下滑与十二点八万到二十万 token 的实践区间：glasp.co/articles/context-rot-rag-long-context-hybrid
• 多针任务准确率从百分之九十五降到百分之六十的厂商侧测试：openlayer.com/blog/needle-in-haystack-ai-testing-llm-context-retrieval
• 长上下文与检索并用的行业分析：atlan.com/know/llm-context-window-limitations