评估方法论：从 LLM 评估到 Agent 评估

难度：基础分类：Evaluation

简短回答

LLM 评估分为三大类：(1) 自动指标评估——用算法计算的确定性指标（如 BLEU、ROUGE、精确匹配），速度快、成本低，但只能衡量表面特征；(2) 人工评估——由人类标注者评判输出质量，是"金标准"但成本高、难以规模化；(3) LLM-as-Judge——用强 LLM 评估其他 LLM 的输出，顶级 Judge（GPT-4o / Claude Opus）与人工评估的 Cohen's Kappa ≈ 0.78-0.84，逼近人类-人类一致性（κ≈0.80），是近年主流趋势。⚠️ 注意 percent agreement 容易虚高（κ=0.62 也能 >80% 一致率），学术界（"Judging the Judges" arXiv:2406.12624）建议用 Cohen's Kappa 才是 Judge 可靠性的正确指标。生产环境推荐混合方案：自动指标做初筛，LLM-as-Judge 做质量评估，人工评估做最终校准。

然而，当评估对象从 LLM 升级为 Agent，评估方法论需要根本性扩展。LLM 评估关注单次输入输出的质量，而 Agent 评估关注多步决策轨迹的整体表现——不仅看最终结果，还要评估推理过程、工具使用、规划质量和错误恢复能力。核心差异在于：Agent 涉及 LLM + 工具 + 环境的交互链，非确定性更强（同一任务可能有多条正确路径），评估维度也从文本质量扩展到任务完成能力、轨迹效率和行为安全。

详细解析

一、LLM 评估方法全景

代码块

Plain Text

┌──────────────────────────────────────────────────────┐

│ LLM 评估方法全景 │

├──────────────────────────────────────────────────────┤

│ │

│ 自动指标 LLM-as-Judge 人工评估 │

│ ───────── ────────────── ───────── │

│ BLEU/ROUGE GPT-4 打分专家评审 │

│ 精确匹配多维度评估众包标注 │

│ F1 Score Pairwise 对比用户反馈 │

│ Perplexity Rubric 评分 A/B 测试 │

│ │

│ 速度: 最快速度: 中等速度: 最慢 │

│ 成本: 最低成本: 中等成本: 最高 │

│ 质量: 有限质量: 较好质量: 最好 │

│ 规模: 无限规模: 大规模: 小 │

└──────────────────────────────────────────────────────┘

Sebastian Raschka 将 LLM 评估总结为四种方法：多选基准、人类偏好、自动化 LLM 评估、和编程基准。

二、自动指标评估

代码块

Python

# 常见自动评估指标

# 1. 精确匹配（Exact Match）

def exact_match(prediction, reference):

return prediction.strip() == reference.strip()

# 适用：数学题答案、事实性问题、代码输出

# 2. BLEU（机器翻译质量）

from nltk.translate.bleu_score import sentence_bleu

score = sentence_bleu([reference.split()], prediction.split())

三、LLM-as-Judge

代码块

Python

async def llm_as_judge(question, answer, reference=None):

"""用 LLM 评估回答质量"""

# 方式 1：直接评分（Pointwise）

