微调数据应该如何划分验证集？
简化版
验证集的核心不是随机拿出 10%，而是模拟模型上线后面对的未见数据。若同一用户会话、同一文档切块、同一 Prompt 模板或近重复样本同时出现在训练与验证中，分数会虚高。
应先去重和聚类，再按用户、文档、模板、任务或时间分组切分；同时保留代表性验证集、困难挑战集和安全回归集。最终测试集应保持隔离，只用于少量关键决策，避免反复调参造成过拟合。
正确的切分单位是可能共享信息的“数据组”，不一定是单条样本。
详细版
典型流程：
raw samples
-> exact/semantic dedup
-> group by conversation, user, document, template or entity
-> stratify groups by task/language/risk
-> train / validation / test
-> post-split leakage audit例如 10 万条客服对话来自 2 万个会话，不能逐消息随机切分。若前几轮在训练集、最后一轮在验证集，模型可能从重复上下文直接猜答案。应以 conversation_id 为组整体分配。
| 切分策略 | 适用目标 | 主要风险 |
|---|---|---|
| 随机样本切分 | IID 基线 | 近重复和组泄漏 |
| Group Split | 未见用户/文档/模板 | 小组分布不均 |
| 时间切分 | 未来数据泛化 | 政策和流量同时变化 |
| 领域留出 | 跨域泛化 | 与真实上线范围不一致 |
| Hash Split | 数据持续增长 | Group Key 必须稳定 |
完整版教学
1. 验证集到底用于什么
验证集用于选超参数、Checkpoint 和早停；测试集用于最终无偏报告。若反复根据测试集调参，它就退化成验证集。
还应把安全红线和历史事故集独立维护，避免平均 Loss 把严重失败隐藏。
2. 为什么逐样本随机切分容易泄漏
SFT 数据常由同一原文切块、同一会话多轮、同一模板替换实体或同一答案改写产生。随机切分会把高度相关样本分到两侧。
验证分数反映的是记忆模板，而不是对未见任务的泛化。
3. Group Split 如何选择分组键
分组键应覆盖主要信息共享来源：会话 ID、用户 ID、文档 ID、代码仓库、Prompt 模板、事件或主体身份。
如果一个样本同时属于多个组，可构建连通分量：任何共享用户或文档的样本都进入同一分区，避免间接泄漏。
例如两段对话虽然 conversation_id 不同，却引用同一政策文档并由同一模板生成；若目标是测未见文档泛化，应优先按 document_id 聚合。分组键由部署时真正希望泛化的维度决定。
4. 去重应该在切分前还是后
先做全局精确和语义去重/聚类，再以簇为单位切分。只在每个分区内部去重，无法消除跨分区近重复。
“训练集和验证集各自没有重复”不代表二者之间没有重复；泄漏审计必须跨集合进行。
切分后仍要再跑一次跨集合相似度检查作为验证。
5. 分层抽样如何保持关键分布
Group Split 后可能导致语言或任务比例偏斜。应按任务、语言、风险和长度对组做分层或优化分配。
| 分层轴 | 原因 |
|---|---|
| 任务类型 | 各能力都需足够样本 |
| 语言 | 防止小语种被随机分空 |
| 风险等级 | 高风险需最低覆盖 |
| 长度区间 | 长上下文能力单独评估 |
| 数据来源 | 防止单一供应商主导验证 |
过采样切片的总体分数需按目标分布加权。
6. 时间切分何时更合理
如果上线后面对未来政策、商品和用户行为，按时间切分比随机切分更接近真实。训练用某日期前数据，验证用之后窗口。
时间切分同时包含概念漂移，分数下降可能来自知识过期而非微调方法，应按任务和政策版本诊断。
7. 验证集大小怎样决定
不能机械使用 10%。大数据集的 1% 可能足够，小数据集的 20% 仍不稳定。样本量由指标方差、切片数量和希望检测的最小差异决定。
对于通过率 p，标准误约为：
SE = √(p(1-p)/n)每个关键切片都需要足够 n，而不只是总体数量大。
8. 小数据集如何避免验证集浪费
可使用 Group K-Fold 做开发比较，让每个组轮流验证；最终仍保留独立测试集。训练最终模型时可在选定配置后使用更多数据，但报告不能复用训练过的验证结果。
高风险样本很少时，不应全部拿去训练；至少保留独立门禁，必要时通过专家构造补充。
9. 代表性集与挑战集为什么要分开
代表性集按线上分布估计总体体验；挑战集集中困难、长尾和安全边界。混成一个总分会让结果无法解释。
发布报告分别列出总体、关键能力、挑战和安全，不用单一加权分掩盖失败。
10. 合成数据应该怎样切分
同一个生成 Prompt 模板和同一教师回答风格会造成强相关。按生成任务模板、种子批次或源文档分组，而不是按最终文本随机切。
若验证集也由同一教师生成，可能只测出学生模仿教师风格。应加入人工或真实线上验证样本。
11. 数据污染如何检查
检查训练集与验证/测试集的 n-gram、MinHash、Embedding 相似和共享答案片段。代码任务还要按仓库和题目来源隔离。
公开 Benchmark 可能已在基座预训练中出现，这类污染无法仅靠当前 SFT 切分解决，应准备私有新鲜集。
12. 持续数据管道如何稳定切分
对稳定 Group Key 做哈希：
bucket = hash(group_id + split_salt) % 100
0..79 train, 80..89 validation, 90..99 test新数据会稳定进入同一分区，防止同一用户后来出现在测试和训练两侧。Salt 与规则要版本化。
13. 如何审计一次切分
报告每个分区的样本数、组数、任务/语言/风险分布、时间范围和跨集合最大相似度。随机抽取相似度最高的样本对人工复核。
还要确认任何验证/测试样本未进入 Few-shot、RAG 索引或人工调参清单。
14. 常见误区与追问
- 误区：随机 8:1:1 适用于所有数据。 会话、文档和模板数据需要 Group Split。
- 误区：先切分再各自去重就没有泄漏。 跨集合近重复仍然存在，应先全局聚类。
- 误区：验证集比例越大越可靠。 关键是绝对样本量、方差与切片覆盖。
- 误区：验证 Loss 最低就一定上线最好。 还要看任务指标、安全、通用能力和成本。
- 误区：测试集可以每次训练都查看。 反复选择会对测试集过拟合。
- 追问：多轮对话按什么切？ 以完整 conversation_id 为组，不拆轮次。
- 追问：持续新增数据怎样保持稳定？ 使用版本化 Salt 对 Group Key 做确定性 Hash Split。
15. 加强记忆
- 先去重，再分组，再分层，最后审计泄漏。
- 分组单位：会话、用户、文档、模板、仓库或主体。
- 三类集合：代表性、挑战、安全分别报告。
- 样本量看误差：关键切片要有统计能力，不机械套 10%。
- 测试集隔离：只做最终决策，持续管道用稳定 Hash Split。