模型替换评测：相关性更高仍可能落选

模型在榜单上赢了，就该替换线上方案吗？作者给求职筛选器换模型时，遇到了一个反例：挑战者的排序相关性从现有模型的 0.779 提高到 0.798，却漏掉了更多优质岗位，最终没能过关。四个模型、五次挑战，全部失败。

这组实验更有用的发现，是同一个模型仅仅调整服务配置，分数变化就超过了多数模型替换带来的差异。对程序员来说，它提供了一套判断方法：先确定工具必须守住什么，再决定哪些数字值得相信。

排序更准，为什么仍然不能换？

作者的流程分两层：本地模型先筛选职位描述，再由更大的模型 Claude 做完整评估。本地筛选器承担的是减少后续评估量的工作，但不能为了省计算，把值得申请的岗位提前扔掉。

所以，作者在第一次测试前就写下了两个条件：

• 与 Claude 评分的排序相关性必须高于现有模型。
• 找到的优质岗位数量至少与现有模型一样多。

两项必须同时满足。排序相关性衡量的是整张列表的顺序是否接近 Claude；优质岗位命中数衡量的是筛选器有没有保住真正重要的机会。

筛选器漏掉一个好机会，和多放行一个普通候选，代价并不对称。

前者可能让作者错失想申请的职位，后者只是让 Claude 多评估一次。只盯排序分数，就可能奖励一个列表整体排得不错、关键岗位却漏得更多的模型。

前四次挑战使用同一组 44 条职位描述，其中 12 条被判为优质岗位，提示词和评分代码也相同。第五次使用更新的 120 条职位，其中 48 条优质岗位，并让现有模型同步运行三次。两组数据规模不同，不能把所有分数当成同一张排行榜直接比较。

五次挑战失败，分别暴露了什么问题？

第一个教训是，通用能力不能直接兑换成任务表现。作者测试的 120B 模型，在通用基准上表现更好，激活参数量是现有模型的四倍，但在岗位排序上，相关性只有 0.646，现有模型则为 0.836 至 0.853。

这不能证明大模型没用，只能说明：作者需要的那项能力，没有被通用榜单充分代表。

中等规模模型更接近胜出。关闭推理时，它的相关性为 0.798；把推理设为 high 时，为 0.778，对应现有模型约为 0.775 至 0.779。匹配配置下，0.798 对 0.779 看起来是一次胜利，但作者认为差距处在重复运行的波动范围内。更直接的问题是，它只找到 12 条优质岗位中的 7 条，现有模型能找到 8 至 9 条。

另一个 30B 速度型模型，在短提示词演示中显得轻快，面对真实职位描述时，每个回答却生成超过 10,000 tokens，始终没有完成有效结果。它的问题甚至还没走到准确率比较：真实输入下，任务就跑不完。

最新发布的模型也没赢，相关性为 0.65 至 0.68，现有模型为 0.71 至 0.73。作者同时承认，这个新模型在部分困难的 agent 任务上确实更强。模型可以在另一类工作里有进步，但这不足以支持替换当前筛选器。

配置和重复运行，为什么比想象中更重要？

最显眼的变化来自同一个模型：相同提示词、相同测试集，一种服务配置下的相关性为 0.891，另一种为 0.777，相差 0.114。

第二种配置重复运行两次，结果相差不超过 0.004。这个配置间差距，明显大于作者观察到的这两次运行波动，也超过多数模型替换带来的差异：最新模型落后约 0.03 至 0.08，最接近的挑战者相差约 0.02，只有 120B 模型落后的 0.19 至 0.21 更大。

但这里不能直接得出「上下文窗口决定效果」的结论。作者调整的是上下文窗口，其他因素也跟着发生了变化，尚未隔离出准确原因。原文也没有给出窗口的具体数值和完整服务配置，读者无法照着复现。

另一个问题是稳定性。在 120 条职位的三次相同运行中，现有模型有两次各漏掉一个优质岗位，而且漏掉的并不是同一个。

作者因此给筛选流程加了一条补救路径：从被丢弃的职位中随机抽取一部分，仍然交给完整评估。这相当于检查垃圾桶，看看筛选器有没有把有价值的内容扔进去。原文没有提供抽样比例，也没有给出加入抽检后的成本和效果数据。

我的判断

我赞成先写通过规则，再看测试结果。它能防止团队看到一个漂亮数字后，临时改变「更好」的定义。尤其是前置筛选，整体排序与关键候选的保留情况，确实应该分别看。

不过，「所有挑战者都输了」只适用于作者这次实验。前四次只有 44 条职位、12 条优质样本；在这组数据上，现有模型相同运行之间的相关性就能变化约 0.04。作者没有给出统计显著性分析，因此小幅领先只能当作线索。

还有一个更根本的限制：这里的参照答案是 Claude 的判断，并非真实招聘结果。相关性更高，证明的是更接近 Claude，不能据此推导出更容易找到工作。

与看到新榜单就换模型相比，这套方法更贴近实际决策；与完整的生产评估相比，它还缺少成本、耗时和长期效果的对照。原文更适合作为一份小规模实验记录，而不是模型选型定论。配置影响很大的结论有实测支撑，具体原因仍然悬而未决。

能拿来做什么

• 给日常 AI 编程流程添加前置筛选时，先写清必须保留哪些结果。例如让模型筛选需要深入审查的代码变更，就应检查重要变更是否被漏掉，而不只看总体评分是否接近参考模型。
• 比较模型时，使用真实任务输入，并固定提示词、评分代码和服务配置。短提示词能跑通，不足以证明它能处理日常长度的材料。
• 对同一批输入运行多次，先了解现有方案自身的波动，再判断挑战者的小幅领先是否值得继续验证。
• 如果 Node 服务会根据模型结果直接丢弃候选内容，可以为被丢弃项保留随机抽检入口。抽样比例需要按漏检代价和评估成本确定，原文没有现成参数可抄。