中 进阶
LLM评测方法#
一句话答案#
LLM 评测结合自动指标（BLEU/ROUGE）、LLM-as-Judge（强模型评分）、人工评估和公开基准测试（MMLU-Pro/GPQA/SWE-bench Pro 等，老基准如 MMLU/HumanEval 已接近饱和）。
核心要点
评测方法全景：
| 层次 | 方法 | 适用场景 | 成本 | 局限 |
|---|---|---|---|---|
| 自动指标 | BLEU/ROUGE（n-gram 重叠度） | 翻译/摘要粗筛 | 极低 | 只衡量表面相似度 |
| LLM-as-Judge | 强模型（通常用与被测模型不同家族的旗舰模型）给回答打分 | 开放式生成评估 | 中 | 有评判偏差 |
| 公开基准 | MMLU（57 学科）、HumanEval（代码）；更难的 MMLU-Pro、GPQA、SWE-bench Pro 等 | 模型能力横评 | 低 | 静态题库，易饱和、易污染 |
| 人类偏好榜单 | Arena（原 Chatbot Arena / LMArena）：匿名两两对战 + 用户投票，Bradley-Terry 排名 | 通用对话体验横评 | 低（用现成榜单） | 偏好不等于正确；存在刷榜和风格偏好争议 |
| 人工评估 | 标注员多维度打分 | 关键场景抽检 | 高 | 慢、主观、难规模化 |
LLM-as-Judge 三大偏差：
- 长度偏好：倾向给更长的回答打高分 → 控制回答长度后对比
- 位置偏差：先出现的回答更易获高分 → 随机打乱顺序
- 自我增强：同家族模型互评分数虚高 → 用不同家族模型交叉评判
RAG 专项评测（Ragas 框架）：
| 指标 | 评测对象 | 含义 |
|---|---|---|
| Faithfulness | 生成端 | 回答是否完全基于召回文档（检测幻觉） |
| Response Relevancy（旧版叫 Answer Relevancy） | 生成端 | 回答是否切题 |
| Context Precision | 检索端 | 召回文档中相关的占比 |
| Context Recall | 检索端 | 相关文档被召回的比例 |
常见评测流水线：
- 自动指标快速迭代（每次 Prompt 修改后跑）
- LLM-as-Judge 细评（每周/每版本）
- 人工抽检关键 case（上线前）
面试回答（2分钟版）
LLM评测需要多维度结合，没有单一银弹。第一层是自动指标，BLEU和ROUGE通过计算生成文本和参考答案的n-gram重叠度来评分，速度快成本低，但只能衡量表面相似度，对开放式生成不够准确。第二层是LLM-as-Judge，用一个强模型给其他模型的回答打分，平衡了成本和评估质量，但需要注意评判模型本身的偏差（比如偏好长回答）。第三层是人工评估，最准确但成本最高速度最慢，适合关键场景抽检。公开基准方面，MMLU测通用知识广度覆盖57个学科，HumanEval测代码生成能力，但头部模型已接近满分，现在更多看MMLU-Pro、GPQA、SWE-bench Pro这类更难、更抗污染的基准；Arena这类人类偏好榜单反映对话体验，不等于任务正确率。落地时建议组合使用：先用自动指标做粗筛快速迭代，再用LLM-as-Judge做细评，最后人工抽检关键case。对于RAG系统还要额外评测检索召回率和答案的忠实度（是否基于检索内容回答而非编造）。
追问与易错
追问方向：
- LLM-as-Judge 的偏差怎么纠正？ → 三招：随机打乱回答顺序（消位置偏差）、控制回答长度后对比（消长度偏好）、用不同家族模型交叉评判（消自我增强）
- RAGAS 评测集怎么构建？需要多少条？ → 从真实文档人工编写 QA 对（Question + Ground Truth + Source Chunk），覆盖直接命中/跨段落/多跳三种难度。最少 50 条起步，按问题类别分层（事实型、多跳、对抗、无答案等）保证每类都有样本。结合项目时可以讲：评测集怎么分类、每类多少条、为什么这么分
- 自动指标和人工评估不一致时怎么办？ → 以人工评估为准（金标准），分析不一致的 case 找规律——通常是自动指标的评估维度不够（如 BLEU 不评逻辑正确性）
- 怎么评测 RAG 系统的检索质量和生成质量？ → 检索看 Recall@K 和 MRR（文档是否找到且排名靠前），生成看 Faithfulness（是否基于检索内容）和 Relevance（是否切题）。用 Ragas 等框架自动化
易错点：
- ❌ “BLEU/ROUGE 能评所有任务” → 只适合有标准答案的场景，开放式生成不适用
- ❌ “LLM-as-Judge 完全客观” → 有长度偏好、位置偏差和自我增强三大偏差
- ❌ “基准测试分数高=实际效果好” → 静态题库易过拟合、易被训练数据污染（OpenAI 2026 年 2 月起不再报告 SWE-bench Verified，理由就是饱和和污染），需结合领域实测