联邦学习框架下的分心驾驶检测：三骨干网络对比与实战

简介：这是一份基于联邦学习的分心驾驶检测完整项目，使用VGG19、EfficientNet和ResNet50三种模型对驾驶员状态数据集分别分类，并在联邦聚合过程中引入Shapley值与激励机制，适合计算机、人工智能等专业学生用于毕设、课程设计或联邦学习入门实践。压缩包共21个文件，体积约99KB，以Python源码为主（11个py文件），另含Markdown说明文档、PNG结构图、依赖清单与LICENSE等，代码覆盖数据生成、模型构建、联邦训练主流程与工具模块，可对照README理解整体结构，目录划分也便于按环节拆解学习。目前已有151人学习下载；项目为作者毕设且经完整测试，答辩评分达96分，关键代码均可运行。下载后可从源码中学习三种模型性能对比、联邦聚合策略及Shapley激励机制的设计思路，同时获得可扩展的代码框架与文档说明，便于在此基础上二次开发。

1. 分心驾驶检测遇上联邦学习：三个骨干网络为什么能塞进同一套框架

分心驾驶检测在真实落地时最难受的不是模型精度不够，而是数据根本不敢出设备。车载摄像头拍下的司机姿态属于敏感生物特征，想靠把数据集中到一台服务器上训练VGG19或者ResNet50，合规这关就过不去。联邦学习恰好能把这个矛盾绕开：客户端本地保存数据、只上传模型权重，服务端完成聚合后再下发更新。这个项目标题把VGG19、EfficientNet和ResNet50三种骨干网络放进同一套联邦学习框架里做分心驾驶检测，解决的正是「如何在数据不出本地的前提下，从三个不同侧重点的模型里选出一个最合适的」这件事。本文会拆出数据预处理、三模型联邦训练、聚合策略与参数配置的完整落地路径，让新手能跑通，让熟手能直接改参复用。

2. 分心驾驶数据集与三骨干网络选型：为什么是VGG19、EfficientNet和ResNet50

2.1 State Farm分心驾驶数据集的处理逻辑

分心驾驶检测最常用的开源数据集是Kaggle的State Farm Distracted Driver Detection，共约2.2万张图像、10个类别——正常驾驶、发短信、打电话、操作收音机、喝水、化妆等。这个项目标题既然同时挂了VGG19、EfficientNet和ResNet50，意味着训练时要跑三份独立实验，数据预处理最好一次性做成通用管线，避免每换一个模型就重写一遍图像读取逻辑。

我通常把预处理拆成三步：先按驾驶员ID划分数据——保证同一个司机不会同时出现在训练集和测试集，否则模型学到的是「这个人长什么样」而不是「这个动作危险不危险」；再做尺寸统一，三个模型的输入尺寸不一致，VGG19和ResNet50是224×224，EfficientNet-B0是224×224但B4以上会到380×380，为了不折腾，统一缩放到224×224；最后做归一化，三个模型在ImageNet上预训练时的mean和std略有差异，但直接用ImageNet标准值（mean=[0.485, 0.456, 0.406]，std=[0.229, 0.224, 0.225]）在迁移学习场景下基本够用。

# 目录结构建议：保证三份实验共享同一份预处理结果 dataset/ ├── train/ │ ├── c0_normal/ # 每个类别一个子目录 │ ├── c1_text_right/ │ └── ... ├── test/ └── driver_imgs_list.csv # 官方提供的司机ID与图片映射

代码逻辑说明：用软链接或目录映射而不是复制图片，是为了在调试预处理参数时不用重新拷贝几十GB数据。driver_imgs_list.csv是必须读的，因为按司机划分训练/验证集要靠这个文件里的driver_id字段。

2.2 VGG19：当基线模型用，别指望它跑得快

VGG19在分心驾驶这类任务上已经属于「老将」——16个卷积层加3个全连接层，参数量约143M，单张224×224图像前向推理在普通GPU上约需30-50ms。选它的理由和选老车一样：结构简单、容易调、出了bug好查。你可以故意把它当基线，后面EfficientNet和ResNet50的精度提升都拿它的结果当参照物。

