Day 50 / 共 68 天 · 阶段 9 评测（最重要）

LLM-as-Judge：请模型当评委

昨天(Day 49)你用"标准答案是否出现在回答里"打了分——但现实里答案千变万化，"3 到 5 天"和"3-5 个工作日"意思一样却匹配不上。今天学业界最主流的打分手段：让另一个大模型当"评委"给回答打分。你会学会写评分表(rubric)、成对比较，以及最关键的——识别并缓解评委的偏见。明天(Day 51)搭一套完整的指标体系。

📍 你在阶段 9（评测 D49-52）的位置
D49 为什么评测最重要→ D50 LLM-as-Judge→ D51 指标体系→ D52 测试集&回归&CI
💡 用一个类比兜住今天（今天全程沿用「作文竞赛评委」的世界观） LLM-as-Judge = 请一位作文竞赛的评委老师来给回答打分。rubric 评分表=评委手里那张"内容 40 分、条理 30 分、语言 30 分"的打分细则；成对比较=让评委在 A、B 两篇里选更好的一篇(PK 赛)；偏见=评委的坏毛病——偏爱长篇大论、偏爱排在前面的那篇、偏爱自己文风相似的作文。今天你不只是"请评委"，还要学会把评委管好，别让它的偏见污染分数。
L01

为什么要请模型当评委

🤔 痛点昨天的硬匹配("答案 in 回答")对开放式回答完全失灵：润色文案、总结文章、聊天回复，根本没有唯一标准答案，你没法写死一个字符串去比对。
💡 本质开放题需要"读懂意思再判断好坏"——这正是大模型擅长的。LLM-as-Judge = 让一个模型读题目、读回答，像评委老师一样打个分。它能理解"3 到 5 天"和"3-5 个工作日"是一回事，也能判断一段总结抓没抓住重点。
三种判分方式，能力递增 硬匹配 答案 in 回答 快/便宜/但死板 只适合选择题 规则/相似度 正则/关键词/向量 比硬匹配灵活 仍难判"好不好" LLM-as-Judge 模型读懂后打分 能判开放式回答 主流，但要防偏见
图注：不是要抛弃硬匹配——选择题/精确值用硬匹配又快又准；开放题才请评委。两者常常混着用。
👶 用模型评模型，不会又贵又不靠谱吗？确实要花额外的调用成本，也确实会有偏见(后面专门讲)。但相比"雇人一条条读几千个回答打分"，它又快又便宜又能自动化，还能 7×24 跑。业界共识是：LLM-as-Judge 不完美，但在开放题上是目前性价比最高的自动评测手段——关键是你要知道它的坑并对冲掉。
L02

rubric：给评委一张评分表

🤔 痛点你直接问模型"这个回答好不好？"，它今天给 8 分、明天给 6 分，全凭它当时的"心情"，你根本没法用来对比。
💡 本质问题出在没给评委标准。作文竞赛不会只说"看着打分"，而是发一张rubric 评分表：每个维度多少分、什么样算满分、什么样扣分。给了明确的尺子，评委才会打得稳、打得一致。
📝 举个例子：客服回答的 rubric 与其问"好不好"，不如给它这张表：
· 正确性(0-2)：信息是否与知识库一致？编造直接 0 分。
· 完整性(0-2)：有没有答全用户问的所有点？
· 态度(0-1)：语气是否礼貌得体？
总分 5 分。每个维度都写清"几分对应什么"，评委就从"凭感觉"变成"对着尺子量"。

👶 小白：维度是不是越多越细越好？

👨‍🏫 老师：恰恰相反，少而清 > 多而糊。维度太多，评委顾此失彼，分数反而更飘。抓住你最在意的 2-4 个维度，每个维度把"满分/零分长什么样"写具体(最好各给一个例子)，比堆十个模糊维度有用得多。这跟写 prompt 的原则一样：明确 > 冗长。

L03

打分 Prompt：让评委输出能被程序读的分数

🤔 痛点评委洋洋洒洒写一段评语，你的程序怎么从中把"分数"抠出来存进表格？总不能人肉去读吧。
💡 本质让评委用固定的 JSON 格式吐分数(呼应 Day 14 结构化输出)：既给一句理由(方便你复查)，又给一个数字(方便程序统计)。关键三件套：给 rubric、要求先说理由再打分、限定 JSON 输出。
# 用大模型当评委给一个客服回答打分（伪代码：client 是你 Day 11 学的 SDK 客户端）
JUDGE_PROMPT = """你是严格的客服质检评委。按下面评分表给"客服回答"打分。
评分表(rubric)：
- 正确性(0-2)：是否与【知识库】一致，编造记 0 分
- 完整性(0-2)：是否答全用户所有问题
- 态度(0-1)：是否礼貌
请先简短说明理由，再给出各项与总分。
只输出 JSON，格式：{"reason": "...", "correctness": 0, "completeness": 0, "attitude": 0, "total": 0}

【知识库】%s
【用户问题】%s
【客服回答】%s"""

def judge(kb, question, answer):
    prompt = JUDGE_PROMPT % (kb, question, answer)
    resp = client.chat(prompt, temperature=0)   # temperature=0：让评分尽量稳定、可复现
    return json.loads(resp)                      # 解析成字典，total 就能直接入库统计

r = judge("退款 3-5 个工作日到账", "退款要多久？", "一般 3 到 5 天哦，亲~")
print(r["total"], r["reason"])   # 例如 → 5 '信息与知识库一致，答全且礼貌'
两个小细节很重要：① temperature=0 让评委每次打分尽量一致(减少"心情波动")；② 先理由后分数——让模型"想清楚再打分"(呼应 Day 17 思维链)，比直接蹦个数字更可靠，也方便你抽查它有没有乱打。
L04

