AI 服务治理指标：别只盯调用成功率

AI 服务治理指标：别只盯调用成功率

一、成功率太粗了

AI 后端服务上线后，很多看板只放调用量、成功率、平均耗时。它们有用，但远远不够。一次调用成功，不代表回答有用；平均耗时正常，不代表长尾没有问题；调用量上涨，也不一定代表产品价值上涨。

AI 服务治理要把传统后端指标和模型业务指标放在一起看。否则系统可能在工程层面“全绿”，用户体验却已经变差。

二、指标要分四层

flowchart TDA[基础设施指标] --> B[服务指标]B --> C[模型指标]C --> D[业务指标]

监控体系的核心在于分层，通常可拆解为四个维度：底层的基础设施指标，涵盖 CPU、内存、连接池及队列长度；中间层的服务指标，重点关注 QPS、错误率、P95/P99 延迟以及超时率；模型层的性能指标，如 token 生成量、截断率、拒答率和格式错误率；以及顶层的业务指标，包括采纳率、重试率、用户取消率和付费转化率。

这些指标需要串在同一个 trace 里。只看模型供应商日志，很难知道问题发生在网关、队列、缓存、提示词还是业务服务。

三、结构化埋点要提前设计

type AiCallEvent = {traceId: stringfeature: stringmodel: stringpromptVersion: stringinputTokens: numberoutputTokens: numberlatencyMs: numberresultType: "ok" | "timeout" | "format_error" | "refused"}

埋点字段不需要一开始就很复杂，但必须稳定。后续排查时，最怕今天叫 modelName，明天叫 engine，不同服务字段对不上。

ai_slo:chat_summary:p95_latency_ms: 3000timeout_rate: 0.02format_error_rate: 0.01report_generation:p95_latency_ms: 12000cancel_rate: 0.05

不同功能要有不同 SLO。实时对话和长报告生成不能用同一个延迟目标。SLO 不合理，看板就会变成摆设。

四、质量指标要能抽样复核

模型回答质量不能完全靠自动指标，但可以设计抽样复核流程。比如每天抽取高成本、低采纳、用户重试次数多的请求，进入人工或半自动评审。评审结果再反向标记提示词版本和模型版本。

还要监控格式稳定性。很多后端任务依赖模型输出 JSON，一旦格式错误率升高，业务失败会成倍放大。格式错误应该单独统计，不能混在普通失败里。

成本指标不能脱离效果指标单独看。单次调用成本是降了，但要是采纳率也跟着往下掉，这未必算优化；反过来，高价模型如果只拿去支撑低价值功能，大概率就是资源配错了。更稳妥的做法是，看板按功能去核算“每次有效结果成本”，比如一条最终被用户采纳的摘要，平均到底花了多少钱，而不是只盯着 token 单价。

治理流程上，可以为每个提示词版本建立发布记录。记录包括上线时间、影响功能、预期改进、回滚条件和观察窗口。这样当指标波动时，团队能快速把变化关联到具体版本，而不是在模型、代码和流量之间来回猜。

另外要保留负样本指标。用户删除生成结果、连续重试、手动大幅改写、任务中途取消，都可能说明模型输出没有价值。把这些行为埋到链路里，能比单纯满意度问卷更早发现质量下降。

如果业务允许，还可以把负样本聚合到评测集，下一轮模型或提示词升级前优先回放。线上真实失败样本，比人工构造样本更能暴露系统短板。

五、总结

AI 服务治理指标不能只盯调用成功率，还要覆盖延迟、成本、token、格式、拒答、采纳和业务结果。

指标分层清楚、埋点稳定、SLO 按功能定义，后端团队才能判断 AI 服务是真稳定，还是只是没有明显报错。