1. 为什么你的 LLM-as-Judge 跑第二遍就对不上做评测的人迟早会撞上这个场景第一次跑出来 A 版本胜率 62%隔天重跑变成 48%代码一行没改。你去翻日志发现昨天用的是某个渠道的 key今天换成了另一个裁判模型昨天是gpt-4o今天手滑写成了gpt-4o-mini温度参数在某个脚本里是 0在另一个脚本里忘了设默认 1.0。结果就是——你根本不知道分数变化是模型真的变好了还是调用链路变了。LLM-as-Judge 的核心思路很直白让一个 LLM 去评价另一个 LLM 的输出。Pointwise 打分适合监控单系统质量趋势Pairwise 对比适合 Prompt A/B 测试。但真正落地时最容易被忽略的不是 prompt 写得好不好而是工程层面的可复现性。裁判模型和被评模型的调用通道如果不分离、不统一你的评测结果就是一次性的没法复跑、没法对比、没法追责。这篇要解决的问题很具体用 TaoToken 的统一 Key 和 API 通道把裁判模型和被评模型放在同一套配置里管理交付一份可复制的config.toml骨架然后跑通 20 条样本输出一张评分一致性对比表。适合正在搭本地评测脚本、被多 Key 切换折磨过的工程师。2. TaoToken 前置统一 Key 解决通道分离问题2.1 为什么裁判和被评要走同一个入口传统做法是裁判用 OpenAI 的 key被评模型用另一家的 key两边 SDK 不同、base_url 不同、重试逻辑不同。一旦要复跑你得同时保证两边的 key 都没过期、额度都够、区域都能访问。任何一个环节变了评测结果就不可比。TaoToken 的做法是提供一个统一的 API 入口你只需要一个 Key就能在同一个base_url下调用不同厂商的模型。裁判模型选gpt-4o被评模型选glm-4-flash两者都走同一个通道配置里只改模型名不改调用方式。这样复跑时变量只剩模型名和 prompt 版本通道本身是常量。注意统一通道不等于统一模型。裁判模型建议选比被评模型更强的避免自我偏见——同一个模型既生成又评分会系统性高估自己的输出。2.2 拿到 Key 和接入信息访问 TaoToken 官网注册后进入控制台创建 API Key。接入文档里有完整的 base_url 和兼容说明。你需要记下两个地址官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 地址https://taotoken.net/api这个不加 UTM直接用于代码里的 base_urlKey 创建后只显示一次复制到本地环境变量里别硬编码进脚本。我习惯用.env文件加python-dotenv或者直接在 shell 里 export。export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api2.3 模型选择的基本盘裁判模型建议用gpt-4o或claude-sonnet-4-6这类强模型被评模型可以用glm-4-flash这类性价比高的。温度方面裁判模型必须设 0 或接近 0减少评分随机性被评模型按你实际业务场景设评测生成质量时通常也设 0保证可复现。并发数别一上来就拉满。20 条样本如果每条要调 2 次裁判被评并发 5 左右比较稳既能跑得快又不容易触发限流。3. 可复制配置config.toml 骨架与调用封装3.1 config.toml 完整骨架把评测的所有变量收进一个配置文件是复现的第一步。下面这份骨架覆盖了裁判模型、被评模型、温度、并发数、prompt 版本号。# config.toml [api] base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY timeout 60 max_retries 3 [judge] model gpt-4o temperature 0.0 max_tokens 512 prompt_version v1.2 [subject] model glm-4-flash temperature 0.0 max_tokens 1024 [run] concurrency 5 samples_file samples.jsonl output_file results.jsonl rounds 3 # Pairwise 随机化轮数prompt_version这个字段很关键。裁判 prompt 改一个字分数分布就可能变。把版本号写进配置结果落盘时一起存复跑时能对上号。3.2 裁判 Prompt 模板带版本管理裁判 prompt 单独放一个文件按版本号命名比如prompts/judge_v1.2.txt。内容参考生产可用的设计1-5 分而非 1-10 分降低方差明确声明长度不影响评分要求返回 JSON 并解释最低分维度。你是一个严格的技术内容评审员。 评估规则 - 评分范围 1-5不是 1-10 - 长度不影响评分只评估内容质量 - 模糊或冗长不是优点清晰简洁是优点 - 3 分代表达到预期不是还行 评分维度各 1-5 分 1. 准确性技术内容是否正确有无事实错误 2. 相关性是否直接回答了问题有无跑题 3. 实用性用户能否根据这个回答解决实际问题 问题{question} 回答{answer} 以 JSON 返回不要其他内容 {accuracy: int, relevance: int, usefulness: int, reasoning: 一句话说明最低分维度的原因}3.3 调用封装一个 client 走两个模型用 OpenAI 兼容的 SDK把 base_url 指向 TaoToken裁判和被评共用同一个 client 实例只是调用时传不同的 model 名。import os import json import tomllib from openai import OpenAI with open(config.toml, rb) as f: cfg tomllib.load(f) client OpenAI( api_keyos.environ[cfg[api][api_key_env]], base_urlcfg[api][base_url], timeoutcfg[api][timeout], max_retriescfg[api][max_retries], ) def call_model(model, temperature, max_tokens, messages): resp client.chat.completions.create( modelmodel, temperaturetemperature, max_tokensmax_tokens, messagesmessages, ) return resp.choices[0].message.content def judge_answer(question, answer, prompt_template): prompt prompt_template.format(questionquestion, answeranswer) raw call_model( cfg[judge][model], cfg[judge][temperature], cfg[judge][max_tokens], [{role: user, content: prompt}], ) return json.loads(raw)这里call_model是唯一的出口裁判和被评都走它。复跑时只要config.toml不变调用链路就是确定的。3.4 结果落盘每条记录带上版本指纹落盘时别只存分数把模型名、温度、prompt 版本、时间戳一起写进去。这样两张结果表放一起你能立刻看出差异来自哪里。import time import hashlib def run_fingerprint(cfg): raw f{cfg[judge][model]}|{cfg[judge][prompt_version]}|{cfg[subject][model]}|{cfg[judge][temperature]} return hashlib.md5(raw.encode()).hexdigest()[:8] def save_result(f, sample_id, question, answer, scores, fingerprint): record { sample_id: sample_id, question: question, answer: answer, scores: scores, fingerprint: fingerprint, ts: int(time.time()), } f.write(json.dumps(record, ensure_asciiFalse) \n)4. 验证请求跑通 20 条样本并输出一致性对比表4.1 准备样本文件samples.jsonl每行一条包含id和question。被评模型的回答在脚本里现场生成这样能同时验证生成和评分两条链路。{id: s001, question: Python 里列表和元组的区别是什么} {id: s002, question: 解释一下 HTTP 和 HTTPS 的主要差异。} {id: s003, question: 什么是数据库索引什么时候不该建索引}4.2 主流程生成 评分 落盘import concurrent.futures def process_one(sample, prompt_template, fingerprint): q sample[question] answer call_model( cfg[subject][model], cfg[subject][temperature], cfg[subject][max_tokens], [{role: user, content: q}], ) scores judge_answer(q, answer, prompt_template) return sample[id], q, answer, scores def main(): with open(cfg[run][samples_file], encodingutf-8) as f: samples [json.loads(line) for line in f if line.strip()] with open(fprompts/judge_{cfg[judge][prompt_version]}.txt, encodingutf-8) as f: prompt_template f.read() fingerprint run_fingerprint(cfg) results [] with concurrent.futures.ThreadPoolExecutor(max_workerscfg[run][concurrency]) as ex: futures [ex.submit(process_one, s, prompt_template, fingerprint) for s in samples] for fut in concurrent.futures.as_completed(futures): results.append(fut.result()) with open(cfg[run][output_file], w, encodingutf-8) as f: for sid, q, a, sc in results: save_result(f, sid, q, a, sc, fingerprint) print(f完成 {len(results)} 条fingerprint{fingerprint}) if __name__ __main__: main()4.3 一致性对比表跑完后用一个小脚本把两次运行的结果对齐算每个维度的平均分和标准差以及两次运行之间的分数差异。import json import statistics def load_results(path): with open(path, encodingutf-8) as f: return {json.loads(l)[sample_id]: json.loads(l) for l in f if l.strip()} def compare(run_a, run_b): dims [accuracy, relevance, usefulness] print(f{维度:12}{RunA均值:10}{RunB均值:10}{差值:8}{一致率:8}) for d in dims: a_vals [run_a[k][scores][d] for k in run_a] b_vals [run_b[k][scores][d] for k in run_b] same sum(1 for k in run_a if run_a[k][scores][d] run_b[k][scores][d]) rate same / len(run_a) print(f{d:12}{statistics.mean(a_vals):10.2f}{statistics.mean(b_vals):10.2f} f{statistics.mean(b_vals)-statistics.mean(a_vals):8.2f}{rate:8.2%}) run_a load_results(results_run1.jsonl) run_b load_results(results_run2.jsonl) compare(run_a, run_b)实测下来温度设 0、prompt 版本一致的情况下两次运行的维度一致率能到 85% 以上。如果低于 70%优先检查温度是不是没设 0或者裁判模型是不是被换了。4.4 成功结果长什么样一次正常的输出大概是这样完成 20 条fingerprinta3f9c2e1 维度 RunA均值 RunB均值 差值 一致率 accuracy 4.10 4.05 -0.05 90.00% relevance 4.35 4.30 -0.05 85.00% usefulness 3.95 4.00 0.05 85.00%差值在 ±0.1 以内、一致率 85% 以上说明你的评测链路是稳的。如果某个维度一致率明显偏低去看reasoning字段通常是该维度的评分标准有歧义。5. 本篇常见错排查5.1 报错 401 或 403先确认环境变量TAOTOKEN_API_KEY有没有被正确加载。在 Python 里print(os.environ.get(TAOTOKEN_API_KEY)[:8])看一眼前缀。如果是在 IDE 里跑注意 IDE 可能不继承 shell 的 export需要在运行配置里单独设。5.2 裁判返回的不是合法 JSON裁判模型偶尔会在 JSON 外面包一层 markdown 代码块或者加一句以下是评分结果。两个解法一是在 prompt 里强调不要其他内容二是代码里做容错解析。import re def parse_judge_output(raw): raw raw.strip() raw re.sub(r^(?:json)?\s*, , raw) raw re.sub(r\s*$, , raw) try: return json.loads(raw) except json.JSONDecodeError: m re.search(r\{.*\}, raw, re.DOTALL) if m: return json.loads(m.group(0)) raise5.3 两次运行结果差异大按这个顺序查温度是不是都设了 0prompt_version是不是一致裁判模型名有没有被改fingerprint两次是不是一样。如果 fingerprint 不同说明配置变了结果不可比。5.4 并发跑的时候偶发超时把concurrency降到 3 试试或者把timeout从 60 提到 90。有些模型在长回答生成时耗时波动大超时设太紧会误杀。另外max_retries设 3 能兜住大部分瞬时抖动。5.5 评分分布过度集中如果 90% 的样本都打了 4 分说明裁判区分度不够。两个方向换更强的裁判模型或者在 prompt 里明确3 分代表达到预期把中间档的定义钉死。也可以把 1-5 分改成 1-4 分强制裁判做选择。6. 把评测链路固定下来LLM-as-Judge 的坑一半在 prompt一半在工程。prompt 的偏见可以靠随机化、分维度、反冗长声明来缓解工程的不可复现只能靠统一通道、配置外置、版本指纹来根治。用 TaoToken 的统一 Key 把裁判和被评放在同一个入口config.toml管住所有变量结果落盘带上 fingerprint这套组合下来你的评测才敢拿去做发布决策。下一步可以做的把rounds用起来对 Pairwise 做多轮随机化算胜率而不是单次判断或者把结果表接到一个简单的看板上每次跑完自动对比上一版。需要长期跑编码类评测、或者把裁判接进 Agent 工作流的可以看看 Coding Plan 的额度方案想先手动验证几个模型的裁判表现直接去模型对话里试 prompt 最快。接入细节和参数说明在接入文档里都有Key 在 API Keys 页面创建。