用百条标注样本建立AI功能验收基线

AI 功能到底能不能上线，不能只看几次演示是否顺眼。作者建议先准备约 100 条来自真实业务、已经确认正确答案的样本，把它们作为固定验收集，每次修改 prompt、模型版本或阈值都重新跑一遍。

这套方法的价值在于，让团队围绕同一批失败案例讨论。但 100 条样本只能提供初步警报，不能证明系统已经可靠。对正在给产品接入 AI 的程序员，这是一套成本较低、可以直接落地的验收办法。

为什么从 100 条开始，又不能迷信 95 分

作者把这批样本称为黄金集（golden set）：固定的真实输入，加上团队认可的正确答案。

约 100 条适合起步，有两个直观原因：错一条，分数就下降一个百分点；失败数量也还少到可以逐条人工检查。第一版追求的是团队能看懂、能复查的测量结果，不是统计上的完美。

但样本少，分数的不确定性就大。原文提醒，测得 95% 的正确率，真实水平仍可能大致落在 89% 到 98% 之间。原文没有交代这个区间的计算方法，也没有展示实际项目的测试数据。

100 条样本适合发现回归，不足以单独担保上线质量。

验收文档应写清这一限制，功能成熟后再逐步扩大样本规模。

样本怎么选，才不会只测出一个漂亮平均分

样本应来自实际业务流程，不能全靠开发者临时编题。作者要求同时覆盖几类输入：

• 常见情况应占大多数，比例尽量贴近实际出现频率。
• 普通变化要包括不同措辞、格式、语言和拼写错误。
• 已知难例要覆盖容易混淆的对象、特殊版式等。
• 必须拒绝或转人工的情况，要包括超出范围的问题、字段缺失等。
• 对抗性输入可放少量，例如输入中藏有指令、空输入、异常长输入。

每条样本都要带类别标签。否则，一个总体正确率可能掩盖「普通问题答得不错，但该拒绝时总是放行」的缺陷。

正确答案由业务流程负责人，或其信任的人决定。两个人独立标注，再讨论分歧，可以提前发现业务规则不清楚的地方。如果连人都无法达成一致，先要补的是需求，而不是继续改 prompt。

每次改动，怎样变成一次可复查的验收

作者建议先冻结验收集，并在第一次运行前写下各类别的通过门槛。例如：自动处理项至少 95% 正确，所有必须拒绝的样本都要拒绝。

之后，每次修改 prompt、模型版本或阈值，都运行同一套样本，记录各版本分数，并读完全部失败项。每个失败都应继续追查：是实现缺陷、标注错误，还是缺少业务规则。

下面这段最小执行器，用来比较系统答案与预期答案，并返回正确率和失败样本：

def evaluate(system, items):
    results = [(it, system(it["input"])) for it in items]
    ok = [r for it, r in results if r["answer"] == it["expected"]]
    return len(ok) / len(items), [it for it, r in results if r["answer"] != it["expected"]]

要注意 r["answer"] == it["expected"]：这里采用完全相等判断。它适合答案可以精确比较的任务；对于允许多种合理表述的生成结果，原文没有提供评分方案。这段代码也没有实现前面要求的分类统计。

冻结也不代表永远不更新。作者建议大约每月加入 10 到 20 条新鲜真实样本，优先采用人工复核队列中的纠错案例，并移除不再符合业务流程的旧样本。如果频繁调优，还应保留一份完全未触碰的留出集（holdout）。

我的判断

我赞成先把验收标准写下来，再讨论模型效果。相比凭几次对话体验判断，它能让回归有迹可查，也能把业务分歧暴露在上线之前。

但「约 100 条就能起步」是方法建议，原文没有提供团队实测或对照数据，不能据此认定它适用于所有任务。刻意增加难例和拒绝案例后，整体分数也未必代表线上流量的正确率，分类结果更有解释价值。

另外，「读完失败」与「不在验收集上调优」之间需要明确边界。逐条围绕这些题改 prompt，仍可能逐渐记住考题。频繁调优的团队，应落实作者提出的独立留出集，而不是只把冻结理解成不修改样本文件。

能拿来做什么

• 给现有 AI 功能整理约 100 条真实输入，邀请业务负责人确认答案，并标注普通、困难、拒绝或转人工等类别。
• 如果 Node 服务返回的是可精确比较的答案，可以参照执行器建立回归检查，在修改 prompt、模型版本或阈值时运行，并分别输出各类别结果。
• 在第一次测试前确定通过门槛，同时记录版本和失败案例；大约每月补充 10 到 20 条真实纠错样本，频繁调优时另留未触碰的验收数据。