谷歌将全同态加密引入 AI 推理流程后数据隐私将由协议约束转变为数学硬约束

在探讨 AI 推理的隐私保护手段时，传统的脱敏技术或差分隐私往往需要在数据精度与隐私强度之间进行权衡。为了达成真正的“数学硬约束”，将全同态加密（FHE）集成到推理流程中是一种有效的路径。FHE 的核心在于支持模型直接在密文状态下开展计算，且解密后的结果与明文计算所得完全一致。这种机制确保了服务端在处理数据时无需掌握私钥，从而无法窥探原始数据的真实内容。

FHE 的工程实现逻辑与传统的“加密-传输-解密-计算”模式截然不同，它构建了一个完整的闭环：首先由客户端利用公钥将原始数据 $m$ 加密为密文 $c = Enc(m)$；接着服务端在不执行解密操作的前提下，直接对密文进行函数运算 $f(c)$；最后服务端将运算得到的 $c'$ 返回给客户端，由客户端通过私钥解密得到 $m' = Dec(c') = f(m)$。

如何根据运算需求选择 BFV 或 CKKS 方案？

针对不同的 AI 推理场景，底层数学方案的选择将直接影响计算精度与适用性。若业务需求侧重于整数运算，BFV 方案是合适的选择；但考虑到 AI 模型推理中存在大量的浮点数运算，则必须采用 CKKS 方案。这两者的参数配置存在显著差异，一旦选型错误，会导致计算结果彻底失效。

参数配置对同态乘法精度有何影响？

虽然谷歌的完整方案尚未实现全面开源，但通过使用 C++ FHE 库进行复现可以发现，参数配置是工程部署中最关键的决策。配置不当会导致在执行同态乘法后，解密结果出现严重的精度偏差或直接报错。

在初始化同态加密环境时，一个关键的参数配置示例是将 poly_modulus_degree（多项式模度）设定为 8192，并配合相应的 coeff_modulus 和 plain_modulus（例如 65537）。在实操中需要特别注意两个问题：一是噪声累积问题，当 poly_modulus_degree 设置过低时，计算过程中的噪声会快速堆积，导致多次乘法运算后的解密结果出错，此时需通过增加模度或执行 relinearization（重线性化）来控制噪声；二是性能损耗问题，虽然提高 poly_modulus_degree 可以增加计算深度，但也会明显拖慢计算速度，在追求毫秒级响应的推理场景中，必须在两者之间寻求平衡。

FHE 在隐私保护上是否优于传统脱敏协议？

对比来看，传统的隐私协议（如法律协议或简单脱敏）本质上是建立在“信任”基础之上的，而 FHE 则是建立在“数学”基础之上的。在金融或医疗等高度敏感的领域，FHE 能够将数据的所有权真正归还给用户。即便云端服务商拥有极强的算力，在面对加密数据时也只能处于“盲计算”状态，即仅提供计算服务而无法触达数据内容。