部署上线只完成一半工作，另一半是监控。这篇给出完整生命周期：先埋日志与追踪、再定四组指标、然后设告警阈值，并补上 Agent 场景专属的工具调用与循环监控。

💡 你将学到

部署上线只完成一半工作，另一半是监控。这篇给出完整生命周期：先埋日志与追踪、再定四组指标、然后设告警阈值，并补上 Agent 场景专属的工具调用与循环监控。

📜 目录

• 部署完成只算一半
• 第一步：日志与追踪
• 第二步：四组指标
• 第三步：告警阈值怎么定
• 第四步：Agent 场景补三组
• 第五步：反馈闭环
• 最小可用配置
• 常见问题
• 相关文章

AI模型部署与监控：上线后必须补上的四组指标与告警

部署完成只算一半

模型上线的那一刻，最大的风险不是它答得不够好，而是它变坏了没人知道。上游数据分布变了、模型被供应商悄悄升级了、检索索引重建后召回率下降、外部接口开始变慢——这些都发生在凌晨，第二天早上是用户先发现的。

监控要按顺序做：先有日志和追踪（这是地基），再定指标，最后才谈告警阈值。跳过前两步直接上告警，得到的是没人看的告警风暴。

第一步：日志与追踪

第一天就要有的结构化日志字段：

有 OpenTelemetry 就把每次推理包成一个 span，采样率不必 100%，但错误必须全采。可观测平台方面，开源侧 Langfuse、MLflow 能覆盖多数需求，再配 Prometheus + Grafana 做基础设施指标。

隐私提醒：日志里别原文记录用户输入，需要排查时用哈希或脱敏后的样本。

第二步：四组指标

四组缺一不可。只有性能指标，会出现"系统很快但答得很烂"；只有质量指标，会在成本失控时毫无察觉。

第三步：告警阈值怎么定

阈值不能拍脑袋，要用自己前几周的数据当基线。经验上的起点：

关键原则：告警要少而准。每加一条告警，就要问"半夜响了我能做什么"，答不上来的先不设，改成日报。

第四步：Agent 场景补三组

Agent 比普通模型服务多三层不确定性，监控也要跟上：

1. 工具调用成功率：按工具分开统计，某个工具突然失败率上升通常是对端接口或鉴权出问题
2. 循环与步数：单次任务的平均步数与最大步数，卡在重试循环里的 Agent 在无声烧钱
3. 任务完成率：用户发起的任务里有多少真正跑完，而不是超时或半途放弃

这三项直接对应"用户到底有没有拿到结果"，比延迟数字更接近业务真相。

第五步：反馈闭环

• 用户纠错、点踩、人工修改的结果，都存成黄金样例
• 每周跑一次固定评估集，冠军版本 vs 挑战者版本对比
• 漂移持续存在就触发重训或重建索引
• 每次模型升级、提示改动，都要在评估集上留记录

最小可用配置

如果时间只够做一件事：日志 + 延迟 + 错误率，上线第一天就上。漂移检测和评估集可以放到一个月内补齐。反过来，如果先做复杂的漂移检测而没有基础日志，出问题时连排查的入口都没有。

常见问题

Q：开源工具够用吗？ A：多数团队够用。Langfuse、MLflow 覆盖追踪、评估与成本统计；商业工具的主要增量在合规、权限和厂商支持。以各自官网的当前能力为准。

Q：采样率设多少合适？ A：正常请求可以采样（例如 10%），错误、超时、成本异常必须全量记录，否则排查时会缺样本。

Q：怎么判断该重训还是该改提示？ A：输入分布没变、但输出质量下降，多半是提示或模型版本；输入分布明显漂移，才是数据层面的问题，考虑重训或补充检索。

Q：没有真值标签，质量怎么监控？ A：用代理指标：用户点踩率、任务完成率、答案引用命中率、人工每周抽检几十条。代理指标不完美，但能提前发现退化。

相关文章

• AI Agent监控2026：生产环境Agent的追踪、Token成本与故障检测
• AI可观测与评估工具2026：抓住静默失败的监控栈
• LLM RAG 可观测性 2026：用开源工具盯住 Token、延迟和回答质量

❓ 常见问题

What is the minimum monitoring setup?

Logs + latency + error rate on day one; drift and evals within a month.

Open-source or paid?

Langfuse and MLflow cover most needs free; commercial tools add compliance and support.