北京
做LLM评测的人最怕什么？不是模型答得差，是打分环节悄悄出了错，而你还拿着这份分数当结论。有一支团队就撞上了这件事——他们在图遍历流程里用LLM打分，结果发现分数不对劲。更麻烦的是，修这个Bug不能把研究本身搞乱。
他们最终的做法是：把图遍历中的LLM打分调用换掉，改用物理方法。这个思路听起来有点跳，但逻辑很直接——当打分环节本身成了不确定性的来源，与其继续在LLM里绕，不如换一套不依赖模型判断的机制。
打分Bug为什么难修
LLM打分的问题在于，它不是一个纯函数。同样的输入，换个格式、换个顺序，输出可能就变了。有作者专门讨论过这个现象：浮点数和整数形式的置信度分数，会让模型行为发生变化。也就是说，输出格式本身就在影响打分结果。
这就带来一个尴尬局面：你以为在测模型能力，实际上可能测的是打分器的脾气。一旦打分环节有Bug，整条研究链路的数据都不可信。而修Bug的难点在于，你不能为了修它把评测标准也改了——那样前后数据就没法比了。
评测这件事，大家各修各的路
围绕LLM评测，已经出现了不少分头探索的方向：
- 有人做提示词质量打分，把预检评分做成API，在Prompt进入流程前先过一道关
- 有人搞自定义评测（Custom Evals），试图给混乱的LLM评测建立秩序
- 有人把AI打分和邮件验证接进端到端测试套件
- 有人用LLM做自动作文评分
- 有人让AI Agent去给所有代码仓库打分，看它能发现什么
这些尝试指向同一个痛点：评测环节太容易变成黑箱。你调用一次打分，拿到一个数，但这个数怎么来的、稳不稳定，往往没人说得清。
换掉打分调用意味着什么
回到那个图遍历的场景。图遍历本身是在搜索解空间，LLM在这里承担的是启发式判断——判断哪个方向更值得走。有研究专门讨论过用LLM启发式做目标导向探索，也有工作提出通过轮询LLM来给子目标打分，帮助聚焦潜在解。
问题在于，打分一旦出错，搜索方向就会跑偏。把LLM打分调用换成物理方法，本质上是把判断权从模型手里拿走，交给一套确定性的规则。这样做的代价是灵活性，换来的是可复现性——对于研究来说，后者往往更重要。
这个取舍没有标准答案。有人愿意接受LLM打分的不稳定，换取它更强的泛化判断；有人宁可要一个笨但稳定的打分器。关键在于，你得知道自己用的是哪一种，以及它什么时候会骗你。
评测工具正在变成基础设施
从这些项目能看出一个趋势：LLM评测正在从"跑个分看看"变成需要专门建设的基础设施。预检API、自定义评测框架、多Agent自动评估——这些都是在给评测本身加护栏。
原因不难理解。当LLM被塞进越来越多的流程里，打分就不再是终点，而是中间环节。中间环节出错，下游全错。那个图遍历里的打分Bug之所以值得写出来，不是因为它多罕见，而是因为它太典型了。
修好它的方法未必适合所有人，但发现它的过程值得借鉴：先怀疑打分器，再怀疑模型。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
