LLM-as-a-judge：由模型自身进行评分 模型

#原理及其优势

向一个模型提供问题、待评估系统生成的回答，必要时再提供用于回答的片段和参考答案，最后提供评分标准。模型会给出分数并说明理由。在一百个案例上重复这一过程，就能得到一个可持续跟踪的指标，用于观察每次更改提示词、模型或检索参数后的变化。

另一种方案是人工评估，它仍是评估的参照标准，却难以大规模开展：没有人会在每次修改提示词后都重新阅读一百条回答。自动评审可以在十分钟内回答“这次修改改善了系统，还是让系统变差了”，从而改变工作方式。Zheng 等人的奠基性论文正是由这一观察所推动的：现有基准测试（MMLU 等）无法衡量开放式对话中真正重要的方面，而大规模人工评估的成本太高，难以对一个每周都在变化的系统进行快速迭代。

#编写一个可容纳的网格

1. 01
   一次只评估一个标准

   要求给出一个总体评分没有意义。应分别评分：对来源内容的忠实程度、相关性和完整性。
2. 02
   等级少且各级含义明确的评分量表

   采用三到四个等级，并说明每个等级的含义。十分制评分会产生无法复现的分数。
3. 03
   要求提供依据后再打分

   要求评审模型先推理再得出结论，比让它直接给出一个数字，结果要稳定得多。这与 Zheng 等人指出的“limited reasoning ability”是同一个道理：强制要求显式推理能减轻这一局限。
4. 04
   优先采用成对对比方式

   模型在回答“这两个回答中哪个更好”时，比回答“以五分为满分，给这个回答评分”表现好得多——Chatbot Arena 就采用这种形式来比较不同模型。

#偏见问题及其缓解方法

这一主题的权威论文明确指出了三种偏差和一个局限：位置偏差、偏好冗长回答的偏差、自我偏好偏差（self-enhancement），以及有限的推理能力。这不是博客中的假设，而是首次提出 MT-Bench 和 Chatbot Arena 的那项研究的核心结果；这两者至今仍是模型排名所用的参考。

好消息是，同一项研究记录了这样的结果：像 GPT-4 这样能力强的评判模型，在 MT-Bench 和 Chatbot Arena 上与人类偏好的一致率超过 80%，与两名人类评估者之间测得的一致率处于同一水平。概括本章的使用原则是：评判模型用于比较，绝不能用于认证绝对质量。单独一个 4.2 分（满分 5 分）说明不了什么；但在同一个测试集上，由同一个评判模型给出的评分从 3.1 升至 3.8，就反映了实际变化。

偏好冗长回答的偏差并非纯粹的理论担忧：AlpacaEval 基准被广泛用于比较经过指令微调的模型，而它在质量相同的情况下偏向生成更长回答的模型，是一个已明确获知的问题。其控制回答长度的版本（“length-controlled”）将与 Chatbot Arena 排名的相关性从 0.94 提升到 0.98——这一量化证据表明，仅消除这一项偏差，就能使自动评判更接近人类评判，而不是使两者更加疏远。

#用本地模型当评审，靠谱吗？

可以，但有两个条件。第一个是模型规模：参数量低于约 140 亿时，评判会变得不稳定，输出格式也会出错，导致整轮评测无法使用——这与本站的内存参考值一致（14B 在 Q4 量化下约需 9 GB）。第二个是上下文：评判模型必须能一次容纳问题、相关段落和回答——上下文满载会导致它对被截断的文本评分，而没有人察觉，因为模型仍会针对实际收到的内容正常作答。

当评估数据涉及机密信息时，本地法官的必要性显而易见：若将每条回答和每段文本发送至外部 API 进行评分，则会彻底丧失本地部署的意义，尤其是在医疗、法律或金融等场景中，原始文本本身即包含敏感数据。与生产环境不同，评估活动对延迟具有很强的容忍度：可安排在夜间启动，使用白天用于其他任务的 GPU，次日早晨获取结果。

