深入浅出TinyML 04：如何判断一个项目是否适合使用TinyML？

TinyML项目常在模型训练后才发现输入不稳定、标签无法统一或误报成本不可接受。把可行性检查前移，可以在投入大量采集和训练工作之前暴露根本问题。

评审结果不需要强行得出"适合"。当稳定阈值已经达到目标、现场无法收集代表性数据，或错误后果无法由系统降级吸收时，放弃模型是合格的工程结论。

|----------------------------------------------|
| 可行性评审先检查问题能否被数据稳定表达，再检查模型能否在目标MCU和错误成本约束下运行。 |

|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 完成本篇后，你应该能够 1. 把模糊的TinyML想法改写成可采集、可评价、可部署的任务定义。 2. 识别数据、标签、资源、风险和维护五类硬性阻断项。 3. 运行立项评审脚本，为一个项目输出继续、试点或停止的可追踪结论。这篇文章用于决定是否值得训练模型。越早发现输入中没有足够信息，越能减少后续无效采集和调参。 |

一、输入必须稳定承载目标信息

传感器数据中需要存在可重复、可区分的模式。安装位置、量程、采样率和时钟如果经常变化，模型会把采集链路差异当成类别特征。此时应先解决硬件与数据一致性。

可以先画出不同类别的原始波形和基础统计分布。若类别高度重叠，应检查传感器位置、标签定义和任务本身，直接增加网络层数通常不能弥补缺失信息。

图1：TinyML项目立项前需要通过的四类检查

二、输出和错误成本需要量化

"识别异常"过于宽泛。项目应写清类别、事件边界、响应时间、误报率、漏报率和未知状态。对于安全相关任务，还要定义模型低置信度、传感器失效和通信中断时的降级输出。

准确率不能替代错误成本。漏报会造成设备损坏时，应优先评估召回率；误报会频繁停机时，还需评估精确率和单位时间误报次数。

表1：立项评审中的通过条件与否决条件

检查项	通过条件	需要暂停
数据	主要工况可采集且可追溯	关键工况无法获得
标签	类别边界和过渡状态有定义	标注者无法达成一致
资源	Flash、RAM和截止时间有余量	基础模型已明显超标
风险	有未知拒识和安全降级	错误后果无法被系统吸收
维护	可监控、更新和回滚	模型失效无法被发现

三、MCU资源与实时任务共同约束模型

可用Flash和RAM需要扣除驱动、协议栈、任务栈、日志与升级空间。推理必须嵌入采集周期，模型平均耗时合格但最坏耗时超出窗口步长，系统仍会丢帧。

项目初期可以设置资源上限，例如模型及运行时可用Flash、Arena上限和单次推理截止时间。候选模型在训练时就按这些条件筛选。

Python：把评审结论保存为可追踪记录

四、维护闭环决定长期可用性

现场温度、传感器批次、安装方式和工况会变化。系统至少需要保存模型版本、预处理参数和关键运行统计，并能够识别未知或低置信度输入。

如果项目没有困难样本回收、重新训练、独立验证和回滚机制，首次部署成功也无法保证长期有效。维护责任和数据权限应在立项阶段写入范围。

把一句需求改写成可验证任务

"检测设备异常"缺少输入、输出和时间边界。可执行版本可以写成：使用固定安装位置的三轴加速度计，以1 kHz采样；每1秒窗口区分稳定运行、轴承松动和UNKNOWN；每200 ms更新一次结果；在独立设备测试集上分别报告三类召回率和每小时误报次数。

任务定义还要写清事件何时开始和结束。若故障发生在窗口最后50 ms，标签是按多数时间、中心时刻还是只要出现就算故障？不同规则会改变训练样本。业务人员和数据标注人员必须使用同一份定义。

接着做可观测性试验。先收集少量但覆盖重复运行的数据，画出原始波形、频谱和简单特征。如果同一类别在不同设备间差异远大于类别间差异，优先处理安装、传感器和标签，不急着增加模型复杂度。

|------------------------------------------------------------------------|
| 任务定义模板：在【固定采集条件】下，用【窗口与更新周期】识别【明确类别与UNKNOWN】，并以【独立划分上的指标】和【系统资源指标】验收。 |

设计一个两周内能否定假设的最小试点

试点用最低成本回答最危险的问题，并允许项目依据证据及时停止。若最大风险是跨设备泛化，就用至少多台设备独立采集并按设备留出测试；若最大风险是MCU资源，就尽早部署一个粗糙基线测Arena和时间。

每个风险都要有停止条件。例如独立设备上的目标类别召回率低于业务底线，且错误分析显示传感器输入缺少可区分信息，则暂停模型路线；若数据可分但模型过大，可以继续做特征或结构优化。停止条件让团队避免无期限调参。

风险排序建议看影响与不确定性。高影响、高不确定的问题先验证；容易修复的界面和美化工作后置。试点结束要留下数据版本、代码、指标、失败样本和决定记录，便于下一轮复现。

