4、需求定义：如何将应用场景转化为具体的数据需求（类别、数量、多样性、标注要求）

在TinyML项目启动初期，团队最容易犯的错误是跳过需求定义直接进入数据采集。开发者往往凭直觉认为“多采一些数据总没错”，结果采集了数万张图片或数千条传感器波形后，却发现类别覆盖不全、样本分布失衡、标注标准混乱，最终导致模型精度远低于预期。需求定义是将模糊的应用场景翻译为可执行的数据工程规范的关键桥梁。它回答四个核心问题：要识别什么（类别）、要多少（数量）、要覆盖哪些变化（多样性）、如何标记（标注要求）。本章将提供一套系统化的转化方法论，帮助你在采集第一份数据之前，就建立起清晰、可验证的数据需求规格书。

4.1 核心原理：从场景到需求的四维映射

应用场景描述的是“设备在什么环境下、面对什么对象、完成什么任务”，而数据需求描述的是“需要采集哪些样本、每种多少、覆盖哪些变化、如何标注”。两者之间存在一个结构化的映射关系。我们将这个映射拆解为四个维度：类别维度回答“世界中有哪些东西需要被区分”；数量维度回答“每个类别需要多少样本才能训练出鲁棒模型”；多样性维度回答“样本需要覆盖哪些环境变化、姿态变化、干扰因素”；标注维度回答“每个样本需要赋予什么标签、标签的粒度如何、由谁标注、如何质检”。

这四个维度并非独立存在。类别定义决定了数量估算的基数，多样性要求直接影响标注的复杂度，而标注规范又反过来约束类别边界是否清晰。例如，一个“识别厨房刀具”的场景，如果类别定义为“刀具/非刀具”，则数量需求相对简单；但如果要区分“菜刀/水果刀/面包刀”，则类别边界模糊，需要更细致的标注规范和更大的样本量。因此，需求定义是一个迭代收敛的过程，而非一次性输出。

4.2 判断方法：四步转化操作流程

将应用场景转化为数据需求，建议遵循以下四个步骤，每一步都产出可验证的中间产物。

步骤1：场景拆解与事件枚举

首先，将应用场景拆解为设备可能遇到的关键事件或状态集合。例如，一个智能门锁的TinyML应用，场景是“识别开门动作与异常撬锁”。拆解后的事件包括：正常指纹开锁、密码输入、钥匙插入、撬锁工具试探、暴力撞击、宠物误触等。每个事件对应一个潜在的类别或需要排除的干扰项。此步骤的输出是一张事件清单，标注每个事件的优先级（必须识别/最好识别/必须排除）。

步骤2：类别定义与边界确认

基于事件清单，定义模型的输出类别。这里需要遵循三个原则：互斥性（一个样本只能属于一个类别）、完备性（所有可能输入都有归属，包括“其他/未知”类）、可标注性（标注者能根据明确规则判断类别归属）。对于边界模糊的类别，需要定义详细的判定规则。例如，“正常开锁”与“异常开锁”的边界是什么？是力度阈值、角度范围还是时间窗口？这些规则必须写入标注规范。

步骤3：数量估算与多样性规划

数量估算不能简单套用“每类1000张”的经验值。建议采用基线+增量策略：先根据任务复杂度设定一个基线数量（如表4-1所示），然后通过小规模试采集训练一个基线模型，用验证集的错误模式指导增量采集。多样性规划则需要列出所有可能影响模型鲁棒性的变化因子，包括环境因子（光照、温度、湿度）、对象因子（不同品牌、型号、磨损程度）、交互因子（不同用户习惯、角度、距离）、时间因子（白天/夜晚、季节变化）。每个因子至少需要覆盖3-5个等级。

步骤4：标注规范与质检方案

标注规范需要明确标注粒度（图像级/区域级/时间点/时间窗口）、标签体系（单标签/多标签/层级标签）、标注工具（开源工具或自研平台）、标注人员要求（领域知识水平）、以及质检流程（双人标注一致性检查、抽检比例、争议仲裁机制）。对于TinyML项目，标注规范尤其要考虑到边缘案例的处理，例如传感器数据中的异常尖峰、通信中断产生的空包、设备启动时的瞬态响应等，这些都需要在规范中预先定义。

4.3 案例拆解：工业设备振动监测的数据需求定义

我们以一个实际的工业设备预测性维护项目为例，完整展示需求定义过程。项目背景：某工厂需要在旋转机械（电机、泵、风机）上部署TinyML振动监测节点，通过加速度计采集振动信号，在MCU上实时判断设备状态，实现异常预警。硬件约束：STM32L4系列MCU，128KB RAM，1MB Flash，加速度计采样率4kHz，电池供电需运行6个月。

