你在公司里用AI查过业务数据吗？有没有拿到过一个听起来合理、但业务同事摇头说「不对」的答案？

举个真实场景。一家企业数据库里有两个字段：cust_lt_val 和 ltv_b2b_adj。前者，模型猜对了——Customer Lifetime Value，客户终身价值，通用概念，没有歧义。

后者，模型猜成了「B2B调整后终身价值」。听起来合理，但错了。这家公司的规定是：B2B客户只能签销售合同，B2C客户只能下订单，两类客户的生命周期计算逻辑完全不同，ltv_b2b_adj 是公司内部专有定义，跟任何行业通用概念都不是一回事。

这条规则不在任何一张表里。它活在业务人员的脑子里，从来没有被写下来过。

AI猜错了，我们叫它「幻觉」。但准确的说法是：模型用通用知识，填补了一个企业专有的空白。换一个更强的模型，它还是会猜——只是猜得更自信。这不是模型能力问题，是语义缺失问题。

数据给了AI，AI读懂的只是技术层

很多团队推AI的第一件事，是把数据库接进来。数据仓库的元数据很完整——字段类型、主键约束、表间关联，技术上无懈可击。

但这些描述的是系统结构，不是业务含义。「B2B客户表」不会告诉AI：两类客户合同规则的差异，什么情况下C端客户会升为B端，哪些指标只对B2B有意义。这些判断标准，是企业多年运营沉淀的隐性知识——不在任何一张表里，也不会自动出现在数据字典里。

在我看来，这是两个不同的层：数据平面放的是技术对象，知识平面放的是语义理解。大多数企业只建了前者，后者从来没有存在过。

Context System 到底管什么

Context System 管理的，不是数据本身，而是数据背后的业务含义：这个术语在公司里是什么意思、两个概念之间有什么关系、某条规则在哪些场景下适用、跨部门的定义在哪里有分歧。这些东西，不在任何一张数据库表里，也不会自动出现在技术文档里。

回到前面的例子。数据库里有 ltv_b2b_adj 这个字段，技术层面没有歧义。但业务含义需要额外一层来记录：这是 B2B 客户专有指标，计算逻辑依赖合同类型，不适用于 B2C 场景，和行业通用的 LTV 定义不是一回事。Context System 做的，就是把这些「活在业务人员脑子里」的判断，转化成 AI 可以读取和使用的结构化知识。

信息科学里有一个叫 Ontology（本体论）的方法论，专门研究怎么把业务概念和它们之间的关系显式定义出来——Context System 做的事和它高度一致。区别在于：Ontology 是一套研究方法，特赞建立的 Context System 是一套持续运行的基础设施。

GEA 如何让这件事持续运行

知识平面最难的不是「要不要建」，是「怎么保持它最新」。业务在变：新产品上线、定义被修改、部门间出现口径分歧。靠人工维护，成本高、速度慢，容易落后半个季度以上——等维护完，业务逻辑又变了。

GEA 的 Context System 解决的是这个持续维护问题。它不依赖一次性的知识工程项目，而是持续从查询日志、文档、业务系统的使用行为中挖掘信号——识别哪些术语被不同部门用了不同口径，哪些字段的使用方式与定义出现偏差，并把这些更新同步进知识层。知识平面不再是一个项目，而是一套一直在运行的基础设施。

结果是：同样让 AI 处理 ltv_b2b_adj，它拿到的不只是字段名，还有「B2B 专有指标、依赖合同类型、与 B2C 不可混用」。执行任务之前，AI 就已经知道这家公司的规则。这就是「Contextual NOT General」——不是把通用模型接进业务，而是让 AI 真正学会这家公司的语言。

你的这层，建到哪一步了

三个快速自测：

一，你们最核心的业务指标，有没有跨部门统一的书面定义？

二，不同部门的人让 AI 查同一个问题，会不会拿到不同答案？

三，现有的 AI 工作流，有没有因为「上下文不够」给出过错误结论？

有两个「不确定」，这层就还没建好。

多数企业的 AI 项目卡在「能用但不准」——不是模型差，是没有建数据到业务知识的那一层。Context System 做的，就是把这层从「业务人员脑子里的判断」变成「AI 可以持续读取的基础设施」。这一层建了，AI 才真正能在你的公司里工作。

你的企业上下文系统走到哪一步了？

扫码下载《Context Moats 2026》白皮书

欢迎与我们预约一次深度诊断