测试数据集构建实战：以fastlivo2为例的完整指南

测试数据集这个东西，平时写模型、调参数的时候大家都在用，但真正愿意花时间认真对待它的团队其实不多。我见过太多项目，前期数据集随便拼一拼，训练集验证集测试集三刀一切就当完事，结果等到模型上线或者参加评测的时候，才发现测试集里早就混进了脏数据、重复样本，甚至标签都对不上。fastlivo2是我最近在做的多模态融合感知项目，做它的测试数据集时，我把之前踩过的坑重新捋了一遍，这里把整套思路和操作细节记下来，给后面做同类工作的朋友一个参考。

开头先把这个东西到底是什么说清楚。测试数据集，就是在模型训练开发全流程中，专门用来做最终评估的那一批数据。它不参与训练，也不参与调参，只负责在模型快定稿的时候，给模型一次“模拟考”。很多人会把测试集和验证集混在一起，但这两者角色差别很大。fastlivo2项目里，我要同时验证视觉惯性里程计和激光雷达融合定位的精度，如果测试集不够干净、分布不够真实，那最后评测出的指标只能自欺欺人。这篇文章就打算从测试集的设计思路、构建流程、样本量测算、常见坑点这几个维度展开，适合那些正在准备自己项目评估数据的算法工程师、数据工程师，还有准备发论文或打比赛需要严格评测标准的研究生。

1. 重新理解测试集：它不是训练数据的一小块边角料

1.1 测试集在模型开发里到底扮演什么角色

很多人对测试集的理解，是“留出一部分数据不训练，最后跑一下看效果”。这句话方向没错，但太模糊，实际操作中会引发一连串问题。打个比方，训练集像学生平时做的练习题，验证集像月考卷，测试集则是期末考试卷。如果一个学生平时把期末考题都提前做过一遍，那期末考试分数就完全失去参考价值。测试集必须和训练过程彻底隔离，这个隔离不仅指数据本身不参与权重更新，更指它的分布、难度、噪声特征都不能在开发阶段被有意无意地“看穿”。

我在fastlivo2项目里遇到过这样一个问题：一开始我把同一个场景的连续帧序列随机切成了三段，一部分做训练、一部分做验证、一部分做测试。结果训练出来的模型在测试集上表现异常优秀，定位误差比平时调试时差了将近一个数量级。后来排查发现，连续帧之间高度相关，同一段走廊的几百帧图像本质上就是同一个场景的重复采样，模型在训练时已经“背”下了这段路，测试自然毫无压力。这就是测训同分布且过度相关的典型问题。

从评估学的角度讲，测试集的核心价值是给出泛化误差的无偏估计。如果你希望模型上线后能在新场景里正常工作，测试集就应该尽可能模拟“没有见过的环境”。fastlivo2项目里我最终的做法是，把测试数据全部换成不同时间段、不同光照条件下单独采集的场景，同一条路线从早中晚各跑一遍，再混合一些动态行人车辆干扰，这样模型在评测时面对的都是训练过程里没出现过的实际变化。

1.2 测试集、验证集和训练集之间怎么划分

先给一张我常用的划分逻辑表，你可以直接代入自己的任务：

边界问题很重要的一个地方在于：验证集和测试集的数据来源，可以是同分布但必须不同批次。举例来说，采集自动驾驶场景数据的时候，你可以在A路段采一部分用于训练和验证，在B路段采集一部分用于测试。如果条件不允许，只能在同一条路段采集，那也要保证测试片段与训练片段之间时间上完全分离，不要出现一帧在训练集里、相邻下一秒跑到测试集里的情况。

fastlivo2的训练集我用了大约2000帧多模态数据，覆盖写字楼室内、地下车库、城市道路几个主要场景。验证集从同样的场景中抽了300帧，但时间上独立。而测试集是第二批单独采集的，总共500帧，包含夜间、雨天、强逆光等训练数据里几乎没出现过的恶劣条件。这样设计的原因很简单：我希望测试集能回答“这个模型在没见过的复杂条件下还能不能跑”，而不是“这个模型在已经背熟的路径上能跑得多顺”。

