llm-as-judge

LLM-as-Judge

概述

有些质量标准本质上是主观的，例如语气、视觉美感、UX 体验、文档清晰度和代码可读性。这些无法通过确定性测试来验证。LLM-as-judge 模式通过采用定义明确的评分标准和 LLM 评审者，提供结构化且可重复的评估，确保主观质量得到一致衡量。

开始时宣布：“我正在使用 llm-as-judge 技能评估主观质量。”

---

阶段 1：确定评估方法

**目标：**判断 LLM-as-judge 是否适用。

决策表：LLM-as-Judge 与确定性测试

标准类型	方法	示例
客观、可衡量	确定性测试	“响应时间 < 200ms”
结构化、可验证	确定性测试	“返回有效的 JSON”
主观、定性	LLM-as-judge	“错误消息友好且有帮助”
审美、感知性	LLM-as-judge	“UI 给人整洁、现代的感觉”
语言、语气	LLM-as-judge	“文档对初学者来说清晰易懂”
整体、体验性	LLM-as-judge	“引导流程给人直观易用的感觉”

**经验法则：**如果可以编写布尔断言，就使用确定性测试。如果评估需要判断，就使用 LLM-as-judge。

停止 — 在进入阶段 2 之前，不要继续：

• 确认标准确实是主观的
• 排除确定性测试的适用性
• 确定要评估的具体产物

---

阶段 2：定义评分标准

**目标：**创建包含权重和锚点的评估维度。

操作

1. 定义 3-5 个评估维度
2. 分配权重（总和必须为 1.0）
3. 为每个维度定义锚点（1=最差，5=合格，10=最佳）
4. 设定通过阈值

评分标准结构

维度	权重	量表	锚点：1	锚点：5	锚点：10
[名称]	0.X	1-10	[最差情况]	[合格]	[优秀]

阈值选择表

质量等级	阈值	适用场景
最低可用	5.0	内部文档、草稿内容
生产级质量	7.0	面向用户的内容、公共 API
卓越	8.5	营销内容、关键 UX 流程

停止 — 在进入阶段 3 之前，不要继续：

• 定义 3-5 个维度，并为其提供清晰描述
• 权重总和恰好为 1.0
• 锚点具体明确（而非含糊）
• 在评估前设定通过阈值

---

阶段 3：评估

**目标：**将产物和评分标准提交给 LLM 评审者。

评审请求结构

{
  criteria: "Description of what to evaluate and the quality standard",
  artifact: "The content to be evaluated (code, text, UI markup, etc.)",
  rubric: [
    { dimension: "Clarity", weight: 0.3, description: "Is the content easy to understand?" },
    { dimension: "Tone", weight: 0.3, description: "Is the tone appropriate for the audience?" },
    { dimension: "Completeness", weight: 0.2, description: "Does it cover all necessary points?" },
    { dimension: "Engagement", weight: 0.2, description: "Does it hold the reader's interest?" }
  ],
  passing_threshold: 7.0,
  intelligence: "opus"
}

评审响应结构

{
  scores: [
    { dimension: "Clarity", score: 8, reasoning: "Well-structured with clear headings..." },
    { dimension: "Tone", score: 7, reasoning: "Professional but occasionally too formal..." },
    { dimension: "Completeness", score: 9, reasoning: "Covers all key topics..." },
    { dimension: "Engagement", score: 6, reasoning: "Could use more examples..." }
  ],
  weighted_score: 7.4,
  pass: true,
  summary: "Overall good quality with minor tone and engagement improvements suggested.",
  suggestions: [
    "Add a real-world example in section 3",
    "Use more conversational language in the introduction"
  ]
}

停止 — 在进入阶段 4 之前，不要继续：

• 已提交产物及完整的评分标准
• 已对每个维度分别评分
• 已为每个分数提供理由
• 已计算加权总分

---

阶段 4：迭代或接受

**目标：**根据评估结果采取行动。

结果处理表

结果	操作	最大迭代次数
通过（分数 >= 阈值）	接受产物，继续推进	完成
接近通过但未通过（相差不超过 1 分）	应用建议，再评估一次	1
明确未通过（低于阈值 > 1 分）	进行重大修改，应用所有建议	2
多次未通过（尝试 3 次以上）	升级处理 — 可能需要调整评分标准或方法	升级处理

