Owkin：联邦学习与多组学药物研发案例

Owkin 的技术核心是联邦学习：在医疗数据无法离开各家医院的前提下，仍然训练出跨中心的模型。这解决的是医疗 AI 的一个根本矛盾——模型需要大量多样化的数据，而医疗数据受隐私法规严格约束，无法集中。

联邦学习的原理

• 数据不动，模型动：中心服务器把模型参数下发到各参与方；
• 各方在本地数据上训练，只把模型更新（梯度或权重）传回；
• 中心把各方的更新聚合（如加权平均）成新的全局模型；
• 迭代若干轮，得到一个「见过所有数据」但从未接触原始数据的模型。

在医疗场景的价值

问题	联邦学习的作用
隐私法规（GDPR、HIPAA）	原始数据不出机构
数据孤岛	可利用多中心数据而无需共享
罕见病样本少	汇聚多中心才有足够样本
单中心模型泛化差	多中心训练提升泛化能力
机构间信任	降低共享数据的顾虑

「单中心模型泛化差」是被低估的一点：一家医院的数据反映的是该院的患者构成、设备型号、操作规范。在此训练的模型换到另一家医院常常性能大跌。多中心训练即使不为隐私，也能提升鲁棒性。

实际难点

• 数据异质性（non-IID）。这是最大的技术挑战。各中心的患者构成、设备、标注标准差异很大，本地训练的模型会朝不同方向漂移，简单平均可能导致全局模型比任何单中心模型都差。需要 FedProx、SCAFFOLD 等改进算法或个性化联邦学习。
• 标签定义不一致：不同医院对同一诊断的标准可能不同，这种「标签噪声」在联邦设置下更难发现和处理。
• 隐私仍非绝对：梯度本身可能泄漏训练数据信息（梯度反演攻击已被证实可行）。需要额外加差分隐私噪声或安全聚合，而这会损失模型精度——这是一个真实的权衡。
• 通信与工程成本：多轮通信、各方基础设施异构、需要各机构 IT 配合，工程与协调成本很高。
• 激励与治理：谁出数据、谁得模型、成果如何分配？这些非技术问题往往比技术问题更难解决。

开源工具

# 主流联邦学习框架
#   Flower      —— 框架无关，易上手，适合原型
#   NVIDIA FLARE —— 面向医疗场景，有临床部署案例
#   OpenFL      —— Intel，医疗影像方向
#   FedML / PySyft —— 研究导向

# 关键实践：
# 1) 先做「集中式上界」实验
#    假装能集中数据训一个模型，作为性能上界参考。
#    联邦模型与它的差距，就是异质性与隐私保护的代价。

# 2) 也要做「本地基线」
#    每个中心只用自己数据训练的模型。
#    联邦模型必须明显优于本地基线，否则不值得这套复杂度。

# 3) 评估要跨中心
#    在留出的中心上测试，才反映真实泛化能力。

# 4) 处理异质性
#    FedProx（加近端项限制本地漂移）
#    或个性化联邦学习（全局共享表示 + 本地个性化头）

第 1、2 条对照实验是必做的：如果联邦模型既接近不了集中式上界，又赢不了本地基线，那么整套联邦架构的复杂度就没有换来价值。

在药物研发中的应用

• 多中心的病理图像分析：预测治疗响应、识别生物标志物；
• 跨药企的模型协作：多家公司在不共享化合物结构的前提下联合训练 ADMET 模型（MELLODDY 项目是这个方向的知名尝试）；
• 真实世界证据：跨医院的疗效与安全性分析；
• 患者分层：识别可能响应的亚群。

跨药企联合建模是很有想象力的方向：各家的内部数据合起来规模可观，但没人愿意共享化合物结构。联邦学习理论上能解决这个矛盾，实践中的难点在于化学空间差异大、以及对梯度泄漏结构信息的顾虑。

延伸资源

• 临床数据路线：319《Valo Health》；其他公司：321《Insitro》；
• 数据隐私与可信 AI 见「决策与监管」模块。