1.3 为什么“测试集泄漏”是比过拟合更隐蔽的坑

过拟合还有一个公开的衡量指标能够肉眼发现，训练集loss降得很低、验证集loss升高，这时候大部分人都会警觉。但测试集泄漏不是这样，它往往发生在你完全不知情的过程中，像一道看不见的后门，等模型上了线才发现实际效果远不如离线评测。

我整理了一下fastlivo2开发中遇到的几种泄漏途径，都是亲身踩过的：

• 数据预处理阶段做了全局归一化。比如整个数据集统一计算均值和方差，再按这个全局统计量归一化。这时候测试集的信息已经通过均值方差偷偷进入了训练过程，严格讲这种评测结果已经不够纯净。
• 训练数据里混入了测试场景的地图信息。fastlivo2涉及激光雷达定位，如果构建定位地图时不小心把测试场景的激光点云也加进去了，那模型在测试集上定位精度就会虚高，因为它不是靠实时感知匹配，而是提前“作弊”知道了地图。
• 人工调参过于频繁地参考测试集结果。一些团队把测试集和验证集混用，每次改完模型都去看一下测试集指标，这个习惯一旦养成，测试集就逐渐变成了第二验证集，失去评估意义。

针对这些坑，我的处理办法很固定：数据预处理的所有统计量在训练集上单独计算，然后保存下来用于验证集和测试集转换。对fastlivo2这样涉及多传感器标定和时间同步的项目，我会对所有测试数据做严格的标定一致性检查，确保测试集不包含训练场景的地图碎片。调参阶段我只盯验证集，测试集锁在一个单独的目录里，加了访问限制，直到最后一次完整评测才打开。

2. 构建测试数据集的核心流程与实操要点

2.1 第一步：数据采集阶段就要考虑测试集独立性

很多项目是把所有原始数据堆在一起然后再划分，这种方式效率很低，因为在原始数据采集阶段，各个场景的数据已经天然交织在一起。你很难在事后把它们彻底拆开而不引入相关性。更好的做法是采集阶段就想清楚：哪些场景用于训练，哪些场景用于测试。

fastlivo2项目在采集前我列了一张清单，把测试集的独立性直接写进了采集计划：

• 测试场景选择与训练场景物理隔离，尽量是不同的楼层、不同的街区。
• 测试时间与训练时间错开，训练数据白天采，测试数据傍晚或者夜间采。
• 测试时的传感器安装角度和高度保持与训练一致，避免把“安装差异”误当成模型能力不足。
• 每个测试序列单独命名、单独存档，采集完立刻标记，不混入原始数据池。

这里有一个很实用的小技巧：给数据文件命名的时候直接把用途打成后缀。比如fastlivo2的原始数据文件名是20250114_office_day_01，如果是测试集专用的序列，我会直接改成20250118_office_night_test_01。看起来只是命名习惯，但到了后期数据量到达几十个G的时候，这个习惯能帮你省掉大量整理时间，也避免误用。

另外采集设备层面也有一点值得注意，就是测试数据里最好包含一些“普通情况”和“极端情况”的混合。如果测试集全部是极端条件，评测指标会非常难看，但也无法判断模型在常规场景下是否退化。我通常的做法是：测试集里大约70%是中等难度的常规场景，30%是难度较高的边缘条件，这样既能看到模型在常态下的稳定性，也能探到它的能力边界。

2.2 第二步：数据清洗时哪些该留哪些该扔

采集完的原始数据，很少能直接进测试集。fastlivo2的数据里经常出现传感器掉帧、时间戳跳变、镜头被污渍遮挡、激光雷达出现反射率异常等情况。这些问题在不同场景下的严重程度不一样，但清洗原则需要统一：宁可损失数量，也不留质量存疑的样本。

