模型评估大模型应用上线前最头疼的问题怎么评估效果人工评估又贵又慢标准还不一致BLEU/ROUGE 这类传统指标对生成式任务基本失效。LLM-as-Judge用大模型当裁判是目前性价比最高的方案但用不好会踩一堆坑。本文是我们在三个项目中沉淀的实战指南。为什么传统指标不行指标 问题 BLEU/ROUGE 依赖字面重叠好的和不错算错换个说法全错 准确率 只适用于有标准答案的任务 人工评估 每千条约 500-1500 元周期 2-3 天标注员之间一致性差生成式任务的答案是开放的同一问题可以有多个正确答案。评判这个回答好不好恰好是大模型擅长的事。基础用法结构化打分JUDGE_PROMPT你是严格的质检员。根据给定标准评估回答质量。 [问题] {question} [参考答案] {reference} [待评回答] {answer} 评估维度 1. 事实正确性与参考答案矛盾则重扣 2. 完整性是否覆盖问题所有要点 3. 格式遵循是否符合要求的输出格式 输出 JSON不要输出其他内容 {{correctness: 1-5, completeness: 1-5, format: 1-5, reason: 一句话理由}}# 温度设 0保证评分稳定scorejudge_llm.generate(JUDGE_PROMPT.format(...),temperature0)三个工程要点用 JSON 约束输出好解析、可统计、温度设 0评分要稳定不要创意、理由必填理由能帮你看懂裁判在扣什么分也显著提升评分质量。四个已知偏差与对策LLM 裁判不完美学界已经确认了四个系统性偏差偏差 表现 对策 位置偏差 偏向对比中的第一个/第二个 同一对答案正反序各评一次取均值 长度偏差 偏向更长的回答 prompt 明确声明简洁不是缺点 自我偏好 偏好自己家族模型的输出 裁判与被评模型用不同家族 权威偏差 被 answer 里的假引用误导 评测时明确参考答案才是事实源位置偏差的对策代码deffair_compare(a,b,question):s1judge(question,a_firsta,b_firstb)# a 在前s2judge(question,a_firstb,b_firsta)# 换序再评return(s1s2)/2## 校准裁判也需要监考上线前必须回答这个裁判可信吗方法是**用人工标注校准** text1.抽100-200条人工和 LLM 裁判同时评分2.算一致率分差 ≤1视为一致85%可用70%需改 prompt 或换裁判3.人工复盘分歧样本把分歧原因写进裁判 prompt 作为补充规则4.版本迭代后重新校准——裁判 prompt 也是代码改了就要回归我们的评估分层日常回归 500 条自动化测试集 LLM-as-Judge每次改动必跑10 分钟 版本对比 2,000 条 双裁判交叉 人工抽检 100 条分歧样本 上线前 灰度流量 线上用户反馈回流闭环验证结论LLM-as-Judge 不是替代人工而是把人工从评每一千条解放到评一百条 写规则。把它当实习质检员用——能力强、要培训、需抽检。用对了评估成本降一个数量级迭代速度翻几倍。