测评方法

引言 随着 LLM 部署规模扩大，安全评估不再是可选项。一个「能力强但不安全」的模型比一个「能力弱但安全」的模型危险得多。2026 年，安全评估已形成系统化的维度体系，涵盖毒性、偏见、越狱攻击、隐私泄露、对齐性等多个层面。本文提供完整的安全评估方法论。 一、安全评估维度全景 LLM 安全评估 ├── 毒性 (Toxicity) │ ├── 仇恨言论 │ ├── 侮辱/骚扰 │ ├── 暴力威胁 │ └── 自残引导 ├── 偏见 (Bias) │ ├── 性别偏见 │ ├── 种族偏见 │ ├── 年龄偏见 │ ├── 宗教偏见 │ └── 残障偏见 ├── 越狱攻击 (Jailbreak) │ ├── Prompt 注入 │ ├── 角色扮演绕过 │ ├── 编码/多语言绕过 │ └── 多轮诱导 ├── 隐私 (Privacy) │ ├── PII 泄露 │ ├── 训练数据提取 │ └── 成员推理 ├── 有害内容生成 │ ├── 武器/毒品制造 │ ├── 非法活动指导 │ └── 虚假信息生成 └── 对齐性 (Alignment) ├── 指令遵循 ├── 价值观一致性 └── 拒绝过度/不足 二、Toxicity 检测 2.1 评估方法 Red Teaming + 自动分类： ...

为什么仍需要人工评估 在 LLM-as-Judge 和自动化评测大行其道的 2026 年，人工评估仍然是不可替代的黄金标准。原因有三： 自动化评估的局限性：LLM-as-Judge 存在已知偏差（位置偏差、长度偏差、自我偏好），需要人工评估作为校准基准 主观维度的不可替代性：有用性、创意性、语气适配等维度，人类判断仍是 ground truth 对抗性场景的判断：Jailbreak 的危害程度、微妙偏见的存在与否，需要人类语义理解 一、评估者招募与培训 1.1 评估者画像 不同评估任务对评估者的要求差异极大： 评估类型 评估者要求 典型时薪 通用对话质量 母语者，本科以上 $15-25 专业领域（代码/医学/法律） 领域专家 $50-100+ 安全/偏见检测 培训过的审核员 $25-40 多语言评估 母语者 + 文化背景 $20-35 创意写作评估 写作背景/文学训练 $25-45 1.2 招募流程 筛选漏斗设计： 基础资质筛选：学历、语言能力证明 能力测试：让候选人对 20 个样本进行标注，与金标准对比 一致性测试：对同一样本标注两次（间隔 48 小时），计算自我一致性 培训与考核：通过者进入培训，培训后通过考核测试才能正式标注 关键指标： 候选人通过率通常在 30-50% 每位评估者需完成 2-4 小时的培训 培训后考核通过率约 70-80% 1.3 培训内容设计 培训不是「读标注指南」，而是系统化的能力建设： 模块一：任务理解——评估维度定义、评分标准详解 模块二：边界案例——最容易标错的案例及其正确标注 模块三：偏差认知——锚定效应、顺序偏差、中心化偏差 模块四：实操练习——30 个练习样本，含即时反馈 模块五：一致性校准——与团队其他成员的对齐练习 二、标注指南设计 2.1 评分量表设计 推荐：5 点 Likert 量表 + 结构化维度 ...

引言 模型能力决定了「能不能做」，推理性能决定了「能不能用」。一个 GPT-5 级别的模型如果每次回复需要 30 秒，在大多数实际场景中就不可用。2026 年，随着模型规模增长和上下文窗口扩展，推理性能优化已成为 LLM 工程的核心挑战。本文系统梳理推理性能的关键指标、测试方法论和主流模型对比。 一、关键指标定义 1.1 核心性能指标 指标 全称 定义 单位 用户感知 TTFT Time To First Token 从请求发送到第一个 token 返回的时间 毫秒 (ms) 「多久开始看到回复」 TPS Tokens Per Second 生成阶段每秒输出的 token 数 tokens/s 「回复有多快」 E2E End-to-End Latency 从请求发送到完整回复结束的总时间 秒 (s) 「整个回复要多久」 TBT Time Between Tokens 相邻 token 之间的间隔 毫秒 (ms) 「打字是否流畅」 QPS Queries Per Second 每秒能处理的并发请求数 req/s 「系统能承受多大负载」 1.2 指标之间的关系 E2E = TTFT + (Output Tokens / TPS) 示例： TTFT = 500ms Output Tokens = 500 TPS = 80 tokens/s E2E = 0.5 + (500/80) = 0.5 + 6.25 = 6.75 秒 1.3 哪个指标最重要？ 取决于应用场景： ...

引言 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 绝对评分 方式 优点 缺点 适用场景 成对比较 更易判断、一致性高 信息量少、不可传递 模型排序 绝对评分 信息丰富、可追踪 标注者差异大 质量监控 排序 信息量最大 认知负担重 小规模深度评估 实践建议：主用成对比较做模型排序，辅以绝对评分做质量追踪。 ...