当失败模式需要语义判断（语气、忠实度、相关性…

为单个主观失败模式设计一个只判断一件事的二元 Pass/Fail LLM 评审提示词

适用场景

解决思路

1. 先完成错误分析并确定失败模式，且已有人工标注的 trace（至少 20 个 Pass 和 20 个 Fail 示例）
2. 在采用评审器前穷尽代码方案：很多看似主观的失败模式在理解领域后可归结为关键词检查、正则或 API 调用（例如检测面试教练是否建议“泛泛”问题，可用 usually、typical、normally 等关键词检查）
3. 每个评审器只检查一个失败模式，不要做覆盖整个 trace 的整体评审
4. 组件一：任务与评估标准——明确说明评审对象，例如“你是一名评估者，评估房地产助理的邮件是否对客户画像使用了恰当语气”，不要写“评估邮件好不好”或“给邮件质量打 1-5 分”
5. 组件二：Pass/Fail 定义——结果严格二元，不用 Likert 量表、不用字母等级、不给部分分；Pass 和 Fail 的定义来自错误分析中的失败模式描述，并给出具体反例
6. 组件三：Few-shot 示例——从人工标注数据中选取带标签的 Pass 和 Fail 示例，每个示例包含输入、输出、critique 和 Result
7. 示例选择规则：至少包含一个明确 Pass、一个明确 Fail、一个边界案例（边界案例最有价值，用于教模型细微差别）
8. 示例从训练集切分中抽取（预留 10-20% 标注数据作为训练集）
9. 任何用于评审提示词的示例都必须从 dev 和 test 集中排除，否则是数据泄漏
10. 示例数量通常 2-4 个，超过 4-8 个后性能趋于平台期
11. 组件四：结构化输出——用 LLM 提供方的 schema 强制（如 OpenAI 的 response_format、Anthropic 的 tool definitions）或 Instructor、Outlines 等库；若提供方不支持 schema 强制，则在提示词中写明 JSON schema
12. 输出必须先有 critique 再有 verdict，把 critique 放在前面迫使评审器在做出决定前先阐述评估
13. 输出 JSON 包含 critique（字符串，对输出针对标准的详细评估）和 result（Pass 或 Fail）
14. critique 必须详细而非简短，要说明具体哪里正确或错误并引用输出中的具体证据；few-shot 示例中的 critique 设定了评审器应产出的详细程度
15. 只向评审器传入做出准确判断所需的内容：语气不匹配传客户画像+生成邮件；答案忠实度传检索上下文+生成答案；SQL 正确性传用户查询+生成 SQL+schema；指令遵循传系统提示规则+生成响应；工具调用合理性传对话历史+工具调用+工具结果
16. 对长文档只传相关片段，不要传整个文档
17. 模型选择：先用可用的最强模型，主任务所用的同一模型也可作为评审器（评审是不同且更窄的任务）；确认对齐后再优化成本
18. 避免反模式：标准含糊（如“这有帮助吗？”）——要针对错误分析中具体可观察的失败模式
19. 避免反模式：对整个 trace 做整体评审——单个评审器覆盖多个维度会产生无法行动的判定
20. 避免反模式：没有 few-shot 示例——没有示例模型不知道在你的应用中什么算失败
21. 避免反模式：用 dev/test 示例做 few-shot——这是数据泄漏，只能用训练集切分
22. 避免反模式：Likert 量表（1-5、字母等级等）——只用二元 pass/fail；Likert 分数看似精确但无法校准，标注者对 3 和 4 的差异意见不一，评审器会继承这种噪声；二元强制你预先定义清晰决策边界，使标注者间一致性可测量、评审器错误可行动；若需捕捉严重程度，用多个二元评审器（如“事实错误”和“危险错误”）而非一个序数量表
23. 避免反模式：跳过验证——在信任评审器前用 validate-evaluator 测量与人工标签的对齐度
24. 避免反模式：对规范类失败未先修提示词就建评审器——如果提示词从未要求该行为，先加指令再建评估器；对关键需求，评审器仍可作为回归守卫

适用边界 · 注意事项

• 当失败模式可以用代码检查（正则、schema 校验、执行测试）时不要用评审器
• 当你需要验证或校准评审器本身时不要用，应改用 validate-evaluator
• 当失败模式属于规范类问题且提示词尚未要求该行为时，先修提示词再考虑评审器