第28章：联邦学习与隐私保护技术¶
本章摘要¶
在上一章中，我们探讨了数据合规框架与治理，明确了“合规左移”和 Privacy by Design（隐私保护设计）的工程重要性，并建立了基于 RoPA、DPIA 以及分类分级的制度基线。然而，面对高度敏感的数据（C3级）或跨机构的数据孤岛，仅靠制度上的“数据可用不可见”或传统的访问控制与脱敏，往往无法彻底阻断数据泄露的物理风险。随着机器学习系统特别是大模型系统不断深入业务核心流程，数据暴露不再只发生在数据库导出、报表展示或人工查询等传统环节，而是开始出现在特征构建、参数训练、联合建模与推理调用之中。
本章将视角从“制度与流程治理”进一步推进到“训练、协作与推理阶段的技术治理”，系统性地介绍联邦学习（Federated Learning, FL）与隐私增强技术（Privacy Enhancing Technologies, PETs）。我们不仅讨论这些技术“是什么”，还重点分析它们为什么必须进入架构设计前期，以及在真实工程系统中如何进行组合、验证与治理。换言之，本章关注的不是概念层面的“技术名词表”，而是一个现实问题：当数据不能自由流动时，组织应该怎样重新设计协作训练系统。
本章首先解释为什么事后加密、事后脱敏在机器学习尤其是大模型场景中经常不够，进一步揭示数据可用性与隐私保护之间的结构性矛盾。随后，我们将构建完整的技术全景图，对比联邦学习、差分隐私（DP）、安全多方计算（MPC）、可信执行环境（TEE）与同态加密（HE）的保护对象、适用阶段、系统代价与组合边界。在此基础上，本章会进一步展开工程落地的关键问题：如何评估精度损失、通信开销与时延增加，如何设计联邦训练系统的组件与控制流，如何理解横向联邦、纵向联邦与联邦微调的适用前提，以及如何通过成员推断、梯度反演、模型投毒与后门测试来验证隐私系统的真实性能。
最后，本章将结合医疗与金融两个跨主体协作案例，并与 P09 隐私保护流水线、Ch27 合规治理框架及 Ch22 多模态视觉检索能力串联，展示隐私保护技术如何在复杂 AI 系统中形成“治理—训练—验证—审计”的闭环。P09 的重点是通过分类、权限、脱敏、隔离、审计、预检和事故复盘形成一条前置治理链路，而本章讨论的是在前置治理完成后，面对跨主体建模时如何继续保证训练阶段与模型阶段的隐私边界。
学习目标（Learning Objectives）¶
通过本章学习，读者应能够：
- 理解为什么隐私保护不能仅停留在制度治理与字段脱敏层，而必须前置进入机器学习系统与模型训练架构。
- 掌握五类核心隐私保护技术（FL、DP、MPC、TEE、HE）的基本原理、保护对象、适用阶段与主要代价。
- 区分横向联邦、纵向联邦与联邦微调三类实施模式，并理解它们在数据分布与协作关系上的前提差异。
- 理解联邦学习中的主要攻击面，包括成员推断、梯度反演、模型投毒和后门攻击。
- 建立隐私技术选型能力，能够在准确率、时延、带宽、可解释性与合规压力之间做工程权衡。
- 掌握隐私增强系统的验证思路，理解为什么“引入了隐私技术”不等于“真正通过了隐私验证”。
- 理解本章技术如何与 P09 隐私保护数据流水线、Ch27 合规治理体系以及 Ch22 多模态检索架构协同工作。
场景引入¶
两家头部三甲医院（A院和B院）与一家顶级 AI 研究机构（C机构）计划联合训练一个罕见病多模态辅助诊断大模型。A院拥有海量高价值的临床文本病历，B院拥有对应的医学影像与基因测序数据。三方都相信这项合作具有明显的社会价值：单一医院看到的病例规模有限，而罕见病样本天然稀缺，若不能跨机构形成联合样本空间，模型的泛化能力很难提升。
然而，项目在立项初期的 DPIA（数据保护影响评估）阶段就被法务和安全部门双双叫停。理由非常明确。第一，这些数据属于医疗健康类的 C3 高敏感数据，绝对不允许离开医院内网。第二，即使 A 院和 B 院在本地去除了患者姓名、身份证号等直接标识符，研究机构 C 若将多模态特征进行联合编码，依然可能通过视觉实体与文本实体的对齐关系，遭遇成员推断或特征反演攻击，反向还原出患者身份。第三，在跨机构协作中，任何一方都不愿承担“集中汇聚原始数据”所带来的制度责任与技术风险。
面对“数据孤岛”与“强合规监管”的双重夹击，传统的“把数据汇总到一个数据湖集中训练”的范式彻底失效。团队必须寻找一种能在不共享原始数据的前提下，实现模型联合优化的架构方案。这正是联邦学习与隐私增强技术出现的现实背景：数据不再自由流动，协作必须通过协议、算法与系统边界来重新组织。
图28-1：跨机构医疗数据协作中的隐私与合规冲突示意图
28.1 为什么隐私保护要前置进入架构设计¶
正如我们在 Ch27 中强调的，合规成本会随着项目生命周期的推进而快速上升，因此必须坚持“合规左移”。在底层技术实现上，隐私保护同样遵循这一铁律。对 AI 系统而言，越晚考虑隐私，越容易在数据接入、特征工程、训练流程和推理接口中留下不可逆的结构性缺陷。很多团队在项目初期只关注模型效果和训练吞吐，把隐私问题视为“模型跑通以后再补”的次要事项，结果往往是在进入验收、上线或合规审查阶段后，才发现系统架构本身已经无法满足监管要求。
这种问题在传统业务系统中尚可通过加字段权限、补日志、加审批或补脱敏来部分缓解，但在机器学习系统中，风险一旦进入训练过程，就很难通过后置手段完全消除。原因在于，模型本身会把训练数据中的统计规律、长尾样本特征甚至个别极端信息压缩进参数空间中。也就是说，数据暴露不再只是一份表被谁导出的问题，而变成了模型是否已经把不该记住的东西学进去了的问题。
28.1.1 事后加密和事后脱敏为何往往不够¶
传统安全思维强调数据库加密、传输加密和前端展示脱敏。这些措施在传统业务系统中当然重要，但在机器学习尤其是大模型场景中并不足够。
首先是模型的记忆效应。深度模型尤其是参数规模较大的模型，往往会对训练集中的长尾样本产生记忆。若某些训练样本本身高度敏感、重复出现频率较低且形式独特，模型可能在参数中保留足够多的信息，导致攻击者通过 prompt、API 探测或对输出进行有针对性的采样，间接恢复训练样本中的隐私片段。
其次是高维特征的可逆问题。很多团队以为“去掉姓名、手机号、身份证号”就意味着安全，但这只是移除了直接标识符。对于图像 embedding、文本向量、多模态对齐特征、梯度信息或中间表征而言，攻击者依然可能通过反演方法重建部分原始内容。也就是说，表层字段脱敏并不自动等于模型层隐私安全。
第三是训练阶段比展示阶段更危险。在很多组织中，安全关注点仍然停留在“前端页面是否打码”“导出的表是否去掉手机号”，但真正高风险的，往往是训练阶段的数据加载、特征缓存、样本拼接、日志打印、中间结果存储与模型更新同步过程。模型上线前就已经泄露，并不一定要等到前端展示那一步才发生问题。
因此，隐私保护不能只是数据进入系统后的“表面遮挡”，而必须成为训练与协作机制本身的一部分。
28.1.2 数据可用性与隐私保护的结构性矛盾¶
隐私保护和数据可用性不是简单的对立关系，而是一种长期存在的结构性张力。如果系统追求极致隐私，最直接的方式是完全切断数据连接、极度限制查询或向训练与输出中注入大量噪声，但这会迅速损害模型的识别能力、回归性能和业务可用性。相反，如果系统追求极致可用，允许跨主体进行全量明文共享和无约束联合建模，模型效果也许更好，但合规风险和责任暴露面会同步放大。
架构设计的任务，不是消灭这种矛盾，而是在特定业务场景下找到“最小可用暴露面（Minimum Necessary Exposure Surface）”。所谓最小可用暴露面，就是在满足业务目标所需的前提下，把可见数据范围、可交换信息种类、可保存中间结果和可暴露模型能力压缩到最低。这个目标决定了隐私增强技术从来不是“有了更好，没有也行”的锦上添花，而是很多跨主体 AI 系统能否存在的前提条件。
图28-2：数据可用性与隐私保护的结构性矛盾示意图
28.1.3 工程系统中的“隐私预算”概念¶
差分隐私（DP）为这种权衡提供了工程上可量化的表达，即隐私预算。隐私预算通常用 \(\epsilon\) 表示，它并不是一笔财务意义上的预算，而是系统允许泄露风险的上界度量。一般来说，\(\epsilon\) 越小，保护越强，但准确率和可用性损失通常也越大；\(\epsilon\) 越大，噪声越小，模型更有用，但泄露风险也会显著提高。
在工程系统中，隐私预算不是一个抽象数学常量，而是一个必须纳入训练轮次、查询次数、实验频率与对外服务配额的治理变量。一个团队若只是会在论文中写出 epsilon，却没有机制去记录每次训练、每次评估、每次对外发布所消耗的预算，那么这个系统在实践中就没有真正管理隐私风险。换言之，预算管理能力本身，就是隐私系统的一部分。
28.1.4 从“数据安全”到“训练安全”的范式转移¶
在传统数据治理中，安全重点通常是“谁访问了数据库”“哪些字段被导出”“哪些报表被分享”。但在 AI 系统中，风险重心开始发生迁移。组织需要关心的，已经不仅是数据是否被看见，而是数据如何被表示、梯度如何被上传、参数如何被聚合、模型如何被调试、输出是否可能泄露训练样本，以及攻击者是否能通过与模型交互反推出原始个体信息。
这意味着安全目标从“守住数据库”转向“守住训练过程、协作边界与模型行为”。本章后续所有技术路线，包括 FL、DP、MPC、TEE 与 HE，实际上都服务于这一范式转移：当数据本身无法被自由移动时，系统就必须在训练协议、聚合逻辑与输出边界上重新建立安全性。
图28-3：从数据安全到训练安全的治理重心迁移图
28.2 技术路线全景¶
解决隐私计算问题，业界目前主要演化出五大技术流派。它们并不是互相排斥的，而是在保护对象、计算损耗和适用场景上各有侧重。理解这些技术的关键，不在于死记定义，而在于看清它们分别保护了什么、牺牲了什么，以及它们适合放在系统的哪个阶段。
图28-4：隐私增强技术全景矩阵图
28.2.1 核心技术解析与对比¶
| 技术流派 | 核心原理 | 保护对象 | 适用阶段 | 实现代价与主要瓶颈 |
|---|---|---|---|---|
| 联邦学习 (FL) | 数据不动模型动；各节点本地训练，仅交互梯度或参数。 | 原始训练数据不直接出域。 | 模型训练、微调 | 通信开销大；存在梯度泄露风险；对节点异构敏感。 |
| 差分隐私 (DP) | 在数据、梯度或输出中注入噪声，掩盖个体贡献。 | 保护个体是否参与训练或查询。 | 训练、统计发布、联邦聚合 | 精度受损；预算管理复杂；调参困难。 |
| 安全多方计算 (MPC) | 通过秘密分享等协议，让多方在不暴露输入的情况下完成联合计算。 | 输入数据与中间结果。 | 联合统计、联合求交、联合风控 | 通信轮次多，时延大；不适合大规模深度训练。 |
| 同态加密 (HE) | 对密文直接做运算，解密后得到与明文一致的结果。 | 计算过程中的数据内容。 | 安全推理、安全聚合 | 算力消耗极高；支持算子有限。 |
| 可信执行环境 (TEE) | 在硬件可信飞地中执行代码和处理数据。 | 运行时内存数据与关键逻辑。 | 安全聚合、敏感推理、密钥管理 | 依赖特定硬件；有侧信道风险；可信根外置于硬件厂商。 |
这五类技术可以粗略分成两组：一组更强调“数据不出域或不见明文”，如 FL、MPC、HE；另一组更强调“即使发生观察，也降低个体可识别性或运行时可见性”，如 DP、TEE。这样的划分有助于理解为什么它们经常不是替代关系，而是组合关系。
28.2.2 技术组合路线与场景选型原则¶
真实工程中，单一技术往往无法解决全部问题，因此更常见的是组合式路线。
最典型的是 FL + DP。联邦学习解决“原始数据不出域”，差分隐私解决“上传更新或模型输出仍可能暴露个体信息”。这种组合非常适合多方联合训练但又必须控制成员推断风险的场景。第二类典型组合是 FL + HE。客户端在本地训练后，把加密后的更新上传给中心端聚合，中心看不到明文梯度，从而降低中心侧的观察风险。第三类是 TEE + FL，把聚合逻辑放进可信执行环境，减少云侧或宿主系统窥探训练中间结果的可能性。对于金融名单求交、联合反欺诈等问题，常见组合是 MPC + PSI，其重点不是训练大模型，而是安全地完成多方集合运算与联合统计。
选型时应优先回答三个问题。第一，保护对象是谁，是原始数据、个体身份、运行时内存，还是计算结果本身。第二，攻击者是谁，是中心平台、合作机构、外部攻击者，还是具备模型查询能力的黑盒对手。第三，系统最不能承受的代价是什么，是精度下降、时延增加、带宽消耗，还是落地复杂度上升。只有把这三个问题说清楚，技术路线才有现实意义。
28.2.3 联邦学习（FL）深挖¶
联邦学习并不只是“把数据留在本地”这么简单，它本质上是一种重新组织训练控制权的机制。在传统集中式训练中，数据被拉到统一环境，训练者掌握所有样本；而在联邦训练中，训练逻辑必须接受一个事实：参与方的数据域彼此分离、网络状态不同、资源能力不同、信任假设也不同。模型要想学习，只能通过跨域同步参数或梯度，而不是跨域同步原始数据。
（1）基本训练闭环¶
典型联邦训练流程通常包括以下几个步骤。首先，中心协调器下发初始模型或当前轮的全局模型。随后，各参与节点在本地数据上训练若干步，生成本地参数更新或梯度更新。接着，各节点将这些更新发送给聚合器。聚合器执行平均、加权平均或更复杂的稳健聚合策略，得到新的全局模型，再将其下发到各节点，进入下一轮迭代。
这样的 round-based 训练流程看起来与分布式训练相似，但二者的核心差异在于：分布式训练假设训练节点由同一组织控制，且数据通常可以被视为整体切分；联邦学习则天然假设参与方相互独立、信任有限，且本地数据存在强业务差异。因此，联邦训练不是简单的“更慢的分布式训练”，而是一套有业务边界和治理约束的协作范式。
图28-5：联邦学习基本训练闭环
（2）FedAvg 与本地更新机制¶
联邦学习中最经典的算法是 FedAvg。其直觉非常简单：各客户端在本地训练若干步后，把模型参数更新上传，由中心端按照样本量或权重进行平均，再形成新的全局模型。FedAvg 之所以广泛应用，是因为它结构简单、易实现，并且在很多中等复杂度场景下具有不错的收敛表现。
但 FedAvg 同时暴露出联邦系统的一个典型权衡：若本地训练步数太少，通信轮次会很多，带宽与同步成本高；若本地训练步数太多，各客户端会朝着各自的局部数据分布方向走得更远，导致聚合后的模型偏移更严重，也就是常说的 client drift。工程上通常需要在本地 epoch 数、客户端参与比例、学习率和聚合频率之间做联合调节。
（3）非 IID 数据问题¶
联邦环境下，各节点数据通常并非独立同分布。不同机构的用户结构、设备来源、地区属性、标注口径和数据规模可能截然不同。这会导致全局模型收敛变慢、个别大节点主导训练方向、少数节点长期得不到收益，甚至出现全局模型在平均意义上可接受，但对关键参与方完全不好用的情况。
非 IID 问题决定了联邦训练不是“数据换个地方放”那么简单，而是带有强业务异构性的协作训练。对医疗、金融、政务等场景而言，这种异构性往往比算法本身更难处理，因为它来自机构本身的现实差异，而不是一个可以轻易被代码抹平的技术变量。
（4）联邦学习的真实边界¶
联邦学习的核心承诺是“原始数据原则上不出域”，但这并不等于“绝对隐私安全”。若上传的梯度、参数更新、训练日志或中间指标可被分析，攻击者仍然可能推断本地数据特征。因此，联邦学习通常是隐私系统的“基座”，而不是完整答案。只要系统仍然需要跨域交换某种可分析的信息，就必须继续考虑差分隐私、安全聚合、鲁棒聚合和审计策略。
28.2.4 差分隐私（DP）深挖¶
差分隐私的核心目标，不是把数据变成“完全看不见”，而是让单个样本是否参与系统，不会显著影响输出结果。换言之，攻击者即便掌握大量背景知识，也很难依据模型输出、统计结果或训练过程中的某些可见信号，判断某个个体是否出现在训练数据中。
（1）DP 的保护对象¶
DP 重点保护的是“个体贡献不可区分性”。它并不承诺业务结果一定保密，也不承诺系统完全没有泄露，而是给出一种概率意义上的保护：在存在或不存在某个个体样本的情况下，系统输出分布的差异被限制在可控范围内。这种保护尤其适合应对成员推断类风险，因为攻击者最常做的就是去判断“某个人是否在训练集中”。
（2）Local DP 与 Central DP¶
从部署位置看，差分隐私大致可分为 Local DP 和 Central DP。Local DP 要求每个用户或客户端在数据离开本地前就自行加噪，因此信任假设最弱，但由于噪声更早进入系统，精度损失通常更明显。Central DP 则是在中心侧统一加噪，模型质量通常更好，但前提是你必须相信中心能够正确执行预算管理与噪声注入。
在联邦场景中，两种方式都可能出现。若组织对中心端缺乏足够信任，会更偏向 Local DP；若组织能接受中心端承担更强的治理责任，则可能采用 Central DP，以换取更好的模型效果。
（3）训练中的 DP-SGD 思路¶
在模型训练中，差分隐私最常见的思路是 DP-SGD。其核心步骤通常包括：先对单样本梯度做裁剪，限制每个样本对整体更新的最大影响；再对聚合后的梯度注入特定分布的噪声；最后在训练过程中累计和记录隐私预算的消耗。这个流程体现了 DP 的工程本质：不是“随便往梯度里加点噪声”，而是先限制个体影响边界，再在这个可控边界上进行噪声注入，从而使风险度量具有可解释性。
图28-6：DP-SGD 训练流程示意图
（4）为什么 DP 难调¶
差分隐私最大的难点不在于“能不能加噪”，而在于“怎样在可用性、预算与稳定性之间找到可接受区间”。理论上很漂亮的参数组合，在真实业务中可能直接把模型打废。反过来，为了保住指标而把 epsilon 放得过大，又可能失去实际保护意义。因此，DP 项目经常卡在一个很现实的问题上：不是理论不成立，而是业务不能接受那样的精度损失。
28.2.5 安全多方计算（MPC）深挖¶
安全多方计算更适合结构相对清晰、计算规则明确、参与方数量有限的场景，例如联合求交、联合统计、联合风控评分等。它的核心价值在于：各方在不暴露自身原始输入的前提下，协同完成某种计算，并只得到允许可见的结果。
（1）秘密分享的直觉理解¶
MPC 的基本直觉可以理解为“把原始数据拆成多个看不懂的碎片，再让这些碎片参与联合运算”。任何单一参与方手中的碎片都不足以恢复原始数据，只有通过协议交互，最终才能得到目标输出。这种机制适合那些计算逻辑相对固定、参与方都希望严格控制输入暴露范围的场景。
（2）MPC 适合什么，不适合什么¶
MPC 特别适合做名单求交（PSI）、黑名单比对、联合统计和部分规则型联合建模，因为这些任务的函数结构相对清晰，且多方都更关心“能否安全算出结果”，而不是“能否高效训练一个巨大的深度模型”。但它并不适合参数量极大的深度神经网络训练，也不适合高频、低时延、参与节点很多的复杂在线场景。原因不是它不能做，而是通信轮次与计算开销往往会把工程可用性迅速拖垮。
28.2.6 同态加密（HE）深挖¶
同态加密最大的吸引力在于“密文可计算”。也就是说，数据即便以加密形式存在，系统仍然可以在不解密的前提下对其进行一定形式的运算，最终解密后获得与明文运算一致的结果。这个特性使 HE 在理论上具有非常强的隐私保护能力，因为计算节点不需要看到明文。
（1）为什么 HE 很强¶
HE 尤其适合那些“数据必须交给不完全可信环境处理，但又不能暴露明文”的场景，例如跨云推理、加密状态下的聚合统计或部分安全推理任务。对于中心平台不可信、但又必须承担计算任务的架构来说，HE 提供了一种非常有吸引力的保护思路：把“不能信任计算方”转化为“计算方根本看不到明文”。
（2）为什么 HE 很重¶
HE 的问题在于工程代价极高。密文运算通常远慢于明文运算，且模型中的非线性算子、复杂控制流和大规模矩阵操作都会显著增加实现难度。因此，HE 往往适合在一些特定环节使用，如安全聚合、有限推理或关键子模块加密计算，而不适合作为整条复杂深度训练流水线的全量替代方案。
28.2.7 可信执行环境（TEE）深挖¶
TEE 的逻辑是“相信硬件飞地，而不是相信宿主机环境”。它通过 CPU 或硬件平台提供的受保护执行空间，让敏感代码和数据在隔离的环境中运行，即便宿主系统、管理员或云厂商运维具有较高权限，也无法轻易查看其中的明文数据与运行时状态。
（1）TEE 的价值¶
TEE 特别适合保护系统中的关键节点，例如联邦训练中的聚合服务、密钥管理服务或某些高敏感推理任务。当组织无法完全信任云厂商运维、容器运行环境或宿主操作系统时，TEE 可以为“最关键但不得不集中执行的那部分逻辑”提供额外的保护层。
（2）TEE 的风险与限制¶
TEE 并不是银弹。它依赖硬件可信根，而硬件本身也存在供应链、实现缺陷和侧信道攻击等问题。与此同时，TEE 的资源限制、调试复杂度和与现有平台的兼容成本，也会显著提升落地难度。因此，工程上更常见的做法是把 TEE 用作关键节点硬化，而不是把整个系统都强行塞进可信飞地。
28.3 选型与系统代价评估¶
引入隐私增强技术，本质上是用系统性能、工程复杂度和组织协作成本，去换取更强的合规可通过性与更低的泄露风险。架构师必须把这些代价显式讲清楚，而不是把隐私方案包装成“零成本升级”。在真实项目中，很多隐私技术失败并不是因为理念错误，而是因为没有人提前告诉业务方：你要为此付出多少算力、多少时延、多少带宽、多少调试成本，以及多少组织协调成本。
28.3.1 精度损失、时延增加与通信开销¶
首先是精度损失。它主要来自差分隐私噪声、MPC/HE 对复杂算子的近似处理、联邦环境下的非 IID 数据分布以及训练轮次受限等因素。对于业务方来说，最直观的问题通常不是“隐私预算是多少”，而是“指标会掉多少”。这说明隐私技术要真正落地，必须用业务能理解的语言说明 utility 的变化。
其次是时延增加。MPC 与 HE 会显著增加计算时延，而联邦学习则往往受到节点等待、网络同步、慢客户端拖尾与重试机制的影响。对于在线推理系统来说，若系统响应要求是毫秒级，那么很多重型隐私计算方案几乎不具备现实可行性。
第三是通信开销。在大模型或高维模型场景下，联邦参数或梯度传输规模极大。若再叠加加密膨胀，带宽常常成为第一瓶颈。很多团队以为问题出在算法，其实问题首先死在网络上。
28.3.2 何时选择制度治理，何时选择技术治理¶
并不是所有项目都需要“上隐私计算大招”。应该结合 Ch27 的分类分级框架来决策。对于 L1（C1）低敏感数据，优先采用制度治理，通常通过 RBAC、常规脱敏、审计日志和审批流即可满足需求。对于 L2（C2）中敏感数据，可以先采用隔离环境、部分字段限制、用途约束和轻量级联邦分析。只有当项目进入 L3（C3）高敏感数据、跨主体协作、跨境场景或外部联合训练时，才必须把“数据不出域”从制度要求上升为系统物理边界，进而引入 FL、MPC、HE 或 TEE 等技术治理手段。
这类判断与 P09 的治理边界是一致的。P09 的目标就是通过分类、权限、脱敏、隔离、审计和事故处理形成一条前置治理闭环，让敏感数据在进入训练或分析系统之前先被控制住。也正因为如此，Ch28 所讨论的隐私增强技术并不是替代 P09，而是在 P09 之后继续向训练阶段推进。
28.3.3 通信优化策略¶
联邦学习中的通信优化是能否落地的关键。一个理论上可行的方案，如果每一轮都要上传超大更新向量、等待所有节点完成训练并重新同步，那么系统很快就会因为网络与时间成本失去可用性。
常见策略之一是梯度压缩。例如只上传 top-k 重要梯度、采用低比特量化或对参数更新做稀疏化处理。这些方法的核心不是追求数学上的完美，而是在可接受的精度损失内显著减少传输体积。第二类策略是减少同步频率。通过增加本地训练步数，降低全局同步轮次，可以用更多本地算力去换更少网络开销。但这种做法也会带来 client drift，需要配合更稳健的聚合策略。第三类策略是异步联邦。它允许不同节点以不同步速参与训练，有助于缓解慢节点拖尾问题，但全局模型的一致性与收敛分析会更加复杂。
图28-7：联邦训练中的通信成本分解图
28.3.4 精度优化策略¶
在引入 DP 或其他隐私约束后，工程团队通常还需要主动做精度补偿。一个简单但经常有效的思路，是先选择更强的预训练基础模型，再在隐私约束下做更轻量的下游优化。因为越强的基础模型，往往越能在有限预算和有限数据下保持可接受的性能。
另一个重要策略是更细粒度地处理样本与客户端差异，例如按机构、群体或任务类型做分组训练，再在更高层级做聚合。对于 DP 场景，还可以在裁剪阈值、噪声强度、训练轮数和优化器上做系统性调参。需要强调的是，隐私场景中的调参比普通模型更复杂，因为你不仅要看损失曲线和验证集指标，还要看预算消耗和攻击验证结果。
28.3.5 系统复杂度与运维代价¶
隐私技术增加的不只是算力代价，还包括密钥管理难度、节点故障恢复复杂度、调试不可见性、日志合规要求以及跨法务、安全、算法和平台团队的协作成本。很多隐私项目失败，不是因为论文方案不对，而是因为运维阶段根本不知道如何排查问题。比如，若聚合器被放进 TEE，中间状态难以直接观察；若使用 HE，开发人员很难像调试普通数值程序那样排查异常；若采用 DP，模型变差时你无法直接判断是预算太小、裁剪太强，还是样本本身太少。
因此，评估隐私增强技术时，不能只算 GPU 和 CPU，更要算组织可维护性。真正能落地的方案，往往不是最“先进”的方案，而是那个在安全、精度、成本与运维之间最平衡的方案。
28.4 实施模式、验证与上线治理¶
28.4.1 横向联邦（Horizontal FL）¶
横向联邦适用于各参与方特征空间基本一致，但用户群体不同的情况。例如两家区域银行都拥有类似的客户特征字段，但服务的是不同地区人群；又如不同城市的医院拥有相似结构的病例字段，但患者样本不重叠。这类场景中，各方的“列”基本一致，而“行”不同，因此更适合把样本层面的协作能力联合起来，以缓解单一机构样本量不足的问题。
横向联邦最大的优势是结构直观，容易理解与部署。但它并不自动意味着训练效果一定好，因为不同机构的用户结构、标签比例与行为模式依然可能存在显著偏差。
28.4.2 纵向联邦（Vertical FL）¶
纵向联邦适用于参与方拥有相似用户群体，但掌握不同特征维度的情况。例如银行掌握用户财务特征，电商掌握消费偏好特征，二者希望在不直接交换原始字段的前提下建立联合风控模型。此时问题的关键不是样本数量，而是特征维度在不同参与方之间的互补性。
纵向联邦的工程难点通常比横向联邦更高，因为它不仅涉及模型协同，还涉及样本对齐、标识匹配与特征联动等问题。若再叠加强隐私约束，系统复杂度会进一步上升。
图28-8：横向联邦与纵向联邦对比示意图
28.4.3 联邦微调（Federated Fine-Tuning）¶
对于大模型场景，越来越多系统采用联邦微调而不是联邦全参数训练。原因非常现实：全量参数训练通信太重、代价太高、隐私暴露面也更大。联邦微调通常会结合 LoRA、Adapter、Prefix Tuning 等 PEFT 方法，仅在各机构间交换较小规模的适配层参数，而不是整个基础模型的全部权重。
这种方式有两个直接好处。第一，通信成本显著降低，更容易在多机构环境中落地。第二，本地机构可以在共享较少参数更新的同时，保留更多对底层模型与私有语料的控制权。因此，联邦微调很可能成为未来跨机构大模型协作的主流形态之一。
28.4.4 安全聚合（Secure Aggregation）¶
联邦训练若要真正成立，必须回答一个问题：聚合器是否能看到每个客户端的单独更新？如果答案是“能”，那么联邦学习虽然阻止了原始数据出域，但仍然可能把梯度泄露风险暴露给中心端。安全聚合的目标，就是让中心端只能看到聚合后的结果，而看不到单个客户端的原始更新。
这一点非常重要，因为很多人会把联邦学习和安全聚合混为一谈。事实上，联邦学习只是组织训练的一种方式，而安全聚合是其中一个非常关键但并非自动拥有的安全模块。一个没有安全聚合的联邦系统，往往仍然留着明显的中心观察面。
28.4.5 上线治理与灰度策略¶
隐私增强系统也必须做灰度、回滚和异常中止。很多团队把隐私技术想象成“后台静默生效”的能力，但实际上它对模型效果、系统时延与参与方协作都会产生显著影响，因此更需要谨慎上线。实践中，联邦或隐私增强系统上线前，通常应设置小范围机构灰度、预算阈值、参数更新频率限制、数据域变更审批、异常训练中止条件以及合作方退出机制。
这类治理要求看似繁琐，但其本质是把“隐私风险”显式纳入系统变更管理。对强监管行业来说，真正危险的不是技术本身，而是技术上线后没人知道什么时候该停、谁有权限改、出了问题怎么追溯。
28.5 联邦学习中的攻击与防御¶
一个成熟的隐私章节，不能只讲技术方案，还必须讲攻击面。否则读者很容易误以为“数据不出域”就已经足够安全。事实上，联邦环境中的攻击面并不比集中式训练少，只是攻击路径发生了变化。攻击者不一定要拿到原始数据库，也可以通过观察梯度、参与训练、操纵更新或分析模型输出来实施攻击。
28.5.1 成员推断攻击（Membership Inference）¶
成员推断攻击的目标，是判断某个样本是否出现在训练集中。在医疗和金融场景中，这种判断本身就已经可能构成重大隐私泄露。举例来说，攻击者若能判断某患者是否出现在某罕见病训练集中，即便不知道该患者的全部病历细节，也已经足以造成严重的伦理和法律问题。
联邦学习并不会天然消除这类风险。因为全局模型仍然可能对训练样本表现出更高的置信度、更稳定的预测模式或特殊的输出行为。攻击者可以利用这些差异，推断某个样本是否曾参与训练。
28.5.2 梯度反演攻击（Gradient Inversion）¶
梯度反演攻击说明了联邦学习的另一个核心风险：即便原始数据不出域，上传的梯度或参数更新本身也可能包含足够多的信息，使攻击者能够恢复原始训练样本或其近似特征。对于图像任务，攻击者可能重建出样本轮廓；对于文本任务，可能恢复关键词、句式甚至部分敏感片段。
这类攻击之所以危险，是因为它直接击穿了很多组织对联邦学习的第一层幻想：数据没有上传，并不等于信息没有上传。只要上传内容仍然保留了可分析结构，攻击面就依然存在。
图28-9：梯度反演攻击示意图
28.5.3 模型投毒与后门攻击¶
在联邦环境中，攻击者不一定要偷数据，还可以通过恶意客户端上传被操纵的模型更新，从而污染全局模型。若攻击目标是整体性能下降，这属于模型投毒；若攻击目标是在特定触发条件下让模型输出错误结果，这通常被称为后门攻击。
这类攻击特别值得重视，因为联邦学习本身鼓励多方共同参与训练，而多方参与也意味着中心平台很难完全确定每个客户端是否行为正常。对医疗诊断、金融审批和公共服务系统而言，哪怕攻击者没有窃取任何原始数据，只要能系统性地扭曲模型决策，也同样属于重大安全事件。
28.5.4 防御机制¶
联邦系统的防御可以从三个层面展开。第一是隐私防御，如差分隐私、梯度裁剪与安全聚合，重点在于降低单个样本和单个客户端更新的可分析性。第二是鲁棒聚合，如 Median、Trimmed Mean、Krum 等稳健聚合策略，重点在于减小恶意客户端对全局模型的影响。第三是异常检测，即对客户端更新幅度、更新方向、损失变化和分布异常进行监控与拦截。
需要指出的是，这三类防御通常也不是替代关系。差分隐私更偏向防推断和防重构，鲁棒聚合更偏向抗投毒，异常检测则更偏向运行期发现问题。一个真正可信的联邦系统，往往必须把这三类能力组合起来。
28.5.5 攻防验证为什么必须纳入上线标准¶
如果系统没有做过成员推断测试、反演测试和投毒鲁棒性测试，那么“系统采用了隐私技术”这一事实本身并不能说明风险已经被控制。真正的合规落地，不是配置技术名词，而是验证可攻击面是否真的下降。也就是说，隐私保护不能只靠设计说明文档证明，还必须靠攻防实验和上线前验证结果来证明。
这也是很多组织在隐私工程上容易忽视的地方：他们会花很多精力介绍用了什么技术，却很少回答“你怎么证明这些技术在你的数据、你的模型和你的攻击假设下真的有效”。本章所强调的上线治理，正是要把这种验证前置成上线门槛，而不是事后补救。
28.6 联邦系统架构设计¶
到这一步，章节必须从“技术概念”进入“系统工程”。因为技术路线能否落地，最终取决于系统如何拆分组件、如何组织控制流、如何记录版本与预算，以及如何处理故障和协作变更。换言之，联邦学习不是一个算法函数，而是一套分布式协作系统。
28.6.1 联邦系统的核心组件¶
一个完整的联邦训练系统通常包括五类核心组件。第一类是 Coordinator / Orchestrator，负责训练轮次调度、参与方注册、任务编排与模型版本控制。第二类是 Client Runtime，部署在各机构本地，负责数据加载、本地训练、策略执行和本地日志管理。第三类是 Aggregator，负责汇总上传更新并生成全局模型。第四类是 Privacy Engine，负责执行梯度裁剪、噪声注入、预算记录、安全聚合或密钥相关操作。第五类是 Audit & Governance Layer，负责日志、审批、审计追踪与异常告警。
一个成熟的联邦系统，往往不是把这些能力堆在一个服务里，而是把训练编排、隐私控制与审计治理明确拆开。这样做的原因是，隐私策略和模型策略并不总是由同一团队维护，若边界不清，后期很容易出现“模型更新了，但隐私参数没同步”“预算耗尽了，但训练还在跑”之类的问题。
图28-10：联邦系统整体架构图
28.6.2 数据流与控制流¶
联邦系统设计中，一个非常容易被忽略但极其重要的问题，是区分数据流和控制流。数据流指原始数据、本地样本、中间特征、梯度或参数更新如何在系统中流动。控制流则指谁来下发训练任务、谁来决定参与轮次、谁来批准策略变更、谁来记录预算消耗、谁有权限终止训练。
很多架构问题并不是出在算法，而是出在没有把这两类流区分清楚，导致权限设计和风险责任混在一起。例如，某个中心服务虽然不直接接触原始数据，但若它可以强制下发任何训练任务、修改任何隐私参数并绕过审计，那么它在控制流上依然拥有过大的权力。对强监管场景而言，这同样是高风险架构。
28.6.3 模型版本、预算版本与审计版本¶
在传统模型平台中，很多团队只记录模型版本号和上线时间。但对联邦与隐私增强系统而言，这远远不够。系统还应显式记录：哪个模型版本使用了什么隐私预算；哪一轮训练引入了哪些机构；哪次聚合采用了什么裁剪阈值、噪声策略或安全聚合方案；哪些告警与该模型版本相关。
这意味着联邦系统中的版本控制，不只是“保存一个权重文件”，而是要能追溯一整个训练治理过程。只有这样，当模型出现问题、合作机构提出质疑或审计部门追问时，组织才能说明：这个模型是如何形成的，在哪些边界内训练过，为什么它被允许上线。
28.6.4 故障、重试与参与方退出¶
联邦系统天然面临参与方不稳定、网络中断、节点性能不一致和训练中途退出等问题。因此，系统必须设计客户端掉线后的容错策略、部分参与方失败时是否继续聚合、训练轮次回滚机制，以及合作机构临时或永久退出时的处理规则。
这一点非常现实。集中式训练假设训练节点由同一个团队维护，而联邦环境中的客户端可能属于不同机构、不同网络、不同安全策略。某个节点掉线不一定是技术故障，也可能是机构策略变化、审批暂停或风控触发。因此，联邦系统的容错不仅是分布式系统问题，也是组织协作问题。
28.7 与 P09 隐私保护流水线的衔接¶
从体系上看，P09 的重点不是联邦训练本身，而是通过分类、权限、脱敏、隔离、审计、预检和事故复盘，形成一条隐私保护数据流水线。其目标不是“做一次脱敏”，而是建立一套可以解释责任边界的处理体系，让敏感数据在进入训练或分析系统之前先被安全地控制住。
28.7.1 P09 解决的是“进入训练前”的治理问题¶
在 P09 中，系统先生成合规范围、分类策略、访问策略和隐私技术选项，再对原始记录执行分类、脱敏、隔离、告警与审计，并通过 preflight 与 postmortem 补齐治理闭环。也就是说，P09 首先回答的是：哪些数据可进入后续系统，哪些必须隔离，哪些字段必须去掉，哪些访问应被审计，哪些异常必须复盘。
这类工作虽然不等于联邦学习，但它是联邦学习之前必须完成的基础治理。因为若前置分类和边界控制都没有做好，后续任何联邦训练都可能是在错误的数据边界上运行。
28.7.2 联邦学习解决的是“跨主体联合训练”的问题¶
即便 P09 已经把数据预处理得足够干净，也不代表这些数据就适合被集中汇聚。联邦学习与 PETs 解决的是另一个问题：在不能集中共享原始数据的情况下，如何继续建模。换言之，P09 保证数据进入模型系统前的治理质量，而 Ch28 讨论的是数据进入各自本地域后，跨主体协作训练如何继续保持隐私边界。
28.7.3 两者如何形成闭环¶
从整本书的体系上看，可以把这条闭环明确写出来。Ch27 负责制度层面的合规框架与分级标准；P09 负责数据进入模型系统前的分类、脱敏、权限、隔离、审计与预检；Ch28 负责训练与协作阶段的隐私保护；Ch22 则负责多模态检索与应用能力承接。这样一来，整套体系就不再是孤立章节，而是一条从“数据治理”走向“模型治理”再走向“应用治理”的完整链路。
图28-11：合规治理、隐私流水线、联邦训练与应用能力闭环图
28.7.4 为什么这条衔接很重要¶
很多项目的问题在于：前置治理是一个团队做的，训练系统是另一个团队做的，两者之间没有统一策略贯通。结果就是，前面做了很多分类和隔离，后面训练系统仍然通过缓存、调试、参数同步或输出日志把风险重新引入进来。本章要强调，P09 与联邦系统不是两个孤立模块，而应共享分类等级、审计策略、风险阈值和异常处置逻辑。只有如此，隐私保护才不是“某一段流程看起来很安全”，而是整个生命周期具备一致边界。
28.8 行业案例深挖¶
28.8.1 医疗场景：跨院多模态罕见病模型¶
回到本章开头的医疗案例。这个案例最能说明为什么单一技术往往不够。首先，数据属于 C3 高敏感，天然不允许自由流动；其次，文本、影像、基因属于跨模态高风险组合，单独脱敏并不足以消除对齐后的重识别风险；再次，参与方跨机构且互不完全信任，任何一方都不愿承担集中建湖的责任。
在这种情况下，较合理的路线往往不是“集中训练 + 脱敏补丁”，而是组合式方案：前置治理承接 P09 的分类、访问控制和直接 PII 去除；训练阶段采用联邦微调，避免跨机构集中共享原始数据；上传更新前叠加差分隐私，降低成员推断风险；中心聚合节点可配合安全聚合或 TEE 做额外保护；上线前则必须执行成员推断与反演测试。
这个案例的关键不在于技术上能不能把数据集中起来，而在于治理边界根本不允许。也正因为如此，隐私增强技术的价值并不只是“让系统更安全”，而是“让原本无法开展的协作训练成为可能”。
28.8.2 金融场景：联合反欺诈与黑名单匹配¶
金融场景与医疗不同，其目标往往不是多模态生成或复杂表征学习，而是联合风控、黑名单求交、异常识别与规则增强。两家机构可能都掌握一定规模的可疑账户信息，但都不能直接交换完整用户名单，因为这既涉及客户隐私，也涉及商业边界与合规责任。
在这种情况下，若任务是做联合求交或交集统计，通常优先考虑 MPC/PSI；若任务是联合训练风控模型，则可考虑 FL；若系统对查询结果仍然担心存在隐私侧泄露，则还可以叠加更严格的结果审计与查询限制。和医疗场景相比，金融更强调规则精确性、低误报和可解释性，因此其技术路线往往更偏向“安全计算 + 审计可追溯”，而不是单纯追求最高模型性能。
图28-12：医疗与金融场景的隐私技术路线对比图
28.9 从训练到推理：隐私保护的全链路视角¶
很多读者容易把隐私问题理解为“训练时的问题”，但真实系统中，训练、部署、查询和追责都可能构成泄露面。训练阶段的风险包括数据接入、梯度上传、聚合、参数存储和调试日志；推理阶段的风险则包括提示词诱导泄露、输出过拟合暴露、查询频次累积形成推断，以及 API 返回内容中泄露训练痕迹；而在审计与追责阶段，组织还必须回答模型是在什么边界内训练的、哪些预算已被消耗、哪次更新引入了问题。
换言之，隐私保护不是训练阶段临时加一层，而是贯穿模型生命周期的持续治理对象。只有当组织把隐私理解为“全链路属性”，而不是“某个模块的附加能力”，它才可能真正形成稳定、可复用、可审计的系统设计。
28.10 实践指南：什么时候该上，什么时候不该上¶
首先，不要为低敏感、单主体、低风险数据过度设计。若数据本身并不敏感，且完全在单组织内部受控环境中使用，那么直接引入联邦学习或 MPC 往往只会增加复杂度，未必带来真实收益。第二，不要把联邦学习当作“天然安全”。联邦学习解决的是数据位置问题，不自动解决梯度泄露、成员推断、模型投毒和后门风险。第三，技术选型应先问协作边界，再问算法偏好。真正应优先回答的问题是：原始数据能否出域、中心端是否可信、参与方是否互信、在线时延要求有多高、是否必须防成员推断、是否要求审计可解释。
一个实用的经验是：当你发现一个项目既不涉及强敏感数据，也不涉及跨主体协作，却仍然试图上最复杂的隐私计算栈时，往往意味着架构已经开始过度设计。反过来，当你面对的是医疗、金融、跨境或政务协作，却还试图只靠“字段脱敏 + 访问控制”来过关，那又意味着架构设计严重低估了现实风险。
28.11 本章小结¶
本章从“为什么隐私保护必须前置进入架构设计”出发，系统介绍了 FL、DP、MPC、HE 与 TEE 五类隐私增强技术，并分析了它们在保护对象、计算成本和适用场景上的差异。我们强调，联邦学习不是“数据不出域”的简单口号，而是一整套关于训练控制权、参数流动方式与协作边界的系统设计。差分隐私提供了可量化的个体保护框架，多方安全计算适合联合统计与求交场景，同态加密为密文计算提供理论上极强的保护能力，而可信执行环境则在硬件层面为关键节点建立起运行时可信边界。
更重要的是，本章把隐私问题从“技术名词介绍”推进到了“工程系统治理”层面。我们讨论了非 IID 数据、通信开销、精度损失、隐私预算、攻击与防御、系统架构、版本追踪以及上线治理等问题，说明隐私增强技术的真正难点不在于能否找到算法，而在于如何将其嵌入完整的模型生命周期中。
最后，结合 P09 隐私保护流水线以及医疗、金融案例，我们可以看到：成熟的 AI 隐私治理体系，不是某一项技术的单点突破，而是制度治理、数据治理、训练治理、验证治理和审计治理的组合拳。真正可落地的系统，必须同时回答四个问题：数据如何进入、模型如何训练、风险如何验证、责任如何追溯。