数据共享这件事，行业内喊了整整十年。最早大家觉得是技术问题，把接口做好、把报表打通就行；后来发现是合规问题，数据离开自己机房的那一刻，泄露风险、责任边界、个人隐私保护全都压上来；再后来发现是利益问题，数据已经成了核心资产，谁都不愿意当那个“数据奶牛”，把自己的家底交出去。我接触过很多银行、保险、互联网公司的联合建模项目，绝大多数都卡在这三座大山的半路上。蚂蚁金服（现在叫蚂蚁集团）的共享智能团队这些年一直在做一件事，想用一套“数据可用不可见、数据不动模型动”的方案，把数据共享的门槛降下来。

这篇内容写给正在做跨机构联合建模、隐私计算平台选型，或者被数据合规限制住业务场景的同行。我会把共享智能的核心思路、底层技术、蚂蚁的工程实践，以及我自己实操时踩过的坑，一次说透。不保证你看完能直接造一套平台出来，但至少再有人跟你谈“多方安全计算”和“联邦学习”，你不会被名词绕晕。

1. 数据共享为什么这么难：先看清三个真实痛点

1.1 不敢共享：责任划分和监管压力

行业内长期流传一句话：数据不出域是硬约束，出域就是事故。这个“域”可以理解成一个机构的安全边界。数据一旦从自己的表里拷贝出去，不管是走邮箱、走FTP，还是走到对方的建模服务器，中间任何一环出了问题，责任都在数据提供方。更重要的是，用户的个人敏感信息被用于联合计算，如果合作方使用不当，提供方也很难撇清关系。

所以很多机构宁可自己单干，也不愿意把原始数据交出去。我参与过的一个跨银行反欺诈项目就是这样：双方都认可共享黑名单能提升识别率，但一到“谁提供、谁存储、怎么删除”的环节，法务就卡住了。最后只能退化成“你给我一个excel，我人工比对”这种极其原始的合作方式，效率低到没法看。

1.2 不能共享：技术口径和数据质量互相打架

即便机构管理层同意共享，技术和数据侧的难题也一点不少。每个公司的客户ID体系不一样，有的用手机号，有的用身份证号，有的是内部生成的客户号。两张表想关联上，得先做身份映射。字段口径更是五花八门，A银行定义的“逾期天数”是自然日，B银行用的是工作日；A机构“活跃用户”看最近30天登录，B机构看的是最近90天交易。

传统合作模式里，这些差异全靠算法工程师在明文的临时表里一个个核对。如果只是两三家机构还好，真正到了共享智能这种多方参与的场景，五六张表一进来，字段清洗工作就能把团队拖垮。更别提有些数据方干脆没有准备好结构化的明细数据，给出的统计口径完全对不上。

1.3 不会共享：缺技术、缺标准、缺人才

还有一个被低估的问题：绝大多数业务团队根本不知道怎么“安全地共享”。隐私计算领域的技术栈很杂，联邦学习、安全多方计算、差分隐私、可信执行环境，每一个拿出来都是一套独立体系。让一个传统的数据工程师三个月搞明白所有密码学协议，再动手搭建一套多方参与的建模环境，现实吗？不现实。

所以蚂蚁做共享智能平台的时候，一个核心设计目标非常明确：把复杂留给自己，把简单留给用户。业务方不需要知道底层跑的是MPC还是联邦学习，他只需要在界面上配置数据、选模型、发起训练。这也是“降低数据共享难度”这句话的真正含义——降低的是全流程的使用门槛，而不只是在某个点位上做技术突破。

2. 共享智能的技术底座：四大核心组件一次讲清

2.1 联邦学习：数据不动，模型动

联邦学习的思路特别容易理解：传统联合建模是把数据聚到一起，然后训练模型；联邦学习反过来，模型在各方之间流动，数据永远留在本地。每一方用自有数据训练出一个更新量，只把更新量传到中心或伙伴那里做聚合。

用小组作业做类比就很清楚：以前是你把所有人的笔记本收上来，自己整理成一份答案；联邦学习是大家各自在自己笔记本上写答案，只把每道题的“结论摘要”互相交换，最终各自都能推演出完整结论，但谁也没拿走谁的原文。蚂蚁在信贷场景里用得比较多的是纵向联邦，也就是A机构有用户的申请信息、B机构有用户的还款行为，两边样本用户重叠，但特征维度互补，联合起来能训练一个比任何单边模型都强的评分模型。

