本体建模和大模型分析推理-规则写不完的地方，才是分析真正开始的地方

大家好，我是人月聊IT。

最近在研究本体模型与大模型结合的问题时，我做了一次比较完整的尝试：在已有的生产质量数据库上，先建立一套业务本体模型，把生产质量分析中涉及的业务对象、数据关系、判断规则和分析步骤都定义清楚，然后让大模型参与一次真实的产线异常调查。

这次实践让我有一个比较深的体会：规则可以告诉我们什么情况属于异常，也可以告诉我们应该按照哪些标准进行判断，但当我们真正面对一个没有预料到的问题时，规则往往无法提前告诉我们下一步应该怎么查。

这并不是说规则没有价值，而是规则和分析本身解决的不是同一类问题。规则更擅长处理已经明确的问题，分析则需要根据实际发生的情况，不断提出新的问题、寻找新的证据，甚至调整原来的判断方向。

图片

我想通过这次产线缺陷分析，把其中的原因和逻辑讲清楚。

一、问题的起点：数据库能查到数据，却不能直接告诉我们原因

先介绍一下这次分析的背景。

我手上有一套生产质量数据库，里面已经包含了产线、产品、工序、工位、设备、人员、班次、物料、BOM、来料批次、来料检验、生产记录、缺陷记录、返修记录以及质量预警等数据。

从传统数据查询的角度看，这套数据库已经比较完整了。想知道某条产线某一周生产了多少台产品，有多少缺陷，哪些设备出现过参数异常，某一批外壳流向了哪些生产批次，基本都可以通过 SQL 查询出来。

但问题在于，查到数据和理解数据之间，还有一段很长的距离。

例如，同样是计算某一周的缺陷率，分母到底应该使用投入台数、过站次数，还是其他统计数量？不同的选择会得到完全不同的结果。又比如，某个指标超过了 5%，究竟属于一般异常还是严重异常，也不能由分析人员临时决定，而必须有统一的业务标准。

还有一个更容易被忽略的问题：数据库中没有某项检验记录，究竟代表现场没有发生问题，还是这项检验根本就没有做过？这两个意思完全不同。

如果没有统一的业务定义，每次分析都要重新解释这些问题。不同的人可能使用不同的分母、不同的时间范围和不同的判断标准，最后得到的结论自然也不一样。更麻烦的是，即使报告中给出了一个看起来准确的数字，别人也很难知道它到底是怎么算出来的。

所以，我希望解决的并不只是数据库查询问题，而是在数据库之上建立一层统一的业务语义和分析约束。

这也是我构建本体模型的直接原因。

二、本体模型不是再画一张关系图，而是把业务知识变成可执行的分析依据

图片

很多人理解本体模型，容易把它看成知识图谱，认为主要工作就是把产品、人员、设备、物料等对象连接起来，形成一张业务关系网络。但这次我做的并不是一张用于展示的知识图谱，而是一套能够实际参与数据分析的业务模型。

简单来说，就是把我们平时依靠业务经验才能理解的内容，尽量整理成机器可以识别和执行的定义。

例如，生产质量分析涉及哪些业务对象，缺陷记录与哪个产品、工序和工位关联，一批物料流向了哪些生产批次，什么情况下算质量异常，异常分析需要经过哪些步骤，这些都需要有明确的定义。

这套模型主要包含六个部分。

M1 对象模型，定义业务世界里有什么。比如产线、产品、工序、工位、设备、人员、物料、批次、缺陷、检验和质量预警等对象，以及它们之间的关系。

M2 行为模型，定义业务活动是怎样发生和变化的。例如，缺陷产生后怎样进入返修流程，质量预警怎样转化为纠正措施，生产批次状态怎样变化。它解决的是业务对象之间不仅存在静态关系，还会发生一系列业务行为的问题。

M3 规则模型，定义业务判断标准。什么情况算异常，缺陷率超过多少需要预警，样本量达到什么要求才允许判断，采取措施后怎样评价效果。这些都应该有统一的定义，而不是让大模型或者分析人员临时决定。