在联邦学习场景里，VGG19最大的问题不是精度而是通信开销。143M参数按float32算，单次上传约572MB；如果10个客户端各传一份，服务端聚合时内存直接吃紧。所以用VGG19做联邦学习，必须配梯度压缩或只传部分层参数。我一般只传conv4_3之后的高层特征层，底层浅层特征在分心驾驶这种域差异不大的任务里几乎不更新，省一半通信量。

# vgg19_feature_extractor.py import torch import torch.nn as nn from torchvision import models def get_vgg19_backbone(freeze_layers=12): """加载VGG19预训练权重，冻结前12层卷积""" model = models.vgg19(weights=models.VGG19_BN_Weights.DEFAULT) features = list(model.features.children()) # 冻结前12层：VGG19的浅层学的是边缘/纹理，迁移到分心驾驶时不需要重新学 for i, layer in enumerate(features): if i < freeze_layers: for param in layer.parameters(): param.requires_grad = False # 替换分类头：ImageNet的1000类换成10类驾驶行为 model.classifier[6] = nn.Linear(4096, 10) return model

参数说明：freeze_layers=12控制冻结深度，如果客户端本地数据量很少（比如每客户端只有500张图），冻结层数可以提到14；本地数据充足就降到8。VGG19的BN层在联邦聚合时有个隐藏坑——见第5章，这里先埋个伏笔。

2.3 EfficientNet：通信量最小，但要注意缩放系数

EfficientNet用神经架构搜索定标出一组复合缩放系数，B0的参数量只有5.3M，是VGG19的二十七分之一。在联邦学习里，通信量直接决定一轮训练耗时。同样是10个客户端，EfficientNet-B0单次上传约21MB，比VGG19的572MB少了一个数量级。这意味着相同带宽下，EfficientNet能跑的联邦通信轮数是VGG19的27倍，收敛速度优势巨大。

EfficientNet的坑在于BatchNorm统计量的聚合。联邦学习服务端做FedAvg时，如果简单地对各客户端的BN层的running_mean和running_var求平均，聚合后的模型在推理阶段容易出现分布偏移。分心驾驶数据里客户端之间光照条件差异很大，有的装的是朝左的摄像头、有的是朝右的，BN统计量漂移会比一般任务更严重。

# efficientnet_client.py import torch import torch.nn as nn from torchvision import models def get_efficientnet_backbone(version='b0', dropout=0.2): """加载EfficientNet预训练模型，替换分类头""" weights_map = { 'b0': models.EfficientNet_B0_Weights.DEFAULT, 'b1': models.EfficientNet_B1_Weights.DEFAULT, } model = models.efficientnet_b0(weights=weights_map[version]) # EfficientNet的features是Sequential，最后几层MBConvBlock负责高阶语义 # 微调时全量放开，因为B0参数量小，即使全部训练通信开销也可控 in_features = model.classifier[1].in_features model.classifier = nn.Sequential( nn.Dropout(p=dropout, inplace=True), nn.Linear(in_features, 10) ) return model

参数说明：EfficientNet的dropout放在分类头前，调大dropout能缓解联邦学习早期客户端过拟合问题——尤其当某客户端只有单一司机的数据时，模型很容易记住这个人而不是动作。version参数要配合输入尺寸调整，B1需要240×240输入，继续用224×224会掉2-3个点精度。

2.4 ResNet50：精度和通信量的折中

ResNet50的25.6M参数介于VGG19和EfficientNet-B0之间，单次上传约102MB。它的残差连接让梯度在深层网络中传播更稳定，在Non-IID（非独立同分布）的联邦场景下表现反而优于VGG19——因为每个客户端的数据分布差异大，梯度更新方向噪声也大，残差结构相当于给优化过程加了阻尼。

选型时不用纠结「哪个最好」，而是要看你的实际约束：如果客户端带宽紧张、轮次预算多，选EfficientNet；如果想少调参、快速验证联邦框架本身通不通，选ResNet50；VGG19只作为精度对比的基线，不建议在生产环境里选它做联邦主模型。三个模型在联邦框架里其实是并列实验的关系，跑完对比结果再定最终模型，而不是同时融合三个模型的特征——别误解标题里的「和」，这里是候选模型不是模型集成。

