做LLM应用落地的人，八成都被同一个问题折磨过：模型的输出到底好不好？以前靠人肉评测，找三五个人读一遍打分，费时费力还不稳定，而且每个人的标准还不一样。后来业内慢慢摸索出一个新思路——既然大模型本身已经这么能打了，干脆让它当裁判替我们打分。这就是LLM-as-Judge评估方法，从一个想法变成了现在做模型微调、RAG问答、提示词迭代绕不开的基础设施。

这篇文章我把LLM-as-Judge的评估范式、Prompt设计、裁判模型选型和完整落地流程一次性讲透，不整花架子，全是实际跑过之后沉淀下来的东西。适合正在做模型评估、对比实验、上线前质检的开发者参考。如果你刚接触这个概念也没关系，我会从最基础的逻辑讲起，很多细节都是可以直接抄作业的。

1. 为什么需要引入AI裁判：传统评测方式的真实困境

1.1 人工评测的难点：贵、慢、不稳定

先聊一个很多人都经历过的事。我第一次给公司做模型效果评估的时候，用的是人工标注，找了六个同学一起打分，一人一份Excel表格，对着一堆模型输出逐条打分。结果折腾了一周，光整理意见就花了两天，最后大家的分歧还很大。有人说“这个回答很自然”，另一个人觉得“信息不完整”，七嘴八舌就是出不来一个统一的结论。

这不是个例。人工评测有三大硬伤。第一是贵，每一条样本至少要两三个标注员同时打分才能保证基本可信度，一个评测集动辄三五百条，折算下来的人力成本很高。第二是慢，标注、收集、清洗、仲裁，整套流程走完可能以周为单位。第三是不稳定，人的状态、疲劳程度、前一条样本的观感都会影响后面的打分，同一份数据隔一周再评一次，结果未必能对上。

我见过不少团队因为评测太费劲，索性放弃系统评估，靠“我个人觉得效果还行”来决策。这种凭感觉做事的方式，短期看是省了事，长期看就是在埋雷。

1.2 传统自动指标为什么失灵：ROUGE、BLEU解决不了开放任务

传统自动评测指标不是没有，像ROUGE、BLEU、METEOR这些，在机器翻译和文本摘要这类确定性强的任务上确实还能用。它们的核心原理是计算模型输出和参考文本之间的词面重合度，说白了就是看“像不像”。

但到了开放域对话、生成式问答、创意写作这类任务上，这套逻辑就崩了。同一个问题，正确且有价值的答案可能有好几种完全不同的表达方式，词面重合度极低，但意思都对。反过来，有些输出词面重合度很高，实际内容却是空洞的套话。用ROUGE去评价这类任务，分数根本反映不了真实质量。

我印象最深的是一个案例：某同学做客服问答优化，ROUGE分数明明涨了不少，但放到线上实测，用户满意度反而降了。后来分析发现，模型学会了模仿标准答案的开头和结尾句式，但真正解决问题的那部分内容并没有变好。这就是用错指标付出的代价。

1.3 LLM-as-Judge的底层逻辑：把质量判断交给大模型

LLM-as-Judge的核心思路其实很朴素：既然大模型已经学习了海量的人类偏好数据，具备了一定的语义理解和内容鉴赏能力，那我们就设计一份结构化的评估指令，让大模型像人类评委一样，根据给定的评估维度对模型输出进行打分或者排序。

用生活化的类比来说，人工评测相当于请专业评审团现场打分，LLM-as-Judge则相当于在公司内部培养了一个经验稳定的评审委员会，一次投资、随时调用。大模型读过的文本比任何一个人都多，对好答案和烂答案见过的样本也多，所以让它来评估内容的完整性、相关性、逻辑性，至少在一致性上远胜于人。

当然，“AI裁判”并不是完全取代人工，而是把人工从海量的基础评测中解放出来，让人只关注那些有争议的、高风险的样本。这个定位想清楚之后，整个评估管线设计起来就顺了。

2. 裁判也有不同流派：三种主流评估范式怎么选

2.1 直接打分式：简单粗暴但要注意分数膨胀

直接打分式是最常见的一种范式：把待评估的模型输出、评估维度和评分量表一起给裁判模型，让它输出一个数值分数。通常用1到5分，或者1到10分。

这种方式的优点是直观、易实现，跑完一批样本就能算出平均分，适合做快速对比。缺点是裁判模型容易给人情分——统一给4分、5分，出现分数膨胀，导致所有结果都挤在一个很小的区间内，根本没有区分度。另外，直接打分没有参照物，单个分数的绝对意义很难判断，8分到底是好还是特别好？没有对比就没法回答。

