悦点科技任鑫琦：语义层的下一站是业务本体——让 AI 从读懂数据，走向执行业务

2026年10月23日,在 DACon 2026 北京站“企业语义层建设”分论坛上,悦点科技创始人兼 CEO 任鑫琦以《语义层的下一站是业务本体:十二年、近百家企业语义建设的得与失》为题,结合长期企业知识工程实践,讨论了业务本体与大模型结合的价值,以及企业应如何推进建设。

企业积累了大量数据,也建设了知识库与分析系统,为什么一旦遇到跨部门、跨流程的复杂问题,仍需要人员逐个系统查找信息、拼接关系、组织判断?此次分享围绕这些问题展开:企业如何把自身的业务知识交付给 AI,使其既能理解问题,也能依据业务条件推进任务。

从适用场景、技术路径到体系建设与案例,分享逐步展开了一个判断:大模型正在改变知识的构建和使用方式,本体则需要进一步组织企业的业务对象、规则与执行逻辑。两者的结合,应在具体业务闭环中检验价值,再逐步形成能够复用的企业能力。

大模型改变了知识的构建与使用方式

任鑫琦从自己的工作经历谈起:在百度接触 Knowledge Graph,在明略数据探索大数据与知识图谱的结合,再到创办悦点科技,将业务对象化、资源化的思路与 AI 结合。这些经历背后,是企业知识工程长期面对的两项困难。

一项困难在使用端。知识图谱即使建设得较为完整,能否从中找到有价值的关系、形成有效判断,仍高度依赖使用者的经验。另一项困难在构建端,将非结构化材料转化为结构化知识,效果和持续维护能力都存在限制。大模型为这两端提供了新的工具:它可以参与知识提取与组织,也可以通过自然语言理解和任务执行,让更多业务人员使用已经积累的知识。

因此,本体在这一轮 AI 应用中重新受到关注,有其实际业务背景。理解本体,需要区分技术实现与建设目标:专家系统、知识图谱、大数据和大模型的技术不断演进,把业务领域中的要素表达清楚、形成共享的语言与符号体系,则是持续存在的目标。

企业需要明确讨论的对象、对象之间的关系,以及某项判断成立的条件。只有这些业务含义得到组织,模型才有依据理解一条记录对应什么业务事实、某个变化可能影响哪些对象,以及后续操作需要满足什么条件。语义建设由此从解释数据,进一步走向对业务运行方式的表达。

跨系统的业务判断需要还原共同的业务事实

本体适用于哪些问题,不能脱离场景讨论。以制造业质量追溯为例,一件产品从物料、生产、设备与工艺,到质量检验、供应和交付,会经过多个部门与系统。出现异常时,问题可能来自其中不同环节,调查必须跨越这些边界。

困难在于,同一个批次、同一台设备或同一项产品,在不同系统中的描述、编码和数据结构并不一致。局部系统可以完整记录各自的业务,但要回答“这批产品为什么异常、会影响谁”,还需要把记录连接到共同对象及其上下游关系上。

数仓能否完成这些分析,涉及的是建设与维护的复杂度:企业需要以怎样的投入,支撑跨系统关系分析及后续处置。领域本体的价值,在于把分散记录组织到共同的业务语义中,使证据、影响范围和责任关系能够被连续追查。

这一需求也存在于客户之声分析中。客服热线、网络舆情、车机反馈和员工工单分别形成记录,但企业真正想知道的,往往是哪些反馈共同指向某类产品、质量或服务问题,以及问题集中在哪些车型、版本和功能。单条客诉处理完成,并不等于企业已经理解这些反馈背后的业务原因。

这两类问题具有共同特征:问题跨越既有数据系统与业务系统,却反映着企业核心业务的一套逻辑。此时,需要被组织起来的不仅是信息,还有人员在分析中使用的对象定义、关联依据和判断条件。对于单域查询、固定流程等较轻需求,则应继续根据实际复杂度选择合适方案。

从分析走向执行需要把业务状态与动作连起来

明确业务表达之后,还要回答这些知识如何进入 AI 的工作过程。分享以 Snowflake、Google Cloud 和 Palantir 等技术路径为参照,讨论从分析决策到业务执行的不同覆盖范围。

围绕数仓的语义能力,主要帮助形成一致的分析结果和决策依据;云平台中的查询语义、知识与上下文能力,则进一步连接不同类型的信息。以业务对象为核心的本体路径,还要把实体状态、逻辑和动作纳入同一套模型,使决策能够继续进入执行环节。

让决策进入业务,还需要明确执行过程中的具体问题:AI 读取了哪些业务状态,提出了什么操作请求,执行前如何检查权限和条件,业务系统完成操作后又如何反馈结果。状态更新能够被下一轮任务使用,分析、决策与执行才形成可持续运行的闭环。与此同时,覆盖的业务范围扩大,也会增加接口集成、流程编排和运行保障的投入。

这也解释了分享为何讨论 W3C、RDF 与 OWL 等标准的价值。形式化表达有助于建立明确的概念和规则,但业务能否准确映射到模型,依然是需要解决的问题。不能仅以推理系统是否确定,替代对业务表达是否完整、适用条件是否准确的检查。

已有标准的积累也具有实际价值。行业中的公共概念和参考模型,可以帮助企业减少从原始数据直接推导完整业务本体的工作。标准表达、跨工具交换与平台执行各有职责,企业需要分别评估,结合业务需要选择和衔接。

体系建设可以分层 推进应从具体任务向下贯通

