📚 课程目录第2章基础知识

2、基础知识：OTA升级、模型更新、人脸识别模型的基本概念与常见术语

智能门锁的“进化”能力，本质上取决于三个核心要素：OTA升级通道（解决“怎么送”）、模型更新机制（解决“怎么换”）以及人脸识别模型本身（解决“认得出”）。这三者构成了智能门锁持续迭代的闭环。在深入灰度发布与回滚策略之前，必须先厘清这些基础概念与行业术语，否则后续的工程决策将缺乏依据。本节将系统梳理OTA升级的链路、模型更新的类型与格式，以及人脸识别模型在端侧部署时的关键指标。

上图展示了智能门锁OTA模型更新的完整知识框架。左侧是OTA升级的物理链路，中间是模型更新的策略机制，右侧是端侧人脸模型的核心组件。三者相互依赖：OTA负责运输，模型更新负责切换，而人脸模型本身的质量决定了最终体验。下面我们逐一展开。

2.1 OTA升级：智能门锁的“空中加油”通道

核心原理：从云端到端侧的可靠交付

OTA（Over-The-Air）升级是指通过无线网络（Wi-Fi、蓝牙、NB-IoT或蜂窝网络）将固件、系统或模型数据包从云端服务器传输到智能门锁端侧，并在本地完成校验、写入和激活的过程。与手机OTA不同，智能门锁对升级的可靠性和断电安全要求极为苛刻——门锁在升级过程中如果出现“变砖”，将直接导致用户无法进出家门，这是不可接受的事故。

智能门锁OTA升级通常分为三个层次：

固件升级：更新MCU（微控制器）或SoC（系统级芯片）的底层代码，修复漏洞、优化功耗、调整外设驱动。
系统升级：更新Linux/RTOS内核、文件系统或中间件，通常涉及较大的数据包（几十MB到几百MB）。
模型升级：仅更新AI算法模型文件（如人脸识别模型、指纹特征提取模型），数据量相对较小（几百KB到几十MB），但需要与算法框架版本严格匹配。

  关键术语：差分升级（Delta OTA）与全量升级（Full OTA）。差分升级只传输新旧版本之间的差异部分，体积小、省流量，但生成差分包需要服务器端具备版本管理能力；全量升级则传输完整镜像，简单可靠但流量消耗大。智能门锁通常采用“全量为主、差分为辅”的策略，因为门锁的Wi-Fi带宽有限，且升级窗口期短（用户不会长时间等在门口）。

判断方法：如何评估OTA通道的健康度

在工程实践中，评估OTA升级通道是否可靠，需要关注以下核心指标：

指标名称	定义	健康阈值	异常表现
升级成功率	完成升级并正常激活的设备数 / 发起升级的设备总数	≥ 99.5%	低于99%需排查网络或固件问题
平均升级耗时	从下载开始到激活完成的平均时间	≤ 3分钟（Wi-Fi环境）	超过5分钟用户会焦虑
断点续传率	因网络中断后能恢复下载的比例	≥ 95%	低续传率导致流量浪费
升级失败回滚率	升级失败后能自动回滚到旧版本的比例	100%	任何无法回滚的情况都是事故

此外，还需要关注升级时机。智能门锁的OTA升级不能像手机那样随时进行，必须避开用户使用高峰期（如早晚出门/回家时段），并确保门锁电量充足（通常要求剩余电量≥30%），否则升级过程中断电将导致严重后果。

案例拆解：一次典型的门锁OTA升级流程

假设某品牌智能门锁需要推送v2.3.1固件，修复低电量下人脸识别模块偶发死机的问题。具体流程如下：

灰度准备：在云端将升级包标记为“灰度中”，先推送给内部测试团队和种子用户（约500台设备）。
条件检查：门锁端收到升级通知后，检查当前电量（>40%）、网络信号（RSSI > -70dBm）、是否处于锁内空闲状态（无人操作）。
下载与校验：通过HTTPS下载全量包（约45MB），使用SHA-256校验文件完整性，并验证数字签名。
写入与激活：将新固件写入备用分区（A/B分区机制），写入完成后原子切换启动标志，重启进入新系统。
结果上报：激活成功后，门锁上报新版本号；若失败，自动回滚到旧分区并上报错误日志。

该案例中，A/B分区机制是核心保障——即使新固件在启动时崩溃，Bootloader也能自动回退到旧分区，确保门锁始终可用。

2.2 模型更新：从“旧脸”到“新脸”的平滑过渡

核心原理：模型文件的可替换性与兼容性

人脸识别模型更新与固件更新有本质区别。固件更新涉及代码逻辑变更，而模型更新只是替换神经网络权重文件（如 .tflite、.onnx、.rknn 等格式）。但模型更新同样面临挑战：新模型可能改变特征向量的分布，导致旧模型注册的人脸特征（存储在门锁本地数据库中的特征向量）无法直接匹配。

模型更新主要有两种策略：

全量替换：直接删除旧模型，部署新模型。优点是简单直接；缺点是如果新旧模型的特征空间差异较大，所有已注册用户的人脸特征都需要重新计算（需要用户重新录入人脸），体验极差。
增量兼容：新模型在训练时保留旧模型的特征输出层（或通过蒸馏学习保持特征空间一致性），使得旧特征向量在新模型下仍然有效。这是目前主流方案，但需要算法团队在训练阶段就考虑版本兼容性。

