3、问题剖析：为什么TinyML中类别不平衡更严重——数据采集成本、边缘设备存储限制、标注困难

TinyML 的落地场景往往高度垂直，例如工业设备振动监测、农业虫害声学识别、可穿戴跌倒检测、电力设备异响诊断等。在这些场景中，模型需要从传感器流中识别出“异常”或“目标事件”，而这些事件天然是稀疏的——设备 99% 的时间都在正常运行，故障或目标事件只占极短的时间窗口。这种天然的不平衡在云端大数据场景中可以通过海量数据收集来缓解，但在 TinyML 的约束下却被急剧放大。本章将深入剖析 TinyML 中类别不平衡问题为何比传统机器学习更严重，从数据采集成本、边缘设备存储限制、标注困难三个维度展开，并给出工程化的应对思路。

3.1 数据采集成本：目标事件的稀疏性与现场约束

核心原理：事件稀疏性决定了数据分布的不平衡上限

TinyML 应用所监测的目标事件在时间轴上往往呈现极端的稀疏性。以工业电机轴承故障检测为例，一个健康轴承在正常工况下可以连续运行数千小时，而故障信号（如早期点蚀、磨损碎片撞击）可能只持续几毫秒到几百毫秒。如果以 16kHz 采样率采集振动数据，正常运行 1 小时产生约 5760 万采样点，而故障事件可能只占其中不到 0.1%。这种物理层面的稀疏性直接决定了：无论后续采用何种采样策略，正样本的数量都极其有限。

更关键的是，TinyML 的部署环境往往不允许“等待”目标事件自然发生。例如在农业害虫声学监测中，害虫啃食声可能只在特定季节、特定温湿度条件下出现；在电力设备局放检测中，局部放电信号可能只在电压峰值附近出现。如果依赖自然发生来采集数据，一个完整的采集周期可能需要数月甚至跨年，这在产品研发周期内是不可接受的。

判断方法：评估数据采集成本的三维模型

在实际项目中，建议在数据采集前先进行“事件密度评估”：在目标现场部署临时采集装置，记录 72 小时内目标事件的自然发生次数。如果 72 小时内正样本事件少于 50 次，则基本可以判定该场景属于“高采集成本”类别，必须提前规划主动数据生成策略（如故障注入、仿真数据、迁移学习）。

案例拆解：工业电机故障声学监测的数据采集困境

某制造企业希望部署一个基于麦克风阵列的电机异响检测系统，目标是识别轴承早期磨损的异常声音。项目初期团队计划采集 10,000 条异常音频样本和 10,000 条正常音频样本。然而实际执行时发现：

• 初始现象：在产线上连续采集 2 周，仅获得 37 条异常音频，且其中 22 条是操作人员敲击外壳产生的伪异常。
• 关键数据：电机正常运行时声压级约 78dB，异常声音出现时声压级仅提升 2-3dB，且持续时间 80% 小于 200ms。
• 分析判断：自然采集需要约 8 个月才能凑齐 1000 条有效正样本，远超项目 3 个月的时间预算。
• 实际操作：团队改为“半物理仿真”方案——在实验室中搭建同型号电机测试台，通过电火花加工在轴承滚道制造不同尺寸的凹坑，模拟 5 种不同磨损程度；同时采集 20 种不同转速/负载组合下的数据。最终获得 2,000 条仿真故障样本，并用真实产线的 37 条样本做验证。
• 结果对比：仅用仿真数据训练的模型在真实产线测试中召回率仅 41%；加入 37 条真实样本进行微调后，召回率提升至 68%。虽然仍不理想，但已证明“仿真+少量真实”的混合策略比纯等待自然采集更可行。
• 复盘经验：数据采集成本高的场景，必须将“主动生成数据”作为第一优先级，同时保留少量真实样本用于域适应校准。

3.2 边缘设备存储限制：数据留存与模型训练的博弈

核心原理：存储容量约束改变了数据收集的范式

典型的 TinyML 设备（如 Cortex-M4 内核 MCU）通常配备 512KB 到 2MB 的 Flash 存储，RAM 则更小（64KB-256KB）。以 16kHz/16bit 单通道音频为例，1 分钟音频数据约 1.92MB，这意味着设备甚至无法在本地缓存 1 分钟的原始音频。对于振动传感器（通常以 3.2kHz 采样三轴），1 小时数据约 138MB，远超存储能力。

这种存储限制带来一个根本性矛盾：模型训练需要大量数据，但边缘设备无法保存大量数据。云端训练模式要求设备将原始数据上传，但在许多工业场景中，现场不具备稳定网络；即便有网络，持续上传大量数据也会消耗流量和功耗。因此，TinyML 项目往往只能依赖设备端“在线特征提取+选择性存储”的方式，即设备只保存触发事件前后的短窗口数据，或者只保存压缩后的特征向量。

