mcpField
A
advanced-evaluation

advanced-evaluation

github.com/shipshitdev测试与质量38184 次安装1 天前更新
代码仓库

关于 advanced-evaluation

advanced-evaluation 是用于设计 LLM-as-a-Judge 评估、评分标准和偏差控制的技能。它帮助团队选择直接评分或成对比较,并依据人工判断评估一致性。

主要功能

  1. 01选择直接评分或成对比较
  2. 02缓解位置与长度偏差
  3. 03构建结构化评分标准
  4. 04按任务类型选择指标
  5. 05校准置信度并处理平局
  6. 06依据人工判断进行验证

适用场景

  1. 01按偏好比较模型回复
  2. 02按客观标准评估输出
  3. 03排查评审结果不一致
  4. 04测试提示词或模型变更

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/shipshitdev/skills --skill advanced-evaluation

安装后在 Claude Code 中输入/advanced-evaluation确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

plugin.json
README.md
references/
bias-mitigation.md
evaluation-pipeline.md
examples.md
implementation-patterns.md
metrics-guide.md
scripts/
evaluation_example.py

详细介绍

高级评估

关键见解:LLM-as-a-Judge 不是单一技术,而是一系列方法,每种方法都适用于不同的评估场景。选择合适的方法并缓解已知偏差,是这项技能要培养的核心能力。

适用场景

  • 为大模型输出构建 LLM-as-Judge 系统
  • 比较多个模型响应,选出最佳响应
  • 在评估团队中建立一致的质量标准
  • 调试结果不一致的评估系统
  • 为提示词或模型变更设计 A/B 测试
  • 专门为 LLM 或人类/LLM 混合评审制定评分标准
  • 分析自动化判断与人工判断之间的相关性

以下相邻工作由其他技能负责,请勿为此激活本技能:

  • 通用确定性检查、回归测试套件、生产质量门禁或结果指标:evaluation。
  • 评估工具的工具 API 合约:tool-design。

核心概念

评估分类

根据是否存在真实标注,在两种主要方法中进行选择:

直接评分——适用于存在客观标准的情况(事实准确性、遵循指令、毒性)。由单个 LLM 按既定量表为一个响应打分。对于定义明确的标准,可靠性中等到较高。注意分数校准漂移和对量表的解读不一致。

成对比较——适用于主观偏好(语气、风格、说服力)。由 LLM 比较两个响应并选出较好的一个。对于主观任务,成对比较方法与人类偏好的相关性往往高于开放式直接评分(claim-advanced-evaluation-position-swap)。注意位置偏差和长度偏差。

偏差类型

在每个评估系统中缓解以下系统性偏差:

位置偏差:排在第一位的响应更容易获得优待。可通过交换位置进行两次评估,再采用多数投票或一致性检查来缓解。

长度偏差:无论质量如何,较长的响应都更容易获得高分。可通过明确提示评审忽略长度,并采用长度归一化评分来缓解。

自我增强偏差:模型对自己的输出评分更高。可通过使用不同的模型进行生成和评估来缓解。

冗长偏差:即使内容不必要,过多的细节也更容易获得高分。可通过针对具体标准的评分规则,对无关细节进行扣分来缓解。

权威偏差:无论准确与否,自信的语气都更容易获得高分。可通过要求引用证据并增加事实核查层来缓解。

指标选择框架

根据评估任务的结构匹配指标:

任务类型主要指标次要指标
二分类(通过/失败)召回率、精确率、F1Cohen's kappa
序数量表(1-5 评分)Spearman's rho、Kendall's tauCohen's kappa(加权)
成对偏好一致率、位置一致性置信度校准
多标签Macro-F1、Micro-F1各标签的精确率/召回率

应优先关注系统性的分歧模式,而非绝对一致率,因为在特定标准上持续与人类判断不一致的评审,比存在随机噪声的评审更值得关注。

评估方法

直接评分实现

通过三个组件构建直接评分:明确的标准、经过校准的量表,以及结构化的输出格式。

标准定义模式:

Criterion: [Name]
Description: [What this criterion measures]
Weight: [Relative importance, 0-1]

量表校准——根据评分规则的详细程度选择量表的粒度:

  • 1-3:含中立选项的二元量表,认知负担最低
  • 1-5:标准李克特量表,在粒度和可靠性之间取得最佳平衡
  • 1-10:仅在每个等级都有详细评分规则时使用,因为校准难度更高

在评分提示词中要求先提供证据再给出分数,这样评审必须先根据可观察到的输出特征来支撑判断,然后才能给出分数。完整提示词见 references/examples.md(§ 直接评分提示词模板)。

成对比较实现

在每次成对评估中应用位置偏差缓解措施:

  1. 先运行确定性预检查:两个候选项必须满足相同的架构、来源证据要求和范围约束。
  2. 第一轮评审:将 Response A 放在第一位,Response B 放在第二位。
  3. 第二轮评审:将 Response B 放在第一位,Response A 放在第二位。
  4. 一致性检查:如果两轮结果不一致,则返回 TIE,并降低置信度。
  5. 最终判定:给出一致的胜出方、平均置信度和明确的平局判定理由。

