模型评测集按任务簇拆分避免数据泄漏的设计

模型评测最容易被忽略的不是指标公式，而是样本之间的关系。若同一个用户、文档、商品或任务模板的变体同时落入训练集和测试集，模型可能只是记住了实体特征，测试分数却看起来很高。更稳妥的做法是先为样本建立任务簇，再按任务簇分配 train、validation 和 test，最后检查不同集合的簇集合没有交集。

先把评测边界写成任务簇

先回答一个工程问题：测试样本在真实使用中会不会与训练样本共享身份、来源或模板？答案为“会”时，这个维度就应该进入分组键。问答数据可以按用户或文档分组，客服数据可以按会话分组，检索数据还应把同一文档的不同切片放在同一个簇内。时间也可能是边界：预测未来事件时，不能让未来内容回流到训练集合。

Hugging Face 的数据集文档把 train、validation、test 视为用途不同的 split；这里的关键补充是，split 的边界要匹配业务实体，而不是机械套用随机比例。

官方资料：https://huggingface.co/docs/evaluate/considerations

用稳定字段生成 group_key

不要用输入行号或随机数作为分组依据。先统一大小写、空白和缺省值，再组合实体、来源和任务族。下面的示例把同一任务簇的样本固定到一个组，并用组级哈希做可复现分配；哈希只负责分布，不替代业务边界判断。

import hashlib
import json

def make_group_key(row):
    # 统一缺省值，避免同一实体因 None 和空字符串被拆成两组。
    parts = [
        str(row.get("entity_id") or "unknown").strip().lower(),
        str(row.get("source_family") or "unknown").strip().lower(),
        str(row.get("task_cluster") or "unknown").strip().lower(),
    ]
    return "|".join(parts)

def choose_split(group_key):
    # 固定命名空间和阈值，重复运行时得到相同的 split。
    digest = hashlib.sha256(("eval-v1|" + group_key).encode()).hexdigest()
    bucket = int(digest[:8], 16) % 100
    if bucket 

如果业务要求每个测试簇都完整留出，也可以使用 scikit-learn 的 GroupShuffleSplit；它按 group 而不是按样本数量解释 train_size 和 test_size。比例只是起点，小簇数量不足时应优先保证测试集覆盖真实任务，而不是追求漂亮的 8:1:1。

官方资料：https://scikit-learn.org/stable/modules/generated/sklearn.model_selection.GroupShuffleSplit.html

拆完之后检查比例与分布

只看行数比例不够。至少统计每个 split 的唯一 group_key 数、标签覆盖、来源占比和任务类型。若某个来源只落在 train，测试结果就不能代表跨来源泛化；若少数类别全部被哈希分到训练集，应在组级别做分层分配或人工固定保留组，而不是把同组样本拆开。

发布评测结果前可以做三项硬检查：

• set(train.group_key) & set(test.group_key) 必须为空。
• 近重复文本、相同文档切片和模板族不能只靠字符串去重后再随机分行。
• 拆分清单要记录规则版本、随机种子、数据快照和时间截止点。

常见问题

为什么不能直接随机划分每一行？

随机行切分默认样本近似独立；当同一实体或模板产生多条样本时，这个前提不成立，测试集会泄露训练集的身份线索。

group_key 越细越好吗？

不是。过细会让真正相关的样本跨集合，过粗又会让测试集过小。应选择与线上泛化目标一致的最小不可泄漏单位。

测试集是否必须固定不变？

用于模型比较的主测试集应冻结并版本化；新增任务可以建立新版本，但不要悄悄替换旧测试集后继续横向比较。