集团做Ontology，预算到底买到了什么？

同一个集团里数据团队交付词汇表图谱团队交付关系网络规则团队交付决策表应用团队交付一个调拨按钮。平台团队说这些可以装进同一套产品。五份方案都叫“本体”预算却可能是五份。集团负责人真正需要问的是每一份预算买到了什么承诺又该拿什么证据验收一、五个团队都交付了“本体”为什么不是同一种东西假设甲集团的A工厂必须在周五开工前拿到一批物料。B工厂账面上有库存但其中一个批次缺少质量放行证据运输到达时间也没有确认。计划员打开新系统问了一个很自然的问题“这批货能调过来吗”数据团队可以解释“可用库存”的定义图谱团队可以找到物料、批次与工厂之间的关系规则团队可以计算供货条件应用团队可以发起调拨申请。可计划员要的是一项能够采取行动的答复。如果系统显示“可以”他究竟可以做什么把B工厂列为候选向质量岗位询问发起审批还是直接创建调拨单这几个结果在界面上可能只差一个按钮在企业里却对应不同的责任、投入与后果。词汇清楚不意味着实例身份正确关系可查不意味着供货条件满足。一份词汇表、一张关系图和一个执行入口各自解决了问题的一部分。把它们统称为Ontology方便了介绍却可能遮住验收对象。我会要求每个团队先补完一句话“对于这次周五前供货的请求我们负责确认什么交付什么结果交给谁接着处理。”数据团队可能承诺统一数量口径图谱团队承诺找全已接入范围内的候选规则团队承诺根据确认过的输入判断可行性应用团队承诺把批准结果可靠地交给库存系统。到了这里负责人才能发现哪些职责重叠、哪些环节无人负责。同一能力也可能已经存在。B工厂的库存系统或许早就管理了预留量质量系统也有放行流程。新增项目要做的可能只是让这些能力围绕同一个物料和同一项需求接起来。若忽略这一步集团很容易付费重建已经可用的功能再为新旧两套口径协调付费。先说清承诺再讨论平台。这是我建议集团开始本体建设的顺序。二、三种建设对象对应三种不同的预算面对“本体建设”这个大名称我会把它拆成三个可分别讨论的对象本体模型、围绕本体运行的业务能力以及持续供给这些能力的产品体系。这是用于建设和评审的划分技术实现可以集中也可以由多个已有系统共同承担。第一种本体模型把业务含义变成共同契约模型回答我们在讨论什么对象它们是什么关系一句话在什么范围内成立。回到供货请求“物料”“库存批次”“可释放数量”和“供货承诺”需要分开。物料相同批次质量状态可能不同账面数量相同扣除预留后的可释放数量也可能不同。“B工厂有这种物料”与“B工厂能在周五前交付这批货”是两项不同的判断。模型的价值是让这些区分能被多个应用共同引用。应用引用同一个物料身份知道数量以什么单位计算也知道替代关系适用于哪个用途。以后某项定义调整团队能找到受影响的规则和消费者。W3C的OWL 2提供了类、属性、个体及其形式化含义的表达方式。企业可以按问题选择表达工具建设内容首先取决于哪些含义需要明确和共享。OWL 2入门第二版这一项预算通常包含领域访谈、定义确认、身份映射、关系与约束设计以及业务样例验证。它的验收证据应当具体A、B两家工厂是否对同一个对象作出了相容解释边界样例是否暴露出歧义定义是否有人负责维护。对象画得多不如一个关键含义被正确地共同使用。第二种运行能力让共同含义进入实际任务运行能力回答系统怎样取得事实、检查证据、形成判断再把判断交给有权岗位执行。模型定义了“质量放行”接口负责取得放行记录模型区分“账面数量”和“可释放数量”库存服务负责按当前状态计算模型表达调出与调入主体授权和业务系统负责批准及写入。这里的预算包含数据接入、映射维护、规则接口、权限、异常处理和动作回执。采购时要看一条具体请求能走到哪里缺少质量证据时返回什么库存被其他订单占用后怎样处理调用超时以后如何确认是否已经建单。合同中的一个功能名称不能替代这些问题。这类能力可以由一体化产品提供也可以复用已有系统。关键是每个环节都有明确输入、输出和责任组合起来能完成已经约定的业务任务。第三种产品体系让其他公司能够持续依赖产品体系回答第二家公司接入后谁维护、谁支持、变更怎样发布旧版本怎样退出。试点里建模人员可以在现场解释每一处例外。推广到多个子公司以后这种做法很快遇到人力上限。使用者需要清楚的接入说明、版本承诺、问题处理入口以及持续有效的维护团队。产品体系的预算因此还包括消费者支持、回归测试、发布、培训、迁移和退役。验收可以安排得很实际让一个没有参与首轮建设的团队接入再模拟一次定义变化观察它能否找到依据、识别影响并完成调整。图1三种建设对象与各自承诺图中三种对象对应的是承诺范围不是强制的三层部署。集团可以先为一个受限任务补模型和接口也可以为多个消费者建设产品服务预算和收益预期应与当前承诺保持一致。如果本阶段只验证模型就先验收共同含义及其用途。如果下一阶段已经承诺跨公司持续服务维护资源就应进入预算。用一次建模的钱承诺长期运营项目很容易在试点之后失去接手人。三、沿一次供货请求走完事实、校验、决策和执行三种建设对象怎样协作沿A工厂这次请求走一遍就清楚了。先确认“是谁”和“此刻知道什么”A工厂的需求要写清接收主体、物料、用途、数量和要求到达时间。B工厂的库存要说明物料身份、批次、单位、预留和质量状态。这些条件共同决定了哪些事实可以进入本次判断。先看身份。两个系统的物料名称相似只能帮助找到候选。是否属于同一物料需要引用已经确认的主数据或业务映射。若两种规格只在特定用途下允许替代就记录有方向、有适用条件的替代关系而不是直接合并身份。再看数量。A工厂按件提出需求B工厂按箱记录库存换算必须引用适用的包装规格。字段都叫“数量”并不表示可以直接相减。B工厂账面有货也要扣除已有订单预留并检查本地保留要求。还要看时间。昨晚的库存快照可以帮助筛选候选最终写入前却需要检查当前状态。系统应让使用者看见事实的时间和来源才能判断这份证据适合支持哪一步操作。这一步的交付是可追溯的候选事实它从哪个系统来指向哪个对象适用于什么时间由谁确认。模型提供共同含义数据服务提供实际记录两者在这里接上。证据缺失时把缺口交给能补齐的人现在发现候选批次没有质量放行记录。系统应该给出怎样的答案直接判定“不合格”把缺少记录变成了质量结论直接判定“可供货”又跳过了放行条件。更准确的答复是“质量放行证据不足暂不能确认该批次可用于本次供货请质量岗位补充或确认。”没有记录不等于事实为假。在OWL采用的开放世界语义下未记载的信息可以仍然未知。企业也可以为一个明确完备的登记范围规定“查无有效资格则不允许进入候选”但要把这个范围和规则说清楚。OWL 2入门第二版未知与行动限制可以同时存在对质量事实系统尚不能下结论对当前动作企业可以规定证据不齐就暂停。这样既守住控制要求也保留了正确的业务解释。校验的价值在于定位这个缺口。采用RDF数据图时SHACL可以表达并检查数据需要满足的形状约束采用其他技术时也应让校验结果指出具体对象、缺失条件及处理办法。SHACL2017年推荐标准同样运输到达时间尚未确认就应返回时效待确认。问题被分给质量和物流岗位各自补齐证据后再进入下一步。一个含糊的“数据质量不达标”很难推动这样的协作。形成供货判断把条件和结论放在一起质量证据补齐、运输时间得到确认后决策服务才有足够输入比较候选。它调用现有库存服务取得可释放数量检查用途、保留量和到达时间形成供货建议。这里可能使用决策表也可能调用计划或优化算法。OMG的DMN标准为决策模型提供了表达方法具体算法及执行方式仍由目标业务决定。DMN 1.5官方版本页一份有用的输出应把结论连同前提交给使用者。例如“按当前已确认的批次状态、预留数量和运输安排该方案满足周五前到货的约束等待调出方批准。”计划员能看懂结果也知道下一步找谁。结果至少要分清三种情况条件满足已有证据表明条件不满足证据不足而无法判断。第二种需要改方案第三种需要补信息。把两者都显示成红灯会让业务人员反复猜测系统到底在拒绝什么。每次判断还应关联使用的输入和规则版本。出现争议时团队可以解释当时为什么得出该结论而不是拿今天修改过的规则重新算一次就认为已经复现了昨天的决策。决策允许以后还要经过授权和执行A工厂的计划员选择了候选方案B工厂的授权岗位同意释放库存。此时才进入创建调拨单的环节。决策允许不等于岗位有权执行。计划员能看到候选库存可以提交申请修改B工厂库存需要另有明确授权。AI助手调用了一个工具也要受同样的对象、动作和岗位范围约束。从建议生成到批准完成库存状态可能变化。业务系统应在提交时校验关键条件并以库存预留或版本校验处理并发占用。若库存已被其他订单占用就返回状态变化要求重新判断原建议仍可保留用来说明此前依据。执行结果也需要一个确定的落点原系统确认创建成功返回业务单号建议与单据建立关联。遇到调用超时应按请求标识查询处理状态需要重试时沿用同一标识由业务系统识别重复请求避免重复创建调拨。这里的验收对象非常清楚权限能否守住变化能否识别业务单据与执行回执能否对应。具体采用哪个中间件、哪个平台是实现选择。单据建好了再看货和经营结果调拨单创建成功只完成了一个动作。货物是否发出、是否按时到达、是否被生产采用还需要后续记录。动作执行成功不等于经营收益已经实现。如果货物迟到系统创建了单据却没有解决周五开工的问题。即使按时收货也要检查改善来自哪里更好的数据、原有规则、物流协调和共享模型可能共同发挥了作用。先保留可以核验的结果再讨论收益归属。更快找到候选是分析改善减少人工对账是工作量变化按期满足需求才可能带来经营改善。每一个结果都对应自己的证据和成本。这条过程也给出了一套精简验收题让系统处理一次放行证据缺失、一次有库存却赶不到、一次无权下单以及一次批准后库存变化。团队怎样处理这些不顺利的分支比顺利点完所有按钮更能说明它交付到了哪一层。四、与主数据、图谱、RAG、规则引擎如何分工现在可以回头回答那个容易争论的问题企业已经有这么多系统本体究竟还要做什么我建议从职责接续来判断。谁已经可靠承担某项职责就让谁继续提供共同含义缺失在哪里就限定补在哪里。主数据确定身份共同模型表达业务上下文主数据已经确认的物料和供应商身份应当被继续引用。本体项目更值得补充的是这个供应主体在哪个地点、针对什么用途具有什么资格这个物料在什么条件下可被替代。不同公司的付款条件、合作状态和本地预留也要保留各自范围。统一身份以后业务差异仍然存在。把所有属性挑一个值汇成“集团真相”会把重要条件丢掉。指标语义层也可以保留原职责。库存周转与某批库存能否调拨使用部分相同数据却服务不同决定。共同身份和时间口径能帮助两者连接指标计算无需因此全部重写。图谱让关系可查业务确认决定关系怎么用设想一个漂亮的图谱供应商连着工厂工厂连着物料物料连着仓库。关系可以展开界面看起来已经很完整。但问到具体批次能否调拨团队仍回答“名称匹配程度较高”“这条线表示存在关联”。那么这张图目前适合发现线索距离可执行决策还缺身份确认、关系含义及必要控制。从供应介绍中提取的“具备某工艺”可以保存为带来源的声明经过质量或采购流程确认后才进入相应的已认可能力集合。探索资料和采取行动需要不同强度的证据。这也说明业务含义怎样建模、数据是否采用图数据库应分别做选择。库存事实可以继续保存在原系统共同模型通过映射与接口引用它们。是否增加图存储要由查询需求、时效和维护成本决定。RAG负责找到并使用资料决策服务负责给出受约束结论RAG把检索获得的信息与生成模型结合。对于这次请求它可以找到质量说明、运输要求和历史处置记录帮助计划员理解问题。RAG原始论文把检索结果用于供货判断还要确认资料适用于哪个物料、批次、用途和时间。共同模型帮助表达这些联系校验处理缺项决策服务检查条件语言模型再把确认后的结果解释给人。GraphRAG使用图和分层摘要等方法研究如何回答面向语料整体的问题。它可以帮助总结一批供应资料中的风险主题周五之前能否交付某一批货还要接上权威事实、规则与动作控制。GraphRAG原始研究因此验收应当根据任务分别组织检索任务看资料和回答依据供货任务看条件与结论执行任务看授权与回执。聊天界面可以把这些体验放在一起后台职责仍应清楚。规则服务作判断工作流与业务系统接住动作现有计划系统如果已经管理了可释放数量和约束就优先调用它。工作流继续管理批准过程库存系统继续承担权威写入。新增共享能力负责让它们引用同一对象、解释同一输入并把判断和动作对应起来。这个边界会直接改变建设范围。为两个系统补共同契约可能比重新实现规则、审批和库存处理更合适。选一体化方案时也应逐项确认哪些现有职责被接替、哪些仍然保留。再看一个更小的反例三位分析员对“有效客户”的统计范围理解不同没有跨系统身份问题也没有多个动作依赖这个定义。把口径、排除条件、样例和责任人写入指标目录就可能足够。词汇表足够时就把词汇表做好。架构师的职责包括识别值得建设的公共能力也包括让集团在较小投入已经能稳定解决问题时停下来。五、预算和评审到底应该检查什么说到这里“本体预算”应当能拆成一份可核对的工作清单。对于A、B两家工厂我会按下面五项组织评审。1. 这笔钱解决哪一个业务决定先固定范围本阶段只帮助两家工厂判断并申请调拨还是已经承诺真实执行是支持一次验证还是提供持续服务把对象、使用者和动作写清楚收益预期才能与交付范围对应。供应中断处置可以是集团级目标本轮投资却需要一个可完成的边界。若只验证候选发现就记录候选质量和人工复核涉及经营收益的承诺继续向执行与采用环节取证。2. 哪些能力复用哪些缺口新增哪些职责退出把工作分别标成复用、补齐、新增和退出。身份已可靠就引用库存时效不足就补接口多个应用确实需要共同含义才建设共享模型重复职责被替代后安排迁移。其中最容易遗漏的是退出。原来三个应用各自维护一份映射新平台建立后旧映射如果继续运行集团可能只是多维护了第四份。没有退出计划的复用承诺可能只减少了新增开发完全没有减少持续维护。退出的应是已被替代的具体职责。仍用于历史查询或本地业务的部分要说明保留理由、责任和成本。3. 与哪一种合理方案比较全部投入是什么新增本体产品体系应与一个可行替代方案比较例如改进现有主数据映射和规则接口为两个应用补共同契约。拿精心整理的新方案对比完全不治理的旧状况会高估新增公共层的贡献。两边都要计算相同范围内的工作业务确认、数据补齐、接口改造、测试、采用、运行和退出。现有平台已经付过许可费调用和维护仍可能占用人员与资源。GAO成本估算指南强调以范围、技术基线、工作分解和假设形成估计再用实际情况更新。用于本体建设时最有用的也是这种纪律钱对应工作工作对应交付假设能够复查。GAO成本估算指南负责人应同时看到整个计划的资金需求以及本体方案相对替代方案增加了多少成本、增加了什么价值。两套方案都要修的接口进入整体预算比较差额时按共同和新增工作分别处理。复用收益也要落到动作上。第二个应用接入是否减少了重复确认一次定义变化是否更快找到消费者旧职责是否实际退役都可以持续记录。人员少花了时间首先是能力释放形成现金节省还要有实际支出变化。4. 哪些证据足以验收谁对证据负责评审不必堆满材料。准备一条正常请求、一条证据不足的请求、一条批准后事实变化的请求让现有方案和候选方案使用相同输入比较结果、人工投入和异常处理。再做一次小变更把某项资格从按供应商统一管理改为按生产地点管理。团队能否找到依赖、估计修改工作、保留历史解释这项演练能检验所谓公共资产有没有共同维护能力。评审记录中最重要的字段是“谁对这句话负责”。谁确认物料相同谁确认批次可用谁批准释放谁核验收货和经营结果都应能指向具体责任岗位。5. 本轮批准到哪里什么证据出现后再追加把本轮结果写成一个明确决定复用哪些系统补哪些模型和接口谁提供持续资源投入上限是多少凭什么进入下一阶段。如果共享含义的价值已经出现但动作授权尚未落实可以先批准限定范围验证。如果维护负担超过了可证明的复用价值就缩小范围或保留本地实现。已投入的成本记录下来后续资金仍根据未来工作与证据决定。回到最初那份供货请求。A工厂的负责人最终需要知道系统今天能给出候选、形成判断还是已经能可靠执行。集团的投资负责人则需要知道为了让第二家、第三家公司持续使用还要增加什么投入。把这些承诺写进预算把对应证据写进验收再让有权岗位承担责任Ontology才会从一个方案名称成为企业可以选择、建设和持续管理的能力。