成对比较：让评委做 PK 而非打绝对分

🤔 痛点你想知道"新 prompt 比旧 prompt 好不好"。但让评委分别打"7.5 分""7.8 分"——这 0.3 分的差距，你敢信吗？绝对分数太飘了。
💡 本质换个问法：把 A、B 两个回答同时给评委，问"哪个更好"。这叫成对比较(pairwise)。就像评委很难说"这篇作文值 82 分"，但"这两篇里哪篇更好"却能答得又快又准。相对判断，比绝对打分稳得多。
绝对打分 vs 成对比较 绝对打分 A→7.5分 B→7.8分 分差小、易受心情影响 难判"到底谁更好" 成对比较(PK) A vs B → "B 更好" 相对判断，稳定清晰 直接得出胜率
图注：跑一批题做成对比较，统计"新版赢了多少%"，就得到一个清晰的胜率——比一堆飘忽的绝对分好用得多。
📝 举个例子：用胜率证明改动有效 拿 50 道题，每道都让评委在"旧 prompt 回答"和"新 prompt 回答"里选更好的。结果新版赢了 38 道、平 6 道、输 6 道——胜率约 76%。这个数字比"平均分从 7.5 涨到 7.8"有说服力得多，写进 PR 描述里，评审一眼就懂。
L05

评委也有偏见：别被它骗了

🤔 痛点你信任评委打的分，但如果评委本身有系统性的坏毛病呢？那你所有决策都建立在被污染的分数上——比没评测还危险，因为你还以为自己很科学。
💡 本质大模型当评委时，会带一些可预测的偏见，就像现实中评委也有偏心。知道有哪些坑，你才躲得开。
偏见它其实在偏爱什么作文竞赛类比
长度偏见更长、更啰嗦的回答，哪怕没更对偏爱洋洋洒洒的长篇
位置偏见成对比较里排前面(或后面)那个先读的那篇印象分更高
自我偏好和评委自己风格像的回答偏爱和自己文风像的学生
措辞偏见语气自信、格式漂亮的，哪怕内容空被漂亮排版和金句唬住
📝 举个例子：位置偏见有多真实 做成对比较时，把同样两个回答测两遍：第一遍 A 在前、B 在后，评委说"A 更好"；第二遍交换位置(B 在前、A 在后)，评委改口说"前面那个更好"——它其实在偏爱"排在前面"的位置，而不是真的偏爱某个回答。如果你不交换位置测一遍，就永远发现不了这个坑。
L06

偏见缓解：把评委管起来

🤔 痛点知道评委有偏见了，那还能用吗？总不能因噎废食全靠人工吧。
💡 本质能用，但要加"防作弊措施"。核心思路：用规则和流程去对冲评委的偏心，就像正规竞赛会匿名评审、交换顺序、多位评委取平均。
手段治哪个偏见怎么做
交换顺序各测一遍位置偏见A/B 和 B/A 都测，只有两次都赢才算真赢
rubric 明确"长≠好"长度/措辞偏见评分表里写死"简洁答对优于啰嗦"
换一家模型当评委自我偏好别用被测模型自己评自己
多评委投票取多数随机波动几个模型/几次打分投票
抽样人工校准整体信任度人工复核一小批，看评委和人是否一致

👶 小白：这么多手段，我一个新手项目全都要上吗？

👨‍🏫 老师：不用一步到位。最低成本、性价比最高的两条先上：① 成对比较时交换顺序各测一遍(治位置偏见，几乎零成本)；② 抽 20-30 条人工复核，看评委打分和你的判断合不合(校准信任度)。这两条能挡掉大部分翻车。面试时你能说出"我知道 LLM-as-Judge 有位置/长度偏见，我用交换顺序和人工抽检来缓解"——这句话的含金量极高，说明你不是盲目信任工具。

L07

今日小结 + 动手 10 分钟

🧠 今天你应该能回答

  • 为什么开放题不能只用硬匹配？LLM-as-Judge 解决了什么？
  • rubric 是什么？为什么"少而清"胜过"多而糊"？
  • 打分 Prompt 的关键三件套是什么？为什么要 temperature=0、先理由后分数？
  • 成对比较为什么比绝对打分稳？"胜率"怎么算？
  • 说出 3 种评委偏见，以及各自的缓解手段。

✋ 动手 10 分钟：给评委写一张 rubric

不需要真调 API，先练"设计评委"这个思维。选一个你熟悉的场景(比如"给菜谱写一段简介")，在纸上或文件里写出：

{
  "场景": "给菜谱写一段 50 字简介",
  "rubric": {
    "准确性(0-2)": "是否忠于原菜谱，不编造食材/步骤",
    "吸引力(0-2)": "读完是否让人想做这道菜",
    "简洁性(0-1)": "是否 50 字左右、不啰嗦（长≠好）"
  },
  "输出格式": {"reason": "一句话理由", "total": "0-5 的整数"},
  "防偏见": ["成对比较时 A/B 交换顺序各测一次", "抽 20 条人工复核"]
}

然后自己扮演评委，给两段简介按这张表打分——体会"有尺子"和"凭感觉"打出来的分，稳定性差多少。

明日预告 · Day 51：今天解决了"单个回答怎么判分"。但一个真实 Agent 的好坏，远不止"答得对不对"——还要看它完成任务的比例、快不快(延迟 P95)、贵不贵(成本)、常怎么错(失败模式)。明天把这些指标搭成一套完整的指标体系，让你能像看体检报告一样全面判断一个 Agent。
← Day 49 · 为什么评测最重要 Day 51 · 指标体系 →