谁来看守看守者?LLM对LLM的评估
虽然使用LLM来评判LLM的输出可能看起来像是让狐狸看守鸡舍,但事实证明这种方法效果相当不错(而且比人类更容易扩展)。
图片来源:Alexandra Francis
随着生成式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 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在这方面没有什么不同。它的不同之处在于,测试一个高度非确定性的系统,其中任何东西都可能是输入,这构成了一个近乎无限的挑战。
使用LLM检查另一个LLM的工作可能像是让学生给自己的考试评分。但LLM评估通常在规模上是有效的。你可以通过使用在对你用例重要的基准上得分高的LLM来确保获得更好的评估。这远非完美,因此请保持人类作为这个过程的一部分。仅仅因为你拥有自动化测试套件,并不会使你的整个QA团队无效。