#无需从头构建处理流程的工具

无需从零编写自己的评判框架。Prometheus 是一个开源研究项目，专门为这一用途训练了一个拥有 130 亿参数的模型：“We train Prometheus, a 13B evaluator LLM that can assess any given long-form text based on customized score rubric provided by the user”（我们训练 Prometheus，这是一个拥有 130 亿参数的评估型大语言模型，能够根据用户提供的自定义评分标准评估任何长篇文本）。作者报告，在同一评估流程下，使用 45 套自定义评分标准时，Prometheus 与人类评估者的皮尔逊相关系数为 0.897，而 GPT-4 为 0.882，ChatGPT 仅为 0.392——这一差距说明，非专用模型的评判可能有多么不准确，即使它在对话中生成的回答在其他方面是正确的。

Prometheus

13B，开放模型，专为依据自定义评分表进行精细评估而设计；是构建专用本地裁判模型的扎实基础，相比之下，使用通用模型来评分则偏离了其原本用途。

14B及以上通用模型

在这一参数规模范围内，Qwen、Llama 或 Mistral 也能充当评判模型，依靠精心编写的评分标准，而不是针对评判这项具体任务进行专门训练。

一个编排框架

适用于启动测试活动、存储结果并跟踪分数随时间的变化，而非每次重新测试新版本时都重新编写代码。

#一个可靠的评判提示词是什么样的

我们用一个具体案例来应用上一节的四条规则：一个回答流程相关问题的内部 RAG 系统。评审模型的提示必须明确包含所提出的问题、检索到的来源段落、待评估的回答、各项标准分别列出的评分表，以及先说明评分理由、再给出分数的要求。这比简单写一句“请按十分制给这个回答评分”更费篇幅，但正是这些细节，区分了可用的评估活动和一个让人安心却没有衡量任何东西的数字。

Question de l'utilisateur : {question}
Passages source fournis au système : {passages}

Réponse A : {reponse_a}
Réponse B : {reponse_b}

Pour chaque réponse, évalue séparément :
1. Fidélité aux passages fournis (aucune affirmation absente des sources)
2. Pertinence par rapport à la question posée
3. Complétude (la question est traitée entièrement)

Justifie d'abord ton analyse pour chaque critère, puis conclus par :
Meilleure réponse : A ou B
Raison en une phrase.

两个细节会让这个基本框架产生截然不同的效果。首先，要把来源段落一并传给评判模型，而不只是传入回答：没有这些段落，就无法检验回答是否忠实于来源，只能检查形式。其次，在提示中，理由应排在结论之前——如果要求评判模型先给分，它往往会事后为分数寻找理由，而不是先推理再作判断，这会加剧参考研究所指出的推理能力有限的问题。最后，在不同案例中交替排列回答 A 和 B 的顺序，再对两轮评判结果取平均，就能抵消 Zheng 等人记录的位置偏差中的大部分影响。

#何时不应使用

为高风险系统进行验证

在医疗、法律和金融领域，对于涉及责任的情况，自动评判系统不能替代人工复核。

用于对比两个差异显著的系统

只要回答格式不同，风格和长度偏差就会占据主导地位，Zheng 等人记录的冗长偏差就说明了这一点。

当存在确定性测试时

如果正确答案是数字或精确值，简单的比较更为准确，也远比LLM裁判便宜得多。

在案例数量过少的情况下

只用十个问题时，生成结果的波动就会超过您想测量的差异。

• Ragas：用数据评估您的本地 RAG
• Langfuse：监控您的本地 LLM（追踪、提示词、评估）
• 正确解读模型排行榜
• 本地RAG：简介（用于明确评估内容）
• 来源：Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena（Zheng 等，2023）
• 来源：Prometheus，一个拥有 130 亿参数的开源评判模型（Kim 等，2023）
• 来源：Prometheus 官方 GitHub 仓库

#FAQ