PHM念叨叨系列--工业场景大模型幻觉治理

工业场景的幻觉治理跟实验室里玩 demo 是两码事。实验室里 hallucination = 输出错一个数字。工业场景里 hallucination = 停线、安全事故、合规罚款、客户投诉。所以工业界的做法不是"选一个方案"，而是多层防御体系。

---

一、工业幻觉的真实后果

场景	幻觉 = 什么	代价
设备运维诊断	报错了根本不存在的问题	误停机，每小时损失十几万
质量控制	漏检缺陷 / 误判良品	不良品流出，召回
工艺参数推荐	给出超出安全边界的参数	设备损坏、产品质量事故
供应链预测	虚构市场趋势/数据	库存积压或缺料
客服/销售	编造产品价格、合同条款	合规风险、客户纠纷

核心差异：工业场景不允许"大概齐"，要的是可追溯、可验证、可定责。

---

二、工业级幻觉治理体系（五层防线）

第一层：数据治理 ------ 源头掐断

幻觉的最大帮贼是垃圾输入。 工业数据的质量直接决定幻觉率。

数据清洗：
├── 去重（MES 系统中同一个工单可能被记录多次）
├── 补缺值（传感器掉线产生的 NaN → 插值或标记）
├── 格式标准化（不同厂商的时间戳/单位/编码）
├── 剔除异常值（传感器故障产生的 -9999）
└── 版本管理（工艺参数每次变更都有版本记录）

工业实践：

• 知识图谱优先于纯文本 RAG。 工业知识结构化程度高，用知识图谱建模设备-工序-故障-处理方案的关联，比向量检索靠谱得多。
• 数据血缘追踪。 每一条被 RAG 检索出来的数据，都能追溯到原始传感器/文档/操作员录入，出了问题能定责。
• 数据时效性控制。 工艺参数三个月前有效不代表今天有效。所有工业数据必须带时间戳和有效状态标记。

第二层：模型选型 ------ 别什么都上大模型

工业界的共识：不是所有问题都需要 LLM。

决策树：
问题需要创造性和开放推理吗？
  ├─ YES → LLM + RAG + 验证层
  └─ NO
       ├── 规则能覆盖吗？ → 规则引擎（零幻觉）
       ├── 有标注数据吗？ → 小模型微调（BERT/CNN/RF）
       └── 都没有 → 先别急着上 AI，攒数据

实际工业选型矩阵：

场景	推荐方案	幻觉风险
设备故障代码匹配	规则引擎 / 决策树	零
质检图像缺陷识别	CNN / YOLO	极低
工艺参数优化	强化学习 + 仿真验证	可控
运维知识问答	LLM + RAG（工业知识库）	中，需管控
工单自动生成	LLM（结构化模板）	低
管理层分析报告	LLM（标注置信度）	中

黄金法则：能用规则不用模型，能用小模型不用大模型，能用确定性不用概率性。

第三层：输出管控 ------ 护栏（Guardrails）

这是工业 R&D 和 POC 的分水岭。 实验室里只关心回答质量，工业上线必须加护栏。

3.1 硬性规则护栏

class OutputGuardrail:
    """输出前必须通过的检查"""
    
    def check_temperature(self, response):
        """工艺温度必须在安全范围内"""
        if suggested_temp > MAX_SAFE_TEMP:
            return BLOCK  # 直接拦截
        elif suggested_temp > NORMAL_RANGE[1]:
            return FLAG   # 标记，需要人工确认
        return PASS
    
    def check_units(self, response):
        """单位必须统一转换为标准单位"""
        return convert_to_standard_unit(response)
    
    def check_format(self, response):
        """输出格式必须是指定的 JSON schema"""
        return validate_json_schema(response, expected_schema)

工业实践中常见的护栏规则：

• 超出物理边界的数值直接拦截（比如建议温度超过材料熔点）
• 涉及安全的操作建议必须经过人工审批
• 禁止输出任何未经验证的"可能"、"大概"
• 所有输出必须附带置信度和决策依据

3.2 置信度分级

confidence = calculate_confidence(response)

if confidence > 0.85:
    execute_automatically(confidence="AUTO_EXECUTE")
    
elif confidence > 0.70:
    route_to_human_review(confidence="NEEDS_APPROVAL")
    # 值班工程师审批后才能执行
    
elif confidence > 0.50:
    return_as_suggestion(confidence="SUGGESTION_ONLY")
    # 仅作为参考，必须人工决策
    
else:
    block_and_escalate(confidence="BLOCK_UNKNOWN")
    # 模型太不确定，升级到专家

这就是工业和玩聊天的最大区别：有置信门槛，有审批流程。

3.3 输出模板化

禁止自由文本，强制结构化输出：

{
    "diagnosis": "轴承磨损",
    "confidence": 0.92,
    "evidence_sources": [
        "振动传感器 V-201 频谱分析 (2024-03-15 14:32)",
        "历史工单 WO-20240312-0045"
    ],
    "recommended_actions": [
        {
            "action": "安排检修",
            "priority": "high",
            "safety_check_required": true,
            "estimated_downtime_hours": 4
        }
    ],
    "uncertainties": [
        "传感器数据有 12 小时空窗期，可能存在漏检"
    ]
}

第四层：验证体系 ------ 双层 + 物理仿真

4.1 LLM 双重验证

Generator LLM  → 生成故障诊断报告
      ↓
