评测岗不是只有跑分

近期有讨论提到，同一模型在 max 设置下测 SWE 反而出现倒挂，有人据此质疑“设置为 max 真的就对吗”，并推荐了几篇相关论文。消息还提到一个观点：SOTA 模型应是完美的信息压缩器，用最少 token 解决最难问题，思考一大堆得出“42”不算 SOTA，E=mc² 才算。这些讨论对求职者的启发是：评测本身存在方法选择问题，不是把分数跑出来就结束。

模型评测与选型方向的岗位，大致分两类。一类偏基准维护：搭评测集、跑分、复现结果、跟踪版本差异，关注指标是否稳定可比。另一类偏业务选型：给定场景、成本和延迟约束，判断哪个模型或参数配置更合适，关注结论能否落地。读岗位描述时，要确认它更靠近哪一端。

面试前准备什么

与其背论文结论，不如准备一个自己设计评测方案的案例。比如同一任务下，对比不同参数配置或不同模型的表现，说明你如何定义评价标准、如何控制变量、遇到结果与预期不符时怎么排查。素材中“max 测 SWE 倒挂”正说明：设置变了，结论可能翻转，评测方案设计能力比记住某个分数更重要。

如果还没有实际项目，可以用假设场景练习：假设要为客服问答选型，你会看哪些指标、如何抽样、怎样避免只挑对自己有利的样例。注意标明这是模拟思考，不是真实工作经历。简历里的成果必须是实际完成的，没有数字就用[实际记录]这类占位，不要编造。

面试时问清团队怎么用评测

面试是双向的。可以问：团队的评测结果如何影响产品决策，是提供参考还是直接决定上线？评测频率和迭代节奏怎样？结论出现分歧时，谁来拍板？这些问题能帮你判断岗位是支持型还是决策型，也决定你日常是写脚本跑分，还是参与选型讨论。

一个小建议：面试前找一份目标岗位的职位描述，把职责逐条标成“跑分”或“选型”，再针对选型那部分准备一个追问。这样你问出的问题会更具体，也更容易看出团队真实的工作方式。