4、模型训练准备：数据采集与预处理、标注规范、训练框架选择（TensorFlow/PyTorch）、模型导出格式（ONNX/Keras/TFLite）

在STM32CubeAI的端侧推理部署链路中，模型训练前的数据工程与框架选型直接决定了最终部署的精度上限与硬件适配效率。本章聚焦于从原始传感器数据到可部署模型文件的全流程准备，涵盖数据采集策略、预处理流水线、标注规范、训练框架对比以及模型导出格式的工程约束。与纯云端AI不同，嵌入式AI的数据准备必须同时考虑目标硬件的算力、内存带宽以及量化敏感性，因此本章内容将围绕“为STM32部署而准备数据与模型”这一核心目标展开。

4.1 数据采集策略与工程约束

核心原理：嵌入式AI模型的数据采集不同于互联网大数据场景，其核心约束在于目标域匹配。STM32端侧模型通常处理来自MEMS加速度计、麦克风、红外阵列或环境传感器的实时数据流。采集的数据必须反映实际部署环境中的噪声分布、温度漂移、安装位置偏差以及个体差异。例如，一个用于工业电机振动监测的模型，如果训练数据仅在实验室恒温、无振动干扰的台架上采集，部署到现场后准确率可能从95%骤降至60%以下。

操作流程：数据采集需遵循“场景穷举-比例分配-质量门控”三步法。首先，列出所有预期部署场景（如手持设备的不同握持姿势、工业设备的启停阶段、可穿戴设备的不同佩戴松紧度）。其次，按场景重要性分配数据量比例，建议核心场景占比不低于60%，边缘场景（如极端温度、强电磁干扰）占比10%-20%。最后，设置质量门控：剔除传感器饱和、通信丢包、时间戳异常的数据段。

4.2 预处理流水线设计

核心原理：预处理的目标是消除与任务无关的变异，同时保留关键判别信息。对于STM32部署，预处理还需考虑计算开销——复杂的预处理算法（如小波变换）在MCU上可能消耗大量CPU周期，因此应优先选择线性滤波、滑动窗口、简单归一化等低成本操作。

标准流水线：典型的传感器数据预处理顺序为：原始数据 → 去直流分量（减去均值）→ 带通滤波（如Butterworth 4阶，截止频率根据物理特征设定）→ 滑动窗口切片（重叠率50%-75%）→ 归一化（Min-Max或Z-score）→ 数据增强（可选）。其中归一化参数（均值、标准差或最大值、最小值）必须在训练集上计算并保存，部署时在MCU端使用相同的静态参数进行推理前处理。

# 以加速度计数据为例的预处理伪代码
def preprocess(raw_signal, fs=200):
    # 1. 去直流
    signal = raw_signal - np.mean(raw_signal, axis=0)
    # 2. 带通滤波 0.5Hz - 45Hz
    b, a = butter(4, [0.5/(fs/2), 45/(fs/2)], btype='band')
    signal = filtfilt(b, a, signal, axis=0)
    # 3. 滑动窗口 2s，步长 0.5s
    windows = sliding_window(signal, window_size=fs*2, stride=int(fs*0.5))
    # 4. 归一化（使用训练集统计量）
    windows = (windows - mean_train) / std_train
    return windows

4.3 标注规范与质量控制

核心原理：标注质量直接决定模型上限。在嵌入式AI中，标注不仅是打标签，还需要时间边界精确。例如，在关键词唤醒任务中，标注的起始/结束时间点偏差超过100ms，就会显著影响模型对语音边界的感知。对于连续传感器流，建议采用“事件标记+分段确认”的标注流程：先由算法自动检测候选事件段，再由人工确认或修正边界。

标注规范清单：

• 类别定义：类别必须互斥且完备，例如“静止/行走/跑步/上下楼”，避免“其他”类占比过高（应控制在5%以内）。
• 标签格式：推荐使用JSON或CSV格式，每条记录包含：样本ID、起始时间戳、结束时间戳、类别ID、传感器通道索引、采集设备ID。
• 一致性校验：至少两名标注员独立标注同一批数据（约10%），计算Cohen's Kappa系数，要求≥0.8。若低于0.7，需重新定义标注规则并培训。
• 时间戳对齐：确保传感器数据的时间戳与标注工具的时间基准一致，建议使用NTP同步或硬件触发信号。

4.4 训练框架选择：TensorFlow vs PyTorch

核心原理：STM32CubeAI的模型转换工具链对TensorFlow（Keras）和ONNX格式支持最成熟，PyTorch模型需先导出为ONNX再转换。因此框架选择需综合考虑部署链路便捷性、量化感知训练支持度以及团队技术栈。

对比分析：

选择建议：对于工业级产品开发，优先选择TensorFlow/Keras，因为其与STM32CubeAI的集成度最高，且QAT支持完善。若团队已有PyTorch模型，则务必在训练阶段就加入ONNX导出验证，避免在部署阶段才发现算子不支持。

4.5 模型导出格式：ONNX / Keras / TFLite

核心原理：模型导出是连接训练与部署的桥梁。STM32CubeAI支持三种主要输入格式：Keras (.h5)、TFLite (.tflite) 和 ONNX (.onnx)。选择哪种格式取决于是否需要量化以及目标MCU的算力。

格式选择路径：

1. Keras (.h5)：适合浮点模型，STM32F4/H7系列（带FPU）可直接运行。导出最简单，但模型体积较大（权重为float32）。
2. TFLite (.tflite)：支持动态范围量化或全整型量化（int8），模型体积可缩小4倍，推理速度提升2-3倍。适合STM32F0/G0等无FPU的低成本MCU。
3. ONNX (.onnx)：作为中间格式，用于从PyTorch或其他框架转换。需注意ONNX算子集版本与STM32CubeAI的兼容性（建议 opset 11-13）。

# TensorFlow 导出 TFLite 量化模型示例
import tensorflow as tf

# 加载训练好的 Keras 模型
model = tf.keras.models.load_model('gesture_model.h5')

# 转换并量化
converter = tf.lite.TFLiteConverter.from_keras_model(model)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = representative_dataset_gen  # 校准数据集
tflite_model = converter.convert()

# 保存
with open('gesture_model_quant.tflite', 'wb') as f:
    f.write(tflite_model)

4.6 常见误区与总结复盘

误区一：数据越多越好。在嵌入式场景中，数据量超过一定阈值后，模型精度提升趋于平缓，但训练时间和数据标注成本线性增长。建议通过学习曲线判断：当验证集精度不再随训练集增加而提升时，应转向优化预处理或模型结构。

误区二：忽略量化感知训练。直接训练浮点模型，再使用后训练量化（PTQ），在STM32上可能因激活值分布偏移导致精度下降3%-8%。正确做法是在训练阶段就模拟量化误差（QAT），让模型权重适应低比特表示。

误区三：预处理参数硬编码在训练脚本中。部署时MCU端无法运行Python预处理代码，必须将归一化均值/标准差、滤波系数等参数固化为C数组，并确保训练与推理使用完全一致的预处理逻辑。

总结复盘：模型训练准备阶段的核心交付物包括：① 与目标硬件匹配的数据集（含标注文件）；② 可复现的预处理流水线（含参数文件）；③ 训练框架与模型结构定义；④ 导出后的模型文件（.h5/.tflite/.onnx）及其量化校准记录。建议建立版本管理，将数据版本、代码版本、模型版本三者关联，便于追溯部署后的问题。在进入STM32CubeAI工具链之前，务必使用验证集数据模拟端侧推理（如通过TFLite解释器或ONNX Runtime），确认模型输出与训练时一致，再进入嵌入式集成阶段。