AI诊断分析 # 故障诊断分析功能实现逻辑 —— 答辩版 工业智能运维决策平台 · 核心功能模块答辩---## 第1页 · 项目背景与问题### 行业痛点 工业设备故障诊断长期依赖资深专家经验存在三大问题| 痛点 | 现状 | 影响 ||------|------|------|| 知识孤岛 | 设备文档分散存储故障时难以快速检索 | 诊断效率低平均耗时数小时 || 经验依赖 | 高水平专家稀缺新手无法独立判断 | 人才瓶颈无法规模化 || 信息陈旧 | 故障知识静态无法获取最新行业方案 | 诊断准确性受限 |### 本项目目标**将大语言模型 RAG 技术引入工业运维实现**- 自然语言输入故障现象 → AI 自动检索相关文档 → 联网补充最新知识 → 生成专业诊断报告- 核心指标检索精度 ≥ 0.7诊断响应 ≤ 30s支持 3 类工业设备---## 第2页 · 技术方案总览┌──────────────────────────────────────────────────────────────┐│ 故障诊断系统架构 │├──────────────────────────────────────────────────────────────┤│ ││ ┌──────────┐ POST /diagnose ┌──────────────────┐ ││ │ Vue 3 │ ──────────────────────→│ Spring Boot │ ││ │ 前端交互 │ ←──────────────────────│ FaultRecordCtrl │ ││ └──────────┘ 诊断结果 JSON └────────┬─────────┘ ││ │ ││ ┌────────────────────────────┼──────┐ ││ │ FaultRecordService │ │ ││ │ │ │ ││ │ ┌──────────────────────┐ │ │ ││ │ │ ① RAG 检索 (向量匹配) │ │ │ ││ │ │ ② 历史运维 故障查询 │ │ │ ││ │ │ ③ 拼接 5 部分 Prompt │ │ │ ││ │ │ ④ 大模型诊断 │ │ │ ││ │ │ ⑤ 结果存 MongoDB │ │ │ ││ │ └──────────────────────┘ │ │ ││ └────────────┬───────────────┘ │ ││ │ │ ││ ┌─────────────────┐ ┌───────┴──────┐ ┌──────────┐ │ ││ │ MongoDB │ │ QwenChatModel│ │ 内存向量库│ │ ││ │ 文档/报告/故障 │ │ qwen-plus │ │ Embedding │ │ ││ │ 持久化存储 │ │ 联网搜索开启 │ │ Store │ │ ││ └─────────────────┘ └──────────────┘ └──────────┘ │ ││ │└──────────────────────────────────────────────────────────────┘---## 第3页 · 核心创新RAG检索增强生成### 为什么不用纯大模型| 方案 | 问题 ||------|------|| 纯大模型 | 不了解企业内部设备文档易幻觉编造 || 微调模型 | 成本高、周期长、文档更新需重新训练 || **RAG本方案** | ✅ 零训练成本 ✅ 文档即时生效 ✅ 回答可溯源 |### RAG 实现原理工程师上传的设备文档PDF/Word/Txt│▼┌──────────────────────────────┐│ DocumentSplitters.recursive │ ← 文档分块500 token/块│ (重叠 50 token 防语义断裂) │└────────────┬─────────────────┘▼┌──────────────────────────────┐│ QwenEmbeddingModel │ ← 向量化文本 → 768维向量└────────────┬─────────────────┘▼┌──────────────────────────────┐│ InMemoryEmbeddingStore │ ← 向量存储内存└──────────────────────────────┘当故障发生时故障现象 → QwenEmbeddingModel → 向量 → 余弦相似度匹配→ 返回 Top 3 最相关文档片段相似度 ≥ 0.7→ 作为大模型诊断的参考资料### 为什么选内存向量库| 考量 | 选择 ||------|------|| 场景 | 工业文档量有限百份级别无需分布式 || 性能 | 内存检索 10ms满足实时性 || 部署 | 零外部依赖系统自包含 || 维护 | 重启自动全量重建保证一致性 |---## 第4页 · 诊断 Prompt 工程### 设计思路 并非简单把故障现象丢给大模型而是**结构化注入三重知识**┌──────────────────────────────────────────┐│ 诊断 Prompt 5 层结构 │├──────────────────────────────────────────┤│ ││ ① 角色设定 ││ 资深的工业故障诊断专家 ││ → 限定回答风格专业、规范 ││ ││ ② 设备知识RAG 检索 ││ 从向量库匹配的 Top 3 文档片段 ││ → 提供该设备相关的操作规程、参数标准 ││ ││ ③ 历史运维报告 ││ 该设备最近一份 AI 生成的运维报告 ││ → 提供近期运行状态、已发现异常 ││ ││ ④ 历史故障记录 ││ 该设备最近一次故障诊断结果 ││ → 避免重复诊断参考已有分析 ││ ││ ⑤ 当前故障信息 ││ 设备类型 故障现象用户输入 ││ → 本次诊断的核心输入 ││ │└──────────────────────────────────────────┘### 容错设计java// 历史报告和故障可能为空新设备无历史数据try { operateStr operateReportRepository...get(0).getContent(); }catch (Exception e) {} // 优雅降级不影响诊断主流程try { faultStr getFaultsByDeviceId(deviceId).get(0).getDiagnoseResult(); }catch (IndexOutOfBoundsException e) {}---## 第5页 · 技术选型对比### 大模型选型| 候选 | 优点 | 缺点 | 是否选用 ||------|------|------|----------|| GPT-4 | 综合能力强 | 海外 API工业数据安全风险成本高 | ❌ || 开源模型 | 本地部署可控 | 需要 GPU 资源推理速度慢 | ❌ || **阿里千问 Qwen-Plus** | 国内合规、联网搜索原生支持、LangChain4j 官方适配 | — | ✅ |### 选型理由1. **合规性**工业数据不出境阿里云国内节点2. **联网搜索**enableSearch(true) 一行代码开启故障诊断可补充最新行业知识3. **框架适配**LangChain4j 社区已有 dashscope 官方模块零封装成本4. **参数调优**temperature0.7 平衡专业性与创造性maxTokens2048 保证诊断报告完整性### 后端框架选型- **LangChain4j** 而非手写 HTTP 调用统一管理 RAG 组件嵌入模型、向量库、检索器内置文档分块策略- **Spring Boot 3** 而非 Python FastAPI团队技术栈统一与 MongoDB 集成成熟---## 第6页 · 数据流与接口设计### API 设计原则| 原则 | 体现 ||------|------|| RESTful | POST 提交诊断GET 查询历史语义清晰 || 原子性 | 一次诊断请求 检索 推理 存储前端一次调用完成 || 幂等性 | GET /faults/{deviceId} 可重复调用无副作用 |### 接口清单POST /api/operate/diagnoseRequest: { deviceId, deviceType, faultPhenomenon }Response: [{ id, deviceId, faultPhenomenon, diagnoseResult, createTime }]SideEffect: 写入 MongoDB fault_records 集合GET /api/operate/faults/{deviceId}Response: [{ id, deviceId, faultPhenomenon, diagnoseResult, createTime }]SideEffect: 无只读查询### 数据存储MongoDB Collection: fault_records{_id: ObjectId, // 自动生成deviceId: device001, // 设备编号deviceType: fan, // 风机/水泵/电机faultPhenomenon: ..., // 原始故障描述diagnoseResult: ..., // AI 诊断结果核心产出createTime: ISODate // 诊断时间戳}---## 第7页 · 实现难点与解决方案### 难点 1文档语义检索精度| 问题 | 检索结果与故障现象不相关 ||------|--------------------------|| 原因 | 文档分块过大导致噪声多过小导致语义不全 || **解决** | recursive(500, 50) — 500 token / 块 50 token 重叠平衡完整性与精度 || 问题 | 低质量片段污染 Prompt ||------|----------------------|| **解决** | minScore0.7 阈值过滤相似度低于 0.7 的片段直接丢弃 |### 难点 2新设备无历史数据| 问题 | 首次诊断时该设备无运维报告和故障记录 ||------|--------------------------------------|| **解决** | try-catch 容错历史数据为空时 Prompt 模板自动跳过对应段落不影响诊断 |### 难点 3大模型联网搜索稳定性| 问题 | 联网搜索可能超时或返回无关内容 ||------|-------------------------------|| **解决** | ① 5 层 Prompt 中 RAG 文档 历史记录 联网搜索结构化优先级 ② Prompt 末尾要求分析专业、步骤清晰约束输出质量 |---## 第8页 · 前端交互设计### 用户体验设计要点故障诊断 Tab 页布局┌─────────────────────────────────────────────┐│ 概览卡片 ││ ┌──────────────┐ ┌──────────────┐ ││ │ 诊断记录 N 条 │ │ AI 智能引擎 │ ││ └──────────────┘ └──────────────┘ │├─────────────────────────────────────────────┤│ 输入区 ││ [设备ID] [风机▾] ││ ┌─────────────────────────────────┐ ││ │ 故障现象描述多行文本placeholder引导│ ││ └─────────────────────────────────┘ ││ [ 诊断故障] ← 有内容前 disabled │├─────────────────────────────────────────────┤│ 结果展示区 ││ ┌─────────────────────────────────┐ ││ │ 故障现象... │ ││ │ ───────────────────────────── │ ││ │ 诊断结果... [导出 PDF] │ ││ └─────────────────────────────────┘ ││ 每张卡片橙色/绿色双色对比一目了然 │└─────────────────────────────────────────────┘### 交互细节| 细节 | 设计意图 ||------|----------|| 按钮 disabled | 未输入故障现象时不可点击防无效请求 || 诊断完成自动清空输入 | 减少操作步骤提升效率 || 结果实时刷新列表 | 无需手动刷新诊断结果即时可见 || 空状态引导 | 无记录时展示插图 提示文字降低认知负担 || 导出 PDF | 诊断结果可离线归档、打印、分享 |---## 第9页 · 系统测试与验证### 测试场景| 场景 | 输入 | 预期行为 ||------|------|----------|| 正常诊断 | device001, fan, 轴承温度100℃振动大 | 返回专业诊断含原因分析 处理建议 || 空输入 | 故障现象为空 | 按钮 disabled提示请描述故障现象 || 无历史数据 | 全新设备首次诊断 | 正常诊断历史报告和故障字段为空 || 无相关文档 | 故障现象与已有文档无关 | RAG 返回空上下文模型依靠自身知识诊断 || 历史查询 | GET /faults/device001 | 按时间倒序返回该设备所有诊断记录 || PDF 导出 | 点击导出 PDF | 生成 A4 格式报告含标题/元信息/现象/结果 |### 性能指标- RAG 检索延迟 10ms内存向量库- 大模型推理≈ 5-15s取决于联网搜索耗时- 端到端响应 30s- 并发支持单机 100 QPSSpring Boot MongoDB 支撑---## 第10页 · 总结与展望### 核心贡献| 维度 | 成果 ||------|------|| 技术创新 | 将 RAG 联网大模型引入工业故障诊断实现知识检索与推理一体化 || 工程实践 | 完整的 Spring Boot Vue 3 MongoDB 全栈实现可直接部署 || 容错设计 | 历史数据缺失优雅降级不影响核心诊断流程 || 用户体验 | 自然语言交互、实时反馈、PDF 导出降低使用门槛 |### 未来方向短期 ──→ 报告/诊断 PDF 导出已实现│中期 ──→ 设备管理模块、告警规则引擎、趋势对比分析│长期 ──→ 用户权限体系、WebSocket 实时推送、多模态故障诊断图片文本---## 附录 · 核心代码清单| 文件 | 路径 | 职责 ||------|------|------|| App.vue | industrial-ai-frontend/src/ | 前端诊断交互 PDF导出 || FaultRecordController | controller/FaultRecordController.java | 诊断/查询 REST API || FaultRecordService | service/FaultRecordService.java | 诊断引擎核心逻辑 || ChatService | service/ChatService.java | RAG 知识库 向量检索 || Langchain4JConfig | config/Langchain4JConfig.java | 千问模型配置 || FaultRecord | entity/FaultRecord.java | 故障记录实体 || FaultRecordRepository | repository/FaultRecordRepository.java | MongoDB 数据访问 |