3、验收指标表的作用：为什么需要统一管理资源预算和业务指标，如何避免指标冲突
TinyML 项目的验收往往陷入“技术指标达标但业务不买账”或“业务目标明确但资源严重超支”的两难境地。根本原因在于资源预算（Flash、RAM、推理延迟、功耗）与业务指标（准确率、召回率、误报率、用户体验）被分散在不同文档、由不同角色分别管理，缺乏一个统一的对照与仲裁机制。验收指标表（Acceptance Metrics Sheet）正是为解决这一结构性矛盾而存在的核心管理工具。它不仅是验收时的打分表，更是项目启动、迭代、变更和复盘全过程中的“单一事实来源”。
上图展示了验收指标表的核心定位：它处于资源预算域与业务指标域的交叉点，通过显式定义优先级、容差和测量方法，将两个域的冲突从“事后扯皮”转化为“事前协商”。下面从原理、方法、案例和误区四个维度展开。
3.1 核心原理：指标冲突的根源与统一管理的必要性
TinyML 项目的指标冲突并非偶然，而是由物理约束与产品诉求的本质差异决定的。资源预算描述的是“设备能不能跑得动”，业务指标描述的是“用户是否满意”。两者天然存在张力：提高模型输入分辨率可以提升准确率，但会增加 RAM 和延迟；增加异常检测的灵敏度可以降低漏报率，但会推高误报率，进而增加功耗（因为需要更频繁地唤醒系统）。
统一管理的必要性体现在三个层面：
- 单一事实来源：没有统一表格时，算法工程师看的是模型卡，嵌入式工程师看的是 linker script，产品经理看的是 PRD，三方对“验收标准”的理解可能完全不同。验收指标表将所有关键指标收敛到一张表中，并明确每个指标的测量条件。
- 优先级显式化：并非所有指标都同等重要。在电池供电的设备中，峰值电流可能比准确率优先级更高；在实时交互场景中，延迟可能比模型大小更重要。验收指标表通过 P0/P1/P2 分级，让团队在资源受限时知道先牺牲什么。
- 变更影响可评估：当业务方提出“准确率再提高 1 个百分点”时，如果没有统一表格，很难快速回答“这需要增加多少 Flash 和 RAM”。有了基线表，可以立即估算资源增量，并判断是否触碰硬性约束。
3.2 判断方法与操作流程：如何构建并维护验收指标表
构建验收指标表需要遵循“双向推导”原则：既要从业务需求向下分解出可测量的技术指标，也要从硬件能力向上约束业务指标的可行边界。具体操作流程分为五步：
- Step 1：收集硬约束——从芯片手册、开发板规格和产品定义中提取不可妥协的资源上限。例如：MCU 的 Flash 总容量为 256KB，但留给 AI 模型的部分只有 80KB；电池容量为 300mAh，要求设备续航 6 个月，则平均电流必须小于 0.7mA。
- Step 2：定义业务指标——与产品经理、算法团队共同确定业务指标及其测量方法。注意区分“离线指标”和“在线指标”。离线指标如测试集准确率，在线指标如实际场景中的误触发率。两者可能差异巨大。
- Step 3：建立映射关系——将每个业务指标映射到至少一个资源指标。例如：准确率 → 模型参数量 → Flash 占用；响应时间 → 推理延迟 → CPU 频率与 RAM 带宽；误报率 → 阈值设置 → 功耗（因为误报会导致后续处理流程唤醒）。
- Step 4：设定优先级与容差——使用 MoSCoW 方法（Must have, Should have, Could have, Won't have）分级。P0 指标是验收的硬性门槛，任何一项不达标即验收失败；P1 指标允许有 5%-10% 的偏差；P2 指标作为参考，不参与验收判定。
- Step 5：建立变更管理机制——任何指标数值的调整都需要走变更流程，评估对其他指标的影响。建议使用简单的电子表格或在线文档，并记录每次变更的原因、影响范围和审批人。
| 指标类别 | 示例指标 | 测量方法 | 优先级 | 容差 |
|---|---|---|---|---|
| 资源预算 | 模型 Flash 占用 | 编译后 .text + .rodata 段大小 | P0 | ±0%（硬上限） |
| 资源预算 | 峰值 RAM 占用 | 静态分析 + 运行时最大栈深度 | P0 | ±5% |
| 资源预算 | 单次推理延迟 | GPIO 翻转法，100 次取 P95 | P1 | ±10% |
| 业务指标 | 唤醒词准确率 | 标准测试集 + 噪声环境实测 | P0 | ≥ 95% |
| 业务指标 | 误唤醒次数 | 24 小时连续运行日志 | P1 | ≤ 3 次/天 |
3.3 案例拆解：智能门锁的指标冲突仲裁
某智能门锁项目采用超低功耗 MCU（主频 64MHz，Flash 256KB，RAM 64KB），需要实现本地人脸识别（TinyML 模型）和 PIR 人体感应唤醒功能。项目启动时，产品经理提出以下业务指标：人脸识别准确率 ≥ 98%，从 PIR 触发到识别完成的总响应时间 ≤ 1.5 秒，待机功耗 ≤ 50μA。
算法团队最初选择了一个 MobileNetV2 变体，在开发板上测试得到：Flash 占用 120KB，RAM 占用 28KB，单次推理延迟 800ms，准确率 98.5%。表面看业务指标全部达标，但资源预算严重超限：Flash 已超过 80KB 的模型分区上限，RAM 也接近系统可用上限（系统其他任务需要至少 20KB）。
此时验收指标表发挥了仲裁作用。团队按照表格中的优先级进行权衡：
- P0 约束：Flash 占用 ≤ 80KB（硬性，否则无法烧录）；RAM 占用 ≤ 40KB（系统稳定性底线）。
- P1 指标：准确率 ≥ 95%（可接受从 98.5% 降至 95%）；响应时间 ≤ 2.0 秒（可接受从 1.5 秒放宽至 2.0 秒）。
- P2 指标：待机功耗 ≤ 60μA（原定 50μA，可适当放宽）。
基于此，团队将模型替换为经过 8 倍量化剪枝的 MobileNetV1（宽度乘数 0.25），并采用混合精度推理（部分层用 int8，部分层用 int16）。优化后实测：Flash 占用 76KB，RAM 占用 22KB，推理延迟 1.2 秒，准确率 96.2%。所有 P0 指标达标，P1 指标中准确率超过 95% 的底线，响应时间 1.2 秒优于 2.0 秒的底线。待机功耗通过优化 PIR 轮询策略降至 52μA，满足 P2 要求。
复盘时发现，如果没有验收指标表，算法团队可能会继续追求 98.5% 的准确率而陷入“模型过大无法部署”的僵局。而产品经理也可能坚持 1.5 秒的响应时间，导致需要更换更高主频的芯片，增加 BOM 成本。统一管理让双方在项目中期就达成了可量化的妥协，避免了后期返工。
3.4 常见误区与总结复盘
在实际项目中，验收指标表的使用常出现以下误区：
- 误区一：指标表变成“愿望清单”——所有指标都设为 P0，没有优先级区分。结果一旦资源冲突，团队无法决策，只能逐级上报，效率极低。正确做法是严格控制 P0 数量（通常不超过 5 项），并明确 P0 之间的相对权重。
- 误区二：只关注平均值，忽略分布——例如延迟指标只写“平均 50ms”，但实际 P95 可能达到 200ms，导致偶发性卡顿。验收指标表应明确使用 P50、P95 或 P99 作为测量统计量，并注明采样次数。
- 误区三：静态管理，不随迭代更新——项目初期定义的指标在中期可能已不适用（例如发现硬件选型有误），但表格未更新，导致团队仍在为不合理的指标努力。建议每两周回顾一次指标表，确认是否仍然有效。
- 误区四：忽略“负指标”——只关注准确率、召回率等正向指标，忽略了误报率、崩溃率、温升等负面指标。在 TinyML 场景中，误报率往往比准确率更影响用户体验（例如智能音箱频繁误唤醒）。
总结而言，验收指标表的核心价值在于将“资源预算”和“业务指标”从对立关系转化为协同关系。它通过优先级分级、容差设定和变更管理，让团队在受限的硬件上做出有依据的取舍。一个健康的验收指标表应该具备三个特征：可测量（每个指标都有明确的测量方法和工具）、可仲裁（冲突时有清晰的优先级规则）、可演进（随项目进展定期回顾和调整）。当团队能够熟练运用这张表时，TinyML 项目的验收就不再是“碰运气”，而是一个可预测、可管理的工程过程。