每一步都合理，但结果是错的——企业AI落地的真实困境

我见过一次很典型的失败。一个团队做了一个采购助手让采购员用自然语言提交补货需求。背后接了公司的库存系统用Function Calling让模型决定调哪个接口。测试阶段跑了几十个case结果看起来都对上线了。上线三天之后仓库那边发现有一批货的补货数量不对系统建议补200件实际应该补20件。去查原因发现模型调用库存查询接口的时候把库存上限列当成了库存列。这两个字段放在同一张物品表里名字里都有库存返回的JSON里挨着模型自己推断了一个错误的对应关系。最后那批货多备了180件压了将近两个月才消化掉。这个错误有意思的地方不在于模型推断错了而在于它推断的方式在逻辑上完全说得通——库存上限确实和库存有关确实在库存表里确实是一个数字字段。如果你不知道这个系统的业务含义你也很可能这么理解。为什么每一步都合理但结果是错的好消息是这个失败案例并不是随机出错而是一种系统性的偏差。大语言模型的推理方式本质上是在做最合理的猜测。训练数据给了它大量的语言规律让它知道什么词经常和什么词一起出现什么样的上下文通常对应什么样的答案。这在自然语言处理上表现出色因为自然语言里的规律和通用知识高度重叠。但企业系统不是自然语言是私有的业务约定。库存上限在A公司的系统里是仓库容量上限在B公司的系统里可能是触发补货的阈值在C公司甚至可能是历史最高库存的记录值。这些差异写在哪里写在内部Wiki、需求文档、老员工的脑子里不在任何公开训练数据里。模型只能用它觉得最合理的解释而这个解释在特定业务场景下可能是错的。这是第一类错误字段语义的私有性。字段名给了模型一个方向但没有给它足够的约束。第二类错误更隐蔽。同一个目标可能有多个接口能部分实现但只有一个是业务上正确的路径。比如查询客户的历史订单系统里可能同时存在/ServerCommand/GetOrders?customer_idxxx和/ServerCommand/GetCustomerOrders?orders_idxxx两个接口前者用在售后服务/客户订单查询页面是给客服用的能看到所有订单包括退款记录后者用在销售管理/工作台和销售管理/订单查询页面是给销售用的只显示有效订单。模型看到两个接口都能返回客户的订单没有额外信息的情况下它随机选一个或者选名字看起来更通用的那个。结果是调用路径对了数据错了而且错误不会触发任何异常。也就是说接口正常返回数据格式正确只是业务口径不对。第三类错误发生在多步调用的时候。AI在执行复杂任务时需要把多个接口的结果组合起来。比如先查库存再查销售记录再生成补货方案。每一步的错误都会传递给下一步而且可能被放大。查库存用了错误的字段算出来的当前库存偏高传给下一步之后补货数量就系统性偏低最后生成的方案在数字上看起来合理但整体方向是错的。这三类错误有一个共同的根源模型不知道你的系统是什么只能靠猜。这导致了模型没有一个结构化的、关于这个系统是什么的认知。不是文档不是示例是结构化的认知——这个系统里有哪些概念这些概念之间是什么关系每个概念可以做哪些操作这些操作的规则和约束是什么。人类新员工入职的时候有一个非正式的学习过程就是在完成这种认知的建立。他不是把API文档背下来而是在工作中逐渐理解哦我们说的客户在系统里对应两张表一张是基本信息一张是交易记录销售用的那个查询接口只返回有效合同你如果想看退款得去另一个地方查。这种认知是结构化的、关系化的不是文本片段的堆积。这个认知有一个名字叫本体Ontology。本体这个词听起来有点哲学实际上在信息科学里的含义很具体对一个特定领域中的概念以及概念之间关系的形式化描述。你的业务系统里有哪些名词实体这些名词有哪些属性可以对它们做哪些动作它们之间是什么关系——把这些东西结构化地描述出来就是这个系统的本体。这不是一个新概念。OWLWeb Ontology Language从2004年就是W3C标准帕兰蒂尔Palantir在它的AIP平台里把本体作为核心概念来组织企业数据已经跑了很多年。只是在大语言模型之前本体主要是给人看的是知识管理和语义检索的工具。现在它多了一个用途给AI看作为AI理解和操作企业系统的认知基础。为了让AI能够弄明白你的业务系统一个完整的业务系统本体除了需要描述实体如物品表和属性如库存、库存上限还需要描述实体之间的关系库存记录属于哪个仓库关联哪个SKU接口的业务语义这个接口适合给谁用返回的是什么口径的数据操作的前置条件和约束等等。怎么把这些东西系统性地建立起来以及建立之后AI怎么用它是接下来几篇要讲的内容。番外RAG能解决这个问题吗很多人在看完全文后会有一个问题把API文档喂给模型让它去查就像RAG那样不行吗实际上这个思路对了一半。RAG检索增强生成的工作方式是把文档切成片段存进向量库用户提问的时候检索相关片段塞进上下文让模型参考。它在知识问答类场景里表现不错因为用户的问题和文档里的答案在语义上通常是对应的——你问差旅报销标准系统能找到写着报销标准的那一段。但调用哪个接口、传哪些参数、怎么理解返回值不是这种结构。原因在于切片。RAG的基本假设是完成这个查询所需的信息尽量在一个或少数几个相邻的切片里。但一个业务操作的完整知识是分散的接口定义在API文档里字段含义在数据字典里业务规则在需求文档里接口之间的依赖关系可能只在老员工脑子里。把这些内容切片之后检索时很难保证把相关的几块都拿回来拿回来的顺序也未必正确。2023年Langchain发布过一份内部评估报告后来收录在他们的文档里测试了RAG在代码库问答上的表现。当问题需要跨越多个文件、多个函数的关联理解时准确率从单文件场景的约75%下降到不足40%。企业系统里的接口调用问题在结构上非常接近这种跨文件关联理解的场景结果大概率也会不及预期。