# resnet50_backbone.py import torch.nn as nn from torchvision import models def get_resnet50(num_classes=10, freeze_stage=2): """ResNet50迁移学习：按stage冻结""" model = models.resnet50(weights=models.ResNet50_Weights.DEFAULT) # ResNet50分为4个stage，freeze_stage=2表示冻结前两个stage的残差块 # stage1和stage2学的是通用边缘特征，分心驾驶数据不需要重新学 stages = [ model.conv1, model.bn1, model.relu, model.maxpool, model.layer1, model.layer2, model.layer3, model.layer4 ] for stage in stages[:freeze_stage * 2 + 4]: for param in stage.parameters(): param.requires_grad = False model.fc = nn.Linear(model.fc.in_features, num_classes) return model

参数说明：这里的freeze_stage=2对应冻结到layer2之前，实际调试时看验证集loss——如果loss下降太慢说明冻结过深，逐步减到1或0。ResNet50的最后一个全连接层替换后需要更大的学习率，常见做法是把fc层学习率设为骨干的10倍，PyTorch里可以用param_group实现。

3. 联邦学习框架搭建：FedAvg聚合与三模型的统一客户端接口

3.1 客户端-服务端架构与通信协议

联邦学习的核心不是模型而是编排逻辑。服务端负责下发全局模型、收集客户端更新、完成聚合；客户端负责在本地数据上训练若干轮后上传权重。分心驾驶场景里，客户端可以理解成每一辆运营车辆的车载边缘盒子，服务端是车队的中心服务器。

通信协议建议直接走PyTorch的state_dict序列化，不要自己定义权重结构。每个客户端训练完，把model.state_dict()里的张量打包成字节流上传；服务端聚合后下发新权重。如果客户端数量上百，考虑用gRPC代替HTTP，但项目起步阶段用Flask或FastAPI搭一个同步通信接口就够了——联邦学习原型验证的阶段，瓶颈几乎永远在模型训练而不是网络传输。

# fl_server.py - 服务端聚合核心逻辑 import copy import torch from collections import OrderedDict def fed_avg(global_model, client_weights_list, client_sizes): """ FedAvg聚合：按客户端本地样本数加权平均 client_weights_list: 每个客户端的state_dict client_sizes: 每个客户端的训练样本数 """ global_dict = global_model.state_dict() total_samples = sum(client_sizes) # 初始化聚合字典 averaged_weights = OrderedDict() for key in global_dict.keys(): averaged_weights[key] = torch.zeros_like(global_dict[key]) # 加权求和 for client_weights, client_size in zip(client_weights_list, client_sizes): weight = client_size / total_samples for key in averaged_weights.keys(): averaged_weights[key] += weight * client_weights[key] # 写回全局模型 global_model.load_state_dict(averaged_weights) return global_model

逻辑说明：这个实现是FedAvg最朴素的形态——按样本量加权。weight = client_size / total_samples这一步决定了数据量大的客户端对全局模型影响更大，符合直觉。但要注意：如果某个客户端本地数据分布极端（比如只有「正常驾驶」这一类），这个加权策略会让全局模型偏向多数类。所以实际项目中会在服务端加一个类别分布统计，样本量权重乘以一个类别均衡系数。

3.2 统一客户端训练接口：一个类适配三种骨干网络

三个骨干网络的预处理、模型定义、优化器配置都不同，但联邦框架不需要关心这些差异。用工厂模式把模型创建包一层，客户端只认model_type字段，本地训练逻辑完全复用。这是能跑通三模型对比实验的关键工程决策——否则你会写三套客户端代码，改一个参数要同步改三处。