联邦学习的优势是通信开销可控、工程实现相对成熟，缺点在于它并不是绝对安全。中间传递的梯度信息理论上可以被反推攻击，因此在实际平台里联邦学习往往要叠加加密聚合、梯度扰动等手段才能合规落地。

2.2 安全多方计算：让计算直接在密文上进行

安全多方计算（MPC）比联邦学习更“硬核”。它将一个计算任务拆解到多个参与方，每个参与方持有的数据在本地被拆分成“秘密份额”，多方在密文状态下完成联合计算，最终结果只推送给指定方。数据全程以密文形式参与运算，连计算方自己都无法知道自己在算什么。

再打个比方：你把自己的数字拆成三份，分别给三个人保管，任何一个人单独拿出来都是无意义的随机数。但三个人凑在一起，把份额相加，才能还原出原始数字。这就是秘密分享的核心思想。MPC在共享智能平台里承担的是“既要求高安全、又要求高准确”的关键计算环节，比如样本对齐、模型聚合、统计指标计算。

MPC最大的痛点是性能。单机在明文上跑一秒钟的运算，MPC可能要跑几百秒甚至更多。蚂蚁在工程上下了很多功夫，包括通信并行化、结构化秘密分享的优化、以及与GPU的混合计算，目的都是把性能压到业务可接受的范围。值得注意的是，MPC并不是万能药，它更适合“小规模、高频次、点数不多”的计算；如果模型有几亿个参数要聚合，纯MPC方案会非常痛苦。

2.3 差分隐私：给计算结果加一层噪声

差分隐私的思路更直白：在对外输出的结果里主动加入一定量的随机噪声，让攻击者无法通过结果的微小差异推断某个具体样本是否存在。它一般用在统计查询、联邦学习的梯度更新以及聚合结果展示场景。

这个方案的好处是简单、透明、性能开销低；代价也明显，噪声加多了，模型精度会下降，统计指标的商业可用性降低。因此差分隐私在蚂蚁共享智能平台里通常不是唯一安全措施，而是作为第二层甚至第三层防线存在。很多合规审查更看重的是“有没有加噪声”这件事本身，而不是噪声的多少，这从侧面说明它的象征意义和实际意义同样重要。

2.4 可信执行环境：用硬件圈出一块安全黑盒

可信执行环境（TEE）走的是另一条路线：不靠密码学，靠硬件。在CPU里圈出一个受硬件保护的安全区，数据进入这个区域后，连操作系统和云管理员都无法读取。大家常听的Intel SGX、ARM TrustZone都是这一类。

TEE的优势是计算性能非常接近明文，工程改造量相对小，适合大型模型训练和高并发在线推理。但它在合规层面一直有争论：数据进了硬件厂商的隔离区，算不算“出域”？硬件自身的安全洞怎么弥补？一些场景还涉及“信任硬件厂商”这一软性约束。蚂蚁在实际平台里把TEE和MPC做了分工：性能敏感、风险可控的场景用TEE；安全等级要求苛刻、涉及核心金融数据的节点用MPC。核心思想是“按场景分级，按数据分级”，而不是一把技术管到底。

四种技术的横向对比如下：

2.5 为什么蚂蚁最终选择了“融合方案”

如果你以为共享智能就是“联邦学习”或者“MPC”，那就低估了这项实践的复杂度。蚂蚁平台最终的方案是融合式的：联邦学习解决协作训练的效率问题，安全多方计算解决关键计算的隐私问题，差分隐私兜底对外输出，TEE承载性能敏感模块。不同的数据、不同的算法、不同的业务诉求，会被自动编排到对应安全等级的技术通道上。

我理解这个选择背后的逻辑很简单：单点技术的短板太明显。纯联邦学习不够安全，纯MPC跑不动，纯TEE说服不了法务，纯差分隐私精度又受不了。平台要做的是“安全、性能、效果”三者的平衡，而不是在任何一个维度上做到极端。这也是为什么共享智能技术路线很难有“标准答案”，更多时候是一门工程妥协的艺术。

