你的LLM评估方法过时了吗？这三个范式转变不容错过 原创

编者按： 在大语言模型时代，你是否也在为评估方法感到困惑？当开发周期越来越快，传统的评估思维却步履维艰 —— 新版本刚上线，评估指标就失效了；想要建立长期基准测试，却总是事与愿违；人工评估成本高昂，全自动评估又难尽人意...

我们今天为大家带来的这篇文章，作者认为在 LLM 时代，我们需要对评估体系进行根本性的范式转变，而不是简单地沿用传统机器学习的评估方法。

文章从作者在 Quora、Waymo 等公司的一线实践经验出发，提出了三个关键的评估范式转变：首先，评估工作应当从开发流程的配角转变为主角，因为 LLM 应用开发中可调整的参数相对有限，而输出的多样性却大大增加；其次，我们应当采用“比较差异”的基准测试方法，这种方法虽然无法得到绝对的性能指标，但能更高效地指导迭代方向；最后，我们要正视并优化人工评估的重要性，而不是一味追求完全自动化的评估方案。

作者 | 姜砺砺

编译 | 岳扬

在我的职业生涯中，我一直致力于为机器学习系统打造评估体系。在担任 Quora 数据科学部门负责人时，我们为新闻源排序、广告投放、内容审查等构建了评估机制。在 Waymo，我们团队为自动驾驶汽车开发了评估标准。而在金融科技初创公司 Coverbase，我们利用大语言模型（LLMs）来简化第三方风险管理的流程。这些经历让我意识到，在使用大语言模型时，我们需要在评估思路上做出一些细微而重要的调整。

本文的目的不在于为你的 LLM 应用提供具体的评估方法，而是提出以下三种评估范式的转变：

1. 评估应当是主体而非点缀。
2. 比较差异的基准测试 。
3. 将人工参与作为评估不可或缺的一部分。

需要说明的是，本文的讨论重点是 LLMs 的应用，而非基础模型的研究开发。 同时，尽管文章标题如此，但我在本文提到的许多观点同样适用于其他生成系统（这得益于我在自动驾驶领域的经验），而不仅仅是 LLMs 的应用。

01 评估应当是主体而非点缀

在机器学习的开发过程中，评估的重要性不言而喻，这一点对于 LLM 来说尤为突出。我认为 LLM 开发中评估的重要性提升有两个原因：

a) 评估的比重增加了，因为在构建 LLM 应用时，可操作的空间相对有限，导致非评估工作的耗时减少。 在 LLM 应用的开发过程中，我们通常是在 OpenAI 的 GPT 或 Anthropic 的 Claude 等基础模型之上进行构建，而在应用层面可调整的参数较少。这些参数的调整速度更快（需要注意的是，虽然调整速度快，但并不意味着能更快地达到理想效果）。例如，修改输入提示词的效率远高于为梯度提升决策树（Gradient-Boosted Decision Tree）编写新的人工特征。因此，非评估的工作量减少，评估所占的时间比例自然就提高了。

Image by author

b) 评估的绝对重要性也有所提升，因为生成式 AI 的输出具有极大的多样性，这使得评估工作变得更加复杂。 与分类或排序任务不同，生成式 AI 的任务（比如撰写关于某个主题的文章、制作某张图像、为自动驾驶汽车规划行驶轨迹）可能有无数种合理的输出结果。因此，评估实际上是一个将高维空间投射到低维空间的过程。例如，对于 LLM 任务，我们可以评估：“输出内容是否真实可靠？”，“是否含有有害信息？”，“语言表达是否简洁？”，“是否频繁使用‘当然！’等词汇开头？”，等等。在二元分类任务中，精确率和召回率是对结果的无损度量（直接测量你所观察到的结果），而我提到的 LLM 任务的评估指标则是对输出文本的损失性度量（测量的是你所观察结果的简化版）。准确地进行这种评估要困难得多。

这种评估范式的转变，对于 LLM 应用项目团队的建设，包括团队规模和人员招聘，都具有实际的影响。

02 比较差异的基准测试

理想状况是：我们在一个目标指标上不断攀升，并持续改进。

Image by author

但现实情况如何呢？

在图表上，你几乎连两个连续的数据点都画不出来！

以下场景你可能似曾相识：

第一次产品上线后，我们收集到了更多数据，导致新的指标数据与之前的不具备直接可比性。而且，我们无法在新数据集上重新运行旧模型 —— 可能是因为系统其他部分已经更新升级，无法回退到旧版本来复现模型；又或者是评估指标依赖于 LLM 作为评判标准，而数据集庞大，每次评估的成本过高，等等。

第二次产品上线后，我们决定改变输出结构。例如，之前我们指导模型输出“是”或“否”的答案；现在我们让模型输出“是”、“否”、“可能”或“我不知道”。因此，之前精心准备的基准测试数据集变得不再适用。

