用单变量评测验证大模型流水线

LLM 接进自动化流程后，最难的往往不是让它返回 JSON，而是证明：换个模型、改句提示词，系统还能不能放心用。作者拿一个付款邮件处理原型做实验，给出的办法很朴素：冻结带标签的数据，每轮只改一项，保存完整结果，先过安全门槛，再比较成本。

这篇值得读的地方，是它把「这个回答看起来不错」拆成了可以复查的工程证据。不过，原型尚未上线，数据也主要来自生成样本。实验能说明方法怎么落地，还不能证明真实业务已经可靠。

先定义什么错误不能接受，再谈模型好不好

作者的原型读取小企业收到的付款邮件，判断是否付款，以及对应哪些参考编号。流程分四步：规则按模式提取信息，本地模型输出包含决策和编号列表的 JSON，代码检查模型答案，最后决定放行还是转人工。

只有规则与模型一致、且没有检查命中，邮件才会进入付款环节。检查放在模型读取之后，各自命名、记录版本，不藏在提示词里。

这里的关键，是把严重程度不同的结果分开计数。

严重错误属于准入门槛，不能靠省下多少人工来抵消。转人工则是避免错误付出的成本，需要报告，但不能因为人工量增加，就否定一个消除了严重错误的配置。通过门槛以后，才比较自动处理量、延迟、硬件和 token 成本。

选型先看能否通过安全门槛，优化再看通过之后的代价。

还有一类结果必须单列：任务既没有完成，也没有转交人工，后续无人检查，作者称为「静默关闭」。原型中有两个配置，其他指标都好看，却因这项指标被淘汰。

这套设计也解释了为什么作者没有直接加一个模型裁判。当前任务可以靠标签和代码检查判定，再引入一个模型，就又多了一份需要测试的不确定性。流程路由交给普通代码，每个步骤独立替换，才能知道究竟是哪一步改变了结果。

零错误需要多少样本，生成数据又能证明什么

测试场景来自当前手工处理业务的人，而且先列「必须拒绝自动处理」的情况。常见的正常邮件容易通过，真正需要保护的边界往往藏在少见形式里，所以稀有场景不能只按真实流量比例采样。

困难样本还要提前写好允许的结果范围。例如，带错别字的邮件可以准确放行，也可以转人工，但不能错误放行。否则测试时很容易临时解释，把失败悄悄放过。

生成数据有两道校验：业务负责人抽查每种场景；另留一份只看场景清单、不看生成模板而独立编写的数据。后一份用来检查系统是否只适应了模板。

样本数量也有边界。没有观察到失败时，错误率的 95% 置信区间上界约为 3/N。545 个样本零严重错误，对应上界约 0.55%；74 个样本零错误，上界仍约 4%。要支持低于 1% 的错误率，大约需要 300 个无失败的独立样本；低于 0.1%，则约需 3000 个。

这里最容易漏掉的是「独立」。

作者有 697 条生成消息，但它们来自几十种模板，不能当成 697 次独立抽样，实际界限会更宽。继续从相同模板生成消息，远不如增加新形式和人工编写样本有用。

所以，客户反馈的边界情况、人工确认或纠正过的决策，都应该进入回归集。只修代码、不留下样本，同一种错误下次仍可能回来。

每轮只改一项，怎样才能负担得起

每次都调用模型跑全量测试，成本很快会上来。作者把运行分成两类：

• 模型能感知的变化，都要重新读取，包括模型、提示词和推理设置。
• 模型外部的规则或检查变化，可以复用已有原始回答，重新计算判定结果。

后者不需要调用模型，通常几秒就能完成。这也是检查与提示词不能同轮修改的原因：既节省实验成本，也保留因果关系。量化同样属于模型变化，不能把同一模型的 Q8 和 Q4 当成等价配置。

每轮还要保存完整记录：模型 digest、量化方式、服务端、全部设置、提示词版本与 hash、测试程序版本与 commit、数据集 hash，以及逐条原始回答、token 和耗时。脚本据此建立数据库，报告重新计算所有判定，目标是与运行记录零差异。

