线上怎么发现质量回退？没有标准答案的场景怎么定监控指标？

线上我们会采样一部分请求，用 LLM judge 打分，比如判回答是否有依据、是否答非所问，出一条质量曲线，掉得多就告警。另外也看用户的点踩率和转人工率。发现回退之后，先查最近有没有发版，如果有就回滚，没有的话再看是不是上游模型变了。

方向是对的：有采样判分、有用户信号、有变更排查。所以能过。

它的问题是：顺序反了（先上 judge 后建基础信号）、归因缺一刀（直接跳到「查变更 → 回滚」）、以及没有告警工程（掉多少算掉？按什么维度分组？）。

我分三部分说：指标怎么分层、告警怎么设、分数掉了第一步做什么。

一、指标分三层，而且顺序不能反。

第一层是不需要模型的信号，必须先建全。

• 用户侧：重问率 / 改写后再问一次的比例、复制率、点踩率、会话中途放弃率、转人工率；
• 系统侧：结构化输出解析失败率、工具报错率、超时率、重试率、拒答率、截断率（打到 max_tokens）、上下文超限率。

这一层的价值在于：不需要标注、不需要 judge、不会漂移、成本近乎为零，而且和用户真实不满的相关性通常比任何 judge 分数都高。我认为最被低估的三个是转人工率、重问率、截断率。 硬判据：没把这一层建全就先上 judge 的团队，是在用一把会漂的尺子，量一个从来没测过的东西。

第二层是需要模型但不需要标准答案的。 采样 LLM judge，判有据性（答案有没有超出给定来源）、拒答是否合理、格式是否合规——注意这些都是有参照物的判断，judge 在这类任务上才可靠；判「事实对不对」没有参照物，那是把幻觉转嫁给另一个会幻觉的模型。 工程约束三条：采样（基线约 2%，高风险或刚改过的路由提到 20%）、异步（在响应返回之后跑，绝不进关键路径）、judge 版本钉死（换 judge 之后历史分数不可比，要用新 judge 重跑历史基线）。 还要加一个输入侧的信号：对用户输入做 embedding 聚类，监控有没有出现新簇——新簇通常意味着新意图或新渠道，这是很多质量事故的真正源头。

第三层是业务终审：转化率、工单解决率、人工复核通过率、退款/投诉率。滞后，但唯一真实。

二、告警不是设一个全局阈值。 全局均值是最后才动的东西。真实的质量回退几乎总是先出现在某个渠道、某类意图、或 P95 上。所以告警必须分组设：按渠道 × 意图 × 模型版本分桶，每桶单独看。开篇那种「新渠道占 14% 流量」的情况，在全局曲线上只表现为一点点下滑，在分桶视图里是一条断崖。 阈值上，不用固定绝对值，用相对基线的变化 + 最小样本量门槛：某桶样本数不足就不告警（否则小桶天天误报）；变化幅度要超过该桶历史波动的若干倍才告。

三、【最重要】分数掉了，第一步不是回滚，是切一刀。 线上分数的分子分母都在动，所以它天然分不出「系统变差」和「输入变难」。解法是造一个分母不动的参照物——金丝雀集：

• 20–50 条固定输入，覆盖主要意图和高风险场景；
• 在生产环境、走同一条链路、同一份 prompt、同一个 judge，每小时跑一遍，单独出一条曲线。

然后对照看：

• 线上掉、金丝雀不动 → 输入分布变了，系统没坏。该做的是补覆盖面、看新流量是什么，而不是回滚。
• 线上掉、金丝雀也掉 → 系统真的变了，再往下切：模型小版本？prompt？检索索引？工具依赖？

我们真踩过一次反例：judge 分数掉 5 个点，值班同学回滚了模型、又回滚了 prompt，分数都没回来，折腾半天才发现是市场部前一天接了个新渠道，那批用户的问题平均长 1.8 倍且集中在退款政策。系统一点没坏，而那半天里两次无谓的回滚还引入了新的缓存不一致。 金丝雀集的成本极低（几十条 × 每小时），但它把这半天压缩成一次看板对比。这和 RAG 排障里「手工把正确文档塞进 prompt」是同一个手法：固定住一个变量，把问题一分为二。