操作流程：边缘数据留存策略设计

1. 确定关键窗口：根据目标事件的物理持续时间，确定需要保存的“事件前-事件中-事件后”窗口长度。例如电机异响通常持续 50-300ms，则保存事件前 100ms + 事件中 300ms + 事件后 100ms，共 500ms 窗口。
2. 设计触发机制：使用简单的能量检测或阈值比较作为“粗触发”，当信号超过预设阈值时启动缓存保存。阈值设置要避免过于灵敏导致存储耗尽，也要避免过于迟钝导致漏采。
3. 特征降维存储：如果原始波形无法保存，则提取 MFCC、FFT 频谱、时域统计特征等，将每个事件压缩为 50-200 维特征向量，存储量可降低 100 倍以上。
4. 定期回传：利用设备空闲时段（如夜间）通过低功耗蓝牙或 LoRa 将缓存数据批量回传到边缘网关或云端。

常见误区：认为“云存储可以解决一切”

许多团队在项目初期假设“先把数据传到云端，云端存储无限”。但在实际部署中，以下问题会迅速打破这个假设：

• 网络不可用：工厂地下室、野外变电站、移动设备等场景经常无信号或信号弱。
• 功耗预算：Wi-Fi 模块传输 1MB 数据约消耗 0.5-1.5 焦耳，对于电池供电的设备，频繁传输会显著缩短续航。
• 隐私合规：某些场景（如医疗、军事）禁止原始数据外传。

因此，TinyML 的数据策略必须默认“设备端只保留最小必要数据”，并将数据压缩、特征提取、选择性存储作为系统设计的一部分，而非事后补救。

3.3 标注困难：专家依赖与时间同步挑战

核心原理：TinyML 数据的标注复杂度远超图像分类

图像分类的标注相对直观——人眼可以判断图片中是否有猫。但 TinyML 处理的大多是时序信号（振动、声音、电流、加速度），标注者需要具备领域知识才能判断“这段振动信号是否代表轴承故障”。更复杂的是，故障的起始和结束时间点往往不清晰，标注者需要精确到毫秒级的时间边界，这远超人类感知精度。

以心音信号分类为例，医生需要同时参考心电图（ECG）来定位心音中的 S1、S2 心音成分，才能判断是否存在收缩期杂音。这种多模态同步标注需要专业设备支持，且标注一个 10 秒的心音片段可能需要 5-10 分钟。如果目标事件只占信号的 2%，则标注效率极低——大量时间花在“确认没有事件”上。

判断方法：标注难度评估清单

案例拆解：可穿戴跌倒检测的标注困境

某团队开发基于加速度计的老年人跌倒检测系统。他们从公开数据集获取了 5,000 条跌倒样本，但在自采数据时发现：

• 初始现象：招募 20 名志愿者进行模拟跌倒，采集了 1,200 条“跌倒”数据，但标注时发现 30% 的数据实际是“快速坐下”或“弯腰捡物”。
• 关键输入数据：志愿者佩戴三轴加速度计（100Hz），同时用高速摄像机记录动作过程作为标注参考。
• 分析判断：仅靠加速度计波形无法区分“跌倒”和“快速坐下”——两者都表现为短时高加速度冲击。需要结合角速度（陀螺仪）和姿态变化才能区分。
• 实际操作：团队重新设计标注协议：要求标注者同时观看视频和加速度波形，并定义“跌倒”为“身体失去平衡并撞击地面”的事件。经过 3 轮标注-讨论-修正，最终将标注一致性（Cohen's Kappa）从 0.52 提升到 0.81。
• 结果对比：使用高质量标注数据训练的模型，在真实老年人测试集上的特异性从 82% 提升到 94%，误报率显著下降。
• 复盘经验：标注困难场景必须建立“标注手册+多人交叉验证+专家仲裁”的流程，且标注成本应计入项目总预算的 30% 以上。

3.4 综合应对框架：从根源缓解不平衡

理解了三个根源之后，TinyML 工程师需要建立一套系统性的应对框架。以下表格总结了针对每个根源的工程策略：

在实际项目中，这三个根源往往相互交织。例如存储限制导致无法保存足够多的原始数据，进而使得标注者缺乏足够的上下文信息，标注难度进一步上升。因此，应对策略必须是组合拳：在数据采集阶段就考虑存储和标注的约束，在系统设计阶段就预留数据回传和标注迭代的接口。