简介这份资源是一套基于深度神经网络的终身学习智能家居系统实现面向嵌入式开发、深度学习与物联网方向的开发者及学生适合作为课程设计、毕业设计或智能家居项目原型参考。系统以语音交互为核心通过采集用户日常调节指令存入数据库并持续训练实现个性化智能管理同时结合光照与温度传感器由智能管家自动调节灯具亮度及空调或地暖温度营造舒适室内环境。压缩包共30个文件约1.98MB包含8个Python脚本、17张PNG图片、2个HTML页面及3个pyc缓存文件涵盖语音处理、多线程调度、Web控制界面与视频采集等模块目录结构清晰。目前已有54人学习下载读者可从中获取完整的系统架构、传感器联动逻辑与终身学习训练思路便于快速复现与二次开发。1. 终身学习智能家居为什么你的模型越训越“傻”智能家居设备有个很尴尬的现实摄像头、传感器、语音模块出厂时训好的模型到了用户家里往往撑不过三个月。新买的灯具、换了位置的沙发、家人新增的方言口音都会让原本 95% 准确率的模型掉到 70% 以下。更麻烦的是你不可能把用户家里的数据全部回传重训——带宽、隐私、算力都不允许。这就是「基于深度神经网络的终身学习智能家居系统」要解决的核心问题让模型在本地持续学新东西同时不忘记旧本事。这个方向适合两类人一类是做边缘 AI 部署的工程师手上有 NPU 或低功耗 GPU 的开发板想把模型更新链路跑通另一类是做智能家居产品定义的人需要判断「终身学习」到底是真需求还是伪命题。我自己的判断是它值得做但前提是你得先接受一个反直觉的事实——灾难性遗忘不是 bug是深度网络的本性。你越用力在新数据上微调旧任务的权重就被覆盖得越狠。后面几章我会把这条链路拆成可复现的步骤从任务边界怎么切、回放样本怎么存到 EWC 正则项怎么加、部署时怎么验证没忘。2. 终身学习的三种落地路线回放、正则、还是动态扩展在动手写代码之前得先选路线。终身学习在学术上有三大流派但落到智能家居这种资源受限场景选型逻辑和论文里完全不一样。我一般会先问三个问题设备端能存多少历史样本训练时能不能拿到任务 ID推理延迟容忍度是多少这三个答案基本就决定了你走哪条路。2.1 回放法最稳但最吃存储回放法Replay的逻辑很朴素既然新数据会覆盖旧知识那我就把旧数据留一小部分每次训练时混进去。在智能家居场景里这意味着设备要维护一个「记忆缓冲区」存每个历史任务的代表性样本。常见做法是每类存 20 到 50 个样本按 herding 算法选最靠近类中心的那些。假设你有 10 个任务、每个任务 5 类、每类存 30 张 224x224 的 RGB 图粗算一下10 × 5 × 30 × 224 × 224 × 3 字节 ≈ 2.2 GB。这对云端不算什么但对一个跑在本地的小盒子就是灾难。所以实际部署时我会做两件事一是把回放样本降采样到 96x96二是用特征向量代替原图存储——把旧样本过一遍冻结的特征提取器只存 512 维的 embedding存储直接降到几 MB 级别。import numpy as np import torch import torch.nn as nn class ReplayBuffer: def __init__(self, feature_dim512, max_per_class30): self.feature_dim feature_dim self.max_per_class max_per_class # 用 dict 按类别索引存特征和标签 self.buffer {} def add(self, features, labels): features: (N, D) 已过冻结backbone的embedding labels: (N,) 类别id features features.detach().cpu().numpy() labels labels.detach().cpu().numpy() for f, l in zip(features, labels): if l not in self.buffer: self.buffer[l] [] # 超过上限就随机替换保持多样性 if len(self.buffer[l]) self.max_per_class: self.buffer[l].append(f) else: idx np.random.randint(0, self.max_per_class) self.buffer[l][idx] f def sample(self, batch_size): all_feats, all_labels [], [] for l, feats in self.buffer.items(): all_feats.extend(feats) all_labels.extend([l] * len(feats)) all_feats np.array(all_feats) all_labels np.array(all_labels) idx np.random.choice(len(all_feats), batch_size, replaceFalse) return (torch.tensor(all_feats[idx], dtypetorch.float32), torch.tensor(all_labels[idx], dtypetorch.long))这段代码的关键参数是max_per_class和feature_dim。max_per_class设太小旧任务的决策边界会模糊设太大存储和训练时间线性上涨。我的经验值是 20 到 30 之间配合 512 维特征10 个任务总存储控制在 5 MB 以内。feature_dim取决于你用的 backboneMobileNetV3 的倒数第二层是 576 维ResNet18 是 512 维别硬凑。回放法的坑在于如果新任务和旧任务的特征分布差异极大比如从「识别手势」跳到「识别烟雾」混进去的旧特征反而会干扰新任务收敛。这时候要调低回放样本的采样比例从 1:1 降到 1:3。2.2 正则法EWC 及其在嵌入式端的简化正则法的代表是 EWCElastic Weight Consolidation。它的核心思想是每个权重对旧任务的重要性不一样重要的权重在新任务训练时别动太多。数学上就是在损失函数里加一项 Fisher 信息矩阵加权的 L2 惩罚。import torch import torch.nn as nn import torch.nn.functional as F class EWC: def __init__(self, model, lambda_ewc1000): self.model model self.lambda_ewc lambda_ewc self.params {n: p.clone().detach() for n, p in model.named_parameters() if p.requires_grad} self.fisher {} def compute_fisher(self, dataloader, num_samples200): 用旧任务的一小批数据估计Fisher信息 self.fisher {n: torch.zeros_like(p) for n, p in self.params.items()} self.model.eval() count 0 for x, y in dataloader: if count num_samples: break self.model.zero_grad() out self.model(x) loss F.cross_entropy(out, y) loss.backward() for n, p in self.model.named_parameters(): if p.grad is not None: self.fisher[n] p.grad.data ** 2 count x.size(0) for n in self.fisher: self.fisher[n] / count def penalty(self): loss 0 for n, p in self.model.named_parameters(): if n in self.fisher: loss (self.fisher[n] * (p - self.params[n]) ** 2).sum() return self.lambda_ewc * losslambda_ewc是最关键的参数。设 100 以下正则项形同虚设该忘还是忘设 10000 以上新任务根本学不动准确率卡在随机水平。我一般从 1000 起步观察新任务 loss 下降速度如果 5 个 epoch 还降不到 0.5 以下就降到 500。EWC 在嵌入式端的简化做法是只对最后两层全连接计算 Fisher前面的卷积层共享特征本来就不容易忘。这样 Fisher 矩阵的存储从几十 MB 降到几百 KB代价是旧任务准确率多掉 2 到 3 个百分点可以接受。2.3 动态扩展什么时候该加分支如果新任务和旧任务差异实在太大——比如从「图像分类」跳到「音频事件检测」——回放和正则都救不了。这时候正确做法是动态扩展给新任务开一个新的分支或新的子网络旧分支冻结。在智能家居里这对应的是「多模态任务隔离」。摄像头任务走视觉分支麦克风任务走音频分支共享底层特征提取高层各自独立。代价是参数量上涨但推理时可以按任务 ID 路由延迟不增加。选型决策表如下路线存储开销新任务学习速度旧任务保持适用场景回放法中特征级 5MB快好任务同模态、类别有重叠EWC 正则低Fisher 几百 KB中中任务同模态、资源极紧动态扩展高参数量翻倍快最好跨模态、任务差异大3. 把终身学习塞进智能家居从任务切分到端侧部署选完路线接下来是工程落地。这一章我按数据流顺序讲任务怎么定义、模型怎么改、训练循环怎么写、端侧怎么跑。3.1 任务边界定义按时间窗还是按事件终身学习的前提是「任务」有明确边界。智能家居里两种切法按时间窗每周一个任务和按事件用户新增一个设备算一个任务。按时间窗的问题是如果这一周没有新数据任务就是空的训练浪费。按事件的问题是事件触发频率不可控可能一天来三个也可能一个月没有。我一般用混合策略以事件触发为主但设一个最小间隔比如 24 小时避免频繁重训。同时维护一个「待学习队列」新样本先入队攒够 200 条或满 24 小时才触发一次训练。这样既不会漏学也不会把设备跑死。任务 ID 的分配要单调递增且和模型版本绑定。每次训练完成后任务 ID 加一旧任务的 Fisher 矩阵或回放缓冲区打上对应版本标签。推理时如果遇到未知任务走默认分支同时记录日志等下次训练时纳入。3.2 模型改造共享 backbone 任务特定 head标准做法是把模型拆成 backbone 和 head。backbone 可以是 MobileNetV3、EfficientNet-Lite 或任何你熟悉的轻量网络head 按任务数量动态增加。import torch import torch.nn as nn class LifelongNet(nn.Module): def __init__(self, backbone, feature_dim576, num_tasks1, classes_per_task5): super().__init__() self.backbone backbone self.feature_dim feature_dim self.heads nn.ModuleList() for _ in range(num_tasks): self.heads.append(nn.Linear(feature_dim, classes_per_task)) self.current_task 0 def forward(self, x, task_idNone): feat self.backbone(x) if task_id is None: task_id self.current_task return self.heads[task_id](feat) def add_task(self, classes_per_task5): new_head nn.Linear(self.feature_dim, classes_per_task) self.heads.append(new_head) self.current_task len(self.heads) - 1 return self.current_task关键点是backbone的输出维度要和feature_dim对齐。如果你用 MobileNetV3-Small最后一层卷积后接 adaptive avg pool输出是 576 维用 ResNet18 则是 512 维。classes_per_task不要求每个任务一样但为了简化回放缓冲区的管理我一般固定成 5 或 10。训练时只更新当前 task 的 head 和 backbone如果走回放或 EWC旧 head 冻结。推理时根据任务 ID 路由到对应 head。如果任务 ID 未知可以取所有 head 的 max logit 或 entropy 加权但实测下来准确率会掉 5 到 8 个百分点所以任务 ID 的传递链路要保证可靠。3.3 训练循环回放 EWC 混合策略纯回放或纯 EWC 都有短板我一般混着用回放负责保持旧任务的决策边界EWC 负责约束 backbone 的权重漂移。def train_one_task(model, new_loader, replay_buffer, ewc, optimizer, epochs10): model.train() for epoch in range(epochs): for x, y in new_loader: # 新任务损失 out_new model(x, task_idmodel.current_task) loss_new F.cross_entropy(out_new, y) # 回放损失从缓冲区采样旧特征过旧head if len(replay_buffer.buffer) 0: old_feat, old_label replay_buffer.sample(batch_size32) # 旧特征直接过旧head不经过backbone old_task_id model.current_task - 1 if old_task_id 0: out_old model.heads[old_task_id](old_feat) loss_replay F.cross_entropy(out_old, old_label) else: loss_replay 0 else: loss_replay 0 # EWC 正则 loss_ewc ewc.penalty() if ewc is not None else 0 total_loss loss_new 0.5 * loss_replay loss_ewc optimizer.zero_grad() total_loss.backward() optimizer.step() return model三个损失项的权重需要调。loss_replay的系数我一般设 0.3 到 0.7太低旧任务掉点太高新任务学不动。loss_ewc的系数就是lambda_ewc前面说过从 1000 起步。注意回放损失里旧特征不经过 backbone直接过旧 head。这是因为 backbone 正在被新任务更新如果旧特征再过一遍 backbone梯度会回传到 backbone反而加剧遗忘。这个细节很多开源实现都搞错了血泪经验。3.4 端侧部署ONNX 导出与推理验证训练在服务器上跑部署在设备端。导出 ONNX 时要把所有 head 都带上推理时按 task_id 选择输出。# 导出 ONNXopset 11 兼容性最好 python export_onnx.py --model lifelong_net.pth --output lifelong.onnx --opset 11 # 用 onnxruntime 验证输出一致性 python -c import onnxruntime as ort import numpy as np sess ort.InferenceSession(lifelong.onnx) x np.random.randn(1, 3, 224, 224).astype(np.float32) task_id np.array([0], dtypenp.int64) out sess.run(None, {input: x, task_id: task_id}) print(out[0].shape) 端侧推理的延迟预算MobileNetV3-Small 在主流 NPU 上单帧 8 到 15 ms加上 head 计算不超过 20 ms。如果超过 30 ms检查是不是 backbone 没量化。INT8 量化后延迟能再降 40%但旧任务准确率可能掉 1 到 2 个点需要重新跑一遍验证集。验证方法每学完一个新任务把之前所有任务的测试集跑一遍记录准确率矩阵。理想情况下对角线当前任务高上三角旧任务不掉超过 5 个点。如果掉超过 10 个点说明回放比例或 EWC 系数需要调。4. 避坑与排查终身学习系统最容易翻车的五个地方这一章是我踩过的坑按「现象 → 原因 → 解决」写。每个坑都真实发生过不是理论推演。4.1 新任务准确率上不去loss 卡在 1.6 附近现象学第三个任务时训练 loss 从 1.6 降到 1.5 就下不去了准确率卡在 40%。原因EWC 的lambda_ewc设太大我一开始设了 5000backbone 权重被旧任务的 Fisher 矩阵锁死新任务的特征提取器根本没法适应。解决把lambda_ewc降到 500同时只对最后两个卷积块计算 Fisher。新任务 loss 在 3 个 epoch 内降到 0.8 以下准确率回到 85%。4.2 旧任务准确率断崖式下跌从 92% 掉到 60%现象学完新任务后回测旧任务准确率直接腰斩。原因回放缓冲区里旧样本的类别分布和新任务高度重叠采样时被新任务样本淹没。比如旧任务有「开灯」「关灯」新任务也有「开灯」「关灯」但新任务的「开灯」样本是不同光照条件回放时旧样本被覆盖。解决回放采样时按类别分层采样每个类别至少抽 2 个样本保证旧任务的每个类都有代表。同时把回放损失系数从 0.3 提到 0.6。4.3 端侧推理时任务 ID 传错输出全是乱码现象设备端推理结果和服务器端对不上logit 值差了一个数量级。原因ONNX 导出时task_id的 dtype 是 int64但端侧代码传的是 int32onnxruntime 没报错但做了隐式转换导致路由到错误的 head。解决在端侧代码里显式转换task_id np.array([tid], dtypenp.int64)并在导出后用 onnxruntime 跑一遍一致性检查确保服务器和端侧输出余弦相似度大于 0.999。4.4 回放缓冲区存储爆炸设备存储写满现象跑了两个月设备存储从 2 GB 用到 7 GB系统开始杀进程。原因回放缓冲区存的是原始特征向量但feature_dim设了 1024且max_per_class设了 10010 个任务 50 个类总存储 1024 × 100 × 50 × 4 字节 ≈ 20 MB看起来不大但每次训练会生成中间 checkpoint累积起来就爆了。解决feature_dim降到 256用 PCA 降维max_per_class降到 30同时训练完删除中间 checkpoint只保留最终模型和缓冲区。存储回到 3 MB 以内。4.5 新任务训练时旧 head 梯度泄漏旧任务悄悄退化现象训练时明明冻结了旧 head但回测旧任务还是掉了 3 个点。原因PyTorch 的requires_gradFalse只影响梯度计算但如果旧 head 的输入特征来自正在更新的 backbonebackbone 的梯度会通过旧 head 的权重回传即使旧 head 权重不更新间接影响 backbone。解决回放损失里旧特征不经过 backbone直接从缓冲区取。同时把旧 head 的requires_grad设为 False并在 optimizer 里只传当前 head 和 backbone 的参数。5. 验证终身学习有没有真学会三个可量化的指标最后一章讲验证。终身学习最怕自欺欺人——你以为模型没忘其实只是测试集和训练集重叠了。我一般用三个指标交叉验证。5.1 准确率矩阵与遗忘率每学完一个任务把所有历史任务的测试集跑一遍得到一个 N×N 的矩阵行是任务列是学习顺序。对角线是当前任务准确率上三角是旧任务保持率。遗忘率定义F (1/(N-1)) * Σ (acc_ii - acc_iN)其中acc_ii是任务 i 刚学完时的准确率acc_iN是学完所有任务后任务 i 的准确率。F 小于 0.05 算优秀0.05 到 0.1 可接受大于 0.15 说明回放或正则没起作用。def compute_forgetting(acc_matrix): acc_matrix[i][j]: 学完任务j后任务i的准确率 n len(acc_matrix) forgetting 0 for i in range(n - 1): best max(acc_matrix[i][j] for j in range(i, n)) final acc_matrix[i][n - 1] forgetting (best - final) return forgetting / (n - 1)5.2 反向迁移与正向迁移反向迁移BWT衡量新任务对旧任务的影响正向迁移FWT衡量旧任务对新任务的帮助。BWT 为负说明遗忘了为正说明新任务反而提升了旧任务——这在智能家居里偶尔发生比如学了「夜间开灯」后「白天开灯」的识别率也涨了因为光照不变性特征被强化了。FWT 的计算FWT (1/(N-1)) * Σ (acc_iN - acc_i_random)其中acc_i_random是任务 i 在随机初始化模型上的准确率。FWT 大于 0.1 说明知识迁移有效。5.3 端侧一致性检查服务器端和端侧的准确率差异不能超过 1 个点。超过说明量化或导出有问题。我一般跑 500 张测试图对比两边输出计算 top-1 一致率。# 端侧一致性检查脚本 python check_consistency.py \ --server_model lifelong_net.pth \ --onnx_model lifelong.onnx \ --test_dir ./test_images \ --num_samples 500如果一致率低于 99%检查三件事输入归一化参数是否一致、task_id 的 dtype 是否一致、ONNX 的 opset 是否和端侧 runtime 兼容。我自己的习惯是每次训练完新任务先跑准确率矩阵再跑端侧一致性两个都过了才推送到设备。有一次偷懒跳过了端侧检查结果设备上任务 ID 传错用户反馈「灯控失灵」排查了两天才发现是 int32 和 int64 的锅。终身学习系统的验证链路比普通模型长别省步骤。希望帮到你。本文还有配套的精品资源点击获取