M4 场景模型，定义具体分析任务应该怎样推进。例如，这次质量异常归因需要经过口径确认、异常确认、缺陷构成、工序定位、要素排查和根因确认六个阶段。

M7 指标与报告模型，定义指标的计算方式、统计维度和报告结构。例如缺陷率如何计算，应该按照哪些维度进行汇总，分析报告中需要展示哪些内容。

MM 映射模型，则负责把本体模型中的业务概念与数据库中的真实表、字段和视图对应起来。可以把它理解成一本翻译手册，告诉分析系统，本体中的生产批次对应数据库中的哪张表，缺陷率应该使用哪个字段和视图，哪些数据存在特殊的使用限制。

这些模型组合起来，形成的就不再是简单的业务关系描述，而是一套可以约束分析过程的业务语义模型。

举两个很实际的例子。

数据库中有一个周统计字段，模型说明将其定义为 ISO 周，但实际数据库视图采用了另一套周计算方式。结果就是，字段标记为 W39 的数据，实际对应的是 09-28 至 10-04，而不是按照通常的 ISO 周理解得到的 09-21 至 09-27。

如果分析人员直接相信字段名称，后面整个异常时间窗口就可能出现偏差。

另一个例子是物料追溯视图。某个视图会把一条缺陷记录重复放大六倍。如果直接对这个视图求和，就会把八千多条记录当成真实缺陷数量，而实际全库只有一千四百多条。

这些问题并不是数据库无法查询，而是数据库字段名称和业务含义之间存在差异。如果没有一层统一的语义定义和数据映射，后面的分析做得越深入，错误反而可能越大。

所以，本体模型首先解决的是一个基础问题：让所有分析都建立在相同的业务定义、数据口径和判断标准之上。

三、一次真实的质量异常，暴露了规则分析的边界

模型建立以后，我需要找一个真实的业务问题来验证它到底有没有价值。

这次选择的是一次产线装配缺陷异常。

九月下旬，L03 产线生产的 SPK-300 出现明显的装配类缺陷上升。按照既定指标口径，W39 周投入 750 台，发现 42 条缺陷，整体缺陷率达到 5.60%，超过了 5.25% 的严重预警线。

生产主管给出的解释是：最近来料外壳的公差存在问题，所以装配不到位。

这个解释听起来非常合理。缺陷名称就是“装配不到位”，缺陷描述又提到壳体存在缝隙，那么自然容易想到是不是外壳尺寸不合适。但质量分析不能停留在一个故事听起来是否合理，而是要看它能不能经得起数据检验。

如果真的是外壳来料问题，为什么之前没有出现同样的异常？是不是刚好换了一个物料批次？同样使用这批外壳的其他产线是否也出现了类似问题？如果不是物料变化，那么设备、人员、工艺和作业环境是否发生了变化？

这些问题没有一个可以直接从最初的缺陷率数字中得到答案。

真正的分析需要不断缩小范围，找到能够支持某种解释的证据，也要主动寻找能够推翻这种解释的证据。

这正是在复杂业务处理中引入大模型辅助分析推理的原因。

我并没有让大模型直接面对整个数据库，自由生成 SQL，然后自行判断根因。而是先把质量归因的基本分析框架固定下来，再让它根据每一步的查询结果，动态决定下一步需要查什么。

四、先固定分析框架，再根据数据动态决定调查方向

图片

这次质量归因在本体模型中预先定义了六个分析阶段。

第一步是口径确认。首先要确定统计指标怎么算，分析时间范围是什么，哪些数据视图存在使用限制。前面提到的 W39 周定义问题和物料追溯视图重复放大问题，就是在这个阶段处理的。

第二步是异常确认。不能只看到缺陷率上升就直接认定异常，还需要检查是否超过业务预警线，样本量是否达到要求，异常是否具备持续性。按照这次定义的判断条件，5.60% 已经超过 5.25% 的严重预警线，满足确认异常的要求。