我实操下来，如果要用直接打分式，评分量表必须带详细的行为描述。比如5分意味着什么、3分意味着什么，而不是简单说“分数越高越好”。量表越具体，裁判的行为就越可控。

2.2 两两对比式：当前稳定性最好的方案

两两对比式就是把模型A和模型B的输出同时给裁判，让裁判判断哪一个更好，或者打平。比起直接打分，对比式对裁判的语义理解能力要求略高，但结果更稳、更可靠。

我做过的多次实验里，两两对比式的内部一致性明显优于直接打分式。原因也好理解，让模型在“两者之间做选择”比让它“给一个绝对分数”要容易得多，这就像让人判断两个苹果哪个大，就比让人用一个抽象的甜度指数来描述苹果要靠谱。对比式在模型迭代、Prompt版本对比、参数微调效果对比这些场景下特别顺手。

代价是成本翻倍，因为每一条样本至少要调用两次裁判（交叉比较A vs B和B vs A），而且当答案相似度高时，无论怎么设计Prompt，裁判都容易给出“打平”。不过相比人工评测，这个成本还是低了一个数量级。

2.3 参考答案式：需要标准答案时的省心选择

如果手头任务有明确的标准答案时，参考答案式就很合适。这种范式会把标准答案、待评估输出和用户问题一起给裁判，让裁判判断待评估输出是否准确覆盖了参考答案的核心信息，以及有没有添加错误信息。

它特别适合抽取式问答、结构化信息提取、知识库检索这类任务。举个实际场景：用户的合同里写了违约金比例是20%，模型在聊天窗口里回答说“违约金一般是10%到30%”，这时候直接打分或者对比都很难准确反映错误程度。而参考参考答案，模型输出中漏掉了“20%”这个关键数字，基本就能立刻判定答案为错误。

参考答案式的关键在于参考答案本身的质量，参考答案不完整、有歧义，裁判的评估结果就会跟着歪。所以这条方案对人工整理参考答案的质量要求比较高，前期准备成本需要算进预算里。

2.4 三种范式怎么搭配使用

从这个表能看出来，没有一种范式是万能的。我在实际项目里更习惯的做法是：先把评估目标拆解，对每一类样本单独选合适的范式。比如做一个RAG问答系统，事实类问题用参考答案式，开放性建议类问题用两两对比式，而总体的体验诊断则用直接打分式跑一轮快速摸底。

3. 让裁判靠谱的关键：评估Prompt设计的核心细节

3.1 评估维度定义不清，裁判就会胡乱发挥

很多人写评估Prompt的时候，只扔一句“请评估以下回答的质量并打分”，然后就没了。这种写法做出来一定翻车。裁判模型确实聪明，但它不是你肚里的蛔虫，你心里想的“相关”和它理解的“相关”很可能根本不是一回事。

必须把评估维度拆开，而且每个维度都要给清晰的定义。比如“相关性”不能只说“评估回答是否与问题相关”，而是要说清楚：如果回答偏离了用户的真实意图，给出了与问题无关的知识或者泛泛的套话，应判定为低分；如果回答正中问题核心，没有冗余信息，应判定为高分。

我建议每个维度都要配正反两个示例。对裁判模型来说，示例是最好的沟通语言。给它一个典型的好答案和一个典型的坏答案，它就知道你定义的那个维度到底是什么量纲了。

3.2 评分标准要用行为描述，而不是形容词

评分量表的设计直接决定结果的区分度。我见过太多这样的量表：“5分表示非常优秀，3分表示一般，1分表示很差”。这种描述废话连篇，模型根本无法稳定映射。

正确的做法是给每一个分数档位配上具体的行为特征。以1到5分的相关性评估为例，应该是这样的格式：

• 1分：回答完全跑题，与用户问题无关，或者是无意义的重复内容
• 2分：回答只涉及问题的边缘信息，核心问题未被解决，存在明显遗漏
• 3分：回答部分解决了用户问题，信息基本正确，但不够完整或聚焦
• 4分：回答完整且直接回应了用户问题，信息准确，冗余控制在合理范围
• 5分：回答精准、简洁地彻底解决了用户问题，且提供了合理范围内的延伸价值

这种写法的好处是，每个分数都对应可观察的输出行为，裁判模型更容易建立稳定的映射关系。实际跑出来的分数分布也明显更均匀，不会挤在4分和5分。