3. 蚂蚁共享智能平台的实践：怎么把“难度”拆解掉

3.1 平台架构的三层拆解

蚂蚁共享智能平台在实现上可以粗略分成三层。最底层是安全协议层，负责把MPC、FL、TEE、DP这些安全能力封装成标准协议，向上提供统一的“安全算子”接口。中间是引擎层，负责分布式任务调度、网络通信优化、GPU加速、容错恢复，这些承重墙决定了平台跑得快不快、稳不稳。最上层是产品层，也就是用户真正打交道的东西：建模工作台、数据管理、任务编排、审计后台。

这个分层真实想明白之后，你就会理解共享智能“降低难度”并不是嘴上说说，而是有具体的产品落点。业务团队看到的是一个拖拽式的建模画布，左边是算子列表，右边是数据表，中间是流程编排。算法工程师看到的是一套可编程的Python SDK，可以直接调用安全求交、联邦特征工程、联邦XGB等能力。合规团队看到的是一个只读的审计面板，每一次数据访问、每一轮参数聚合、每一个模型文件输出，都留有不可篡改的操作日志。

3.2 四个“降难度”的具体动作

第一个是标准数据接入。平台定义了一套统一的数据接入规范，各方只需将表结构映射成标准字段，平台自动完成字段对齐和脱敏映射。第二个是现成可用的安全算子。安全求交、联合统计、联邦分箱、联邦WOE、联邦逻辑回归、联邦XGB，这些在隐私计算学术论文里极其抽象的模块，被封装成了一个个开箱即用的算子。第三个是工作流的可视化编排。业务人员不需要写一行代码，把数据节点、特征节点、训练节点连起来，就能发起任务。第四个是全流程审计。

我在实际对接过一个合作机构之后才真正意识到，第四个动作往往才是合规方最看重的。业务部门拍板前，法务和合规要先过一遍“这个平台能不能让我看清楚，数据在什么时间、被什么计算、被谁拿走了”。审计日志把这个问题回答得明明白白，合作流程就会顺畅很多。

3.3 典型场景：信贷风控里的跨机构联合建模

蚂蚁的共享智能最早也最成熟的应用来自金融风控。最典型的场景是多头借贷和共债风险识别。一个人在多家机构同时借款，任何单一机构只能看到自己的那笔信贷记录，看不到全貌。过去洞察这些风险需要把各家的放款数据汇聚到某一家数据中心，这在合规上是很难走通的。共享智能平台推出后，核心变成了各机构把“用户借款行为特征”以隐私计算方式参与联合建模，输出的是一个统一的风险分，而不是原始的贷款明细。

另一个落地较好的场景是跨机构反欺诈名单共享。传统方式是某机构把黑名单ID打包发出去，既泄露客户信息，也容易被人“捡走”。共享智能的做法是各参与方各自维护本地名单，在密文状态下做匹配，最终各方只得到一个匹配命中的加密凭证，匹配结果之外的信息什么都带不走。

这里有个容易被忽视的细节：平台里的“名单共享”并不是直接共享名单本身，而是共享“名单匹配产生的信号”。这个信号可以是命中率、概率分，也可以是打标后的数据特征。一句话说就是：数据本身没有流动，但数据产生的价值流入了模型。

3.4 营销和保险场景的延展

除了风控，蚂蚁也在营销、保险定价等场景里跑通了共享智能方案。比如金融机构和电商平台联合做营销，银行想知道一批潜在客户里哪些人更容易激活信用卡，电商平台想展示高意向但又不把用户画像暴露出去。共享智能可以把双方的标签做联合统计和模型训练，最终给出一个“营销敏感度分群”，双方依据分群策略做投放，同时避免用户隐私裸奔。

保险定价场景更有意思：保险公司有历史理赔数据，医疗机构有诊断和用药数据，两者联合建模会显著提升风险定价精度。但因为医疗数据高度敏感，多年以来一直是行业禁区。共享智能的价值在于让保险公司拿到一个有解释性的定价因子，而不是拿到任何患者的就诊明细。单凭这一点，就值得很多还在观望的保险公司重新评估这条技术路线。

4. 实操全流程：从0到1做一次跨机构联合建模

4.1 先想清楚业务目标和场景形态

