质量指标要有基线
每周用固定评测集抽跑一轮，记录成功率与错误类型，与上线基线对比。质量下滑通常先体现在特定类型问题上，按类型拆分才能定位是数据、提示词还是模型版本；混在一起看只会得出模棱两可的结论。
接管与投诉更灵敏
人工接管率、转人工原因分布、用户投诉关键词是业务侧最灵敏的信号。接管率突然上升，往往意味着知识过期或模型行为变化，比技术指标更早暴露问题；值班人员应能直接看到这些数据，而不必等周报。
性能与容量水位
盯 P95 延迟、超时率、队列长度与并发水位，设置分级告警。容量水位建议留出余量，接近上限前就要扩容或限流，不要等超时投诉出现；扩容决策还要与采购周期一起考虑，避免计划赶不上变化，这类阈值要按季节与促销周期校准。
成本与用量归集
按场景统计单位任务消耗与月度总额，设预算阈值告警。异常增长常来自上下文变长、重试增多或某入口被刷，需要能按标签下钻；否则只能看到总额上涨，找不到具体原因，优化也就无从下手，分账粒度不宜过细。
变更登记与灰度
模型版本、提示词、检索配置、知识库批次都要登记版本号与生效时间，重大变更走灰度并保留回滚。没有登记，故障复盘只能靠猜；登记要轻量，否则一线会绕过流程，记录反而失真，登记表要与发布流程绑定，避免线下补录。
适用与不适用
适合谁
- 已上线、需要稳定运行并有一线配合的业务团队
- 多场景共用一套模型、需要分账的企业
- 准备把试点转为正式服务的项目组
不适合谁
- 还在选型阶段、没有运行数据的项目
- 不接受变更登记与灰度流程的团队
典型场景
某电商的售后助手在大促前一周接管率异常上升。值班人员按标签下钻，发现某类退换货政策文档刚更新但知识库未同步，检索仍返回旧版本。补齐同步流程并加文档变更告警后，接管率回落，团队把该检查加入上线前清单。
可执行步骤
- 确定四组指标与各自基线，写入运维手册与值班清单，并指定指标负责人
- 配置分级告警与接收人，明确响应时限与升级路径，避免告警无人认领，并定期复核
- 建立变更登记表，记录版本、生效时间与回滚方式，由变更人签字确认，作为回滚依据
- 每周抽跑评测集，按月做质量与成本复盘并公开结论，纳入部门例会，形成记录
- 每季度演练降级与回滚流程，记录耗时与问题清单，逐项关闭并复盘，形成闭环
常见坑
- 只监控服务可用性，不看回答质量，问题靠用户投诉才发现，损失已经发生，复盘也只能事后补救，责任也难以界定。
- 指标没有基线，告警阈值凭感觉设定，误报频繁后被忽略，真异常反而漏过，告警机制形同虚设，排查方向随之跑偏。
- 提示词改动不留版本，效果变差时无法定位到具体改动，只能整体回退，试错成本明显上升，问题溯源几乎不可能。
- 成本只看总额不分场景，异常增长无法归因，优化只能凭猜测，预算评审也难以通过，预算约束形同虚设。
自检与验收清单
- 四组指标是否都有基线与告警阈值，是否定期复核
- 告警是否有明确接收人与响应时限，是否演练过
- 模型与提示词变更是否登记版本，能否快速回滚
- 是否每周抽跑评测集并留档，结论是否对内公开
- 降级与回滚是否演练过，耗时与问题是否记录，问题是否关闭
常见问题
小团队也需要这么多指标吗？
可以精简，但质量、延迟与成本三类至少各留一个。哪怕只做每周一次评测抽跑和月度成本对账，也比完全不看好，关键是形成固定节奏，避免问题攒到季度末才处理，也避免告警疲劳后无人响应。
评测集要不要持续更新？
要。业务变化会产生新类型问题，建议每季度补充样本并复核旧样本是否仍有效。评测集长期不更新会逐渐失去区分能力，评测结论也会变得乐观，无法反映真实体验，团队容易误以为系统稳定。
供应商升级需要重新验收吗？
建议做回归测试而非完整验收：用同一评测集对比升级前后，重点看错误类型与结构化解析率。差异明显时先灰度，确认后再扩大范围，同时保留回退到旧版本的路径，避免上线后被动。