第三次产品上线后，我们决定将单个 LLM 调用拆分为两个 LLM 调用的复合调用，并需要评估这些子组件。为此，我们需要为子组件评估准备新的数据集。

……

问题的核心在于，在 LLM 时代，开发周期如此之快，以至于很难对同一指标进行持续追踪。

那么，我们应该如何应对？

关注性能的变动。

换句话说，我们应该接受这样一个事实：在图表上，我们通常只能看到两个连续的数据点（译者注：例如，一个代表当前版本的性能，另一个代表新版本的性能）。关键是要确保每个模型版本都比前一个版本有所改进（基于你当时所掌握的知识），尽管我们很难从绝对意义上了解模型的性能水平。

假设我有一个基于 LLM 的语言学习辅导程序，它能够首先判断输入内容是英语还是西班牙语，然后提供语法建议。一个简单的评估指标就是“英语/西班牙语”标签的准确率。现在，如果我修改了提示词，并想要知道新的提示词是否提升了准确率。除了手动标注大量数据并计算准确率之外，还有一种方法，就是只关注那些旧提示词和新提示词给出不同标签的数据点。这样虽然无法得知两个模型的绝对准确率，但我可以确定哪个模型的准确率更高。

Image by author

我想明确一点，我并非全盘否定以绝对值为基准的价值。我的意思是，我们应该意识到这种做法的成本，而比较差异的基准测试（虽然它不能完全替代前者），通常是一种更经济高效的方法来得出大致的方向性结论。 这种范式的转变，其根本原因之一在于，如果你是从零开始构建机器学习模型，那么你通常需要精心准备一个大规模的训练集，评估数据集往往就是这一过程的自然产物。但这一点在利用预训练模型进行零样本或小样本学习时并不适用（例如大语言模型）。

再举一个例子，假设我有一个基于 LLM 的评估指标：我们用一个独立的 LLM 来判断 LLM 语言导师所提供的解释是否足够清晰。有人可能会问：“既然评估已经自动化，比较差异的基准测试是否仍然比基于绝对值的基准测试更节省成本？”答案是肯定的。因为现在的评估指标更为复杂，我们可以不断优化这些指标本身（比如对 LLM 的提示词进行工程优化）。一方面，我们仍然需要对评估结果本身进行评估，比较差异的基准测试能够告诉我们新的指标版本是否有所改进。另一方面，随着基于 LLM 的评估指标不断演进，如果我们只关注比较 LLM 语言导师模型的相邻版本，那么就无需费心用新版本的评估指标来补充所有旧版本模型的基准测试结果。

比较差异的基准测试可以作为一种高效的内循环快速迭代机制，而将成本较高的基于绝对值的基准测试或长期跟踪方法留到外循环的低频次迭代中使用。

03 将人工参与作为评估不可或缺的一部分

如上文所述，想要一劳永逸地筛选出一个完美无缺的黄金数据集，用以长期作为基准的想法可能并不现实。筛选工作将是一个持续且必要的开发环节，无论是直接对 LLM 的输出进行筛选，还是对充当评委的 LLM 或其他更复杂指标进行筛选。我们应该致力于让评估工具尽可能具备可扩展性；关键在于，即便如此，我们也不应幻想能够完全摆脱人工筛选。 我们越快接受这一点，就能越早开始对工具进行正确的投资。

因此，无论我们选用何种评估工具，无论是自研还是外部采购，都应确保有一个简便易用的人工筛选界面。基本的界面可能如下所示：结合之前提到的比较差异的基准测试，它提供了一个并排比较的面板，用户可以轻松浏览结果。同时，该界面还应支持用户轻松记录筛选笔记，以便这些笔记未来可以作为黄金标签（golden labels）用于基准测试（从而减轻未来的筛选工作负担）。

更高级的版本应当是盲测模式，筛选者不知道哪一边是哪个版本。我们的数据多次证实，如果不进行盲测，即便是开发人员出于好意，也可能会有下意识地倾向于自己开发的版本。

这三个范式的转变，一旦被识别，适应起来其实并不复杂。真正的挑战在于，如何在兴奋和快速的开发节奏中提前发现这些转变。我希望分享这些思考能够帮助那些在工作中面临类似挑战的人们。

Thanks for reading!

Hope you have enjoyed and learned new things from this blog!

About the author

Lili Jiang

Fmr. Eng leadership at Waymo, Head of Data at Quora

END

本期互动内容 🍻

❓除了文中提到的三个范式转变，你觉得在LLM评估方面还有什么值得关注的新趋势？

原文链接：

​​https://towardsdatascience.com/paradigm-shifts-of-eval-in-the-age-of-llm-7afd58e55b29​​