RAG 与长上下文的定位
百万级窗口不等于不需要检索：成本随 token 线性涨、context rot 让长输入的有效性塌方、知识更新与权限过滤仍要在窗口之外解决。「RAG 已死」之争的正确答法是按数据规模、更新频率、成本预算划边界，而不是站队。
也叫：RAG 已死 · 长上下文 vs RAG · 全量塞窗口
「RAG 已死」之争：怎么答才不掉坑出自 T2-1
每隔半年就有人喊一次「长上下文杀死 RAG」。面试官抛这个问题，考的不是立场，是你的工程判断力。标准答案是：互补，不是替代。 理由分四条：
- 成本与延迟：每次都灌百万 token，费用和首字延迟都是数量级差距；RAG 只送最相关的几千 token。
- 效果：输入越长模型越容易失焦（context rot），有实验显示模型在超过某个长度后准确率会「塌方」式下跌，不是线性变差。喂得多 ≠ 答得准。
- 规模：企业知识库动辄 GB 到 TB 级，任何上下文窗口都装不下。
- 可控性：RAG 能做权限过滤、时效过滤、引用溯源——这些是 toB 场景的硬需求，长上下文给不了。
加分收尾：长上下文真正改变的不是「要不要 RAG」，而是 RAG 的参数——窗口变大后可以放宽 chunk 粒度、多送几个候选、少做激进压缩。它让 RAG 更好用，而不是让它消失。
以上节选自T2-1 RAG 全链路总览 &「RAG 已死」之争，读全文能看到前后语境。