4. 模型版本对比方法论：版本号命名规则，语义化版本控制，模型版本管理的必要性，对比维度定义（精度、内存、延迟）
做嵌入式AI最头疼的事是什么？我个人觉得，不是模型精度不够，而是你根本搞不清哪个模型是哪个版本。
我见过太多团队，模型文件命名成“model_final_v2_真的最终版_别改了.onnx”。结果三个月后，谁都不知道这个模型是用什么数据训练的，量化参数是多少，推理延迟是多少。你说这项目还怎么迭代？
所以这一章，咱们就把模型版本管理这件事彻底讲清楚。说白了，就是给每个模型一个“身份证”，让团队里每个人都能一眼看懂这个模型的来龙去脉。
4.1 版本号命名规则：别再用“最终版”了
先说说命名。我自己的习惯是：项目名_模型架构_版本号_附加标识。
举个例子：
person_detection_mobilenetv2_1.2.1_quant.tflite
拆开看：
- person_detection：项目名，一眼知道是干啥的
- mobilenetv2：模型架构，方便对比不同架构
- 1.2.1：语义化版本号，后面细讲
- quant：附加标识，表示量化后的模型
这里有个坑，我曾经踩过：文件名里不要用空格和中文。有些工具链对中文路径支持不好，编译时直接报错，排查起来特别费劲。
4.2 语义化版本控制：主版本.次版本.修订号
语义化版本控制（SemVer）不是软件开发的专利，模型管理同样适用。格式就是：主版本号.次版本号.修订号。
具体怎么用？我总结了一套规则：
| 版本位 | 变更条件 | 举例 |
|---|---|---|
| 主版本 | 模型架构变更、输入输出变化、精度大幅波动（>5%） | MobileNetV2 → MobileNetV3，主版本+1 |
| 次版本 | 训练数据更新、超参调整、精度小幅变化（1%~5%） | 增加新类别数据，次版本+1 |
| 修订号 | 量化参数调整、算子替换、bug修复，精度变化<1% | 更换量化校准集，修订号+1 |
你想想看，如果团队里每个人都遵守这个规则，看到“v2.1.3”就知道：这是第二个大版本，经历了1次数据更新和3次小修小补。是不是清晰多了？
4.3 模型版本管理的必要性：没有版本管理，项目就是一团乱麻
为什么要花时间搞版本管理？我直接说三个真实场景：
- 复现问题：客户反馈模型在设备上推理结果不对。如果没有版本记录，你根本不知道客户用的是哪个模型，训练参数是什么，量化方式是什么。查都没法查。
- 回归测试：新模型精度提升了2%，但内存占用多了50KB。这个代价值不值得？没有版本对比，你只能凭感觉做决策。
- 合规审计：有些行业（比如医疗、汽车）要求模型版本可追溯。出了问题，要能查到是哪个版本、谁训练的、用的什么数据。
说白了，版本管理不是增加工作量，而是给未来的自己留一条后路。
4.4 对比维度定义：精度、内存、延迟
模型版本对比，不能光看精度。嵌入式设备资源有限，你得从三个维度综合评估。
4.4.1 精度（Accuracy）
精度是模型的核心指标。但要注意，不同任务用不同指标：
- 分类任务：Top-1准确率、Top-5准确率
- 检测任务：mAP（平均精度均值）
- 分割任务：mIoU（平均交并比）
我建议在版本记录里同时保留验证集精度和测试集精度。验证集精度用于训练过程中的调参决策，测试集精度用于最终版本发布。两个精度差距过大，说明模型过拟合了。
4.4.2 内存（Memory）
嵌入式设备的内存是硬约束。内存占用分两部分：
- 模型大小：模型文件在Flash中的占用，直接影响存储成本
- 运行时内存：推理时RAM的峰值占用，包括输入输出张量、中间激活值、权重缓冲区
举个例子，我做过一个项目：模型从FP32量化到INT8，模型大小从2MB降到500KB，但运行时内存只降了30%。为什么？因为中间激活值还是FP32的。所以只看模型大小是不够的，必须实测运行时内存。
4.4.3 延迟（Latency）
延迟就是模型推理一次需要多长时间。注意，这里要区分：
- 单帧延迟：处理一帧数据的时间
- 端到端延迟：从数据采集到结果输出的总时间，包括预处理和后处理
我习惯在版本记录里同时记录这两个值。因为有时候模型推理很快，但预处理（比如图像缩放、归一化）反而成了瓶颈。
4.5 版本对比矩阵：一张表看清所有差异
有了上面的维度定义，我们就可以做一个版本对比矩阵。每次发布新版本，都填一张这样的表：
| 版本号 | 模型架构 | 精度（Top-1） | 模型大小 | 运行时RAM | 单帧延迟（ms） | 备注 |
|---|---|---|---|---|---|---|
| v1.0.0 | MobileNetV2 | 92.3% | 2.1 MB | 1.8 MB | 45 | FP32基线 |
| v1.1.0 | MobileNetV2 | 92.5% | 2.1 MB | 1.8 MB | 45 | 增加数据增强 |
| v2.0.0 | MobileNetV3 | 93.1% | 1.6 MB | 1.5 MB | 38 | 架构升级 |
| v2.0.1 | MobileNetV3 | 92.8% | 0.5 MB | 1.1 MB | 22 | INT8量化 |
看到这张表，你就能快速判断：v2.0.1虽然精度掉了0.3%，但模型大小只有v1.0.0的四分之一，延迟也减半。对于资源紧张的嵌入式设备，这个取舍是值得的。
4.6 知识结构图：模型版本管理全景
下面这张图，把模型版本管理的核心逻辑串起来了。你可以把它贴在团队的白板上，每次讨论版本时对照着看。
4.7 实战建议：从今天开始建立版本管理习惯
说了这么多，最后给几个马上能用的建议：
- 建立版本记录文件：在每个模型目录下放一个VERSION.md，记录版本号、变更内容、精度指标、内存延迟数据。格式可以参考上面的对比矩阵。
- 自动化版本检查：在CI/CD流程中加入版本号检查脚本，确保每次提交都更新了版本号。我曾经因为忘记更新版本号，导致两个不同模型用了同一个版本号，排查了整整一天。
- 团队统一规则：版本命名规则和对比维度定义，一定要团队达成共识。最好写进项目Wiki里，新人来了直接看。
版本管理这件事，前期投入一点时间，后期能省下大把的排查时间。说白了，这是给项目上的一份“保险”。