直接回答：两者不是替代关系而是互补。长上下文适合"语料固定且能塞进窗口"的场景：整本书问答、代码库分析、多文档对比，模型能看到全局、做跨文档推理，这是 RAG 切块后丢失的能力。RAG 适合"语料海量、持续更新、权限复杂"的场景：企业知识库动辄千万文档远超窗口，且要按用户权限过滤、按天增量更新。成本也是硬约束：百万 token 每次请求都付全量费用，RAG 每次只付检索出的几千 token。

展开解析：长上下文的实际短板：延迟和成本随长度线性到平方增长；"大海捞针"测试满分不代表真实长文推理可靠，中段信息利用率仍有衰减；KV cache 占用限制了长上下文请求的并发。RAG 的短板：切块破坏全局结构，多跳推理和"统计全部文档中 X 的次数"这类全局问题答不了。工程上的融合趋势明显：RAG 检索出的结果直接灌进长上下文窗口（top-k 可以放大到上百块）；prefix caching 让固定的长文档只算一次；Agentic RAG 让模型自己决定何时检索、检索什么。选型决策树：文档总量小于窗口且更新少→直接长上下文；否则 RAG，复杂任务再叠 Agent。

追问方向：prefix caching 如何降低长上下文成本？GraphRAG 解决什么问题？上下文位置偏置（lost in the middle）怎么缓解？

（约 470 字）