4、采集批次元数据：记录采集时间、设备、环境、传感器配置等元数据，构建批次信息表

TinyML 项目的数据生命周期中，采集批次（Collection Batch）是连接物理世界与模型训练的核心单元。一次完整的采集活动，不仅包含传感器输出的原始数值，还隐含了采集时间、设备状态、环境条件、传感器配置等关键上下文信息。这些上下文信息即元数据（Metadata），它们决定了数据样本的物理含义、适用边界和可信程度。在模型追踪体系中，批次元数据是数据版本管理的基石——没有元数据的原始数据只是一堆无法追溯的数字，而有了完整元数据的批次则成为可复现、可审计、可比较的科学实验单元。本章将系统讲解批次元数据的构成要素、信息表设计方法、采集流程规范，以及在实际 TinyML 工程中的落地案例。

上图展示了批次元数据的核心构成与流转关系。批次 ID 作为唯一锚点，左侧关联采集上下文元数据（时间、设备、环境等），右侧关联传感器配置快照（量程、采样率、滤波等），两者共同汇聚为批次信息表（Batch Manifest），供后续数据版本管理、模型训练和实验追踪使用。下面我们将从核心原理、操作流程、实战案例和常见误区四个维度展开。

4.1 核心原理：为什么批次元数据是 TinyML 数据版本管理的“锚点”

在传统机器学习中，数据集通常以“文件夹+文件名”的方式组织，元数据散落在实验记录本或共享文档中。但在 TinyML 场景下，这种粗放式管理会带来严重问题：边缘设备部署环境复杂，同一型号传感器在不同温湿度下的输出特性可能漂移；固件升级后采样时序可能变化；不同批次的硬件版本可能影响信号完整性。批次元数据的核心价值在于为每一份数据提供“物理上下文快照”，使得数据版本管理不再局限于文件哈希，而是扩展到物理世界的语义层面。

从数据版本管理的视角看，批次元数据承担三个关键角色：可复现性——任何人在任何时间拿到批次 ID，都能通过元数据重建采集条件；可比较性——不同批次的数据只有在元数据维度对齐时才能进行公平的模型评估；可审计性——当模型在部署后出现性能下降时，可以通过元数据回溯到训练数据与现场数据的分布差异。例如，一个用于工业电机振动监测的 TinyML 模型，如果训练数据采集于 25°C 环境，而部署现场温度达到 60°C，加速度计的偏置和噪声特性会显著变化。没有批次元数据，这种分布偏移将难以定位。

4.2 批次信息表设计：字段规范与存储形态

构建批次信息表（Batch Manifest）是元数据落地的核心操作。一个设计良好的批次信息表应包含以下字段组，每个字段组对应一个 JSON 对象或关系表列族：

在存储形态上，推荐采用 “目录内嵌 Manifest + 集中式索引” 的双层结构。每个采集批次目录下放置一个 manifest.json 文件，包含上述全部字段；同时在数据版本管理系统中维护一个全局的 batches.csv 或数据库表，用于跨批次检索和对比。这种设计兼顾了本地可移植性和全局可查询性。

// manifest.json 示例（节选）
{
  "batch_id": "batch_20240521_0930",
  "collection_timestamp": "2024-05-21T09:30:00Z",
  "duration_sec": 3600,
  "device": {
    "device_id": "dev_007",
    "hw_version": "v1.3",
    "fw_version": "v2.1.0",
    "sensor_model": "BMI270"
  },
  "environment": {
    "temperature_c": 26.5,
    "humidity_pct": 45.0,
    "illumination_lux": 320
  },
  "sensor_config": {
    "sample_rate_hz": 100.0,
    "accel_range_g": 4,
    "gyro_range_dps": 500,
    "filter_type": "low_pass_20hz"
  },
  "data_files": [
    {"path": "raw/accel.bin", "format": "int16_le", "checksum": "a3f2...", "num_samples": 360000}
  ],
  "calibration": {
    "date": "2024-05-20",
    "offset": [0.01, -0.02, 0.03],
    "gain": [1.0, 1.0, 1.0]
  }
}

4.3 操作流程：从设备端到版本库的元数据采集与登记

批次元数据的采集不是事后补录，而应嵌入到数据采集的自动化流程中。推荐以下五步操作流程：