第三步是缺陷构成。需要进一步判断究竟是哪一类缺陷导致整体指标上升。是所有缺陷都在增加，还是某一个缺陷代码突然变多？如果增长主要集中在少数几类缺陷，分析就应该继续向这些缺陷收敛。

第四步是工序定位。找到主要缺陷以后，还要进一步确定它集中在哪个工序或工位，而不能简单地认为发现缺陷的位置就是产生缺陷的原因。

第五步是要素排查。通常从人、机、料、法、测、环几个方面寻找证据，判断哪些因素出现了变化，哪些解释得到数据支持，哪些解释可以被反证。

第六步是根因确认。把前面得到的证据放在一起，判断它们是否能够形成完整的解释。同时也要明确还有什么问题没有解决，不能为了让报告完整，就强行给所有异常找一个原因。

这六个阶段是提前定义好的，但有一个很重要的区别：预先定义的是分析要经过哪些阶段，以及每个阶段必须回答什么问题，而不是把每一步所有可能执行的查询和判断全部提前写死。

例如，发现缺陷集中在总装工位以后，下一步就有必要比较白班和夜班的情况；发现同批外壳也被另一条产线使用，就可以考虑跨产线对照；发现来料检验没有尺寸测量记录，就需要把尺寸公差列为未评估项。

这些具体的调查方向，只有看到前一轮数据以后才有意义。

这就像医生看病一样，问诊、检查、诊断是基本流程，但并不是所有病人都按照完全相同的检查项目走一遍。发现某种异常以后，才需要决定下一步做什么检查。

规则负责规定分析不能跳过哪些关键环节，大模型则根据当前情况决定具体的检查方向。

五、真正的转折：数据没有支持主管的解释，反而出现了新的线索

按照前面的分析步骤，先看缺陷构成。

这次异常窗口中，D010“装配不到位”占全部缺陷的 44.4%。如果只看这个比例，并不算特别集中。但是，把异常窗口与之前的基线进行比较，就会发现 D010 贡献了全部缺陷增量的 74.6%。

这里需要注意，44.4% 和 74.6% 看的是两个不同问题：前者看异常窗口内的缺陷构成，后者看相对于基线新增的缺陷中有多少来自 D010。两个比例的统计分母不同。

这两个数字放在一起，说明了一个重要情况：整体缺陷构成看起来比较分散，但这次新增加的缺陷主要来自装配不到位。

这时候，分析就不应该简单地按照所有缺陷的存量比例进行全面排查，而应该重点追踪 D010 为什么突然增加。

继续向下分析，发现总装工位的缺陷率从基线的 0.587% 上升到异常窗口的 2.667%，贡献了约 78% 的工序增量。

至此，分析范围已经从整条产线收窄到了总装工位。

接下来需要验证主管提出的来料外壳解释。

首先看时间关系。数据库中只有三个外壳批次，分别在 07-10、07-20 和 07-30 入库。09-28 出现异常时，距离最后一个批次入库已经约 60 天，而且异常发生前后使用的还是同一批外壳。

如果是某个新批次引起的问题，通常应该能够在批次切换的时间上找到一些对应关系。但这次并没有发现这种情况。

然后看其他产线。同样的 SPK-300 产品也在 L04 生产，而且使用的是同一批外壳。L04 的装配不到位率从基线的 0.290% 上升到 0.333%，基本保持稳定；而 L03 则从 0.347% 上升到 2.333%。

这组数据很有价值。

如果外壳批次本身存在普遍性质量问题，那么使用同批外壳的另一条产线，理论上也应该有机会出现类似的变化。但实际结果并不支持这种解释。

最后再检查来料检验记录，发现一个重要问题：外壳来料检验只有色差项目，并没有尺寸、翘曲度和卡扣间距等测量记录。

这意味着我们不能直接说外壳公差一定正常，也不能说外壳公差一定超差。数据库里没有这方面的数据，准确的结论只能是：目前没有证据支持来料批次是主要原因，但外壳尺寸公差仍然没有得到有效评估。

接下来出现了更值得关注的人员线索。