我建议清洗分成两个层级。第一层是硬过滤，规则明确，任何满足条件的数据直接扔掉。包括：图像完全黑屏或纯白、IMU数据连续静止超过3秒、激光雷达点云数量低于正常值的一半、时间戳相邻帧间隔超过设定阈值。第二层是软检查，需要人工或半自动算法辅助，比如图像亮度异常但还没到纯黑的程度，可能是光圈问题，也可能是环境就是暗。这类样本我不会直接删除，而是标注出来，在评测时单独作为一个子集观察。fastlivo2做法是软检查中识别出的问题样本单独放到一个test_special目录里，这样主测试集和特殊测试集分开评测，结果可解释性更强。

很多人会担心清洗过多导致测试集变小，这确实是个矛盾。我的经验是：与其保留大量质量一般的样本，导致模型评测结果忽高忽低不好解释，不如减少样本量但保证每一帧都是可信的。测试集关注的是评测置信度，样本量太少会让置信区间变宽，但样本质量太差会让评测结果偏移，两者相比，质量问题的危害更大。

fastlivo2最终500帧的测试集，是从原始采集的将近1200帧数据里清洗出来的。去掉的有传感器失步的序列、有强反光导致的点云空洞、有运动模糊严重的图像，还有一些移除了场景重叠部分。清洗之后剩下的数据，虽然量不大，但每一帧都有明确来源和状态说明，评测结果可以放心引用。

2.3 第三步：标签标注与一致性检查

对大多数机器学习任务来说，测试集的标签质量直接影响评测有效性。fastlivo2是定位和建图类项目，它的“标签”并不是简单的框选或者分类，而是高精度的轨迹真值。为了获得可信的测试真值，我使用了两种方式交叉验证：一种是固定部署的动捕系统输出的轨迹，另一种是高精度RTK-GNSS和激光雷达点云配准得到的后处理轨迹。两种真值之间的偏差需要控制在一个很小的范围内，否则这一帧数据就要重新评估是否保留。

这里我想重点提醒一下多人协作场景下的标注一致性问题。如果你的测试集不是一个人单独完成标注，而是多人分工协作，那务必要设计一个标注规范文档，并对每一个标注人员进行培训考核。图像分类任务里最常见的错误是边界box画多宽算合格、密集场景下遮挡目标要不要标、模糊目标按哪一帧状态标。这些问题如果不提前统一，测试集标签的噪声就会变得不可控。

我见过一个团队做目标检测，三人标注同一批图像，结果其中一个人把远处的行人标了，另外一个人认为太远不需要标，最终测试集上模型的召回率波动了差不多10个百分点。这个问题不是模型造成的，是标签不一致造成的。fastlivo2虽然没有框选式标注，但在后期做语义分割验证时也遇到过类似情况，我当时让三个人分别标注同一批50张图，然后计算两两之间的标注重合度，对差异超过阈值的样本重新讨论定标规则。

另外，我强烈建议在测试集正式封存前，做一次全量标签复核。把自动生成的标签用简便的可视化脚本画出来，然后在屏幕上快速过一遍，这个过程虽然比较枯燥，但往往能发现很多意外的错误。比如fastlivo2测试数据里曾有一次真值轨迹的坐标原点没有对齐，如果没有可视化检查，直接跑评测就会产生几十米的误差。

2.4 第四步：切分比例和样本量到底怎么定

切分比例这个问题，不能只死记“7:1.5:1.5”这种公式，它和你的任务类型、数据总量高度相关。我常用的判断思路是：在数据量有限的情况下，优先保证训练集的数量能满足模型学习需求，测试集则要满足统计显著性要求。从统计角度讲，如果测试集只有几十个样本，那评测指标的置信区间会很宽，A模型和B模型之间的差异很难说清是真实优劣还是随机波动。

对于分类任务，通常可以用二项分布估算测试集样本量。假设你期望的准确率是90%，想让误差范围控制在正负2%以内，按正态近似粗略计算，大概需要864个测试样本。对于连续指标如定位误差，则需要看误差的标准差和你想探测的最小差异。fastlivo2的定位误差标准差大概在0.1米左右，我希望测试能分辨出0.05米的精度差异，这样计算下来，测试集至少需要64个以上的独立轨迹片段，每个片段内有连续帧用于统计，最终我保留了500帧，足够支撑一个比较稳的均值估计。

