2、基础知识：TinyML部署流程回顾、端侧评估与云端/PC评估的区别、常见离线指标的定义与适用场景
TinyML 的工程落地并非“训练完模型就结束”，而是从数据采集、模型设计、压缩量化、板端移植到端侧推理的完整闭环。在实际部署中，我们经常遇到一个尴尬局面：模型在 PC 端验证 AUC 达到 0.95，但烧录到 MCU 后，实际唤醒率却明显下降。这种偏差的根源，在于端侧评估与云端/PC 评估之间存在系统性差异。本章将首先回顾 TinyML 的标准部署流程，明确端侧评估在流程中的位置；随后深入剖析端侧评估与云端/PC 评估在硬件环境、数据分布、数值精度、实时性约束等方面的本质区别；最后系统梳理准确率、召回率、F1、混淆矩阵、AUC 等离线指标的定义、计算方式与适用场景，帮助你在模型上板前建立一套科学的评估基线。
上图展示了 TinyML 部署的四个核心阶段以及端侧评估的定位。可以看到，端侧评估并非独立环节，而是与模型训练、压缩量化、板端移植紧密耦合的验证闭环。下面我们逐一展开。
2.1 TinyML 部署流程回顾
核心原理：TinyML 部署流程可以概括为“训练-压缩-移植-评估”四步循环。训练阶段在 PC/云端完成，使用浮点精度（FP32）训练出基线模型；压缩阶段通过剪枝、权值共享、知识蒸馏和量化等手段，将模型体积和计算量压缩到 MCU 可承受的范围；移植阶段将量化后的模型转换为 TensorFlow Lite Micro、CMSIS-NN 等端侧推理框架支持的格式，并完成算子映射、内存规划和中断/ DMA 配置；评估阶段则在真实板卡上运行模型，采集离线指标（准确率、召回率等）和硬件指标（延迟、RAM/Flash 占用、功耗）。
判断方法或操作流程：在实际项目中，建议按照以下流程执行部署：
- 基线评估：在 PC 端用测试集评估 FP32 模型的准确率和 AUC，作为后续对比的基准。
- 量化感知训练（QAT）或后训练量化（PTQ）：优先尝试 PTQ，若精度损失超过 2%，则改用 QAT。
- 板端移植：使用 TFLite Micro 转换工具生成 C++ 数组，编写推理调用代码，注意对齐输入张量的维度与数据类型。
- 端侧离线评估：将测试集（或采集的真实传感器数据）通过串口/文件系统输入板卡，逐条推理并记录预测结果，计算混淆矩阵和派生指标。
- 硬件指标采集：使用逻辑分析仪或板载定时器测量单次推理延迟，通过调试接口读取 RAM/Flash 占用。
2.2 端侧评估与云端/PC 评估的区别
核心原理：端侧评估与云端/PC 评估的本质区别在于“环境真实性”和“资源约束”。PC 评估运行在 x86 架构上，使用 FP32 浮点运算，内存充足，推理过程不受实时性限制；而端侧评估运行在 ARM Cortex-M 系列等 MCU 上，使用 INT8 或 INT16 定点运算，RAM 可能仅有几十 KB，且推理必须在严格的时序窗口内完成（例如音频唤醒词识别要求 <50ms 延迟）。这些差异会导致模型在两端表现不一致。
判断方法或操作流程：下表总结了关键区别维度，帮助你快速定位评估策略：
| 对比维度 | 云端/PC 评估 | 端侧评估 | 影响说明 |
|---|---|---|---|
| 数值精度 | FP32 浮点 | INT8/INT16 定点 | 量化误差可能导致精度下降 1%-5% |
| 数据输入 | 静态文件批量读取 | 实时传感器数据流 | 数据时序、噪声特性不同 |
| 内存约束 | 无限制 | RAM 通常 16-512 KB | 内存不足时可能触发算子 fallback |
| 实时性 | 无要求 | 硬实时或软实时 | 延迟超标会导致丢帧或系统卡顿 |
| 功耗 | 不关注 | 电池供电场景严格限制 | 影响推理频率和唤醒策略 |
| 算子支持 | 完整 TensorFlow 算子 | 仅支持 TFLM 子集 | 不支持的算子需替换或重写 |
案例拆解：以关键词唤醒（KWS）模型为例，我们在 PC 端用 1000 条干净语音样本评估，准确率为 95%。移植到 Cortex-M4 平台（主频 80MHz，RAM 64KB）后，使用 INT8 量化模型，准确率降至 91%。进一步分析发现，量化后部分权重分布偏移，导致对轻声唤醒词的敏感度下降。通过改用 QAT 并在训练时加入噪声增强，端侧准确率回升至 93.5%。这个案例说明，端侧评估必须考虑量化误差和真实数据分布，不能直接套用 PC 端结果。
2.3 常见离线指标的定义与适用场景
核心原理：离线指标用于在固定数据集上量化模型性能。在 TinyML 场景中，由于端侧推理速度慢、数据采集成本高，离线指标是评估模型质量的主要手段。常用指标包括准确率（Accuracy）、精确率（Precision）、召回率（Recall）、F1 分数、混淆矩阵（Confusion Matrix）和 AUC（Area Under ROC Curve）。
判断方法或操作流程：选择指标时需根据任务类型和业务目标：
- 准确率：所有样本中预测正确的比例。适用于类别均衡的分类任务，如手势识别（5 类，每类样本数相近）。
- 精确率：预测为正类的样本中实际为正类的比例。适用于误报代价高的场景，如异常检测（误报警会打扰用户）。
- 召回率：实际为正类的样本中被正确预测的比例。适用于漏报代价高的场景，如跌倒检测（漏报可能导致严重后果）。
- F1 分数：精确率与召回率的调和平均。适用于类别不平衡且需要平衡误报与漏报的场景。
- 混淆矩阵：展示每个类别的预测分布，用于分析错误模式（如“将 A 类误判为 B 类”）。
- AUC：ROC 曲线下面积，衡量模型在不同阈值下的排序能力。适用于二分类且需要选择最优阈值（如唤醒词检测中调整灵敏度）。
案例拆解：假设我们开发一个基于加速度计的跌倒检测模型，测试集包含 200 个跌倒样本和 800 个日常活动样本。模型 A 的准确率为 92%，但召回率仅为 70%（漏报 60 个跌倒）；模型 B 的准确率为 88%，但召回率为 95%（漏报 10 个跌倒）。从准确率看，模型 A 更优，但从业务角度看，模型 B 更安全。此时应使用 F1 分数或直接以召回率为核心指标。计算模型 B 的 F1：精确率 = 190/(190+80)=0.704，召回率=0.95，F1=2*0.704*0.95/(0.704+0.95)=0.809。而模型 A 的 F1 为 0.757。因此，在跌倒检测场景中，模型 B 更合适。
常见误区或总结复盘：
- 误区一：只看准确率。在类别不平衡时（如异常检测中负样本占 99%），准确率会虚高，掩盖模型失效。
- 误区二：忽略混淆矩阵。混淆矩阵能揭示具体错误类型，例如在关键词识别中，混淆矩阵可以显示“是”与“不是”的混淆程度，从而指导数据增强。
- 误区三：AUC 与业务阈值脱节。AUC 反映的是排序能力，但实际部署需要选定一个阈值。建议在端侧评估时，同时输出 ROC 曲线并标注当前阈值对应的精确率/召回率。
- 误区四：指标计算方式不一致。端侧评估时，由于浮点转定点，预测概率分布可能偏移，导致按 PC 端阈值分类时结果不同。建议在端侧重新校准阈值。