数据集结构决定模型上限：从划分到防泄漏的完整指南

1. 为什么说“模型上限”藏在数据集结构里

先说个我自己踩过的坑。前几年做图像分类项目，调了一个多月的模型，准确率死活卡在 91% 上不去。后来把训练数据翻出来细看，发现测试集里混了一批和训练集几乎一模一样的图片——不是重复样本，而是同一样本的亮度微调版本。当时数据集管理得乱，原始图片、预处理图片、增强图片全堆在一个文件夹里，划分训练集和测试集的时候随手一 split，结果验证指标虚高得离谱，换到真实场景直接打回原形。

那次之后我才真正意识到一个反直觉的结论：模型性能的瓶颈往往不在算法，而在数据集的底层结构。算法工程师追求的是调参、换网络结构、上更复杂的 loss，但数据集的目录怎么组织、样本怎么标注、训练集和验证集怎么划分，这些看似“没有技术含量”的事情，才是决定整个项目能不能落地的地基。

很多人学机器学习，一上来就是线性回归、决策树、神经网络，天天研究损失函数和梯度下降，但问到“数据集里到底应该有什么”却答不上来。实际做项目的时候，拿到手的往往是一堆杂乱的文件：几千张图片、一个 CSV 表格、几十个 JSON 标注文件，甚至有的数据散落在不同同事的电脑里。这时候，你首先面对的问题根本不是“选什么模型”，而是“这些数据怎么整理才能喂给模型吃”。

数据集的“结构”这个词，涵盖了三层意思：

• 存储结构：文件目录怎么组织，图片放哪里、标注放哪里，命名规则是什么；
• 样本结构：每一条数据样本由什么组成，特征是数值型还是文本型，标签是单值还是多值；
• 划分结构：训练集、验证集、测试集怎么从全量数据中切分出来，切分逻辑是否公平、是否避免信息泄漏。

这三层结构决定了模型训练 Pipeline 的起点。出发点错了，后面再多的 trick 都是在错误的地基上修修补补。这篇文章我会从这三层结构出发，把数据集结构的底层逻辑讲透，再结合真实项目中的踩坑经历，告诉你一套可以直接落地的数据集组织方案。

这套内容适合所有正在入门机器学习的人。不管你是学生正在做课程作业，还是工程师第一次把模型推向生产环境，理解了数据集结构，你才能真正理解为什么“数据决定上限，算法只是逼近这个上限”。

2. 数据集的最小单元：样本、特征与标签的三元组关系

2.1 一条样本到底包含什么

在拆解复杂的数据集结构之前，先把最小单元搞清楚。机器学习的训练过程，本质上就是“喂入大量样本 → 模型寻找特征与标签之间的映射关系 → 在新样本上做预测”。每一条训练样本，都应该包含两部分核心内容：特征（Feature）和标签（Label）。

特征就是模型用来做判断的输入信号，标签是那个“标准答案”。拿房价预测来类比：特征是一套房子的面积、卧室数量、所在楼层、周边配套，标签是这套房子实际成交的价格。模型要做的事，就是找出特征和价格之间的函数关系。

但真实世界的数据不会天然整齐地分成“特征”和“标签”两列。原始数据往往是一堆没有结构的信息——图片的像素值、文本的字符序列、语音的波形幅值。把这些原始信息转化成模型能处理的数值特征，这个过程叫特征工程，而特征工程的第一步，就是把原始数据整理成规范的“特征矩阵 + 标签向量”结构。

一个典型的表格型数据集，在 Python 里用 pandas 读进来之后的表现形式如下：

python复制import pandas as pd

df = pd.read_csv("house_prices.csv")
print(df.head())
print("特征矩阵形状:", df.drop("price", axis=1).shape)
print("标签向量形状:", df["price"].shape)

每行是一条样本，每列是一个特征，price 列是标签。这就是最基本的数据集结构——二维表格。后续所有的数据清洗、标准化、模型输入，都是围绕这个表格结构展开的。

2.2 监督学习、无监督学习各自的数据结构差异

搞明白样本 = 特征 + 标签之后，还要区分学习范式的不同。常见的机器学习范式有三种，它们对数据集结构的要求差异很大：

刚入门时最容易犯的错，就是拿到无监督任务，却按监督学习的思路去准备数据——非要给无标签数据硬造标签。聚类任务的数据集，就是一个没有任何标签的矩阵，每行是样本，每列是特征，模型根据特征距离自动把样本划分成若干簇。这时候标签不是不存在，而是模型训练完之后的输出结果，不是输入。