# fl_client.py - 统一客户端训练循环 import torch import torch.nn as nn from torch.utils.data import DataLoader class FLClient: def __init__(self, client_id, model_type, train_loader, device='cuda'): self.client_id = client_id self.train_loader = train_loader self.device = device # 工厂方法创建模型 self.model = create_model(model_type).to(device) self.criterion = nn.CrossEntropyLoss() def local_train(self, global_state_dict, local_epochs=5, lr=1e-4): """在本地数据上训练，返回更新后的state_dict""" self.model.load_state_dict(global_state_dict) optimizer = torch.optim.Adam(self.model.parameters(), lr=lr) self.model.train() for epoch in range(local_epochs): for inputs, labels in self.train_loader: inputs, labels = inputs.to(self.device), labels.to(self.device) optimizer.zero_grad() outputs = self.model(inputs) loss = self.criterion(outputs, labels) loss.backward() optimizer.step() return self.model.state_dict()

参数说明：local_epochs=5是联邦学习里最常用的本地训练轮数，不是拍脑袋定的——经验上1-2轮欠拟合、10轮以上容易灾难性遗忘（见第5章），5轮左右在多数任务上是甜点区。lr=1e-4配合Adam是迁移学习的保守起点，如果你的客户端数据有几千张图可以放大到3e-4。这里的关键设计是load_state_dict严格加载全局权重，不允许部分加载，否则聚合逻辑会被打破。

3.3 三份客户端数据划分策略：模拟Non-IID的真实分布

分心驾驶的联邦学习如果按IID（独立同分布）划分数据——每个客户端都包含全部10个类且比例一致——那训练出的模型精度会虚高，真实场景根本不可能这么理想。真实分布是：有些司机只在白天开车、有些司机总在下班高峰堵车时化妆、还有的司机开车习惯左手拿手机。所以必须按驾驶员ID把数据切到不同客户端，让每个客户端的类别分布天然倾斜。

每个客户端分到的数据量也不一样——在真实车队里，有人天天开车有人一周开一次。这种数据量和分布的双重不均匀，才是联邦学习真正要处理的问题。对比IID划分的实验你会发现，Non-IID下模型收敛慢很多，大约要多1.5-2倍的通信轮数才能达到相同精度。用2.1节里的driver_imgs_list.csv做按司机分组，是最省事也最贴近实际的模拟方式。

4. 联邦训练的参数配置与收敛策略：通信轮数、本地Epoch和客户端采样率

4.1 三个关键超参数的作用与建议取值范围

联邦学习有自己的一套超参数体系，不能直接套用集中式训练的经验。最核心的三个是：通信轮数（rounds）、客户端采样率（fraction）、本地训练轮数（local_epochs）。它们共同决定了收敛速度、通信成本和模型精度的三角权衡。

推荐从这组值开始：rounds=100，fraction=0.3（10个客户端每轮采样3个），local_epochs=5，batch_size=32。这套组合在大多数分心驾驶数据集上能稳定收敛。如果精度不够，先调local_epochs到8试试，不行再调fraction——不要一上来就猛加通信轮数，轮数翻倍的代价是所有客户端都要等最慢的那个跑完。

4.2 服务端聚合的后处理：BN层统计量的特殊处理

第2章提过EfficientNet和ResNet50的BN层在联邦聚合时容易出问题。原因是BN层的running_mean和running_var是训练过程中累积的全局统计量，直接对多个客户端的累积值求平均，等于混合了多个不同分布的平均值。分心驾驶数据里客户端图像风格差异越大，这个问题的破坏力越强。我见过聚合后的模型推理时accuracy直接掉15个点的案例，根源就是BN统计量被平均坏了。

常见做法是在聚合后做一次「BN校准」：拿一小批服务端持有的公共数据（可以是没有隐私问题的公开分心驾驶样本）跑一次前向，重新计算每个BN层的running_mean和running_var。在联邦学习里这个技巧叫BN-statistics synchronization或post-aggregation calibration，代价极小但效果显著。

# bn_calibration.py def calibrate_bn(model, calib_loader, device='cuda'): """ BN层校准：用公共数据重新估计running_mean和running_var 必须在model.eval()之外跑，因为BN层在train模式下才会更新统计量 """ model.train() # 注意：保持train模式，否则BN统计量不更新 with torch.no_grad(): for inputs, _ in calib_loader: inputs = inputs.to(device) model(inputs) # 前向传播时BN层自动更新running_mean/var model.eval() return model

