Skip to content

生成文本的人工评估

如何对 LLM 与 NLG 输出开展一次经得起推敲的人工评估：精确定义各项标准，在绝对评分与成对比较之间做出选择，为研究提供足够的统计功效，并报告足以复现的细节。

像 BLEU 和 ROUGE 这样的自动指标与生成文本的实际优劣相关性很弱，因此人工评估仍是标准做法，而它做砸的次数往往多于做好的次数。把一次可信的人工评估与装点门面的评估区分开来的三件事：精确定义每一项标准，相对判断优先于绝对评分，并报告足够的细节使他人能够重新运行它。 本指南讲的是流程，而不是评分标准的措辞。

为什么要人工评估，以及为什么难以信任它

对于开放式生成、摘要、对话、翻译、LLM 回复而言，自动指标对照参考文本进行比较，却漏掉了大部分要紧之处：一个流畅且忠实、但措辞与参考不同的回答得分很低，而一句流畅的谎言却得分很高。因此人工判断仍然是基准真相。问题在于，人工评估本身就是一件测量工具，而设计糟糕的工具产出的数字，其噪声不亚于它所取代的那些指标。

问题的规模已有文献记载。Howcroft et al. (2020) 梳理了二十年的 NLG 评估，发现该领域甚至无法就自己的标准意味着什么达成一致：「流畅性」「充分性」「自然度」等术语在不同论文中定义各异（或根本没有定义），使得结果无法相互比较。他们开出的药方，是任何严肃评估的起点：在收集任何一个判断之前，先钉死每一项标准究竟意味着什么。

精确定义标准

标准含糊，正是大多数人工评估出错的地方。「请给质量打 1 到 5 分」等于邀请每位标注者各自发明一套质量的定义。把它拆分为命名清晰、各自单独定义的维度，并为每一个写下一句可操作的定义：

  • 流畅性：抛开内容是否正确不谈，文本是否合乎语法、结构良好？
  • 连贯性：句子作为一个整体是否顺理成章地衔接？
  • 忠实性 / 事实准确性：每一项主张是否有来源支撑（用于摘要/RAG）或为真（用于开放式生成）？幻觉正是在这里被抓出来。
  • 相关性：它是否真正回应了提示？
  • 有用性：对于助手类任务，它是否完成了用户想要的事？

分开测量这些维度，能告诉你一个系统为何胜过另一个，而不只是它胜过了。

绝对评分还是相对比较

最大的设计抉择在于：标注者是一次评估一个输出，还是比较若干个。

  • **绝对评分（李克特）**简单，却受制于量表偏差：标注者的锚点各不相同，回避两端，并在一次会话中逐渐漂移，因此一位评分者的「4」并不等于另一位的「4」。
  • 成对偏好（A 好还是 B 好？）完全绕开了量表偏差，通常更为可靠，这正是它支撑起 RLHF 偏好数据和模型比较的原因。代价是你得到的是排名，而非绝对水平。
  • **最优—最劣量表法**展示一小组，只询问最优和最劣，是用少量判断获得可靠排名的一种低成本方式。

van der Lee et al. (2021) 给出了恰好涵盖这些抉择的最佳实践指南：需要多少条目和评估者、采用哪种量表、做哪种统计分析，值得在你敲定设计之前一读。

为它提供功效，并加以报告

即使设计已然正确，仍有两种失败模式。

第一，功效不足的比较。 要检出两个都不错的系统之间的微小质量差异，所需条目数往往超出人们的预期；先做功效分析，采用恰当的显著性检验，并报告效应量，而不只是哪个均值更高。

第二，未加报告的细节。 Belz et al. (2021) 审视了 NLP 中的可复现性，发现人工评估尤其难以复现，通常是因为论文略去了确切的标准、指示语、标注者群体和分析方法。把这一切都作为研究的一部分记录下来，而不是事后补上。

几项可防止本可避免之偏差的做法：随机化输出顺序，使位置不致泄露（人们偏爱第一个选项）；遮蔽系统身份，使标注者无法看出是哪个模型产出了什么；以及先在一小批上做试点，以测量一致性，并在扩大规模之前修正令人困惑的标准。

在 Potato 中实现

Potato 为每一种评估方式都提供了一个方案，因此上述设计抉择可直接映射为配置。对于按标准分项的绝对评分：

yaml
annotation_schemes:
  - name: faithfulness
    annotation_type: likert
    description: "Is every claim in the response supported by the source? 1 = many unsupported, 5 = fully supported."
    size: 5
  - name: fluency
    annotation_type: likert
    description: "Is the response grammatical and well-formed?"
    size: 5

对于盲态 A/B 比较，使用 pairwise 方案，并随机化把哪个系统显示为 A：

yaml
annotation_schemes:
  - name: preference
    annotation_type: pairwise
    description: "Which response is more helpful overall?"
    labels: ["A is better", "Tie", "B is better"]

若要在一遍之内完成结构化的多标准评分，rubric_eval 方案会为评分标准的每个维度各收集一个分数。无论选用哪一种，都要在一个共享子集上保留重叠，以便报告一致性，并在导出中保留每位标注者的标签，好让显著性检验拥有它所需要的方差。

延伸阅读