数据不出库，也能一起算？我用隐私计算做了一次跨机构联合分析，终于明白它为什么火了
作者：Echo_Wish
这两年，大模型很火，数据要素也很火。
很多企业都开始意识到：数据本身已经成为生产资料。
但现实却很尴尬。
医院有医疗数据，银行有金融数据，保险公司有理赔数据，运营商有通信数据……
如果这些数据能够联合分析，很多事情都会变得更精准。
比如：
- 银行可以更准确识别欺诈用户；
- 医院可以联合多个医疗机构训练疾病预测模型；
- 多家制造企业可以一起分析供应链风险；
- 多个政府部门可以共同发现异常企业。
问题来了。
谁敢把自己的数据发给别人？
没人敢。
数据泄露怎么办？
商业机密怎么办？
法律合规怎么办？
于是，一个看起来几乎不可能完成的问题出现了：
数据不能共享，但计算必须共享。
而这，就是近几年越来越火的——隐私计算（Privacy Computing）。
今天，我们就聊聊工程里面真正落地最多的两种方案：
MPC（Multi-Party Computation，多方安全计算）
HE（Homomorphic Encryption，同态加密）
很多文章都讲概念，但真正做项目的人，更关心：
它到底怎么写？性能怎么样？什么时候该用？
今天，我们就从工程角度聊聊。
为什么传统的数据共享越来越难？
假设现在有三家医院。
医院A
患者数据：100万
医院B
患者数据：80万
医院C
患者数据：60万
如果把三家数据放一起。
预测癌症模型的准确率可能提升：
83%
↓
91%
但是现实里面。
医院A说：
我的数据不能出院。
医院B说：
我的数据涉及患者隐私。
医院C说：
法律不允许。
于是项目直接黄了。
真正的问题其实不是算法。
而是：
数据不能移动。
所以后来整个行业开始转变思路：
以前：
数据 → 算法
现在：
算法 → 数据
甚至进一步变成：
数据不动
计算流动
这就是隐私计算最大的思想。
MPC：大家一起算，但没人知道别人的数据
MPC可以理解成一句话：
参与计算，但不知道别人输入了什么。
举个最简单的例子。
三家公司想统计总销售额。
公司A
1000万
公司B
3000万
公司C
5000万
任何一家都不愿公开销售额。
怎么办？
MPC里面会把数据切成很多"秘密份额（Secret Share）"。
例如：
1000
↓
200
300
500
分别发送给不同节点。
任何一个节点看到的数据都是残缺的。
最后所有节点一起计算：
1000
+
3000
+
5000
=
9000
大家只知道：
9000
不知道：
1000
3000
5000
是不是很神奇？
这就是秘密共享（Secret Sharing）。
Python模拟一个简单的秘密共享
下面只是演示思想，不是真正生产算法。
import random
def secret_share(secret):
share1 = random.randint(1, 100000)
share2 = random.randint(1, 100000)
share3 = secret - share1 - share2
return share1, share2, share3
secret = 1000
shares = secret_share(secret)
print("Share:", shares)
recover = sum(shares)
print("Recover:", recover)
输出：
Share:
(29483,
10593,
-39076)
Recover:
1000
真正工程里面当然不是这样简单。
通常采用：
- Shamir Secret Sharing
- SPDZ
- ABY
- MP-SPDZ
但原理基本一致：
任何一个参与者拿到的数据都没有意义。
MPC为什么越来越受欢迎？
因为它特别适合：
联合统计
联合建模
联合风控
联合画像
联合反欺诈
例如：
银行
+
运营商
+
电商
三方一起识别黑产。
没人需要交换用户信息。
却能得到共同结果。
这就是很多大型金融机构正在做的事情。
HE：数据一直都是加密状态
如果说MPC解决的是：
大家一起算。
那么HE解决的是：
数据一直是加密的。
什么意思？
普通加密：
加密
↓
不能计算
↓
必须解密
HE：
加密
↓
直接计算
↓
最后再解密
整个计算过程中：
没有任何明文。
这就是同态加密。
例如：
5
↓
Encrypt(5)
8
↓
Encrypt(8)
服务器执行：
Encrypt(5)
+
Encrypt(8)
=
Encrypt(13)
最后用户自己解密：
13
服务器从头到尾不知道：
5
8
13
这就是HE最大的魅力。
Python演示一个简单HE示例
真实项目一般使用微软SEAL、OpenFHE等库。
下面演示使用 TenSEAL 的基本思路。
import tenseal as ts
# 创建上下文
context = ts.context(
ts.SCHEME_TYPE.CKKS,
poly_modulus_degree=8192,
coeff_mod_bit_sizes=[60, 40, 40, 60]
)
context.generate_galois_keys()
# 加密数据
a = ts.ckks_vector(context, [5])
b = ts.ckks_vector(context, [8])
# 密文直接计算
c = a + b
print(c.decrypt())
输出：
[13.0]
整个过程中：
服务器不知道：
5
不知道：
8
也不知道：
13
MPC和HE到底怎么选？
很多人第一次接触时，总觉得两者是竞争关系。
其实不是。
更准确地说，它们各自擅长不同场景。
| 场景 | MPC | HE |
|---|---|---|
| 多机构联合计算 | ⭐⭐⭐⭐⭐ | ⭐⭐ |
| 单方云计算 | ⭐⭐ | ⭐⭐⭐⭐⭐ |
| 计算速度 | ⭐⭐⭐⭐ | ⭐⭐ |
| 通信开销 | 较高 | 较低 |
| CPU消耗 | 中 | 很高 |
| 实际工程成熟度 | 很高 | 正在快速成熟 |
我的经验是：
多机构协同优先考虑MPC；单方把敏感数据交给云端处理，更适合同态加密。
如果既有跨机构协作，又要在云端进行部分安全推理，那么混合架构往往能兼顾安全与效率。
真正落地时，最大的难点不是算法，而是工程
很多人觉得隐私计算最大的挑战是密码学。
其实真正做项目以后会发现：
真正耗时间的是下面这些。
第一：
参与方网络质量。
MPC需要不停通信。
如果：
北京
上海
广州
香港
四地互联。
网络延迟直接影响性能。
很多项目最后都是网络先成为瓶颈。
第二：
数据标准统一。
A医院：
gender
B医院：
sex
C医院：
GenderCode
算法根本跑不了。
真正耗时的是：
数据治理
而不是：
MPC
第三：
密钥生命周期管理。
HE最大的坑就是：
密钥管理
包括：
- 密钥生成
- 密钥轮换
- 密钥托管
- 权限控制
- 审计追踪
很多团队算法写得很好。
结果：
密钥泄露。
整个系统直接失效。
第四：
性能优化。
很多人第一次跑HE都会被速度吓一跳。
普通计算：
2ms
HE：
500ms
甚至：
2秒
因此工程里面一般不会把所有逻辑都放进HE。
通常会采用：
普通计算
+
HE
+
MPC
+
TEE（可信执行环境）
组成混合计算架构。
只有真正涉及敏感数据的部分才进入隐私计算流程，其余计算依然走传统高性能链路，这样才能兼顾安全与吞吐量。
我的一点思考
很多人认为：
隐私计算就是一种新的加密算法。
我并不认同。
在我看来，它更像是一场数据协作方式的变革。
过去，我们默认"共享数据才能共享价值"；现在，我们越来越倾向于"共享计算能力，同样可以创造价值"。
未来，越来越多的数据不会离开自己的"领地"，但模型、算子和计算任务会主动靠近数据。数据所有权依旧清晰，价值却能够跨组织流动。
当然，我们也不应该神化隐私计算。它并不是万能钥匙。
如果数据质量差、口径不一致、治理混乱，再先进的MPC、HE也无法算出有价值的结果；如果业务流程缺乏信任机制，再安全的密码学协议也无法解决组织之间的协作问题。
真正成熟的跨机构联合分析，往往需要数据治理、权限控制、审计追踪、密码学技术和业务规则共同配合，缺一不可。
所以，我始终认为，隐私计算不是为了让数据"藏起来"，而是为了让数据能够在不暴露隐私的前提下，更安全、更高效地流动。
当越来越多企业开始把数据视为资产而不是负担时，隐私计算的价值才会真正显现。未来的数据合作，不一定是"把数据给我"，更可能是："数据留在你那里，我们一起把答案算出来。"
这或许就是数据要素时代最值得期待的一种合作方式。