置信度校准——将置信度与位置一致性对应:两轮结果一致 → 置信度 = 各轮置信度的平均值;两轮结果不一致 → 置信度 = 0.5,判定 = TIE。完整提示词请参阅 references/examples.md(§ Pairwise Comparison Prompt Template)。

量表生成

生成量表,以减少相较于开放式评分的评估差异。除非在目标评估集上经过测量,否则应将具体的差异减少幅度视为因工作负载而异。

量表应包含以下组件:

  1. 等级描述:明确界定每个分数等级
  2. 特征:定义各等级的可观察特征
  3. 示例:各等级的代表性文本(可选,但很有价值)
  4. 边缘情况:针对模糊情形的指导
  5. 评分指南:确保应用一致性的一般原则

根据使用场景校准严格程度:

  • 宽松:通过门槛较低,适合鼓励迭代
  • 均衡:符合典型的生产环境预期
  • 严格:适用于安全关键或高风险评估的高标准

让量表适应具体领域,并使用领域专属术语。代码可读性量表应提及变量、函数和注释;医疗准确性量表应参考临床术语和证据标准。

实践指南

评估流水线设计

使用以下层级构建生产级评估系统:标准加载器(量表 + 权重)-> 主评分器(直接评分或成对比较)-> 偏差缓解(位置互换等)-> 置信度评分(校准)-> 输出(分数 + 理由 + 置信度)。完整的可视化布局请参阅评估流水线图。

决策框架:直接评分还是成对比较

应用以下决策树:

Is there an objective ground truth?
+-- Yes -> Direct Scoring
|   Examples: factual accuracy, instruction following, format compliance
|
+-- No -> Is it a preference or quality judgment?
    +-- Yes -> Pairwise Comparison
    |   Examples: tone, style, persuasiveness, creativity
    |
    +-- No -> Consider reference-based evaluation
        Examples: summarization (compare to source), translation (compare to reference)
扩展评估规模

对于大批量评估,采用以下策略之一:

  1. LLM 小组(PoLL):使用多个模型作为评审,并汇总投票以减少单个模型的偏差。成本较高,但对高风险决策更可靠。

  2. 分层评估:使用快速、低成本的模型进行筛查,并使用昂贵的模型处理边缘情况。需要校准筛查阈值。

  3. 人工参与闭环:自动处理明确的情况,并将低置信度的判定交由人工审核。设计反馈闭环,逐步改进自动评估。

示例

references/examples.md(§ Example 1-3)中提供了三个完整示例——事实准确性的直接评分、带位置互换的成对比较,以及量表生成。

指南

  1. 评分前始终要求提供证据 - 以证据为先的提示词更便于审计判断,也能减少缺乏依据的数字评分

  2. 成对比较时始终交换位置 - 单次比较会受到位置偏差影响

  3. 评分尺度的粒度应与评分标准的具体程度相匹配 - 没有详细的等级描述时,不要使用 1-10 分制

  4. 将客观标准与主观标准分开 - 客观标准直接评分,主观标准采用成对比较

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

  6. 明确定义边缘情况 - 模糊情况最容易导致评估结果出现差异

  7. 使用领域专用的评分标准 - 通用评分标准只能产生通用评估

  8. 根据人工判断进行验证 - 只有与人工评估结果相关,自动化评估才有价值

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

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

注意事项

  1. 评分没有理由说明:评分缺乏依据,难以调试。始终要求先提供基于证据的理由说明,再给出评分。

  2. 单次成对比较:不交换位置时,位置偏差会影响结果。始终在交换位置后评估两次,并检查结果是否一致。

  3. 标准过载:同时衡量多个方面的标准会导致评分不可靠。确保一项标准只衡量一个可测量的方面。

  4. 缺少边缘情况指导:没有明确说明时,评估者对模糊情况的处理会不一致。在评分标准中加入边缘情况,并明确规定处理规则。

  5. 忽视置信度校准:高置信度的错误判断比低置信度的错误判断影响更大。根据位置一致性和证据强度校准置信度。

  6. 评分标准漂移:随着质量标准变化或模型能力提升,评分标准会逐渐失准。定期审查评分标准,并使用新近人工标注的示例重新校准各评分等级。

  7. 评估提示词敏感性:评估提示词中的细微措辞变化可能导致评分显著波动。对评估提示词进行版本控制,并在部署提示词变更前运行回归测试。

  8. 未受控的长度偏差:即使更偏好简洁的回答,较长的回答也会系统性地获得更高评分。在评估提示词中加入明确的长度中立指示,并使用长度受控的测试对进行验证。

集成

此技能负责评判器设计和偏差缓解。相邻技能负责更广泛的质量门禁和基础设施:

  • evaluation:通用确定性检查、回归套件、质量门禁和生产监控。
  • context-optimization (references/fundamentals.md):评判器提示词的上下文结构。
  • tool-design:评估工具的架构和错误处理。
  • context-optimization:高频评估中的令牌和延迟效率。

参考资料

内部参考资料:

外部研究:

此合集中的相关技能:

  • evaluation - 评估基础概念
  • context-optimization(基础参考)- 评估提示词的上下文结构
  • tool-design - 构建评估工具

评论

支持 Markdown