3. TinyML数据特点
TinyML 与传统云端机器学习在数据层面存在本质差异。云端模型可以依赖海量历史数据、分布式存储和高性能清洗管道，而 TinyML 的数据采集、存储、标注和验证都发生在资源极度受限的嵌入式环境中。理解这些约束如何影响数据质量，是构建可靠 TinyML 系统的前提。本章从资源受限、传感器噪声、边缘分布漂移和标注成本四个维度展开，分析它们对覆盖度、准确性和可复现性的具体冲击，并给出可操作的应对策略。
3.1 资源受限：数据采集与存储的物理天花板
TinyML 设备通常搭载 Cortex-M 系列 MCU，Flash 容量在 256KB 到 2MB 之间，RAM 往往只有 64KB 到 512KB。这意味着设备无法像云端那样缓存大量原始数据，也无法在本地运行复杂的数据清洗算法。资源受限对数据质量的影响体现在三个层面：采样率被迫降低、量化位宽被压缩、存储窗口极短。
以加速度计数据为例，一个 3 轴加速度计以 100Hz 采样、16 位精度输出，每秒产生 600 字节数据。若设备仅有 256KB Flash 可用于数据缓存，则最多只能存储约 7 分钟的原始数据。对于需要捕捉罕见事件（如设备跌落、异常振动）的应用，这个窗口远远不够。实际工程中，常见做法是采用环形缓冲区 + 触发式存储，但这会引入选择性偏差——只有触发条件满足时数据才被保留，导致训练集覆盖度不足。
| 资源维度 | 典型约束 | 对数据质量的影响 | 缓解策略 |
|---|---|---|---|
| Flash 存储 | 256KB - 2MB | 数据保留窗口短，覆盖度受限 | 特征压缩、事件触发存储、增量上传 |
| RAM 内存 | 64KB - 512KB | 无法批量处理数据，清洗能力弱 | 流式处理、滑动窗口、轻量滤波 |
| CPU 算力 | 几十 MHz - 几百 MHz | 复杂去噪算法无法实时运行 | 查表滤波、定点运算、硬件加速器 |
| 功耗预算 | mW 级 | 采样频率受限，时间分辨率下降 | 自适应采样、休眠调度、事件驱动 |
资源受限还直接影响数据的数值精度。许多 TinyML 设备采用 8 位或 16 位定点数存储传感器数据，相比云端常用的 32 位浮点数，量化误差会被放大。例如，一个量程为 ±16g 的加速度计，若用 8 位有符号数表示，每个 LSB 代表 0.125g，这意味着微小的振动信号可能被量化噪声完全淹没。这种精度损失在数据验收时表现为信噪比下降和特征分布畸变。
3.2 传感器噪声：数据准确性的隐形杀手
传感器噪声是 TinyML 数据质量中最难处理的问题之一。与云端数据（通常是人工录入或经过预处理的结构化数据）不同，TinyML 的原始数据直接来自物理世界的模拟信号转换，噪声来源复杂且难以完全消除。常见的噪声类型包括：热噪声（由电子运动产生，呈高斯分布）、量化噪声（由 ADC 有限分辨率导致）、1/f 噪声（低频段显著，随频率升高而降低）、环境耦合噪声（电源纹波、电磁干扰、机械共振）。
噪声对数据质量的影响并非均匀分布。在时域上，噪声可能导致信号尖峰被误判为有效事件；在频域上，噪声会抬高本底，掩盖微弱特征频率。更棘手的是，不同批次的传感器个体差异明显——同一型号的加速度计，其零偏（bias）可能相差 ±50mg，灵敏度误差可达 ±2%。如果训练数据来自一个传感器，而部署设备使用另一个传感器，模型性能会显著下降。
3.3 边缘分布漂移：训练与部署的鸿沟
分布漂移（Distribution Shift）是 TinyML 数据质量验收中最容易被忽视、却对模型长期稳定性影响最大的因素。云端模型可以通过定期重训练来适应数据分布变化，而 TinyML 设备一旦部署，往往在数月甚至数年内无法更新模型。边缘场景的分布漂移主要来自三个来源：环境变化（温度、湿度、光照、季节）、个体差异（不同用户、不同设备安装位置）、时间衰减（传感器老化、机械磨损）。
以工业预测性维护为例，振动传感器安装在电机轴承座上，训练数据采集于春季（环境温度 20°C），而部署后经历夏季（环境温度 35°C）。温度升高导致润滑脂黏度下降，振动频谱的整体能量分布发生变化，模型可能将正常的温度相关变化误判为故障前兆。这种漂移在数据验收阶段几乎无法察觉，因为验收时使用的是同一时间段采集的数据。
3.4 标注成本高：数据覆盖度的结构性瓶颈
TinyML 的标注成本远高于传统机器学习，原因在于：领域专家稀缺（如振动故障诊断需要机械工程师）、标注粒度细（需要逐帧标注而非整段标注）、数据量大（高频采样产生海量数据）、标注一致性难保证（不同专家对同一信号的判断可能不同）。标注成本高直接导致训练集覆盖度不足，尤其是罕见事件（如设备故障、异常行为）的样本数量极少。
标注成本对数据质量的影响是结构性的。当标注预算有限时，团队往往倾向于标注"容易标注"的数据（如正常状态），而忽略"难以标注"的数据（如故障状态）。这造成训练集类别严重不均衡，模型对少数类的召回率极低。更隐蔽的问题是，标注成本高会迫使团队减少数据采集的多样性——只采集容易获取的场景，而放弃需要额外部署或等待的场景。
应对标注成本高，业界已发展出多种策略：主动学习（优先标注模型最不确定的样本）、弱监督（利用规则或粗粒度标签）、半监督（利用大量未标注数据辅助训练）、迁移学习（从相关任务复用特征提取器）。但这些策略本身也引入新的数据质量风险——弱监督标签可能包含系统性偏差，主动学习可能过度关注异常样本而扭曲分布。
3.5 案例拆解：工业振动监测的数据质量陷阱
某工厂部署了一套基于 TinyML 的电机轴承故障预警系统，使用加速度计采集振动信号，目标是在轴承故障发生前 7 天发出预警。系统在实验室验证时准确率达到 92%，但部署后 3 个月内频繁误报，现场准确率不足 60%。
初始现象与约束：设备使用 STM32L4 MCU（512KB Flash，128KB RAM），加速度计采样率 4kHz，16 位精度，每次采集 2 秒数据（8000 个采样点），通过环形缓冲区存储最近 10 次采集。标注由 2 名机械工程师完成，共标注 500 段数据（400 段正常，100 段故障）。
分析判断过程：团队对误报数据进行了频谱分析，发现误报集中在两个时段：每天下午 2-4 点（工厂环境温度最高）和每周五（设备维护后）。进一步检查发现：
- 温度漂移问题：加速度计的零偏随温度变化，从 25°C 到 45°C 时零偏漂移约 80mg，导致低频段能量显著增加，被模型误判为轴承磨损特征。
- 标注偏差问题：两位工程师对"早期故障"的定义不一致，一位将 0.5g 以上的振动视为故障，另一位以 0.8g 为阈值，导致 30% 的标注样本存在标签冲突。
- 覆盖度缺口：训练数据全部采集于 3 月（环境温度 15-20°C），未覆盖夏季高温场景，模型从未见过高温下的正常振动模式。
实际操作步骤：团队采取了以下措施：
- 在数据采集链路中加入温度传感器，记录每次采集时的环境温度，建立温度-零偏补偿模型（使用 3 阶多项式拟合，在 MCU 上以查表方式实现）。
- 重新定义标注规范，明确"早期故障"的量化标准（振动能量在 2kHz-4kHz 频段超过基线 3 倍），并让两位工程师对 50 段重叠样本进行交叉标注，计算 Cohen's Kappa 系数确保一致性。
- 在 4 月到 8 月期间持续采集数据，覆盖 15°C 到 42°C 的温度范围，并按照温度区间分层抽样构建训练集。
结果对比与复盘：经过上述调整后，现场准确率从 60% 提升至 85%，误报率降低 70%。但团队也付出了代价：数据采集周期延长了 5 个月，标注工作量增加了 40%。复盘经验表明，TinyML 数据质量验收不能只关注"数据量够不够"，更要关注数据覆盖的维度是否完整（温度、湿度、工况、个体差异），以及标注标准是否可复现。
3.6 常见误区与总结复盘
在 TinyML 数据质量验收中，以下误区最为常见：
| 误区 | 表现 | 后果 | 正确做法 |
|---|---|---|---|
| 数据量至上 | 盲目追求样本数量，忽视多样性 | 模型过拟合特定场景，泛化能力差 | 按场景维度（环境、个体、时间）分层评估覆盖度 |
| 忽略传感器个体差异 | 用同一传感器采集所有训练数据 | 部署到新设备时性能骤降 | 使用多台设备采集，记录设备 ID 作为元数据 |
| 标注标准模糊 | 依赖标注者主观判断 | 标签噪声高，模型学习到错误边界 | 制定量化标注规范，进行一致性检验 |
| 忽视时间维度 | 所有数据在短期内采集完成 | 无法捕捉季节性漂移和老化效应 | 延长采集周期，覆盖完整工况循环 |
总结而言，TinyML 数据质量验收的核心挑战在于：资源受限限制了数据采集的广度和深度，传感器噪声降低了数据的信噪比，边缘分布漂移威胁模型的长期有效性，标注成本高制约了覆盖度的提升。这四个维度相互耦合，不能孤立处理。有效的验收策略应当是：在项目启动阶段就明确资源预算和标注预算，设计覆盖关键维度的数据采集计划，建立噪声评估和补偿机制，并预留分布漂移的监测和应对方案。只有这样，才能确保 TinyML 模型从实验室到现场的性能一致性。