Long Context vs RAG¶

长上下文和 RAG 解决的不是同一个问题。长上下文扩大一次推理能看到的材料，RAG 决定哪些材料应该被看见。窗口变大以后，检索、过滤和证据治理不会自动消失。

什么时候用长上下文¶

材料数量有限、来源可信、任务需要跨全文综合时，长上下文更直接。比如分析一份合同、总结一份报告、检查一个小型代码包，硬切成很多 chunk 反而可能破坏全局结构。此时重点是上下文顺序、稳定指令、章节边界和输出结构。

长上下文的风险是有效信息被噪声稀释。窗口里“放得下”不等于模型“遵循得住”。系统约束、当前目标、关键字段和证据片段要分层组织，不能把历史、资料、规则和工具结果混成一锅文本。

资料规模大、更新频繁、权限复杂、版本敏感时，优先做 RAG。企业知识库、制度问答、工单排查、产品文档助手都属于这一类。系统要先在当前用户有权看到的材料里找证据，再把证据交给模型。

RAG 的价值不是省 token，而是建立证据边界。它能把租户、部门、版本、生效状态、文档类型这些条件提前放进查询计划。没有这层，长上下文只是在更大的窗口里混入更多旧资料和越权资料。

第一版不要迷信“长上下文替代 RAG”。如果资料来自固定少量文件，先用长上下文；如果资料来自持续增长的知识库，先做 RAG；如果任务既要全局理解又要查证，先用 RAG 找证据，再把少量关键材料放进较长上下文。

可以这样答：Long Context 扩大模型可见范围，RAG 控制证据进入范围。材料少、稳定、可信、需要全文综合时，我会优先用长上下文；材料多、更新频繁、权限复杂、需要引用时，我会优先 RAG。线上系统最常见的是组合用法：先用检索和过滤建立证据边界，再用足够长的上下文完成综合和生成。