维修资料常分散在手册、报警列表、备件表和老员工经验中。知识助手的任务是把设备、部件、故障、症状、措施和资料来源串起来，让维修人员按具体设备快速找到可信线索。知识图谱提供明确关系，检索与问答提供自然语言入口；边缘节点使现场在受限网络中也能使用这些资料。
现场任务与数据条件
同一报警代码可能因设备版本不同而对应不同原因，备件号也会随改型变化。建设前应以资产台账为主线，统一设备型号、序列号、控制版本、部件号和文档版本，给知识条目设置责任人和生效范围。
故障记录的自然语言常含简称和口语，需要清洗同义词，并将“发生过”与“已确认根因”区分。助手回答时应优先引用适用机型的手册、工单和审核记录，呈现出处及更新时间；找不到证据时要明确告知，而非编造维修步骤。
系统架构与数据闭环
文档入库经过解析、结构化、去重和审核，图谱建立设备到部件、报警到原因、原因到检修步骤的关联。查询先按设备与权限过滤，再组合结构化关系和文档片段，输出可能原因、检查顺序与安全前提。维修结果回流后由负责人审核，才能更新正式知识。
离线车间可缓存常用资料和本地索引，中心统一管理知识版本和权限。涉及工单创建时可生成草稿并由人员确认；不能把知识助手的建议直接当作执行许可。要有过期文档撤回和错误知识纠正通道。
图谱的关系不应只有“报警对应故障”。更实用的链路是设备版本—部件—测点—症状—可能原因—检查步骤—备件—工单，且每条关系有来源与审核状态。这样维修人员可以从报警反查受影响部件，也能从备件号核对适用机型。
试点期间可统计“找到资料的时间”和“因引用错误而撤回的建议”，并让资深工程师审核难题。知识条目过期或设备改型后，应显示停用状态，不让旧方案继续作为推荐依据。
环节 | 建议明确的交付内容 | 现场核对重点 |
|---|
输入与采集 | 设备清单、信号或图像、设备ID和时间戳 | 数据权限、缺失值、同步与协议 |
边缘处理 | 预处理、模型或规则、事件缓存 | 并发、时延、版本、断网恢复 |
业务与执行 | 结果接收、人工复核、控制器边界 | 权限、联锁、日志与异常回退 |
工控机选型与集成
若本地同时承载检索索引和生成式问答，可评估N-BOX-S9；以查询终端为主、推理在中心时可评估N10-52。内存与SSD按文档数量、索引大小、并发用户和版本保留测算，具体型号要用真实资料集验证响应时间。
机柜安装、受限网络、备份和账号管理同样是交付条件。硬件采购并不自动包含图谱构建与知识治理，需在项目任务书中分别约定。
采购配置时建议同时提供目标模型及运行时版本、摄像头或传感器清单、现有PLC/MES/SCADA接口、现场供电与安装尺寸，以及连续运行和数据留存要求。派勤可据此核对标准整机、工业主板及x86 OEM/ODM改型方向。实际软件、采集卡、加速器和现场协议的兼容性以联合测试为准。
软硬件联调时，应先建立一份逐项可核对的接口清单：信号来自何处、由谁授权读取、数据以什么单位和周期产生、结果送往哪个系统、消息失败后怎样重试。对每个接口指定负责人和测试样例，保存正常、缺失、重复、延迟及错误格式的处理记录。涉及第三方算法或平台时，明确部署包、驱动、操作系统、协议适配与远程升级分别由哪一方提供。这样在扩线、换机或故障排查时，现场人员可以按记录定位问题。
实施步骤与验收
先选一个设备族，把典型故障、报警、备件和已审核手册做成试点。用真实问答测试机型匹配、来源引用、拒答、版本切换与访问权限，并记录维修人员是否减少重复查找。推广时建立每月知识审校与错答反馈机制。
项目可按需求确认、样机联调、现场试点、批量部署四步推进。样机阶段冻结硬件版本与软件镜像，记录接口、驱动、资源占用和热状态；试点阶段保留人工复核与旧流程对照。进入批量前，按量产配置确认开机、接口、温度、存储与恢复日志，并落实现场维护、版本回退和备件机制。
需要定制时，先明确不能由标准机型满足的接口、结构、散热或供货条件，再评审主板、整机、BIOS、外壳与连接器改型。派勤制造测试可采用12小时高温负载连续开机老化测试；这是硬件出厂流程的表述，不代表本应用的算法效果或项目现场测试结果。
常见问题
问：知识图谱和普通文档搜索有什么区别？
答：图谱明确设备、部件和故障之间的关系，便于跨资料追溯；原始文档仍是重要证据，二者通常配合使用。
问：没有完整维修数据库可以开始吗？
答：可以从一类设备的手册、报警与已审核工单做小范围试点，先建立命名和版本规则，再逐步扩充。
如需评估现场部署，请提供业务目标、设备与数据清单、模型和软件环境、目标节拍或响应时间、安装供电条件及预期数量。这样可以先验证最关键的接口与计算负载，再确定整机或定制方案。
