高级评估

advanced-evaluation
分类通用
作者Agentic Awesome Skills 社区
许可MIT
评分4.90/5
使用14.7K

高级评估 (Advanced Evaluation)

本技能涵盖了使用 LLM 作为评判者（LLM-as-judge）评估 LLM 输出的生产级技术。它将学术论文研究、行业实践和实际实施经验综合为可操作的模式，用于构建可靠的评估系统。

核心洞察：LLM-as-a-Judge 不是一种单一的技术，而是一系列方法的集合，每种方法适用于不同的评估场景。选择正确的方法并减轻已知偏差是该技能培养的核心能力。

何时使用

在以下场景中激活此技能：
  • 为 LLM 输出构建自动化评估流水线
  • 比较多个模型的响应以选择最佳方案
  • 在评估团队之间建立统一的质量标准
  • 调试结果不一致的评估系统
  • 为提示词（Prompt）或模型变更设计 A/B 测试
  • 为人工或自动化评估创建量表（Rubrics）
  • 分析自动化评判与人工评判之间的相关性

核心概念

评估分类法

评估方法分为两大类，其可靠性特征截然不同：

直接打分 (Direct Scoring)：单个 LLM 根据定义好的量表对一个响应进行评分。

  • 适用场景：客观标准（事实准确性、指令遵循度、毒性）

  • 可靠性：对于定义明确的标准，可靠性为中到高

  • 失败模式：分数校准漂移、量表理解不一致

两两比较 (Pairwise Comparison)：LLM 比较两个响应并选出较好的一方。

  • 适用场景：主观偏好（语气、风格、说服力）

  • 可靠性：在偏好评估方面比直接打分更高

  • 失败模式：位置偏差、长度偏差

MT-Bench 论文 (Zheng et al., 2023) 的研究表明，在基于偏好的评估中，两两比较与人类评判者的一致性高于直接打分；而对于有明确标准答案的客观标准，直接打分仍然适用。

偏差图谱

LLM 评判者存在系统性偏差，必须积极减轻：

位置偏差 (Position Bias)：在两两比较中，排在第一个位置的响应更容易获得青睐。缓解方案：交换位置进行两次评估，采用多数投票或一致性检查。

长度偏差 (Length Bias)：无论质量如何，较长的响应往往被评为更高分。缓解方案：在提示词中明确要求忽略长度，或使用长度归一化评分。

自我增强偏差 (Self-Enhancement Bias)：模型倾向于给自己的输出打高分。缓解方案：生成和评估使用不同的模型，或在分析时承认此局限性。

冗余偏差 (Verbosity Bias)：即使是不必要的详细解释也会获得高分。缓解方案：制定针对具体标准的量表，对无关细节进行扣分。

权威偏差 (Authority Bias)：无论准确与否，自信且权威的语气更容易获得高分。缓解方案：要求引用证据，增加事实核查层。

指标选择框架

根据评估任务的结构选择指标：

| 任务类型 | 主要指标 | 次要指标 |
|-----------|-----------------|-------------------|
| 二分类 (通过/失败) | 召回率 (Recall), 精确率 (Precision), F1 | Cohen's κ |
| 定序量表 (1-5 |
| 评分) | Spearman's ρ, Kendall's τ | Cohen's κ (加权) |
| :--- | :--- | :--- |
| 成对偏好 | 一致率, 位置一致性 | 置信度校准 |
| 多标签 | Macro-F1, Micro-F1 | 单标签精确率/召回率 |

核心洞察：绝对一致性的高低并不如系统性分歧模式重要。一个在特定标准上始终与人类意见相左的评判者，比一个带有随机噪声的评判者更具问题。

评估方法

直接评分实现

直接评分需要三个组件：清晰的标准、校准后的量表以及结构化的输出格式。

标准定义模式：

code
标准：[名称]
描述：[该标准衡量的内容]
权重：[相对重要性，0-1]

量表校准：

  • 1-3 分量表：带中立选项的二元量表，认知负荷最低

  • 1-5 分量表：标准 Likert 量表，粒度与可靠性平衡较好

  • 1-10 分量表：粒度高但难以校准，仅在有详细评分细则时使用

直接评分的提示词结构：

code
你是一位评估响应质量的专家评判员。


任务

根据各项标准评估以下响应。

原始提示词

{prompt}

待评估响应

{response}

评估标准

{针对每个标准：名称, 描述, 权重}

指令

针对每项标准：
1. 在响应中寻找具体证据
2. 根据评分细则打分（1-{max} 分量表）
3. 提供证据证明评分的合理性
4. 提出一项具体的改进建议

输出格式

以结构化 JSON 形式响应，包含分数、理由和总结。

思维链 (CoT) 要求：所有评分提示词必须要求在给出分数之前先提供理由。研究表明，与先打分的方法相比，这种方式可将可靠性提高 15-25%。

成对比较实现

成对比较在基于偏好的评估中天生更可靠，但需要减轻偏差。

