OpenAI Assistants：LLM 测评和验证的新范式

Confident AI 联合创始人，DeepEval 与 DeepTeam 创造者。LLM 评估成瘾患者。前谷歌（YouTube）、微软 AI（Office365）工程师。

在那场名满天下（或臭名昭著）的 OpenAI 开发者大会后一周，我们 Confident AI 发布了 JudgementalGPT——一个基于 OpenAI Assistants API 构建的 LLM agent，专门用于评估其他 LLM 应用程序。这个最初作为实验想法的项目很快演变成了我们迫不及待想要发布的原型，因为用户反馈表明，与 G-Eval 等其他最先进的基于 LLM 的评估方法相比，JudgementalGPT 提供了更准确、更可靠的结果。

可以理解，由于 Confident AI 是全球首个开源 LLM 评估基础设施，许多人在我们初次发布后要求更多地了解 JudgementalGPT 的构建方式：

我以为全都是开源的，但看起来 JudgementalGPT 对用户来说是个黑箱。如果我们能更了解它是如何构建的就太好了。

那就让我满足你吧，亲爱的匿名网友，这篇文章就献给你。

基于 LLM 的评估的局限性

G-Eval 的作者指出：

传统的基于参考的指标，如 BLEU 和 ROUGE，已经被证明与人类判断的相关性相对较低，尤其是对于需要创意和多样性的任务。

对于那些还不了解的人，G-Eval 是一个框架，利用具有思维链（CoT）处理的大语言模型来评估生成文本的质量，采用表单填充范式。如果你曾经尝试实现过自己的版本，你会很快发现使用 LLM 进行评估会带来一系列问题：

不可靠性 —— 虽然 G-Eval 使用低精度评分标度（1–5），这使得解释更容易，但即使在相同的评估条件下，这些分数也可能差异很大。这种可变性源于 G-Eval 中的一个中间步骤，它动态地为后续评估生成步骤，这增加了评估分数的随机性（这也是为什么提供初始种子值没有帮助）。

不准确性 —— 对于某些任务，一个数字通常占主导地位（例如，使用 gpt-3.5-turbo 的 1–5 评分标度中的 3）。绕过这个问题的一种方法是从 LLM 的输出令牌概率中获取数据来规范化分数，并取其加权求和作为最终分数。但不幸的是，如果你使用 OpenAI 的 GPT 模型作为评估器，这不是一个选项，因为他们几个月前已经弃用了 logprobs 参数。

事实上，另一篇探索"LLM 作为法官"的论文指出，使用 LLM 作为评估器有几个缺陷。例如，GPT-4 对自身生成的输出给予优惠待遇，在数学方面表现平平（但我也不擅长），并且容易产生冗长性偏见。冗长性偏见是指它倾向于更长、更冗长的回复，而不是准确的、更短的替代方案。（事实上，一项初步研究表明 GPT-4 在 8.75% 的时间里表现出冗长性偏见）

你能看到，如果你试图评估一个摘要任务，这会是多大的问题吗？

OpenAI Assistants 为现存问题提供了变通方案

这里有个惊喜——JudgementalGPT 不是由一个使用新 OpenAI Assistant API 构建的评估器组成的，而是多个。没错，在幕后，JudgementalGPT 是多个 assistant 的代理，这些 assistant 根据当前的评估任务执行不同的评估。以下是 JudgementalGPT 被设计来解决的问题：

偏见 —— 我们仍在试验这个（这也是 JudgementalGPT 闭源的另一个原因！），但 assistant 具有使用代码解释器工具编写和执行代码的能力，这意味着，通过一点 prompt 工程，它可以处理更容易出现逻辑谬误的任务，如编码或数学问题的判断，或需要更多事实性而不是对其自身输出给予优待的任务。

可靠性 —— 由于我们不再需要 LLM 动态生成 CoT/评估步骤，我们可以为特定的评估任务强制执行一套规则。换句话说，由于我们已经根据手头的评估任务预定义了多套评估步骤，我们消除了导致随机性的最大参数。

准确性 —— 为不同任务提供一套预定义的评估步骤也意味着我们可以根据人类对每个评估器的实际期望提供更多指导，并根据用户反馈快速迭代实现。

在将 G-Eval 集成到我们的开源项目 DeepEval 时，我们获得的另一个见解是意识到 LLM 生成的评估步骤往往是任意的，通常对评估指导没有帮助。你们中的一些人可能也想知道，当 JudgementalGPT 找不到适合特定评估任务的评估器时会发生什么。对于这种边界情况，我们回退到 G-Eval。这是 JudgementalGPT 如何工作的快速架构图：

每个块代表一个不同的 OpenAI Assistant 评估器，在必要时可以在评估期间使用代码解释器工具

在写这篇文章的时候，我发现了最近一篇介绍 Prometheus 的论文，"一个完全开源的 LLM，当附带适当的参考资料（参考答案、评分标准）时，在评估能力上与 GPT-4 相当"，它也要求评估步骤被明确定义。

为整个组织标准化 AI 质量，而不仅仅是个别团队

为所有 AI 用例提供相同的质量标准，通过一体化的 evals、可观测性和红队测试，在规模上强制执行。

但 LLM 评估的问题仍然存在

一个未解决的问题涉及源于评估分数中单个数字占主导地位的准确性挑战。理论上，这种现象不仅限于旧模型，也可能影响 gpt-4-1106-preview 这样的高级版本。所以我对这可能如何影响 JudgementalGPT 保持开放的心态。我们非常期待更多研究，这些研究要么支持我们的想法，要么给我们全新的视角——不管怎样，我洗耳恭听。

最后，定义我们自己的一套评估器仍然可能涉及复杂性。例如，就像 G-Eval 不是万能解决方案一样，摘要或相关性也不是。任何受可解释性制约的指标都注定会让期望不同东西的用户失望。目前，最好的解决方案是让用户清楚地定义他们的评估标准，以消除 LLM 的任何评估歧义。

说到底，LLM 评估没有万能解决方案，这就是为什么工程师/数据科学家经常对非人类评估分数感到失望。然而，通过为不同的用例定义具体而简洁的评估步骤，LLM 能够更好地应对歧义，因为它们获得了更多关于人类对不同评估标准的期望的指导。

P.S. 到现在为止，那些读懂言外之意的人可能已经知道，构建更好评估器的关键是为特定用例量身定制，而 OpenAI 的新 Assistant API 及其代码解释器功能只是锦上添花（也是一个很好的营销策略！）。

所以，亲爱的匿名网友，我希望你满意，下次见。

你想讨论如何评估你的 LLM（应用程序）吗？在我们的 discord 上问我们任何问题。我可能会给你一个"啊哈！"的时刻，谁知道呢？

为整个组织标准化 AI 质量，而不仅仅是个别团队

为所有 AI 用例提供相同的质量标准，通过一体化的 evals、可观测性和红队测试，在规模上强制执行。