有了百万级长上下文，为什么还要 RAG？「RAG 已死」你怎么看？
谁在问：一二面开场辨析题；头部 AI 公司尤其爱问，考判断力不考立场
口语化问法
- 现在模型都支持一百万 token 了，直接把文档全塞进去不就行了，还要 RAG 干嘛？
- 网上老有人说 RAG 要死了，你怎么看？
- 什么情况下你会选择不用 RAG，直接用长上下文？
考察意图
这是一道立场陷阱题。面试官不想听你站队，想看你能不能把技术判断拆成可量化的维度。一边倒地说「RAG 永远不会死」和「长上下文确实取代了 RAG」，扣分是一样的。第三问尤其关键——能说出「什么时候该用长上下文」的人，才证明他不是在背结论。
参考答案
60 分答案（及格线）
两者是互补不是替代。理由：① 成本——每次都灌百万 token，费用和延迟都远高于只送几千 token；② 规模——企业知识库常是 GB 到 TB 级，再大的窗口也装不下；③ 效果——上下文越长模型越容易失焦，不是塞得越多答得越准；④ 可控性——RAG 能做权限过滤、时效过滤和引用溯源，这些是企业场景的硬需求。
90 分答案（有生产经验的回答）
在四条理由基础上补三层深度：
- 把「效果」这条讲实：长输入不是线性变差，而是过了某个长度会「塌方」式下跌（context rot）。有实验对十余个主流模型做过测试，几乎每个模型输入变长准确率都会掉，部分模型在越过某阈值后从 95% 直接跌到 60% 附近。所以「全塞进去」在效果上也未必占优。
- 给出反向答案（关键加分）：长上下文确实有它的甜点区——单份文档的深度理解（一份 200 页合同逐条分析）、文档总量小于窗口且需要全局理解（不到 100 页的手册做归纳）、原型验证阶段（跳过整套检索基建，一天上线）。这些场景硬上 RAG 反而是过度工程。
- 给出正确的关系判断（收尾）：长上下文真正改变的不是「要不要 RAG」，而是 RAG 的参数——窗口变大后可以放宽 chunk 粒度、多送几个候选、少做激进的上下文压缩。它让 RAG 更好用了，而不是让它消失。
追问链
立场陷阱题：不验你站哪边，验你能不能把判断拆成可量化的维度
你说成本高，能具体到数量级吗？
期望要能粗算：RAG 每次送几千 token vs 全量送几十万到百万 token，差两到三个数量级，再乘日均请求量就是月成本差距；首字延迟也从数百毫秒变成数秒信号只会说「贵」、一算就算不出来 → 成本意识停留在口号什么是 context rot？为什么上下文变长模型反而变笨？
期望无关信息稀释注意力、关键信息被淹没（lost in the middle）、早期的错误信息污染后续推理；表现是非线性下跌而不是缓慢劣化信号能说出「不是线性变差，是到某个点塌方」→ 真读过材料而非想当然那什么场景你会直接用长上下文而不搭 RAG？
期望单文档深度分析、语料总量小于窗口、需要全文级别的全局理解、原型快速验证、一次性任务（不值得建索引）—— 这题答不出来说明只会背一边信号坚持说「任何场景都该用 RAG」→ 典型的教条式回答长上下文变便宜以后，你的 RAG 系统会怎么调整？
期望会变的：chunk 切更大、top-k 放宽、少做压缩和多路裁剪、父子分块的父块更大；不会变的：混合检索、rerank、权限过滤、引用溯源 —— 它们解决的不是「装不装得下」信号能划开「哪些环节被窗口约束、哪些不是」→ 很强的结构化信号如果我坚持认为 RAG 三年内会被淘汰，你怎么说服我？
期望不硬顶：先承认对方的合理内核（窗口和成本确实在改善，Naive RAG 的部分场景确实被吃掉了）→ 再落到三个不随窗口变化的约束：数据规模无限增长、权限与合规必须在检索层做、引用溯源需要明确的来源边界 → 姿态上同意一半、坚持一半信号被压一下就全盘倒戈，或激烈对抗完全不让步 → 两种都不理想
前两层还在比参数表，第 3 层才开始验真：能说出长上下文的甜点区，才证明结论是推出来的不是背来的；第 5 层看被压之后立场稳不稳 —— 倒戈和硬顶一样扣分。
评分要点
- 明确给出「互补而非替代」的结论
- 说出成本/延迟维度并能给量级
- 说出规模维度（知识库远大于任何窗口）
- 说出效果维度并知道 context rot / 非线性下跌
- 说出可控性维度（权限、时效、引用溯源）
- 加分且关键：能说出长上下文的适用场景（反向判断）
- 加分：能说出长上下文改变的是 RAG 参数而非存废
常见错误
一边倒地捍卫 RAG，答不出任何该用长上下文的场景——教条。
只答「贵」这一条，其余维度缺失。
把 context rot 说成「模型会慢慢变差」，没抓住非线性塌方这个要点。
通篇没有数量级概念，全是定性形容词。
被追问后立场反复横跳，说明结论是背来的不是推出来的。