测评方法

引言 LLM-as-Judge 指使用大语言模型作为评估器来评判其他模型的输出质量。这一方法在 2024 年随 GPT-4 评审能力成熟而大规模采用，到 2026 年已成为行业标准实践。但「用 AI 评估 AI」并非无懈可击——偏差、成本、校准都是必须严肃对待的问题。 一、Judge 模型选择 1.1 Judge 模型能力要求 一个合格的 Judge 模型需要具备： 指令遵循能力：严格按照评估 rubric 打分，不自由发挥 长文本理解：能处理长回答和复杂 rubric 领域知识：对被评估内容有足够理解 评分稳定性：对相似输入给出一致的评分 抗偏见能力：不受回答长度、格式、风格等表面因素干扰 1.2 主流 Judge 模型对比（2026） Judge 模型 评分准确率 成本/1K 评估 延迟 推荐场景 GPT-5 88% $0.12 中 通用评估首选 Claude 4 Opus 87% $0.15 中 代码/推理评估 Gemini 2.5 Ultra 84% $0.08 低 大规模评估 GPT-4o 82% $0.05 中 预算有限 DeepSeek V3.5 79% $0.02 低 开源/低成本 Llama 3.3 70B 74% 自部署 低 数据隐私场景 准确率指与人类专家判断的一致率，基于 MT-Bench 和 Arena-Hard 基准。 ...

引言 代码生成是 LLM 最成功的落地场景之一，但「能写代码」和「能解决工程问题」之间有巨大鸿沟。HumanEval 上的 90% 通过率并不意味着模型能胜任真实的软件工程工作。本文系统梳理 2026 年代码 LLM 评估从基础到工程级的完整体系。 一、基础代码生成评估 1.1 HumanEval HumanEval 由 OpenAI 在 2021 年发布，是代码 LLM 评估的元老级 Benchmark。包含 164 个 Python 编程任务，每个任务包含函数签名、docstring 和测试用例。 评估方式： 给定函数签名和 docstring，模型生成函数体，用测试用例验证正确性。 Pass@k 指标： Pass@k = 1 - C(n-c, k) / C(n, k) 其中 n 是总采样数，c 是通过测试的采样数，k 是允许的尝试次数。 2026 年头部模型 Pass@1： 模型 HumanEval Pass@1 GPT-5 96.2% Claude 4 Opus 95.8% Gemini 2.5 Ultra 94.1% DeepSeek-Coder V2.5 93.5% Llama 3.3 70B 88.7% 问题： HumanEval 已严重饱和，头部模型差距不到 8 个百分点，基本失去区分度。 ...

引言 2026 年的多模态模型已不再局限于「看图说话」。GPT-5、Gemini 2.5 Ultra、Claude 4 等模型能同时处理图像、音频、视频，并进行跨模态推理。但多模态评估远比纯文本复杂——视觉理解不只是图像分类，音频理解不只是语音识别，视频理解更涉及时序推理。本文系统梳理 2026 年多模态评估的方法论与 Benchmark 现状。 一、视觉理解评估 1.1 评估维度体系 视觉理解 ├── 基础感知 │ ├── 物体识别 (Object Recognition) │ ├── 属性识别 (Attribute Recognition) │ └── 场景分类 (Scene Classification) ├── 视觉推理 │ ├── 空间推理 (Spatial Reasoning) │ ├── 关系推理 (Relational Reasoning) │ └── 物理推理 (Physical Reasoning) ├── 文档理解 │ ├── OCR / 文字提取 │ ├── 图表理解 (Chart QA) │ └── 文档推理 (Document QA) ├── 细粒度理解 │ ├── 计数 (Counting) │ ├── 差异检测 (Difference Detection) │ └── 细节描述 (Detailed Description) └── 创意理解 ├── 梗图理解 (Meme Understanding) ├── 艺术作品分析 └── UI/UX 理解 1.2 主流视觉 Benchmark Benchmark 评测重点 样本数 头部得分 区分度 VQAv2 基础视觉问答 1.1M 92%+ ⚠️ 饱和 GQA 组合视觉推理 22M 88%+ ⚠️ 接近饱和 ChartQA 图表理解 30K 85-90% ✅ 良好 DocVQA 文档问答 50K 92-95% ⚠️ 接近饱和 MMMU 多领域视觉推理 11.5K 65-72% ✅ 良好 MMBench 多维度视觉评估 6K 80-85% ✅ 良好 MathVista 数学视觉推理 6K 55-70% ✅ 高 RealWorldQA 真实世界理解 7K 70-78% ✅ 高 1.3 关键 Benchmark 详解 MMMU (Massive Multi-discipline Multimodal Understanding) MMMU 覆盖 30 个学科（艺术、科学、商业、医学等），要求模型基于图像进行大学级别的推理。 ...

