长上下文模型出来以后，RAG 还有必要吗？
面试怎么回答
长上下文和 RAG 不是替代关系，要看数据规模、成本、权限和时效。小规模、相对稳定的文档，比如一份合同或一个项目的代码，直接放进长上下文加提示词缓存，效果好、实现简单。但企业知识库动辄几百万份文档，装不下；每次带几十万 Token 成本和延迟太高；上下文越长越容易忽略中间信息；而且不同用户权限不同、文档每天更新，检索可以按权限和版本过滤。所以我的做法通常是结合：检索召回更大的粒度，比如整篇文档或章节，再用长上下文综合理解。最终用同一套评测集比较准确率、成本和延迟来决定。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
现在不少模型的上下文窗口已经到了几十万甚至上百万 Token，于是有人说：「直接把文档全塞进去就行，还做什么 RAG？」面试官问这题，看的是你能不能从成本、延迟、准确性和数据规模几个角度做取舍，而不是站队。
长上下文的优势
- 不用切分文档，不会因为切块切断上下文；
- 跨章节、跨文档的综合理解更好；
- 链路简单，不需要维护向量库和检索服务。
长上下文解决不了的问题
- 数据规模：企业知识库是几十万、几百万份文档，再大的窗口也装不下；
- 成本：每次请求都带上几十万 Token，费用和延迟都会成倍上升，即使有缓存，首次和变化部分仍要付费；
- 注意力稀释：上下文越长，模型越可能忽略中间的信息，关键事实淹没在大量无关内容里；
- 权限：不同用户能看的文档不同，RAG 可以在检索时按权限过滤，全量塞进去就很难控制；
- 时效：文档每天更新，检索可以只读最新版本。
实际怎么选
- 小规模、相对稳定的文档集（一份合同、一本产品手册、一个项目的代码）：直接放进长上下文，配合提示词缓存，往往效果更好、实现更简单；
- 大规模知识库、多租户、权限复杂：仍然需要检索，先找出相关的部分；
- 两者结合：检索时召回更大的粒度（整篇文档或整个章节），而不是很小的片段，再用长上下文让模型综合理解。
对数据团队意味着什么
RAG 不会消失，但重点会从「切得多细、向量多准」转向：
- 文档的元数据、版本、权限是否准确；
- 检索召回的是不是最新、正确、有权限的文档；
- 用评测集比较「长上下文」「RAG」「两者结合」三种方案的准确率、成本和延迟。