比较应在同一主机上完成。同一模型和提示词，在笔记本 CPU 与 GPU 上处理 222 条消息，只有 167 条返回完全相同的文本。服务器变化也可能改变结果，不能只把它看作速度差异。

重复运行则用来识别噪声。作者的读取步骤设为 temperature 0、关闭 reasoning，并在同主机复跑确认文本一致。对于不确定的模型，两次重复之间的波动，就是这套测试能分辨变化的尺度。

改动带来的差异如果小于重复运行的波动，就还不能算测出了改进。

日常流程是先用几百条消息定位变化，再用同主机全量测试和重复运行验收，发布时再使用留出集。每个接受的版本成为下一轮基线。数据集扩充后，历史结果也只能在共同样本上直接比较。

实验真正支持的是哪些取舍

原型经过九次单项修改，严重错误从 51 个降到 1 个；最后单独运行的留出集出现 0 个严重错误。有一种不应付款的邮件形式会跟着提示词修改反复变化，最终由代码检查保护。

模型更大也没有自动成为更好的选择。在同一 GPU 主机、同一流程和数据集上，五个 4B 到 31B 的模型没有出现严重错误。12B 与 31B 分别放行 545 条可付款消息中的 452 条和 460 条，作者认为这组数据不足以区分两者质量，选择应更多考虑硬件和速度。另外两个更小模型出现严重错误，被排除。

12B 的 Q8 构建虽然多放行四条，却静默关闭一条。如果只看自动处理量，它反而会显得更好。

提示词实验也有类似结果。一个更严格的版本要求：主题提到、正文付款表却未列出的编号应转人工。它同时把四条正常消息转给人工，静默关闭一条，放行量从 452 降到 448。针对同类问题增加代码检查，重算后消除了该变体的全部 3 个严重错误，而且没有损失自动处理量。作者接受检查，拒绝提示词变体。

另一个失败方向是小型决策模型。三个 0.3B 到 2B 模型，搭配八种问法，测试 114 条消息，判断每个四位或五位数字是否为参考编号。最佳组合找回主模型漏掉的 8 处中的 6 处，却把原本读对消息的 37% 到 46% 也标成异常。方案被放弃，但误报分析反过来帮助作者补齐了代码检查。

第二遍 reasoning 也有明确限制。在 temperature 0.6、30 条待放行消息加 15 条对照消息的实验中，一个模型三次重复都静默关闭同一条消息，使问题得以稳定复现。但第二遍只能提高自动处理量：第一遍已经错误放行的消息不会进入它，安全门槛仍得在前面守住。

我的判断

我认同作者把模型测试接回常规工程方法：先定标准，保存证据，再做单项回归。他有 11 年银行和 SaaS 测试自动化、性能测试经验，这套思路的价值也主要在这里。

但实验结论必须留在边界内。真实邮件尚未跑过流程，真实输入的误报率未知；检查编写者知道生成模板的形式；提示词只针对一个小模型调优，留出集也只验证了该模型。生产反馈闭环目前只是设计，尚未运行。

性能同样没有测完。调用耗时虽有记录，目标硬件尚未确定，容量、每秒 token 数和尾延迟都还没有结果，因此不能据此宣布哪个模型性价比最高。

相比继续强化提示词，明确、稳定的业务约束更适合写进代码，这个方向有实验支持。但「检查不损失自动化」只是这次测试的观察，不能推广成通则。规则也会误报，也要回归。至于该方法比其他评测体系省多少成本、降低多少线上事故，作者没有对照数据，目前仍是经验之谈。

能拿来做什么

• 给现有 AI 自动化建立一个冻结回归集，先收录必须拒绝、必须转人工的案例，并逐条写清允许结果，不要只准备容易成功的演示输入。
• 在 Node 流程中保留模型原始 JSON，把解析后的业务检查独立出来并记录版本，让检查修改可以复用历史回答重算。
• 修改模型、提示词、量化或推理参数时，每轮只动一项；在同一运行环境复测，并分别报告严重错误、静默丢单和人工接管量。
• 把人工纠正结果持续补进测试集，明确可由代码判断的条件，再考虑增加模型步骤；发布前仍要跑完整链路，单个组件通过不代表系统通过。