2.3 标签的多种形态：单标签、多标签、结构化输出

标签本身也不是只有“一个类别名”这一种形态。根据任务性质不同，标签结构可能完全不同，这直接影响数据如何组织：

• 单标签分类：每张图片对应一个类别，标签是整数或 one-hot 编码。MNIST 手写数字就是这种，标签范围 0~9，每张图只属于一个数字。
• 多标签分类：每个样本可以同时属于多个类别。比如一张图片里既有猫又有狗，标签就不能是一个整数，通常编码成一个定长向量，每个维度代表一个类别是否存在。
• 回归任务：标签是连续数值，比如温度、价格、点击率，不需要类别映射，直接以浮点数形式存在。
• 序列输出：标签本身是序列，比如机器翻译里源语言的标签是目标语言的句子，此时数据集结构会复杂得多，通常需要对齐工具把源序列和目标序列一一对应起来。

理解标签的形态，是在设计数据集结构时绕不开的一步。我见过有人把多标签任务硬塞进单标签的目录结构里——每张图只能放一个文件夹，结果一张猫狗同框的图片只能归到猫或者归到狗，模型训练出来效果自然一塌糊涂。这种时候应该选择多标签的标注格式（比如 JSON 或 CSV 里一行存多个标签），而不是强行套用单标签的目录结构。

3. 训练集、验证集、测试集：数据划分不是“随手一 split”

3.1 三份数据的使命各不相同

数据集的存储结构和样本结构是基础，但真正让初学者掉坑的，往往是划分结构。为什么要把数据分成训练集、验证集、测试集三份？它们各自承担什么角色？

很多人理解成“训练集用来训练，测试集用来测试”，这没错但不够准确。更本质的理解方式是这样的：

• 训练集（Training Set）：用来拟合模型参数。模型在这里“做作业”，通过一次次迭代把参数调到能让损失函数变小的方向。
• 验证集（Validation Set）：用来做模型选择与超参数调优。模型不直接在验证集上学参数，但你会拿验证集的结果来对比不同模型、不同超参数哪个更好——相当于“模拟考”。
• 测试集（Test Set）：用来最终评估模型的泛化能力。只允许在模型全部调优完毕之后使用一次，相当于“高考”。

可以这么理解：训练集是平时的练习册，验证集是考前模拟卷，测试集是最终高考。**如果高考题不小心混进了模拟卷，那模拟成绩再高也不代表你高考能考好。**这就是数据泄漏（Data Leakage）的本质——模型对测试集不再是“没见过的新题”，指标自然虚高，项目落不了地。

3.2 切分比例与切分策略：随机切分、分层切分、时间序列切分

数据划分的常见比例是 60% / 20% / 20%、70% / 15% / 15% 或 80% / 10% / 10%，具体看数据量。数据量大可以给训练集更多比例，数据量小验证集和测试集至少要保持数百条以上，否则评估结果方差太大，指标不稳定。

比比例更重要的是切分策略：

随机切分是最简单的方式，train_test_split 函数默认就是干这个的。数据量足够大（几万条以上），且类别比例比较均衡时，随机切分就够用。

分层切分（Stratified Split）用于分类任务。假设原始数据里正样本只占 5%，如果随机切分，很可能测试集和训练集中的正负比例有差异，导致评估失真。分层切分会保证训练集、验证集、测试集中每个类别的比例和全量数据大致一致。

python复制from sklearn.model_selection import train_test_split

X_train, X_temp, y_train, y_temp = train_test_split(
    X, y, test_size=0.3, stratify=y, random_state=42
)
X_val, X_test, y_val, y_test = train_test_split(
    X_temp, y_temp, test_size=0.5, stratify=y_temp, random_state=42
)

时间序列切分是另一个极易被忽略的场景。如果数据带有时间顺序（股票价格、流量预测、用户行为日志），就不能随机切分，否则就是用未来的数据去预测过去，测试指标虚高到离谱。正确做法是按时间点切分：前 80% 时间的数据做训练，后 20% 做测试。

我在实际项目中见过最典型的一次翻车：一个电商平台点击率预估项目，同事把用户日志随机打乱后训练测试，模型在离线评估时 Auc 高达 0.85，上线之后掉到 0.62。后来排查发现，训练集里混入了未来时间段的行为数据，模型学到的根本不是稳定的用户偏好，而是特定日期的事件模式。这类问题用任何“高级模型”都无法解决，只能回炉重做数据划分。

