传统软件上线后，监控的重点是服务是否可用、接口是否报错、响应是否够快。大模型应用除了这些，还面临一类特殊的问题：服务一切正常、没有任何报错，但输出的质量却在下降。 可能是服务商更新了模型版本，可能是知识库中的文档过时了，也可能是用户开始问一类之前没见过的问题。没有专门的质量监控，这些问题往往要等到用户投诉才会被发现。

为什么大模型应用需要专门的监控

  • 输出不确定：同样的输入可能产生不同的输出，问题不一定能稳定复现；
  • 静默退化：质量下降不会触发错误告警；
  • 外部依赖变化：使用第三方模型服务时，模型更新可能改变应用行为；
  • 成本随用量波动：用户行为变化可能导致成本快速上升；
  • 新型安全风险：提示注入、越狱、敏感信息泄露等需要专门检测。

第一层：调用链追踪

为每一次用户请求记录完整的处理过程：

  • 用户输入和最终输出；
  • 使用的提示词版本、模型名称和参数；
  • 检索到的文档及其相关性分数；
  • 工具调用的名称、参数和返回结果；
  • 每个环节的耗时和 Token 消耗；
  • 用户和会话标识（注意隐私保护）。

完整的调用链是排查问题的基础。当用户反馈一个错误回答时，可以快速定位是检索没找到资料、模型理解错误，还是工具返回了错误数据。Agent 应用尤其需要完整的轨迹记录，参见 AI Agent 常见故障模式。

记录日志时要遵守隐私和数据保护要求，对敏感信息进行脱敏，并设置合理的保存期限。

第二层：质量信号

用户显式反馈

点赞、点踩、评分、纠错提交等。反馈率通常不高，但负面反馈非常有价值。

用户隐式行为

  • 用户是否重新生成了回答；
  • 用户是否大幅修改了 AI 生成的内容；
  • 用户是否在短时间内换一种方式问同样的问题；
  • 用户是否转向人工服务；
  • 会话是否在 AI 回答后立即结束。

这些行为信号往往比显式反馈数量更多，也更能反映真实的满意度。

自动质量评估

对线上输出进行抽样，用规则或大模型评委进行自动评估，例如检查回答是否基于检索内容、是否包含不当承诺、格式是否正确，参见 LLM-as-a-Judge。

人工抽检

定期抽取一定比例的对话进行人工审核，特别关注负面反馈和自动评估标记出的可疑案例。

第三层：性能与成本

  • 延迟：首 Token 时间和总响应时间的分布，特别是慢请求的比例，参见降低大模型应用延迟；
  • 错误率：模型服务超时、限流、格式解析失败、工具调用失败的比例；
  • Token 用量：按功能、按用户统计的输入和输出 Token；
  • 成本：每日成本、单次请求平均成本、单个用户成本分布，识别异常的高成本请求，参见大模型 API 成本优化。

第四层：安全监控

  • 输入检测：识别疑似提示注入、越狱尝试的输入；
  • 输出检测：检测输出中的敏感信息、违规内容、异常链接；
  • 行为异常：Agent 的异常工具调用模式，例如突然大量访问数据或向陌生地址发送内容；
  • 滥用检测：异常高频的调用、批量的自动化请求。

参见提示注入攻击与防御。

告警设计

  • 设置基线：先观察一段时间的正常指标范围，再设定告警阈值；
  • 关注变化：除了绝对阈值，还要关注指标的突然变化，例如负面反馈率比上周同期明显上升；
  • 分级告警：严重问题（如服务不可用、安全事件）即时通知，一般问题（如质量指标轻微下降）汇总报告；
  • 避免告警疲劳：告警过多会让团队忽视真正的问题，定期清理无效告警。

闭环：从监控到改进

监控的价值在于推动改进：

  1. 定期复盘：每周查看质量指标、负面反馈和典型问题案例；
  2. 问题归类：区分知识缺失、检索失败、提示词问题、模型能力问题；
  3. 补充评测集：把线上发现的问题案例加入评测集，参见如何构建评测集；
  4. 修复验证：修复后通过评测和线上指标确认效果；
  5. 关注外部变化：使用第三方模型时，关注服务商的模型更新通知，必要时固定模型版本。

小结

大模型应用的监控需要在传统的可用性监控之上，增加调用链追踪、质量信号、成本和安全监控。用户的显式反馈和隐式行为、自动评估和人工抽检相结合，才能及时发现静默的质量退化。把监控发现的问题持续反馈到评测集和迭代流程中，形成闭环，是大模型应用长期保持高质量的关键。