8. 数据切分、泄漏、污染与版本化
核心工程 · 2～3 小时
学习目标
- 避免测试集被开发过程污染
- 理解 Benchmark contamination 与环境漂移
- 建立 Dataset / Evaluator / Environment Version
前置知识
- 第 7 章
本章产物： 给现有 EvalSuite 建立版本清单和 Holdout 策略。
8.1 Test 反复看，就不再是 Test
如果团队每天看同一批“隐藏测试”结果并针对失败调 Prompt，这批数据实际上已经成为 Validation。
推荐：
Development Set
Validation / Regression Set
Release Holdout
Production Shadow Set8.2 Agent Eval 的泄漏比传统 ML 更复杂
泄漏可能来自：
- Case 进入 Prompt；
- Tool 文档包含答案；
- Repository/网站已经出现在训练数据；
- Agent Memory 保留前一个 Eval 的状态；
- Environment 没有 reset；
- Judge 看到了不该知道的 reference；
- Case ID 本身暗示答案。
8.3 环境泄漏
Case A 创建文件，Case B 恰好读取这个文件，就会产生顺序依赖。
所以每个 Case 必须回答：
environment isolation?
reset strategy?
seed?
shared mutable state?8.4 Dataset Version
建议 SemVer 或不可变 digest：
customer-service-eval@1.4.0
sha256:...修改 Case expected state 不是“无影响的文档修改”，它会改变历史分数含义。
8.5 Benchmark Contamination
公开 Benchmark 可能进入模型训练数据。遇到异常高分时，不应直接证明“泛化能力”。
可以增加：
- 新鲜私有 Case；
- 时间切分；
- hidden holdout；
- procedural generation；
- task perturbation；
- unseen domains。
8.6 Eval Result 必须绑定版本
suite: customer-service@1.4.0
agent: 0.9.1
model: provider/model@revision
evaluator: state-checker@2.1.0
environment: retail-fixture@12没有版本信息的历史曲线很容易失去意义。
8.7 验收问题
- 为什么 Eval 环境 reset 失败也属于数据泄漏？
- 为什么修改 Evaluator 后不能直接和旧分数比较？
- 怎样保留真正的 Release Holdout？
本章依据
原理性结论优先来自原始论文和官方文档。论文中的实验数字只属于论文声明的模型、数据、环境和评测设置，不能直接外推为你的生产结论。