2、TinyML数据基础：传感器数据特点、资源约束、数据质量对模型性能的影响
TinyML 的“小”不仅体现在模型参数量上，更体现在数据获取、存储、处理与标注的全链路约束中。与云端 AI 动辄 TB 级训练集不同，TinyML 项目往往面对的是低采样率、短时长、多噪声、强时序依赖的传感器数据，且设备端 Flash/RAM 通常以 KB 计。理解这些数据特性与资源边界，是后续进行重复样本清洗、异常样本剔除和错误标签定位的前提——因为很多在云端看似“标准”的清洗策略，在 TinyML 场景下会因算力或存储限制而失效。
2.1 传感器数据的本质特征
TinyML 的数据几乎全部来自物理世界的传感器——加速度计、陀螺仪、麦克风、温湿度、气压、红外、磁力计等。这些数据与图像、文本有本质区别，最核心的差异在于时间维度的强相关性。一个加速度计的 X 轴读数在 t 时刻与 t-1、t-2 时刻高度相关，单独看某一帧数据几乎无法判断当前动作状态，必须结合上下文窗口。这意味着在数据清洗时，不能像处理图像那样随机打乱样本后独立判断——重复样本、异常样本的判定必须考虑时间连续性。
第二个显著特点是噪声来源复杂。传感器噪声可能来自电源纹波、电磁干扰、机械振动、温度漂移、量化误差等。例如，在工业电机旁部署振动传感器，50Hz 工频干扰会叠加在有效信号上；在可穿戴设备中，人体运动伪迹会污染 PPG 心率信号。这些噪声在频域上可能与真实信号重叠，简单的低通滤波反而会滤除有效信息。因此，数据清洗的第一步不是“过滤”，而是识别噪声类型——是随机白噪声、周期性干扰，还是突发脉冲。
第三个特点是类间不均衡极其严重。以人体活动识别（HAR）为例，用户一天中“走路”可能占 60% 的时间，“跑步”占 10%，“跌倒”可能一周都不会发生一次。如果直接采集原始数据训练，模型会严重偏向多数类。更麻烦的是，少数类（如跌倒、异常工况）恰恰是 TinyML 应用最关心的安全事件。数据清洗阶段就需要考虑重采样、合成少数类样本，但受限于设备资源，不能使用云端常用的 SMOTE 等复杂算法。
2.2 设备资源约束对数据处理的限制
典型的 TinyML 设备（如 Cortex-M4 内核 MCU）资源如下：Flash 256KB~1MB，RAM 16~256KB，主频 48~120MHz。这些数字意味着什么？一个 3 轴加速度计以 50Hz 采样、每个样本 2 字节，存储 1 分钟的数据需要 3×50×60×2 = 18KB——已经占用了入门级设备 RAM 的 70% 以上。因此，数据无法在设备端完整缓存，必须采用“边采集边处理”的流式架构。
| 资源项 | 典型容量 | 对数据清洗的影响 |
|---|---|---|
| Flash 存储 | 256KB~1MB | 只能保存模型权重和少量校准数据，无法存储完整训练集 |
| RAM 内存 | 16~256KB | 滑动窗口通常只能容纳 1~3 秒的传感器数据 |
| CPU 算力 | 数十 MHz | 无法运行复杂的统计检验或迭代聚类算法 |
| 电池容量 | 几十~几百 mAh | 每次数据清洗操作都要考虑功耗预算 |
这些约束直接决定了数据清洗策略的选择。例如，云端常用的 K-Means 聚类去异常需要迭代计算质心，在 MCU 上运行一次可能耗时数百毫秒，且需要存储全部样本——这在资源上是不可行的。TinyML 更倾向于使用单遍扫描算法（如基于中位数偏差的鲁棒 Z-score）或轻量级规则（如阈值+持续时间判定）。
另一个容易被忽视的约束是数据标注的“离线-在线”分离。设备端采集的原始数据通常通过蓝牙或串口导出到 PC 上进行标注和训练，训练好的模型再部署回设备。这意味着数据清洗可以分两阶段：离线阶段（在 PC 上做深度清洗）和在线阶段（在设备上做轻量过滤）。离线阶段可以奢侈地使用复杂算法，在线阶段必须精简到几十行 C 代码。
2.3 数据质量如何影响模型性能
数据质量对 TinyML 模型的影响可以用“三重放大效应”来概括。第一重：模型容量小，参数少，每个训练样本对梯度更新的影响权重更大，一个错误标签可能把决策边界拉偏。第二重：传感器数据维度低（通常 3~6 维），特征空间稀疏，异常样本更容易形成“孤立岛”，导致模型在局部区域过拟合。第三重：部署环境与训练环境分布不一致，如果训练数据中混入了特定噪声模式，模型会把这些噪声当作有效特征，部署到新环境后立即失效。
以关键词唤醒（KWS）任务为例，训练集中如果混入了带有风扇背景噪声的“Hey Device”录音，模型可能学会利用频谱中的周期性纹波来辅助判断。当部署到安静的卧室时，这种“伪特征”消失，唤醒率从 95% 骤降到 60%。这就是数据质量问题的典型表现——模型没有错，错的是数据中隐藏的虚假相关性。
具体来说，数据质量问题可分为三类，每类对模型的影响机制不同：
- 重复样本：导致模型对某些模式过度加权，降低泛化能力。在 TinyML 中，由于数据采集成本高，重复样本往往被误认为“增加了数据量”，实际上它们只是放大了已有偏差。
- 异常样本：包括传感器失灵产生的全零帧、突变尖峰、漂移段。这些样本会拉大损失函数的梯度，使训练不稳定，甚至导致量化后的模型出现 NaN 输出。
- 错误标签：这是最隐蔽的问题。传感器数据不像图像那样直观，标注者很难准确判断一段加速度波形是“上楼”还是“下楼”，错误标签率可能高达 10%~20%。
2.4 案例：可穿戴跌倒检测设备的数据质量陷阱
我们以一个真实的可穿戴跌倒检测项目为例，说明数据基础分析的重要性。设备使用 MPU6050 六轴传感器（3 轴加速度+3 轴陀螺仪），采样率 50Hz，部署在老人腰部。目标是在跌倒发生后 2 秒内发出警报。
初始数据采集：在实验室招募 10 名志愿者，每人执行 5 种动作（走路、坐下、躺下、慢跑、模拟跌倒），每种动作重复 20 次，共采集 1000 个样本，每个样本为 3 秒窗口（150 帧×6 通道）。数据导出后在 PC 上标注。
初步训练结果：使用一个 3 层卷积网络（参数量约 18K），训练集准确率 98.2%，验证集准确率 91.5%。看似正常，但部署到真实老人家中后，第一周就出现了 3 次误报和 1 次漏报。
数据质量分析：我们回查训练数据，发现三个问题：
- 重复样本：志愿者“模拟跌倒”时，有 3 次动作几乎完全一致（因为志愿者刻意模仿第一次的动作），导致这 3 个样本在时间序列上高度相似，模型对特定跌倒轨迹过拟合。
- 异常样本：有一次“慢跑”数据中，传感器电池电量不足，导致最后 0.5 秒数据出现线性漂移（加速度值整体偏移 0.3g）。这个异常样本被模型学习为“慢跑”的特征之一。
- 错误标签：志愿者“坐下”和“躺下”的动作在加速度波形上非常相似，标注者将 2 个“躺下”样本误标为“坐下”。
清洗过程：我们采用三步清洗策略。第一步，计算每个样本与同类别其他样本的 DTW（动态时间规整）距离，将距离小于阈值的样本标记为重复，最终删除 7 个重复样本。第二步，检查每个样本的统计特征（均值、方差、最大变化率），将方差超过类别均值 3 倍以上的样本标记为异常，人工确认后删除 2 个异常样本。第三步，使用置信学习（Confident Learning）方法，训练一个初始模型后，找出预测概率与标签不一致的样本，人工复核后修正了 2 个错误标签。
结果对比：清洗后的数据集（989 个样本）重新训练，验证集准确率提升到 94.2%，部署后第一周误报降为 1 次，漏报 0 次。更重要的是，模型在量化到 8-bit 后，精度损失从清洗前的 4.7% 降低到 1.2%。
复盘经验：这个案例揭示了 TinyML 数据清洗的三个核心原则。第一，重复样本的判定必须基于时间序列相似度，而不是简单的逐帧比较。第二，异常样本的检测要结合物理知识——电池电量不足导致的漂移，仅靠统计方法难以识别，需要知道传感器硬件特性。第三，错误标签的修正需要迭代，一次清洗往往不够，需要“训练-清洗-再训练”的循环。
2.5 常见误区与总结
在 TinyML 数据基础阶段，工程师常犯以下错误：
- 误区一：盲目追求数据量。在云端，更多数据通常意味着更好性能；在 TinyML，由于模型容量小，数据量超过一定阈值后收益急剧递减，反而增加了清洗难度和存储压力。
- 误区二：忽略时间连续性。将传感器数据当作独立样本处理，随机打乱后划分训练/验证集。这会导致相邻时间窗口的数据同时出现在训练集和验证集中，造成“数据泄漏”，验证集准确率虚高。
- 误区三：清洗过度。使用过于激进的异常检测算法，删除了大量“看似异常但实际有效”的样本（如跌倒瞬间的剧烈波动）。TinyML 的数据量本来就少，过度清洗可能导致训练数据不足。
- 误区四：离线与在线处理脱节。在 PC 上使用了复杂的清洗算法（如孤立森林），但部署到设备端后无法复现同样的清洗逻辑，导致推理时的输入分布与训练时不匹配。