如何评测AI模型：判断新模型是否真的更适合你的工作

简短回答：发布会跑分答不出你的问题

每一次前沿模型发布，都会附上一张图表，显示它在一组标准化评测中领先。这些数字是真实的，但对于判断你周一该用哪个模型，几乎没什么用，原因有三个。

差距很小，而且测的不是你的任务。 推理类跑分上两分的差距，说明不了哪个模型写的客户邮件更好，也说明不了哪个模型在两百行数据里能更稳定地保持结构一致。

跑分测的是容易打分的任务， 也就是有标准答案的那种。而大部分职场工作并没有标准答案：语气、结构、该省略什么的判断力。恰恰是这些地方模型差异最大，也恰恰是这些地方没人去测量。

发布会上的对比是厂商自己做的。 不一定是刻意造假，但没有厂商会公布自家模型排第二的那次评测。

真正值得回答的问题要窄得多：在你每周要做二十次的那些具体任务上，这两款模型哪个更好？这个问题没有现成答案可查，但只需要大约一小时就能自己测出来。

版本迭代之间，真正会变的是什么

纵观近几次前沿模型发布，真正影响日常使用体验的改进，反复出现在同样几个方面，而这些方面很少出现在发布公告里。

提升的方面	你会怎么感觉到	跑分是否体现
指令遵循	它不再无视你的第三条要求	很少
否定型指令	「不要用类比」这条真的会被遵守	不会
长上下文回忆	它能找到第140页的内容，而不只是第3页的	部分体现
格式规范	表格每次都严格按你要求的列来	不会
校准过的不确定性	它会说不知道，而不是瞎编	不会
语气控制	改到能发出去之前，需要改的次数变少	不会
推理深度	它能发现你漏掉的边界情况	会，这是他们唯一测量的一项

这七项里有五项在跑分图表上根本看不见，而这正是新模型用起来感觉更好或更差的原因。尤其是指令遵循，直接决定了一份初稿是能改一改就用，还是只能整个扔掉重写。

一小时评测法

与其去读发布会报道，不如这样做：拿你自己的材料，把两款模型放在一起并排测试。

1. 收集五个真实任务， 取自最近两周，要真实任务，把你实际的上下文粘贴进去，不要用玩具级提示词。至少包含一个写作任务、一个结构化输出任务，以及一个需要对陌生内容做推理的任务。
2. 在运行之前，先用一句话写下一个好答案应该包含什么。 这一步能防止你不自觉地偏向那个更长、语气更自信的输出，这是一种很强、而且大多数人意识不到的偏见。
3. 让每个任务同时交给两款模型运行， 这样两边的答案都不会被对方牵着走。
4. 按修改工作量打分， 也就是从输出到你能直接发出去之间要改多少，而不是看它读起来顺不顺。
5. 记下差距的大小， 而不只是记下谁赢了。如果两个结果差不多，这本身就说明这个任务不用再纠结选哪个模型，这个信息很有用。
6. 把记录保留下来。 三个月后新版本发布时，你只需重新跑一遍同样的五个任务，二十分钟内就能得到真正的答案。

最后这一点是能持续增值的。保留下来的这套评测任务，是让之后每次新版本发布都能低成本评估的唯一原因。

六个能区分前沿模型的提示词

泛泛的问题，任何一款有实力的模型给出的答案都差不多。如果你想看出差异，就要针对某项具体能力去施压测试。

• 困难情境下的语气。 写一封通知客户我们错过截止日期的邮件。要承担责任，但不要过度道歉，也不要找借口。120字以内。 语域上的差异会立刻显现出来。
• 否定型约束。 不使用任何类比或比喻来解释[概念]。 模型对否定型指令的遵守程度，差异远比你想象的大。
• 严格提取。 把每一个日期、金额和当事方提取成一个JSON数组，字段名必须完全一致。如果某个字段缺失就用null。不要推测。 测试的是格式纪律，以及模型自行补空的倾向。
• 长上下文回忆。 上传一份长文档，问中间部分的内容。这能揭示模型实际可用的上下文长度，跟宣传的上下文长度不是一回事。
• 承认不知道。 问一些确实冷门或非常新的内容。最好的答案是明确说「我不知道」，或者给出有来源的检索结果。在这项测试上编造答案，无论跑分多高都该淘汰。
• 多重约束遵守度。 一次给六个约束条件，数一数有几个能被同时满足。这一项单独就比列表里其他所有测试都更能预测日常使用的满意度。

答案通常是「两个都要，各司其职」

人们面对新版本发布时，都想要一个明确的结论，但认真跑完评测后得到的诚实结果，几乎总是各有胜负。一款模型在写作和语气上更胜一筹，另一款在严格结构和速度上更强。两者在通用推理能力上差距很小，小到不足以左右决定。

这不是和稀泥，而是真实的结果，而且它有一个实际意义。如果你只能用一款模型，那你实际上是在选哪一类任务甘愿做得差一点。如果两款都能用，新版本发布这件事就不再是「要不要换」的问题，而变成「哪些任务该迁移」的问题，这是一个小得多、风险也低得多的决定。

这也改变了新版本发布对你的意义。当新模型加入一个已经有好几款模型的工作空间时，你只需要重新跑一遍那五个任务，调整一下路由设置，然后继续工作。不需要迁移，不需要取消订阅，也不会因为没测试就先承诺，结果用了一整个月更差的模型。

发布当天该做什么

不要立刻切换默认模型。 发布周的第一印象主要被新鲜感和最先流传开的那几个案例所左右。

重新跑一遍你的评测任务集。 如果上次留下了一套，这次只要二十分钟。

检查那些不起眼的细节。 上下文窗口大小，你现有的提示词是否还表现一致，以及你依赖的东西有没有变化。一款整体更强的模型，在你的具体模板上完全可能更差，这一点值得在你把生产工作迁移过去之前先弄清楚。

按任务逐个调整路由，而不是一刀切全部切换。 只把新模型明显胜出的那几类任务迁移过去，其余的保持不变。

等两周再看局限性。 新模型的失败模式，通常在大规模使用大约两周后才会浮现出来，而这些很少出现在发布公告里。

关于整体框架，可以参考如何选择AI模型；关于如何针对同一个提示词并排运行两款模型的具体做法，可以参考并排比较模型。