LLM 上线后，告警不能只盯异常

LLM 功能上线后，接口没报错、用户还在点击，回答却可能已经变差，或者悄悄破坏下游代码依赖的输出格式。dev.to 的这篇文章提出：生产告警要分别观察回答质量和指令遵循情况，并关联具体请求的执行追踪，让排查提示词、模型和工具调用时有据可查。

目前能确认什么

HTTP 请求成功，不代表 LLM 完成了任务。

节选区分了两类故障。质量退化可能表现为用户负面反馈增多，或不同模型之间的错误率出现差异；指令遵循失败则包括 JSON 必填字段缺失、输出超长、命中禁止模式等。两者不能合成一个总分：格式正确的回答可能没用，内容流畅的回答也可能无法被程序解析。

文章建议，能机械检查的约束先用校验器处理；语气、引用要求等较模糊的规则，再抽样交给 LLM 评判。上线前评估检查历史样例，生产监控则要观察当前请求、用户输入和工具返回。

告警还应附上出错样本的追踪标识（trace_id），串起模型、提示词版本、工具输入输出和 token 用量。排查时先读工具返回，再判断问题出在哪。延迟和每次成功任务的成本，也应纳入监控。

我的判断

对需要解析模型输出的程序，最容易补上的缺口是格式校验失败率。请求返回成功，但 JSON 无法消费，这已经是业务故障，不能只留一条日志。

对多步 Agent，更关键的是保留完整执行路径。仅凭耗时上涨就改提示词，很难分清是模型输出变长、工具变慢，还是重试过多。

先让告警能带你找到一次具体失败，再谈调模型。

节选给出了监控方向，但没有提供适用于所有业务的阈值，也未说明如何可靠判定「任务成功」。质量评判的准确性、抽样比例和误报控制，仍需更多原文内容或实现文档确认，不能把这些建议直接当成现成配置。