09-18 入职、技能等级为 L1 的 EMP-0031，从 09-21 起就在总装工位独立顶岗。到 10-10 为止，他完成了 1080 次作业，其中出现 41 次失败，失败率为 3.796%。同一工位其他人员合计完成 720 次作业，出现 4 次失败，失败率为 0.556%。

两者相差约 6.8 倍。

再看班次数据，同一台设备、同一产品、同一批外壳，夜班缺陷率只有 0.278%。到了 10-12，换回熟练员工顶岗以后，总装工位缺陷率回落到 0.533%，D010 缺陷率也回落到 0.200%。

把这些证据放在一起，原来主管提出的来料解释就变得不那么成立了。相反，人员上岗安排、技能培训、授权管理以及总装作业条件，成为更值得关注的调查方向。

这里需要特别说明，我们讨论的不是某个人能力不行，而是新员工是否在具备充分培训和授权的情况下独立承担了相应工序。质量问题往往不只是个人问题，还涉及企业的培训机制、岗位授权和现场管理。

到这里，数据已经形成了一个比较有说服力的分析方向，但还不能说所有原因都已经完全确认。

例如，09-28 前后缺陷率曾经从约 3.3% 再次跳升到约 6.7%。但数据库中没有发现设备停机、保养、换型、物料批次变化等对应记录，锁付扭矩也都在规格范围内，工单没有变化，单件耗时也没有明显变化。

这段时间究竟发生了什么，现有数据还无法解释。

因此，比较严谨的结论应该是：本次缺陷上升的主要线索指向总装工位的作业条件差异，尤其与特定人员顶岗安排高度相关，但仍有一个时间节点上的异常变化需要进一步现场核实。

这个结论并不完美，但它比为了让报告完整而编造一个确定原因更有价值。

六、经典本体推理为什么能发现异常，却不能独立完成根因分析

图片

现在回到技术问题。

有人可能会问：既然已经建立了本体模型，也有完整的业务对象、关系和规则，为什么还需要大模型？用传统本体推理不行吗？

要理解这个问题，需要先弄清楚经典本体推理主要解决什么问题。

OWL2 可以用来描述业务世界中有哪些概念、对象，以及它们之间是什么关系。比如，生产批次使用某个物料批次，缺陷记录归属于某个工序，员工在某个工位进行作业。

SHACL 可以用来检查数据是否满足预先定义的结构和约束。例如，一条缺陷记录必须有发生日期和缺陷代码，一个生产批次必须关联供应商，某些重要字段不能缺失。

SWRL 则可以定义一些明确的判断规则。简单理解，就是把业务中的条件和结论写成机器能够执行的规则。例如，如果某条产线的缺陷率超过 5.25%，样本量达到要求，同时满足持续性条件，就可以推出该产线已经达到严重异常标准。

再由推理机执行这些规则，把已有事实和预先定义的逻辑结合起来，推导出允许推出的结论。

这套技术路线本身非常有价值。

在这次质量分析中，经典本体推理完全可以帮助我们发现整体缺陷率超过预警线，检查缺陷记录是否缺失关键字段，找到缺陷对应的工序，追踪物料批次的使用范围。如果提前写好了某个新批次上线后缺陷率明显增加的判断规则，它也可以在条件满足时及时给出提示。

这些工作都是确定性比较强的任务，使用规则推理反而更加稳定，也更容易审计。

问题出在后面的根因调查。

经典推理最擅长的是根据已有事实和规则推出结论，而根因分析还需要决定：面对当前这组数据，下一步应该提出什么问题，选择什么证据，验证哪一种可能性。

这两件事并不完全相同。

1. 规则可以执行，但不一定知道这次应该换一个分析角度

这次缺陷构成分析中，原本有一条帕累托判断规则：如果排名第一的缺陷占比不到 50%，并且累计达到 80% 需要超过五类，就按照系统性问题进行全面排查。

本次第一名 D010 的占比是 44.4%，累计到 80% 需要六类。严格按照原规则执行，确实会得到一个系统性问题的判断。

推理机没有做错，因为它只是按照已经定义好的条件执行。

