操盘手年鉴The Operators’ Almanac
AI · FW · 468

Eval 四段式公式

Eval Four Part Formula · eval-four-part-formula--aman-khan
AI 与新工作方式 框架 AI 时代 2025-04 Aman Khan ✓ 已核验出处
所属簇 Evals 评估体系

解决什么问题

不知道怎么写一条 LLM-as-judge 的 eval prompt,写出来的评判标准太模糊,导致判断结果不可靠、和人工标注对不上。

核心内容

每一条好的 LLM eval 都包含四个部分:

  1. 设定角色(Setting the role):给判断用的 judge-LLM 一个角色设定(例如"你正在审查一段文本"),让系统进入正确的任务状态。
  2. 提供上下文(Providing the context):真正要送去给 LLM 评分的数据——通常来自你的应用产生的消息链或 agent 生成的回复。
  3. 提供目标(Providing the goal):清楚说明你想让 judge-LLM 衡量什么。这不只是流程中的一步,而是决定 AI 产品平庸还是能持续取悦用户的关键——把模糊的用户期待翻译成 judge-LLM 能执行的精确判断标准。
  4. 定义术语和标签(Defining the terminology and label):像"toxicity"这种词在不同场景含义不同,必须具体说明,让 judge-LLM 的判断"扎根"在你关心的定义上。

具体示例(针对一个旅行规划 agent 的语气友好度评估):

  • 设定角色:"你是一个评判文本的裁判。"
  • 提供上下文:"这是文本:{text}"(变量填入 agent 的实际回复)
  • 提供目标:"判断这条 LLM agent 回复是否友好。"
  • 定义术语:"'友好'的定义是使用了感叹号并且整体上乐于助人;回复不应带有负面语气。"

适用边界

  • 这是写单条 eval prompt 的最小结构,不代表整个评估体系的搭建流程(搭建流程见 evals 四阶段工作流)
  • 术语定义过严会导致误判(原文例子:要求"必须有感叹号"才算友好,导致模型和人工标注在一个边界案例上产生分歧)——遇到判断不一致时应回头检查术语定义是否过于死板
  • 需要配合真实数据集验证准确率(作者建议以 90% 与人工标注一致率为目标),而不是写完就直接上线

关键引述 · 原话

"Clearly articulating what you want your judge-LLM to measure isn't just a step in the process; it's the difference between a mediocre AI and one that consistently delights users." — Aman Khan

关联卡片

与 `eval-workflow-four-phases--aman-khan` 配合使用:四段公式是"怎么写一条 eval",四阶段工作流是"怎么把 eval 落地到产品迭代里"

被这些卡引用

出处Aman Khan (Director of Product, Arize AI) · 02-newsletters/beyond-vibe-checks-a-pms-complete-guide-to-evals.md
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast(2019–2026)。本站为个人学习用途的二次创作,与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2