模型快了 100 倍，总耗时为什么只少了 3%？

假设审查一次代码修改，模型判断需要 10 秒，必要测试需要 300 秒，两步顺序执行，总共 310 秒。

换上新模型，判断只要 0.1 秒，是原来的百分之一。测试仍需 300 秒，整个任务于是变成 300.1 秒。

模型调用快了 100 倍，任务却只节省 9.9 秒，耗时减少约 3.2%。

这不是哪款模型的实测，而是一道用来辨认比较口径的小算术。它也解释了我读 Jev 发布材料时最想追问的事：快速的结构化决策组件当然有价值，但接口上的优势，最终能替使用者省下多少等待和工作？

先看模型时间占了多少

完整任务除了模型调用，还可能包括取数、检索、等待工具、失败重试和人工复核。开头的例子里，模型只占原总耗时的约 3.23%；即使把这 10 秒完全消掉，总耗时也只能降到 300 秒。

如果换一种任务，模型原来占总耗时的 90%，把这一部分缩短到百分之一，在其余部分不变且顺序执行的假设下，总耗时就会降到原来的 10.9%，约为 9.17 倍加速。同样的模型改进，收益取决于它在流程里占了多大比例。

术语也值得分清。310 秒变成 300.1 秒，耗时降幅约为 3.19%，加速比约为 1.033。两者的分母不同。日常说“快了约 3%”不难理解，但评测报告最好明确写时间或比值，避免数字越传越大。

平均值之外，还要看等待时间的分布。多数调用很快、少数调用频繁超时的系统，用户可能经常碰到漫长等待。报告需要说明失败和重试是否计入，不能只展示最顺利的一次。若任务可以并行执行，则要看决定结束时间的那条路径，也不能直接套用上面的顺序相加。

TypeSafe 在 Jev 发布文里披露了比较条件：演示使用的短输入有利于 Jev，部分公布收益预计处于实际收益的较高端。这些说明应与速度数字一起阅读。

比较对象，要完成同一份工作

假设业务只是把请求分给十个部门。一边只返回部门名，另一边却被要求生成长解释和完整概率分布，延迟差距当然会变大。但这个差距同时来自输出要求，不能全算在模型能力上。

反过来，如果业务确实依赖概率来分流，要求双方提供概率就有意义。公平比较的前提，是先确定系统需要什么，再配置候选方案；不能看完结果以后才挑最有利的输出口径。

生成式模型也可以受约束地输出结构化内容。XGrammar就是这类结构化生成工作的一个例子。不过，输出符合格式，并不说明分类判断正确。比较时需要同时检查交付格式、判断质量和完成成本。

TypeSafe 的发布文已经说明，其工作流评测中的大语言模型使用了结构化输出封装，并指出返回概率会增加耗时和成本。因此，合理的疑问是这套输出要求是否符合自己的任务，不能误说它只是拿未经配置的聊天窗口作对手。

我会把比较分成两类：固定预算时谁做得更好，以及达到相近质量时谁更省。推理设置、上下文长度、输出字段和失败处理都应随结果保留。如果任务本来就能用规则或小型分类器解决，也应把它们列为候选；更换大型模型未必是唯一选择。

与参考模型一致，离真实正确还有多远

速度可以用秒表记录，正确性先要决定由谁判定。

TypeSafe 的 Workflow evals 方法说明将任务拆成程序规则和模型判断，假设执行流程的代码正确，再用强模型回答的平均结果形成参考标签。这能衡量各方案在指定工作流里与参考判断的一致程度，也能帮助发现分歧。

但参考模型没有因此变成事实本身。如果输入漏掉关键材料，多个模型一致也不能补出缺失事实。评测中被假定正确的流程代码，同样不能再由这份得分证明正确：权限、版本状态和检查遗漏，仍需相应的工程验证。

这不使评测失去价值，只是限定了它回答的问题。对于容易取得实际结果的任务，例如文件能否被未授权用户访问，可以用执行结果核对；对于有歧义的语义判断，则可能需要人工标注、多方意见和分歧记录。参考答案怎样产生，会决定我们能怎样解释那个“准确率”。

99% 的准确率，可能漏掉全部危险案例

再看一组假设：1,000 个 PR 中，990 个按既定标准可以放行，10 个含有严重问题。审批器对所有请求都回答“通过”。

它判断正确了 990 次，总体准确率是 99%；与此同时，10 个严重问题一个也没拦下。多数类占比很高时，总分可以很好看，关键任务却完全没有完成。

把分母展开，问题就清楚了：

• 自动放行覆盖率：1,000 ÷ 1,000 = 100%。
• 已放行案例中的错误比例：10 ÷ 1,000 = 1%。
• 严重问题漏检率：10 ÷ 10 = 100%。

这些比例描述不同事情，不能互相替代。风险后果也应分开记录：漏掉注释格式与漏掉权限条件，不能只按“一次错误”平均。类别和判定标准应在看测试结果之前确定，避免结果不理想时临时换口径。

另一个极端，是把几乎所有请求转给人，只自动处理极少数简单案例。它可能得到很低的错误率，也确实节省一部分工作，但必须同时交代处理比例。研究中的选择性分类，讨论的正是允许模型拒答之后，覆盖率与风险之间的取舍。

实际使用还得算转人工的成本。模型若把复杂材料原样丢给维护者，再附上一堆误报，人工可能比从头检查更累。一个有用的方案，应在相近错误水平下减少总工作量，而不只是缩短模型输出。

提高置信度阈值也需要实测。只有分数能够有效区分高风险和低风险案例，提高门槛才可能筛掉更多错误；如果模型恰好对某类错误特别自信，阈值更高并不会自动解决它。

一百次零错误，先别急着扩大权限

假设某个系统在相同条件下每次独立出错的概率为 1%，连续一百次没有出错的概率是 0.99 的一百次方，约为 36.6%。一个存在 1% 错误率的系统，拿出一百次零错误演示，并不罕见。

这是说明样本不确定性的计算，不是在估计 Jev 的错误率。现实案例往往还不独立：来自同一仓库、同一种修改、同一份模板，看似一百次，覆盖的情况可能很窄。如果看着失败案例反复调提示词，再拿原样的案例宣布成功，测到的更像对练习题的适应程度。

保留集因此有用：先冻结模型、提示和规则，再使用没有参与调试的材料检查。要部署到多个仓库，就应关注不同仓库和风险类型的表现，而不只是合并后的总分。

上线后的“没有投诉”也不能直接记作正确。缺陷可能尚未触发，用户也可能没有反馈。应事先约定抽查哪些已放行项目、观察多久、后来发现的问题怎样回填；没有取得结果的案例，保留为未知。

一种起步方式是让模型先在后台给出判断，由原有流程继续负责实际决定，再比较分歧。这样的试运行不能证明所有部署风险都已消除，但可以在扩大自动处理范围前，找到一批具体的误判。之后模型、提示或规则发生相关变化，再补做受影响的评估，而不是把一次成绩永久沿用。

如果要据此挑选产品，我希望看到的交付物很具体：明确的任务范围，同样的输入输出要求，可追溯的参考判断，以及自动处理比例、错误放行、关键风险漏检和完整任务耗时。失败案例应能回到具体输入和记录，便于判断它是否也会发生在自己的系统里。

回到开头的 310 秒，节省 9.9 秒可能值得，也可能远不如优化那段 300 秒的测试。答案取决于调用频率、成本和真正的瓶颈。把这些条件算清楚，才能知道该替换模型，还是先改流程。

文中时长、PR 数量和错误概率均为说明性假设，不是 Jev 的实测结果。公开资料于 2026 年 9 月 27 日复核。