2. 基础知识

TinyML 模型的开发与传统嵌入式软件有一个本质区别:模型的行为由数据决定,而非由代码逻辑完全决定。在资源受限的 MCU(微控制器)上部署模型时,我们无法像调试普通程序那样单步跟踪每一层神经网络的内部状态,因此测试数据集的质量直接决定了我们对模型可信度的判断。一个定义清晰的测试数据集,能够回答三个关键问题:模型在目标硬件上是否按预期工作?模型的精度在真实环境中是否达标?模型的鲁棒性是否足以应对部署后的各种变化?本章将系统梳理 TinyML 测试数据集的定义、三大类型(合成数据、回放数据、真实数据)及其适用场景,帮助你在实际项目中建立科学的测试数据策略。

TinyML 测试数据集类型与适用场景 测试数据集定义 用于验证模型在目标硬件上性能的输入样本集 合成数据 · 程序生成/仿真产生 · 可精确控制分布 · 可生成极端/边界样本 · 无标注成本 适用:单元测试、回归测试 传感器仿真、故障注入 回放数据 · 预先采集的真实信号 · 通过SD卡/串口/文件回放 · 可重复、可对比 · 保留真实噪声特征 适用:板端验证、算法对比 回归测试、多版本评估 真实数据 · 现场实时采集 · 包含完整环境因素 · 最接近部署条件 · 标注成本高 适用:最终验收、现场测试 长期稳定性评估 数据选择决策路径 开发阶段 → 合成数据(快速迭代) 集成阶段 → 回放数据(一致性验证) 部署阶段 → 真实数据(最终验收) 测试目标 → 边界条件:合成数据 测试目标 → 噪声鲁棒性:回放数据 测试目标 → 现场适配:真实数据 最佳实践:三类数据组合使用,覆盖不同测试维度

2.1 核心原理:为什么 TinyML 测试数据集需要特殊设计

TinyML 测试数据集与传统机器学习测试集的最大区别在于:它不仅要评估模型的算法精度,还要验证模型在特定硬件平台上的实际表现。传统 ML 测试通常只关注模型权重和推理逻辑,而 TinyML 测试必须考虑传感器接口、内存布局、量化误差、中断时序、电源波动等硬件因素。例如,一个在 PC 上精度达到 95% 的语音唤醒模型,部署到 Cortex-M4 上可能因为 int8 量化损失 2% 精度,或者因为麦克风采样率偏差导致性能下降。因此,TinyML 测试数据集必须能够同时反映算法层面和硬件层面的问题。

另一个核心差异是数据获取的物理约束。TinyML 设备通常部署在边缘环境,传感器数据具有强烈的时空相关性。测试数据集需要保留这种相关性,才能真实反映模型在部署环境中的行为。例如,加速度计数据如果仅保留幅值而丢失时间序列结构,模型可能无法正确识别手势。这意味着测试数据集不仅仅是样本的集合,还包含采样率、通道同步、时间戳等元信息。

2.2 合成数据:可控性与边界覆盖

合成数据是通过程序、数学模型或仿真工具生成的测试样本,不依赖真实传感器采集。在 TinyML 开发中,合成数据主要用于早期算法验证和边界条件测试。其核心优势在于完全可控:你可以精确指定数据的分布范围、噪声水平、异常模式,甚至生成在现实中极难采集的极端工况。

合成数据的生成方式通常分为三类:

  • 基于数学模型的生成:例如正弦波叠加噪声模拟振动信号,或使用高斯分布生成随机噪声样本。这种方式适合验证模型的基本功能,如分类是否正确、回归是否收敛。
  • 基于物理仿真的生成:利用 Simulink、Unity 等工具模拟传感器在特定物理环境下的输出。例如,模拟无人机在不同风速下的 IMU 数据,或模拟工业设备在不同负载下的电流波形。
  • 基于数据增强的生成:从少量真实数据出发,通过旋转、缩放、加噪、时间扭曲等方式扩展数据集。这种方式介于合成与真实之间,但本质上是程序生成的变体。

合成数据在 TinyML 测试中的典型应用场景包括:

  • 单元测试:验证模型对特定输入的输出是否符合预期,例如输入全零向量时输出是否为默认类别。
  • 边界测试:生成超出正常范围的数据,测试模型的饱和行为。例如,麦克风输入满幅值方波时,模型是否会产生错误触发。
  • 故障注入:模拟传感器断线、短路、漂移等故障,验证模型的容错能力。
经验提示:合成数据虽然可控,但容易陷入"过度拟合测试集"的陷阱。如果模型只在合成数据上测试,可能对真实数据的噪声分布、非线性特征缺乏鲁棒性。建议合成数据占比不超过测试总量的 40%,且必须与回放或真实数据交叉验证。

2.3 回放数据:可重复性与一致性验证

回放数据是指预先从真实传感器采集、存储,然后在测试时通过某种接口重新输入到设备中的数据。这是 TinyML 测试中最实用的数据类型,因为它兼顾了真实性和可重复性。回放数据的核心价值在于:它保留了真实传感器的噪声特性、非线性失真和环境干扰,同时允许你在完全相同的输入条件下反复测试不同版本的模型或不同硬件配置。

回放数据的实现方式通常有两种:

  1. 离线文件回放:将传感器数据保存为 CSV、WAV 或二进制文件,通过 SD 卡、USB 或串口传输到开发板。测试程序读取文件并模拟传感器数据流输入模型。这种方式适合开发阶段的迭代测试。
  2. 在线缓冲回放:在设备 RAM 中预加载一段数据,通过定时器或 DMA 按采样率输出。这种方式更接近真实时序,适合验证实时性要求高的应用。

