企业知识库下半场：从RAG到Context Architecture

过去两年，多数团队构建企业知识库的路径惊人的一致：接入文档、切片分块、向量嵌入、挂载数据库、开放对话接口。演示阶段效果往往令人满意，但一旦进入实际业务场景，问题便接踵而至——系统引用的是过期制度、无法识别用户权限、不了解项目当前进展、更无法触发后续业务动作。此时我们意识到：RAG技术并非失效，而是已经不够用了。企业知识库的下半场，关键词已从RAG转向Context Architecture（上下文架构）。

RAG的贡献与局限

当前行业信号愈发清晰。一方面，AI Agent开始真正接入工单、审批、企业系统等业务环节；另一方面，越来越多的团队发现，仅靠“把文档搜出来”根本无法支撑这些Agent稳定运行。企业面临的真实问题远比“哪份文档最相关”复杂得多：用户是否有权查看该内容？该文档是否为最新版本？当前处于哪个项目、哪条流程节点？回答应该触发哪个系统动作而非仅生成一段文字？RAG解决的是“让模型看到更相关的文本”，但企业真正需要的是让模型进入一个有边界、有状态、有身份、有流程的上下文环境中工作。

什么是Context Architecture

必须明确的是，RAG并未过时，它仍是企业知识系统的基础层。RAG至少解决了三个关键问题：让模型不再仅依赖预训练记忆、让回答可以引用企业私有知识、让通用问答场景能够快速落地。对于文档问答、制度检索、FAQ助手、产品说明查询等场景，RAG依然极具价值。然而，当企业从“问答Demo”进入“真实工作流”时，系统要求发生了根本转变。用户不再问“这份制度怎么写”，而是问“结合我当前负责的客户、正在走的流程、我所在的部门权限，下一步我应该怎么做”。此时，相关文本只是答案的一部分，真正决定系统可用性的，是上下文。

五层上下文的架构设计

Context Architecture的核心思想可以概括为：不是只给模型一堆资料，而是给它一个“能正确做事的工作现场”。这个工作现场包含五层上下文。第一层是知识上下文，即传统RAG最擅长的文档、制度、会议纪要、FAQ等，回答“有哪些内容与当前问题相关”。第二层是身份与权限上下文，同一问题不同岗位、不同部门能看到的答案范围本就不同，系统必须知道“这个人此刻有权看到什么”。第三层是时效与状态上下文，知识往往与时间、版本、流程状态强相关，系统需要回答“现在有效的到底是哪个版本、哪个状态”。

第四层是任务与流程上下文。企业知识库的真正痛点不是“找不到答案”，而是“找到了也做不下去”——销售想推进客户跟进、运营想把审批卡点推进掉、工程团队想结合当前事故状态做处置。系统需要知道当前任务是什么、上一步做了什么、下一步允许做什么、可以调用哪个系统动作。第五层是责任与审计上下文，企业引入AI后必然面临“这句话依据哪来的”、“这一步是谁触发的”这类问题，系统必须能追溯来源、权限、动作和版本，形成完整的审计链条。

如有侵权，请联系删除。