制造业设备故障诊断机器人：使用Dify知识库+工作流程的实用设计指南

简介

在制造业，每次设备出现故障，都会请资深工程师过来，依靠经验和直觉反复应对。然而，随着技术工人不断老龄化和退休，这种基于个人的失败应对模式是不可持续的。设备手册、SOP、过去的维修记录、报警代码列表——虽然这些信息存在于公司内部，但它是分布式的、非结构化的，对现场响应能力没有贡献。

本文从架构设计到调优，实际讲解了如何结合Dify的知识库和工作流程构建制造设备故障诊断助手。

背景和问题

制造业故障响应的现实

为什么 Dify 适合您

Dify 通过以下方式适应制造故障诊断场景：

• 通过知识库对多个知识源进行集成管理
• 使用工作流程进行路由和条件分支的可视化设计
• 使用**自托管（Docker Compose）**进行本地/封闭网络部署
• 微调搜索参数，例如重新排名和分数阈值
• 通过HTTP请求节点与MES/SCADA等外部系统联动

整体架构

flowchart TD
    A[現場担当者の問い合わせ] --> B[Dify Chatbot / API]
    B --> C{質問分類ノード}
    C -->|設備仕様| D[KB: 静的知識]
    C -->|標準手順| E[KB: SOP・アラームコード]
    C -->|過去事例| F[KB: 修理記録・ナレッジ]
    C -->|現在状態| G[HTTP Request: MES/SCADA]
    D --> H[回答生成ノード]
    E --> H
    F --> H
    G --> H
    H --> I[構造化回答出力]
    I --> J{信頼度チェック}
    J -->|高| K[現場担当者へ回答]
    J -->|低| L[エスカレーション: 保全チームへ通知]

知识库层次结构设计

设计理念：4层模型

将所有文档放入一个知识库是制造业中一种致命的反模式。我们建议采用“分层知识设计”，根据信息的性质划分知识库，并为每种问题类型切换搜索目的地。

####第一层：设备静态知识库

作用：回答“这个设备原本应该如何工作？”的问题。

大块策略：分为章节、子系统和部分模块。避免分割成固定数量的字符。

####第二层：标准操作/故障响应知识库

作用：回答“如果出现这种异常，默认情况下你会如何处理？”

分块策略：分为报警代码单元和程序段落单元。理想情况下，一个块对应一个应对路径。

第三层：历史案例知识库

角色：回答“过去出现类似症状时，您实际上是如何解决的？”

块策略：1 次失败 = 1 个块。添加设备 ID、日期和警报代码作为元数据。

####第四层：实时辅助信息（外部协作）

作用：回答“这件装备目前的状态如何？”最好使用工作流的 HTTP 请求节点实时获取它，而不是将其放入知识库中。

工作流程设计细节

###问题分类节点（LLM节点）

它接收用户输入并将其分为以下四类。

System Prompt:
あなたは製造業設備の問い合わせ分類エンジンです。
ユーザーの質問を以下のカテゴリに分類してください。

1. SPEC - 設備の仕様・原理・構造に関する質問
2. SOP - 標準手順・アラームコード・点検に関する質問
3. CASE - 過去の故障事例・修理履歴に関する質問
4. STATUS - 現在の設備状態・稼働状況に関する質問

カテゴリ名のみを出力してください。複数該当する場合はカンマ区切りで出力。

条件分支节点

根据分类结果切换搜索目标知识库。使用 Dify Workflow 的 IF/ELSE 节点 或 问题分类器节点。

IF category contains "SPEC" → Knowledge Retrieval(静的知識KB)
IF category contains "SOP"  → Knowledge Retrieval(SOP・アラームKB)
IF category contains "CASE" → Knowledge Retrieval(事例KB)
IF category contains "STATUS" → HTTP Request(MES/SCADA API)

如果有多个类别，则并行搜索，合并结果，并将其传递给答案生成节点。

###答案生成节点（LLM节点）

System Prompt:
あなたは製造業の設備保全エキスパートアシスタントです。
以下のフォーマットで回答してください。

## 初期判断
[症状に対する第一印象]

