Context System、RAG 与知识图谱：企业记忆的三种建法

很多企业在问"我们用 RAG 还是知识图谱"时，其实在问一个更底层的问题：AI 怎么记住关于我们企业的事？

这三种技术都在处理"让 AI 使用企业知识"这件事，但它们的假设、能力边界和适用场景完全不同。

RAG 的假设：文档里有答案

RAG（Retrieval-Augmented Generation）的逻辑是：把你的企业文档向量化，当 AI 需要回答问题时，先检索最相关的片段，再生成回答。

它解决的问题是：大模型不知道你公司内部的事，但你有文档，可以临时喂给它。

这个逻辑在文档检索问答场景很好用——"我们公司的差旅报销标准是什么""这个合同的条款在哪里"。但它有一个根本假设：答案存在于某个文档的某个片段里。

一旦超出这个假设，RAG 就力不从心。"这个客户现在的决策倾向是什么"——这不在任何文档里，它在历史对话、报价记录、服务工单、以及 AI 从这些信号里推断出来的模型里。"我们上次做类似项目时踩了什么坑"——这需要跨多个项目文档的结构化推理，不是片段检索能给出的。

知识图谱的假设：关系是可以预先定义的

知识图谱试图解决 RAG 的关系推理弱点：把实体和实体之间的关系显式建模，让 AI 能沿着关系走。

它在某些场景很强：医疗知识库里的药物-疾病-症状关系、制造业里的零件-工艺-检测关系。这些关系相对稳定，可以人工定义，定义完之后查询精度很高。

但企业业务的大多数关系不是稳定的——客户关系在变，产品迭代在变，团队结构在变。知识图谱需要持续维护，维护成本随复杂度指数上升。而且它描述的是"什么和什么有关系"，不是"在这个具体业务上下文里，这些关系意味着什么判断"。

Context System 的假设：企业知识是动态的、多层的、与执行不可分的

特赞的 Context System 处理的是一个不同的问题：不是"如何检索企业文档"，而是"如何让 AI Agent 在执行任务时始终基于企业的真实状态"。

它包含几个层面：

静态上下文：品牌基因、产品定义、市场定位——这些相对稳定，类似于"公司的宪法"。

动态上下文：客户状态、项目进度、竞品动态、市场信号——这些持续更新，是每次执行的工作底座。

推理上下文：AI Persona（基于真实数据构建的用户/客户模型）、历史决策模式、能力边界——这些不在任何单一文档里，是从大量信号中提炼出来的推理层。

Context System 的核心设计不是"存储和检索"，而是"作为 Agent 执行的 single source of truth"。当一个 Proactive Agent 在执行任务时，它不是去检索文档，而是在 Context System 的语境下推理：这个品牌的这个客户在这个时间点，应该做什么。

三者的适用边界

企业真正的问题不是选哪种技术，而是搞清楚 AI 在你的业务里扮演什么角色。

如果 AI 是一个高级搜索引擎，RAG 够用。如果 AI 是一个需要理解复杂关系的查询工具，知识图谱有价值。如果 AI 是一个需要持续运行、主动执行、基于企业真实状态做判断的 Agent，那需要的是 Context System——不是存储，而是 Agent 的认知底座。