Machina 预测性维护智能体

微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署
AI模型价格对比 | AI工具导航 | ONNX模型库 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

在第一篇文章中，我描述了为什么我开始构建 Machina：当时没有框架可以构建用于工业维护的 AI 智能体。在第二篇中，我论证了这种框架的基础是一个包含资产、工单、故障模式和 ISO 代码的领域模型，而不是一个聪明的提示。

这两篇文章都建立在一个我还没有明确陈述的假设之上：

智能体做的并非都是推理。而且也不应该是。

Machina 正在积极开发中。以下是我正在跨 LLM 提供商验证的一个设计假设。

1、默认模型

打开任何最近关于"智能体 AI"的文章，画面大致是这样的：一个单一 LLM 在工具使用循环中，自主决定读取什么、调用什么、下一步写什么。ReAct、函数调用、"智能体工作流"。一个美丽的抽象，但在你把它指向一个真实的维护场景时就会崩塌。

以我在 Machina 中一直运行的典型例子为例：一个警报触发，智能体必须对其进行分类，在 CMMS 中查找资产，决定是否创建工单，填写正确的字段，通知正确的技术人员。

如果你把它连接成一个大的"给 LLM 所有工具让它自己搞定"的循环，会发生三件事：

1. 它在非决策上浪费 token。 读取传感器值不是决策。按标签查找资产不是决策。LLM 不需要"推理"是否在 iot.read_alarm() 之后调用 cmms.get_asset(tag)。那条边是固定的。
2. 它偶尔会编造一个步骤。 它跳过资产查找，用一个虚构的 asset_id 写一个工单。在 Jupyter 演示中这很有趣。在工厂中，它会污染 CMMS。
3. 它变得无法调试。 当出现问题时，跟踪是一个 14k token 的独白，没有人能回答 "为什么智能体那样做？"。

推理不是系统的基础。它是确定性骨架中的一种成分。

2、什么真正属于推理

我在设计 Machina 工作流时使用的启发式方法是每一步问一个问题：

这一步是否需要解释非结构化信号、模糊语言或未充分定义的上下文？

如果是，那就是一个推理步骤。LLM 在那里发挥作用。如果不是——"按 ID 获取这条记录"、"发布这个负载"、"如果严重度 > 3 则升级"——那就是一个确定性步骤。代码来完成。

在 Machina 附带的警报到工单工作流中，划分大致如下：

[D] 订阅 OPC-UA 警报主题
[D] 解析警报标签 → 资产（通过注册表）
[D] 获取该资产最近 30 天的工单
[R] 将警报 + 历史分类为可能的故障模式
[D] 查找该故障模式的 ISO 14224 代码
[R] 起草人类可读的症状描述
[D] 构建 WorkOrder 对象（优先级、资产、故障模式）
[D] 通过连接器推送到 CMMS
[R] 决定通知哪个技术员渠道（班次、角色、关键程度）
[D] 发送消息
[D] = 确定性    [R] = 推理

十个步骤中有三个推理步骤。其余的是管道工作。这个比例反映了维护工作的实际本质：一个结构化过程，穿插着少数判断时刻。

在 Machina 的工作流引擎中，这转化为类似这样的东西：

workflow = Workflow(
    trigger=AlarmTrigger(source="opcua"),
    steps=[
        Step.deterministic("resolve_asset", tool="registry.find_by_tag"),
        Step.deterministic("fetch_history", tool="cmms.get_recent_wos"),
        Step.reasoning("classify_failure", prompt="failure_mode_v1"),
        Step.deterministic("lookup_iso", tool="taxonomy.iso14224"),
        Step.reasoning("draft_description", prompt="symptom_v1"),
        Step.deterministic("create_wo", tool="cmms.create_work_order"),
        Step.reasoning("route_notification", prompt="routing_v1"),
        Step.deterministic("notify", tool="comms.send"),
    ],
)

每个 Step.reasoning(...) 是唯一调用 LLM 的地方。其他一切都是普通代码。

3、为什么这是一种模式，而不仅仅是优化

我所描述的在比我们更古老的领域有一个名字：确定性编排与叶节点推理。同样的模式出现在编译器中（确定性解析器、启发式优化器），机器人技术中（确定性运动规划器、学习型感知），交易中（确定性风险门控、学习型信号）。工业维护是最新需要它的领域，而不是第一个。

三个属性使其在这里不可协商：

可审计性。 每一个触及 CMMS 或传感器的动作都必须可追溯。"LLM 认为这是个好主意"不是审计追踪。显式的确定性步骤为每次转换提供一条日志记录；推理步骤被隔离，输入和输出单独记录。

在重要的地方保持确定性。 单位转换不是一个创造性行为。ISO 代码查找不是一个创造性行为。将 LLM 的非确定性保留在那些非确定性本身就是目的的任务上——解释、摘要、上下文感知排序。

成本和延迟。 一个调用 LLM 14 次来完成 for 循环和三个函数调用就能做的事情的工具使用循环，是 for 的缓慢、昂贵的重新实现。

4、我实际测试了什么

混合模式是 Machina 工作流引擎中内置的设计假设。框架本身正在积极测试中，每次运行后仍有一些事情让我惊讶。

到目前为止最一致的发现：较小和本地托管的模型在长工具使用循环中编造步骤的频率远远高于在具有清晰输入和清晰预期输出的单一、范围明确的推理步骤中编造的频率。约束 LLM 被允许"决策"的表面减少了我之前在纯智能体运行中看到的失败模式。我还不会点名提供商——我想发布正式数据，而不是轶事——但模型之间的差距足够大，以至于"它在 GPT-4 级模型上有效"不等于"它有效"。

这就是将 Machina 构建为框架的全部意义：我希望你能够更换提供商——云端的、本地的、蒸馏的——并让工作流保持正确，因为推理是一个小型的、范围明确的组件，而不是系统的脊梁。我们还没到那一步。我们正在测试。

5、如果你想深入了解

Machina 在 Apache 2.0 下开源。警报到工单工作流在这里。

如果这种框架理念引起共鸣，你现在能做的最有用的事情是给仓库加星。这告诉我这是否能打动真正从事维护工作的人。问题和 PR 都是开放的。打破东西并告诉我的人正是我为之构建的人。

原文链接: Not Everything a Predictive Maintenance AI Agent Does Is Reasoning

汇智网翻译整理，转载请标明出处