RAG 正在变成 Context Layer：从向量检索到企业证据系统

核心判断：朴素 RAG 只解决“找出相关片段”的第一步。企业真正需要的是一层 Context Layer，能够按任务选择证据源、检索与重排、判断证据是否充分，并保留引用和权限边界。

01. 开场

这两年做大模型应用，RAG 几乎是绕不过去的词。很多人第一次听，会把它理解成一个很标准的流程：把文档切块，做向量化，放进向量库；用户提问的时候，找出最相关的几段，塞进提示词，再让大模型回答。这个理解没错——但如果你现在去看 OpenAI、Claude、Gemini，还有微软的 GraphRAG，会发现一件事：现在很多所谓的 RAG，已经越来越不像传统 RAG 了。

02. 它不再只是检索几段文档

它开始重写问题、拆分问题，把关键词和语义检索混在一起，再对结果重新排序，判断上下文够不够，调用数据库和接口，甚至由 Agent 自己决定要不要检索、查哪里、查几次。所以这期我们不做 RAG 入门。

03. 这期真正要讲的判断

我们来讲一个更重要的问题：RAG 到底在向什么方向演化？为什么它会变成企业 AI 的上下文基础设施？我先把结论放这儿——朴素 RAG 没有错，但它只解决了“把资料找出来”的第一步；真正难的，是把正确的事实、足够的证据、合适的工具结果，组织成模型能用的上下文。

04. 第一部分 · 朴素 RAG 只是第一步

先说清楚，朴素 RAG 并不是错的。它解决了大模型应用早期两个非常关键的问题。

05. 它解决了两个真问题

第一个，是模型不知道你的私有资料。企业内部制度、产品手册、设备说明、历史工单，这些模型训练时根本没见过。第二个，是模型容易幻觉。让它凭记忆回答，它可能说得很顺，但不一定对；而 RAG 至少给了它一些外部证据。

06. 早期 RAG 很自然，也确实有效

所以最早的 RAG 很自然：文档切块，向量化，检索，回答。对于常见问答、产品说明、制度查询、客服知识库，这套流程确实能快速起效。但只要你把它放进真实企业场景，它的问题就会非常明显。

07. 第二部分 · 朴素 RAG 为什么经常翻车

把它放到真实业务里，至少有四个地方会翻车。

08. 翻车一 · 相似，不等于正确

比如你问：故障码 E05 是什么？某个设备编号对应哪个项目？这些问题的关键，是编号、变量名、设备名、故障码、版本号。纯向量检索擅长找“意思相近”，但不一定擅长找“字面精确”，它会找来一堆看起来相关、却没真正回答你的资料。所以生产级方案很少只靠向量检索，更主流的是混合检索：语义加关键词，再加过滤和重排。

09. 翻车二 · 切出来的片段，丢了身份

第二个问题，片段被切出来之后，经常失去身份。比如一句“供水温度设为七度”，单看没问题，但它属于哪个项目？哪个设备？是设计值，还是某个案例的经验？上下文一丢，模型就可能把一个局部经验，当成普遍规则。这正是 Anthropic 提出 Contextual Retrieval 的原因：切块前先补一小段说明，让片段重新知道自己是谁、属于哪、在讲什么。

10. 翻车三 · 相关，不等于足够

第三个问题更关键：相关的上下文，不等于足够的上下文。Google 提出过一个很有价值的视角，叫充分上下文——一段材料可以和问题高度相关，却仍然不足以回答它。模型拿到一点相关材料，就会误以为证据已经够了，于是自信地补全答案。这正是很多 RAG 幻觉的来源。

11. 翻车四 · 企业的问题，不只在文档里

第四个问题，企业真实的知识，并不只在文档里。它还在数据库、设备台账、报警记录、时序数据、运行日志、工单和历史复盘里。你要是把所有东西都转成文档塞进向量库，系统最后一定又慢又乱。比如问“这个项目最近为什么能耗异常”，这就不是一条文档能回答的——它要查实时数据、查设备配置、查报警、查工单。这时候 RAG 就不再是文档问答，而是上下文构造。

12. 第二部分 · 主流方案正在分层

所以现在的生产级方案，正在分层。我们一层一层看。

13. 第一层 · 混合检索，企业的默认起点

第一层是 Hybrid RAG，混合检索：稠密向量，加关键词检索，再加元数据过滤和重排。它应该成为企业知识库的默认起点。因为企业知识里有大量精确词——项目名、型号、变量名、故障码。语义检索负责“像不像”，关键词负责“有没有这个词”，重排再负责“哪个结果真能回答”。

14. 第二层 · 给片段补回上下文

第二层是 Contextual RAG，专治片段丢上下文。切块之后不直接向量化，而是先给每个片段生成一小段上下文：它来自哪个文档、哪个章节、讲的是什么对象、适用什么范围。这一招特别适合标准规范、合同、项目报告、技术手册这类材料。