还有一个容易被忽视的点：测试集里的“独立样本数”比“总帧数”更有价值。哪怕你有10000帧数据，但如果它们来自同一条10分钟的连续序列，那真正独立的信息可能只有这一段场景。fastlivo2测试集500帧分散在10多个不同的独立序列里，每个序列几十上百帧不等，这些序列之间来源完全不同，这样评测结果才具备更好的泛化代表性。

3. 测试数据集构建实操记录：以fastlivo2为例

3.1 数据来源规划与采集执行

我分两个方面来规划来源：一是自己实地采集，二是复用团队之前积累的历史数据。fastlivo2需要传感器数据包含视觉、惯性、激光雷达三种模态，所以自采数据是主力。我用了手持设备和一个安装在移动机器人平台上的传感器组合，按照预定路线连续采集。为了让测试集的场景多样化，我选了办公楼楼层、地下停车场、园区道路、楼梯间这几个完全不同结构的场景。

提前规划路线的时候，我使用了一台具备RTK定位的参考设备，让地面控制点在采集前已经被标定好。这些控制点在后处理中用来给真值轨迹做全局对齐，保证测试集轨迹真值的坐标精度。执行过程中，有几个实际操作的细节值得说一下：

• 每个场景开始前后都要静止几秒，方便做IMU初始化和时间同步。
• 采集时不急转弯、不快速晃动，减少运动模糊和点云畸变。
• 遇到玻璃墙、反光地面等困难区域，放慢速度，让传感器有时间采集足够多的有效帧。
• 每到结束点检查一下存储卡剩余空间和电池电量，避免中途断采导致整个序列作废。

这些看起来都是小事，但它们直接影响后期清洗困难和真值精度。我在实际踩坑中遇到过快速转动导致的IMU饱和，这种数据即使后面算法再厉害也无法纠正，只能做删除处理。

3.2 数据结构设计与时间同步验证

fastlivo2的数据结构设计相对朴素，但层次清晰。每一条序列是一个以时间戳命名的目录，内部包含left_image、right_image（或单目），imu_data.csv，lidar_pointcloud.pcd（或bag），还有一个calibration.json和sensor_config.yaml。这样的好处是后续评测脚本可以统一遍历目录结构，不用为每个序列单独写路径处理逻辑。

时间同步是多媒体融合数据集中最容易出问题的环节。fastlivo2的相机帧率约30Hz，IMU约200Hz，激光雷达约10Hz。三种数据如果时间戳不对齐，融合定位的效果会大幅下降。我有一个习惯，拿到一个序列后先用工具画出各传感器的采样时间轴，检查是否存在同一个时间范围内部分传感器掉线的情况。如果某个时间段视觉数据缺了帧，但IMU和雷达还在跑，这个片段虽然不一定会立即报废，但要让评测脚本标记出来，因为算法在这种时段的分工可能发生了变化。

时间同步验证的具体做法是算相邻传感器时间戳差值的分布。正常情况下，相机和IMU时间戳差值应该符合一个较窄的分布，如果有大量跳变，说明驱动配置有问题。fastlivo2测试数据中有一段来自旧驱动版本采集的序列，时间戳偏移就会周期性跳到几十毫秒，这类序列后来被我从测试集中移除。虽然少了一个场景的数据，但避免了时间同步差异对效果评估的干扰。

3.3 冷链式数据管理：保存、版本控制与访问权限

测试数据集一旦确定，就不能再随便改动。为了保证这一点，我对fastlivo2的测试集实施了“冷链式”管理。所有测试集数据存放于独立目录，目录权限设置为只读，任何人（包括我自己）在最终评测之前都只有读取权限，不能改写。目录内包含一个README.md，记录每个序列的来源、采集时间、场景描述、清洗记录、真值生成方式。

