Edge AI实验管理基础：核心概念与典型应用场景
在Edge AI开发从原型验证走向产品落地的过程中，实验管理往往是被团队忽视却决定成败的关键环节。与云端AI训练不同，Edge AI实验涉及硬件平台差异、量化精度损失、功耗约束、传感器数据分布漂移等多重变量，每一次实验的复现与对比都远比纯软件环境复杂。本章将系统梳理Edge AI实验管理的核心概念、常见术语及其在真实工程链路中的典型应用场景，帮助读者建立一套统一的语言框架和认知模型，为后续章节的数据版本控制、参数追踪和指标管理打下坚实基础。
上图展示了Edge AI实验管理的核心概念框架。一个实验（Experiment）是围绕某个研究问题或工程目标展开的完整探索过程，它包含多次运行（Run），每次运行都绑定特定的数据集版本、模型版本、训练参数组合和指标记录。这四个实体构成了实验管理的基本维度，而版本、参数、指标、追踪则是贯穿其中的操作手段。下面我们将逐一深入解析这些概念。
2.1 核心概念：实验、运行、数据集、模型、指标
2.1.1 实验（Experiment）与运行（Run）
在Edge AI场景中，实验是一个逻辑容器，它代表一个完整的研究或工程任务。例如，“在STM32H743上部署MobileNetV2进行图像分类”是一个实验，“使用INT8量化对比FP32精度损失”是另一个实验。实验的粒度取决于团队的管理需求——可以按算法类型划分，也可以按目标硬件平台划分，还可以按业务场景划分。一个实验通常持续数天到数周，包含数十到数百次运行。
运行（Run）是实验的最小执行单元，代表一次具体的训练、微调、量化或推理测试过程。每次运行都有唯一的标识符（如时间戳+随机数），记录完整的输入输出信息。在Edge AI中，一次运行可能包含以下阶段：数据预处理→模型训练/微调→模型量化→编译部署→目标板推理→指标采集。每个阶段都可能产生中间产物和日志，这些都需要被系统化记录。
关键区别：实验是“做什么”的定义，运行是“怎么做”的执行记录。一个实验可以包含多次运行，每次运行尝试不同的超参数、数据子集或硬件配置。实验管理系统的核心任务就是组织好这种一对多的关系，并确保每次运行的可复现性。
2.1.2 数据集（Dataset）与模型（Model）
在Edge AI中，数据集不仅是训练样本的集合，还包含数据采集环境信息、标注版本、预处理流水线、数据增强策略等元数据。由于边缘设备常面临传感器数据分布漂移问题，数据集版本管理尤为重要。例如，一个用于工业缺陷检测的数据集，可能包含不同光照条件下的图像、不同批次产品的样本、不同标注人员的标注结果。每次数据更新都应视为一个新版本，并记录变更原因。
模型在Edge AI语境下包含多个层次：原始网络结构（如PyTorch/TensorFlow格式）、训练好的权重文件、量化后的模型（INT8/FP16）、编译后的部署格式（如TensorFlow Lite、ONNX Runtime、CMSIS-NN）。每个层次都可能存在多个版本，且它们之间存在映射关系。实验管理需要追踪模型从训练到部署的完整演变链路。
2.1.3 指标（Metrics）
Edge AI的指标体系比云端AI更复杂，除了传统的准确率、召回率、F1分数外，还必须包含硬件相关指标：推理延迟（单次推理毫秒数）、内存占用（RAM/Flash）、功耗（mW）、模型大小（KB）、吞吐量（FPS）。这些指标与硬件平台强相关，同一模型在不同MCU上的表现可能差异巨大。因此，指标记录必须同时包含硬件环境信息（芯片型号、时钟频率、内存配置、编译器版本）。
| 指标类别 | 具体指标 | Edge AI特有说明 |
|---|---|---|
| 模型质量 | 准确率、mAP、IoU、F1 | 与云端AI相同，但需关注量化后的精度损失 |
| 性能指标 | 推理延迟、吞吐量 | 受硬件平台、编译器优化、缓存策略影响 |
| 资源占用 | RAM、Flash、模型大小 | 边缘设备资源受限，需严格评估 |
| 功耗指标 | 平均功耗、峰值功耗 | 电池供电设备的关键指标 |
| 稳定性指标 | 温度漂移、长期运行稳定性 | 工业场景需考虑环境因素 |
2.2 常见术语：版本、参数、指标、追踪
2.2.1 版本（Version）
版本管理是实验管理的基石。在Edge AI中，版本管理覆盖三个层面：数据版本（数据集变更记录）、代码版本（训练脚本、推理代码）、模型版本（权重、量化配置、编译配置）。版本管理需要遵循以下原则：
- 不可变性：一旦发布，版本内容不可修改，只能创建新版本
- 可追溯性：每个版本必须记录创建时间、创建人、变更说明、父版本
- 可复现性：给定版本号，应能完整重建对应的数据、代码、模型环境
在Edge AI实践中，版本管理常与Git配合使用，但需要额外处理大文件（数据集、模型权重）。常见的做法是使用DVC（Data Version Control）或LakeFS管理数据版本，使用Git LFS管理大模型文件。
2.2.2 参数（Parameter）
参数在Edge AI中有两类含义：训练超参数（学习率、批大小、优化器、正则化系数）和部署配置参数（量化位宽、编译器优化级别、缓存策略、批处理大小）。这两类参数都需要被记录和追踪。训练超参数影响模型质量，部署配置参数影响硬件性能指标。实验管理系统应支持参数的结构化存储和对比分析。
# 典型的Edge AI训练参数记录示例
training_params:
learning_rate: 0.001
batch_size: 32
optimizer: Adam
epochs: 50
data_augmentation: true
quantization: int8
target_hardware: STM32H743
compiler: arm-none-eabi-gcc 10.3.1
optimization_level: -O2
2.2.3 指标（Metric）与追踪（Tracking）
指标是实验结果的量化表达，追踪是记录指标随时间或参数变化的过程。在Edge AI中，追踪不仅是记录最终结果，还要记录训练过程中的损失曲线、验证精度变化、量化前后的精度对比、不同硬件平台的性能对比。追踪系统应支持自动记录和手动标注两种模式，并能够生成可视化对比图表。
实践建议：在实验开始时，先定义好需要追踪的指标清单，包括指标名称、计算方式、采集时机、目标值。这能避免实验结束后发现关键指标未记录的问题。例如，在部署到电池供电设备前，必须追踪待机功耗和峰值功耗，而不仅仅是平均功耗。
2.3 典型应用场景
2.3.1 场景一：模型量化精度对比实验
某团队需要在Cortex-M7内核的MCU上部署一个关键词识别模型。他们需要对比FP32、INT8量化、INT8+混合量化三种方案的精度和性能差异。这是一个典型的实验管理场景：
- 创建实验“KWS模型MCU部署量化对比”
- 为每种量化方案创建一次运行，记录量化配置参数
- 每次运行记录精度指标（准确率、召回率）和硬件指标（推理延迟、RAM占用）
- 实验结束后，对比三次运行的指标，选择最优方案
如果没有实验管理系统，团队可能面临以下问题：忘记记录某次运行的量化配置、无法复现三个月前的实验结果、不同硬件版本导致的性能差异无法解释。
2.3.2 场景二：数据漂移后的模型更新
一个工业视觉检测系统部署后，由于生产线更换了新的原材料，导致检测精度下降。团队需要基于新数据重新训练模型。此时实验管理的作用体现为：
- 记录新数据集的版本（v2.1），标注变更原因“原材料更换”
- 基于v2.1数据集创建新的实验，与旧实验（基于v2.0数据集）进行对比
- 追踪模型在新旧数据集上的表现差异，判断是数据漂移还是模型过拟合
- 如果新模型部署后效果良好，将模型版本标记为“生产候选”
2.3.3 场景三：多硬件平台适配管理
一个AI算法需要部署到三种不同规格的硬件平台（高端手机SoC、中端MCU、低端传感器节点）。实验管理系统需要支持同一模型在不同硬件上的运行记录，并对比性能差异。这要求系统能够记录硬件环境信息，并支持跨实验的指标对比。
风险提示：在Edge AI实验管理中，最常见的风险是“环境漂移”——同一代码在不同时间运行，由于依赖库更新、编译器版本变化、硬件固件升级，导致结果不可复现。因此，每次运行必须记录完整的软件环境快照（操作系统版本、库版本、编译器版本、固件版本）。
2.4 常见误区与总结复盘
在Edge AI实验管理的实践中，团队常陷入以下误区：
- 误区一：将实验管理等同于代码版本管理。代码版本管理只解决了“代码从哪里来”的问题，而实验管理还需要回答“数据是什么版本”“模型如何生成”“在什么硬件上运行”等问题。
- 误区二：只记录最终指标，不记录过程指标。训练过程中的损失曲线、验证精度变化趋势，往往比最终指标更能揭示问题。例如，过拟合现象只有在观察训练曲线时才能及时发现。
- 误区三：忽略硬件环境信息。Edge AI的指标与硬件强相关，不记录硬件环境信息的实验数据，在后续对比中可能完全失去价值。
- 误区四：版本命名混乱。使用“final_v2_最终版”这类命名方式，会导致版本追溯困难。应使用语义化版本号（如v1.2.0）或哈希值。