3.3 Random Seed 的隐藏价值

切分数据时，random_state 这个参数一定要设置。它的作用是让切分结果可复现——你这次跑出来是这批样本进训练集，下次跑还是一样的结果。团队协作时，大家统一用一个 seed，就能保证每个人看到的训练样本完全一致，排查问题时对齐成本大幅降低。

我自己的习惯是项目根目录放一个 config.py，统一管理数据切分的 seed：

python复制DATA_SEED = 42
TRAIN_RATIO = 0.7
VAL_RATIO = 0.15
TEST_RATIO = 0.15

而不是把 seed 散落在各个 Notebook 单元格里。数据划分逻辑是项目的“宪法”，应该集中管理、版本控制。

4. 从 COCO 到 CSV：主流公开数据集的目录与标注组织方式

4.1 COCO 数据集的目录结构和 JSON 标注体系

COCO 数据集的目录结构是一个绝佳的学习样本，因为它把这个领域里最规范的组织方式展示出来了。COCO 2017 数据集的典型目录长这样：

text复制coco2017/
├── annotations/
│   ├── instances_train2017.json
│   ├── instances_val2017.json
│   ├── captions_train2017.json
│   └── person_keypoints_train2017.json
├── train2017/
│   ├── 000000000139.jpg
│   ├── 000000000285.jpg
│   └── ...
├── val2017/
│   ├── 000000000139.jpg
│   └── ...
└── test2017/
    └── ...

annotations/ 目录下的 JSON 文件就是标注数据，图片文件按训练集和验证集分开存放。这种“图片文件 + 独立标注文件”的结构，在后面做目标检测、实例分割任务时几乎是标准做法。

打开 instances_train2017.json，它的 JSON 结构是嵌套的：

json复制{
  "info": {...},
  "images": [
    {"id": 139, "file_name": "000000000139.jpg", "width": 640, "height": 426, ...},
    ...
  ],
  "annotations": [
    {"id": 1, "image_id": 139, "category_id": 2, "bbox": [100, 120, 50, 80], ...},
    ...
  ],
  "categories": [
    {"id": 1, "name": "person", "supercategory": "person"},
    ...
  ]
}

三块核心结构分别是：images 里存的是每张图片的元信息（文件名、宽高等），annotations 里存的是每个标注框的坐标和类别，categories 里存的是类别字典。标注框通过 image_id 和 category_id 和图片、类别形成关联——这就是典型的关系型结构，而不是把标注信息和图片文件绑死在一个目录里。

我当时第一次接触这个结构时，觉得挺绕的——为什么不直接在每张图片旁边放一个同名 txt 文件，像 YOLO 那样？非要用一个巨大的 JSON 把全部标注捆在一起。后来做了一轮数据处理才明白：把所有标注集中在 JSON 里，方便做全量统计分析（比如统计每个类别有多少实例），也方便划分数据集时统一按 image_id 操作，不会出现图片复制了一份而标注文件没跟上的问题。

4.2 YOLO 格式的目录与标注规范对比

同样是目标检测，YOLO 系列采用的就是完全相反的结构。YOLO 格式一张图片对应一个同名 txt 文件，每行表示一个目标：

text复制<object-class> <x_center> <y_center> <width> <height>

所有坐标值归一化到 0~1 之间，比如：

text复制2 0.507031 0.579688 0.251562 0.298438
3 0.157813 0.953125 0.101562 0.082031

目录结构也更扁平，通常直接在 images/ 和 labels/ 两个大目录下按训练集和验证集分：

text复制dataset/
├── images/
│   ├── train/
│   │   ├── 0001.jpg
│   │   └── ...
│   └── val/
│       ├── 0001.jpg
│       └── ...
├── labels/
│   ├── train/
│   │   ├── 0001.txt
│   │   └── ...
│   └── val/
│       ├── 0001.txt
│       └── ...
└── data.yaml

COCO 和 YOLO 两种格式各自适合不同场景。COCO 结构信息丰富，适合复杂任务和多类别场景；YOLO 格式读取快、文件数量多但单个文件小，训练时方便直接按文件名加载。实际工作中经常需要转换格式，建议团队里准备一个标注格式转换脚本，避免下次换模型时又要手动改一遍。

4.3 图像分类数据集的目录约定：MNIST、CIFAR 之外的自建方案

图像分类任务的数据集结构最简单，也最容易视觉化理解：一个类别一个文件夹。比如猫狗分类：