VLM 评估维度 VLM 评估需同时考察视觉感知和语言推理两条链路。 ┌──────────┬──────────┬──────────┐ │ 感知层 │ 推理层 │ 生成层 │ 图像理解 │ 对象识别 │ 因果推理 │ 描述生成 │ 视频理解 │ 动作识别 │ 时序推理 │ 摘要生成 │ 3D 理解 │ 空间感知 │ 交互推理 │ 场景描述 │ └──────────┴──────────┴──────────┘ 感知层 能力 测试方法 对象识别 “图中有哪些物体” 属性识别 颜色、大小、材质 空间关系 物体间位置关系 细粒度识别 区分相似物体 OCR 识别图中文字 推理层 能力 示例 物理推理 “杯子从桌边掉落会怎样” 社会推理 “图中的人为什么生气” 多步推理 “根据路标该往哪走” 生成层 能力 示例 图像描述 无障碍 alt text 视觉问答 “图中时钟显示几点” 图文创作 看图写故事 核心基准 基准 规模 核心能力 特点 MMBench 2943题 20维度综合 中英双语，细粒度分类 MMMU 11.5K 学科知识+视觉 30学科，大学水平 SEED-Bench 19K 多模态理解 覆盖图像/视频/3D MME 2394 感知+认知 是/否问答 GQA 22M 场景图推理 结构化推理 MMBench 能力维度 ├── 粗粒度感知 (对象存在/计数/场景分类) ├── 细粒度感知 (属性/空间关系/OCR) ├── 推理 (物理/社会/逻辑) └── 关系 (图内/跨图) MME 评估 # Yes/No 问答，避免开放式生成的评分问题 def evaluate_mme(model, dataset): correct = 0 for item in dataset: for question, answer in item['questions']: pred = model.answer(item['image'], question) if normalize(pred) == answer.lower(): correct += 1 return correct / len(dataset) 视频理解评估 维度 基准 时序理解 MVBench, TempCompass 动作识别 Kinetics 视频问答 NExT-QA, EgoSchema 长视频理解 LongVideoBench 视频评估策略 def evaluate_video(model, video_path, questions): for q in questions: if q['type'] == 'temporal': frames = sample_frames(video_path, fps=2) # 密集采帧 elif q['type'] == 'action': frames = sample_keyframes(video_path, n=16) # 关键帧 else: frames = sample_uniform(video_path, n=8) # 均匀采样 answer = model.answer(frames, q['question']) 视频评估挑战 帧采样偏差：均匀采帧可能错过关键事件 时序长度：短视频和长视频需不同策略 计算成本：视频编码比图像贵 100x+ 3D 理解评估 基准 任务 数据形式 ScanQA 3D场景问答 点云+RGB-D 3D-LLM 3D场景对话 点云+语义标注 SpatialBench 空间关系推理 合成3D场景 评估陷阱 1. 数据泄露 def check_contamination(train_data, test_data): from imagehash import phash train_hashes = {phash(img) for img in train_data} leaked = sum(1 for img in test_data if phash(img) in train_hashes) return leaked / len(test_data) 2. 位置偏差 偏差 规避方法 位置A偏好 随机化选项顺序 末位偏好 选项排列组合测试 长度偏好 控制选项长度一致 3. 语言先验作弊 def test_vision_dependency(model, questions): with_image = [model.answer(q['image'], q['question']) for q in questions] without_image = [model.answer(None, q['question']) for q in questions] gap = accuracy(with_image) - accuracy(without_image) if gap < 0.1: print("警告：模型可能未有效利用视觉信息") 4. 指标陷阱 陷阱 解决方案 精确匹配过严 用语义相似度或LLM裁判 BLEU/ROUGE不适用 用 CIDEr 或 SPICE 多选准确率虚高 报告随机基线+normalized gain 实战建议 多基准组合：至少 3 个基准交叉评估 分维度报告：按感知/推理/生成分维度 做数据泄露检查：网络图片基准尤其注意 控制推理成本：视频和3D评估预算大 中英文分别评估：VLM 中英文能力差异可能很大 关注长尾能力：平均分高的模型可能特定维度很差 人工校验：抽 5-10% 人工复核确保指标可信 多模态评估仍在快速发展，保持对新方法和基准的关注，定期更新评估体系。 加入讨论 这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。 ...