经验提醒：在模型更新前，务必在实验室用“旧模型注册的特征库”去测试“新模型的识别率”。如果识别率下降超过1%，就需要考虑特征迁移或重新注册策略。不要轻信训练集上的精度提升，端侧部署的模型必须用真实注册数据验证。

判断方法：模型更新的版本管理

模型版本管理比代码版本管理更复杂，因为模型文件是二进制大对象（BLOB），且与训练数据、训练框架、量化方式强相关。建议采用以下命名规范：

模型命名规范：{算法代号}_{训练数据集版本}_{网络结构}_{量化精度}_{发布时间}
示例：face_v3.2_ghostnet_q8_20240515.rknn
含义：人脸识别v3.2版本，使用ghostnet结构，8bit量化，2024年5月15日发布

同时，模型更新必须携带元信息（JSON格式），包括：最低固件版本要求、兼容的算法框架版本、特征向量维度、相似度阈值建议值等。门锁端在加载模型前会校验这些元信息，避免不兼容的模型被加载。

案例拆解：人脸模型升级导致“老用户无法开门”

某厂商将人脸识别模型从v2.0升级到v2.1，新模型在公开测试集上错误率降低了30%。灰度发布后，客服收到大量投诉：部分老用户（尤其是戴眼镜、发型改变的用户）识别失败率明显上升。排查发现：

根因：v2.1模型的特征输出维度从256维变为512维，且特征分布发生了偏移。旧模型注册的256维特征向量无法直接用于新模型比对。
影响范围：约15%的存量用户受到影响，这些用户的人脸特征是在旧模型下注册的。
解决方案：紧急暂停灰度，回滚到v2.0模型。同时，在v2.2模型中增加“特征迁移层”，将旧特征映射到新特征空间，确保兼容性。
复盘教训：模型升级前必须做“跨版本兼容性测试”，不能只看算法指标，更要看端侧实际注册数据的匹配效果。

2.3 人脸识别模型：端侧AI的“大脑”与“眼睛”

核心原理：从图像到特征向量的映射

智能门锁的人脸识别模型通常运行在低功耗的AI芯片上（如瑞芯微RK3566、地平线X3、安谋Cortex-M55+Ethos-U55等）。模型的核心任务是将摄像头采集的人脸图像转换为一个固定维度的特征向量（Embedding），然后通过计算特征向量之间的余弦相似度或欧氏距离来判断是否为同一人。

一个完整的端侧人脸识别模型包含三个子模块：

人脸检测：从画面中定位人脸位置（如RetinaFace、SCRFD），输出人脸边界框和关键点（眼睛、鼻子、嘴角）。
人脸对齐：根据关键点做仿射变换，将人脸校正为标准姿态（通常为112x112像素）。
特征提取：通过卷积神经网络（如MobileFaceNet、GhostNet）提取512维或256维的特征向量。

此外，活体检测模块（判断是否为真人而非照片/视频）通常独立于识别模型，但也会随OTA进行更新。

判断方法：端侧模型的性能指标

在智能门锁场景下，模型性能不能只看识别率，还要关注以下工程指标：

指标	说明	门锁场景要求
推理延迟	从输入图像到输出特征向量的耗时	≤ 200ms（含检测+对齐+提取）
模型大小	量化后的模型文件体积	≤ 10MB（受限于Flash空间）
RAM占用	模型运行时占用的内存	≤ 50MB（与系统其他进程共存）
功耗	单次识别的平均功耗	≤ 0.5W（避免电池快速耗尽）
误识率(FAR)	将他人误认为主人的概率	≤ 0.001%
拒识率(FRR)	将主人误认为他人的概率	≤ 1%

风险提示：FAR和FRR是相互制约的。降低FAR（更安全）会导致FRR升高（主人被拒之门外）。在门锁场景中，通常优先保证低FAR（安全性），但FRR过高会严重影响用户体验。模型更新时，必须明确本次更新是偏向“更安全”还是“更便捷”，并在发布说明中告知用户。

常见误区与总结复盘

在理解OTA与模型更新时，工程师常陷入以下误区：

误区一：模型更新等于固件更新。实际上，模型更新可以独立于固件进行，且频率更高（模型可能每月更新，固件每季度更新）。
误区二：OTA升级包越大越好。大包虽然包含完整信息，但下载失败率更高。对于模型更新，优先使用差分或增量方式。
误区三：忽略模型量化影响。训练时是FP32精度，部署时量化为INT8，精度损失可能超过2%。必须在量化后重新评估FAR/FRR。
误区四：没有回滚预案。任何OTA升级都必须有回滚机制，模型更新也不例外。建议保留至少两个历史模型版本在Flash中。

总结来说，OTA升级、模型更新和人脸识别模型三者构成了智能门锁持续进化的技术底座。理解这些基础概念，是后续掌握灰度发布策略、回滚机制和模型质量评估的前提。在实际项目中，建议建立“模型版本-固件版本-算法框架版本”的三元组管理矩阵，确保任何一次更新都可追溯、可验证、可回退。