初始现象与目标：工厂希望识别三种状态：正常运转、轴承早期磨损、转子不平衡。但现场工程师反馈，不同设备型号的振动基线差异很大，且环境振动（如附近冲压机）会造成干扰。目标是在误报率低于5%的前提下，对轴承磨损的检出率不低于90%。

关键输入数据与参数：我们收集了3台电机、2台泵、2台风机的历史振动数据（各约200小时），发现正常状态振动幅值在0.5-2.5 mm/s RMS之间，轴承磨损特征频率在1kHz-2kHz频段，转子不平衡表现为1倍频幅值异常增大。环境干扰振动频率集中在50Hz-200Hz。

分析判断过程：首先，我们按4.2节步骤1拆解事件：正常、轴承磨损、转子不平衡、外部干扰（需排除）。步骤2定义类别：由于外部干扰与正常状态在频域上可区分，我们将其作为“其他”类处理，不单独建模。步骤3估算数量：任务复杂度为中高（3类，且轴承磨损与转子不平衡在低频段有重叠），基线数量设为每类1500个样本（每个样本为1秒的振动波形，4096个采样点）。多样性规划覆盖：3种设备类型、4种转速档位（800/1200/1800/2400 RPM）、2种负载条件（空载/满载）、3种安装位置（水平/垂直/轴向）。标注规范：由振动分析工程师标注，标签为“正常/轴承磨损/转子不平衡/其他”，每个样本附带设备型号、转速、负载、安装位置等元数据。

实际操作步骤：我们先用每类500个样本训练了一个基线CNN模型（输入为4096点FFT频谱），在验证集上准确率为82%。分析错误后发现：轴承磨损在低转速下与正常状态混淆严重，且不同设备型号的频谱基线偏移导致泛化差。于是我们执行增量采集：针对低转速工况补充了800个轴承磨损样本，针对不同设备型号补充了500个正常样本。同时，我们增加了“设备型号归一化”预处理步骤。第二次训练后准确率提升至94%，误报率4.2%，满足目标。

结果对比与复盘：最终数据需求规格书为：每类2500个样本，总样本量7500个，覆盖4个转速档、2种负载、3种安装位置、7台不同设备。标注耗时约120人时，质检抽检率15%，标注一致性达96%。复盘经验：数量需求不是一次性确定的，而是通过“基线训练→错误分析→增量采集”循环迭代出来的；多样性规划必须与硬件部署现场紧密结合，不能只依赖实验室数据。

4.4 常见误区与总结复盘

在需求定义阶段，团队常犯以下四类错误，需要特别注意规避。

• 误区一：类别定义过于粗糙。例如将“异常”作为一个类别，但异常包含多种根本原因不同的模式，导致模型无法收敛。对策：在场景拆解阶段尽可能细化事件类型，即使最终合并为同一输出类别，也要在标注时保留细粒度标签，便于后续分析。
• 误区二：数量估算脱离硬件约束。TinyML模型容量有限，如果数据量过大但模型无法拟合，反而增加过拟合风险。对策：先根据RAM/Flash估算模型参数量上限，再反推所需数据量。经验公式：参数量不超过Flash的1/10，训练样本数至少为参数量的10倍。
• 误区三：多样性规划只关注“正常”场景。实际部署中，设备会遇到传感器饱和、信号丢失、电池低电量等异常输入。这些“非目标”样本也需要采集并标注为“其他”类，否则模型在真实环境中会产生不可预测的输出。
• 误区四：标注规范与模型输出不一致。例如标注时使用“轻微磨损”和“严重磨损”两个标签，但模型输出只有“磨损/正常”二分类，导致标注信息浪费且标注者困惑。对策：标注粒度应略细于模型输出粒度，但要在规范中明确映射关系。

总结：需求定义是TinyML数据建设的“宪法”，它决定了后续采集、清洗、增强、标注的所有工作方向。一个高质量的数据需求规格书应包含：事件清单与优先级、类别定义与判定规则、每类基线数量与增量触发条件、多样性因子矩阵（因子×等级×样本数）、标注规范与质检方案、以及数据来源划分（训练/验证/测试）。建议团队在正式采集前，用一周时间完成需求定义并组织评审，邀请算法工程师、嵌入式工程师、领域专家共同参与，确保需求既符合模型训练要求，又能在硬件约束下实现。