课程导入：为什么TinyML模型评估不能只看准确率？
TinyML（微型机器学习）正将人工智能推向微控制器、传感器节点和电池供电的边缘设备。当模型被部署在仅有几十KB内存、主频几十MHz的MCU上时，评估方式与云端AI有着本质差异。许多工程师在初涉TinyML时，习惯性地用Accuracy（准确率）作为唯一指标，却往往在真实业务场景中遭遇“模型指标好看，实际效果糟糕”的困境。例如：一个用于工业设备异常检测的模型，若异常样本仅占全部数据的1%，那么一个“永远预测正常”的模型也能达到99%的准确率——但这显然毫无价值。本章将系统拆解TinyML模型评估的核心逻辑，厘清混淆矩阵、TP/FP/TN/FN与业务成本之间的深层关系，帮助你在资源受限的嵌入式环境中做出科学的模型选型与部署决策。
1.1 学习目标与课程结构
本章作为整个TinyML评估体系的开篇，旨在建立一套“业务导向”的评估思维。完成本章学习后，你将能够：（1）准确说出混淆矩阵四个象限的物理含义，并能在嵌入式数据集上手动计算TP/FP/TN/FN；（2）解释为什么在类别不平衡场景下Accuracy会失效，并能用具体数据说明；（3）理解F1-Score与Recall的数学定义及适用边界；（4）建立“业务成本矩阵”的概念，能够将FP与FN的代价量化为具体业务损失；（5）掌握TinyML场景下评估指标选择的决策路径。
课程结构上，本章分为四个递进模块：首先从混淆矩阵出发，建立基础术语体系；其次剖析Accuracy失效的数学本质；然后引入Precision、Recall、F1等衍生指标；最后将业务成本与评估指标结合，形成完整的决策框架。后续章节将在此基础上深入讨论阈值调优、成本敏感学习、模型压缩对指标的影响等进阶主题。
1.2 核心概念：混淆矩阵与TP/FP/TN/FN
混淆矩阵（Confusion Matrix）是评估分类模型最基础的工具。在二分类问题中，它将预测结果与真实标签组合成2×2矩阵。假设正类（Positive）代表我们关注的事件（如“设备故障”“入侵行为”“疾病阳性”），负类（Negative）代表正常状态。四个象限定义如下：
- TP（True Positive）：实际为正类，模型也预测为正类。例如：设备确实故障，模型正确报警。
- FP（False Positive）：实际为负类，模型却预测为正类。即“误报”。例如：设备正常，模型误报警。
- TN（True Negative）：实际为负类，模型也预测为负类。正确识别正常状态。
- FN（False Negative）：实际为正类，模型却预测为负类。即“漏报”。例如：设备已故障，模型未报警。
在TinyML场景中，这四个数值直接决定了模型在真实硬件上的行为表现。以振动传感器故障诊断为例，一个部署在STM32上的二分类模型，其输出结果会触发继电器动作或LED告警。若FP过高，则会导致频繁的虚假告警，消耗维护人员精力，甚至引发“狼来了”效应；若FN过高，则设备故障被忽视，可能造成产线停机甚至安全事故。
| 象限 | 预测=正类 | 预测=负类 | TinyML典型业务含义 |
|---|---|---|---|
| 实际=正类 | TP（正确报警） | FN（漏报） | 故障被及时发现 vs 故障被忽视 |
| 实际=负类 | FP（误报） | TN（正确静默） | 无故障却告警 vs 正常运行不打扰 |
1.3 Accuracy失效的数学本质与案例拆解
Accuracy的定义为：Accuracy = (TP + TN) / (TP + FP + TN + FN)。当数据集中正负样本比例严重失衡时，这个指标会变得极具欺骗性。考虑一个工业异常检测场景：某产线正常运行时间占比99%，故障占比1%。若模型简单粗暴地“永远预测正常”，其Accuracy高达99%。但这个模型毫无用处——它无法识别任何故障。
更隐蔽的情况是：模型学到了一些与故障无关的噪声特征，在测试集上Accuracy达到95%，但部署后由于数据分布漂移，实际Accuracy骤降至60%。这是因为Accuracy对先验分布极其敏感，且无法区分FP与FN的代价差异。
我们用一个具体案例来拆解。假设某智能门锁的TinyML人脸识别模块，用于区分“家庭成员”（正类）与“陌生人”（负类）。训练数据中家庭成员出现频率为每100次开锁出现5次（5%）。模型A的测试结果如下：
- TP = 40（正确识别家庭成员40次）
- FN = 10（漏识别家庭成员10次）
- FP = 30（将陌生人误识别为家庭成员30次）
- TN = 920（正确拒绝陌生人920次）
计算Accuracy = (40+920)/1000 = 96%。表面看模型表现优秀。但分析业务成本：FN（漏识别家庭成员）导致用户体验差，用户需要手动输入密码；FP（误放陌生人）则意味着严重的安全漏洞。若一次安全漏洞造成的损失（如财物被盗、隐私泄露）是用户体验损失的100倍，那么单纯看Accuracy完全无法反映模型的实际风险。
进一步计算：Recall（召回率）= TP/(TP+FN) = 40/50 = 80%，意味着有20%的家庭成员被拒之门外；Precision（精确率）= TP/(TP+FP) = 40/70 ≈ 57.1%，意味着每次自动开锁中有近43%是误放。这两个指标比Accuracy更能揭示模型的真实行为。
1.4 Precision、Recall、F1与业务成本矩阵
为了更全面地评估模型，我们引入三个衍生指标：
- Precision（精确率） = TP / (TP + FP)。衡量“模型报警中有多少是真正故障”。高Precision意味着误报少。
- Recall（召回率） = TP / (TP + FN)。衡量“真实故障中有多少被模型发现”。高Recall意味着漏报少。
- F1-Score = 2 × (Precision × Recall) / (Precision + Recall)。Precision与Recall的调和平均，在两者之间取得平衡。
在TinyML中，Precision与Recall往往存在此消彼长的关系。提高Recall通常需要降低判定阈值，使模型更“敏感”，但这会增加FP；提高Precision则需要提高阈值，减少误报，但可能增加FN。F1-Score提供了一个综合度量，但它默认Precision与Recall的代价相等——这在真实业务中很少成立。
因此，我们引入业务成本矩阵（Cost Matrix）。设C(FP)为一次误报的代价（如人工核查成本、告警疲劳导致的信任损失），C(FN)为一次漏报的代价（如设备损坏、安全事故）。则总业务成本为：
Total Cost = FP × C(FP) + FN × C(FN) + TP × C(TP) + TN × C(TN)
其中 C(TP) 通常为0（正确报警无额外成本），C(TN) 为0（正确静默无成本）。以智能门锁为例，假设C(FP) = 10元（安全人员远程核查的通信与人力成本），C(FN) = 1000元（一次安全漏洞的平均损失）。则模型A的总成本 = 30×10 + 10×1000 = 10300元。若另一个模型B的Accuracy略低（95%），但FP=5，FN=15，则总成本 = 5×10 + 15×1000 = 15050元。虽然模型B的Accuracy更高，但业务成本反而更高。这说明：评估指标必须与业务成本挂钩，而非孤立地追求某个统计量。
| 指标 | 计算公式 | 业务含义 | TinyML适用场景 |
|---|---|---|---|
| Accuracy | (TP+TN)/总数 | 整体正确率 | 类别均衡、代价对称 |
| Precision | TP/(TP+FP) | 报警的可信度 | 误报代价高（如告警疲劳） |
| Recall | TP/(TP+FN) | 故障的发现率 | 漏报代价高（如安全事件） |
| F1-Score | 2PR/(P+R) | P与R的平衡 | P与R代价相近时 |
| 业务成本 | FP×C(FP)+FN×C(FN) | 实际经济损失 | 所有TinyML商业部署 |
1.5 常见误区与总结复盘
在TinyML模型评估实践中，工程师常陷入以下误区：
- 盲目追求高Accuracy：在类别不平衡数据上，Accuracy高不代表模型有效。必须同时查看混淆矩阵。
- 忽略阈值的影响：TinyML模型输出的概率值需要设定阈值才能转化为类别。改变阈值会同时改变TP/FP/TN/FN。许多工程师只报告默认阈值（0.5）下的指标，而实际部署时可能需要根据业务成本调整阈值。
- 在测试集上过拟合评估指标：反复在同一个测试集上调整模型以提升F1，会导致指标虚高，部署后性能下降。应使用交叉验证或独立验证集。
- 未考虑硬件资源对指标的影响：量化（如INT8）后的模型精度会下降，导致FP/FN变化。评估时必须使用部署后的实际模型（而非浮点模型）进行测试。
- 忽视时间维度：TinyML设备长期运行，数据分布可能漂移。初始评估指标良好，但数月后可能恶化。需要建立持续监控机制。