write-judge-prompt

编写 LLM-as-Judge 提示词

为一种特定故障模式设计一个二元 Pass/Fail LLM-as-Judge 评估器。每个评估器只检查一件事。

前提条件

• 已完成错误分析，并已识别故障模式。
• 你有该故障模式的人工标注轨迹（至少 20 个 Pass 示例和 20 个 Fail 示例）。
• 基于代码的评估器无法检查这种故障模式。在使用评估器之前，先穷尽所有基于代码的选项——许多看似主观的故障模式，在了解其领域后，都可以简化为关键词检查、正则表达式或 API 调用。例如：检测 AI 面试教练是否提出“泛泛”的问题（询问典型行为，而非某个具体的过往事件），看起来需要语义理解，但实际上，检查 “usually”“typical” 和 “normally” 等词就可能相当有效。

四个组成部分

每个评估器提示词都必须包含以下四个组成部分：

1. 任务和评估标准

说明评估器要评估什么。每个评估器只针对一种故障模式。

You are an evaluator assessing whether a real estate assistant's email
uses the appropriate tone for the client's persona.

不要写：“评估这封邮件是否不错”，或“以 1-5 分评价邮件质量”。

2. Pass/Fail 定义

结果严格采用二元形式：Pass 或 Fail。不使用李克特量表、字母等级或部分得分。明确定义 Pass 和 Fail 分别代表什么。这些定义应源自错误分析中的故障模式描述。

## Definitions

PASS: The email matches the expected communication style for the client persona:
- Luxury Buyers: formal language, emphasis on exclusive features, premium
  market positioning, no casual slang
- First-Time Homebuyers: warm and encouraging tone, educational explanations,
  avoids jargon, patient and supportive
- Investors: data-driven language, ROI-focused, market analytics, concise
  and professional

FAIL: The email uses a tone mismatched to the client persona. Examples:
- Using casual slang ("hey, check out this pad!") for a luxury buyer
- Using heavy financial jargon for a first-time homebuyer
- Using overly emotional language for an investor

3. 少样本示例

纳入人工标注数据中的 Pass 和 Fail 示例。

## Examples

### Example 1: PASS
Client Persona: Luxury Buyer
Email: "Dear Mr. Harrington, I am pleased to present an exclusive listing
at 1200 Pacific Heights Drive. This distinguished property features..."
Critique: The email opens with a formal salutation and uses language
consistent with luxury positioning — "exclusive listing," "distinguished
property." No casual slang or informal phrasing. The tone matches the
luxury buyer persona throughout.
Result: Pass

### Example 2: FAIL
Client Persona: Luxury Buyer
Email: "Hey! Just found this awesome place you might like. It's got a
pool and stuff, super cool neighborhood..."
Critique: The greeting "Hey!" is informal. Phrases like "awesome place,"
"got a pool and stuff," and "super cool" are casual slang inappropriate
for a luxury buyer. The email reads like a text message, not a
professional communication for a high-end client.
Result: Fail

### Example 3: PASS (borderline)
Client Persona: First-Time Homebuyer
Email: "Hi Sarah, I found a property that might be a great fit for your
first home. The neighborhood has good schools nearby, and the monthly
payment would be similar to what you're currently paying in rent..."
Critique: The greeting is warm but not overly casual. The email explains
the property in relatable terms — comparing mortgage to rent, mentioning
schools — which is educational without being condescending. It avoids
jargon like "amortization" or "LTV ratio." While not deeply technical,
this matches the supportive tone expected for a first-time buyer.
Result: Pass

示例选择规则：

• 至少包含一个明确的 Pass、一个明确的 Fail，以及一个边界案例。边界案例最有价值——它们能帮助评估器掌握细微差别。
• 从训练集（预留 10-20% 的标注数据集用于此目的）中选取示例。
• 用于评估器提示词的所有示例都必须从开发集和测试集中排除。使用开发集或测试集的示例会造成数据泄漏。
• 通常使用 2-4 个示例。超过 4-8 个后，性能提升会趋于停滞。

4. 结构化输出格式

使用 LLM 提供商的架构约束功能（例如 OpenAI 中的 response_format、Anthropic 中的工具定义），或使用 Instructor、Outlines 等库来强制采用结构化输出。如果提供商不支持架构约束，请在提示词中指定 JSON 架构。

输出必须先包含评析，再给出判定结果。先写评析可迫使评估器在作出决定前明确阐述自己的评估。

{
  "critique": "string — detailed assessment of the output against the criterion",
  "result": "Pass or Fail"
}

评析必须具体详尽，不能过于简短。好的评析会说明具体哪些地方正确或不正确，并引用输出中的具体证据。少样本示例中的评析会为评估器生成的评析设定详尽程度的标准。

选择传给评估器的内容

只提供评估器作出准确判断所需的内容：

故障模式	评估器所需内容
语气不匹配	客户角色设定 + 生成的邮件
答案忠实度	检索到的上下文 + 生成的答案
SQL 正确性	用户查询 + 生成的 SQL + 架构
指令遵循	系统提示词规则 + 生成的回复
工具调用合理性	对话历史 + 工具调用 + 工具结果

对于较长的文档，只提供相关片段，而不是整份文档。

模型选择

从当前可用的能力最强的模型开始。主任务使用的同一模型也可以用作评估器（评估器执行的是不同且范围更窄的任务）。确认评估结果一致后，再优化成本。

反模式

• 标准模糊，例如“这有帮助吗？” 应针对错误分析中发现的具体、可观察的失败模式。
• 用一个整体评判器评估整条轨迹。 一个评判器覆盖多个维度，会给出无法指导后续行动的判定结果。
• 没有少样本示例。 没有示例，模型就不知道在你的应用中什么情况算失败。
• 将开发/测试示例用作少样本示例。 这会造成数据泄漏。只能使用训练集。
• 使用李克特量表（1–5、字母等级等）。 只能使用二元通过/失败判定。李克特量表给出的分数看似精确，却无法校准：标注者对 3 分和 4 分的区别意见不一，而评判器也会继承这种噪声。二元判定会迫使你预先定义清晰的决策边界，从而能够衡量标注者间的一致性，并让评判器的错误更具可操作性。如果需要体现严重程度，可以使用多个二元评判器（例如“事实错误”和“危险性错误”），而不是使用一个有序量表。
• 跳过验证。 在信任评判器之前，使用 validate-evaluator 衡量其与人工标签的一致性。
• 未先修复提示词，就针对规范要求未满足的情况构建评判器。 如果提示词从未要求模型执行该行为，应先添加相应指令，再构建评估器。对于关键要求，评判器仍可作为回归保护。