回放数据的关键参数包括采样率、位深、通道数、时间戳对齐方式。例如,一个 16kHz 采样、16 位量化的音频回放文件,在板端必须以精确的 16kHz 速率输出,否则模型可能因为时序偏差产生错误结果。下表列出了回放数据在不同测试场景中的配置建议:

测试场景 数据长度 回放速率 关键验证点
算法功能验证 10-30 秒 标称采样率 分类/回归结果是否正确
实时性测试 1-5 分钟 1.5x 标称速率 是否出现数据溢出或丢帧
长时间稳定性 1-24 小时 标称采样率 内存泄漏、温度漂移、时钟偏差
多设备一致性 30-60 秒 标称采样率 不同板卡间输出差异

回放数据的一个典型应用场景是模型量化前后的对比测试。在 PC 上训练好的浮点模型转换为 int8 量化模型后,使用同一段回放数据分别输入两个版本,对比输出差异。如果差异超过预设阈值(如分类置信度变化超过 5%),则说明量化过程引入了不可接受的精度损失。

2.4 真实数据:最终验收与现场适配

真实数据是指在目标部署环境中,通过实际传感器实时采集的数据。这是最接近生产条件的数据类型,也是最终验收测试的必要输入。真实数据的价值在于它包含了所有不可预测的因素:环境温度变化、电磁干扰、机械振动、用户行为差异等。这些因素在合成数据和回放数据中都无法完全模拟。

真实数据测试通常分为两个阶段:

  • 受控现场测试:在部署现场但处于可控条件下采集数据。例如,在工厂车间中指定特定位置、特定时间段采集振动数据。这种方式可以部分控制变量,同时保留真实环境特征。
  • 完全自由运行测试:设备在实际使用条件下连续运行数天或数周,自动记录传感器数据和模型输出。这种方式最能反映真实性能,但数据标注困难,通常需要事后人工分析。

真实数据测试的挑战在于标注成本和不可重复性。同一场景下两次采集的数据不可能完全相同,因此无法直接进行 A/B 对比。解决方法是建立"黄金数据集":在部署初期采集一批高质量的真实数据,进行详细标注并保存,作为后续版本验证的基准。

风险提示:真实数据测试中常见的错误是"数据漂移"——部署环境随时间变化(如季节更替、设备老化),导致测试数据与训练数据分布不一致。建议定期更新真实测试集,并监控模型在真实数据上的性能趋势。

2.5 案例拆解:智能门锁振动传感器测试数据策略

以一个基于加速度计的智能门锁敲击识别项目为例,说明三类测试数据的实际配合使用。该设备使用 LIS3DH 加速度计,采样率 100Hz,模型需要区分"敲门"、"踢门"、"环境振动"三类事件。

开发阶段(合成数据为主):工程师使用 Python 生成三类合成信号——敲门模拟为 50ms 的衰减正弦波叠加随机噪声,踢门模拟为 200ms 的宽脉冲,环境振动模拟为低幅值高斯噪声。合成数据用于验证模型的基本分类能力和边界响应(如输入幅值超过量程时是否饱和)。

集成阶段(回放数据为主):在真实门上安装加速度计,采集 30 分钟真实敲击数据,保存为二进制文件。通过串口将数据回放到开发板,验证模型在真实噪声下的表现。发现模型对"踢门"的识别准确率从合成数据的 98% 下降到 91%,原因是真实踢门信号包含低频共振分量,合成数据未覆盖。工程师据此调整了预处理滤波器参数。

部署阶段(真实数据):将设备安装在实际入户门上,连续运行 72 小时,记录所有事件。人工标注后统计发现,模型将"邻居装修的电钻振动"误判为"敲门",误报率 3.2%。团队决定增加一个 2 秒的确认窗口,并要求连续两次检测到敲击特征才触发报警,最终误报率降至 0.8%。

这个案例展示了三类数据的递进关系:合成数据快速验证算法逻辑,回放数据暴露真实噪声问题,真实数据发现环境适配问题。每一类数据都发现了前一类数据无法覆盖的问题。

2.6 常见误区与总结复盘

在 TinyML 测试数据集的使用中,以下误区需要特别注意:

  • 误区一:只用合成数据测试。合成数据无法模拟真实传感器的非线性、温漂和时变特性,容易导致模型在部署后性能骤降。
  • 误区二:回放数据不控制时序。如果回放速率不精确,模型可能因为数据到达时间偏差而产生错误输出。必须使用定时器或 DMA 保证采样间隔。
  • 误区三:真实数据不标注。没有标注的真实数据只能用于监控,无法用于精度评估。建议至少对 10% 的真实数据进行人工标注。
  • 误区四:三类数据割裂使用。正确做法是建立统一的测试框架,让三类数据可以无缝切换,便于对比分析。

总结而言,TinyML 测试数据集的设计应遵循"分层递进、组合覆盖"的原则:合成数据保证算法正确性,回放数据保证硬件适配性,真实数据保证环境鲁棒性。在实际项目中,建议按照 20% 合成数据、50% 回放数据、30% 真实数据的比例构建测试集,并根据项目阶段动态调整。同时,所有测试数据都应记录完整的元信息(采集时间、环境参数、硬件版本),以便追溯性能变化的原因。