工业视觉、本体与归因，怎样改变一家工厂的 AI 转型。
我在为 Noxdi 制定工业 AI 方案时，用 Reality Runtime 演示了一个场景：一扎布料从 8 号工位被搬回 7 号。系统保留着下游工序的完工记录，现场轨迹却重新停在上游。在这段预设场景中，多出来的 41 分钟，被标成了没有进入系统的返工。
一边是记录，一边是过程。订单仍然有编号，工序仍然有名称，报表也可以正常生成。但如果那段过程没有被采集，接入这些记录的 AI，就缺少判断它实际经历了什么的直接证据。
这份方案中的案例和数值用于说明设计，尚不足以证明真实产线上的效果。我想借它讨论一个问题：当系统记录与现场过程之间存在空白，工业 AI 靠什么理解这段空白？
Reality Is All You Need，是我围绕这个问题提出的判断。这里的 Reality，是可以追溯、可以核对、允许纠正的现场证据。它决定了后续推理能站在哪里。对过程数据仍然缺失的工厂，转型首先需要解决的，就是这种证据从哪里来。
从系统记录到现场过程
ERP、MES 等工业软件，已经为订单、库存、工艺和生产执行建立了重要的记录结构。一些系统也能直接接入设备和传感器。具体到一家工厂，数据完整到什么程度，取决于它实际接入了哪些数据源、覆盖了哪些过程。
如果某段流程主要依赖开始、完成两个扫码节点，系统就容易知道一个状态何时被提交，却未必知道两个节点之间发生过什么。临时借料、重复作业、等待转运，可能需要额外的记录渠道，才能进入分析范围。
在这样的数据上增加 AI，可以改善检索、问答、排程和报表分析；Computer Use 可以进一步读取界面、操作软件，减少人的操作负担。这些能力都有价值。它们能否理解现场，仍然取决于现场信息有没有通过某个渠道进入系统。操作界面的能力，本身不会增加一项物理观测。
我把从物理现场采集事件、再与已有记录连接的能力称为 Reality Use。如果 Reality Is All You Need 表达的是工业 AI 应当从哪里出发，Reality Use 就是我对其中一项具体能力的定义：让 AI 读取发生在物理现场的过程。在为 Noxdi 制定方案时，我将这一思路放进了生产流转的场景。这样，AI 的上下文才能同时包含系统里提交的状态，以及状态之间实际发生的过程。
工业视觉：观察过程，不替代业务判断
工业视觉在其中承担了一项具体工作。
在质量检测、尺寸测量、定位和识别等应用之外，视觉也可以被用于采集过程：某个物料何时进入区域，是否被搬走，停留多久，有没有返回上游。以 Cognex 的机器视觉文档为例，一套视觉应用需要明确观察的特征、拍摄时机、照明，以及如何传递分析结果。这些物理条件始终是采集的一部分。Cognex：机器视觉系统的组成与工作过程
把视角从产品表面移到生产过程，会改变视觉系统的验收问题。除了能否识别对象，还要检查它是否漏掉搬运，是否把遮挡当成离开，是否在交接时跟错物料。对过程分析而言，一次错误的身份关联，可能把整段经历记到另一张订单上。
在这份方案中，我设计的分工是：用扫码锚定身份，用视觉补充流转。视觉轨迹与扫码事件在工位和时间上对齐后，才尝试建立关联。真实落地时，这种关联仍要处理多人同时操作、多个扎包并行、轨迹中断等情况，并保留无法确认的状态。
这也限定了视觉能够解释什么。摄像头观察到物料停留，可以支持停留事件；要把它解释成作业、等待或返工，还需要工序状态和其他证据。动作背后的意图，往往要通过上下文或现场确认才能澄清。识别到物料，也不能直接替代完工、合格数量或质量验收。
本体：让现场事件进入业务语言
接下来的问题是：这些事件应该怎样进入企业的业务语言？
这就是本体发挥作用的地方。哲学中的本体论讨论存在及其分类；在工业 AI 的工程语境里，本体把对象、属性、关系及其含义明确下来。W3C 的 OWL 2 文档将本体描述为对某个领域的精确陈述，使概念及其关系可以被软件理解和推理。W3C：OWL 2 本体语言入门，2012
一扎布料可以同时关联订单、款式、工艺路线、工位和周转车。它返回某个区域，在图像里只是一次移动；沿着这些关系，系统才可能知道那里对应上游工序，这次移动偏离了哪一版工艺路线，以及哪些订单可能受到影响。
这些定义也决定了什么状态可以被提交。搬到下一工位、完成加工、通过质检，分别表示不同的业务事实。把它们都压成一个完成状态，会让后续分析失去区分；把它们的条件与验证来源写清楚，才有机会检查流转是否合理。
本体还要保留变化的时间。工艺路线何时生效，工位当时安排了谁，某个物料在哪一刻属于哪个扎包，都会改变事件的解释。拿今天的路线判断昨天的生产，可能制造出不存在的违规；用当前人员安排解释此前的动作，也可能关联错人。
在 Palantir 的工程实践中，Ontology 同样被定义为连接数据资产与现实对象的运营层，并包括对象、属性、关系以及受治理的动作。这说明本体可以支撑业务操作。具体项目仍然需要为它接入可靠的数据，并验证关系是否成立。Palantir：Ontology 概述
一张关系完整的图，可以清楚地表达一套错误的认识。本体里没有记录转运负责人，现场也可能存在一项未录入的安排；工位绑定某个人，未必能证明某次动作由他执行。一个可用的业务模型，需要给缺失、推断和已核实的信息留下不同的位置。
起步也可以很小。围绕一种返工或一处转运问题，先明确相关对象、关系、状态与规则，已有数据库和事件记录就可能足够。后续是否需要更复杂的本体工具，应由实际推理和协作需求决定。
三条线：让现场与记录对账
有了观测与业务含义，现场和记录才具备对账的基础。在我为 Noxdi 制定的方案中，我把它写成三条线：应该走的、系统说的、现场看到的。
应该走的来自有效的工艺路线与计划；系统说的来自扫码、报工和其他记录；现场看到的来自摄像头或传感器。三者需要对齐到同一对象、同一时间范围，再比较哪里出现了差异。模型预测的下一步也可以提供线索，但历史上经常发生的行为，未必符合当前有效的工艺要求。
这种对账仍然要检查数据源。视觉可能跟错对象，系统可能延迟同步，现场也可能执行了一项尚未更新的工艺变更。差异意味着有一件事需要核查。确认哪条信息可靠，要继续沿着各自的来源找证据。
围绕对象组织事件，也有助于避免把过程拆散。一次搬运可以同时关联扎包、订单、工位和周转车。OCEL 2.0 这类对象中心的事件日志，支持表达事件与对象的关系、对象之间的关系，以及对象属性的变化，为这种记录方式提供了可参考的规范。OCEL 2.0 规范，2024
归因：从候选解释到验证行动
但把差异组织清楚之后，还有一个更难的环节：归因。
在演示的返工场景中，工艺改版后发生了物料倒流，旧版工艺单因而成为一个候选原因。这条线索值得调查。如果现场照片证明旧版工艺单仍在使用，候选原因就获得了更多支持。不过，要确认它造成了这次返工，还需要核对返工内容、版本差异，以及当时是否存在其他影响因素。
归因应当帮助负责人缩小核查范围。系统可以把候选原因、支持证据、反对证据和验证动作放在一起：检查工艺版本，核对来料问题，确认是否只是临时暂存。让负责人知道下一步查什么，比直接给出一个原因名称更接近可执行的价值。
这里也需要理解分数的含义。模型给出的分类分数或原因排序，要经过真实场景的检验，才能知道它是否可靠。演示中的置信度只说明界面怎样表达判断。它不能替代概率校准，更不能让一个待验证的解释自动成为结论。
同样，负责人派出一张核查单，表示这个问题值得处理。只有补回的证据和后续结果，才能继续支持原因判断。若把派单直接当成正确标签，系统就可能不断强化最初的猜测。回灌需要保留核查结果，也需要留下判断被纠正的过程。
这种区别会影响工厂里的责任分配。某个班次出现更多停滞，可能与订单难度、物料配套或交接安排有关。工位和人员关联可以帮助找到核查入口；绩效或责任判断，还需要更完整的证据，以及当事人补充情况的渠道。
我把方案中的整个过程串成了看见、锚定、解析、对账、归因、交付、回灌。方案把事项交给负责人，由人确认处理；必要时，再通过软件接口或 Computer Use 写回业务系统。行动之后，还要继续观察：工艺单是否更新，物料是否恢复流转，相同问题是否再次发生。处理结果因此能回到系统，成为下一次判断的依据。
转型成效：区分方案改善与模型贡献
而这只是第一层归因：业务异常为什么发生。
工业 AI 转型还需要第二层归因：项目带来的变化，有多少来自 AI？
假设一家工厂在项目期间同时增加了摄像头、统一了物料编号、整理了工艺版本、调整了转运责任，又启用了模型。后来等待时间下降，整套方案可能有效。模型在其中贡献了多少，仍然需要进一步评价。
这个问题决定下一笔投入。如果主要改善来自明确交接责任，企业就需要继续完善流程；如果现有证据仍不完整，就需要改善采集；如果模型确实能在相同证据上提高分类或核查效率，扩展模型应用才有更具体的依据。把贡献辨认清楚，企业才知道该复制哪一部分。
反过来，把项目效果不佳统一归于模型，也会误导下一轮投入。轨迹失真、身份错配、工艺版本过期、事项无人处理，发生在不同环节。更换模型只能处理其中一部分。转型的归因框架，应当覆盖从采集到行动的整条链路。
Hernán、Hsu 和 Healy 在关于数据科学任务的论文中，区分了描述、预测和包含因果推断的反事实预测，并强调因果分析需要领域知识。把这一区分带回工厂，知道发生了什么、预测接下来会怎样，以及判断某项投入改变了什么，需要不同的证据与假设。Hernán 等：数据科学任务的分类，2019
因此，评价工业 AI，需要尽量建立可比较的基线：相近的款式和批量、明确的工艺版本、相同的指标口径，以及对班次和人员安排变化的记录。条件允许时，可以采用有可比组的分阶段上线或受控试验。仅有上线前后两个数字，很难排除订单结构、设备状态和管理调整的影响。
评价还可以分两步。先看整套方案相对原有流程是否改善；再在适当范围内比较相同数据和规则条件下，增加模型后有没有额外收益。感知、规则、人员行动和模型可能存在相互作用，未必能够完全拆开。这时应报告整套方案的结果，并说明单项贡献仍有不确定性。
观测的变化尤其容易影响评价。当过去没被记录的返工开始进入系统，账面上的返工数量可能暂时上升。要判断生产是否变差，需要同时检查实际过程与采集覆盖，避免把发现能力的提高误读为问题增加。
改善最终也要回到经营结果。系统找到了多少差异，可以衡量发现能力；企业还要看有效问题是否被解决，等待和返工是否减少，交付是否改善。核查人工、误报、维护和算力都是成本。节省了一段等待时间，能否形成更多产出，还取决于它是不是生产约束的一部分。
从一个可验证的问题开始
这些限制也让 Reality 有了更具体的边界。已有设备日志和传感器足以回答问题时，可以先使用那些数据；人工核查与简单规则能够稳定处理的问题，可以保留这种做法。采集手段与模型复杂度，应当跟随尚未解决的问题。
对于仍然依赖离散报工节点的现场，工业视觉的意义，是补充一段过去难以记录的过程；本体把这段过程连接到订单、工艺和资源；归因再引导人核查原因，并检验行动是否有效。三者一起，才可能让 AI 的建议获得可检查的业务依据。
回到我为 Noxdi 制定的方案里，那扎返回上游的布料。那 41 分钟目前只能说明方案想解决什么。要证明它在真实产线上有用，还需要验证轨迹是否正确、身份是否可靠、返工是否成立，以及处理之后有没有改善。
这也给工业 AI 转型留下了一个实际的起点：先选一个反复出现的现场问题，把它的证据、含义、核查和处理结果连接起来。下一次布料返回上游时，负责人能更快知道该查什么，并在行动后验证结果，这项转型才有了可以继续检验的基础。