我见过太多项目上来就谈“要用联邦学习”，但追问一句“你打算提升什么指标”，对方反而答不上来。联合建模与常规建模最大的区别在于，它每一步都涉及多方协作和成本分摊，如果没有一个清晰的业务目标，很容易变成为了隐私计算而隐私计算。

实操前可以先回答三个问题：第一，这个场景的数据是否天然分布在多个机构，且明文汇聚不可行？第二，合作各方是否有明确的数据贡献和收益分配机制？第三，联合模型相比单边模型是否有足够大的增益预期？这三个问题有一个不成立，项目大概率会在中途烂尾。

确定可以做之后，要判断数据形态。两家机构用户样本重叠度很高、特征互补明显，走纵向联邦；样本重叠低、但特征维度相似，比如两家银行都想做欺诈识别，走横向联邦；如果两边特征和样本都差异很大，还要做迁移学习，但这类场景难度高、落地少，新手尽量避开。

4.2 数据接入和安全样本对齐

数据接入阶段最容易踩坑。各机构的客户标识必须经过同一套规范化映射，那台负责身份校验的“准出方”尤其关键。我在一个项目里就遇到过：A机构用手机号做ID，B机构用加密后的手机号哈希做ID，两边哈希算法不一致，安全求交一跑，交集率不到预期的一半。只能返工，重新约定哈希盐值和统一的ID归一化规则。

安全求交（PSI）的目的是让参与方只拿到交集样本，不暴露交集之外的数据。实操中必须注意：用于求交的ID字段需要先做加盐哈希，盐值不能明文传输；求交结果也要做二次加密，防止输出阶段被截获。

4.3 联邦统计和特征工程

样本对齐之后进入特征工程阶段。这一步和传统建模很像：要跑分箱、计算WOE和IV值、做特征筛选，只是所有这些计算都在安全协议通道下完成。平台里一般会封装好“联邦分箱”“联合统计”这几个算子，直接拖到画布上配置即可。

这里有个实操技巧：先在小样本子集上跑一遍全流程，确认各参与方的特征分布是否合理。因为多方数据的质量参差不齐，有一方的字段空值率高达60%，直接入模不仅没增益，还会倒灌噪声。很多平台支持“分布式统计直方图”输出，可以快速看到各字段在各方数据上的分布差异，建议每次迭代都跑一下。

4.4 模型训练与效果评估

训练阶段，平台通常会提供联邦逻辑回归、联邦XGB、联邦深度网络等算法。以一个纵向联邦逻辑回归为例，在蚂蚁开源的隐语（SecretFlow）框架里，代码简版如下：

import secretflow as sf # 初始化多方环境 sf.init(['alice', 'bob', 'center'], address='local') alice = sf.PYU('alice') bob = sf.PYU('bob') # 将各自的本地数据包装为联邦数据 v_data = sf.vertical_data({ alice: alice_data, bob: bob_data, }) # 指定标签方为 bob model = sf.app.vertical_logistic_regression( v_data, label_holder='bob', epochs=30, learning_rate=0.1, batch_size=128, ) # 发起训练 model.fit() # 联合评估 metrics = model.evaluate() print(metrics)

这段代码只是示意，但基本能看出共享智能平台“降低难度”在产品层的体现。作为算法工程师，你关心的仍然是模型结构、学习率、batch size这些熟悉的参数，底层用的是MPC还是联邦学习，已经被封装掉了。

模型评估要特别注意和基线模型对比。不要只看联邦模型的AUC，要看它相比“单边模型”的增益到底有多少。如果联合之后KS值只提升了0.01，而通信成本和组织协调成本翻了十倍，那这个项目在业务上就不值得继续推进。

4.5 部署上线与持续监控

模型训练完成不等于项目结束。金融场景里模型要部署到生产环境跑实时推理或批量评分，所以平台需要支持多方环境下的在线推理部署。蚂蚁的做法通常是把训练好的模型参数做安全分发，在各参与方本地环境部署一个推理节点，在线请求时各方本地完成推理，再聚合得到最终评分。

部署阶段还有一个让人头大的问题：模型是联合训练的，上线后如果某一方的特征数据口径发生变化，或者训练数据分布漂移，整体模型效果会断崖式下降。建议在监控面板里同时跟踪各参与方的特征漂移指标、请求成功率、以及评分分布变化，任何一方指标异常都要及时告警。这个问题不做，等于白干。