逻辑说明：把模型切回train()模式但用no_grad()限制梯度计算，这招是BN校准的关键——很多工程师在eval()模式下跑校准，结果BN统计量纹丝不动，还以为是代码bug。校准集只要几百张图就够，但类别要均衡，否则BN统计量会偏向校准集的类别分布。

4.3 模型选择与结果对比：三份实验怎么做横向评估

三个模型跑同样的联邦配置、同样的客户端划分，得到三组精度曲线。评估时要对比的不只是最终精度，还有收敛速度和通信成本。一台只有入门级GPU的服务器，跑100轮联邦通信，EfficientNet可能只需要几个小时，VGG19要跑到天荒地老。把「每轮通信耗时」计入决策，是联邦学习项目落地和学术实验最大的区别。

建议每轮通信后都在服务端跑一次全局模型评估，记录acc、macro-F1、混淆矩阵三个指标。混淆矩阵在分心驾驶场景里尤其重要——「正常驾驶」被误判成「用手机发短信」和「正常驾驶」被误判成「喝水」，对系统的容忍度完全不同。前者会让司机被频繁警告（烦人但安全），后者可能漏掉真正的危险行为。宏F1比分准确率更能反映少数类的表现，而分心驾驶数据集里「做动作」类的样本天然比「正常驾驶」少。

5. 联邦学习实战避坑：灾难性遗忘、Non-IID偏移与后门攻击的三个教训

5.1 灾难性遗忘：客户端本地训练轮数不是越多越好

现象：客户端local_epochs从5调大到20后，全局模型的精度不但没提升，反而在前几轮通信后出现断崖式下跌——从85%掉到60%再缓慢爬升，甚至无法恢复到之前的水平。

原因：每个客户端在本地数据上训练过多轮后，模型参数会严重偏向本地分布，服务端一聚合就把其他客户端的贡献「冲掉」。在Non-IID划分下，这个问题被放大——客户端的类别分布极端，本地训练10轮相当于是用一个严重偏斜的数据集重新训练整个模型。

解决：把local_epochs控制在3-5轮，同时加上梯度裁剪（clip_grad_norm_设为1.0或0.5）。如果业务上确实需要更多本地更新（比如带宽极有限、希望减少通信频率），改用FedProx算法——在本地损失函数里加一个和全局模型参数的L2距离惩罚项，防止更新跑太远。PyTorch里实现FedProx只需要在loss.backward()前手动加上prox_term。

5.2 BN统计量在Non-IID数据下被平均坏

现象：训练过程中全局模型的训练loss一直在降，但每轮通信后的验证集精度波动剧烈，甚至出现「训练loss 0.3、验证精度只有30%」的魔幻情况。换成没有BN层的VGG19（不带BN的原始版本）后，波动消失。

原因：不同客户端的图像光照、摄像头安装角度差异导致BN层的running_mean/var各自收敛到不同的分布中心。FedAvg对参数求平均时，把多个不同中心的统计量混在一起，推理时遇到哪个分布都不匹配。这在分心驾驶场景里尤其严重，因为不同车辆的摄像头位置和朝向差异会让特征分布产生系统性偏移。

解决：有两种路径——训练前用3.2节的load_state_dict严格加载，聚合后就地做4.2节的BN校准；或者在客户端本地训练时冻结BN层，只更新卷积层和全连接层参数。冻结BN的做法在联邦学习论文里叫FedBN，用model.eval()模式跑前向再手动更新参数层可以绕过BN统计量更新，工程上更好实现。我个人的经验是：如果客户端数据量充足，优先做BN校准；如果数据量少，直接冻结BN层更省心。

5.3 后门攻击：恶意客户端让模型对特定动作「失明」

现象：某轮通信后，全局模型在正常测试集上的精度几乎不变，但实际部署时，只要司机戴某款特定样式的墨镜，系统就判定为「正常驾驶」——哪怕司机正在玩手机。这是最危险的一种攻击，因为精度指标完全看不出异常。