## 考えられる原因（優先度順）
1. ...
2. ...
3. ...

## 推奨する確認手順
1. ...
2. ...

## 確認すべきログ・センサー・部品
- ...

## エスカレーション判断
[人手による対応が必要かどうかの判断]

注意事項:
- 推測の域を出ない場合は明示すること
- 安全に関わる作業は必ず「有資格者による実施」を注記すること
- 検索結果に該当情報がない場合は「該当情報なし」と明示すること

调整搜索参数

调整概念

在制造业的故障诊断中，“通过一个参数设置对应所有问题类型”是不现实的。这是因为最佳参数根据问题类别而不同。

推荐参数设置

调音记录模板

在实际调优过程中，我们建议保留以下记录。

Chunk设计的实用要点

警报代码文档的块示例

---
alarm_code: E-401
equipment: 油圧ユニット HU-200
severity: WARNING
---

## E-401: 油圧圧力低下

### 症状
油圧系統の圧力が設定値を下回った場合に発報。設備は低速運転を継続するが、加工精度が低下する可能性がある。

### 考えられる原因
1. 油圧ポンプの摩耗
2. リリーフバルブの設定ずれ
3. 油圧ホースからのリーク
4. 作動油の劣化（粘度低下）

### 対処手順
1. 油圧計で実測圧力を確認
2. ポンプ周辺の油漏れを目視確認
3. 作動油のサンプリング検査を実施
4. 異常が認められた場合、ラインを停止し保全チームに連絡

添加元数据

将文档上传到 Dify 知识库时，在文件名和文档描述中包含以下元数据将提高搜索准确性。

• 设备ID/设备名称
• 警报代码（如果适用）
• 文档类别（手册/SOP/示例/清单）
• 最后更新

本地部署注意事项

使用 Docker Compose 自托管

在制造工厂环境中，互联网连接通常受到限制。 Dify 提供了自托管版本（Docker Compose），它允许在封闭网络上运行。

# docker-compose.yml 抜粋（LLM プロバイダ設定例）
services:
  api:
    environment:
      # ローカル LLM を使用する場合（Ollama 等）
      - OLLAMA_API_BASE=http://ollama-server:11434
      # または vLLM を使用する場合
      - OPENAI_API_BASE=http://vllm-server:8000/v1
      - OPENAI_API_KEY=dummy

本地LLM选项

请注意，在封闭网络上运行时，嵌入模型也必须在本地托管。

操作流程及持续改进

###反馈循环设计

flowchart LR
    A[故障発生] --> B[ボットに問い合わせ]
    B --> C[回答を確認]
    C --> D{解決?}
    D -->|Yes| E[解決記録を KB に追加]
    D -->|No| F[保全チームが対応]
    F --> G[対応結果を工単に記録]
    G --> E
    E --> H[ナレッジベース更新]
    H --> I[検索精度が向上]

定期保养项目

实施步骤

1. 第 1 阶段（2-3 周）：使用警报代码列表和关键 SOP 填充知识库。开始作为基本的问答机器人工作。
2. 第 2 阶段（1-2 个月）：添加了结构化的过去修理工/故障记录。引入问题分类节点，实现搜索目的地自动排序。
3. 第 3 阶段（2-3 个月）：添加了用于 MES/SCADA 协作的 HTTP 请求节点。现在可以根据实时情况提供答案。
4. 第 4 阶段（持续）：根据现场反馈不断改进知识和参数。

总结

制造业的设备故障诊断机器人不仅仅是上传手册。 知识的层次结构，根据问题类型的搜索路由，优化块设计，以及在操作阶段不断积累知识 - 通过将这些设计在一起，它就成为第一次在该领域使用的工具。

Dify的知识库+工作流程组合为这一需求提供了足够的灵活性。特别是，通过使用自托管版本，可以满足制造业特有的安全需求（封闭网络、禁止外部数据传输），大大降低了企业实施的门槛。

最重要的是，不要将这个项目定位为“人工智能引入项目”，而是“领域知识结构化项目”。隐性知识如何转化为可搜索资产的设计质量决定了机器人的实用性。