版本控制上，我用了一个比较轻量但有效的方案：给数据集打上版本号，并且用哈希值做完整性校验。每次新加入或删除数据，版本号递增，同时重新生成一份校验文件。这样做的好处是，如果评测结果有疑问，可以准确回溯到当时使用的是哪一批数据，不会出现“这个结果是用老版本跑的还是新版本跑的”这种说不清的问题。

虽然很多团队还没有到需要这么严格管理的阶段，但只要项目周期超过一个月，或者涉及多人协作，我建议至少做到两条底线。第一，测试集目录跟训练集目录物理分离。第二，做任何修改前先备份原始版本。这两条能让你在出问题时有退路，不至于推倒重来。

3.4 评测流程脚本化的价值

fastlivo2的最终评测我用了一套脚本化的流程，脚本放在仓库的eval/目录下，运行一次会按顺序执行：数据加载、时间戳对齐、定位算法推理、轨迹保存、误差计算、可视化结果生成。整个流程输入是测试集目录和模型配置，输出是一个汇总报告，包含ATE、RPE、不同场景子集的分项指标等。

脚本化的好处不只是自动化，更重要的是可复现性。人工跑评测很容易出现参数不一致、忘记切换分支、用了旧权重文件这样的低级错误。脚本把这些环节全部固定下来，每次都是同样的流程，唯一变化的是模型权重或者算法版本。fastlivo2开发后期，我每天会跑一遍完整评测，然后对比前一天的结果变化，如果某个修改导致指标下滑，可以直接定位是哪个环节引入的问题。

经常有人问评测脚本和训练脚本要不要放同一个仓库，我的建议是分开但共享核心工具库。训练脚本变动频繁，评测脚本尽量稳定。评测脚本一旦被过度改动，你很难确认每次结果之间是否可比。fastlivo2的评测脚本从第一次正式评测后就很少改动了，只增加了一些可视化和日志功能，核心逻辑保持不变，这样前后指标才有可比性。

4. 测试集构建中的常见问题与避坑经验

4.1 测试集太小或者太特殊，结论没有说服力

我在实际开发中经常看到的一个问题是，团队花了很多精力做训练数据，测试集却草草了事，随便留几百张图。对于图像分类这类输入信息量较大的任务，几百张也许勉强够看；但对于定位、检测、分割这类输出空间更大、更复杂的任务，几百张样本可能完全不够支撑一个有意义的结论。

如果你发现自己的测试集只有一两个场景、几十个样本，评测指标的置信区间会很大，两个模型之间的差距很难说是真实存在的。我的建议是至少让测试集能够按场景维度做分层统计，比如室内和室外、白天和夜晚、晴天和雨天分别出指标，这样测试集虽然总量不大，但结论依然有结构、有层次。fastlivo2最终评测里我就把指标分成了办公楼层、地下车库、雨夜道路三个子集，分别给出误差，这样比总指标更有说服力。

还有一种情况是测试集选得太特殊，比如全部是极暗环境或者全部是开阔场地，最终模型测评结果看上去很好，但大家都知道这是因为任务本身在这些场景下比较简单。要规避这个问题，在构建测试集时就应该刻意加入不同难度等级的数据，并且记录每个样本的难度标签，方便后续按难度维度解读结果。

4.2 爬取和合成数据带来的噪声问题

很多人做测试集会从网上爬数据，或者用合成数据生成器制造样本。这种方式速度很快，但有一个致命问题：你很难完全掌握这些数据的生成条件和噪声特性。一个模型在你的测试集上表现不好，究竟是因为模型能力不足，还是因为测试数据不正常，这个问题很难回答。所以我不建议把爬取或合成数据作为测试集的主力。

fastlivo2在训练阶段确实用了一些合成的传感器噪声数据来增强鲁棒性，但测试集全部来自真实采集。原因无他，真实传感器数据里面隐含的噪声模型、系统误差和不同模态之间的耦合关系，是合成数据很难模仿的。如果你没有条件采集，只能使用公开数据集做评测，那我建议至少先做一轮针对性检查，看看公开数据集的传感器配置是否和你的任务一致，标注质量是否可靠，场景覆盖是否能满足你的评测问题。

