降低误报需要调整阈值而非仅依赖操作员适应
别名: 误报整改 · alarm threshold tuning · deadband
概念解释
降低误报本质上是一个检测和过程工程问题，需要动手去调整触发阈值、死区、延迟时间、状态判定逻辑，或者干脆更换质量更好的传感器；只是简单要求操作员"习惯就好""自己学会分辨"，其实是把本该由工程手段解决的过滤工作，转嫁给了操作员本就有限的注意力资源。这条讨论的是该从哪些具体的工程手段入手去真正降低误报率，脱敏这个后果怎么形成、信任损耗还包括哪些方面、疲劳的危害什么时候才显现，分别是同组另外三叶的内容。
机制
阈值如果设置得离正常波动的噪声太近，就会被正常噪声反复触发；如果没有配置滞回（也就是触发和恢复用不同的阈值），数值在临界点附近来回摆动时就会不停地抖动报警；如果判定逻辑没有按运行模式区分，那么在启停这类正常的工况切换过程中也会被误判成异常而触发。这三种修正手段——调阈值、加滞回、按模式区分逻辑——每一种都是在灵敏度和响应延迟之间做权衡，调得越保守就越不容易误报，但也就越可能真的漏掉一个本该被发现的异常，所以任何一次调整都必须同时看漏报率有没有跟着上升。
边界
单纯把阈值往不敏感的方向调，可能会把变化缓慢或者幅度很小但其实很重要的故障过程给隐藏掉，看起来报警少了，实际上是该报的也不报了；另外，反复出现的报警也可能真实反映的是设备本身反复出问题，而不是算法参数设置得不对，这种情况下该修的是设备而不是阈值。涉及安全的限值更是不能因为报警让人烦就随意挪动位置，这类限值的调整必须走独立的安全评审，不能和普通的误报整改混在一起处理。
怎么落地
用带标注的历史数据画出命中率、误报率和提前预警时间三者之间的权衡曲线，先排查并修复传感器本身的问题和状态判定逻辑的缺陷，确认这两块没问题之后，再去调整阈值、死区和延迟这几个参数。每一次调整之后，都要用独立于原始触发场景之外的真实故障案例去验证有没有引入新的漏报，同时明确记录能够安全响应这类故障所需要的最短窗口，确保调整后的参数仍然留有足够的响应时间。