text复制cat_dog/
├── train/
│   ├── cat/
│   │   ├── cat_001.jpg
│   │   └── cat_002.jpg
│   └── dog/
│       ├── dog_001.jpg
│       └── dog_002.jpg
├── val/
│   ├── cat/
│   │   ├── cat_101.jpg
│   │   └── ...
│   └── dog/
│       ├── dog_101.jpg
│       └── ...
└── test/
    ├── cat/
    │   └── ...
    └── dog/
        └── ...

用 ImageFolder 类可以直接读这种结构，代码非常简洁：

python复制from torchvision.datasets import ImageFolder

train_dataset = ImageFolder("cat_dog/train")
print(train_dataset.class_to_idx)
# 输出: {'cat': 0, 'dog': 1}

这种“文件夹即类别”的结构，好处是直观，文件系统本身就承担了标签标注的职责，不需要额外的标注文件。但坏处也有：如果一张图片属于多个类别（多标签分类），这种结构就无能为力了，需要回归到 JSON 或 CSV 标记的方式。

MNIST、CIFAR 这类经典数据集则采用了更紧凑的序列化存储。MNIST 的图片不是一张张散落的，而是打包在几个二进制文件里，读取时需要专门的解析代码：

python复制import tensorflow as tf

mnist = tf.keras.datasets.mnist
(x_train, y_train), (x_test, y_test) = mnist.load_data()
print(x_train.shape)  # (60000, 28, 28)
print(y_train.shape)  # (60000,)

对小数据集来说，这种方式读写效率更高；但对大规模图片数据集，散落文件 + 索引文件的方式更灵活，方便增量增加样本。

4.4 表格数据集的结构：Titanic 里学到的“宽表思维”

表格型数据集是最常见、也最容易被低估的结构。Kaggle 上的经典案例 Titanic 数据集就是一个典型的宽表：

text复制PassengerId,Survived,Pclass,Name,Sex,Age,SibSp,Parch,Ticket,Fare,Cabin,Embarked

• PassengerId：样本唯一标识；
• Survived：标签（1 表示存活，0 表示遇难）；
• 其余列是特征：舱位等级、姓名、性别、年龄、兄弟姐妹数量、票价、船舱号、登船港口等。

表格数据的核心结构就是“宽表”——每行一个样本，每列一个特征。但在真实项目中，原始数据很少是完美宽表，通常是多张表通过外键关联。比如一个电商项目，订单表、用户表、商品表分属不同文件，需要先做多表 Join 拼成一个宽表，才能喂给模型。

做特征工程之前，先看数据结构，这是表格类项目的首要步骤。数据结构混乱的话，特征算得再花哨，喂给模型的时候错位了，等于白算。

5. 设计一个能长期演进的数据集仓库

5.1 用“原始数据 - 中间数据 - 最终数据”三层结构组织目录

看过了公开数据集的规范，再聊自建数据集的组织方案。一个能支撑项目长期迭代的数据集仓库，至少要分成三个层次：

text复制data/
├── raw/          # 原始数据，不可修改
├── processed/    # 清洗、转换后的中间数据
└── final/        # 模型直接使用的最终数据，通常是训练/验证/测试划分完毕

• raw/ 里放的是从数据源直接拿过来的原始文件，永远不要手动修改。如果要做数据备份、去重、格式转换，都应该另外生成新文件，而不是就地改动。这样一旦后续处理逻辑写错了，随时可以从 raw 重新生成。
• processed/ 是中间产物，比如完成缺失值填充、归一化、文本清洗之后的数据。
• final/ 是模型训练时直接读入的数据，通常是已经划分好的训练集、验证集、测试集。

这个三层结构的核心理念是：数据和代码一样需要版本管理。模型迭代的过程中，数据可能被反复清洗、反复切分。如果没有保留 raw 层，一旦发现某一步处理有 bug，就只能手工修复几百个文件，费时费力还容易出错。有了 raw 层，跑一遍处理脚本就能重新生成全部下游数据。

5.2 命名规范与元信息记录：让三个月后的自己也能看懂

多花一点时间做好命名规范和元信息记录，后期能省下大量沟通成本。我常用的命名规范如下：

text复制{数据集名称}_{日期}_{版本}.{ext}

比如：

text复制cat_dog_20250112_v1.0.zip
cat_dog_20250112_v1.1.zip

同时在 data/ 目录下放一个 README.md 或者 DATA_DICT.md，记录：

