Federated Learning / FedAvg：跨域协作 AI
一句话:
Federated Learning / FedAvg 解读
面向对象: AI Product Architect / Data Product / Privacy Architect / Risk Product / AI Platform PM。 核心问题: 当数据不能集中到同一个训练环境时，如何训练共享模型？Federated Learning 能解决什么，不能解决什么？ 学习目标: 理解 FedAvg、cross-device / cross-silo federated learning、secure aggregation、privacy controls、模型治理，并映射到金融零售跨机构风险协作、集团内数据隔离、财富/信贷模型训练和 KYC/欺诈场景。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| FedAvg paper | https://arxiv.org/abs/1602.05629 | 理解 Federated Averaging 和 decentralized training 的基本问题 |
| Google Research publication | https://research.google/pubs/communication-efficient-learning-of-deep-networks-from-decentralized-data/ | 理解通信效率和分布式客户端训练的背景 |
| TensorFlow Federated | https://www.tensorflow.org/federated | 理解 federated computation 的工程抽象 |
| TensorFlow Federated GitHub | https://github.com/tensorflow/federated | 理解 TFF 作为开源实验框架的边界 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 把联邦学习纳入风险、测量、治理和监控 |
一句话:
Federated Learning 让多个数据持有方在数据不离开本地环境的前提下，共同训练或改进一个共享模型，但它不是隐私、合规和安全的自动豁免。
1. 为什么需要联邦学习
在金融零售里，很多高价值 AI 问题天然跨边界:
- 不同银行都能看到一部分欺诈行为，但单家机构样本不足。
- 集团内银行、保险、财富、零售子公司数据不能随意合并。
- 不同国家或地区的数据 residency 限制不同。
- 分支机构、商户、合作方各自拥有本地数据。
- 客户设备或边缘端能提供行为信号，但不能上传原始数据。
传统集中训练假设:
all data -> central data lake -> training -> model
联邦学习改成:
central coordinator sends model
-> participants train locally
-> participants send updates
-> coordinator aggregates
-> shared model improves
核心价值:
- 减少原始数据移动。
- 支持数据分散场景。
- 降低部分数据共享阻力。
- 在样本稀缺场景提升模型覆盖。
- 让跨组织协作有更细的技术控制面。
但要清楚:
- 模型更新也可能泄露信息。
- 参与方之间仍需合同、治理和审计。
- 数据质量、标签口径和分布差异仍然存在。
- 模型输出仍可能产生偏差或客户影响。
- 联邦学习不能替代隐私评估、法律评估和模型风险管理。
2. FedAvg 的核心直觉
FedAvg 的基本流程:
server initializes model
-> selects clients
-> sends current model weights
-> clients train locally for several steps
-> clients send weight updates
-> server averages updates weighted by local data size
-> repeat
为什么叫 Federated Averaging:
- 每个参与方在本地数据上训练。
- 中央协调器不直接看原始样本。
- 聚合时对本地模型更新做加权平均。
产品/架构意义:
| 技术机制 | 产品含义 |
|---|---|
| Local training | 原始数据不出本地边界 |
| Model update aggregation | 协作对象从“数据”变成“模型更新” |
| Client sampling | 参与方可按策略、可用性、风险选择 |
| Communication rounds | 成本、延迟、网络和稳定性成为系统约束 |
| Weighted aggregation | 大数据方影响更大，需要公平和治理设计 |
3. Cross-Device vs Cross-Silo
| 类型 | 参与方 | 典型场景 | 金融零售映射 |
|---|---|---|---|
| Cross-device | 大量终端设备 | 输入法、移动端行为、个人设备学习 | 移动银行个性化、设备侧欺诈信号 |
| Cross-silo | 少量组织或数据域 | 医院、银行、子公司、合作伙伴 | 银行联盟欺诈模型、集团内 KYC/AML 模型 |
金融零售更常见的是 cross-silo:
- 参与方少，但每方数据量大。
- 合同和治理复杂。
- 网络稳定性比移动端好。
- 数据 schema 和标签口径差异明显。
- 需要清晰的责任、审计和退出机制。
Cross-device 更关注:
- 设备可用性。
- 电量和网络。
- 客户同意。
- 本地模型大小。
- 差分隐私和 secure aggregation。
4. 联邦学习不是完整隐私方案
常见误解:
数据没有离开本地，所以一定安全合规。
问题在于:
- 梯度或模型更新可能泄露训练样本信息。
- 恶意参与方可能发起 poisoning。
- 协调方可能从更新中推断敏感属性。
- 不同参与方标签质量不一致会污染模型。
- 模型反演、成员推断仍需防控。
需要组合控制:
| 控制 | 作用 |
|---|---|
| Secure aggregation | 协调方只看聚合结果，不看单个参与方更新 |
| Differential privacy | 限制单个样本或用户对模型更新的影响 |
| Participant attestation | 确认参与方运行的是批准代码和环境 |
| Data contract | 统一 schema、标签、时间窗口、质量标准 |
| Update validation | 检测异常更新、poisoning、漂移 |
| Governance agreement | 明确用途、责任、退出、审计、模型所有权 |
| Model evaluation | 按参与方、地区、客户群体评估 |
联邦学习是一种数据协作架构，不是合规结论。
5. 金融零售案例
5.1 跨机构欺诈模型
问题:
- 单家机构只能看到自己客户和交易。
- 欺诈团伙跨机构迁移。
- 共享原始交易数据法律、商业和隐私阻力大。
联邦架构:
bank A local fraud data
bank B local fraud data
bank C local fraud data
-> local training
-> secure update aggregation
-> shared fraud model
-> local validation and deployment
必须解决:
- 标签定义是否一致。
- 欺诈确认延迟如何处理。
- 参与方是否可以贡献低质量或恶意更新。
- 模型输出是否直接影响客户交易。
- 误杀客户的责任如何分配。
5.2 集团内信贷模型
集团内不同业务线不能简单合并数据:
- 银行数据。
- 汽车金融数据。
- 零售信贷数据。
- 外部合作渠道数据。
联邦学习可以训练共享表示或初始模型，但正式信贷决策仍需要:
- 本地模型验证。
- 公平借贷评估。
- reason code。
- adverse action 边界。
- 数据用途和客户同意审查。
5.3 KYC 文档模型
不同地区 KYC 文件样式不同。联邦学习可以让地区模型贡献文档识别能力，但:
- 文档包含高敏 PII。
- OCR 错误会影响客户 onboarding。
- 各辖区政策不同。
- 本地规则和人工复核仍不可省略。
6. Architecture Checklist
| 设计项 | 高级问题 |
|---|---|
| Federation scope | 是跨设备、跨子公司、跨机构还是跨国家 |
| Governance | 谁是 coordinator，谁拥有模型，谁批准参与方 |
| Data contract | schema、标签、时间窗口、质量阈值是否一致 |
| Privacy controls | 是否需要 secure aggregation、DP、TEE 或 clean room |
| Update validation | 如何检测异常、poisoning、漂移、低质量参与方 |
| Evaluation | 全局指标和本地 slice 指标如何同时满足 |
| Deployment | 共享模型是否统一部署，还是各方本地 fine-tune |
| Audit | 是否能证明训练轮次、参与方、版本、隐私参数和评估结果 |
| Exit | 参与方退出后模型和贡献如何处理 |
| Liability | 客户影响、误判、投诉和监管问询由谁负责 |
7. 面试表达
30 秒版本
Federated Learning 适合数据不能集中但又需要协作建模的场景，例如跨机构欺诈或集团内多数据域建模。FedAvg 的核心是把模型发到本地训练，再聚合模型更新。但它不能自动解决隐私和合规问题，模型更新仍可能泄露信息，所以通常要结合 secure aggregation、差分隐私、数据契约、参与方治理、更新验证和本地模型风险管理。
2 分钟版本
我会先区分 cross-device 和 cross-silo。金融零售更常见的是 cross-silo，例如多银行欺诈模型或集团内信贷模型。架构上，coordinator 发送模型，参与方本地训练，返回更新，服务器聚合。产品层面关键不是算法本身，而是协作边界：参与方资格、数据口径、标签延迟、隐私参数、异常更新、模型所有权和客户影响责任。上线前要做全局评估和各参与方本地评估，不能因为全局指标提升就忽略某个客户群体或地区的风险。
架构师版本
联邦学习是分布式 ML 与数据治理的交叉架构。它需要 coordinator、participant runtime、secure aggregation、privacy accountant、feature/data contract、update validation、model registry、audit log 和 local deployment pipeline。它解决的是“少移动原始数据”，不是“无需治理”。
8. 作品集任务
做一个跨机构欺诈联邦学习方案:
- 画 cross-silo FL 架构图。
- 定义参与方、coordinator、数据 contract、模型所有权。
- 写 10 条数据/标签一致性检查。
- 设计 secure aggregation + DP 的控制组合。
- 写 poisoning/update anomaly 监控清单。
- 定义全局指标、本地指标和客户影响指标。
- 写一页 governance memo: 为什么不直接共享原始数据，为什么 FL 仍需法律和模型风险评审。