1. 采集前配置导出：在启动采集前，由设备端固件自动生成当前传感器配置快照，包括寄存器值、采样率、滤波参数等。此步骤应通过固件 API 直接读取，避免人工录入错误。
2. 环境参数同步记录：如果设备端集成环境传感器（温湿度、气压等），则自动记录；否则由采集人员通过配套 App 或 Web 表单录入，并标注数据来源（自动/手动）。
3. 批次目录初始化：在数据存储系统中创建以 batch_id 命名的目录，并生成空的 manifest.json 模板。
4. 数据写入与实时校验：原始数据流式写入 raw/ 子目录，同时计算每个文件的 SHA-256 校验和，并记录样本数、时间戳范围。若采集过程中发生中断，需在 manifest 中标记 status: "partial" 并记录中断原因。
5. Manifest 最终化与登记：采集结束后，将设备信息、环境参数、文件索引等合并写入 manifest.json，并同步更新全局批次索引表。此时批次进入“已登记”状态，可供数据版本管理工具（如 DVC、MLflow）引用。

4.4 实战案例：可穿戴跌倒检测项目的批次元数据管理

我们以一个可穿戴跌倒检测 TinyML 项目为例，说明批次元数据如何在实际中发挥作用。该项目使用 IMU（惯性测量单元）采集加速度和角速度数据，目标是训练一个能在 MCU 上运行的跌倒检测模型。

背景与约束：项目团队有 5 名测试人员，使用 3 块不同硬件版本的开发板（v1.0、v1.1、v1.2），在室内、室外、楼梯三种场景下采集数据。固件版本在采集过程中升级过一次（v1.0 → v1.1），采样率从 50Hz 提升到 100Hz。初始目标是采集 200 个跌倒样本和 400 个日常活动样本。

初始现象：在训练第一个模型时，验证集准确率达到 92%，但在部署到现场设备后，准确率骤降至 70%。团队初步怀疑是过拟合，但通过检查批次元数据发现，训练数据中 85% 的样本来自 v1.0 硬件和 50Hz 采样率，而现场设备是 v1.2 硬件和 100Hz 采样率。

分析判断过程：通过查询全局批次索引表，团队按 hw_version 和 sample_rate_hz 分组统计了数据分布。发现 v1.2 硬件的数据仅占 5%，且全部来自室外场景。进一步对比 v1.0 和 v1.2 的传感器配置快照，发现 v1.2 的加速度计量程从 ±4g 调整为 ±8g，导致数据分辨率不同。

实际操作步骤：

• 步骤 1：在批次信息表中增加 hw_version 和 accel_range_g 作为过滤条件，重新划分训练集/验证集，确保每个硬件版本的数据按比例出现。
• 步骤 2：使用 v1.2 硬件重新采集 100 个跌倒样本和 200 个日常样本，并在 manifest 中记录新的配置。
• 步骤 3：在数据预处理脚本中，根据 accel_range_g 字段对原始整数进行归一化，消除量程差异。
• 步骤 4：重新训练模型，并在测试集中按批次元数据分层评估。

结果对比：调整后，现场准确率从 70% 提升至 88%。虽然仍低于实验室的 92%，但通过元数据定位到剩余差距主要来自环境温度差异（现场 5°C vs 实验室 25°C），为后续温度补偿提供了方向。

风险与代价：重新采集数据耗时 2 天，且需要协调测试人员。但相比盲目调参，元数据驱动的排查节省了至少一周的无效实验时间。

复盘经验：批次元数据不仅是“记录”，更是“决策支持工具”。在项目启动时就应该定义好元数据的最小集，并在每次采集后立即检查分布，而不是等到模型部署后再回溯。

4.5 常见误区与总结复盘

在批次元数据管理实践中，以下误区值得警惕：

总结复盘：批次元数据是 TinyML 数据版本管理的“锚点”，它将物理世界的采集条件转化为可查询、可比较、可复现的结构化信息。通过设计包含批次标识、设备信息、环境参数、传感器配置、数据文件索引和校准记录的批次信息表，并嵌入到自动化采集流程中，团队能够显著提升模型的可维护性和部署成功率。在项目实践中，元数据驱动的分析往往能比盲目调参更快地定位问题，是 TinyML 工程化中不可忽视的基础设施。