08. 如何设计一套贴近业务的离线评测流水线？
整理贴近业务场景的离线评测流水线设计原则与工程实践。
简单回答
业务离线评测流水线的核心是构建一套"能快速发现模型退步、又贴近真实用户场景"的测试体系。关键要素包括：有代表性的测试集（覆盖真实用户的 query 分布）、稳定可靠的评测指标、自动化执行和结果对比、以及和 CI/CD 的集成。设计评测流水线最常见的错误是：测试集和真实场景脱节、指标选取错误导致错误放行、或者整个流程太慢导致没人愿意用。
详细解答
测试集的构建原则
代表性是第一位的。测试集要覆盖真实用户 query 的分布，而不只是开发人员写的"觉得模型应该能回答"的题目。获取真实分布的方法：从生产日志中抽样（过滤掉敏感内容后），按 query 类型分层抽样，确保各类型的覆盖；对罕见但重要的 case（边界情况、高风险问题）做额外补充，超采样。
分层结构：把测试集按任务类型、难度、重要性分层。常见分层维度：核心能力（模型最基础的功能必须正确）、回归防护（历史上曾经出过问题的 case，每次更新都要跑）、边缘 case（低频但高影响的场景）、新增能力（验证本次更新的目标能力）。
规模的权衡：测试集太小（几十条），随机性大，可能遗漏问题；太大（几万条），跑一次时间太长，影响迭代速度。通常的做法是维护一个"快速验证集"（几百条，几分钟能跑完）和一个"完整评测集"（几千到上万条，定期跑），分别用于日常迭代和重要版本发布前的验证。
标注质量：测试集的标准答案或评测标准必须高质量。用 LLM 自动生成的标准答案要人工抽查；人工标注的要有标注规范和质控流程。测试集的质量问题会污染所有评测结论，是最底层的风险。
评测指标的选取
指标的选取要和业务目标对齐，而不是只看方便测量的指标。
明确负向指标（不能发生的事情）：比如对特定敏感词/话题的回复不能包含某类内容、代码生成不能包含明显安全漏洞、关键事实性问题不能出错。这些是"红线"，触发就是不合格。
正向指标（做得越好越好）：有帮助性分数、格式正确率、任务完成率等。这些有阈值要求，通常要求新版本不能低于旧版本减去某个容忍范围（比如 -3%）。
避免代理指标陷阱：很多团队用"BLEU 分数高"来代理"回答质量高"，但 BLEU 和真实质量的相关性很差，容易出现 BLEU 分上去了但用户体验反而差的情况。指标要尽量接近"用户最终感受"，而不是"方便算的替代指标"。
自动化执行和基线对比
基线系统：每次评测都要和"基线"对比，通常基线是当前生产版本。新版本在每个维度的评测结果和基线比较，自动标记出有明显下降的维度。没有基线对比，单次评测数字很难判断是好是坏。
差异报告：自动生成评测报告，不只是汇总指标，还要列出新版本相比基线，哪些测试 case 变好了、哪些变差了。变差的 case 要方便人工查看（一键跳到具体的对比），便于定位问题根因。
结果稳定性：LLM 的输出有随机性（temperature > 0），同样的 case 两次运行结果可能不同，评测分数会有波动。工程上有几种处理方式：用 temperature=0 保证确定性（适合选择题、代码等），多次运行取均值（适合开放生成评测），报告置信区间而不是单点分数。
和 CI/CD 的集成
理想的离线评测流水线应该和代码合并流程集成，每次 PR 合并前自动跑快速验证集，失败时阻塞合并。重要版本发布前跑完整评测集，需要人工确认结果才能发布。
评测结果要持久化存储，方便历史对比——跟踪每个版本的评测分数趋势，可以发现缓慢的能力退化（每次变化很小，但长期下来有明显下降）。
常见工程陷阱
测试集过拟合：随着时间推移，模型的迭代方向会不自觉地向测试集"优化"，导致测试集上的分数好但实际表现没提升。解决方法是定期更新测试集（每季度替换 10~20%），加入新的测试 case，防止测试集被"记住"。
评测和生产环境不一致：评测时用的 system prompt、温度参数、max token 等配置要和生产完全一致，否则评测结果不能代表生产表现。
忽略尾部风险：平均指标好不代表没有严重的局部失败。应该额外关注最差情况（P99）的表现，以及特定类型 case 的失败率，而不只是看平均分。
面试时可以这样答
设计业务评测流水线有几个核心要点。测试集要从真实用户 query 里抽，按类型分层，维护"快速验证集"（几百条，分钟级）和"完整评测集"（几千条，重要版本前跑），分别对应不同的速度和覆盖需求。
指标选取上，先定红线（不能发生的事），再定正向指标，要对齐业务目标而不是方便算的代理指标。每次评测都要和基线对比，自动输出差异报告，变差的 case 要能一键查看，不然出了问题不知道往哪查。
工程上要和 CI/CD 集成，PR 合并前自动跑快速集，失败阻塞合并。结果要持久化存储，跟踪趋势，能发现缓慢退化。
两个最常见的坑：测试集和真实场景脱节（只测开发者觉得重要的，不测用户真正会问的）；还有测试集过拟合（迭代久了模型默默对测试集优化），要定期更新测试集，防止集合被"记住"。
常见追问
- 测试集应该多久更新一次？怎么决定替换哪些 case？
- 离线评测结论和线上 A/B Test 不一致时，怎么判断哪个更可信？
- 对于多轮对话的产品，离线评测集怎么设计？单轮测试能代表多轮能力吗？