第一次接手AI反诈项目：传统功能测试为什么很快就不够用了？

摘要：以Meta公开的WhatsApp端侧Scam Alert架构为事实起点，拆解端侧AI既要识别诈骗又不能扩张消息用途的测试难题，给出数据出境、模型完整性、实验分流、透明日志、对抗样本与持续评测方案。

用户收到一条“快递丢失，点击链接领取赔偿”的消息。手机上的反诈骗模型判定风险较高，弹出提醒。功能看起来很简单，但测试团队马上会遇到两组互相拉扯的问题：如果模型看不到足够内容，诈骗识别可能变差；如果为了评测把消息、标签和反馈上传云端，隐私边界又可能被悄悄扩大。

Meta公开的WhatsApp Scam Alert方案把模型放在设备端运行，并明确表示消息内容不会为了分类离开设备，也不会自动上报。它还披露了模型制品签名、公开透明账本、设备侧活动日志、隐私保护的实验机制，以及在Beta前让外部研究人员核验隐私架构和模型用途。

这篇实践最值得测试团队学习的，不是“端侧模型”四个字，而是它试图回答一个更困难的问题：用户怎么知道安装到自己手机上的模型就是公开声明的版本？团队怎么评估准确率而不收走原始私聊？实验怎么随机分流，又不变成针对某个具体用户投放特殊模型？

本文把这些问题落成一套可执行的端侧AI测试框架，帮助普通团队同时证明效果、隐私、模型完整性和可追责性。

第一个陷阱：没有请求接口，不代表没有数据离开

很多验收只抓分类API，发现没有上传正文就宣布通过。真实App还可能通过崩溃日志、分析埋点、截图反馈、诊断包、剪贴板、通知预览和第三方SDK泄露内容。模型输入可能没走“业务接口”，却被错误日志完整记录。

因此要从数据流而不是接口名出发。列出消息从存储、解密、特征处理、模型推理、提醒展示到日志清理的生命周期。每一跳记录数据形态、所在进程、保存时长、是否落盘、是否可能被系统备份。

测试时用可识别的金丝雀文本，例如一串只出现在测试消息里的随机标识。触发正常推理、模型崩溃、低内存、切后台、用户截图、提交反馈等路径，再扫描网络包、日志、缓存和诊断文件。如果标识出现在声明之外的位置，哪怕分类结果正确也必须失败。

第二个陷阱：下载到端侧的模型可能不是你以为的模型

App版本没变，模型却可能独立更新。CDN缓存、灰度实验、回滚和供应链问题都可能让不同设备拿到不同制品。只记录“模型加载成功”，无法回答某条提醒到底由哪个版本产生。

更可靠的链路是：每个模型制品有哈希；哈希写入签名清单；客户端校验签名和适用范围；推理Trace记录model_hash与policy_version；用户或审计人员能查询某时刻设备使用的版本。

可以把安装门禁写得很朴素：

def verify_model(artifact, manifest, device):
    assert sha256(artifact) == manifest["model_hash"]
    assert verify_signature(manifest)
    assert device.region in manifest["allowed_regions"]
    assert manifest["purpose"] == "scam_detection"
    assert manifest["expires_at"] > now()

这段代码不评价模型聪不聪明，只确保“被评过的那一个”才有资格运行。

第三个陷阱：隐私实验也可能形成定向能力

模型需要灰度，否则一次错误升级会影响全部用户。但如果服务端能让某个指定用户下载特别版本，就存在定向投放风险。Meta公开方案强调，实验流量的设计不能形成“给某个具体用户指定模型”的通道，实验版本也要进入公开可核验的制品记录。

测试要覆盖：同一实验桶是否稳定；换账号、设备和网络后是否出现不应有的定向；实验服务能否绕过签名；紧急回滚是否回到已知制品；实验结束后旧模型是否清理；实验版本是否同样遵守用途声明。

这里的核心不是A/B平台能不能分流，而是分流权力有没有被限制和留痕。

准确率评测为什么不能把隐私问题外包给数据团队

诈骗样本天然包含电话号码、关系、转账信息和语境。直接把真实消息集中到云端标注，会让“为了保护用户”成为新的数据收集理由。团队需要先定义最小评测数据：可以用合成消息覆盖套路，用自愿提交与严格脱敏样本验证真实分布，用端侧聚合统计观察整体效果。

效果指标也不能只有precision和recall。误报会让用户习惯性忽略提醒，漏报会造成损失；特定语言、年龄群体或地区的错误分布可能不同。建议至少分层查看诈骗类型、语言、是否包含链接、联系人关系、模型版本和提醒后的用户动作。

同时设隐私预算：原始消息离端率必须为零；诊断包敏感标识出现率为零；端侧日志保留期符合规则；聚合统计低于人数阈值不出报表；任何新增字段都要说明它支持哪项质量判断。

