AI 发现与准确度 — 引擎发现的问题与人留下的判断
时序引擎不等用户发问，会自行发现问题并记录为"发现"。 协作助手接收到后，紧急的立即通知， 其余的在早上汇总展示，需要人工判断的则作为提案卡片呈现。人在提案中留下的判断，用来重新衡量 AI 的准确度， AI 据此自行修正判定基准。
엔진이 발견을 적는다 (설비 이상 · 오더 목표 미달 · 데이터 끊김 …)
→ 코파일럿이 1분마다 받아 온다
→ 급함 · 높음은 즉시 알림 / 나머지는 아침 브리핑 카드 / 판단이 필요하면 AI 제안 카드
→ 사람이 제안에서 무시(사유) · 수락/거절 · 효과를 남긴다
→ 그 표시로 정확도를 재고, 설비별 판정 기준을 스스로 조정
本文档中的任何按钮都不会控制设备或改变订单·排程。AI 自行改变的 只有一项：异常判定基准（各设备的传感器阈值）。
«报表 › AI 准确度»标签页、监控界面（/watch）中的 AI 发现·注意设备·报警架·维修后确认，异常诊断运营控制台中的AI 判定（正确·误报·不确定）与
漏报举报、待验证（/review），在新界面中均不存在。人工留下的判断统一汇聚到提案一处，相关数据在管理控制台和自动化报告中查看 — 见下文。
AI 发现去哪里了
没有单独汇总查看 AI 发现的界面。发现会根据种类和紧急程度进入以下位置。
| 发现 | 去向 |
|---|---|
| 设备异常 | 提案 › 待办 › 突发中的待确认异常。严重度高时会上升为事件 |
| 紧急或严重度高 | 即时通知 — 屏幕通知·推送，以及已配置时的邮件·Slack。每次按原因设备各发一条 |
| 其他 | 晨间简报卡片 — 每天凌晨（默认 05:00）按原因设备汇总，在提案 › 计划中以一张卡片呈现 |
| 订单目标未达·延误恢复方案·故障风险 | 与上述分开，在提案 › 计划中以AI 提案卡片呈现 → AI 提案卡片 |
- 同一发现在同一级别只通知一次。严重度上升或紧急标记开启时会再次通知。
- 也可以在问答中询问「帮我整理一下当前开放的 AI 发现」来获取列表 — 发现列表工具（
list_findings）初始即已 开启（2026.10 再发布（2026-10-20）） → 时序洞察工具 - 尚未通过验证的影子判定，不会出现在通知·提案·问答的任何一处 — 见下文«影子»。
发现的种类
| 种类 | 内容 |
|---|---|
| 设备异常 | 传感器·OEE·RAM·能耗与平时不同 |
| 订单目标未达 | 预计进行中的订单在计划结束前无法达到目标数量 |
| 数据中断·数据质量问题 | 数值未传入，或传入的数值异常（非设备问题而是数据问题） |
| 连锁停机 | 前端设备停机导致后端设备跟随停机 |
| 故障风险 | 近期内可能发生故障 |
| 预计达到极限值·预计电力峰值 | 按当前趋势发展将触及极限·峰值 |
| OEE 下降·不良率异常信号·换型作业延误 | 生产指标方面的发现 |
| 零件延误传播·延误恢复方案 | 零件延误波及排程及其恢复方案 |
| AI 配置变更 | AI 自行更改基准的记录 |
设备异常由既有的异常检测与 AI 发现按相同规则判定。为避免同一异常被重复通知，
默认情况下（anomaly.source=both）由异常检测方发出通知，AI 发现中的设备异常仅用于对照比较。
若运营者切换为 findings，则由 AI 发现方发出通知，此时低·中等级别的设备异常不会即时通知，而是进入晨间简报。
今日优先查看的设备
引擎会为每个站点维护注意设备排名 — 根据开放发现·健康评分·24小时趋势·设备重要度打分（0~100）并排序， 同时给出三项理由及相较昨日的排名变化。没有专门的排名表界面，**在问答中询问「今天要优先查看哪些设备？」**即可得到同样排名的回答 （该工具默认开启）。
- 数据中断等数据质量问题不计入评分。
- 设备重要度（致命·重要·一般·较低）由管理控制台的设备重要度等级设定。
通知蜂拥而至时 — 抖动与洪流
同一设备·同一种类在 60 分钟内达到第三次即时通知时，该通知会附带「[抖动 3次/60分钟]」标记，此后不再通知（抖动）。 若某站点 10 分钟内即时通知超过 10 条，则不再逐条通知，而是发送一条「通知洪流」并将其余汇总呈现（洪流）。 无论哪种情况，记录行与发现本身都会保留。**致命设备的高·紧急通知不会被抖动·洪流所掩盖。**相关数值为默认值，可通过配置调整。
可设置期限与理由暂停通知的报警架、以及汇总查看已暂停通知的界面，在新界面中均不存在。已设置的暂停期满后会自动解除。
抖动·洪流的基准数值位于系统设置的 alert.chatter.count · alert.chatter.window.min · alert.flood.threshold · alert.flood.window.min。
人留下的判断
判断在提案的详情中留下 → 提案
| 判断 | 位置 | 值 | 用途 |
|---|---|---|---|
| 忽略原因 | 待确认异常的忽略 | 安装·换型作业中·设备停机·待机中·维护中·传感器问题·其他 | 将该异常标记为误报。同一卡片下的关联异常会一并标记。作为设备级精度与阈值调整的依据 |
| 接受·拒绝 | AI 提案卡片的AI 提案判断 | 接受 / 拒绝（已处理·无需处理·提案有误·其他） | AI 提案的成绩。«已处理»会触发维修后自动确认 |
| 效果 | 已接受的提案 | 有效·无效·尚不确定（+备注） | 供 AI 选择下一个提案时参考 |
| 诊断判定·实际原因 | 事件的结果记录 | 诊断正确·诊断错误 / 机械·电气·工艺·操作·其他（均为可选） | 管理控制台 回答质量 › 诊断准确度 |
| 处理方案拒绝原因 | 待批准事件的拒绝 | 诊断错误·措施不合适·已处理·现在无法执行（资源·日程）·并非异常（误报）·其他 | «诊断错误»记为诊断判定«错误»，«并非异常（误报）»将该事件记为误报 → 提案 — 处理方案审核 |
- 判断仅做记录 — 点击不会关闭通知，也不会改变设备·订单·排程。
- 若不确定，请勿随意忽略。凭猜测选择的原因会扭曲准确度。效果不明时请保留为尚不确定。
- 这些标记可通过公开 API
GET /api/v1/ai-feedback获取 → API 对接指南
有两项标记由服务器自动添加，无需人工点击。
| 自动标记 | 内容 |
|---|---|
| 停机·故障规则 | 每小时对照当时设备是否实际发生停机·故障，标记正确·误报·漏报（accuracy.rule.enabled）。若停机·故障开始时前后 5 分钟内无异常判定，则标记为漏报。与人工标记分开单独统计 |
| 维修后自动确认 | 处理后经过规定时间，标记效果已确认·无效果·无法判断 → 异常检测·事件处理 |
人工对异常标记«正确»或举报 AI 漏报的栏位，在新界面中均不存在。人工留下的只有上表中的五项（忽略原因·接受/拒绝·效果·诊断判定·处理方案拒绝原因）， 正确·漏报由上述«停机·故障规则»自动标记。
准确度在哪里查看
«报表 › AI 准确度»界面已被移除。与准确度相关的数据在以下四处查看。
| 内容 | 位置 | 对象 |
|---|---|---|
| 各设备阈值调整的进度·原因·最近判断 | 管理控制台准确度调优（/admin/tuning） | 管理员 + 拥有«阈值调整晋升·回退»权限者 |
| AI 回答质量的定期测试评分（最近 90 天） | 管理控制台回答质量（/admin/quality） | 管理员 |
| 事件 AI 诊断的诊断准确度 — 人工判定的正确率（30 · 90 · 180 天），按异常类型 · 模型 · 设备 · 周 · 实际原因 | 管理控制台回答质量（/admin/quality）下方一节 | 管理员 |
| 过去 30 天 AI 异常判定的准确程度 — 正确·误报·漏报·精度汇总及精度较低的设备 | 自动化模板**«AI 准确度检查»** — 报告（默认每周一 09:00） | 创建该自动化的人及接收角色（默认为厂长） |
-
处理措施的成绩（验证通过·复发）位于提案 › 已完成标签页顶部一行。
-
准确度调优·回答质量界面的具体栏位见协作助手管理控制台（诊断准确度见回答质量）， «AI 准确度检查»见用例 — 自动化。
-
基准数值与计算方法见准确度·基准。
-
«AI 准确度检查»报告中收录的仅为汇总数据及精度最低的前十台设备（限于本人设备范围内，样本不足时标注«样本不足»）。查看全部设备标记率·误报原因· 学习中设备的表格界面，在新界面中均不存在。
准确度的统计方式
以下为服务器按设备统计的方式 — 即便界面变化，计算方式保持不变。
| 值 | 含义 |
|---|---|
| 精度 | 正确 ÷（正确 + 误报）。人工标记计算的结果与停机·故障规则计算的结果分开统计 |
| 漏报 | 按来源分别统计 — 如停机·故障开始时前后 5 分钟内无异常判定的事件等 |
| 标记率 | 已标记行数 ÷ 判定行数 — 数值偏低时不可信赖精度数据 |
| 误报原因 | 准备·待机·维护·传感器·其他 |
标记不足 10 件时不输出精度，而是标注为「样本不足」。因为少量样本得出的百分比接近随机结果。 要获得有效数值，需要在现场持续留下判断。
事件的诊断准确度（回答质量画面）规则不同 —— 判定不足 20 件时会附上「样本不足」，但比率照常显示。
学习中·无法判定
新设备或长期停机的设备，在各标签建立基准之前不会产生评分。
| 状态 | 含义 |
|---|---|
| 无法判定 | 所有标签均处于学习中 — 不进行异常判定 |
| 学习中 | 仅部分标签处于学习中 — 其余标签照常判定 |
| 判定失败 | 引擎未能对该设备打分（与学习无关 — 如推理故障等） |
🔴 **提案中没有异常，并不代表设备正常。**处于无法判定状态的设备即便存在异常，也不会作为待确认异常被提出。 剩余时间只能按引擎提供的信息了解，无法确知时标注为«不确定» — 绝不臆测。
设备级阈值自主调整
AI 利用人工标记和停机·故障规则，自行调整各设备的传感器阈值。被改变的 只是判定基准本身，不会对设备·工艺做任何操作。
매일 밤 지난 3일로 후보 평가 → 더 나은 값이 있으면 그림자 3일
→ 통과하면 승격 → 7일 감시 → 나빠지면 자동 되돌림 (연속 2번이면 그 설비 일시정지)
- 默认模式为auto（无需人工干预自动晋升）。propose模式下，通过影子验证的数值 需等待管理员晋升。off模式下则停止调整（已使用的数值保持不变）。
- 标记不足时不会做任何改动（«样本不足»）。
- 在管理控制台准确度调优中可按设备查看«影子第N天·准备晋升·应用中·观察第N天·已停止»状态及阈值·原因·最近判断， 并可点击晋升·回退·恢复。
影子 — 向现场发布前仅作记录
AI 判定中尚未通过验证的部分（设备传感器异常通知·短期故障风险）会以影子状态运行 — 进行判定但仅做记录，
不会出现在通知·提案·问答中。可在管理控制台现场通知预览（/admin/field-modes）中查看以影子方式记录的发现（最近 48 小时），
若误报不多，可填写理由后切换为现场启用 → 协作助手管理控制台
旧版中让人工对影子判定标记正确·错误的«待验证»界面，在新界面中已不存在。权限«影子判定审核»仍保留在权限组中，但新界面中已无使用之处 → 权限
管理员设定项
| 内容 | 位置（管理控制台） |
|---|---|
| 设备重要度（致命·重要·一般·较低）— 修改时须填写备注 | 设备重要度等级 |
| 影子 ↔ 现场 — 将判定功能开放到现场（须填写理由） | 现场通知预览 |
| 阈值调整的晋升·回退·恢复 | 准确度调优 |
| 全局数值与开关 | 系统设置 — 见下表 |
| 设置项 | 默认值 | 含义 |
|---|---|---|
finding.enabled | true | 接收 AI 发现与晨间简报 |
finding.repair.enabled | true | 维修后自动确认 |
anomaly.source | both | 设备异常通知由谁发出 — pipeline · both · findings |
attention.enabled | true | 注意设备排名 |
accuracy.rule.enabled | true | 停机·故障规则对照 |
anomaly.tuning.mode | auto | 设备级阈值自主调整 — auto · propose · off |