从风险到最小验证动作

高风险假设	最小实验	停止信号
传感器能看到目标	同工况重复采集并可视化	类别差异低于采集波动
标签可以一致	两名标注者独立标注	关键类别持续分歧
模型能跨设备	按设备留一测试	仅随机窗口划分有效
MCU资源足够	最小模型早期上板	仍明显超出硬预算

五、落地检查

用原始数据证明类别中存在可重复差异。
写清输入、输出、未知状态和事件边界。
把误报、漏报、响应时间和系统降级转成验收指标。
为模型、运行时和业务功能分别建立资源预算。
确定现场监控、困难样本回收、更新和回滚责任。

动手：完成一份带硬阻断项的TinyML立项评审

评分表很容易掩盖致命问题：即使总分很高，只要没有可用数据或没有安全降级，项目也不应直接进入训练。下面的脚本先检查硬阻断项，再对可优化项打分，最终给出STOP、PILOT或PROCEED。

实验环境与输入

Python 3标准库。
保存为 `tinyml_gate_review.py` 后运行。
示例项目是假设的电机状态识别，用于学习评审方法。

按顺序完成实验

运行默认配置，阅读阻断项、加权得分和决策。
把 `labels_agreed` 改成False，确认无论分数多高都得到STOP。
恢复标签后，把维护与资源得分逐步提高，观察PILOT何时变成PROCEED。
复制配置并替换成你的项目事实；不知道的项目必须写0或False，不能默认通过。

可直接运行：硬门槛优先的项目评审脚本

|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| hard_gates = { "signal_observable": True, "labels_agreed": True, "safe_fallback": True, "independent_test_possible": True, } # 0=没有证据，1=很弱，2=初步可用，3=证据充分 scores = { "data_coverage": (2, 3), "mcu_budget": (1, 3), "error_cost_defined": (2, 2), "maintenance_loop": (1, 2), "team_and_schedule": (2, 1), } blocking = $name for name, passed in hard_gates.items() if not passed$ weighted = sum(value * weight for value, weight in scores.values()) maximum = sum(3 * weight for _, weight in scores.values()) ratio = weighted / maximum if blocking: decision = "STOP" elif ratio >= 0.75: decision = "PROCEED" else: decision = "PILOT" print("hard blockers:", blocking or "none") print(f"weighted score: {weighted}/{maximum} = {ratio:.1%}") print("decision:", decision) if decision == "PILOT": weakest = sorted(scores, key=lambda k: scores $k$ $0$ ) print("validate first:", weakest $:2$ ) |

先读懂代码中的关键路径

hard_gates保存一票否决条件，未知项必须记False，直到取得真实证据。
软评分的元组是"当前分数、权重"，权重只表达试点优先级，不能覆盖硬风险。
PILOT分支找最低分项，目标是设计能否定高风险假设的最小实验。
评分表本身也要版本化，因为类别、资源或安全要求变化会改变评审结论。

你应该观察到什么

默认配置给出PILOT，并指出证据最弱的资源预算与维护闭环。
任何硬门槛为False时，决策立即变为STOP。
提高软评分只能让PILOT变成PROCEED，不能覆盖硬阻断项。

成功标准

每个True、False和分数都有项目证据或明确的待验证计划。
评审记录同时包含进入条件与停止条件。
试点优先验证影响最大且最不确定的假设，而非优先训练复杂模型。

失败时从哪里查起

立项评审中容易出现的偏差

现象	问题	改进
所有项目都能通过	把未知项默认记为高分	未知必须记0并创建验证任务
总分高但风险不可接受	没有硬阻断项	将数据、安全和独立测试设为门禁
试点结束仍无法决定	没有停止条件	试验前写出通过与停止阈值

评审脚本只负责保持决策逻辑一致，最终输入必须来自采集证据、资源测量和业务风险确认。

把实验迁移到真实MCU项目

最早的上板工作可以只部署一个粗糙基线：固定黄金输入、记录Arena和周期。它不要求模型效果成熟，却能提前验证运行时、算子和硬件预算。

把试点结果写成"假设---方法---数据---结果---决定"。若输入中没有稳定信息，应暂停项目并改进传感器或任务定义，而非继续增加网络层。

用反例检查你的项目定义

写出一个无需TinyML、用阈值或状态机即可解决的基线方案。
列出最容易造成虚高测试结果的数据泄漏路径。
把"准确率高"替换为至少三个与业务错误成本相关的验收指标。

|--------------------------------------------------------------------------------|
| 这篇文章的结论适合TinyML的项目同时满足数据可表达、任务可定义、资源可承载、风险可降级和模型可维护五项条件。缺少其中任何一项都应先补齐工程基础。 |

参考资料：

TensorFlow Lite Micro 官方代码仓库

Google AI Edge：构建并转换微控制器模型

STMicroelectronics：STM32H743/753 官方资料

更新时间：2026 年 8 月 5 日