pointwise_prompt = f"""

请评估以下回答的质量（1-5分）：

问题：{question}

回答：{answer}

{"参考答案：" + reference if reference else ""}

四、人工评估

代码块

JSON

human_evaluation_methods = {

"专家评审": {

"方法": "领域专家按预定标准打分",

五、混合评估框架（推荐）

代码块

Python

class HybridEvaluator:

"""混合评估：自动指标 + LLM Judge + 人工抽检"""

async def evaluate(self, test_set):

results = []

for example in test_set:

prediction = await self.model.invoke(example.input)

scores = {}

# Layer 1: 自动指标（全量，毫秒级）

scores["exact_match"] = exact_match(prediction, example.reference)

scores["f1"] = token_f1(prediction, example.reference)

# Layer 2: LLM-as-Judge（全量或采样，秒级）

scores["llm_judge"] = await llm_as_judge(

example.input, prediction, example.reference

)

六、评估指标选择指南

#qrSJtuvVefHU text{white-space:pre}.fb0{stroke:var(--N900-FG, 0.15)}.fx0{stroke-miterlimit:10}.fa1{fill:#bbbfc4}.fx1{font:normal 400 12px MonospacedNumber,LarkHackSafariFont,LarkEmojiFont,LarkChineseQuote,-apple-system,BlinkMacSystemFont,Helvetica Neue,Tahoma,PingFang SC,Microsoft Yahei,Arial,Hiragino Sans GB,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol,Noto Color Emoji}.fx2{text-anchor:middle}.fx3{dominant-baseline:central}.fx4{stroke:none}.fc0{fill:var(--text-caption)}.fa2{fill:var(--text-link-disabled)}.fx5{font:400 normal 13px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"}.fx6{text-anchor:start}.fx7{dominant-baseline:alphabetic}.fc1{fill:rgb(0, 0, 0)}.fb1{fill:var(--N900-FG, 0.15)}.fb2{fill:rgb(209, 217, 224)}.fa3{fill:var(--bg-body)}ABC123456789任务类型事实性问答文本摘要翻译创意写作对话质量代码生成Agent 任务安全性推荐指标精确匹配/F1ROUGE + LLMBLEU + 人工人工 + LLMLLM 多维评分Pass@k任务完成率拒绝率/攻击成功评估方式自动自动 + LLM Judge自动 + 人工LLM Judge + 人工LLM Judge自动（运行测试）自动 + 轨迹评估自动 + 红队测试

七、从 LLM 评估到 Agent 评估——核心差异

LLM 评估的三大方法（自动指标、人工评估、LLM-as-Judge）仍然适用于 Agent，但 Agent 的评估需要根本性扩展。

LLM 评估评的是单次输出，Agent 评估评的是「推理 ⇄ 工具 ⇄ 观察」整条循环轨迹。

表格加载中...

#hKaNvHKTnxbx text{white-space:pre}.fb0{stroke:var(--N900-FG, 0.15)}.fx0{stroke-miterlimit:10}.fa1{fill:#bbbfc4}.fx1{font:normal 400 12px MonospacedNumber,LarkHackSafariFont,LarkEmojiFont,LarkChineseQuote,-apple-system,BlinkMacSystemFont,Helvetica Neue,Tahoma,PingFang SC,Microsoft Yahei,Arial,Hiragino Sans GB,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol,Noto Color Emoji}.fx2{text-anchor:middle}.fx3{dominant-baseline:central}.fx4{stroke:none}.fc0{fill:var(--text-caption)}.fa2{fill:var(--text-link-disabled)}.fx5{font:400 normal 13px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"}.fx6{text-anchor:start}.fx7{dominant-baseline:alphabetic}.fc1{fill:rgb(0, 0, 0)}.fb1{fill:var(--N900-FG, 0.15)}.fb2{fill:rgb(209, 217, 224)}.fa3{fill:var(--bg-body)}ABC123456789维度评估对象评估范围确定性关键指标工具使用安全性评估复杂度基准测试LLM 评估单次生成输出文本质量较高准确率、BLEU无输出安全低MMLU、GSM8KAgent 评估多步决策轨迹任务完成 + 过程低（多路径可行）任务完成率、效率核心评估维度行为安全（操作）高SWE-bench、GAIA

ACL 2025 的 Agent 评估综述提出二维分类法：评估"什么能力"（推理、规划、工具使用等） x "用什么方法"（基准测试、人工评估、LLM Judge 等）。

八、Agent 评估的四层模型

代码块

JSON

agent_evaluation_layers = {

"Layer 1 - 结果评估（What）": {

"问题": "Agent 是否完成了任务？",

"指标": ["任务完成率", "答案准确率", "部分完成度"],

"方法": "自动化检查最终状态",

"示例": "SWE-bench: 代码修改后测试是否通过",

"Layer 2 - 轨迹评估（How）": {

"问题": "Agent 的决策路径是否合理？",

"指标": ["步骤合理性", "是否有冗余步骤", "是否走了弯路"],

"方法": "LLM-as-Judge 或人工评估 Trace",

"示例": "10 步完成 vs 3 步完成，效率差异巨大",

"Layer 3 - 工具评估（With What）": {

"问题": "Agent 是否正确使用了工具？",

"指标": ["工具选择准确率", "参数正确率", "调用次数"],

"方法": "与最优工具使用序列对比",

"示例": "搜索 vs 计算——应该用计算器时却去搜索",

"Layer 4 - 鲁棒性评估（What If）": {

"问题": "Agent 面对异常情况如何表现？",

九、轨迹评估（Trajectory Evaluation）

代码块

Python

class TrajectoryEvaluator:

"""评估 Agent 的完整执行轨迹"""

async def evaluate_trajectory(self, task, trajectory):

scores = {}

# 1. 步骤级评估：每一步是否合理

十、主要 Agent 基准测试

代码块

JSON

agent_benchmarks = {

"代码 Agent": {

"SWE-bench": "修复真实 GitHub Issue（Resolved Rate）",

"HumanEval": "生成函数代码（Pass@k）",

"MBPP": "Python 编程任务（Pass@k）",

"Web Agent": {

"WebArena": "在真实网站完成复杂任务",

"Mind2Web": "跨网站的通用网页操作",

"VisualWebArena": "需要视觉理解的网页任务",

"通用推理 Agent": {

"ALFWorld": "文本版家庭环境中的任务执行",

"WebShop": "模拟电商购物任务",

"GAIA": "通用 AI 助手评估（需要多工具组合）",

十一、生产环境 Agent 评估框架

代码块

Python

十二、推理过程评估（Reasoning Process Evaluation）

前面的章节主要评估「Agent 做了什么」（结果、轨迹、工具），这一节深入「Agent 是怎么想的」——即推理过程本身的质量。这部分内容整合自 #057（#057 原文已并入本节），聚焦四个进阶问题：过程 vs 结果奖励、推理忠实性、推理质量的层次、基于 Trace 的自动诊断规则。

推理质量的层次模型

与第八节「Agent 评估的四层模型」（按评估对象横向划分为结果/轨迹/工具/鲁棒性）互补，这里给出一个自下而上的推理深度层次——从单步逻辑一直到任务完成：

代码块

Plain Text

Level 4: 任务完成度 "Agent 是否完成了用户的请求？"

↑

Level 3: 推理路径质量 "推理过程是否高效、合理、有无弯路？"

↑

Level 2: 工具使用合理性 "是否选对了工具？参数是否正确？"

↑

Level 1: 单步推理正确性 "每一步推理是否逻辑正确？"

关键认知：结果正确 ≠ 过程正确。一个 Agent 可能因为错误的推理偶然得到正确答案（right answer, wrong reason），只看 Level 4 会高估其推理能力。只有 Level 1–3 同时成立，结果才可靠、可复现。这也解释了为什么纯结果评估（ORM）会漏掉「答案对但推理错」的案例——必须配合过程评估。

PRM vs ORM：过程奖励 vs 结果奖励

这是「过程评估 vs 结果评估」在打分与训练层面的核心范式之争。

代码块

Python

class ProcessRewardModel:

"""对推理过程的每一步打分（PRM）"""

def evaluate_reasoning(self, problem, reasoning_steps):

step_scores = []

for i, step in enumerate(reasoning_steps):

score = self.prm_model.score(

problem=problem,

previous_steps=reasoning_steps[:i],

current_step=step,

)

实践建议：两者结合——ORM 做初筛（便宜、全量），PRM 对失败或争议案例做深入分析（贵、精准）。在 Agentic-RL 训练中，PRM 提供的逐步奖励信号比 ORM 更能稳定提升推理能力（参见 #103）。

Faithfulness：推理忠实性评估

忠实性（Faithfulness）指推理链是否真实反映了模型的决策过程，而非事后合理化（rationalization）——即模型可能先得出答案，再编造一条看似合理的推理链来「解释」这个答案。这样的推理链是「装饰性」的而非「功能性的」，会让评估者误以为模型具备它实际上并不具备的推理能力。

核心检测思路是干预法（intervention）：篡改推理链中的某个关键步骤，看最终答案是否随之改变。

代码块

Python

def check_faithfulness(model, problem, original_reasoning):

"""忠实性检测：改掉关键步骤，看答案是否真的依赖它"""

# 1. 原始推理链及其答案

original_answer = model.solve(problem, reasoning_hint=original_reasoning)

# 2. 篡改中间某个关键步骤（如把中间计算结果改错）

tampered = tamper_step(original_reasoning, step_idx=3, new_value="999")

# 3. 答案若不变 → 模型并未真正依赖这条推理链 → 不忠实

tampered_answer = model.solve(problem, reasoning_hint=tampered)

is_faithful = original_answer != tampered_answer

return is_faithful

判定逻辑：篡改关键步骤后答案若不变，说明模型没有真正「使用」这条推理链——它是装饰性的。OpenAI 的 CoT Monitorability 研究正系统性地探索思维链在多大程度上能被忠实监控；这与推理模型（#055）的可解释性直接相关——如果一个推理模型的 CoT 不可忠实监控，那么基于 CoT 的安全审查就形同虚设。

基于 Trace 的生产诊断规则

生产环境里不可能逐条人工审推理，通常把推理与工具调用记录成 Trace（Span 级别，参见 #074），再用一组启发式规则自动标红异常轨迹。这组规则是对第十一节「生产环境指标」的补充——前者回答「指标是多少」，这里回答「什么模式说明出了问题」：

代码块

Python

# Trace 自动评估规则：命中即标记为可疑轨迹

trace_alert_rules = {

"循环推理": "推理步骤数 > 阈值 → 可能陷入循环 / 来回兜圈",

"工具滥用": "同一工具连续调用 > 3 次 → 可能在重试无效操作",

"策略失误": "工具调用失败率 > 30% → 工具选择策略有问题",

"效率异常": "总 token 消耗远超同类任务均值 → 推理效率低",

}

# 典型工具栈：Langfuse / LangSmith / Arize Phoenix

# 这些平台原生支持 Span 属性（输入/输出/延迟/token）与父子关系，

# 上述规则可配置为告警阈值，无需手写轮询逻辑。

这四条规则分别对应推理过程的四类隐患——循环、重试、选型、开销——它们在生产监控中往往比「最终答案对不对」更早暴露问题，也更适合接入持续评估流水线（#077）。

常见误区 / 面试追问

误区："BLEU/ROUGE 分数高就说明质量好" — 这些指标只衡量表面词汇重叠，无法评估语义正确性、逻辑合理性和实用性。两个语义相同但措辞不同的回答可能得到很不同的 BLEU 分数。LLM 时代这些传统指标的参考价值有限。

误区："LLM-as-Judge 完全可以替代人工" — LLM Judge 有系统性偏差（冗长偏好、位置偏差、自我偏好），且在专业领域（医学、法律）的判断可能不可靠。生产中应该定期用人工评估校准 LLM Judge 的准确性。

误区："Agent 评估只看最终结果就够了" — 最终结果正确但过程不合理的 Agent 同样有问题——可能走了弯路浪费资源，可能碰巧得到正确结果但推理错误（不可靠），可能使用了不安全的操作。轨迹评估和结果评估同等重要。

误区："用 LLM 基准测试就能评估 Agent" — LLM 基准（如 MMLU）测试的是知识和推理能力，无法反映 Agent 的工具使用、规划和错误恢复能力。Agent 需要专用基准（如 SWE-bench、WebArena、GAIA）。

追问："如何提高 LLM-as-Judge 的可靠性？" — (1) 提供详细的评分 Rubric（标准）而非让 Judge 自由打分；(2) 交换位置做两次评估取平均（消除位置偏差）；(3) 用多个 Judge 模型投票；(4) 定期用人工标注校准。

追问："评估数据集从哪里来？" — 三个来源：(1) 从生产日志中采样真实问题；(2) 人工构造边界案例和对抗样本；(3) 使用公开基准（MMLU、GSM8K 等）。最佳实践是三者结合——公开基准评估通用能力，私有数据集评估业务场景。

追问："如何评估 Agent 的效率？" — 三个维度：(1) 步骤效率——完成任务用了多少步（vs 最优步数）；(2) 成本效率——消耗了多少 token/金钱；(3) 时间效率——端到端延迟。权衡是：更多步骤可能提升准确率但增加成本。

追问："Agent 评估的最大难点是什么？" — 非确定性。同一任务可能有多条正确路径，无法用固定的"标准答案"对比。解决方案：(1) 评估最终状态而非中间步骤；(2) 用 LLM Judge 评估轨迹的合理性；(3) 多次运行取统计指标。