AI 功能验证价值:别只盯着一场 A/B 测试

AI 功能的结果往往由模型、提示词、检索内容、工具调用、上下文、界面和人工兜底共同决定。一个离线分数更高的方案，不一定能带来真实使用价值；一个线上主指标上涨的方案，也不能抵消严重的安全、隐私、延迟或成本问题。

更完整的验证思路是：用不同方法补足不同类型的证据。

第一层：离线评测，先挡住已知的失败

离线评测是在上线前，用有代表性的任务、输入与评分标准，比较模型、提示词、检索策略或工作流。

它适合回答：候选方案是否完成关键任务？输出格式是否合规？引用能否追溯？面对高风险输入时是否应该拒答或转人工？新版本有没有让旧能力退化？

离线评测的优势是可重复、可控制，能把明显不合格的方案留在真实流量之外。但它也有边界：再精心构造的样本，也无法穷尽用户的真实意图、上下文与操作方式。

因此，离线评测不是为了给模型发一张总分成绩单，而是为了定义并守住一项任务的最低质量线。

第二层：线上实验，验证用户是否真的受益

只有当质量和风险门槛基本达标，线上 A/B 或其他受控实验才适合用来验证用户价值。

它要回答的不是“用户觉得回答顺不顺”，而是：用户是否更容易完成原来的任务？是否更愿意采纳结果、减少重试、节省时间或持续使用？与此同时，时延、单位任务成本、投诉和人工升级率是否仍在团队能接受的范围内？

一次可解释的实验，至少要在开始前写清四件事：

1. 面向哪类用户或组织；

2. 改了什么，而不是笼统地说“优化了 AI”；

3. 希望改善哪项用户或业务结果；

4. 哪些护栏一旦恶化就不能扩大。

例如，可以把假设写成：对首次使用知识库问答的用户，在回答下展示来源，预期提高答案采纳；同时，首个有效回答的完成情况和响应时间不能越过预先约定的护栏。

这样做不是为了让实验文档更正式，而是为了避免结果出来后才临时挑选有利指标。

第三层：灰度与监控，让系统继续接受现实检验

有些场景不适合马上做经典 A/B：操作失败的代价很高、客户数量不足、不同用户之间会互相影响，或者团队刚进入一个还不了解的新环境。

这时可以缩小范围，设置人工确认、回滚和审计日志，结合抽样审核、反馈与异常监控逐步积累证据。NIST 的 AI 风险管理框架强调，AI 系统不仅应在部署前接受测试，也需要在运行中持续测试和监控，并保留测试集、指标、方法和结果等记录。

这意味着上线不是一次最终考试，而是把系统放进真实环境后的下一轮学习。

把“模型好不好”翻译成“任务有没有成功”

如果目标只写成“提高回答质量”，后面的指标几乎无从设计。团队需要先回到用户任务。

会议纪要助手的目标，未必是摘要写得流畅，而是让参会者能快速确认决定、待办与责任人；客服助手的目标，也不只是像人一样对话，而是帮用户找到正确路径，同时避免错误承诺。

任务被说清后，评估才有落点：哪些输入必须覆盖？什么输出算成功？哪些错误绝不能接受？哪些可以自动判断，哪些必须由业务专家审核？

我会把这类指标分为三层：

• 任务质量：完成情况、事实准确性、引用可追溯性、格式合规、恰当拒答等。具体指标必须随任务变化。

• 用户价值：采纳、减少重试、完成时长、持续使用等，验证用户是否真的更容易完成目标。

• 系统与风险护栏：时延、错误、单位成本、隐私与安全事件、人工升级、投诉或申诉等，防止主指标掩盖不可接受的副作用。

质量不过线时，不该进入线上；用户价值没有改善时，不能只因模型分数更高就扩大；护栏失守时，也不能用增长指标冲淡风险。

ToB 还是 ToC，关键不在标签，而在实验条件

“ToC 做 A/B，ToB 做访谈”是过度简化。两类产品都可能需要定量与定性证据，真正要判断的是：改动影响的范围是什么？随机化单位应该是什么？样本量和干扰条件是否支持可信比较？

如果同一工作区成员共享知识库、权限、配置或协作结果，按个人分流可能使实验组和对照组互相影响。这时，团队可能需要按工作区、团队或租户设计实验。Microsoft 对租户随机实验的研究就讨论了单位数量更少、客户差异更大时的统计挑战。

这个案例并不等于“企业产品不能做 A/B”。它提醒我们：当随机对照不可行或证据不足时，要诚实说明当前能得到的是哪一种证据，并用离线任务集、试点数据、客户回访、人工审核或灰度监控补足最重要的不确定性。

让失败样本回到下一轮设计

AI 系统上线后，总会遇到评测集中没有出现过的输入、意图和失败方式。用户反馈、人工审核、客服工单与异常日志不该只用于救火，也应回流到下一轮评测与产品设计。

可以把这条闭环记成：

真实使用中的失败 → 评估影响并确定责任人 → 加入评测或红队样本 → 比较候选方案并设置门槛 → 小范围验证价值与护栏 → 持续监控。

它最终帮助团队回答的，不只是“哪个模型更好”，而是：什么任务值得交给 AI，哪些失败可以接受，在哪些地方必须由人接手。

下次讨论“要不要做 A/B”时，可以先问一句：我们此刻缺的到底是质量证据、用户价值证据，还是生产风险证据？ 方法选对了，实验才会成为决策工具，而不只是报告里的一个数字。