离线评测分数很高，线上用户为什么仍然不满意？数据分布与任务成功率排查
文章摘要
离线集可能过于干净、静态和均衡，无法覆盖线上噪声、权限、长对话、超时和真实业务结果。
一、问题为什么容易误判
线上质量应以任务是否完成和用户是否解决问题为核心，而不只是回答相似度。
常见表现包括：
- 离线准确率高但转人工率高
- 真实输入更短更乱
- 高峰期超时影响结果
- 评测无权限和工具故障
- 用户反复追问
这类问题不能只通过重复请求或更换模型解决。应先把调用链拆开，确认故障发生在输入、配置、状态、检索、工具、模型还是输出阶段。
二、完整调用链
用户请求 → 离线评测分数很高，线上用户为什么仍然不满意前置处理 → 核心服务 → 模型/数据/工具 → 输出校验 → 用户
排查时要为每一段记录输入摘要、版本、耗时、错误类型和关联ID，避免只看最终异常。
三、最常见的根因
- 数据集与线上分布不同
- 只评最终文本
- 忽略延迟和成本
- 缺少失败与边界样本
- 标签由模型生成未人工校准
四、推荐排查顺序
- 抽样真实流量脱敏入集
- 按场景风险分层
- 评测完整轨迹
- 增加任务成功和转人工指标
- 建立线上失败回流
- 比较离线与线上相关性
一次只改变一个变量，并保留变更前后的Trace。否则即使问题消失，也无法确认真正原因。
五、核心实现示例
QualityDecision decision = qualityGate.evaluate(
offlineReport, shadowMetrics, canaryMetrics);
if (!decision.pass()) {
releaseService.block(decision.reasons());
}
示例只展示关键控制点。生产项目还应补充参数校验、异常映射、超时、重试边界、租户权限和审计字段。
六、需要记录的观测指标
- request_id与tenant_id
- 实际模型、Prompt和配置版本
- 阶段耗时与错误分类
- 重试、回退和取消次数
- 最终业务状态与成本
七、容易踩的误区
- 只看最终错误，不检查中间阶段
- 把所有异常都当成模型质量问题
- 同时修改多个配置后无法定位原因
- 在日志中记录完整敏感输入
- 没有为问题建立可回放测试样本
八、上线前检查清单
□ 完整调用链可追踪
□ 关键配置和版本进入Trace
□ 错误类型有稳定业务映射
□ 异常场景有自动化回归
□ 高风险失败默认拒绝
九、如何建立最小可复现环境
针对“离线评测分数很高，线上用户为什么仍然不满意？数据分布与任务成功率排查”这类问题，建议不要直接在生产环境反复修改配置。可以建立一个只包含单个入口、单个测试租户和固定测试数据的最小环境，并固定以下变量：
代码提交版本
Prompt版本
模型与Provider
配置中心版本
测试数据或索引版本
请求参数
预期结果
先在最小环境稳定复现，再逐层替换真实组件。每次实验只修改一个变量，并保存请求Trace、配置快照和输出差异。这样才能判断修复是来自代码、配置、模型、数据还是偶然波动。
十、修复后怎样灰度验证
修复不能只验证一条成功请求。推荐依次执行：
- 回放最初失败样本，确认问题不再出现；
- 运行同类边界样本，防止只修复表面现象；
- 使用影子流量比较修复前后的错误率、延迟和成本；
- 先对内部用户或低风险租户开放；
- 连续观察关键指标后再扩大流量；
- 保留旧配置和快速回滚开关。
发生过的故障还应进入回归测试集。只有能够自动阻止同类问题再次上线，排查工作才真正形成了工程资产。
总结
离线评测只有与线上任务成功和用户反馈相关，才是有效测量。
延伸阅读
如果你正在关注企业级 AI 应用、Spring AI、RAG、Agent 与大模型工程化落地，欢迎访问 智元界：
https://www.zyentor.com/
智元界将持续分享可运行的技术实战、架构设计、问题排查与企业应用案例。