RAG 还是长上下文？企业知识库的技术选型

「上下文窗口都百万 token 了，RAG 是不是该淘汰了？」——这可能是今年企业知识库选型中被问得最多的问题。答案比想象中复杂。

支持长上下文一方的理由很直接：把全部资料塞进窗口，模型自己「阅读理解」，省去切块、索引、检索的整条工程链路，召回逻辑也从「猜测相关」变成「全文可见」。

但成本与性能的现实很快泼来冷水：长上下文的推理成本随 token 数线性甚至超线性增长，且存在「中间遗忘」——位于上下文中部的关键信息容易被忽略。对企业级百万文档的库，全量塞入既不经济也不可靠。

检索决定「看什么」，长上下文决定「怎么看」。

实践中的共识是混合架构：用检索缩小范围（成本可控、可溯源），用长上下文保证深度（召回段落的完整语境）。检索决定「看什么」，长上下文决定「怎么看」。

选型的真正问题不是二选一，而是你的场景更在意哪一端：高频问答场景优化检索精度，复杂分析场景放宽上下文预算，而合规要求严格的行业，可溯源的 RAG 链路依然不可替代。