我发现一个单一的安全门指标掩盖了 AI 生成解释功能长达一整天的停机。通过将“门控拒绝”和“模型加载失败”视为同一件事，该指标提供了一种虚假的健康感。它记录了四次拒绝和零次成功，但在此期间模型从未运行——这一错误可能导致操作员对故障系统视而不见。
混淆是如何发生的
该功能使用本地语言模型将原始机器逻辑转换为人类可读的句子。下游的安全门会拦截任何违反预定义规则的输出。在生产环境中，我暴露了一个单一的计数器，每当安全门拒绝一个句子时，该计数器就会递增。当无人机记录了四个 AI 解释时，计数器报告了四次拒绝且没有成功的输出。我将其理解为安全门正在履行职责，而不是功能失效。
该计数器掩盖的是一个两阶段故障：
- 模型未运行 – 模型与系统的其余部分共享一台机器。为了节省内存，主机在闲置后会将其卸载。
- 重新加载超时 – 当新的威胁出现时，系统尝试重新加载大约两 GB 的模型数据。重新加载超过了 30 秒的响应超时时间，因此请求超时并返回了空答案。
由于计数器将门控拒绝和超时导致的空答案视为同一事件，仪表板显示“安全门工作正常”，而 AI 功能实际上已经瘫痪。
为什么这很重要
在 AI 驱动的产品中，安全门负责拦截有害或无意义的输出。操作员通过观察安全门的触发频率来判断系统健康状况。当该信号与无关的故障模式合并时，指标就会变成一个“沉默的谎言”：它在服务不可用时反而给人以安心的错觉。
恢复可见性的修复方案
我进行了三项实际的改进：
- 保持模型常驻 – 调整主机以将模型保留在内存中，从而消除重新加载的延迟。
- 延长超时时间 – 扩大响应窗口，以处理偶尔出现的缓慢加载。
- 拆分计数器 – 用四个不同的计数器取代单一的“被安全门拒绝”指标：accepted（已接受）、rejected（已拒绝）、empty response（空响应）和 no answer（无回答）。
第三步被证明是决定性的。与其使用一个可以有多种解读的单一数字，不如通过四部分细分来显示安全门是否处于活动状态、模型是否正在回答，或者请求是否根本没有到达模型。
权衡与反论
下一步需要关注什么
部署 AI 组件的开发人员应审计任何将安全检查与系统级故障混合在一起的聚合计数器。建立详细的历史日志，记录每个请求的路径——模型加载开始、安全门评估、最终结果——可以提供发现隐藏问题所需的溯源数据。
核心总结： 单一的“门控拒绝”指标可能会掩盖失效的 AI 服务；将该指标拆分为其组成事件可以揭示真相，并防止对一个实际上并未正常运行的系统产生错误的信心。