用途
Write LLM-as-Judge Prompt 用于为某一个具体的失败模式设计一个二元的 Pass/Fail LLM-as-Judge（大模型作为评判者）评估器。每个评判器只检查一件事。它适用于那些代码评估器无法检查、需要语义理解的评估场景。
前置条件
- 错误分析已完成，失败模式已识别。
- 已拥有该失败模式的人工标注 traces（至少 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.
不应使用：“Evaluate whether the email is good” 或 “Rate the email quality from 1-5.”
2. Pass/Fail 定义
结果严格二元：Pass 或 Fail。不使用 Likert 量表、不使用字母等级、不使用部分分数。需要精确定义什么构成 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. Few-Shot 示例
包含来自人工标注数据的、带标签的 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、以及一个临界（borderline）案例。临界示例最有价值——它们教授细微差别。
- 示例从训练集（为此外预留的标注数据的 10-20%）中抽取。
- 任何用于评判提示词的示例都必须从 dev 和 test 集中排除。使用 dev/test 示例属于数据泄漏。
- 通常 2-4 个示例。4-8 个之后性能趋于平台期。
4. 结构化输出格式
使用你的 LLM 提供商的结构化输出强制机制（例如 OpenAI 的 response_format、Anthropic 的 tool definitions），或使用 Instructor、Outlines 之类的库来强制结构化输出。如果提供商不支持 schema 强制，则在提示词中指定 JSON schema。
输出必须包含先于结论的批判（critique）。把批判放在前面，迫使评判器在做出决定之前先阐述其评估依据。
{
"critique": "string — detailed assessment of the output against the criterion",
"result": "Pass or Fail"
}
批判必须详细，而非简短。好的批判会具体解释哪里正确或错误，并引用输出中的具体证据。Few-Shot 示例中的批判细节水平会为评判器设定标准。
选择传给评判器的内容
只传入评判器做出准确决定所需的内容：
- 语气不匹配：客户画像 + 生成的邮件
- 答案忠实度：检索到的上下文 + 生成的答案
- SQL 正确性：用户查询 + 生成的 SQL + schema
- 指令遵循：系统提示词规则 + 生成的回复
- 工具调用合理性：对话历史 + 工具调用 + 工具结果
对于长文档，只传入相关片段，而非整个文档。
模型选择
从可用的能力最强的模型开始。用于主任务的同一模型也可作为评判器（评判器执行的是另一项更窄的任务）。在确认对齐之后再优化成本。
反模式
- 模糊标准，如“这是否有帮助？”。应针对错误分析中特定的、可观察的失败模式。
- 对整个 trace 做整体评判。单个评判器覆盖多个维度会产生无法据以行动的结论。
- 没有 Few-Shot 示例。没有示例，模型不知道在你的应用中什么算失败。
- 使用 dev/test 示例作为 Few-Shot。这是数据泄漏。只使用训练集。
- 使用 Likert 量表（1-5、字母等级等）。只用二元 Pass/Fail。Likert 量表产生的分数听起来精确但无法校准：标注者对 3 和 4 的区别存在分歧，评判器会继承这种噪声。二元强制你预先定义清晰的决策边界，使标注者间一致性可衡量，评判器的错误可据以行动。如果你需要捕获严重程度，使用多个二元评判器（例如“事实错误”和“危险错误”），而非一个序数量表。
- 跳过验证。在信任评判器之前，使用 validate-evaluator 衡量与人工标签的对齐度。
- 对规范类失败构建评判器而不先修复提示词。如果提示词从未要求该行为，应先添加指令再构建评估器。对于关键需求，评判器仍可作为回归防护。