工业设备智能运维与AI知识问答平台

立项背景与目标：客户为某大型制造集团（下称"A集团"，客户名称已做脱敏处理），在全国拥有12个生产基地、3万余台工业设备。此前设备点检、故障报修依赖纸质工单与电话沟通，故障平均响应时间超过4小时；历史维修记录散落在各厂区的Excel台账中无法复用，一线工程师遇到疑难故障只能依靠老师傅经验。集团希望建设一套统一的设备智能运维平台，目标是：故障平均响应时间压缩50%以上，设备非计划停机率下降30%，并将沉淀多年的2万余份维修工单转化为可检索、可问答的知识资产。

软件功能与核心模块： 1、设备物联接入与实时监控：通过MQTT对接PLC与各类传感器，实现温度、振动、电流等12类运行指标的秒级上报、趋势曲线与阈值告警，支持设备档案、点位模型与拓扑关系的统一管理。 2、智能工单全流程闭环：现场扫码报修、系统按技能标签与地理位置自动派单、接单—维修—配件领用—验收评价全流程流转，内置SLA计时与超时逐级升级机制。 3、AI知识问答（RAG检索增强）：将维修工单、设备手册、SOP文档清洗入库并向量化，工程师可用自然语言提问（如"3号线灌装机的封口温度报警怎么处理"），系统返回带原文出处的处置步骤与相似历史案例。 4、备件与预测性维护：备件库存台账、安全库存预警与采购联动；基于设备运行时长与告警频次生成保养计划，并对高风险设备输出劣化趋势提示。 5、运营驾驶舱：面向管理层的多基地设备OEE、故障TOP榜、停机损失、工程师绩效等可视化大屏，支持按厂区/产线/设备类型多维下钻。

业务流程与功能路径：工程师扫码发起报修→系统自动定级派单→维修人员App接单并现场处理、上传照片与更换备件→验收评价自动生成工单知识条目→工单数据回流至知识库并触发同类设备预警，形成"报修—维修—沉淀—复用"的数据闭环。

整体架构与设计思路：采用前后端分离 + 微服务的分层架构。接入层用EMQX承接设备MQTT上报，经规则引擎清洗后写入时序库TDengine（海量点位数据）与MySQL（业务数据）；业务层按"设备、工单、知识库、备件、报表"拆分为Spring Cloud Alibaba微服务，注册配置走Nacos、网关用Spring Cloud Gateway、服务间调用Feign；AI层独立部署Python服务，文档解析（PDF/Word/扫描件OCR）→按语义分段→调用Embedding模型生成向量→存入Milvus向量库，问答时采用"向量召回+BM25关键词召回"双路混合检索，再经ReRank重排后拼接上下文交给大模型生成回答，并强制返回引用出处以抑制幻觉；前端管理端用Vue3+TypeScript+Element Plus+Vite，移动端用工单App（uni-app一套代码同时打包安卓与小程序）；数据大屏用ECharts+WebSocket实时刷新。全链路Kubernetes容器化部署，配合Prometheus+Grafana监控、Jenkins+GitLab CI自动化发布。

我负责的模块与结果：作为技术负责人兼核心开发，我负责整体技术选型与架构设计、物联接入服务的开发，以及AI知识问答服务从0到1的落地（文档解析、向量化、混合检索、Prompt编排与出处回传），并完成了权限体系与多厂区数据隔离的设计。平台上线6个月后：接入设备2.8万余台，日均上报点位数据约1.2亿条；故障平均响应时间由4.2小时降至1.1小时（下降约74%）；设备非计划停机率下降31%；知识库累计沉淀工单与文档3.4万条，AI问答平均命中率（答案被工程师采纳的比例）约86%，一线疑难故障首解率由六成提升至九成。

难点与解决方案： 1、设备数据洪峰写入：12个厂区上万点位秒级上报，初期MySQL直接被写爆。改造为MQTT→Kafka削峰→批量写入TDengine，并按设备类型做降采样与冷热分层，单机写入能力提升数十倍，查询P99从8秒降到300毫秒级。 2、知识库"搜不到"问题：纯向量检索对型号、编号、专有名词不敏感，导致召回率低。改为向量+BM25混合召回并加ReRank重排，对型号类关键词做同义词与别名词典扩展，召回命中率提升约35个百分点。 3、大模型幻觉：模型会编造并不存在的处置步骤。通过在Prompt中约束"仅依据给定资料回答、无依据则明确说明"，并要求回答必须携带文档与工单编号的引用出处，同时把高风险操作（如高压设备）加入人工复核白名单。 4、历史数据脏乱：各厂区Excel字段不统一、日期格式与设备编码混乱。编写规则+AI辅助的清洗映射脚本，统一设备编码主数据，累计清洗历史工单2.3万条，人工校对量减少约80%。