业务知识如何在企业内部组织,是从技术路径转向落地的关键。相关知识不仅存在于数据库,还分散在人员经验、操作文档和系统资料中。企业需要贴近业务部门获取这些信息,再将其与既有数据资源连接。

在体系上,数据连接与知识层提供业务数据、材料和可追溯证据,领域本体统一跨场景的核心概念,场景本体补充具体任务中的细节、约束与逻辑,应用层再面向排程、质量、设备或供应链等工作提供服务。各部门可以保留自身特点,但企业级本体应能沿着真实业务关系相互连接。

架构分层并不意味着项目必须从最底层依次建设。实际推进应先找到一个业务小切口,向下明确它依赖哪些知识、规则和数据,把这条链路贯通,尽快完成应用验证,再按照各层的依赖关系扩展复用。这样,建设范围始终与一个能够验收的任务相联系。

公共参考与行业模型也应在这一过程中发挥作用。企业可以复用已有的概念框架和领域共识,再通过映射、裁剪和补充,把自身的业务差异落实到模型中。共享的对象定义与具体任务规则需要分别管理,避免每个场景都重复建模,也避免脱离实际任务追求过大的公共模型。

本体的效果要在业务工作方式的变化中验证

质量追溯实践进一步说明了这一点:当一批产品出现客诉,客户、生产、供应与研发岗位需要分别进入 CRM、MES、ERP、PLM 等系统,查询交付、工单、物料、采购和设计信息,再汇总这些记录。重复的跨系统查找与跨岗位协同,占用了大量工作时间。

按照分享材料中的案例口径,原先需要约4人天投入的跨系统追溯查询,在本体辅助下可由一人发起,约5分钟完成。这里比较的是追溯查询的耗时,不代表完整根因验证或整改周期。

这一变化背后,是查询过程被重新组织:批次、客户、物料和供应商等对象形成可关联的业务模型,客诉定位、生产追溯、供应链追溯与设计回溯分别由 Agent 或工作流推进。人员不必再逐个系统手动拼接信息,业务关系、查询步骤和执行逻辑也有了复用基础。

连接多个系统的建设成本,需要结合企业已有的数据治理基础判断。在数据平台和数仓基础较好的条件下,进一步表达业务语义并完成映射,可以复用此前的投入。业务本体需要补足的是跨系统理解与任务组织能力,而建设范围仍由具体场景决定。

悦点 Knora 的产品实践围绕这种连接展开:将已有资源组织为可使用的业务语义,再结合逻辑、行为与应用服务支撑任务。本体和业务可视化帮助人员查看对象与关联,实际价值则要由查询和执行结果来检验。

演讲还谈到了经销商索赔这一较小的业务切口。面对配件问题,人员需要核对订单、包装、收货情况及产品信息,并分析物流、使用或产品等不同原因。本体在连接材料与流程的同时,可以结合多模态模型的多轮交互校正分析过程,减少人工反复确认信息的工作。不同场景规模虽有差异,都需要围绕实际任务组织对象、知识和执行资源。

本体与 Agent 要在运行反馈中持续完善

如果知识在建成后仍然主要依赖人员逐项维护,就难以持续适应业务变化。这一问题也回应了开场讨论的构建和维护困难:本体需要与 RSI 自我改进机制结合,使知识能够在使用中持续完善。

本体在其中承担两方面职责。一方面,它提供共享的业务规范与判断依据,使 Agent 的运行和反馈有共同语义;另一方面,企业在执行中发现的新知识、语义偏差和能力缺口,也需要进入模型的持续完善过程。知识的使用与更新因此应当连接起来。

持续改进需要可检查的过程:记录任务轨迹与结果,诊断问题,形成候选变更,再通过独立评测验证收益和约束。候选变化通过后才进入小范围发布,并保留差异记录与回滚能力。业务反馈可以推动改进,未经检验的变化则不能直接进入生产流程。

对于建设方式,任鑫琦在口头分享中特别补充,仅用“大模型辅助”不足以概括这种变化。AI 应承担更多知识构建与处理工作,专家则提供基础的做事方法,推动知识在使用中持续更新。与之相应,本体也需要从主要供人阅读的关系表达,进一步扩展为供 AI 调用的业务逻辑与执行条件。

小切口做闭环 让收益与复用都有实际依据

本体建设的目标更接近业务执行,并不意味着每个企业都需要同样的系统。企业级本体、小部门模型和单一 AI 场景,在建设深度、运行要求和投入上有不同取舍。项目需要先把要解决的问题表达清楚,再讨论技术方案。

场景复杂度、数据规模、可靠性、实时性和并发性,应分别评估。对于较轻的查询或固定流程,可以采用较轻的方案;当跨域关系、复杂逻辑或关键业务保障要求提高时,再针对瓶颈加强模型、校验、同步和运行能力。图数据库等组件也应根据实际图分析与链路分析的需要配置。

因此,建设可以按照三个相互衔接的要求推进。先以小切口完成闭环,让任务、输入输出与验收条件明确;再验证收益,把效率、质量、建设成本和后续维护投入一起分析;在样板得到验证之后,检验第二个场景能够复用哪些对象、规则与方法,逐步扩展公共能力。

从语义层走向业务本体,企业需要把自身的数据、知识与经验转化为 AI 能够使用、业务人员能够验证的能力。此次分享所提出的路径,是从一个值得建模的业务判断开始,在真实任务中贯通分析、决策与执行,再把经验证有效的方法沉淀为可复用的知识资产,使 AI 在明确的业务规则和执行边界内逐步参与企业运营。