• 数据来源和采集时间；
• 字段说明（每个特征的含义、取值范围、单位）；
• 标签说明（标签含义、类别分布）；
• 数据划分的规则（哪个脚本切分的、seed 是多少）；
• 已知问题和注意事项（比如“本版本含有重复样本，需去重”）。

这些元信息看第一遍时觉得没必要，但一旦项目推进三个月、团队里来了新人，或者你自己换了个项目再回来，会发现这份文档比很多代码还值钱。

5.3 数据存储格式的选型思路

数据集的存储格式选择对性能和后续开发的便利性影响很大，下面是常见格式的对比：

我的建议是：常规项目直接用“图片文件 + 标注文件”就够了，没必要一开始就上 TFRecord 或者 HDF5 这种花哨格式。只有数据量大到 I/O 成为瓶颈时，才值得付出额外的工程成本去做格式转换。

5.4 从零到一的完整流程示例

这里用一个简化的图像分类项目为例，把前面说的结构完整串一遍：

第一步，拿到原始图片，放入 data/raw/images/：

bash复制mkdir -p data/raw/images
cp ~/downloads/source_images/*.jpg data/raw/images/

第二步，编写一个 Python 脚本对图片做基础清洗和分类整理：

python复制import os
import shutil
import pandas as pd

# 假设有一个 CSV 记录了每张图片的类别
df = pd.read_csv("data/raw/labels.csv")
for _, row in df.iterrows():
    src = os.path.join("data/raw/images", f"{row['image_id']}.jpg")
    dst_dir = os.path.join("data/processed", row["label"])
    os.makedirs(dst_dir, exist_ok=True)
    shutil.copy(src, os.path.join(dst_dir, f"{row['image_id']}.jpg"))

第三步，做分层切分，并保存切分索引：

python复制from sklearn.model_selection import train_test_split

train_files, temp_files = train_test_split(
    df, test_size=0.3, stratify=df["label"], random_state=42
)
val_files, test_files = train_test_split(
    temp_files, test_size=0.5, stratify=temp_files["label"], random_state=42
)

train_files.to_csv("data/final/train.csv", index=False)
val_files.to_csv("data/final/val.csv", index=False)
test_files.to_csv("data/final/test.csv", index=False)

第四步，写模型训练代码时，统一从 data/final/ 读取。如果后续要换数据，只需要替换 final 目录下的内容，模型代码不用改一个字。

6. 数据泄漏与划分陷阱：结构设计里最隐形的敌人

6.1 数据泄漏的三种典型场景

数据泄漏是数据集结构设计中最隐形、危害最大的一类问题。我总结三种最典型的场景：

**场景一：重复样本跨集合泄漏。**同一张图片在数据采集时被重复保存了两次，一个随机进了训练集，另一个随机进了测试集。模型在训练时已经见过这张图，测试时当然“认识”它。解决方法是切分之前先做去重。

**场景二：预处理泄漏。**先用全量数据的均值、方差做标准化，再切分训练集和测试集——这是最经典的泄漏。正确的做法是先只对训练集 fit 得到均值和方差，再用这个均值和方差变换验证集和测试集。特征工程如果用到全局统计量也是一样的道理。

python复制# 错误写法：在切分前对全量数据做标准化
from sklearn.preprocessing import StandardScaler
scaler = StandardScaler()
X_scaled = scaler.fit_transform(X)

# 正确写法：只对训练集 fit，再 transform 其他数据集
X_train_scaled = scaler.fit_transform(X_train)
X_val_scaled = scaler.transform(X_val)
X_test_scaled = scaler.transform(X_test)

**场景三：时间序列随机切分。**前面提到的电商点击率项目就是典型代表。数据有明确时间戳，却被随机打乱切分，等价于用未来预测过去。

6.2 如何用代码检查泄漏

检查泄漏除了靠经验，还可以在代码层面加一些防御机制。比如在数据加载后，显式检查训练集和测试集是否有重复样本：

python复制train_ids = set(train_df["image_id"])
test_ids = set(test_df["image_id"])
duplicates = train_ids & test_ids
if duplicates:
    raise ValueError(f"训练集和测试集存在 {len(duplicates)} 个重复样本")

这个检查在多人协作、数据处理环节多的时候特别有用。宁可多跑一次这种防御性检查，也不要等模型上线了再发现问题。

6.3 验证集与测试集的“一题多考”问题

还有一个容易忽略的点：验证集被反复使用也会导致过拟合。调参调了几百次，每次都用同一个验证集对比效果，验证集的信息其实已经被写进了你的决策过程——你选的超参数是在“迎合”这个验证集。所以验证集指标有轻微虚高是正常的，最终以测试集为准。

这也解释了为什么测试集只能使用一次：一旦你用测试集调过参，它就不再是“见过世面的陌生人”，之后所有的参数决策都会隐含地针对它过拟合。

7. 数据集的长期维护：版本管理与团队协作

7.1 数据版本化的必要性

代码可以用 Git 做版本管理，但数据往往体积巨大，不适合直接塞进 Git 仓库。常见的方案是用 DVC（Data Version Control）或 W&B Artifacts 做数据版本管理。DVC 的使用方式很直观：

bash复制dvc init
dvc add data/final
git add data/final.dvc .gitignore
git commit -m "add final dataset v1.0"

dvc add 会生成一个 .dvc 文件记录数据文件的元信息和校验值，真实数据存储在本地缓存或远程对象存储（如 S3）中。需要切换旧版本数据时，一条命令就能拉回对应的文件。这个工具我用了几年，基本可以做到“代码回退到哪个提交，数据也跟着回到那个状态”。

7.2 团队协作时的数据结构约定

团队里做机器学习，最怕的是“每个人有自己的一套数据管理方式”。有人在网盘传数据、有人用 U 盘拷贝、有人把文件放服务器上的个人目录……最后合版本时一片混乱。

建立一套团队统一的数据集结构规范，至少包含以下约定：

• 数据集目录统一用 data/raw、data/processed、data/final 三层结构；
• 全部数据统一命名，带日期和版本号；
• 数据文件统一存放到共享存储或对象存储，而不是每个人本地各留一份；
• 数据更新的操作有流程：先更新 raw，再运行统一处理脚本，生成新版本 final，然后更新版本记录文件。

7.3 记录“数据血缘”

更高阶的团队会做数据血缘（Data Lineage）记录：**这张训练集是从哪个原始版本、通过什么脚本、什么 seed、什么时间生成的。**听起来有点重，但实际操作并不复杂——只要在处理脚本里把输入的 raw 版本、处理参数、输出路径都记录到一份日志 JSON 里就可以了。

json复制{
  "dataset": "cat_dog",
  "version": "v1.1",
  "created_at": "2025-01-12 18:30:00",
  "raw_version": "raw_v1.0",
  "preprocess_script": "scripts/preprocess.py",
  "split_seed": 42,
  "samples": {
    "train": 12000,
    "val": 1500,
    "test": 1500
  }
}

有了这份记录，复现一个实验结果就不再是“重新跑一遍代码”这么简单，而是“在数据 v1.1 和代码 commit 哈希 xxx 下重新跑”。数据血缘写多了你会发现，很多玄学的模型性能差异，最终都能追溯到数据版本的对不上。

8. 我自己的一套最小践行动作

最后分享一套我现在每次开新项目都会执行的最小践行动作，算是这几年踩坑后沉淀下来的“肌肉记忆”。

第一，拿到任何数据，先把 raw 层锁住。无论原始数据来自哪里、格式多乱，先完整拷贝到 data/raw/ 目录，计算一次校验值存起来。之后所有处理都在下游进行，绝不回头改动 raw。

第二，写一个 prepare_data.py 脚本，把“原始数据 -> 清洗 -> 划分 -> 输出 final”的完整流程脚本化。这一步花的时间通常在半天到一天，但从此以后数据重建只需要一条命令。

第三，划分数据集时，强制使用分层切分（分类任务），并固定 seed。不要相信“这次结果好只是因为随机划分走了狗屎运”，好的数据集结构设计就是要让结果可复现、可解释。

第四，训练和测试之前，先跑一遍重复样本检测和泄漏检查。这个过程很快，但能拦住绝大多数项目后期才会爆发的坑。

第五，无论项目大小，用一个 README 记录数据集结构说明。哪怕只有自己一个人看，也值得写。

我见过太多机器学习项目，算法选型没有问题、模型代码写得也漂亮，最后就是死在数据这一层——要么数据划分泄漏导致指标永久停留在“自嗨”水平，要么数据集结构混乱导致换一个场景就要重头整理。如果你刚开始学机器学习，我反而建议你先把 20% 的时间花在理解数据集结构上，这比一头扎进更多花哨的模型架构有用得多。模型可以换、超参可以调，但数据集的骨架一旦定错了，返工成本是几何级上升的。