Eval Dataset 的分层与 Grouped Split
在 Eval Dataset 中同时保持关键类别覆盖并按 user、episode 或 scenario family 分组切分,避免近重复场景跨 split 造成泄漏和虚假的泛化成绩。
#type / concept
#status / growing
#tech / ai
#tech / dev / test
[!info] related notes
- 所属 MOC: agent-evals-moc、testing-moc
- 前置概念: eval-dataset
- 并列概念:
- 易混淆概念:
- 关系笔记: bodysense-diagnosis-model-governance-eval-loop
Eval Dataset 的分层与 Grouped Split
一句话定义
Eval Dataset 的 Grouped Split 是在 development、calibration、holdout 等数据切分时,既保证重要 case category 有代表,又保证同一 user / episode / scenario family 不跨 split,从而减少泄漏。
Stratified 与 Grouped 回答不同问题
Stratified
→ 每个重要类别在各 split 中都有足够代表
Grouped
→ 高度相关的一组案例整体只能落在一个 split
两者通常需要同时满足。
只做 stratified 而不 grouped,可能把同一场景的轻微改写同时放进 development 与 holdout;这样模型虽然没见过完全相同的文本,却已经见过几乎相同的问题结构。
为什么 scenario family 是重要分组键
Agent eval 中常见泄漏不只是相同 user:
- 同一用户的多轮或多次变体;
- 同一 episode 的不同快照;
- 同一模板改写出的多个 case;
- 同一根本 failure mode 的近重复案例。
因此可以定义:
scenario_family_id
并确保一个 family 只进入一个 split。
常见数据集角色
Development Set
→ 可以反复查看并用于改 Agent / Prompt / Validator
Calibration Set
→ 调 Judge rubric / threshold
Holdout Set
→ 未见数据上的资格验证
Regression Set
→ 历史真实失败,防止复发
Challenge Set
→ 有意 oversample 高风险 failure modes
Regression / Challenge 与普通 holdout 的统计含义不同,不应把 challenge raw average 直接解释成真实生产分布表现。
关键原则
同一类风险要在各必要 split 中有代表,但同一个 user / episode / scenario family 不能跨 split。
这能同时保护 coverage 与 independence。
常见误解
- 随机切分天然公平:随机 row split 可能把近重复案例分散到不同集合。
- 只要文本不同就不算泄漏:语义模板、episode 和 scenario family 也会泄漏。
- Regression Set 应永远保持未见:它的目的本来就是持续防复发;真正独立资格证据应依赖 holdout。