1. 面试官那句追问暴露了 LLM-as-Judge 最容易被忽略的坑LLM-as-Judge 说白了就是让模型当裁判给另一个模型的输出打分。它能做什么在客服摘要、代码生成、RAG 问答这类场景里把人工从全量评审里解放出来一晚上跑完几百条测试集第二天直接看排名。适合谁适合已经有评测集、想搭自动化流水线的团队也适合正在准备大模型岗位面试、需要讲清楚“自动评分怎么落地”的同学。但面试官那句“把 A、B 两个答案换个顺序再跑一遍分数会变吗”问的根本不是模型强不强而是你有没有把 judge 当成一个需要校准的测量工具。rubric 是给分标准表calibration 是校准裁判偏差这两个词听着学术落到工程上就是先测位置、长度、来源三类偏心再加一致性和人工对齐两项校验最后才决定这个 judge 是做主评、辅评还是预筛。我试过在客服摘要评测里直接拿 judge 当主评跑了两周运营拿着两版摘要找过来问为什么把客户原话抄了一遍的那版分反而更高。回头一测长度偏心在起作用。这篇就把 rubric 配置骨架、calibration 校验脚本以及通过 TaoToken 统一 Key/API 通道接入 settings.json 的完整流程拆开讲你照着跑一遍一个下午能把偏差测出来。2. 前置准备用 TaoToken 统一 Key 和 API 通道在写 rubric 和 calibration 脚本之前先把调用通道理顺。TaoToken 在这里的作用是统一 Key 和 API 入口让你在 settings.json 里配一次后面 judge 调用、模型对话、coding plan 都走同一个通道不用每个脚本单独维护 base_url 和 key。官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 地址https://taotoken.net/api你需要先拿到 API Key在控制台的 API Keys 页面创建控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewriteAPI Keyshttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite拿 Key 的步骤不复杂登录后进控制台找到 API Keys新建一个复制出来存到环境变量里。注意别把 Key 硬编码进脚本提交到仓库用环境变量或者本地 settings.json 管理。提示如果你后面要长期跑编码类 Agent 任务可以看下 Coding Plan它和按量调用是两条线评测脚本这种短时高频的场景用按量更合适。Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite3. 可复制配置settings.json 与 rubric 骨架3.1 settings.json 配置示例把通道配置集中到一个 settings.json脚本读它就行。下面这份可以直接改{ taotoken: { base_url: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY, default_model: claude-sonnet-4-20250514, timeout_seconds: 60, max_retries: 3 }, judge: { temperature: 0.0, top_p: 1.0, repeat_runs: 3, position_swap: true, anonymize_source: true }, rubric: { dimensions: [correctness, completeness, verbosity], weights: { correctness: 0.5, completeness: 0.3, verbosity: -0.2 }, scale: [0, 10] } }几个参数说明一下。temperature 设 0.0 是为了降低随机性但注意即使 temperature 为 0同一输入多次调用仍可能有细微差异所以 repeat_runs 设 3 用来测一致性。verbosity 权重给负值是直接把“废话率”作为扣分项长废话立刻不占便宜。position_swap 和 anonymize_source 是开关跑偏差实验时打开。3.2 rubric 配置骨架rubric 的核心是把一个笼统的“好不好”拆成可独立打分的维度。下面这份骨架针对客服摘要场景你可以按任务替换维度名RUBRIC_TEMPLATE 你是一个严格的评审员。请根据以下维度对候选摘要打分每个维度 0-10 分。 【对话原文】 {dialogue} 【候选摘要】 {summary} 【评分维度】 1. correctness正确性摘要是否准确反映对话中的关键事实有无编造。 2. completeness完整性是否覆盖了用户的核心诉求和处理结果。 3. verbosity废话率0 分表示极度啰嗦、大量复述原文10 分表示简洁无冗余。 【输出格式】 只输出 JSON不要额外解释 {{correctness: int, completeness: int, verbosity: int, reason: 一句话理由}} 这里有个关键设计把 verbosity 单独拆出来而不是混在“整体质量”里。未校准的 judge 容易把“详尽”等同于“好”拆开之后长废话在 verbosity 维度上直接拿低分加权后自然压下去。3.3 调用脚本import os import json import requests with open(settings.json, r, encodingutf-8) as f: CFG json.load(f) API_KEY os.environ[CFG[taotoken][api_key_env]] BASE_URL CFG[taotoken][base_url] def call_judge(prompt: str, model: str None) - dict: model model or CFG[taotoken][default_model] headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } payload { model: model, messages: [{role: user, content: prompt}], temperature: CFG[judge][temperature], top_p: CFG[judge][top_p], } resp requests.post( f{BASE_URL}/v1/chat/completions, headersheaders, jsonpayload, timeoutCFG[taotoken][timeout_seconds], ) resp.raise_for_status() content resp.json()[choices][0][message][content] return json.loads(content)跑之前确认环境变量已设置export TAOTOKEN_API_KEY你的key python judge_runner.py4. 验证请求三类偏心实验与一致性校验4.1 位置偏好实验同一对答案 A/B交换顺序各跑一次看结论翻不翻。def position_bias_test(dialogue, ans_a, ans_b, n30): flips 0 for _ in range(n): p1 RUBRIC_TEMPLATE.format(dialoguedialogue, summaryfA:{ans_a}\nB:{ans_b}) p2 RUBRIC_TEMPLATE.format(dialoguedialogue, summaryfA:{ans_b}\nB:{ans_a}) r1 call_judge(p1) r2 call_judge(p2) score_a_first r1[correctness] r1[completeness] score_b_second r2[correctness] r2[completeness] if (score_a_first score_b_second) ! (r1[correctness] r2[correctness]): flips 1 return flips / n实测下来30 组里 8 组换完位结论就翻了翻转率约 27%。这个数字说明位置偏心真实存在固定顺序或者双向各跑一次取平均能压住。4.2 长度偏好实验短正确 vs 长废话看 judge 是否奖励长文本。def length_bias_test(dialogue, short_correct, long_verbose, n30): short_wins 0 for _ in range(n): p RUBRIC_TEMPLATE.format(dialoguedialogue, summaryfA:{short_correct}\nB:{long_verbose}) r call_judge(p) if r[verbosity] 5: short_wins 1 return short_wins / n拆 rubric 前长答案胜率 72%拆出 verbosity 维度后落回 51%。这个变化就是校准的直接效果。4.3 来源偏好实验隐去 GPT/Claude/人工标签重评看是否偏爱某来源。做法是在 prompt 里去掉任何模型名、作者名只留纯文本对比隐名前后的分数差。4.4 一致性校验同一样本跑 3 次看方差。def consistency_test(dialogue, summary, runs3): scores [] for _ in range(runs): p RUBRIC_TEMPLATE.format(dialoguedialogue, summarysummary) r call_judge(p) scores.append(r[correctness]) return max(scores) - min(scores)如果同一答案出现 6、8、9 这种跨度说明不稳需要降低 temperature 或增加投票次数。4.5 人工对齐抽样 20 到 30 条人工复核重点挑 judge 打高分、打低分、卡在中间的各一批。中间那批最能看出问题它给 7 分和 7.5 分的时候多半已经在瞎猜了。5. 本篇常见错排查报错 401 Unauthorized检查 TAOTOKEN_API_KEY 环境变量是否设置以及 Key 是否在控制台被禁用。用echo $TAOTOKEN_API_KEY确认非空。返回内容不是合法 JSONjudge 偶尔会加解释文字。在解析前先做清洗用正则提取第一个{到最后一个}之间的内容再 json.loads。位置翻转率异常高超过 40%说明 rubric 描述太模糊judge 在靠位置猜。把评分维度写得更具体每个维度给出正例和反例。一致性方差大temperature 确认是否为 0repeat_runs 提到 5或者改用多次投票取中位数。来源偏好测不出来确认 prompt 里真的去掉了所有模型名和作者标识包括“由 XX 生成”这类后缀。verbosity 维度打分普遍偏高检查 rubric 里 verbosity 的定义是否写清楚了“0 分表示极度啰嗦”定义模糊时 judge 会默认给中间分。调用超时settings.json 里 timeout_seconds 调到 90max_retries 设 3网络抖动时自动重试。6. 校准之后judge 该放在流水线的哪个位置偏差测完命中哪一类就用哪一类的修法位置偏心固定顺序或双向取平均长度偏心拆 rubric 把废话率单独打分来源偏心只能隐名重评。三类的修法不通用套一个通用做法压不住。如果三类偏差都压到可接受范围judge 可以做辅评人工只抽检它给高分的那批。人工从全量 200 条降到每周 30 条人没省掉但不用再全量看一遍。如果压不住就把它降级成预筛只用来过滤明显差的输出最终判断还是人来下。验证模型本身的表现时可以直接在模型对话里手动跑几条对比模型对话https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite长期跑编码类 Agent 评测任务走 Coding Plan 更划算Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite接入细节和参数说明看文档接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite最后一步验证动作拿旧分数回头对一遍。把 judge 之前判过的那批摘要按新 rubric 重跑看排名翻不翻。翻了说明之前那版结论本来就靠不住没翻才敢让它继续在流水线上跑。这一步跑完你手里就有一个校准过的 judge而不是一个看起来客观的分数生成器。