先说结论：替代不了，但长上下文确实把 RAG 的适用边界砍掉了一大块。知识库够小、更新够慢、不要求出处——这种场景现在真没必要再搭一套检索。反过来，只要牵扯到「这句话是哪儿来的」，你还得老老实实做检索。这周素材大部分跟这题无关，但有三条刚好从两头把这个判断钉住了：HN 上那篇 Handbook.md 讲长文档塞进上下文管不住 agent，ArXiv 的 ExtractBench 把「来源证据」直接写进评分标准。一正一反，边界清楚得很。
长上下文最爽的地方，也是最坑的地方
长上下文模型最直接的诱惑：把检索系统整个删掉。公司内部几百份文档、几千条 FAQ——窗口够大的话，直接拼进 system prompt，完事。不用维护 embedding pipeline，不用调召回参数，不用处理 chunk 切割后语义被切碎的问题。
这个诱惑是真实的。知识库总共就几百页 PDF 的场景，全塞进上下文，预算和复杂度远低于维护一套检索，这种团队我见过不少——人力和维护成本是隐形的，但是最大的那一块。
账要算在另一边：上下文是你花真金白银买的。窗口越大，prefill 延迟和账单跟着线性往上走。100K 上下文的场景和 10K 不是「10 倍」的区别，是你得重新想一遍这个系统的请求频率、并发量、超时预算。很多场景不是「塞得下」就赢了，是「塞得下且响应时间还能看」才赢了，这两个要求差得很远。
而且「塞得下」和「用得上」之间，隔着一道实证出来的沟。
塞进去不等于用得上
HN 上那篇 Handbook.md 论文标题就很直接：长政策文档并不能可靠地约束 agent 行为。把公司手册、操作规范全塞进上下文，agent 该违规还是违规。
问题在这：上下文窗口大，不意味着模型把窗口里每个位置同等对待。中间段的注意力本来就衰减，文档一长，前面写的规则后面就被「遗忘」了。我不知道这个衰减的具体曲线长什么样——这得拿自己的文档去测——但谁做过长文档 QA 都清楚，从 100 页 PDF 里找一句夹在中间的话，和从检索结果里找，完全是两种体验。
所以我的判断是：长上下文适合「文档本身就是被读的对象」的场景，比如整本手册从头到尾读一遍。但如果答案是藏在「一堆文档里找那么几段」，塞进去不解决问题，只是把「检索失败」换成了「模型没注意到」——后者更难排查。
什么时候我劝你别上 RAG
我自己划线的标准三条：
一条，知识库总量能塞进预算内的窗口。什么叫预算内？别信厂商宣传的最大窗口，拿真实文档跑一遍，量你自己的 p95 延迟和账单。
二条，更新不频繁。知识库每周都在改，你每次都要重新生成完整上下文、重新定价——这个成本很快就让你怀念「检索只拿增量」的方案。半年不动的东西，全塞很稳。
三条，答案不需要给出处。你问「退货政策是什么」，模型说「30 天内可退」，没人追问「哪儿写的」——全塞没问题。可一旦是合规审计、技术支持、法律场景，答案没有出处等于不存在。
需要出处，就得老老实实检索
出处是硬需求，不是体面问题。ArXiv 这周的 ExtractBench 做 schema-guided 文档抽取，评分里专门带一项 source evidence——每个抽取出来的值必须指向文档里的来源。你注意这个设计，它不是只问「值对不对」，是每个值都要能追溯。没有来源支撑的值，在审计场景里就是零分。
这种需求，全塞上下文给不了。你问模型「这个数字哪来的」，它给你编一段「从第 X 页的表中总结」——来源是幻觉出来的，比没有来源还糟。检索返回的每一条都带文档 ID、页码、上下文片段，这些能追溯、能复核、能写进审计报告。检索不是可选项，是地基。
再举个这周的现成例子，HN 上那个 Bullshit Detector，给视频和文章做 fact-check。事实核查的本质就是：拿到一个说法，然后去查证来源。你不可能把全世界的事实塞进模型上下文——你得在需要的时候把相关片段拉过来。这就是 RAG 的核心价值：不是记住知识，是在需要的时候找到知识。
按我现在看，接下来一两年的形态大概率是混合的：小知识库直接塞，大知识库或者强溯源要求的场景走检索，中间地带按实际情况切。也许 6 个月后回头会被打脸——窗口还在涨，成本还在降。但「需要出处」是信息架构层面的需求，不是模型能力层面的需求，窗口再大也绕不过去。长上下文砍掉了 RAG 一块地盘，但「可溯源」这张牌还攥在检索手里，短期丢不了。