但问题是，这条规则主要关注缺陷的整体构成，而这次我们真正要解释的是为什么缺陷突然增加。两者关注的重点不一样。

从整体构成看，D010 占比不到一半；从新增部分看，D010 却贡献了 74.6% 的增长。

如果继续按照原来的规则全面排查，就可能把分析带向各个要素都查一遍，最后得出很多没有明显异常的结论。反而忽略了最值得调查的总装工位。

这时候，大模型做的不是简单推翻规则，而是发现原规则的观察角度和当前问题并不完全匹配，主动提出改用增量视角进行分析，并说明为什么改变分析方式。

这就是动态分析和固定规则之间的一个区别。

2. 知道业务关系，不等于知道应该利用哪种关系

本体模型可以描述 L04 也在生产同一款产品，并且使用同一批外壳。也可以描述总装工位存在白班和夜班。

但是，描述出这些关系，并不意味着系统一定会主动想到要做跨产线、跨班次的比较。

这里实际上存在两个不同层次的问题。

一个是业务事实：哪些产线使用同一批物料，哪些人员在哪个工位工作，哪些设备服务于哪些生产任务。

另一个是分析动作：这次应该选择哪条产线作为对照？应该比较不同班次，还是比较换人前后的缺陷变化？

前者可以通过本体模型和数据库准确表达，后者则需要根据当前异常的表现来决定。

当然，我们完全可以把跨产线对照、跨班次对照等方法都写成规则。这样下一次遇到相似情况，就能够重复使用。

但这仍然有一个前提：我们必须事先想到这些分析方法。

3. 两件事同时发生，不代表已经找到了因果关系

数据库可以记录某个员工从哪一天开始上岗，也可以记录随后缺陷率发生了变化。

经典规则可以分别判断这两个事实是否存在关联，但仅有这些事实还不足以证明人员变化就是缺陷上升的原因。

我们还需要检查换人前后，设备、物料、产品、工艺和统计窗口是否发生了其他变化。要保证比较条件尽可能接近，才能让这个对照具备一定的说服力。

这实际上已经不是简单的数据库查询，而是在设计一次针对某种解释的验证。

大模型可以根据已有数据提出这样的验证思路，自动组织需要比较的对象和指标，再调用受控的数据查询能力取得结果。

但也要强调，大模型组织出来的前后对照仍然只是证据，不会自动变成严格的因果证明。最终还需要判断是否存在其他影响因素，并通过现场试验进一步确认。

4. 查不到数据，不代表没有问题

前面提到，外壳来料检验没有尺寸、翘曲度和卡扣间距的测量记录。

对于经典推理来说，这个问题其实很明确：没有相关数据，就无法判断尺寸到底是否超差。

这本身是正确的。

但根因分析不能停在这里，还要继续追问：这个未知是否影响当前结论？应该补充什么数据？能不能设计一个对照试验来验证？

例如，可以对现有外壳补测尺寸，再让熟练员工和新员工使用同批外壳进行交叉装配试验。如果熟练员工一次装配成功率明显更高，就会进一步支持人员和作业条件方面的解释；如果两者都出现较多失败，则需要重新评估外壳尺寸和结构适配问题。

这里真正重要的是区分三种状态：已经确认没有问题、已经发现存在问题，以及目前没有足够数据判断。

这三种状态不能混在一起。

大模型不能凭空补出不存在的尺寸数据，但它可以识别这个未知，并提出下一步应该怎样消除这个未知。

5. 规则可以不断补充，但不可能提前想到所有情况

有人可能会说，既然跨产线比较、跨班次比较、换人前后验证都有价值，那就全部写成规则不就行了？

当然可以，而且已经验证过的有效分析方法，本来就应该沉淀下来，成为下一次可以复用的知识。

但需要注意，规则的补充往往发生在问题解决之后。

这次我们发现同批物料跨产线对照有价值，下次可能出现的是某个供应商、某台设备和某个班次组合在一起才出现异常。再下一次，可能是新工艺、新工装，或者数据库中原来没有采集过的字段影响了分析。