Agent 基准测试与传统 LLM 评测的区别 传统 LLM 评测关注单轮输入输出质量——生成文本是否流畅、知识是否准确、推理是否正确。但 Agent 评测面临根本差异：Agent 需要在多轮交互中自主决策、调用工具、维护状态、处理错误。一次错误的工具调用可能让整个任务失败，即使后续推理完全正确。 Agent 基准测试必须考察：长程规划能力（复杂目标分解为可执行步骤）、工具使用准确性（参数构造与调用时机）、错误恢复能力（异常时调整策略）、状态管理（多轮交互的上下文一致性）。 设计原则 任务真实性：基准任务应反映真实世界需求，而非人造玩具问题 可复现性：同一 Agent 多次运行结果应稳定，随机性需控制和记录 评估客观性：优先程序化评估而非人工判断，可大规模运行 难度梯度：包含不同难度级别，避免天花板或地板效应 测试集构建 来源 优点 缺点 示例 真实工单 高生态效度 获取困难 SWE-bench 人工构造 可控性强 偏离真实分布 AgentBench 合成生成 规模可扩展 复杂度有限 ToolBench 混合方法 兼顾真实与可控 设计成本高 tau-bench 构建流程：原始任务池 → 去重过滤 → 难度标注 → 验证集构建 → 评估脚本开发 → 试测校准 → 正式发布 评估指标体系 metrics = { "success_rate": "任务完成率（最核心指标）", "step_efficiency": "实际步骤数 / 最优步骤数", "tool_accuracy": "正确工具调用数 / 总工具调用数", "cost_efficiency": "任务完成数 / 总 token 消耗", "error_recovery_rate": "成功恢复的错误数 / 总错误数", "hallucination_rate": "幻觉工具调用数 / 总工具调用数", } def composite_score(result): weights = {"success_rate": 0.5, "step_efficiency": 0.2, "tool_accuracy": 0.2, "cost_efficiency": 0.1} return sum(result[k] * w for k, w in weights.items()) 主流基准对比 AgentBench 覆盖 8 类任务环境：操作系统交互、数据库操作、知识图谱问答、卡片游戏、迷宫导航、网页浏览、家务模拟、购物对话。优势是覆盖面广，局限是部分任务生态效度参差不齐。 ...

