前阵子和一家银行风控团队聊联合建模对方问了个很实际的问题我们两家机构客户重叠度不高、特征各有各的样本真用联邦学习能做出比各自本地模型更好的效果吗这个问题我过去一年被问过很多次。恰好杨强老师在IJCAI上的报告主题就是联邦学习的最新发展和应用里面有几个判断和案例基本把我遇到过的疑问都覆盖了。这篇文章我想把联邦学习当下的真实状态写一写——它到底解决什么问题、技术上走到哪一步、落地时哪些地方特别容易想当然——给正在评估或已经在做联邦项目的团队一个参照。1. 联邦学习为什么在这个时间点被推上前台1.1 合规收紧和数据孤岛模型开始吃不饱过去几年AI落地最顺畅的路径是把各方数据汇聚到一个地方然后集中训练。这个模式在业务上很好用但现在越来越难走。数据安全和个人信息保护的监管环境持续收紧金融、医疗这类数据富矿机构对原始数据出库的管理极其严格数据要离开自己的机房做联合建模合规评审这一关就很难过。加上商业层面的考量没有哪家机构愿意把自己最有价值的数据资产无偿交给合作方哪怕是联合建模过程中让对方看到了原始字段分布都有人觉得是被抄家。这就形成了一个很拧巴的局面算法越来越依赖大数据而数据流动的通道反而在变窄。单靠一家机构的数据模型很快就碰到天花板——银行看得到用户的还款行为但看不到他在电商平台的消费偏好医院积累了影像数据但没有患者在其他医院的用药记录。数据孤岛是物理存在的不是观念问题。联邦学习的核心主张是数据不动模型动原始数据留在各自的机构内通过交换模型参数或梯度来完成联合建模。这一设计同时回应了监管约束和商业利益两个问题所以这几年才会从一个小众研究方向变成产业界的标配选项之一。杨强老师在这次IJCAI报告里反复强调的也是这个判断数据合规和隐私保护不是联邦学习的阻碍反而是它被大规模采用的最大推动力。1.2 横向、纵向、联邦迁移三种模式的适用边界很多团队一听联邦学习就直接开始写代码但第一步其实应该先搞清楚自己属于哪种联邦模式。按数据分布方式联邦学习分三类适用的业务场景完全不同。表格对比更直观模式数据分布特征典型场景核心挑战横向联邦各机构样本ID不同特征空间重叠不同银行之间的信用卡反欺诈客户不同、字段相近样本量小的一方参与度低Non-IID分布导致全局模型震荡纵向联邦各机构样本ID重叠多特征互补同批用户银行出还款特征、电商出消费特征做联合授信ID对齐的安全性问题特征拼接后的通信开销联邦迁移学习样本和特征重叠都少国内信贷模型迁移到海外新市场冷启动标签对齐迁移有效性验证选模式不是拍脑袋得先做数据字典比对和ID对齐率统计。我见过不少项目数据方觉得反正都是联邦学习框架支持就行结果跑起来才发现自己的ID对齐率不到20%纵向联邦根本做不了只能退回横向方案。这个事情往前推一步做准了后面能省大量返工时间。2. 数据不动模型动核心链路与第一个隐藏坑2.1 FedAvg的完整工作链路联邦学习最经典的基线算法是FedAvg联邦平均理解它也就理解了联邦学习的基本运行方式。整个流程可以拆成四步服务端初始化一个全局模型把初始参数下发到参与训练的客户端。每个客户端用自己的本地数据在本地设备或服务器上跑若干轮梯度下降得到一组本地更新后的参数。客户端把更新后的参数或梯度加密后上传给服务端而不是上传任何原始数据。服务端按每个客户端的样本量加权平均所有上传的参数更新全局模型然后进入下一轮。核心逻辑用一段伪代码可以写得很清楚# FedAvg伪代码仅表达核心逻辑 def fed_avg(global_model, clients, rounds, local_epochs): for r in range(rounds): # 每轮按参与率采样客户端 sampled random.sample(clients, kparticipation_rate * len(clients)) local_weights [] for c in sampled: # 客户端在本地数据上做多轮SGD不共享原始数据 w local_train( global_model, c.local_dataset, epochslocal_epochs ) local_weights.append(w) # 按样本量加权平均各客户端参数更新全局模型 global_model weighted_average(local_weights, sample_sizes) return global_model这里有个容易忽略的点为什么加权平均是按样本量而不是简单平均因为不同机构的数据规模差异可能非常大一家银行可能有100万样本另一家只有8万如果简单平均小机构的影响会被稀释到几乎没有意义。按样本量加权让大客户端的贡献更突出但也带来一个副作用——小客户端的数据特征容易被淹没这一点后面讲灾难性遗忘时还会再提。关于隐私保护层级公开资料里常说要上同态加密、安全多方计算这没错但真实工程里往往要分层处理。我的习惯是梯度传输阶段默认做安全聚合Secure Aggregation用秘密分享或掩码的方式让服务端只能得到聚合后的结果看不到单个客户端的梯度。模型效果阶段如果业务场景要求更高会叠加差分隐私在梯度和参数更新中加入适量噪声进一步阻止反向推理。原始数据交互阶段几乎不用全同态加密做端到端训练成本太高工业界很难承受。2.2 Non-IID数据参数平均为什么会让模型跑偏FedAvg的假设前提是各个客户端本地数据近似独立同分布但现实世界几乎不存在这种情况。每家机构的用户群体、业务重心、数据采集口径都不一样数据分布差异大到离谱的情况很常见。我打个比方同一门课A班老师的教学重点是函数B班老师天天练几何C班侧重概率。期末考试前让三个班的老师把各自的正课提纲交上来平均出一份综合提纲结果大概率是哪个班都不满意——函数深度不够几何讲得不透概率更是只剩标题。联邦学习里的参数平均就是这个效果。这种Non-IID问题在工程上的典型表现是全局模型收敛速度变慢训练曲线震荡剧烈甚至精度比任何一个本地模型都差。我在一个真实项目里遇到过3家数据分布差异明显的机构做联合模型FedAvg跑到第30轮就开始在高位来回抖50轮后有个客户端本地模型反而把全局模型甩开了3个点。最后只能换策略在目标函数里加近端项限制本地更新不要偏离全局模型太远——这就是FedProx的思路还有FedNova这类把不同客户端本地训练步数折算到统一刻度的做法。如果你们的训练曲线开始大幅震荡优先排查数据分布差异不要急着调超参数。2.3 通信与算力的现实权衡联邦学习和中心化训练最大的不同之一是通信成本和设备算力不再是免费午餐。每轮训练里服务端要广播模型参数客户端要回传更新一次训练几十上百轮对带宽和稳定性都提出要求。实际操作中我建议拿三个旋钮做控制客户端参与率、本地训练epoch数、通信频率。三者的变化会直接影响收敛速度和最终精度必须做小规模模拟来标定而不是照搬框架默认参数。比如在10个模拟客户端上先固定参与率0.4把本地epoch从1调到5对比收敛曲线。带宽紧张的环境下还可以对梯度做量化8位代替16位、稀疏化只传top-k梯度甚至低秩分解来压缩通信量。我自己在医疗客户的驻场项目里遇到过十几Mbps的内网通信压缩不是优化项是必需项。3. 灾难性遗忘比通信效率更值得关注的联邦老问题3.1 灾难性遗忘在联邦场景下的两种表现灾难性遗忘本来是深度学习里研究了很多年的经典问题模型在学了新任务之后会把旧任务的能力忘掉。但在联邦学习里这件事的形态发生了变化理解不到位容易踩大坑。第一种表现是任务增量型遗忘。某个客户的业务更新了本地数据里新增了新的类别或新的用户行为模式本地SGD会自然而然把模型权重推向新任务的方向。问题在于这个客户端只看到了自己的新数据并不知道其他客户端的旧数据长什么样本地更新完成后上传到服务端全局模型被平均了一下结果可能是旧任务和新任务都做不好。我在做跨机构的风控模型时遇过类似的一家机构新增了反欺诈策略本地数据里出现了大量新型欺诈样本模型在新诈骗样本上的识别率提升了但全局模型在另外两家机构上的逾期预测准确率反而掉了。第二种表现是分布漂移型遗忘。当参与训练的客户端集合随时间变化比如有新机构加入、有老机构退出或者某个客户端的用户结构发生变化全局模型在适应新分布的过程中会把过去分布上学到的知识逐渐冲淡。这比中心化训练里的遗忘更隐蔽因为它不是你主动切换任务而是数据环境被动变化等到发现时往往已经忘得差不多了。3.2 为什么联邦场景比中心化训练更容易遗忘稀有知识中心化训练里只要数据分布稳定全局损失函数能把各个方向的知识都约束住。联邦学习的问题在于每个客户端都只能看到自己的局部数据一些只在少数客户端里出现的稀有知识——比如罕见病样本、少数高净值客户的行为画像——在参数平均的过程中贡献很容易被多数客户端的参数覆盖掉。打个比方多所学校联合排名某所学校有一门特别强的特色课程但只要全校总分排名这门课的优势几乎体现不出来。联邦参数平均就是这么干的它天然倾向于平均化和抹平差异那些稀疏却珍贵的知识在没有专门机制保护的情况下就是会被平均掉。这个过程在每一轮训练里都在发生累积几十轮之后稀有知识在全局模型里的痕迹会淡到几乎不存在。3.3 我实测有效的三条缓解路径EWC、知识蒸馏和个性化层针对灾难性遗忘学术界和工程界提出了好几种思路我在项目里实际验证过三条效果比较明确。第一条是EWC弹性权重巩固。核心思想是在计算损失函数时对每个参数加一个重要性权重重要参数在后续更新中不允许被推得太远不重要的参数则可以自由调整。联邦场景下每个客户端可以基于自己的本地数据计算Fisher信息矩阵告诉服务端我刚才这个参数有多重要然后和梯度一起上报。加了这个约束之后全局模型在吸收新任务的同时对旧任务的记忆保留程度明显提高。这个方案的代价是计算量变大每个客户端都要额外做一次Fisher矩阵估计但相比收益我认为值得。第二条是知识蒸馏。在联邦训练里引入一个服务端维护的教师模型或旧任务输出分布客户端在本地更新时不只是拟合自己的标签还要尽量让本地模型对公共数据或旧任务参考样本的输出分布和更新前的全局模型保持一致。蒸馏的作用是软约束它不强制参数位置而是约束行为输出对抗遗忘的效果比较柔和适合那些参数空间本身已经支离破碎的场景。第三条是拆个性化层。把模型结构拆成共享表示层本地个性化头部底层共享几层通用的特征抽取结构跨机构学习公共表示顶层分类器或预测头则留在本地每个客户端维护自己的一套头部参数。灾难性遗忘最明显的其实是本地头部——你换了业务分类逻辑变了旧头部就会被推翻。头部留在本地后即使出现遗忘也只需要用少量旧数据做一步本地微调就能把旧业务的能力拉回来成本极低。我在一个实际项目中把三条路径组合起来用全局模型加EWC正则做增量学习服务端加一层软蒸馏约束客户端头部本地化。实测旧任务精度从掉近10个百分点缩到两个点左右。不能说完全消除遗忘但对业务容忍度来说已经好很多了。如果你要按优先级排我的建议是先做个性化层拆分投入最小、见效最快然后视情况加EWC蒸馏最后作为补充因为它的调参成本相对高。4. IJCAI视角下的最新方向个性化、异步训练与联邦大模型4.1 个性化联邦学习不再用一套参数适配所有客户端传统联邦学习的目标是压缩出一个全局模型但这里面有个隐含假设所有客户端都希望得到同一个模型。现实中这个假设经常不成立。银行A主要做小微企业贷银行B主做消费贷用户结构完全不同用一个全局模型适配两家效果一定不是最优解。个性化联邦学习的方向就是承认客户之间的差异不再追求一个模型包打天下。具体做法分几个流派一类是在训练时引入多任务学习框架把每个客户端当成一个任务模型内部做参数共享与任务分离另一类是用元学习初始化先在所有客户端上学习一个适合被快速微调的初始模型再交到各客户端手里用本地数据做少量适配还有一类就是上面提到的共享网络个性化头部结构工程实现最简单。这个方向在风控场景里特别有现实意义。我和合作伙伴联合建模时应用层永远还是各家在本地跑各自的后院模型全局模型只是一层底座。个性化联邦学习让底座和各自的头上模型可以互相配合而不是互相踩踏。杨强老师在报告里也用较大篇幅讲了从全局统一模型到个性化联邦的演进逻辑我理解这是他判断联邦学习价值升级的关键转折点。4.2 异步联邦与通信压缩解决掉队节点拖慢全局的问题联邦学习同步联邦版本有一个明显瓶颈每轮训练要等最慢的客户端完成。移动端场景尤其明显手机算力参差不齐、网络状况时好时坏一个差节点就能拖住整个训练进度。异步联邦学习的思路是允许客户端在不同时间点提交更新服务端用版本号机制控制过期更新的影响——更新太旧的参数会给予较低权重防止它干扰最新的全局状态。这个机制带来的问题是收敛分析更复杂训练过程也更难稳定。我在一个工控场景的联邦训练里试过异步方案收敛速度确实快了不少但模型的最终精度波动比同步版本大需要额外增加验证集监控随时准备回滚。所以异步联邦适合那些对实时性敏感、容忍一定精度波动的场景如果业务对稳定性格外敏感同步方案更稳妥。通信压缩方面梯度量化和低秩因子化是我见过用得最多的手段。把32位浮点梯度压到8位再上传通信量直接降四分之三精度损失在很多场景下可以控制在合理范围内。配合模型结构里的深度可分离卷积或低秩适配器通信压缩还有进一步的优化空间。4.3 联邦大模型的苗头LoRA微调与参数保护大模型LLM和联邦学习的结合是这一两年最受关注的方向之一。直接把完整的大模型参数放客户端去全量训练通信成本和算力负担都极其夸张所以工业界走的是参数高效微调的路子客户端在本地冻结基座模型只更新LoRA这种低秩适配器的参数服务端聚合的也是这些小参数模块。这带来的好处很明显通信量表减少了几个数量级基座大模型始终留在本地不出域避免了大模型权重被合规审查盯上的尴尬而应用层又可以针对各机构的不同场景做个性化适配。目前这个方向大部分还停留在实验和论文层面但已经有一些机构在用企业内部私有数据做联邦微调测试目的是让大模型学到企业间不敢共享的行业知识。我对这个方向的判断是它会成为联邦学习一个极其重要的增长引擎但短期别想替代中心化的大模型训练范式。大模型全量联邦训练涉及的技术挑战还很多通信、隐私、算力分配都还远没到标准化程度。如果团队考虑跟这个方向建议先在私有数据、小参数规模上做验证把链路跑通再考虑扩大规模。5. 落地联邦学习项目前先想清楚这四件事5.1 收益判断清单隐私保护到底带来了什么做联邦学习项目之前我强烈建议团队先回答四个问题不要急着选框架。第一个问题你的业务真的需要多方数据吗有些项目单方数据就已经能把效果做到可接受水平硬要上联邦学习纯粹是给自己的工程复杂度加戏。先做一把离线AB测本地模型跑一遍看看瓶颈在哪里如果瓶颈不是数据量而是特征质量那联邦也不一定救得了你。第二个问题隐私保护需求是真实存在的吗是因为监管审计要求还是商业谈判需要这直接决定你要在隐私保护技术上投入多少成本。监管驱动的场景通常需要可审计、可追溯像同态加密和安全计算这类重型黑盒不一定过审商业谈判驱动的话安全聚合加差分隐私通常就够用了。第三个问题数据对齐率到底有多少横向联邦看样本重叠和特征空间纵向联邦看ID对齐率。我对团队的要求是任何纵向联邦项目的ID对齐率如果低于30%就重新评估可行性。数据对齐这部分工作应该在选型前完成不是选型后。第四个问题你能接受多少精度损失联邦模型和中心化理想模型之间天然有差距这个差距在没有仔细调优时可能相当大。项目启动前一定要把精度掉几个点的预期统一到所有人心里否则等到验收阶段再发现扯皮会很痛苦。5.2 三个容易踩的工程坑第一坑一上来就追求全量参与、全量数据。你刚把框架部署起来就想所有客户端每轮都跑、所有数据都参与训练这不是效率问题是灾难。我见过多个团队在模拟阶段跑得很好一上真实环境就崩——真实客户端不稳定掉线、数据质量差、算力不足各种问题一起来。正确的做法是先用小规模子集做端到端验证稳了再扩。第二坑忽略客户端算力差异。这一点在跨机构场景尤其常见。一个合作机构可能只有几台旧服务器运行你的模型时本地训练一轮要十几分钟直接拖垮整轮训练。项目设计时要提前收集各参与方的硬件清单然后决定是否需要剪枝、量化或更轻量的模型结构。第三坑安全与性能失衡。有两种极端要么完全不做隐私保护梯度裸奔不说监管层面单是商业谈判就会崩要么过度堆砌加密技术训练慢到没法用。正确思路是从威胁模型出发——谁可能攻击、攻击什么数据、攻击成本多高——再决定用哪一档安全方案不搞配置拉满。5.3 我的验收基线与数据退化曲线联邦学习项目的验收不能只看模型上线跑起来了这个结果要看更具体的指标。我做项目时会给团队画一条数据退化曲线把联邦模型、单方本地模型、理想中心化模型三个指标放在同一张图里比较。如果联邦模型只比本地模型高一点点项目价值存疑如果能明显逼近中心化上限说明联邦聚合机制起效数据联合是有真实增益的。训练过程中要盯住的三个数字通信量级每轮上传参数体积X客户端数、单轮训练耗时、以及全局模型在验证集上的精度变化曲线。这三个数字一旦有任何一个严重偏离预期优先定位的是数据分布和客户端状态而不是模型结构。跑完验证轮次再回到第一个问题重新审视——这个项目的收益真的来自于多方数据联合吗如果来自那前面的准备就没白费。最后说点个人体会。联邦学习从论文热词变成真实项目背后确实有杨强老师和FATE这类开源工具一路推动把门槛降了不少。但我见过太多团队把框架跑通demo就以为能上线结果被数据对齐、安全审计、Non-IID这些问题当头一棒。我的经验是别把它当算法题要当工程题来做——先把数据的真实分布摸清楚再决定用横向还是纵向然后才轮到调聚合算法。正在评估这类项目的团队我的建议很简单先用小规模真实数据跑一轮端到端记录精度、通信量、训练时间三个数字再决定要不要往下投。数据不会骗人跑完一轮心里就有底了。