Domain-Specific Verifier
      ├── 规则验证器（物理边界、工艺约束）
      ├── 事实验证器（对比真实传感器数据）
      └── 一致性验证器（历史经验库匹配）
      ↓
仿真引擎（Digital Twin）
      ├── 在数字孪生体上模拟建议的参数
      ├── 检查结果是否在安全边界内
      └── 模拟结果通过才放行

关键创新：引入物理仿真/数字孪生作为验证器。 这不靠 LLM，靠物理定律和工程模型。

4.2 A/B 平行验证

# 实际部署中的影子模式
def shadow_mode():
    """
    新模型上线前，以影子模式运行 30-90 天：
    - 模型生成建议，但不执行
    - 工程师独立做出决策
    - 对比模型建议和人工决策的差异
    - 统计准确率、误报率、漏报率
    - 达标后才切换到"建议模式"
    - 再运行 90 天后评估是否允许"自动模式"
    """

工业上任何新模型都要走这个流程。 没人敢直接上线让 LLM 控制产线。

第五层：运维监控 ------ 持续追踪

上线不是终点。工业场景对模型监控的要求远高于互联网公司。

5.1 幻觉率实时监控

# 每天自动统计
metrics = {
    "daily_queries": 1500,
    "high_confidence_correct": 1200,   # 高置信且事后验证正确
    "high_confidence_wrong": 15,       # 高置信但错误 → 这是"致命幻觉"
    "escalated_to_human": 200,         # 不确定升级到人工
    "human_overrode_model": 45,        # 人工推翻模型建议
    "hallucination_rate": 1.0%,        # 15/1485 → 在监控阈值内
    
    "sla_threshold": 2.0%,             # 超阈值触发告警
    "critical_hallucination_count": 0  # 涉及安全的错误，容忍度为0
}

5.2 数据漂移检测

# 监控输入数据分布变化
if input_distribution_shift > threshold:
    trigger_alert("数据分布偏离训练集，模型性能下降风险")
    # 举例：新装了传感器型号，数据范围不同
    # 或者：工艺路线变更，旧数据不再适用
    schedule_model_retraining()

5.3 审计追溯

每条 LLM 输出必须可审计：

Audit Log:
- Timestamp: 2024-03-15 14:32:05.123
- Query ID: Q-20240315-004521
- Model: gpt-4-0125-preview
- Input hash: sha256(...)
- RAG sources: [DOC-001, SENSOR-LOG-789, WO-20240312-0045]
- Generated response: {...}
- Confidence: 0.92
- Guardrail checks: [PASSED x7]
- Verifier decision: APPROVED
- Human reviewer: 张工（值班）
- Final outcome: 检修完成，轴承确实磨损

这不只是技术，这是合规。 出了事故，你得说清楚当时模型说了什么、依据是什么、谁审批的。

---

三、典型工业场景拆解

场景 A：设备故障智能诊断

输入：
├── 实时传感器数据（振动、温度、电流）
├── 历史故障库
├── 维护手册
└── 设备运行日志

幻觉治理：
1. RAG 只检索该型号设备的特定文档（限制检索域）
2. 输出的所有诊断必须附传感器数据支撑
3. 建议的操作不能超出安全规程范围（硬规则）
4. 任何涉及停机的建议必须工程师审批
5. 诊断结果与后续检修结果闭环验证

场景 B：工艺参数优化

输入：
├── 当前工艺参数
├── 产品质量检测结果
├── 历史最优参数记录
└── 材料批次信息

幻觉治理：
1. 推荐参数必须在物理/工艺边界内（硬拦截）
2. 参数变更量不能超过历史最大变更幅度
3. Digital Twin 仿真验证（模拟新参数下的产品质量）
4. 首次执行小批量试验 → 确认质量 → 再全量
5. 每次变更后持续监控质量指标 24 小时

场景 C：工业知识问答（最典型幻觉场景）

场景：操作工查"XX 设备的 YY 故障怎么处理"

幻觉治理：
1. 知识源只有企业 Wiki + 设备手册（不包含互联网数据）
2. 每句话必须带来源标注（第几页手册、哪个 SOP）
3. 安全操作步骤禁止自由生成，直接从 SOP 模板填充
4. 答案中不确定的部分明确标识
5. 所有问答记录进入知识库，定期由专家审核

---

四、工业幻觉治理的成熟度模型

阶段	特征	幻觉率
Level 0 - POC	裸用 LLM，无约束	高，不可控
Level 1 - 受控 POC	加了 RAG 和格式约束	中，可统计
Level 2 - 影子模式	双层验证 + 影子运行	低，有监控
Level 3 - 建议辅助	所有建议需人工审批	极低
Level 4 - 受限自治	高置信场景自动执行	接近零
Level 5 - 不可达	100% 无幻觉	不存在

实话：绝大多数工业项目还在 Level 1-2。到 Level 4 需要投入巨大且不适用所有场景。Level 5 不存在------接受这个事实，比假装不存在更重要。

---

五、一句话总结

工业场景解决幻觉的公式：

严格数据治理 + 模型分级 + 规则护栏 + 仿真验证 + 人工审批 + 持续监控 = 可控幻觉

不是"让模型别胡说"，而是假设它一定会胡说，然后建立体系兜底。

这是工业和互联网的根本区别：互联网接受 occasional hallucination，工业不接受------因为代价不一样。