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

随着生成式AI被更广泛地实施，特别是在生产应用中，工程师们正在思考如何使他们的应用程序更加可靠。随着开发者使用并更加熟悉LLM，他们意识到不能盲目信任这些模型的输出。我们2025年的开发者调查发现，AI采用率正在增加，而对AI的信任和好感度正在下降。光环已经消退，现在工程团队正在寻找构建可信系统的机制。

人类评估的局限性

每个人都希望有人类对LLM输出进行审核和评估。但对有害内容（更不用说准确内容）的人类审核很难在没有社区努力的情况下扩展。对GenAI内容这样做实施起来更加不合理。而且不仅仅是有害内容：还有个人可识别信息、幻觉、与提示的一致性等等。因此，许多人转向了LLM作为评判者的策略，即使用不同的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"Transformers论文的合著者、NEAR的联合创始人Illia Polosukhin说。“即使他们没有在那个特定数据上训练，他们也可以生成一堆类似的数据，对吧？然后它就明白了。”

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

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

Stack Overflow的解决方案

不断变化的信息环境在软件和技术中尤其明显。在Stack Overflow，我们为工程师们当前的编程问题提供了一个最新的人类提供答案的存储库。我们的母公司Prosus注意到了这一点，并做了一些研究，看看我们社区策划的数据是否可以帮助评估GenAI对编程相关问题的响应。

现有的编码基准都有显著的局限性，使它们不太适合实际应用。一些评估集限制自己为单一语言，如广泛使用的HumanEval。该集合已被翻译成多语言集合，但它们仍然依赖于164个手工制作的问题，因此它们可能无法扩展到评估任何给定的编码响应。其他基准，如SWE-BENCH，将其视为机器学习问题，并在GitHub问题和拉取请求的语料库上训练。但这将现实世界任务的复杂性抛给了LLM，而LLM仍然难以有效管理这种规模。（大多数一次性创建整个应用程序的 vibe coding 工具是代理性的，并将任务分解为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在这方面没有什么不同。不同的是，测试一个 wildly 非确定性系统，其中任何东西都可能是输入，构成了一个近乎无限的挑战。

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