停止 — 满足以下条件时，评估完成：

• 产物达到通过阈值，或
• 已完成 3 次迭代并做出升级处理决定

---

常用评分标准模板

文档质量

Clarity (0.3): Is the content easy to understand for the target audience?
  1=incomprehensible  5=adequate but requires re-reading  10=crystal clear
Accuracy (0.3): Is the information technically correct?
  1=factually wrong  5=mostly correct  10=perfectly accurate
Completeness (0.2): Does it cover all necessary topics?
  1=missing critical info  5=covers basics  10=comprehensive
Examples (0.2): Are there sufficient, relevant code examples?
  1=no examples  5=some examples  10=rich, varied examples
Threshold: 7.0

错误消息质量

Helpfulness (0.4): Does the message help the user fix the problem?
  1=no help at all  5=vague direction  10=exact fix steps
Clarity (0.3): Is the message easy to understand?
  1=cryptic  5=understandable  10=immediately clear
Tone (0.2): Is the tone empathetic and non-blaming?
  1=hostile/blaming  5=neutral  10=empathetic and supportive
Actionability (0.1): Does it suggest a concrete next step?
  1=no suggestion  5=vague suggestion  10=specific actionable step
Threshold: 7.5

代码可读性

Naming (0.3): Are variable/function names descriptive and consistent?
  1=single letters everywhere  5=adequate  10=self-documenting
Structure (0.3): Is the code logically organized?
  1=spaghetti  5=functional  10=elegant and clear
Simplicity (0.2): Is the code as simple as possible (but not simpler)?
  1=over-engineered  5=reasonable  10=minimal and clear
Documentation (0.2): Are complex sections adequately commented?
  1=no comments where needed  5=some comments  10=well-documented why
Threshold: 7.0

UX 文案

Clarity (0.3): Is the copy easy to understand?
  1=confusing  5=understandable  10=immediately clear
Brevity (0.2): Is it concise without losing meaning?
  1=verbose  5=adequate length  10=perfectly concise
Tone (0.2): Does it match the brand voice?
  1=off-brand  5=neutral  10=perfectly on-brand
Actionability (0.2): Do CTAs clearly communicate what happens next?
  1=unclear  5=adequate  10=crystal clear action
Accessibility (0.1): Is the language inclusive and jargon-free?
  1=exclusionary  5=neutral  10=fully inclusive
Threshold: 7.5

---

反模式 / 常见错误

反模式	为什么不对	正确做法
对可量化的标准使用 LLM-as-judge	浪费 token，可靠性低于断言	对所有可量化的内容使用确定性测试
评估维度含糊不清（“好不好？”）	会产生不可靠、不一致的分数	使用具体的维度，并提供有明确标准的示例
未定义及格门槛	无法客观判断通过或失败	始终在评估前设置门槛
为了让不合格的内容通过而调整评估标准	违背了质量门槛的初衷	修改内容，而不是评估标准
只评估一次，不说明理由	不理解原因就无法改进	始终要求说明每个维度的评估理由
使用较弱的模型进行评估	判断质量较低	使用最强的可用模型（Opus）
修改后跳过重新评估	无法验证修改是否提升了质量	修改后始终重新评估

---

集成点

技能	关系
acceptance-testing	LLM-as-judge 用于处理主观的验收标准
spec-writing	规范可能包含主观质量标准
code-review	在代码审查期间评估可读性
verification-before-completion	完成前的主观验证门槛
senior-prompt-engineer	使用 LLM-as-judge 评估提示词质量
tech-docs-generator	文档质量评估

---

下游引导模式

+----------+     +----------+     +----------+     +----------+
|  SPECS   |---->|   CODE   |---->|  TESTS   |---->| LLM-AS-  |
|          |     |          |     |(determin)|     |  JUDGE   |
|          |     |          |     |          |     |(subject) |
+----------+     +----------+     +----------+     +----+-----+
                      ^                                  |
                      |          backpressure             |
                      +----------------------------------+

确定性测试用于验证客观标准。LLM-as-judge 用于验证主观标准。两者都必须通过。

---

技能类型

FLEXIBLE — 根据上下文调整评估维度和门槛。模式结构（定义评估标准、评估、打分、迭代）固定不变。始终在评估前设置门槛，切勿在评估后设置。