WhatsApp 正在有限范围内测试 Scam Alert：当陌生联系人发来消息时，端侧机器学习模型会判断其中是否存在潜在诈骗风险。这个方案值得关注的地方不只是“把模型放进手机”，而是如何在消息内容留在设备上的前提下，完成模型效果评估、遥测统计和模型交付。
根据公开摘要，这套架构组合了端侧推理、机密计算、Oblivious HTTP、差分隐私和模型透明度。它展示了一种更完整的隐私工程思路：不仅保护输入数据，还要控制元数据、统计结果以及模型分发过程可能暴露的信息。
为什么诈骗检测适合在设备上运行
诈骗消息通常包含紧迫催促、索要验证码、虚假退款、异常链接或冒充身份等信号。云端分类服务当然可以识别这些模式，但它要求客户端把待检测内容发送给服务器，这与“消息内容留在设备上”的目标直接冲突。
端侧推理改变了数据流：
- 消息进入用户设备。
- 本地模型读取文本并计算风险分数。
- 客户端根据阈值决定是否展示 Scam Alert。
- 原始消息不因检测任务而上传到分析服务。
将范围限定在“非联系人消息”也很关键。它既贴近诈骗的高风险入口，又能减少模型扫描范围和误报造成的干扰。不过，非联系人并不等于诈骗者，联系人也不等于可信来源，所以联系人状态只能作为触发条件或风险特征，不能成为最终结论。
端侧运行同样不是免费的。移动设备的内存、耗电、模型包大小和推理延迟都有硬约束；模型还可能因语言、地区表达和新型骗局发生漂移。工程团队必须在召回率、误报率、模型体积和响应速度之间做取舍。
四层隐私机制分别解决什么问题
这些技术不能互相替代，它们保护的是不同环节。
端侧机器学习：隔离消息正文
模型在设备上执行，意味着分类服务不需要接收消息正文。这是数据最小化的核心，但仍需检查日志、崩溃报告、调试接口和缓存文件，避免正文通过旁路泄露。
Oblivious HTTP：降低请求与用户身份的关联
Oblivious HTTP 通常通过中继拆分网络身份和请求内容。中继可能看到客户端网络信息，却不应同时看到完整业务请求；后端处理方可以看到请求，但难以直接获得原始客户端地址。
它解决的主要是传输关联问题，而不是自动匿名化所有数据。如果请求中仍携带稳定设备标识、精确时间戳或罕见属性，后端仍可能重新关联用户。
差分隐私：限制聚合指标泄露个体信息
产品团队仍要知道模型是否有效，例如警报触发率、用户反馈比例或不同模型版本的总体表现。差分隐私可以通过随机化或噪声机制，限制单个用户对统计结果的影响。
这里需要区分“消息不上传”和“完全不上传数据”。隐私保护遥测仍可能发送经过随机化的统计信号，只是它不应包含原始消息，并且要受到隐私预算、保留周期和最小聚合规模约束。
机密计算与模型透明度：约束服务端和模型交付
摘要还提到机密计算和模型透明度，用于支持性能测量并保护模型交付。机密计算可以让敏感处理发生在受保护的执行环境中，但其可信度依赖远程证明、密钥管理、运行代码审计和基础设施配置。
模型透明度则应让模型版本、来源和更新状态具备可验证性。它不能直接证明模型没有偏差，却能降低客户端收到未授权模型或无法追踪版本的风险。具体实现细节未在摘要中展开，因此不宜把某一种证明协议视为 WhatsApp 已确认采用的方案。
可以这样实践：本地检测加随机响应遥测
下面是一个可直接运行的 Python 原型。它不是 WhatsApp 的实现，也不代表其真实模型；这里用关键词规则代替机器学习模型，用随机响应演示本地差分隐私。程序只输出模型版本和随机化后的一个比特，不输出消息正文。
将 MESSAGE 和 IS_CONTACT 改成测试数据，然后运行脚本：
import json
import math
import random
MESSAGE = 'Your account is locked. Send the verification code now.'
IS_CONTACT = False
EPSILON = 1.0
MODEL_VERSION = 'demo-2025-01'
RISK_TERMS = (
'verification code',
'send money',
'account is locked',
'urgent payment',
'gift card',
)
def detect_locally(message: str, is_contact: bool) -> bool:
if is_contact:
return False
normalized = message.casefold()
matches = sum(term in normalized for term in RISK_TERMS)
return matches >= 1
def randomized_response(value: bool, epsilon: float) -> bool:
if epsilon <= 0:
raise ValueError('epsilon must be positive')
truthful_probability = math.exp(epsilon) / (math.exp(epsilon) + 1)
if random.random() < truthful_probability:
return value
return not value
potential_scam = detect_locally(MESSAGE, IS_CONTACT)
private_report = randomized_response(potential_scam, EPSILON)
telemetry = {
'model_version': MODEL_VERSION,
'reported_alert': int(private_report),
}
print('Show local warning:', potential_scam)
print('Privacy-preserving telemetry:', json.dumps(telemetry))
运行命令：
python3 scam_alert_demo.py
随机响应会以一定概率翻转真实结果。若真实发送概率为
p = exp(epsilon) / (exp(epsilon) + 1)
服务端可以从大量报告中估算总体触发率，却无法把单条报告直接当作某台设备上的真实判断。epsilon 越小，单个报告的隐私保护通常越强，但聚合结果需要更多样本才能稳定。
生产系统还需要增加批量上传、时间模糊化、最小样本门槛、隐私预算记账和数据过期策略。Oblivious HTTP 也必须由实际的客户端、中继和网关实现，不能靠上述 Python 脚本中的随机化代替。
上线前应检查的边界
端侧诈骗检测不应被描述成“识别诈骗的最终裁决器”。攻击者会主动修改措辞、插入 Unicode 字符、使用图片或语音，也可能通过正常对话逐步建立信任。模型警报应该提供谨慎提示和可撤销操作，避免直接阻断合法消息。
落地时可以重点检查以下项目：
- 原始正文、链接和附件特征是否会进入日志或崩溃报告。
- 模型是否覆盖主要语言、混合语言和低端设备。
- 警报阈值是否分别评估误报率与漏报率。
- 遥测事件是否包含可重新识别用户的稳定字段。
- 差分隐私预算是否按用户、时间窗口和指标进行约束。
- 模型更新是否具备签名、版本回滚和可验证交付机制。
- 用户是否能理解警报只是风险提示，而不是确定结论。
WhatsApp 的测试说明，隐私保护型机器学习并不是单独选择一个“端侧模型”就结束了。真正困难的是把推理、传输、统计和模型供应链一起纳入威胁模型，并明确每一层技术能保护什么、不能保护什么。