位置偏差缓解协议：
1. 第一轮：响应 A 在第一位，响应 B 在第二位
2. 第二轮：响应 B 在第一位，响应 A 在第二位
3. 一致性检查：如果两次结果不一致，则返回 TIE（平局）并降低置信度
4. 最终裁定：一致的获胜者及其平均置信度

成对比较的提示词结构：

code
你是一位比较两个 AI 响应的专家评判员。


关键指令


  • 不要因为响应较长而偏好该响应


  • 不要基于位置（第一还是第二）产生偏好


  • 仅根据指定标准关注质量


  • 当响应确实等同时，允许判定为平局


原始提示词

{prompt}

响应 A

{response_a}

响应 B

{response_b}

比较标准

{标准列表}

指令

1. 首先独立分析每个响应
2. 根据每项标准进行比较
3. 确定最终获胜者及置信水平

输出格式

JSON 格式，包含各项标准的比较结果、最终获胜者、置信度 (0-1) 及推理过程。

置信度校准：置信度分数应反映位置一致性：

  • 两次结果一致：置信度 = 个人置信度的平均值

  • 两次结果不一致：置信度 = 0.5，裁定 = TIE

评分细则 (Rubric) 生成

与开放式评分相比，定义良好的评分细则可将评估方差降低 40-60%。

评分细则组件：
1. 等级描述：每个分数等级的清晰界限
2. 特征：定义每个等级的可观察特征
3. 示例：每个等级的代表性文本
l（可选但有价值）
4. 边缘情况 (Edge cases)：针对模糊场景的指导
5. 评分指南 (Scoring guidelines)：确保一致应用的一般原则

严格度校准 (Strictness Calibration)：

  • 宽松 (Lenient)：通过分数门槛较低，适用于鼓励迭代的场景

  • 均衡 (Balanced)：公平，符合生产环境的典型预期

  • 严格 (Strict)：高标准，适用于安全关键或高风险的评估

领域适配 (Domain Adaptation)：评分量表应使用领域特定术语。例如，“代码可读性”量表会提到变量、函数和注释；“医学准确性”量表则会引用临床术语和证据标准。

实践指南

评估流水线设计

生产级评估系统需要多个层级：

code
┌─────────────────────────────────────────────────┐
│                 评估流水线 (Evaluation Pipeline)    │
├─────────────────────────────────────────────────┤
│                                                   │
│  输入：响应 + 提示词 + 上下文                       │
│           │                                       │
│           ▼                                       │
│  ┌─────────────────────┐                         │
│  │   标准加载器         │ ◄── 评分量表、权重        │
│  └──────────┬──────────┘                         │
│             │                                     │
│             ▼                                     │
│  ┌─────────────────────┐                         │
│  │   主评分器           │ ◄── 直接评分或两两对比    │
│  └──────────┬──────────┘                         │
│             │                                     │
│             ▼                                     │
│  ┌─────────────────────┐                         │
│  │   偏差缓解           │ ◄── 位置交换等           │
│  └──────────┬──────────┘                         │
│             │                                     │
│             ▼                                     │
│  ┌─────────────────────┐                         │
│  │   置信度评分         │ ◄── 校准                 │
│  └──────────┬──────────┘                         │
│             │                                     │
│             ▼                                     │
│  输出：分数 + 理由 + 置信度                         │
│                                                   │
└─────────────────────────────────────────────────┘

常见反模式 (Anti-Patterns)

反模式：无理由评分

  • 问题：分数缺乏依据，难以调试或改进

  • 解决方案：始终要求在给出分数前提供基于证据的理由

反模式：单次两两对比

  • 问题：位置偏差 (Position bias) 会干扰结果

  • 解决方案：始终交换位置并检查一致性

反模式：标准过载

  • 问题：一个标准衡量多个维度会导致结果不可靠

  • 解决方案：一个标准 = 一个可衡量的维度

反模式：缺失边缘情况指导

  • 问题：评估者对模糊情况的处理不一致

  • 解决方案：在评分量表中加入带有明确指导的边缘情况

反模式：忽略置信度校准

  • 问题：高置信度的错误判断比低置信度的错误更糟糕

  • 解决方案：根据位置一致性和证据强度校准置信度

决策框架：直接评分 vs. 两两对比

请参考此决策树：

code
是否存在客观的标准答案 (Ground Truth)？
├── 是 → 直接评分 (Direct Scoring)
│   └── 示例：事实准确性、指令遵循度、格式合规性
│
└── 否 → 这是否属于偏好或质量判断...
判断？ ├── 是 → 成对比较 (Pairwise Comparison) │ └── 示例：语气、风格、说服力、创造力 │ └── 否 → 考虑基于参考的评估 (Reference-based evaluation) └── 示例：摘要（与原文对比）、翻译（与参考译文对比）
code
### 规模化评估

针对大规模评估：


1. LLM 评审团 (PoLL)：使用多个模型作为评审员，汇总投票结果
   - 减少单个模型的偏见
   - 成本较高，但对于高风险决策更可靠