4.3 测试集沾上了预处理统计量

这是相对隐蔽、但危害不小的问题。以图像数据集为例，如果你的预处理流程里包含“所有数据统一减均值、除方差”这一步，而这个均值方差是从包含测试集在内的全量数据里算出来的，这意味着测试集的一阶和二阶统计信息已经间接参与了训练过程中的数据变换。虽然严格说它没有直接修改模型参数，但在pipeline层面它确实造成了信息传递。

我自己从某次竞赛评测中深刻体会过这个问题。当时排行榜上模型性能极高，但线下复现怎么都达不到，后来发现线上评测在生成特征时用到了包含测试数据统计信息的全局均值，造成了轻微的数据泄漏。从那以后，我所有涉及预处理统计量的项目都强制规定：统计量只从训练集计算，然后固化保存，用同一组统计量处理验证集和测试集。

除了均值方差，还有一类常见的泄漏来自数据增强。如果你的数据增强策略里包含了类似“mixup”或者“cutmix”的方案，而这些方案在训练过程中随机混合了不同样本，那测试集也一定要被排除在增强候选池之外。一些深度学习框架的默认数据加载逻辑可能不会注意这一点，需要手动设置隔离。

4.4 维护与更新：测试集要不要跟随模型迭代更换

这是一个经常被问起的话题。我的看法是：测试集可以小范围更新，但不能频繁、无规则地更换。如果一个测试集在开发过程中被反复替换，那指标的纵向可比性就没有了。比较科学的方式是冻结一个主测试集，长期不变，用于版本之间的回归对比；再定期构建一个全新的挑战性测试集，用于检验模型在真正没见过的数据上的表现。

fastlivo2项目里，我维护了test_stable和test_challenge两个目录。test_stable用来日常跑回归对比，内容固定不变；test_challenge每两个星期更新一次，选取一些之前没有覆盖到的难度场景，用来及时发现模型的能力短板。这样的安排兼顾了稳定性和新鲜感，也不会让评测结果失去参照系。

数据集的持续完善也是一项值得投入的基础设施建设。很多团队直到要发论文或者参加评测的时候才仓促构建测试集，往往因为时间紧迫而降低清洗和标注标准。我的经验是，把测试集当作一个长期资产来管理，每次采集数据时都顺手保留一部分高质量数据作为候选测试样本，经过清洗标注后入池。这样到了关键时刻，你会发现自己已经有一个储备充足、质量可控的测试集可以直接拿出手。

5. 写在最后的几点心得

测试数据集这件事，很多时候看起来没有算法模型那么“高大上”，但它在整个研发流程里起到的把关作用不可低估。一个设计良好的测试集，不只是给最终报告提供几个数字，它更像是一面镜子，能照出模型的真实水平和尚未被发现的短板。fastlivo2在最初几次评测中暴露出的夜间定位精度下降、逆光条件下视觉特征丢失等问题，都是靠分类分层测试集才被量化和定位的。

从操作层面总结，我有几件会坚持做的事：把测试集独立采集，绝不把训练数据的残渣拿来充当测试样本；在采集阶段就想清楚训练场景和测试场景的隔离，而不是事后再急切地分离；给测试集打版本、做校验，封存在只读目录里；所有评测都脚本化，保证任何一次上报的指标都可以被重复验证。这些习惯前期会花掉一些时间和精力，但到项目后期，特别是在多个版本迭代、多人协作、或者需要对结果负责的时候，它们带来的安全感和效率提升是值得的。

如果你正在准备自己的测试数据集，我的核心建议就是：明确你的评测问题，再围绕着这个评测问题去设计测试集的规模和结构。不必追求数量和覆盖率上的大而全，但要保证每一条数据、每一个标签都是清晰和可信赖的。有了这样一个测试集，你的模型评测才不是走形式，而是真正能给到项目决策有用的信息。