谁来看守看守者？LLM在LLM评估中的应用

虽然使用LLM来评判LLM输出可能看起来像是让狐狸看守鸡舍，但事实证明这种方法效果相当不错（而且比人类评估更具扩展性）。

随着生成式AI得到更广泛的应用，特别是在生产环境中，工程师们正在思考如何使他们的应用程序更加可靠。随着开发人员使用LLM并对其更加熟悉，他们意识到不能盲目信任这些模型产生的内容。我们2025年的开发者调查发现，AI采用率正在增加，而对AI的信任和好感度却在下降。新鲜感已经消退，因此工程团队现在正在寻求建立机制来构建可信赖的系统。

每个人都希望由人类来审核和评估LLM输出。但对于有害内容（更不用说准确内容）的人类审核，如果没有社区努力，很难扩展规模。对于GenAI内容来说，实施人类审核更是不合理到数量级。而且不仅仅是有害内容：还有个人可识别信息、幻觉、与提示的一致性等等。因此，许多人转向了LLM作为评判者的策略，即使用不同的LLM来评估输出的准确性。

这可能看起来像是狐狸看守鸡舍，但正如我们将看到的，这是一种扩展评估的好方法。有一些严重的问题需要考虑，我们将看看我们自己的一些研究，以及我们母公司Prosus的研究，这些研究试图创建一个能够可靠判断准确性的基准。

LLM能评判另一个LLM吗？

正如我们所看到的，GenAI非常强大，但在某些方面存在缺陷，这些缺陷很难被发现。在这些缺陷到达人类之前捕获它们，对于GenAI成为有用工具而不是错误信息机器的未来至关重要。

在评判AI响应的准确性、语气和呈现方式时，人类评估一直是黄金标准。我们是人类，所以我们通常信任其他人类的看法。我们可以理解那个思维过程。任何给定的人类都相当擅长发现LLM犯的一些错误（尽管社交媒体帖子除外），但人类的扩展性不是特别好。如果你需要具有专业知识的人类进行判断或标注，请准备好支票簿——在专业领域，LLM判断的质量会下降。

对于那些希望自动化GenAI评估的人来说，好消息是使用LLM评判者的结果与人类判断相当吻合，具体取决于你的生成器/评判者配对。这些模型是在大量人类写作数据上训练的，因此它们至少能够大致上与人类反应保持一致是有道理的。但它们有自己的偏见：它们更喜欢冗长的答案，选择第一个答案作为最佳答案，并且在判断数学和推理方面有困难。

与许多其他GenAI问题一样，工程团队已经转向将LLM响应基于某种代表理想状态的数据。当你希望LLM做出质量判断时，通过给它参考答案——即良好判断的示例——你会得到更好的结果。像Etsy工程高级总监Mahir Yavuz这样的人将这些手工标记的评估集称为"黄金数据集"。“如果黄金数据集评估进展顺利，那么我们还有教师模型，即使用多个LLM来验证彼此的输出。这是目前行业中一种经过充分实践的技术。我们认为这是一种很好的扩展方式，因为你不能仅仅通过手工标记的数据来扩展。”

再次强调，人类仍然提供对数据的最佳判断，因此任何可扩展的自动化解决方案都需要某种形式的人类参与循环。有用于翻译和摘要的评分方法，但这只是LLM功能的很小一部分。生成式AI在开放场景中生成语言，评估涵盖了一系列品质，如偏见、准确性和恶意提示。你的评估LLM将需要一个结构良好的评估提示，并具有清晰的评估标准。这里的棘手部分是评估标准，因为如果没有黄金数据集或其他人类标记的数据集，这完全是一个无监督的机器学习问题。

假设你有一个定义了什么是好答案的原始黄金数据集。互联网上有一些基准和评估数据集可用，但如果你能找到这些数据集，LLM也可以，并且可以在它们上面进行训练。“这有点像鸡和蛋的问题，因为一旦你发布了某些东西，它就会被解决，“原始"Attention Is All You Need"Transformer论文的合著者、NEAR的联合创始人Illia Polosukhin说。“即使他们没有在特定数据上进行训练，他们也可以生成一堆类似的数据，对吧？然后它就明白了。”

任何用作训练数据的评估数据都可能影响评估的质量。对于基准测试——在特定提示下比较多个模型——它绝对会影响结果：这就像参加开卷考试。对于提示和响应的评估，将这些数据训练到LLM中可能并不那么糟糕，尽管这些评估者可能会陷入自我偏好的陷阱，即他们对来自类似训练数据的响应评分高于其他响应。

但每个数据集，即使是最黄金的，都是一个静态存储，除非你不断输入新数据。这很重要，因为世界和向你的AI提供提示的人不是静态的。新的信息、新的编程范式、新的说话和思维方式不断出现。评估这些变化意味着需要有稳定的数据流输入。

我们这里有你的黄金数据集

不断变化的信息环境在软件和技术领域尤其明显。在Stack Overflow，我们提供（并授权商业使用）一个最新的人类提供答案的存储库，这些答案针对工程师当前关心的编程问题。我们的母公司Prosus注意到了这一点，并进行了一些研究，看看我们社区策划的数据是否有助于评估GenAI对编程相关问题的响应。

现有的编码基准都存在显著限制，使其不太适合实际应用。一些评估集仅限于单一语言，如广泛使用的HumanEval。该集合已被翻译成多语言集合，但它们仍然依赖于164个手工制作的问题，因此它们可能无法扩展以评估任何给定的编码响应。其他基准，如SWE-BENCH，将这个问题视为机器学习问题，并在GitHub问题和拉取请求的语料库上进行训练。但这将现实世界任务的复杂性抛给了LLM，而LLM仍然难以有效管理这种规模。（大多数能够一次性创建整个应用程序的vibe编码工具都是代理性的，并将任务分解为LLM可以处理的较小部分。）