业务世界不断变化，异常表现也不会始终按照我们预先设想的方式出现。

如果希望用规则覆盖所有问题，就需要提前考虑所有可能的异常形态、业务组合、调查方向和判断条件。即使继续增加一层管理规则的规则，也只是把原来的判断向上移动了一层，并没有消除未知情况。

所以，经典本体推理的边界并不是它无法进行复杂推理，而是它的推理范围最终受到已有知识、规则和数据的约束。没有预先表达出来的分析方法，它就不会凭空知道下一步应该做什么。

规则能够解决我们已经想清楚的问题，但不能保证提前覆盖未来所有值得思考的问题。

七、既然大模型能够动态分析，为什么还要建立本体模型和预定义规则

讲到这里，又会出现另一个问题。

既然大模型可以根据数据决定下一步应该查什么，为什么不直接把数据库交给大模型，让它自己分析就行了？

原因其实很简单：能够动态分析，不代表可以自由决定业务事实和判断标准。

如果没有本体模型，大模型可能把 5% 当成严重预警线，也可能使用过站次数代替实际投入台数；可能把发现缺陷的工位当成造成缺陷的工位，也可能直接对存在重复记录的追溯视图进行求和。

这些错误有时非常隐蔽。大模型完全可以把错误的数据和错误的逻辑组织成一份看起来很专业的分析报告。

所以，本体模型和规则模型承担的是一个非常重要的职责：给分析建立边界。

首先是统一业务含义。产品、工序、工位、批次、缺陷等概念必须有清晰定义，不能让大模型根据字段名称自行猜测。

其次是统一计算口径。缺陷率使用什么分母，统计窗口如何划分，预警阈值是多少，都必须有固定依据。

再次是统一判断条件。什么情况下可以判定异常，什么情况下只能标记为待验证，哪些证据必须具备才能进入根因确认，都应该有明确约束。

最后是保证分析过程可以追溯。大模型提出的每一个重要判断，都应该能够回到具体的数据、业务对象、指标和规则，不能只留下一个自然语言结论。

这也是为什么我更倾向于把大模型放在本体模型划定的范围内工作，而不是让它完全自由地面对数据库。

本体模型不是替大模型思考，而是确保大模型思考的起点和边界是正确的。

八、真正合理的技术分工：固定的交给规则，变化的交给分析

从这次实践来看，我认为比较合理的方案不是让本体推理和大模型相互替代，而是让它们承担不同层次的工作。

数据库负责存储真实发生的业务事实。它应该是分析过程中取得原始数据的来源。

SQL 和统计计算负责把数据算准确。无论是缺陷率、增量、分组比较，还是显著性计算，都应该尽量使用确定性的程序完成，而不是让大模型通过语言推测数字。

本体模型负责统一业务概念、数据关系、指标口径和判断规则。它告诉系统什么是产线、什么是工序，哪些数据应该怎样使用，什么条件下可以认定为异常。

大模型负责处理动态分析过程中那些没有被完全预定义的判断。它根据上一轮查询结果决定下一步查什么，识别当前规则是否适用，选择合适的对照对象，组织不同证据之间的关系，并明确还存在哪些未知。

而现场人员负责补充数据库中不存在的事实，实施物理验证，并最终确认措施是否有效。

这几个部分并不冲突。

例如，每天定时检查各条产线的缺陷率是否超过预警线，这是一项重复性很强的工作，直接使用 SQL 和规则引擎就足够了，没有必要让大模型每次都参与。

但如果某条产线突然出现从未发生过的异常，可能涉及人员、设备、物料、工艺等多个因素，而且每一步的分析结果都会影响下一步调查方向，这时才真正需要大模型的动态分析能力。

换句话说，日常监控主要解决已知条件下的自动判断，根因调查则需要处理未知条件下的分析决策。

两者的任务不同，适合采用的技术方式自然也不同。

当然，大模型参与分析也必须有约束。它生成的查询需要经过权限控制，尽量采用只读访问；每一轮查询、分析判断和规则调整都应该留痕；偏离原有规则时必须说明理由；涉及真实生产原因的结论，最终仍然要经过业务人员和现场验证。