5. 实战踩坑实录：常见问题排查与避坑指南

5.1 性能慢到不可接受，怎么办

多方安全计算的性能瓶颈主要在通信，不在计算。尤其当参与方分布在不同的机房、不同的云环境，一次聚合可能需要数百次网络往返。我遇到过的一个真实案例：一亿行数据的联邦分箱任务，纯MPC跑了十多个小时，业务方直接吐槽“等结果出来黄花菜都凉了”。

解决思路是混合协议：频繁、低敏感的计算走联邦学习或本地计算；少数关键聚合和统计走MPC。平台可以根据数据字段的安全等级自动选择技术通道，人工干预反而容易配置出错。另外一定要开启通信压缩和数据缓存，中间结果缓存好后再跑二次迭代，能省下不少时间。

5.2 样本对齐结果异常偏低

样本交集率低通常三个原因：ID格式不一致、哈希盐值不一致、或数据时效差异。排查的时候别急着查代码，先找数据方要一份脱敏后的ID样例做肉眼检查。比如A方给的是“13800138000”格式的手机号，B方给的是“+8613800138000”，这两者哈希后完全对不上。统一ID映射规则后，交集率会从40%回到正常水平。

5.3 梯度泄露的风险要提前堵住

别因为底层走了联邦学习就认为数据一定安全。联邦学习传递的参数更新里可能隐含训练样本的信息，恶意参与方甚至可以通过梯度反推某条样本的特征值。缓解办法主要是三招：对梯度做裁剪和差分隐私扰动、使用安全聚合协议把明文梯度加密后再聚合、以及限制参数更新的粒度。

我这边通常建议在参与方和聚合方之间加一层“阈值验证”：只有超过最小样本量的批次才允许参与更新，防止小样本情况下被精准反推。成本不高，但能挡掉大量隐患。

5.4 业务侧反馈“效果不明显”

联合建模不是万能解药。很多时候效果不明显是因为参与方提供的数据字段跟业务目标没有强相关性，或者样本量差异悬殊。另一个常见问题是“标签泄漏”：某一家提供的特征里间接包含了目标变量的强信号，训练时AUC虚高，上线后立刻失效。

对待这类问题，我的经验是先跑“联合模型 vs 最佳单边模型”的增益对比，增量不明显就果断止损。与其硬撑，不如换个场景，把时间和资源投到真正有价值的数据合作上。

几个典型问题的速查对照如下：

5.5 合规配合上的卡点

最后补充一个技术之外却很常见的坑：不同机构对“哪些字段可以参与计算”的标准不一致。有的银行把手机号视为敏感字段，要求全程不出现；有的把交易金额视为极敏感字段，不能参与统计。如果平台没有提供细粒度的字段脱敏和权限管控，合规评审会反复打回方案。

实操建议是：第一次合作尽量用白名单机制，只允许明确列出的字段参与计算；对敏感字段一律先做匿名化和泛化处理；计算结束后提供可导出的审计报告，包含各参与方的数据使用时间、参与算子、输出内容摘要。把这一套走顺了，后续扩大合作范围才会简单很多。

最后说几句实在话

我自己做过多个跨机构联合建模项目，最大的体会是：共享智能不是万能钥匙，它只解决“怎么安全地共享”这件事，根本不解决“共享什么、共享了到底有没有价值”。技术平台做得再好，如果参与方之间的数据贡献不对等、业务目标不一致，项目一样会失败。

如果让我给正在准备启动共享智能项目的团队一个建议，我会说：先找一个能明确量化业务增益的场景做试点，数据样本量不用大，几十万条甚至十几万条都够，把流程跑通、把各方信任建起来，再考虑扩展到全量数据。不要第一次就追求七八家机构的大联盟，那只是在给自己挖坑。

技术选型也是一样，不要被“联邦学习”“多方计算”这些名词绑架。先讲清楚你要解决的是安全的统计、安全的求交，还是安全的建模，再决定用哪套协议，最后再选平台。把时间花在梳理业务逻辑、统一数据口径、确定收益分配机制上，这些才是降低数据共享难度的真正大头。技术，只是把信任变成产品的那一块拼图。