原因：恶意客户端在本地训练时混入「毒样本」——把戴墨镜玩手机的照片标签改成正常驾驶，同时把墨镜上某几个像素patch改成一个特定模式（常见做法是给图片角落加一个固定的小白点）。本地训练几轮后，模型把「角落有小白点+戴墨镜」这个组合学成了正常驾驶的免死金牌，上传的恶意权重通过FedAvg污染了全局模型。

解决：服务端不能盲目相信客户端上传的权重。基础方案是异常检测——观察每个客户端权重的L2范数相对于历史均值的偏差，偏差超过3个标准差就丢弃该客户端本轮更新。更稳的方案是采用差分隐私梯度：客户端在上传前给梯度加高斯噪声，让恶意注入的信息无法精确传递。代价是模型精度会掉1-2个点，但在合规敏感的车载场景里值得。做实验时建议故意植入一个恶意客户端验证检测逻辑是否生效，别等到真被攻击了才第一次测异常检测代码。

6. 联邦学习分心驾驶检测的进阶验证：可视化注意力区域与跨客户端泛化测试

分心驾驶检测的联邦模型做好之后，验证工作比训练更考验工程功底。三个模型都跑完100轮通信后，我把EMNIST手写数字识别那套「精度至上」的思路抛弃了，改用三类验证手段：类别混淆分析、模型可解释性可视化、以及跨客户端泛化测试。最后一个最反直觉——在联邦学习里，你用A组司机的数据参与训练，但真正要服务的是B组从未参与训练的司机。所以光看全局测试集精度是不够的，要把B组司机的数据单独留出来做「冷启动测试」。具体操作是从driver_imgs_list.csv里随机抽出20%的司机，这些司机一张图都不进联邦训练，只出现在最终的测试集里。对三份模型分别算冷启动测试的macro-F1，如果哪个模型的分数明显低于它在全局测试集上的表现，说明它记住的是参与训练的司机特征而非驾驶行为本身——这种现象叫客户端记忆效应，是分心驾驶联邦模型最隐蔽的泛化陷阱。

第二个进阶验证是类激活图（CAM）。三个模型虽然做同样的分类任务，但关注区域完全不同——我常用torchcam库快速生成热力图。VGG19在判断「打电话」时关注的是手和耳朵的接触位置，EfficientNet更关注手机屏幕的亮光区域，ResNet50则会同时关注方向盘和脸的朝向。这个差异不是玄学，而是网络结构设计导致的信息提取偏好：VGG19的密集小卷积核擅长捕捉局部细节，EfficientNet的深度可分离卷积让注意力分布更广，ResNet50的残差连接让中低层特征得以保留到深层。理解这个差异能帮你做模型选型决策——你的车队摄像头装在挡风玻璃正中，司机的右手动作是判断手机使用的主要线索，那VGG19或ResNet50可能比EfficientNet更适合；如果摄像头装在A柱附近，需要捕捉更大范围的头部移动，EfficientNet的全局注意力优势就体现出来了。

最后一个建议是搭建一个简单的联邦训练可视化脚本，记录每轮通信的全局模型在验证集上的loss曲线，同时画出三个模型在同一个Non-IID划分下的收敛对比。一条经验是：三个模型在IID划分下精度差距往往在2-3个点以内，但到了Non-IID划分下差距会拉大到5-8个点——这说明模型在联邦场景下的优劣排序和集中式训练完全不同。所以选主模型时别参考任何ImageNet排行榜，用你的Non-IID数据跑三遍实验比什么论文都管用。

这套联邦学习框架跑通后，价值不止在分心驾驶检测本身。三骨干网络对比、FedAvg聚合、BN校准、异常客户端剔除这几个模块，可以平移到疲劳驾驶检测、酒驾行为识别甚至车内儿童遗留检测——车载边缘算力场景的数据隐私约束是通用的，换的只是数据集和分类头。在我的项目中，这套代码后来被复用到车队驾驶行为分析平台，唯一改动的只是数据加载路径和类别数。希望帮到你。

本文还有配套的精品资源，点击获取