15. 第三层 · GraphRAG，别神化

第三层是 GraphRAG，很火，但别神化。它不是普通 RAG 的万能替代，而是专门解决两类问题：一类是跨文档的连接，答案要跨多个实体、多个关系才能拼出来；一类是全局理解，比如这个库整体有哪些主题、反复出现的风险是什么。它适合做案例网络、风险关系、故障原因图谱；但你只是查“某个参数是多少”，普通混合检索可能更直接。

16. 第四层 · Agentic RAG，动态组织证据

第四层是 Agentic RAG。传统 RAG 是固定流程，每次都先检索、再回答；Agentic RAG 是动态流程：Agent 先判断问题类型，再决定查什么、查几次、要不要重写问题、要不要调数据库、要不要补查、甚至要不要拒答。这就是它看起来不像 RAG 的原因——它已经从“检索增强生成”，变成了“围绕任务，动态组织证据”。

17. 第五层 · 文档不再是孤立知识

第五层，是 Document Agent 和业务工作流。很多文档场景不是问答，而是流程。比如合同审查：抽条款、对模板、查法规、识别风险、生成意见、再进人工确认。这不是“把相关文档塞给模型”能搞定的，它需要解析、抽取、检索、规则、状态管理和流程编排。这就是 LlamaIndex 说的方向：文档不再是孤立知识，而是业务流程的一部分。

18. 第三部分 · 长上下文会替代 RAG 吗

那绕不开一个问题：上下文窗口越来越长，会不会直接把 RAG 替代掉？

19. 长上下文，确实会吃掉一部分

现在很多模型支持很长的上下文，上百万 token；再配合提示缓存，直接塞大量资料变得更现实。所以在一些场景里，长上下文确实会吃掉一部分 RAG——一份合同、一份方案、一组不大的资料、一个代码包，直接放进去，可能比专门做 RAG 还简单。

20. 但它消灭不了企业级 RAG

但长上下文消灭不了企业级 RAG，原因有四个：第一，成本和延迟，每次塞一大堆，不一定划算；第二，权限和多租户，企业必须按用户、部门、客户、项目做过滤；第三，资料在持续变化，实时数据、日志、工单，不适合每次都塞全文；第四，长上下文不等于能稳定找出多个细节。所以更合理的判断是：小资料直接塞，中等资料检索加长上下文，大规模资料还得靠 Context Layer，而实时业务数据，应该走工具、接口、数据库查询。

21. 第四部分 · 终局不是向量库，是 Context Layer

所以回到这期的核心判断：RAG 没有过时，但朴素 RAG，正在变成底层零件。

22. 它要构造的，是一个上下文包

未来真正有价值的，是企业 AI 的 Context Layer。它要做的不是简单返回几段片段，而是根据问题，动态构造一个上下文包。这个包里可能有：文档片段、数据库查询结果、时序数据摘要、日志片段、规则判断、历史案例、引用来源、置信度，以及最关键的一条——“证据到底够不够回答”的判断。

23. 新旧架构，差在哪

旧的 RAG 架构是：用户提问，检索，回答。新的架构更像：用户提问，识别意图，选择证据源，查文档、查数据库、查日志、查时序、查规则，把结果重排，构造上下文，再判断够不够，才生成答案，最后还要引用和校验。这就不是一个向量库能解决的事情了。

24. 第五部分 · 企业到底该怎么落地

如果你现在要在企业里做 RAG，别被各种新词带偏，我的建议是分四步走。

25. 落地四步

第一步，先做一个可靠的混合检索：把解析、元数据、混合检索、重排、引用、检索测试做扎实，目标不是炫技，是稳定找对资料。第二步，接入业务数据，形成 Context Layer：项目表、设备表、报警、时序、工单这些，别都塞向量库，用数据库、接口、工具去访问。第三步，把复杂任务交给 Agentic RAG，比如运维诊断、节能分析、方案生成。第四步，建评测体系——没有评测，RAG 优化基本靠玄学。

26. 结论 · RAG 真正的价值是证据系统

所以最后的结论很简单：RAG 没有消失，消失的是“RAG 等于向量库问答”这个简单想象。过去我们说 RAG，是检索增强生成；现在更准确的说法，可能是上下文增强推理。模型越来越强，长上下文越来越长，但企业 AI 的核心问题一直没变：模型，能不能拿到可信、足够、可追溯的上下文。谁解决了这个问题，谁就不只是做了一个知识库，而是在搭企业 AI 的基础设施。

27. 延伸判断

参考资料与延伸阅读

不同产品对 Hybrid、Agentic 与 Context Layer 的定义并不完全一致，文中把它们作为架构模式而非统一标准。资料核验日期：2026-08-23。

#RAG #Context Layer #知识库 #企业AI