3.3 一份可直接复用的评估Prompt模板

我这里贴一个经过多次调试的评估Prompt模板，场景是RAG知识库问答的质量评估，包含相关性和忠实度两个维度。你可以直接复制改一改就能用：

你是一个公正严谨的AI测评专家。你的任务是对一个知识库问答系统的回答质量进行评估。 评估对象信息： - 用户问题：{question} - 检索知识片段：{context} - 待评估回答：{answer} 请从以下两个维度分别评分（每个维度1到5分）： 1. 相关性（考察回答是否直接解决用户问题）： - 5分：回答精准命中问题核心，信息直接有效，无冗余尾巴 - 4分：回答完整覆盖问题，但存在少量无关信息 - 3分：回答部分覆盖问题，核心信息有所遗漏或存在偏移 - 2分：回答与问题相关但未解决核心需求，只有皮毛 - 1分：回答与问题无关或完全答非所问 2. 忠实度（考察回答是否与检索知识片段一致，有无事实性编造）： - 5分：回答中的所有事实细节均在检索片段中有据可查 - 4分：回答基本忠实于检索片段，存在轻微语序调整，但事实无误 - 3分：回答有一处事实细节无法在检索片段中找到来源 - 2分：回答存在多处无来源的事实性内容，或关键数字错误 - 1分：回答大部分内容不属于检索片段，疑似凭空生成 输出格式要求： ```json {"score_correlation": 4, "score_faithfulness": 3, "reason": "简要说明评分理由"}

特别注意：

• 只能按检索片段和用户问题来判断，不得调用你的背景知识
• 如果检索片段中没有的信息在回答中出现，就是编造
• 评价要严格，敢于给低分，不得因为回答流畅就手软
• 输出必须是合法的JSON，不要包含其他文字

这个模板里我特别关注几点：一是把“知识片段”作为评估依据显式传入，让裁判只依据检索内容判断，尽量抑制它调用自有知识；二是加了“不得因为回答流畅就手软”这句话，应对裁判的流畅度偏见；三是限定输出JSON格式，方便程序解析。 ### 3.4 裁判有偏见：位置偏差和长度偏差怎么抑制 LLM-as-Judge不是完全中立的，它有一堆系统性偏见，其中最明显、影响最大的两个是位置偏差和长度偏差。 位置偏差，也就是在两两对比时，排在前面的答案更容易被裁判选中。理论上模型不应该有这种偏好，但实测就是有。抑制它最有效的方法是做双向对比。比如比较生成系统V1和V2，第一轮把V1放前面、V2放后面，第二轮反过来再比一次，两次都判定胜出的才算赢。 长度偏差就更隐蔽。裁判在对比两个答案时，经常会倾向于给出更长、内容更多的那一个，哪怕长答案里面全是废话。抑制它的办法包括：在Prompt里显式强调“回答的长度不是评估依据，请只关注信息质量和相关性”；或者把两个答案的长度差异控制在合理范围内；对超长输出先做截断再评估。 还有一个我自己踩过坑：裁判模型对“语气自信”的答案有天然好感。同样的事实内容，语气笃定的回答往往分数更高。这个没法完全消除，只能通过加大忠实度维度的占比来对冲。 ## 4. 裁判模型怎么选：选型思路和避坑经验 ### 4.1 选裁判的三条基本原则 裁判模型的选择，直接决定了整个评估体系的可靠性。选小了评不准，选大了成本扛不住。我总结出三条基本原则，你照着走基本不会跑偏。 第一条，裁判的能力要明显强于被测对象。让一个水平一般的模型去评价另一个水平相近或者更强的模型，它根本没有足够的判别力，给的分数自然不可信。裁判和被评估模型的差距越大，评估结果的参考价值越高。 第二条，指令遵循能力必须过硬。评估任务本质上是一个高度结构化的指令任务，要求裁判严格按维度评分、按格式输出。如果模型连输出JSON这种基本要求都做不到，别的都不用谈了。 第三条，稳定可复现。同一份样本同一套Prompt，今天测和明天测结果要能对齐。有些模型的输出随机性大，或者有较强的上下文偏见，这种模型做裁判就是给自己挖坑。 ### 4.2 四档裁判模型的实际表现对照 按我实际项目里用过的模型，我会把可选的裁判分成四档，每档都有不同的能力边界和成本区间，没有绝对的优劣，只有适不适合。 优先级最高的是闭源旗舰模型。它在语义理解、指令遵循、长文本处理上都是第一档，评测结果最接近人类标注员，适合作为最终基准裁判。代价是调用成本高、有客观速率限制，不适合海量样本全量评估，最好用来评估抽样样本和仲裁争议样本。 第二档是中端闭源模型。能力比旗舰款弱一些，但已经远超大多数开源模型，做对比评估和初步判断完全够用。关键是成本大约是旗舰款的十分之一甚至更低，适合常规批量的评估任务。如果项目预算有限，用它做主力裁判是很划算的选择。 第三档是头部开源模型（大参数级别，如几十B到上百B参数）。在很多任务上已经能和上一档打平，而且在本地部署之后，成本几乎可以忽略不计。但部署难度和资源占用是实打实的门槛，一台主流显卡跑一个大规模模型并不是轻松的事，推理速度也会拖慢整个评测流程。 第四档是轻量级开源模型（几B级别）。坦白讲，我个人非常不推荐把这档模型当主要裁判。我实测过，它们在简单任务上勉强能给出可参考的打分，但一旦评估维度稍复杂，评分就开始飘。原因也简单，裁判任务本质上也是一个需要高阶语义理解的任务，小模型的能力天花板就在那里。 | 裁判档位 | 判别力 | 稳定性 | 成本 | 推荐用法 | | --- | --- | --- | --- | --- | | 闭源旗舰模型 | 最高 | 高 | 高 | 基准裁判、争议仲裁 | | 中端闭源模型 | 较高 | 高 | 中 | 常规批量评估主力 | | 头部开源大模型 | 中高 | 中 | 低 | 本地部署、大规模评测 | | 轻量级开源模型 | 弱 | 较低 | 极低 | 不推荐，除非资源极度受限 | ### 4.3 决策流程：你的任务形态决定裁判选型 很多人一上来就问“用什么模型当裁判最好”，我的答案永远是一句话：先看你的任务难度，再定裁判档位。 如果你的评估任务非常简单，比如判定“回答是否包含指定关键词”这种，用轻量级模型就够了，没必要杀鸡用牛刀。但这类任务根本不需要LLM，写个规则也就解决了。真正需要LLM-as-Judge的场景，任务复杂度普遍不低。 凡是需要综合判断的评估维度，比如逻辑是否严密、表达是否自然、内容是否完整，我都建议直接上中端闭源模型起步。因为它已经经过大规模对比验证，结果能直接对外汇报，而开源模型的表现方差较大，容易在关键决策上误事。 如果你做的核心实验对精度极其敏感，比如微调模型上线前的最终验收，那基准裁判一定要用旗舰模型，至少对抽样样本跑一遍作为锚点。这样做的好处是给整个评估体系定一个基准坐标系，后续日常迭代用低成本的裁判模型去追踪相对趋势就行。 ### 4.4 一个让我印象深刻的选型翻车案例 有一次项目为了省成本，用一个小参数量开源模型当决赛裁判，对比两个版本检索问答模型的效果。跑出来的结果跟之前的真值评测完全相反，版本B被裁判判为明显优于版本A，但人工抽样看下来版本A的效果其实更好。 后来定位原因，发现那个小模型在评估时对“回答长度”产生了极高的权重，版本B因为回答普遍长了一截，被误判成“更详细更优质”。把那部分控制变量之后，它的判别力和人类标注的相关性低得离谱。这个项目最后推倒重来，换成了中端闭源模型做裁判，结果才回归正轨。 这件事之后我总结了一个教训：越是便宜的裁判，看似省了钱，实际上后续纠错的成本更高。评估系统是整个AI应用的地基，地基歪了，上面的优化方向全是错的，那才是真正的浪费。 ## 5. 从零搭建一套LLM-as-Judge评估管线 ### 5.1 评测集怎么构建：数量、覆盖面和标注规范 评估管线的第一步是构建评测集。很多人以为评测集就是拿一批线上日志丢进去就行，其实没那么简单。评测集的质量直接决定评估结果的代表性，这里我建议按下面几条标准来准备。 评测集的数量，建议首批至少200到300条。太少了，统计结论的置信区间很宽，改动一点点Prompt就会导致分数大范围跳动；太多了，除非要发布专项报告，否则每次迭代都全量跑一遍，成本和时效都不划算。我个人的节奏是日常迭代用100到200条快速跑，里程碑节点再用500条以上的全量集做一次彻底验证。 评测集的覆盖面比数量更重要。也就是样本要尽量覆盖不同类型的用户问题：简单的事实问答、复杂的长尾问题、多轮上下文依赖问题、知识库检索不到的问题、用户输入有歧义的问题等等。如果评测集全是简单问题，评估结果就只能反映顺风局的模型能力，对真实线上环境毫无意义。 样本的来源建议优先取线上真实日志，再人工补充一些边界场景。构建完必须做一遍标注，给每一条样本打上期望的答案要点和要点等级，这既是评测集的质量保证，也是后期仲裁的依据。 ### 5.2 评估执行：并发调用、失败重试和成本控制 评测集的评估执行听起来简单，真正跑起来全是细节。首先是调用方式，我一般用异步并发，控制并发数在裁判API允许的范围内，既能压吞吐又不容易触发限流。一次200条的评测集，几分钟就能跑完一轮。 失败重试是必踩的坑。模型偶尔会返回非JSON格式的输出，或者在长文本输入时直接超时。所以评估代码里必须抓好几个环节：解析失败就自动追加一次重试（最多三次），超过重试次数就人工标记；超时阈值要按最长输入估算，给足余量。 成本这块，常规做法是引入“粗筛-精评”两级机制。第一轮用便宜的裁判模型全量跑一遍，筛出得分明显偏高和偏低的，中间区域再去让高阶裁判复核。这样可以显著降低旗舰模型的调用量，同时保证核心决策基于高质量评估数据。 ### 5.3 结果统计：兼顾均值、差异显著性、分类一致性 评估跑完之后，最忌讳的事情就是直接算个平均分然后拍板说“B版本平均分4.2，高于A版本的3.9，所以B赢了”。均值当然要看，但它只说明总体水平，无法回答“B是不是在所有场景下都更好”或者“这两个分数之间的差异是真实变化还是随机波动”。 我的习惯是至少算三组指标：总体均值、分维度均值、分类型（比如按问题类型分组）均值。只看总体结果的团队，通常都会在某个角落翻车。只看到整体胜率提升，打开分类明细一看，原来是客服类问题提升明显，技术类问题反而退步了。 分类型统计是发现问题的最快方式，视觉化输出成表格之后，有没有偏科一眼就能看出来： | 问题类型 | 样本数 | 版本A均分 | 版本B均分 | 差异方向 | | --- | --- | --- | --- | --- | | 事实问答 | 64 | 4.01 | 4.32 | B显著占优 | | 多轮对话 | 52 | 3.78 | 3.65 | A略占优 | | 长文本总结 | 48 | 4.15 | 4.11 | 无明显差异 | | 边界问题 | 36 | 2.98 | 3.42 | B占优 | 另外一个必须做的是抽检一致性。每轮评测抽10%到20%的样本做人工复核，重点看裁判的评分和人工判断是否吻合。如果一致性低于80%，说明裁判Prompt或模型选型需要重新调。这个抽检流程看似麻烦，实际上是评估体系可信度的最后防线。 ### 5.4 自洽性验证：结果稳定了才算数 一套评估体系能不能长期用，还要看它有没有自洽性。我每次搭完新评估管线都会做一个简单的验证：同一份评测集，用同一套Prompt跑三遍，看标准差。标准差小说明评估结果稳健，标准差大就要警惕了，可能裁判模型对输入顺序敏感，或者评分标准没有被稳定遵守。 更严格一点的验证是把同一批样本打乱顺序再跑一遍，确认结果不受样本排列顺序影响。再进一步，换一种表述的Prompt但保留相同语义，看分数是否基本一致。如果分数波动剧烈，说明Prompt设置有问题，要么是维度定义太模糊，要么是示例影响了裁判的判断框架。 自洽性验证不是一次性工作。每换一次裁判模型、每改一次评估维度，都要重新做一遍。我自己在踩过几次坑之后，已经养成了把自洽性验证写进自动化流水线的习惯，每次评估跑完自动输出一致性报告，省心很多。 ## 6. 常见问题与排查技巧实录 ### 6.1 裁判一直给高分，分数区分度很差 出现分数膨胀，先说结论：多半是评分量表没写清楚，或者是Prompt里没有给足“需要严格打分”的暗示。裁判模型本质上是一个偏好人类认可的模型，它天然倾向给出中性偏正的评价，除非你明确要求它严格。解决办法是按前面3.2节的方式重写评分量表，把每个分数档位写成可观察的行为描述，并在Prompt里加上“敢于给低分”“这是严格评估”这类型约束。 ### 6.2 两两对比时，裁判老是判“打平” 这种问题大多出现在两个答案质量确实接近的场景。如果只是小比例打平，那是正常现象；如果打平比例超过三成，就要考虑是不是评估问题太难了，或者两个对比对象的差异太小。解决办法有三个：一是增加评估维度，从多个维度分别打分而不是只看整体；二是把对比改成“偏好判断”，强制要求裁判必须二选一，即使差别微弱；三是换更强的裁判模型，判别力上来了自然就能分出高下。 ### 6.3 裁判模型自己脑补知识，不该用背景知识时用了 RAG场景下最常见。裁判在评估忠实度时，没有严格按照给它的检索片段来判断，而是动用了自己记忆里的背景知识。这种情况在答案涉及常见知识时就容易发生。解决思路是参考答案式模板里写的那条：“只能按检索片段和用户问题来判断，不得调用你的背景知识”。如果加了这句话还不够，就在Prompt后部再加一个自检步骤，让裁判先列出回答中所有关键事实点，逐条标明在检索片段中的对应位置，再输出分数。把隐含推理过程显式化，能有效压制脑补倾向。 ### 6.4 换了评估维度，评估结果整体漂移 加了某个评估维度之后，其他维度的分数也变了，这是维度间的交叉干扰。比如加了“表达流畅度”这个维度后，裁判把流畅度得分高的答案在相关性上也打了高分。要解决这个问题，可以在Prompt里声明“各维度相互独立，需分别评分”，也可以把维度拆成多次独立的评估调用，每个调用只评估单一维度，最后再合并结果。后者成本更高但隔离效果最好。 ### 6.5 评估结果和人工感受差异很大 如果评估结果跟人类直觉有明显出入，先不要急着怀疑模型选型，先按这个顺序排查：第一步，人工复核是否受了个别样本的干扰，看的是总体趋势还是个别案例；第二步，检查评测集是否偏离真实数据分布，线上问题难易分布和测试集差距过大会导致结果失真；第三步，检查评估Prompt是否有语义模糊的表述，每个维度的描述是否还能制造歧义；最后，才考虑换裁判模型。大多数“AI裁判不靠谱”的情况，排查到最后都发现是Prompt或数据的问题，而不是模型本身的问题。 ### 6.6 一个小众但很实用的小技巧 在做对比式评估时，适当加入一部分已知优劣的“金标校验样本”，比如人工已经判定A明显优于B的样本。评估跑完之后，先看金标样本里的判断是否和已知结论一致。如果连金标样本都判不对，说明整个评估体系存在系统性偏差，后面的统计结果直接作废。这个机制相当于给AI裁判配了一组闭卷考试题，每轮评测自动校验裁判状态。 | 常见问题 | 可能原因 | 排查方向 | 解决手段 | | --- | --- | --- | --- | | 全给高分 | 评分量表模糊 | 检查分数分布 | 重写行为化量表、加严格指令 | | 对比总打平 | 答案相近/判别力不足 | 统计打平比例 | 强制二选一、增加维度、换强裁判 | | 裁判脑补知识 | 背景知识干扰 | 抽查忠实度案例 | 显式自检步骤、强调只用检索片段 | | 维度互相污染 | 指标交叉影响 | 对比单维度/多维度评分 | 声明独立、分维度多次调用 | | 结果偏离人工 | Prompt/数据问题 | 按4步顺序排查 | 先查Prompt和数据再换模型 | | 稳定性差 | 温度参数/模型方差 | 跑多次看方差 | 温度置0、固定随机种子、换稳定模型 | 我个人在实际操作里的一个强烈建议是：永远把LLM-as-Judge评估体系里最关键的那批评估任务设定为“可追溯到人”，也就是每轮评估结束后，自动导出一份人工抽检清单。这样既能监控裁判状态，也能在往上汇报结果时拿出“AI打分+人工抽检”的双重证据。这套做法我已经用了很久，几乎每一次快速定位模型回退问题，靠的都是评估管线里保留的那些人工锚点样本。 最后再分享一个细节：裁判模型的温度参数一定要设置为0。很多人搭LLM应用时习惯保留一定的温度来增加多样性，但这个习惯用到评估场景就是灾难。随机性再小，都会让裁判对完全相同的输入产生不同的评分，本来稳定的评估体系会因此出现莫名其妙的抖动。这个细节不贵，但能让你少踩90%的“评估结果不重现”的坑。