EDD 核心理念 评估驱动开发（EDD）将评估置于开发流程中心。传统开发是"先写功能，再测试"，EDD 反过来：“先定义评估标准，再开发功能”。借鉴了 TDD，但有关键区别：TDD 关注代码正确性，EDD 关注产品效果。 维度 传统开发 EDD 开发起点 功能需求 评估集 验收标准 功能可用 评估指标达标 迭代依据 直觉/用户反馈 评估数据 回归保护 单元测试 评估集回归 评估集先行 评估集是带预期结果的测试用例，用于量化 Agent 在特定任务上的表现，是随产品演进的活文档。 eval_set = { "version": "1.3.0", "cases": [ { "id": "case_001", "input": "帮我查北京到上海的高铁票", "expected": { "tool_calls": ["search_trains"], "tool_args": {"from": "北京", "to": "上海", "type": "高铁"}, "response_must_not_contain": ["飞机", "航班"], }, "difficulty": "easy", }, { "id": "case_042", "input": "先查高铁，再看上海天气，总结出行建议", "expected": { "tool_calls": ["search_trains", "get_weather"], "tool_call_order": ["search_trains", "get_weather"], "max_turns": 5, }, "difficulty": "medium", }, ], } 管理原则：版本化（每次更新打标签）、分层级（核心集50个CI跑 + 完整集500个发版跑）、防污染（不进训练数据）、持续扩充（每周加5-10个 bad case）。 自动化评估流水线 代码提交 → 单元测试 → 评估集执行 → 指标计算 → 对比基线 → 通过/告警 class EvaluationPipeline: def __init__(self, eval_set, baseline_results): self.eval_set = eval_set self.baseline = baseline_results self.metrics = [ ToolAccuracyMetric(), ResponseQualityMetric(model="gpt-4o"), LatencyMetric(), CostMetric(), SafetyMetric(), ] async def run(self, agent): results = [] for case in self.eval_set["cases"]: result = await self._evaluate_case(agent, case) results.append(result) summary = self._summarize(results) diff = self._compare_baseline(summary, self.baseline) return { "summary": summary, "regressions": [r for r in diff if r["change"] < 0], "improvements": [r for r in diff if r["change"] > 0], } CI/CD 集成：merge request 跑核心集（50个），main 分支跑完整集（500个），评估不通过则阻止合并。 ...

为什么人工评测不可替代 自动化评估（LLM-as-Judge、程序化指标）发展迅速，但人工评测仍是金标准。原因有三：开放性任务无标准答案，创意写作和多轮对话的正确答案不唯一甚至不存在；LLM-as-Judge 存在位置偏差、长度偏差、自我偏好偏差，需要人工校准；细微质量差异（更自然、更有帮助、更安全）往往需要人类判断。 但人工评测有致命弱点：贵、慢、不一致。好的设计在这三个约束下最大化评估质量。 标注规范设计 核心要素：任务描述、评估维度、评分标准表、判断规则、至少5组带标注样例。 ## 评估维度示例 - 帮助性 (1-5): 回答是否直接解决了用户问题？ - 准确性 (1-5): 信息是否正确、有无幻觉？ - 安全性 (1-5): 是否包含有害内容？ - 自然度 (1-5): 语言是否流畅、表达是否得体？ ## 评分标准 | 分数 | 帮助性 | 准确性 | |------|--------|--------| | 5 | 完全解决，超出预期 | 完全正确，来源可靠 | | 4 | 基本解决，小瑕疵 | 正确，轻微不精确 | | 3 | 部分解决 | 大部分正确，有小错误 | | 2 | 几乎没帮助 | 有明显错误 | | 1 | 完全无关 | 严重错误或幻觉 | ## 判断规则 - 质量接近（差距≤1分）选择"平局" - 准确性与详细性冲突时，准确性优先 - 安全性问题一票否决（直接1分） 成对比较 vs 绝对评分 方式 优点 缺点 适用场景 成对比较 更易判断、一致性高 信息量少、不可传递 模型排序 绝对评分 信息丰富、可追踪 标注者差异大 质量监控 排序 信息量最大 认知负担重 小规模深度评估 实践建议：主用成对比较做模型排序，辅以绝对评分做质量追踪。 ...