2. 分层评估：使用快速且廉价的模型进行筛选，使用昂贵的模型处理边缘案例
   - 对大批量数据具有成本效益
   - 需要对筛选阈值进行校准


3. 人机协同 (Human-in-the-loop)：对清晰的案例进行自动评估，对低置信度案例进行人工审核
   - 关键应用场景中可靠性最高
   - 设计反馈循环以优化自动评估


示例


示例 1：准确性的直接评分


输入：

Prompt: "地球上季节产生的原因是什么？"
Response: "季节是由地球地轴的倾斜引起的。随着地球绕太阳公转，
不同半球在一年中的不同时间接收到的阳光直射程度不同。"
Criterion: 事实准确性 (权重: 1.0)
Scale: 1-5
code
输出：
json
{
"criterion": "事实准确性",
"score": 5,
"evidence": [
"正确地将地轴倾斜识别为主要原因",
"正确解释了不同半球阳光分布的差异",
"不存在事实错误"
],
"justification": "回答准确解释了季节产生的原因，科学推理正确。地轴倾斜及其对阳光分布的影响均描述正确。",
"improvement": "可以添加具体的倾斜角度 (23.5°) 以使内容更完整。"
}
code
### 示例 2：带位置交换的成对比较


输入：

Prompt: "向初学者解释机器学习"
Response A: [包含专业术语的技术性解释]
Response B: [基于简单类比的解释]
Criteria: ["清晰度", "易懂度"]
code
第一轮 (A 在前)：
json
{ "winner": "B", "confidence": 0.8 }
code
第二轮 (B 在前)：
json
{ "winner": "A", "confidence": 0.6 }
code
(注：胜者为 A 是因为 B 处于第一位置)


映射后的第二轮：
json
{ "winner": "B", "confidence": 0.6 }
code
最终结果：
json
{
"winner": "B",
"confidence": 0.7,
"positionConsistency": {
"consistent": true,
"firstPassWinner": "B",
"secondPassWinner": "B"
}
}
code
### 示例 3：评分量表 (Rubric) 生成


输入：

criterionName: "代码可读性"
criterionDescription: "代码易于理解和维护的程度"
domain: "软件工程"
scale: "1-5"
strictness: "平衡"
code
输出 (简略版)：
json
{
"levels": [
{
"score": 1,
"label": "差",
"description": "如果不付出巨大努力，代码很难理解",
"characteristics": [
"变量或函数命名无意义",
"没有注释或文档",
"逻辑嵌套过深或过于复杂"
]
},
{
"score": 3,
"label": "合格",
"description": "经过一定努力可以理解代码",
"characteristics": [
"大多数变量具有有意义的名称",
"复杂部分有基础注释",
"逻辑可追踪但可以更简洁"
]
},
{
"score": 5,
"label": "优秀",
"description": "代码立即清晰且易于维护",
"characteristics": [
"所有...
code
json
"命名具有描述性且保持一致",
"文档详尽",
"结构清晰且模块化"
]
}
],
"edgeCases": [
{
"situation": "代码结构良好但使用了领域特定缩写",
"guidance": "基于领域专家的可读性评分，而非面向普通受众"
}
]
}
```

指南

1. 评分前必须提供理由 - 思维链（Chain-of-thought）提示可将可靠性提高 15-25%

2. 两两比较时必须交换位置 - 单次比较容易受到位置偏差（position bias）的影响

3. 量表粒度需与评分标准具体程度匹配 - 若无详细的分级描述，请勿使用 1-10 分制

4. 区分客观标准与主观标准 - 客观标准采用直接评分，主观标准采用两两比较

5. 包含置信度分数 - 根据位置一致性和证据强度进行校准

6. 明确定义边缘情况 - 模糊的情况是导致评估方差最大的原因

7. 使用领域特定的评分标准 - 通用标准会产生通用（且实用性较低）的评估结果

8. 通过人类判断进行验证 - 只有当自动化评估与人类评估相关时，它才具有价值

9. 监控系统性偏差 - 按标准、响应类型和模型跟踪分歧模式

10. 为迭代而设计 - 评估系统通过反馈循环不断改进

集成

本技能与以下内容集成：

  • context-fundamentals - 评估提示词需要有效的上下文结构
  • tool-design - 评估工具需要适当的 Schema 和错误处理
  • context-optimization - 评估提示词可以针对 Token 效率进行优化
  • evaluation (基础) - 本技能扩展了基础评估概念

参考资料

内部参考：

  • LLM-as-Judge 实现模式

  • 偏差缓解技术

  • 指标选择指南

外部研究：




本集合中的相关技能：

  • evaluation - 基础评估概念

  • context-fundamentals - 评估提示词的上下文结构

  • tool-design - 构建评估工具

---

技能元数据

创建日期: 2024-12-24
最后更新: 2024-12-24
作者: Muratcan Koylan
版本: 1.0.0

局限性

  • 仅在任务明确符合上述范围时使用此技能。
  • 不要将输出视为环境特定验证、测试或专家评审的替代方案。
  • 如果缺少必要的输入、权限、安全边界或成功标准，请停止并请求澄清。