把联邦入侵检测落到代码里：读 FIDSUS 的客户端、原型与全局分类头

先说清楚这篇文章讨论什么

无人机群的入侵检测面对的不是一台配置固定、数据分布稳定的服务器。不同节点可能采集到不同流量，在线状态和通信质量也会变化；如果把各端数据直接汇总到一个中心，隐私、带宽和管理边界都要重新考虑。联邦学习提供了分散训练的组织方式，但它本身不会自动解决客户端异构、类别不均衡和节点掉线。

我这次依据公开仓库和代码梳理 FIDSUS 的实现结构，重点放在客户端如何保留本地适配、服务端如何利用类别原型和全局分类头。这里是源码阅读，不是本轮重跑论文实验，也不代表已经在真实无人机集群上部署验证。

项目标识：daodeqing/UAV（GitHub）。README 将 FIDSUS 介绍为面向无人机群的联邦入侵检测方法，论文题目为 FIDSUS: Federated Intrusion Detection for Securing UAV Swarms。仓库还包含 HGFIDSUS、SGEFIDSUS 和 SkyGuardPFIDS 等扩展实现，阅读时最好先分清主方法与后续方案，避免把不同算法的设计拼成一个流程。

先从目录找到一轮训练的入口

核心实现主要分布在两个文件：客户端逻辑位于 system/flcore/clients/clientFIDSUS.py，服务端逻辑位于 system/flcore/servers/FIDSUS.py。README 中列出的服务端文件名与当前目录树里的实际文件名有大小写差异，Linux 等区分大小写的环境中，按真实仓库路径核对会更稳妥。

从服务端的训练循环看，一轮大致由这些步骤组成：选取参与客户端、下发模型、在评估轮检查个性化模型、客户端本地训练、服务端接收客户端结果、训练服务端分类头，再把全局分类头同步回客户端。它把“客户端本地更新”和“服务端头部训练”分开，因此读代码时不能只盯着常见的模型参数平均步骤，还要看每轮结束后分类头如何更新、如何回传。

客户端保留个性化模型用于本地训练和评估。对无人机群这类数据异构场景，这个安排有一个实际意义：共享知识不必等于所有节点最后使用完全相同的决策边界。评估时，代码也会分别运行客户端模型并汇总指标；这比只报告一个全局模型分数更接近“不同节点的效果是否都可用”这个问题。

类别原型：让跨端信息带上类别语义

仓库中的原型处理可以分成两步理解。第一步是在类别维度组织特征原型；同一类别收到多个原型时，聚合函数会计算它们的平均表示。第二步是对当前轮原型和历史个性化原型做混合：代码先归一化两边的向量，再根据两者距离计算混合权重，并把权重限制在一个区间内，避免权重因为单轮波动变得过于极端。

这类设计的关注点不是“把所有客户端数据合并”，而是让服务端在不直接集中原始样本的前提下，获得按类别组织的表示信息。历史原型参与混合，也让类别中心不会只由某一个瞬间的更新决定。对于客户端样本量不同、某些类别在部分节点缺失的情况，复现时仍需要逐项核对：缺失类别如何处理、客户端上传原型是否经过同样的归一化、聚合是否按客户端等权，以及不同数据划分下原型数量如何变化。

这里也要留出审查空间：原型是特征摘要，不等于天然没有隐私风险；它的稳定性也不能仅凭公式判断。若要把方法扩展到更强的隐私威胁模型，需要进一步说明原型可能泄露什么、攻击者能观察到什么，以及差分隐私或安全聚合等机制是否改变算法效果。

全局分类头与类别不均衡

服务端 FIDSUS.py 中还实现了 LogitAdjustedCE。它维护类别计数的指数移动平均，根据当前估计的类别先验构造对数调整项，再将调整项用于分类损失。它试图把类别分布信息显式带入分类头训练，而不是只看总体准确率。

这会带来一个重要的评估提醒：如果入侵类别分布不均衡，总体 Accuracy 可能掩盖少数类漏检。服务端代码中记录了 Macro F1、Weighted F1、Macro Recall、Balanced Accuracy、Macro AUC 和 Macro PR-AUC 等指标。实际比较时，至少要把宏平均指标、少数类召回和混淆矩阵一起看，并在所有方法上使用一致的测试集与类别定义。某个损失函数的设计动机不能替代结果验证。

怎样复现，先把数据协议对齐

README 指出实验数据包括 NSL-KDD 与 UNSW-NB15，并说明 UNSW-NB15 已按 Dirichlet 分布划分为 50 个子集。这个“怎么切分数据”会直接影响非独立同分布程度，因此复现时要记录数据版本、标签映射、随机种子、客户端数量、参与比例和每个客户端的样本数；仅仅使用同名数据集，并不能保证实验协议相同。

仓库提供 env.yaml 和运行脚本。README 给出的基本路径是先按环境文件创建 Conda 环境，再进入 system 目录运行项目脚本；具体算法参数应以当前 system/main.py 的参数解析和仓库示例为准。README 还描述了把 T-ITS CSV 转成项目所需 NPZ 格式的流程。迁移新数据时，建议先单独验证特征列、标签列、类别编号和客户端划分，再启动联邦训练，否则数据预处理差异很容易被误当成算法收益。

一个可复查的实验记录至少应该保存：代码提交版本、配置文件、数据划分文件或其哈希、随机种子、每轮参与客户端、训练和评估日志、最终逐类指标。若比较 FIDSUS 与其他联邦基线，还要保持相同的数据切分和参与策略，并报告多个随机种子；单次运行的最好结果不足以说明方法稳定。

README 中的结果数字该怎样读

项目 README 提到，论文在大规模场景下相对既有联邦学习方法取得了平均准确率提升，给出的范围为 4% 到 34%。这个数字应当理解为 README 对论文实验的概述。要判断它适用于自己的数据和部署条件，还需要回到论文中的具体数据集、基线、规模定义、指标口径和实验设置；本文没有独立复现这组结果，所以不把它当成本次验证结论。

同样，NSL-KDD 或 UNSW-NB15 上的客户端模拟，也不能直接证明系统已经经受真实飞行环境验证。真实无人机还涉及无线链路抖动、能源限制、节点移动、时钟与传感器差异、在线更新安全和故障恢复。把论文方法用于实际集群之前，还需要补充硬件在环或实地试验、通信中断策略、模型更新认证和可解释的误报漏报分析。

我从这份代码里得到的三个工程提醒

第一，联邦学习实验的关键不只在模型结构，也在数据如何切分、客户端如何抽样、每轮如何通信。把这些协议写清楚，结果才有可比较性。

第二，个性化模型、类别原型和全局分类头分别承担不同作用。读代码时按“谁产生、谁聚合、谁消费”追踪数据，比只看算法名或论文图更容易发现实现与描述之间的偏差。

第三，论文报告、仓库代码和真实部署是三个不同的证据层级。README 中的实验结论可以作为复现线索，代码结构可以说明实现意图，但只有按明确协议跑出的日志和真实环境测试，才能支持更强的性能或部署结论。

参考代码

• 项目 README：README.md
• FIDSUS 客户端：system/flcore/clients/clientFIDSUS.py
• FIDSUS 服务端：system/flcore/servers/FIDSUS.py
• 数据集与运行脚本：dataset/

如果你正在读联邦入侵检测代码，可以先从一轮训练循环开始，顺着模型、原型和指标的数据流往返追踪，再回到论文核对定义。这样更容易把“方法想解决什么”和“代码实际上做了什么”对应起来。