知识工程不是把文档丢给AI

企业里的AI应用，听到最多的一句感叹是，工具挺好，模型也挺聪明，但在实际工作中帮不上忙。

说这话的人，通常已经认真试过了。他们把业务文档发给AI，问了几个问题，AI的回答要么是错的，要么看起来有模有样但实际经不起推敲，要么干脆牛头不对马嘴。于是丢过来一句反馈：幻觉太严重，这东西还不行。

但问题通常不在模型。

我做产品经理这些年，中途接手系统时，最头疼的不是系统复杂度，而是搞清楚系统现状。PRD散落在十几份word文档里，还有几十条需求变更记录在wiki评论、jira、群聊和邮件中。技术文档缺失那是常事儿，能在上线后补齐都算是尽职尽责的了，有时甚至只有两年前初代版本的一份概要设计。想知道某个费用到底是怎么计算出来的，问了一圈儿没一个人说得准，最后只能扒代码。此时唯有凝神聚气，长叹一声天将降大任于斯人也，然后花几周时间，请教十几个人，整理出一份系统功能全景图。

一个活人，带着对行业的理解和若干项目经验，花几周才能拼出来的图景，你指望AI读一遍文档就能答对？

这不是幻觉问题，这是上下文问题。

一个交易系统的"订单"，在业务需求里叫"客户指令"，在技术方案里叫"order"，在数据库里叫"t_trade_order"，在测试用例里叫"委托单"。它们说的是同一个东西，但AI读完之后会以为这是四个不同的东西。你问它"这个订单为什么被拒绝"，它在四个版本的文档里找到四段互不关联的描述，拼在一起，给你一个自相矛盾的答案。

这些知识从来没有被当作"知识"来管理过，它们只是被当作"文档"存着。这些文档在被写出来的那一刻，就跟其他文档断了联系。没有人标记过它们之间的依赖关系，没有人维护过它们的一致性，没有人定义过它们描述的是不是同一个东西。

这就是知识工程要做的事。

知识工程拆开来看，至少包含三件事。知识的建模，也就是本体论平台，给所有业务实体定义一套统一的语义模型。知识的抽取和存储，把散落在文档、代码、数据库里的信息结构化地整合起来，形成适合AI读取的知识谱系。知识的管理和维护，版本怎么管，失效的怎么标记，权限怎么控制。

最基础也最容易被忽略的是第一件。给客户、产品、订单、合约、账户、风控规则这些业务实体，定义一套统一的语义模型。这个东西叫什么，它有哪些属性，它在不同系统、不同文档里分别以什么形式出现，它和其他实体的关系是什么。这件事做完以后，AI才能理解"BRD里的客户指令"和"数据库里的t_trade_order"是同一个东西。

还有文档的生命周期。一篇PRD从草稿到评审到发布到废弃，中间可能被改过很多次。AI读到的版本，是当前版本还是三年前的版本？它引用的技术方案，有没有被后来的变更覆盖？这些信息如果不在知识工程里管理，AI给你的答案就永远带着一份你不知道的风险。

知识工程很枯燥，没绩效亮点，不出风头，但它决定了AI在企业里能做的事情有多深、有多实。

没有它，AI只能在聊天框里回答“FICC的场外衍生品系统一般都包含哪些模块”。

有了它，AI才能上手分析“场外衍生品业务要新增支持XX品种，需要新增哪些功能，接入什么数据，涉及哪些周边系统，既有页面和接口要做哪些改造”。

下次再觉得AI帮不上忙，先别急着叹气。看看你给它的上下文，够不够支撑它干活儿。