先前的研究表明，Stack Overflow上人类策划的知识非常适合LLM。问题和答案格式，结合赞和标签——本质上是人类标记——使得微软研究人员能够通过策划和蒸馏的过程创建一个小型模型，但其表现超出了其权重。Prosus研究人员希望使用原始数据构建模型，无需蒸馏。本质上，如果一个AI阅读了所有Stack Overflow，它能成为多好的程序员？

在这项研究中，他们创建了一个包含Stack Overflow和几个技术Stack Exchange站点公共转储的数据集。因为这些都是用户提供的信息，他们不想全部采用，只选择了那些被认为有价值的问题和答案。他们选择了至少有一个赞且有一个被接受答案至少有一个赞的问题。为了避免SWE-BENCH遇到的复杂性问题，他们将集合限制在字符数少于16,000的答案。标签让模型理解涉及什么编程语言或技术（有时甚至是版本）。但他们想要网站上标准标记和标记之外的其他信息。为此，他们使用LLM提供复杂性级别——初级、中级、高级——以及问题类型——概念性、调试、实现、优化、版本。

通过这个过程，他们产生了两个评估基准。StackEval将LLM响应与参考答案进行比较，并判断其准确性。他们发现，拥有参考答案使StackEval在发现好答案方面有更高的成功率——84%，这比仅仅使用思维链推理更好。参考答案有助于消除上面讨论的自我偏好偏见，但事实证明，具有 mostly-objective 正确解决方案的问题（如编码问题）不会像其他问题那样容易受到自我偏好偏见的影响。

总的来说，LLM在应对StackEval提出的历史和常见编程问题时表现非常好。这是有道理的，因为Stack Exchange转储是许多LLM训练数据的一部分。因此Prosus团队创建了StackUnseen，一个由最新问题和答案组成的基准。在这里，LLM表现稍差，无法将历史数据推广到新兴和利基问题。在他们进行研究的25个月中，根据更新的StackUnseen基准，给定LLM每年的表现下降约12-14%。模型漂移也适用于CodeGen：新问题、新技术、新理解不断产生。程序员知道他们的工作涉及持续学习；AI代码生成器也是如此。

从基准测试中判断

要超越基于一系列预先存在的问题来评估LLM，转向评估实时响应，我们进入了一个更模糊的领域。LLM本质上是非确定性的，因此它们的响应和判断会有所不同。也就是说，无论是对于人类还是AI，批评一个响应比生成一个响应更容易，因此我们可以期望一个与人类偏好良好对齐的LLM能够很好地判断一般文本质量。

对于涉及一般人类知识的评估，LLM可以在没有任何黄金数据集或参考数据的情况下表现得相当好。这包括语气和情感、偏见以及响应与给定上下文的契合度等方面。你需要严格指定评估标准和评分类别，以获得有价值的见解。我们发现数值分数不能提供可操作的反馈，并且即使有人类判断，变化也很大。

这里的棘手部分是定义上下文。对于给定的提示，你可以认为上下文只包括该提示中包含的内容。你可以尝试引入其他相关数据，如文档或其他网站。但对于特定领域的请求（如软件工程中的请求），提示有一个更大的、 mostly tacit 的上下文。

这就是基准及其所基于的数据集可以派上用场的地方。许多基准要么是从参考数据中蒸馏出来的，要么是基于人类标记或提供的响应。这些基础数据可用于提供AI可能遇到的问题类型的额外上下文。这个LLM在应对这个提示时表现如何，特别是对于一个新颖的提示？当你期望一个LLM评估领域专家提示和响应时，提供一些关于该专业知识是什么样子的指示会有所帮助。

上面提到的StackUnseen基准基于Stack Overflow最近三个月的问题和答案，因此它包含许多新颖的编程信息。它已被纳入ProLLM（Prosus的开放评估平台）以及其他数据中。当我们创建stackoverflow.ai时，我们使用ProLLM来对用于生成和评估的模型进行基准测试。

我们在这些评估中看到的是，当随时间测试LLM与我们的基准时，评估会随时间退化。它们没有见过这些数据，因此无法应对新颖的问题。它们在关于答案语料库较小的标签的问题上也表现不佳。如果模型要跟上现实世界，就需要不断的新数据。

LLM作为评判者框架并不能完全替代人类判断。自动化评估可以帮助GenAI应用程序扩展，但人类抽查仍然是必要的。因为这些AI过程仍然容易出现幻觉（而且LLM评估是盲人领盲人），你应该始终包括某种标记不良响应的方法。这些是生成器和评估器LLM的失败，应该用来改进两者。

依赖基准数据集进行评估存在一个危险：过拟合。通过将你的全部反馈循环基于单个基准评估的结果，你将得到一个调整以改进该基准的模型，而不是提供更好的结果。“这最终是由于古德哈特定律生效，如果过度索引，基准就不再有意义，“Stack Overflow的员工数据科学家Michael Geden说。“话虽如此，当用作评估面板时，它们仍然非常有用——这些对过拟合不太敏感。”

规模和速度

每个软件工程项目都需要某种测试来确定流程是否成功，无论是在构建时还是在生产中。在这方面，GenAI没有什么不同。不同之处在于测试一个极度非确定性的系统，其中任何东西都可能是输入，这构成了一个近乎无限的挑战。

使用LLM检查另一个LLM的工作可能像是让学生给自己的考试评分。但LLM评估通常在规模上是有效的。你可以通过使用在对你用例重要的基准上得分高的LLM来确保获得更好的评估。这远非完美，因此请保持人类作为这个过程的一部分。仅仅因为你拥有自动化测试套件，并不会使你的整个QA团队无效。