如何构建可复用且保护隐私的端侧 AI 测试夹具

直接回答

测试夹具是一个受控示例，用于在代码变化后再次走一遍输入路径并检查结果。对端侧 AI 来说，夹具不只是一个文本提示：它还可能包含图片或音频来源、数据许可和同意记录、预处理版本、任务指令、期望属性以及人工审查规则。如果其中某项悄悄改变，前后结果就不再能够比较。项目事实卡强调可复现工作负载和保护隐私的记录；夹具正是落实这两点的地方。 不同问题要使用不同类型的夹具。解析器测试可以用结构固定的合成 JSON；OCR 测试可以用自制或获许可的图片及经核对文字；音频夹具可以包含取得同意的录音、时间点和转写标注。基准样例可以追求代表性，边界样例则专门覆盖空输入、超长内容、混合文字系统或畸形值。不要把所有例子混在无标签目录中，也不要把少数人工挑选的“顺利样例”说成完整质量集。 每个夹具应有稳定 ID、版本、来源、许可或同意记录、输入摘要、预处理版本、期望属性和保留责任人。摘要有助于发现意外更改，却不能替代来源记录。不要把用户内容放入源码、截图、公开 issue 或 CI 日志。尽可能使用合成内容。若验证特性必须用真实媒体，应尽量缩小范围、取得许可、限制访问并设定删除期限。仅改掉文件名，并不能让可识别的声音或照片自动适合公开。 断言要选在合适层级。解析器接受已知结构等确定性转换，可以比对精确结果。模型生成可能变化；只有在确有理由时才做逐字比较，其他情况应检查属性，例如指定实体是否保留、输出是否符合结构、引用是否指向提供的片段、回答是否越过声明的安全边界。人工评审要使用明确评分表，记录问题、预期行为、允许替代答案和严重程度。不能为了让测试通过就直接把预期答案改掉；变更须有人审查并形成新版本。 测试夹具应与用户状态隔离。测试不能上传私人内容、修改用户保存的笔记，或留下临时模型文件。只记录夹具 ID 和结果，而不是私人字节。若测试需要较大模型制品，单独固定制品修订和完整性证据，不要与夹具版本混为一谈。预处理算法改变应产生新的管线版本，否则回归就可能被误认为模型变更。 有意识地结合复现性和覆盖面。重复跑同一夹具能发现某些回归，却不能涵盖所有语言、光线、噪声、格式和用户意图。按任务、输入模态、失败边界、适用语言/文字系统及期望结果维护覆盖表。发现真实缺陷后可以新增夹具，但需清理其中数据并解释它覆盖哪种行为。日常测试保留小型冒烟集，发布判断另用更全面的审查集。没有采样计划时不能声称覆盖有代表性。 夹具治理还要进入代码审查。评审者应检查来源、许可、访问范围、保留期限、预期属性理由和版本变化。CI 只输出夹具 ID、版本及成功/失败，不打印敏感输入。若许可到期或来源撤回，应从执行集合移除，并说明历史记录如何处理。高质量夹具集是受管理的数据，不是随时间无人负责地堆积文件。 这个过程产出的是可审计的测试语料，不是现实世界准确率保证。项目 RAG-01 和 benchmark 事实支持来源追踪与可复现方法，但不证明样例覆盖所有用户，也不证明某个模型具备普遍能力。结论只能适用于实际运行过的夹具、预处理、制品、runtime 和评审规则。想扩展范围，需要新增证据，而不是把样例通过等同于所有场景正确。 夹具版本应与结果一并保留。若只更新一个图片裁剪、音频片段或期望属性，应给出变更原因并让评审者确认旧结果是否还能比较。可以把不可变输入保存在受控仓库，将描述信息和脚本与应用代码一起版本化，但不要在公开 repo 留下取得授权不明的数据。跨团队共享时，先确认使用范围与删除责任，否则即使输入已匿名也可能越权复用。 最后，评估失败也要有稳定表示。测试结果可以是通过、拒绝、输出格式无效、信息遗漏、夹具损坏或环境异常；这些类别不能都叫“模型低质量”。恢复动作也不同：夹具坏了需修复测试数据，解析失败应查格式约束，内容缺失才进入模型任务复核。记录具体失败类型，可避免团队用扩大样例或更换模型来掩盖测试基础设施问题。

提示改动似乎修复了文档摘要回归

团队重跑少数从客服工单复制的文档，但每次文件内容不同，也没人知道哪个预处理版本生成了预期摘要。

决策

用治理完善的夹具替代真实用户记录，固定输入、预处理、期望属性和版本。

预期结果

测试可重复运行，不泄露用户内容，也不会悄悄改变通过答案的含义。

需要收集的证据

只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：

• BENCHMARK-01：可复现结论需固定工作负载并保留方法证据；夹具变更应具有版本。
• RAG-01：涉及检索或引用时，应验证输入来源和可追溯路径，不能只判断语言流畅度。

发布结论只对所记录的配置和验收集有效；扩大适用范围需要更多记录。

实施流程

1. 为单一测试问题选定夹具. 标明示例用于解析、模型行为、OCR、音频、检索还是边界测试，并区分代表性集合、压力场景与日常冒烟样例。
2. 记录来源与许可依据. 给每个夹具设 ID、版本、来源/许可或同意、输入摘要、保留规则、预处理修订和负责续期或删除的人员。
3. 运行前定义期望属性. 只有有理由时才要求逐字匹配；否则记录必需字段、事实保留、允许替代、拒答边界与人工评分规则。
4. 隔离执行并避免修改用户数据. 使用隔离账户和存储。日志仅留夹具标识与结果；模型制品独立固定，测试不能接触或上传真实用户字节。
5. 将期望变化作为数据审查. 缺陷修复改变预处理或行为时，创建新版本并写明理由。不要为消除红色测试而直接改掉预期答案。

让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。

验收标准

• 每个夹具均有来源、许可/同意、版本、预处理身份和保留责任人。
• 仅在理由充分时使用精确答案；生成变化通过已审查、可测试的属性进行判断。
• CI 只暴露夹具标识和结果，不打印提示、图像、音频或私人文档正文。
• 夹具或管线变化形成可审计的新版本，不静默重写旧测试含义。

决策对照表

需要避免的失败模式

• 把支持工单或真实用户媒体直接复制进仓库和 CI。
• 每次模型输出变化都随手更新 golden answer，让测试不再捕捉真实回归。

还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。

最小复现记录

发布检查表

• ☐ 主要搜索问题已回答，且没有未经支持的数字。
• ☐ 所有模型文件和运行时版本均已固定。
• ☐ 代表性任务和失败处理策略均有说明。
• ☐ 生命周期、取消、清理和回退均已测试。
• ☐ 用户内容与网络边界均有说明。
• ☐ 结论只适用于被记录的配置。
• ☐ 新增测试结果时链接到原始方法或证据。

来源与相关证据

• Cove 基准测试方法
• Android 测试基础概念
• Android 测试替身与受控依赖

中文部署与排错专题见。奇连 AI 端侧专题。

常见问题