不能因为大模型能够生成一段合理的解释，就把它当成事实。

九、这次实践让我重新理解了本体模型的价值

过去谈本体模型，很多讨论容易集中在对象、属性、关系、知识图谱和逻辑推理上。但通过这次实践，我认为本体模型的价值不应该只停留在描述业务世界。它更重要的作用，是把企业过去依靠人的经验才能完成的业务判断，逐步整理成可以被机器理解、查询、校验和执行的分析基础。

如果只把本体模型做成对象之间的关系图，它当然能够提供一定的业务上下文，但还不足以真正支撑复杂的业务分析。

只有进一步把行为、规则、场景、指标和数据映射都纳入进来，本体模型才有可能成为连接业务知识与实际业务分析的中间层。

但即使如此，也不意味着所有业务知识都可以在建模阶段一次性定义完毕。

模型能够沉淀已经明确的知识，规则能够覆盖已经理解的判断，场景能够规定分析的基本过程。可当真正遇到一个新问题时，仍然需要有一种能力，根据当前数据重新组织问题、寻找证据、选择路径。

这正是大模型可以补充的地方。

我越来越倾向于把这两种能力看成互补关系：本体模型负责建立相对稳定的业务认知和分析秩序，大模型负责应对实际问题中的变化和未知。前者让分析有依据、有边界、可复核；后者让分析不局限于事先写好的规则和流程。

当然，规则本身也不是越少越好。成熟、稳定、重复发生的业务判断，应该尽可能沉淀为规则。大模型在分析过程中发现的有效方法，也应该在经过验证后重新进入模型和规则体系。

这样，企业的业务模型才能随着实际问题不断完善，而不是每次遇到新问题都从头开始。

十、规则写不完的地方，才是分析真正开始的地方

回头看这次产线质量分析，最初我们只有一个简单的现象：L03 产线的装配缺陷率突然上升，主管认为是来料外壳公差导致的。

真正完成分析以后，我们发现问题主要集中在总装工位，来料批次解释缺乏足够支持，人员上岗安排和作业条件成为更强的调查线索。同时，还有一个时间节点上的异常变化没有得到解释，需要继续通过现场调查确认。

整个过程并不是大模型直接读完数据库就得出了答案，而是先有本体模型统一业务含义和数据口径，再由规则完成确定性判断，然后由大模型根据每一步的分析结果决定下一步查什么，最后通过现场验证补齐数据无法回答的部分。

这也让我对经典本体推理和大模型之间的关系有了更清楚的认识。

经典本体推理并没有过时。它在业务语义表达、数据约束和确定性规则判断方面仍然非常重要。大模型也不是来替代这些规则的，而是弥补传统分析方式面对未知情况时，缺少动态选择调查方向的能力。

以前我们做信息系统，通常希望把业务流程和业务规则尽可能提前定义完整，然后交给系统执行。这种方式对于流程稳定、规则明确的业务非常有效。

但真实世界并不总是这样。很多复杂业务问题，只有真正发生以后，我们才知道还需要检查哪些因素，原来定义的规则是否适用，以及哪些数据缺口会影响最终判断。如果把所有分析方法都要求在事前写成规则，最终就会陷入不断补规则、不断补流程的循环。而本体+大模型辅助推理，面对非提前预定的规则情况下，AI仍然可以基于已有约束进行分析和推理，得出最佳结论。人的作用是审核这些改进意见，如果可行，我们可以将过程中的关键规则逻辑进一步沉淀到原有的本体模型中，这才是我原来讲的可持续自我进化的动态本体。

而大模型带来的变化，是让系统能够在已有业务知识和规则的基础上，根据实际发生的情况动态组织分析过程。

规则负责把已知的事情做准确，大模型负责在未知的地方继续追问。

规则能够告诉我们什么情况已经构成异常，但当我们进一步追问为什么会发生异常时，真正的分析才刚刚开始。

下图为本体+AI大模型输出的分析报告截图：

图片