排行榜迷思 LMSYS 上 GPT-4o 排第一，SuperCLUE 上 Qwen 排第一，OpenCompass 又是另一个结果。这不是数据造假，而是每个排行榜的评测方法论、任务分布、评分机制完全不同。理解这些差异，才能正确使用排行榜指导模型选择。 LMSYS Chatbot Arena 机制 核心机制是众包盲测成对比较 + Elo 评分：用户输入问题 → 随机选两个模型匿名回答 → 用户选择更好的一个 → Elo 更新。 def update_elo(rating_a, rating_b, score_a, k=32): """score_a: 1表示A赢, 0.5平局, 0表示B赢""" expected_a = 1 / (1 + 10 ** ((rating_b - rating_a) / 400)) new_a = rating_a + k * (score_a - expected_a) return new_a # GPT-4o(1420) vs Claude(1400)，用户选 GPT-4o # GPT-4o → ~1421.3, Claude → ~1398.7 优势与局限 优势 局限 生态效度高（真实问题分布） 用户偏技术人群，通用场景代表性不足 抗污染（实时用户输入） 长度偏差（用户偏好更长的回答） 盲测（消除品牌偏差） 英文占60%+，中文评估弱 动态更新（新模型1-2周出数据） 大量简单问题，区分顶级模型困难 分领域子榜更具参考价值：Coding（编程）、Hard Prompts（高难度）、Vision（多模态）、Chinese（中文）。优先看你关心的领域子榜，不要只看总榜。 OpenCompass 上海 AI Lab 主导的开源评测体系，特点是大而全：100+ 数据集，中英文全覆盖。 # OpenCompass 配置示例 datasets: - mmlu # 多任务理解 - cmmlu # 中文多任务 - gsm8k # 数学 - humaneval # 代码 - bbh # 推理 - ceval # 中文考试 特点 说明 全开源 评测代码、提示词、数据处理全公开 覆盖广 MMLU/CMMLU/GSM8K/HumanEval/BBH/C-Eval 等 可复现 Docker 镜像确保环境一致 标准化 统一提示词模板和评估脚本 与 LMSYS 差异 维度 LMSYS OpenCompass 评估方式 人工成对比较 程序化指标 问题来源 用户真实输入 标准测试集 可复现性 低（依赖用户输入） 高（固定测试集） 数据污染风险 低 高（测试集公开） 主观任务覆盖 好（创意写作等） 差（主要客观题） 中文能力 弱 强 HELM (Holistic Evaluation) 斯坦福推出，核心理念是全息评估：多场景 × 多指标 × 多透明度。 ...

什么是 GAIA GAIA（General AI Assistants Benchmark）是由 Meta AI、Hugging Face 等机构联合发布的通用 AI 助手评测基准。如果说 MMLU 是 AI 的"高考"，那 GAIA 就是 AI 的"执业资格考试"——它不考知识记忆，考的是解决真实问题的能力。 设计理念 GAIA 的核心设计原则： 真实世界问题：所有题目来自日常场景，不是人造的测试题 多步骤推理：平均需要 5-10 步才能解决 需要工具使用：搜索、计算、文件处理等 答案唯一确定：尽管过程多样，但最终答案可验证 三个难度等级 Level 1（简单） 问题：在2024年奥斯卡颁奖典礼上，最佳导演获奖者的导演处女作是什么电影？ 需要步骤： 1. 搜索2024奥斯卡最佳导演 2. 查找该导演的处女作 预计耗时：人类约30秒 Level 2（中等） 问题：找到附件PDF中提到的所有公司，查询这些公司2023年的营收， 按营收从高到低排列，输出CSV格式。 需要步骤： 1. 解析PDF内容 2. 提取公司名称 3. 逐一搜索营收数据 4. 排序并格式化输出 预计耗时：人类约5分钟 Level 3（困难） 问题：分析过去10年全球AI论文发表趋势， 按国家和技术领域分类， 生成可视化报告并预测2027年趋势。 需要步骤： 1. 搜索多个数据源 2. 爬取和解析论文数据 3. 数据清洗和分类 4. 统计分析 5. 生成图表 6. 撰写分析报告 预计耗时：人类约2小时 评测维度 维度 权重 说明 准确率 40% 最终答案是否正确 过程合理性 20% 步骤是否合理，有无冗余 工具使用 20% 是否选对工具，使用是否正确 效率 10% Token 消耗和步骤数 安全性 10% 是否有危险操作 2026 最新排行 排名 系统 Level 1 Level 2 Level 3 总分 1 GPT-5 + Code Interpreter 92% 73% 42% 71% 2 Claude 4 + Computer Use 88% 69% 38% 67% 3 Gemini 2.5 Pro 85% 65% 35% 64% 4 Qwen3-Max 78% 52% 22% 53% 5 DeepSeek-V4 75% 48% 18% 49% - 人类平均 95% 85% 70% 84% GAIA 暴露的问题 1. 工具选择困难 很多 Agent 在面对"模糊需求"时选错工具： ...

聊天机器人有 MMLU，Agent 有什么？本文梳理 Agent 测评的方法论、主流 Benchmark 和实践建议。