上线后怎么发现模型效果变差了？
一句话回答
效果变差通常有几类原因：用户问题的分布变了、知识库过期、上游模型更新、自己的 Prompt 或代码改动。发现手段分两类：一类是被动的信号，比如点踩和重新生成变多、会话变长、转人工增加、格式错误率上升；另一类是主动检测，定期抽样线上对话用模型打分，每天用固定的评测集跑一遍。再配合固定模型版本、记录每次变更，指标异常时就能很快定位是哪一类原因。
详细解析
为什么会变差
| 原因 | 例子 | 特点 |
|---|---|---|
| 问题分布变化 | 新功能上线、做活动带来了新类型的问题，用户群体变了 | 评测集没覆盖，离线分数不变，线上变差 |
| 知识过期 | 政策、价格、产品文档更新了，知识库没同步 | 回答很自信，但内容过时 |
| 上游模型变化 | 用了会自动指向新版本的模型别名，供应商更新后行为变了 | 自己什么都没改，效果却变了 |
| 自身改动 | 改了 Prompt、调了检索参数、改了工具定义、升级了依赖 | 时间点和某次发布对得上 |
| 依赖服务异常 | 检索服务超时后降级、工具接口返回的格式变了 | 通常伴随错误率的变化 |
能观察到的信号
| 类别 | 信号 |
|---|---|
| 显式反馈 | 点踩率、负面的文字反馈 |
| 隐式行为 | 重新生成率、换个说法再问、会话轮数变长、中途停止、复制率下降 |
| 业务结果 | 转人工率上升、问题解决率下降 |
| 技术指标 | JSON 解析失败率、工具调用错误率、拒答比例、输出长度的分布、截断比例 |
| 质量评分 | 线上抽样的模型评分、人工抽检的结果 |
| 输入分布 | 新类型的问题增多；检索结果的最高相似度整体下降，说明很多问题在知识库里找不到匹配 |
单个信号的噪声都很大，要和历史同期对比，并按功能、模型、Prompt 版本拆开看。
主动检测
- 线上抽样评估：每天按功能分层抽样一批对话，用固定的评委模型和细则打分，看分数的趋势；低分样本进入人工复核队列，点踩的对话单独全量看
- 固定评测集定时跑：即使没有任何改动，也每天用线上配置跑一遍固定评测集。分数突然下降而自己没改东西，多半是上游模型或依赖变了
- 固定模型版本：用带日期或版本号的模型名，不用会自动升级的别名；升级模型当作一次改动，走回归测试和灰度（见 回归测试）
- 变更时间线：Prompt、模型、知识库、代码的每次变更都记下时间，指标异常时先对照时间线
- 知识库新鲜度：监控文档最后一次同步的时间和同步失败，定期检查高频问题命中的文档是否过期
- 问题分布漂移：对问题做 Embedding 聚类或意图分类，对比本周和上周各类的占比，新出现的类别抽样查看，补进评测集
告警怎么设
- 用相对变化，而不是写死的绝对值：比如点踩率明显超出过去几周同一时段的波动范围
- 按维度拆开：整体平稳，可能掩盖了某个功能或某类用户的恶化
- 样本量小的维度不要设太灵敏的告警，否则全是误报
- 告警之后，先看变更时间线，再看 trace 和低分样本，定位到原因的类别
代码示例
从调用日志里按天、按功能统计质量信号（MySQL 语法，表结构为示意）：
SELECT
DATE(created_at) AS day,
feature,
COUNT(*) AS requests,
SUM(feedback <=> 'down') / COUNT(*) AS thumbs_down_rate, -- <=> 遇到 NULL 返回 0；用 =，整组都没有反馈时结果是 NULL 而不是 0
SUM(regenerated) / COUNT(*) AS regenerate_rate,
SUM(finish_reason = 'length') / COUNT(*) AS truncated_rate,
SUM(json_valid = 0) / COUNT(json_valid) AS json_error_rate, -- 只统计要求输出 JSON 的请求
AVG(judge_score) AS judge_score -- 只有被抽样评分的请求有值，AVG 会忽略 NULL
FROM llm_requests
WHERE created_at >= CURDATE() - INTERVAL 28 DAY
GROUP BY day, feature
ORDER BY day, feature;面试官可能追问
自己什么都没改，效果突然变差，怎么排查？
先看每天定时跑的固定评测集：分数也降了，多半是上游模型或依赖服务变了，检查模型名是不是用了别名、供应商有没有发布更新、依赖服务的错误率；评测集的分数没变，说明是线上的输入变了，看问题分布有没有出现新类型、知识库是否过期。再按功能和用户群拆开看，缩小范围。
用户很少反馈，怎么监控效果？
不要只依赖显式反馈。隐式行为（重新生成、换说法再问、转人工）的量大得多；技术指标（格式错误、截断、拒答比例）不依赖用户；再加上线上抽样的模型评分和定期的人工抽检。几种信号同时变化时，结论更可信。
怎么提前发现供应商更新模型带来的影响？
用固定版本的模型名，供应商发布新版本时就不会自动切换；关注供应商的版本弃用通知，在旧版本下线之前留出时间，用评测集和小流量灰度验证新版本。如果必须使用别名，就靠每天定时跑的固定评测集兜底。
线上抽样评估，每天抽多少条？
取决于想发现多大的变化。通过率的波动范围和样本量的平方根成反比，样本太少时，日常的波动就会掩盖真实的下降（估算方法见 评测集怎么构建）。按功能分层抽样，保证每个重要功能都有足够的样本；点踩、报错这类已经有信号的对话单独全量看，不占抽样名额。
易错点
- 只盯错误率和延迟这类技术指标，它们正常不代表回答质量没变差
- 使用会自动升级的模型别名，效果变化时无从追溯
- 只看整体的均值，某个功能或某类问题的退化被掩盖
- 发现问题后只修个案，不把案例补进评测集
AI 模拟面试官
用自己的话回答，AI 对照参考答案打分、指出遗漏，再追问，最多 3 轮
这道题你掌握了吗？
选一个最接近的状态，没掌握的题会出现在"我的进度 · 待复习"里。
学习记录暂存在本机浏览器。登录后自动同步到账号，换设备也能看到。