AI 服务治理指标别只盯调用成功率一、成功率太粗了AI 后端服务上线后很多看板只放调用量、成功率、平均耗时。它们有用但远远不够。一次调用成功不代表回答有用平均耗时正常不代表长尾没有问题调用量上涨也不一定代表产品价值上涨。AI 服务治理要把传统后端指标和模型业务指标放在一起看。否则系统可能在工程层面“全绿”用户体验却已经变差。二、指标要分四层flowchart TD A[基础设施指标] -- B[服务指标] B -- C[模型指标] C -- D[业务指标]基础设施指标包括 CPU、内存、连接池、队列长度。服务指标包括 QPS、错误率、P95/P99 延迟、超时率。模型指标包括 token、截断率、拒答率、格式错误率。业务指标包括采纳率、重试率、用户取消率和付费转化。这些指标需要串在同一个 trace 里。只看模型供应商日志很难知道问题发生在网关、队列、缓存、提示词还是业务服务。三、结构化埋点要提前设计type AiCallEvent { traceId: string feature: string model: string promptVersion: string inputTokens: number outputTokens: number latencyMs: number resultType: ok | timeout | format_error | refused }埋点字段不需要一开始就很复杂但必须稳定。后续排查时最怕今天叫modelName明天叫engine不同服务字段对不上。ai_slo: chat_summary: p95_latency_ms: 3000 timeout_rate: 0.02 format_error_rate: 0.01 report_generation: p95_latency_ms: 12000 cancel_rate: 0.05不同功能要有不同 SLO。实时对话和长报告生成不能用同一个延迟目标。SLO 不合理看板就会变成摆设。四、质量指标要能抽样复核模型回答质量不能完全靠自动指标但可以设计抽样复核流程。比如每天抽取高成本、低采纳、用户重试次数多的请求进入人工或半自动评审。评审结果再反向标记提示词版本和模型版本。还要监控格式稳定性。很多后端任务依赖模型输出 JSON一旦格式错误率升高业务失败会成倍放大。格式错误应该单独统计不能混在普通失败里。成本指标也要和效果指标放在一起看。单次调用成本下降如果采纳率也下降未必是优化高价模型如果只服务低价值功能也可能是资源错配。看板最好按功能计算“每次有效结果成本”例如一次被用户采纳的摘要平均花费多少而不是只看 token 单价。治理流程上可以为每个提示词版本建立发布记录。记录包括上线时间、影响功能、预期改进、回滚条件和观察窗口。这样当指标波动时团队能快速把变化关联到具体版本而不是在模型、代码和流量之间来回猜。另外要保留负样本指标。用户删除生成结果、连续重试、手动大幅改写、任务中途取消都可能说明模型输出没有价值。把这些行为埋到链路里能比单纯满意度问卷更早发现质量下降。如果业务允许还可以把负样本聚合到评测集下一轮模型或提示词升级前优先回放。线上真实失败样本比人工构造样本更能暴露系统短板。五、总结AI 服务治理指标不能只盯调用成功率还要覆盖延迟、成本、token、格式、拒答、采纳和业务结果。指标分层清楚、埋点稳定、SLO 按功能定义后端团队才能判断 AI 服务是真稳定还是只是没有明显报错。