Behavioral Evaluation要测“提醒之后发生了什么”

最终分类只是Outcome。真正的行为链包括：消息到达、模型选择、置信度、是否展示提醒、用户选择、是否误触链接、是否上报、日志是否可见。测试要断言模型低置信度时不会使用过度确定的话术，也不会自动替用户删除消息或举报联系人。

准备四组样本：典型诈骗；正常但包含付款词的家人对话；刻意规避关键词的社会工程；混合语言和图片文字。每组再叠加模型更新、离线、低电量、权限变化和旧设备，观察结果与副作用。

可验证不等于把所有内部细节公开

用户不需要看到模型全部权重和每一步计算，但应能知道三件事：哪一个版本做了判断、是否真的只在设备内处理、提醒历史能否由本人查看。外部研究者则需要更强证据，例如可获取制品、检查网络流、验证签名和测试用途越界。

测试报告可以按五层组织：数据没有离开声明边界；制品与公开记录一致；模型只完成声明用途；实验不能针对个人；用户和研究者拥有可复核证据。任何一层缺失，都不能用“端侧”两个字代替。

回归集怎样随诈骗变化而长大

诈骗套路会演化，固定题库很快失效。线上只回传聚合或用户主动反馈时，要保留来源与同意状态；新样本进入人工复核，拆成语言变化、链接伪装、身份冒充、紧迫感和多轮诱导等标签。模型更新后既跑新套路，也跑历史正常对话，避免追新时扩大误报。

Continuous Evaluation可以分三层：离线样本看识别与公平；端侧自动化看数据流和制品；小流量Beta看真实提醒后的行为。上线门禁不是某一个分数，而是一组不能互相抵消的约束。

普通团队可以复制什么

你不需要做全球通信产品。选一个本地OCR、端侧敏感内容检测或语音唤醒功能：给模型制品加哈希与签名；用金丝雀扫描所有出站与日志；给每次判断记录本地版本；设计一个不可定向到个人的灰度桶；让用户能查看和清除自己的活动记录。

这五步会让“我们重视隐私”变成可测试证据。

端侧AI真正难的，从来不是把模型文件塞进安装包，而是让效果评估、灰度升级和问题追踪都不反过来破坏最初的隐私承诺。测试工程师要守住的不是一个接口，而是数据用途边界。模型可以更新，诈骗会变化，但用户为什么把消息交给这个功能，必须始终能被证明没有改变。

端侧模型还要面对设备差异

同一个模型在不同芯片、系统版本和量化配置上，可能走不同算子或精度。旧设备为了性能启用更激进量化，边界样本的置信度可能改变；低内存时模型加载失败，应用又可能静默切到规则或云端兜底。

设备矩阵不必覆盖所有型号，可以按CPU/GPU/NPU、内存档位、系统大版本和语言包做代表性组合。每次记录实际执行后端、量化版本、推理耗时、峰值内存与降级路径。若端侧失败后改走云端，必须重新获得符合声明的授权，不能把“保证可用”当成数据出端的后门。

误报的业务后果需要单独评估

诈骗提醒不是普通分类标签。对家人转账、二手交易和小商家收款的误报，会伤害信任；频繁提醒还会产生告警疲劳。评测应模拟同一用户一周内收到多次提醒，观察是否开始无视，提醒文案是否把“可能风险”写成“对方就是骗子”。

可以把后果拆成三档：提示但不阻断；增加一次确认；禁止操作。模型置信度只能决定候选风险，最终动作还要结合场景与确定性规则。涉及支付或账号变更时，最好让用户看见可理解证据，例如陌生链接、催促转账或身份信息不一致，而不是只显示一个神秘分数。

怎样验证“模型只做声明用途”

用途越界往往不会表现为网络请求。一个诈骗模型也可能意外学会推断关系、职业或敏感属性。测试准备与诈骗无关但包含这些信号的对照数据，检查输出接口是否暴露额外标签，内部日志是否记录不需要的推断，模型是否可被提示诱导完成其他分类。

若外部研究者能获取模型制品，可设计purpose probing；产品侧则检查接口只返回最小结果，禁止其他团队复用中间特征。用途限制既是政策，也是接口与组织权限问题。

出现争议时如何还原

因为不上传原始消息，客服不能像云端系统那样直接查看上下文。设备侧活动日志需要保存时间、模型版本、是否触发、是否展示和用户选择，但不保存消息正文。用户可主动导出相关片段并决定是否提交。

测试一个完整争议流程：用户申诉误报、导出本人记录、选择性提供消息、团队定位版本、加入脱敏回归、发布修复、用户设备验证更新。这个闭环能证明隐私保护没有让质量问题变得无法修复。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。