芯耀
与非AI
382
不少企业试图从“数据+大模型”直接迈向智能化，却在落地时发现：Demo里对答如流，上线后却频现幻觉，数据不准确，也讲不清决策依据。
这些问题的根源，是AI与业务之间缺少一层能够统一数据口径、业务概念与决策逻辑的语义接口。
本次分享专家结合高速收费、制造、金融等领域的实战经验，提出以“动态本体”打通数据、知识与智能的落地路径，让AI从会回答走向可执行，真正跨过业务闭环的最后一公里。
分享嘉宾：中创股份数据产品经理，李希明
内容已做精简，如需获取专家完整版视频回放，请文末扫码领取。
01、为什么数据不能直接迈向智能
最开始，我们希望在公司的优势行业里，把已有业务系统与AI结合起来。过往我们给不少客户建设过数据中台，首先尝试用“数据+智能”的方式，从智能问答、智能问数等场景切入。
落地过程中，发现数据中台解决了很大一部分数据治理问题，但AI仍然无法理解企业到底在处理什么业务。智能问答、智能问数在Demo阶段可能有效果，真正上线以后却会出现各种幻觉，很难进入具体业务场景。
以高速收费领域为例，一个企业可能有几十个业务系统，覆盖收费、清算、结算、发行等模块。每个系统都在处理自己的业务，AI只与数据库中的数据结合，即使把元数据作为语义层或者上下文提供给模型，也无法直接获得企业多年积累的业务经验。
用户还会追问：结果到底准不准？这个数是怎么算出来的？如果系统不能说明结果的计算和决策依据，就会面临不可解释、难追溯的问题。
如果想从数据直接迈向智能，中间缺少几样关键能力：AI无法理解企业内部的业务对象；不了解业务计算和处理规则，无法掌握业务流程；也不能解释结果背后的决策依据。
如果没有统一语义层，AI只能停留在回答层，无法真正参与业务。所以要让AI成为理解企业运行逻辑的智能引擎，必须在AI和数据之间架设一个语义层。
它向下承接数据，向上向大模型传递企业的核心业务概念、业务规则和计算逻辑，让AI与业务系统结合时，能够理解自己到底在处理什么业务。
逐渐加入规则和动作以后，我们把这一层称为本体：由本体提供统一的概念体系、关系体系和规则体系，让AI能够正确理解、组织和使用知识，同时约束知识的使用方式。
02 、本体给企业AI带来的四方面价值
有了本体以后，它可以从几个方面提升业务系统的智能化水平。
第一是准确性。本体能够减少业务歧义，但仅靠学术意义上的本体，例如OWL或者W3C体系，也很难保证业务百分之百正确。还需要补充业务术语、指标和非结构化知识抽取等能力。
第二是稳定执行。相关规则、动作和约束可以增强AI输出的可靠性，让AI按照业务要求处理问题。
第三是开发效率。企业不可能给每一个业务系统都单独建设一套智能体，这样开发慢、难以复用，跨数据和跨业务系统的协同也很难实现。有了统一的业务语义层，开发和应用效率可以明显提升。
第四是可持续沉淀。数据中台沉淀的是数据资产，本体平台则可以把业务知识资产化，支持长期迭代。
03 、本体智能平台架构如何建立
本体智能平台以本体语义为核心，目标是构建一个语义运行时，打造面向企业级AI应用的知识中枢和语义智能底座，打通数据、知识与智能的全链路。
平台向下可以对接企业已经建设的数据中台，如果企业没有数据中台，我们也会提供相应的数据处理能力。
首先，平台完成统一的知识建模，包括对象、属性、关系、规则、指标和业务术语等能力。
第二，概念和逻辑模型构建完成后，需要与底层数据做融合和映射。这些数据既可以来自数据中台，也可以来自业务系统。
第三，将知识和业务概念抽取出来，生成业务本体图谱。
第四，通过平台的智能推理能力构建推理引擎。这里既包括确定性的业务规则推理，也包括因果推理、一致性检测、前向链、后向链和溯因推理等能力。
最后，把这些能力封装成工具，提供给上层AI原生应用或者Agent。上层可以构建智能问答、异常诊断、告警和决策类智能体，让它们使用语义层中的业务知识、业务对象和业务实例。
本体平台向上提供业务视图的语义层，通过业务与数据的关联形成统一的本体语义对象，统一业务语言、数据语义、指标口径和异常分析规则。
基于这个语义层，平台可以形成面向本体对象、本体实例、业务语义模型的查询工具，也可以提供规则推理和知识库查询工具，上层智能体可以通过MCP等方式调用这些工具。
04 、本体建模不是把数据治理再做一遍
在具体项目中，客户经常会问：本体建模是不是把原来的数据治理重新做一遍？我们本来只想做一两个Agent应用，为什么要投入一整套治理工作？投入和回报能不能成正比？
数据中台刚开始兴起时，也经历过类似阶段。很多客户投入大量工作建设数据治理，却不清楚成果如何体现为业务价值。
本体并不是否定原来的数据治理和数据中台，而是在已有成果之上再构建一层业务语义。数据中台已经沉淀的元数据、数据标准、主题和指标，都可以被复用。
我们的落地过程大致分为六个步骤。
第一，业务梳理与调研。业务专家要帮助团队明确具体场景、业务对象、规则和流程。在公司熟悉的优势行业里，现场运维和业务人员可以加快这一步。
第二，概念建模。基于数据中台已经沉淀的元数据和标准，定义类、对象、属性，以及对象之间的关系和层级，输出概念模型。
第三，逻辑建模。在概念模型之上补充业务流转规则、计算规则、不同业务之间的约束和相关指标。已有主题层和指标逻辑可以与本体挂接，并关联底层数据源，形成逻辑模型。
第四，校验和优化。对模型进行一致性校验，检查规则是否冲突、定义是否正确，并由业务专家评审函数、衍生属性和计算逻辑。
第五，模型发布。在一个场景中验证没有问题后，把该领域的本体模型正式发布。
第六，系统集成。模型与线上数据中台或业务系统集成，再把相关工具暴露给智能体开发平台，为智能化应用提供支撑。
05 、本体落地要从小场景开始
我们的实践经验是，本体建设不能一开始就追求大而全。如果一上来就对企业所有业务对象统一建模，周期会很长、投入会很大，也很难在短期内看到效果。
1）应该优先选择高频使用、经常出现问题的场景，快速搭建POC原型，围绕场景构建本体，先验证它能不能解决问题，验证有效后，再逐步扩大范围。
2）同时，应当先建设业务核心本体，通过迭代不断完善。不要第一次就试图把所有对象、属性、关系、规则、指标、函数和动作全部构建出来，否则很容易陷入建模工作本身。
先把真实场景会使用到的核心业务对象，以及相关关系、属性、动作、规则和指标构建出来，在场景中验证，再逐步扩展。
3）本体也不能完全依靠人工引导式建模。我们增加了AI辅助建模能力，先让模型梳理核心对象，再与数据库表进行初步映射，并结合设计文档和用户手册提取业务规则。
规则可以先用自然语言表达，再逐步转换为SWRL等规则形式。当规则表达式无法满足业务要求时，再构建函数，或者调用业务系统已经开放的接口，把接口封装为函数，与规则结合。
这样可以加快落地和场景验证，但AI生成的内容仍然需要业务专家校验。
06 、高速、制造与金融领域的案例实践
以高速领域的收费场景为例，拆分场景进行本体建模。
一辆车进入高速公路，从入口收费站行驶到出口收费站，通过OBU、CPC卡或ETC等方式完成通行和缴费。费用进入省中心后，再根据车辆实际经过的路段拆分给不同业主。业主经常会问“收到的钱对不对？”“拆分有没有问题？”
过去，运营人员要查询不同数据库，核验多类数据，再根据收费和拆分规则重新计算，才能向业主解释。这非常消耗人力和运维时间。
建设数据中台以后，我们从指标层做了一些优化，但仍然无法直接回答这些业务问题。本体建模在很大程度上让AI可以参与处理。
首先，我们对收费和拆分领域的车辆、用户、站点、支付方式、通行方式、通行记录、路段和业主等对象进行统一建模。
其次，梳理这些对象在业务处理中依赖的规则。收费计算方式可以表达为函数；拆分异常如何判定，可以表达为规则，并与本体模型挂接。
原有指标也可以映射到本体。例如通行量可以建立在收费站对象上；收费金额既与收费站有关，也与路段和省中心有关。不同对象上都可以构建相应指标模型。
模型完成后，我们面向三个方向构建智能体：智能问数、异常归因和业务结果追溯。
省中心和路段业主可以查询每天的收费额、ETC使用率、免费车辆通行情况、拆分到账金额和货车通行占比，也可以直接追问某笔账单或某天拆分金额由什么组成、是否异常、异常原因是什么。
底层数据仍然来自原有数据中台，本体对象映射数据中台中的数据，再由语义运行服务向上层智能体提供工具，实现从数据到智能的业务闭环。
在制造业的装置智能管控场景中，一个复杂装置可能包含成百上千个传感器，这些传感器协同完成科学实验。我们对传感器和设备进行整体建模，并把原有小模型封装成函数，与本体模型挂接。
智能体做设备异常检测、异常更新和资源调度时，可以直接调用这些函数，获得准确率较高的结果，再进行协调、指挥和调度。
在金融租赁物监管场景中，租赁物可能包括船舶、车辆、设备和房产等多种类型。我们把不同租赁物建模为本体，再根据具体业务规则进行统一语义建模。
平台向上提供相关工具，为租赁物监管、租赁物估值以及后续风险判断提供支撑。
07 、Q&A 问答环节
爱分析：基于本体能力落地应用场景，从目前的实践看，本体应用落地过程中最大的挑战是什么？
李希明：我们在具体领域落地时，最大的挑战还是业务规则的梳理和业务函数的生成。这对业务专家和数据专家的协同要求很高。
如果规则层构建得不好，后面用它做推理或者构建智能应用，效果都会很差。所以，最大的挑战是有没有业务专家在本体建模过程中提供足够支撑。
比较幸运的是，我们落地的几个场景都是公司的优势行业，也积累了相关专家。项目中虽然遇到很多问题，最终还是能够解决。如果进入一个我们不熟悉的领域，业务规则和业务动作怎样梳理、怎样落到本体语义层上，就是最大的挑战。
爱分析：很多大型企业，让AI基于企业现有文档预生成本体或者梳理业务规则，这种方式在实际落地中的效果怎么样？
李希明：首先要看业务需要什么结果。我们落地的几个行业都和资金密切相关，一旦金额算错，无论处理过程多智能、速度多快，都是不可接受的。
在这些行业里，仅凭自然语言表达规则，用户无法接受，因为它会产生幻觉。我们更多还是通过具体业务规则和函数逻辑，把模型约束在确定规则上。
允许一定误差的场景，可以用自然语言构建部分规则。但我们的实践是，最初用自然语言生成规则时，结果准确性不高，不仅客户不能接受，现场运营人员也认为无法使用，更无法向客户解释。
后来，我们没有继续采用纯自然语言生成规则的方式，而是转向使用SWRL等形式化方式描述规则。
爱分析：平台在设计权限管理采用什么方式？
李希明：我们主要采用ABAC架构控制整体权限。相关技术标准对权限要求也比较严格，要把控制下沉到对象、对象实例和对象属性。
什么角色能看到什么属性、访问哪些数据；具体数据是否需要脱敏或加密；哪些动作需要在沙箱中运行；某些规则在特定情况下能不能执行；是否支持动态规则注入，这些都要纳入权限模型。
ABAC比RBAC的配置复杂度更高，但它对本体模型的约束可以更细、更强。
爱分析：当本体应用从Demo或试点进入生产级，底层数据平台的哪些能力会变得更重要？
李希明：我认为首先是数据集成，尤其是实时数据集成。
企业需要把多元异构的实时数据与本体实例直接挂接，让本体平台形成实时语义，支撑实时决策、实时预测和实时分析。
现在数据库厂商越来越多，技术架构也很多，包括结构化和非结构化数据。怎样通过CDC或者其他方式，把实时数据持续接入本体语义层，是一个重要能力。
实时集成过程中也包含实时计算。Flink CDC对一些主流数据库的支持比较强，但在国产数据库快速发展的情况下，尤其在一些特定行业中，怎样打通不同国产数据库的实时数据，仍然是一个难点。
爱分析：企业现在普遍建设智能体中台或智能体开发平台。本体平台与智能体平台之间应该怎样结合？
李希明：我们公司有企业级的智能体开发管理平台，与本体平台相辅相成。
两者通过工具和管道连接，智能体管理平台可以通过管道接入本体平台，本体平台再向它提供对象查询、对象实例查询、语义模型查询、动作执行、规则推理和知识库查询等工具。
智能体在构建过程中，可以自主选择和使用本体平台上的工具。对于需要确定性的场景，调用本体平台提供的工具，反而会更简单、可靠。而且当智能体处理确定性场景时，可以直接调用本体平台的工具，把规则和业务约束带入执行过程。
以上就是本次分享的内容，如需获取完整课件和视频回放，请扫码领取。
13年软件开发与数据平台研发经验，6年研发负责人团队管理经验，目前担任中创股份数据产品经理职位，负责产品研发团队整体工作，带领团队深耕数据领域全链路产品研发与落地，团队核心覆盖架构设计、核心研发、测试优化、项目落地等全流程岗位。深耕数据技术领域多年，全程主导参与各类数据平台的架构设计、核心研发与迭代优化工作，曾深度参与传统数据应用开发、企业级数据中台搭建等前期项目，后续牵头搭建并落地公司全栈数据产品体系，核心负责本体智能平台、数据集成平台、数据治理平台、数据分析平台、AI模型管理平台五大核心平台的整体设计、技术架构搭建与核心代码研发，同步统筹平台的性能优化、功能迭代与规模化落地。
