这篇超有用！手把手教你搭建 AI 产品 Evals
流传最广的 Evals 入门教程（Aman Khan 原作，Founder Park 编译），Lenny's Newsletter 出品。四阶段闭环讲得干净利落，是「从零到一跑通第一个 eval」的最佳导引。
核心内容速览
- 三种评估方法按场景组合：代码评估（可验证输出，便宜快速）、LLM-as-judge（主观任务，可扩展）、人工评估（基准与抽检）。
- Eval prompt 四要素：设定角色 → 提供上下文 → 阐明目标（精确定义好与坏）→ 定义术语与标签。
- 四阶段闭环：收集 10–100 条标注样本 → 写 eval 并对齐人工（目标准确率 ≥90%）→ 分析失败模式迭代 prompt → 用同一套 eval 做改模型/改 prompt 的 A/B 测试。
- 三个常见坑：起步设计太复杂、不测边缘案例、不用真实用户反馈验证 eval 本身。
适合谁 · 怎么用
零基础入门的第一篇（路径第 1 步就是它）。工具上可以从文中推荐的 Phoenix（Arize）或 promptfoo 起步。
闯关自测
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
Q1 三种评估方法各自最适合什么场景？
代码评估：输出可程序化验证（格式、可执行、含特定内容），便宜快速；LLM-as-judge：主观开放任务，可规模化；人工评估：建立基准与抽检，成本高但最贴近真实体验。
Q2 一个合格的 eval prompt 有哪四个要素？
设定角色 → 提供上下文（待评数据）→ 阐明目标（精确定义好与坏）→ 定义术语与标签（如「toxic」在你的语境下具体指什么）。
Q3 起步数据集多大合适？Judge 与人工对齐的目标是多少？
10–100 条带人工标注的真实样本即可起步；eval 与人工判断的一致率目标 ≥90%，不达标就分析失败案例改 prompt。
以下为原文全文
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
几乎每个用生成式 AI 的产品经理都痴迷于打磨 prompt 和追新模型，但很少有人真正掌握每个 AI 产品背后那个隐藏的杠杆：评估（Evaluations）。Evals 是唯一能让你拆解系统中每一步、并精确衡量单个变更影响的方法。Prompt 可能会上新闻头条，但 Evals 却在悄无声息地决定你产品的生死。
Evals：为 AI 产品定义一个「好」的标准
Evals 是你衡量 AI 系统质量和效果的方法，像软件开发中的回归测试，为产品清晰地定义「好」的标准。评估 AI 系统不像传统软件测试，更像一场驾照考试：
- 感知：能否准确解读信号，对变化的环境做出适当反应？
- 决策：即使在未知情况下，能否稳定做出正确选择？
- 安全：能否始终遵循指令，安全抵达目的地？
传统单元测试像检查火车会不会脱轨：过程直接，结果确定。而 LLM 的 Evals 更像开车穿过繁忙的城市：环境多变，系统本身不确定——同一 prompt 多次输入，可能得到略微不同的回答。你处理的通常是定性或开放式指标（相关性、连贯性），难以用简单的「通过/失败」衡量。
Evals 的三种方法
人工 Evals
内置人工反馈机制（赞/踩按钮），或请领域专家标注。优点：直接关系到最终用户体验。缺点：反馈稀少、信号不强、成本高。
基于代码的 Evals
检查 API 调用或代码生成结果（如生成的代码是否可执行）。优点：成本低、速度快，初次实施常比 LLM-as-judge 更省。缺点：对主观或开放式任务信号弱。
基于 LLM 的 Evals（LLM-as-judge）
用外部 LLM 充当「裁判」，通过特定 prompt 评估输出质量。优点：可扩展性极高（相当于成本极低的人工标注团队），产品经理可直接用自然语言编写，可要求裁判给出解释便于调试。缺点：需要少量已标注样本做初始设置和性能验证；结果是概率性的，需要足够数据量才能信任信号。
基于 LLM 的 Evals 本身就是一种自然语言 prompt——就像你需要通过 prompt 塑造 Agent 的能力，你也需要通过编写 prompt 来描述你希望评估系统捕捉到的问题。
旅行规划 Agent：每个环节都可能出错，也都有对应的 Eval
通用评估标准
- 幻觉（Hallucination）：Agent 是准确利用了提供的上下文，还是在凭空捏造？适用于提供文档供 Agent 推理的场景；
- 恶意/语气（Toxicity/Tone）：输出是否包含有害或不当言论；
- 总体正确性：系统在核心目标上的表现，如问答准确率；
- 其他常见领域：代码生成、摘要质量、检索相关性。
一个优秀的 LLM Eval 由四部分组成
- 设定角色：给裁判 LLM 一个角色（如「你是审查书面文本的专家」）；
- 提供上下文：将要评分的实际数据（对话记录或 Agent 生成的消息）；
- 阐明目标：清晰说明希望裁判衡量什么——精确定义成功与失败的标准，把用户微妙的期望转化为明确准则。这是区分 AI 质量的关键；
- 定义术语与标签：如「恶意」在不同语境含义不同，要做出具体规定，让裁判的判断标准与你的定义一致。
从零开始构建一个 Eval：四阶段
第一阶段：收集数据
收集真实用户交互（赞/踩反馈、人工查阅交互记录），记录边缘案例，构建一个代表性数据集，最好附上人工标注的「真实标签」。经验建议：初期准备 10—100 条带人工标签的样本作为基准。可从电子表格开始，后续考虑用 Phoenix 等开源工具管理数据。
第二阶段：初步评估
按四部分公式编写初始 Eval prompt，在数据集上运行，目标是与人工标注基准相比准确率至少达到 90%。然后分析失败模式：评估在哪些地方表现不佳？据此迭代 prompt。例如 prompt 要求「友好的回复必须包含感叹号」可能太严格——这就是需要调整的信号。
第三阶段：迭代循环
- 优化 Eval prompt：加入几个「好」与「坏」的评估案例（few-shot prompting）为裁判提供参照；
- 扩充数据集：定期补充新案例和边缘场景，检验 prompt 是否有效泛化；
- 迭代 Agent prompt：Evals 是 A/B 测试 AI prompt 的终极考验。换模型时（如 GPT-4o → Claude），让新 Agent 重跑问题集，用同一套 Eval 评估输出，目标是超越初始模型的分数。
第四阶段：生产环境监控
设置自动化流程让 Evals 在实时交互中持续运行（如对所有响应持续跑「友好度」Eval，追踪长期趋势）；对比 Eval 结果与真实用户反馈，寻找差异并改进框架；构建可指导行动的 Eval 仪表盘，与业务成果挂钩。
Evals 设计要避免的错误
- 起步就设计得过于复杂——会产生噪音信号，导致团队失去信心。先专注具体的输出评估，后续再增加复杂度；
- 不测试边缘案例——在 prompt 中提供一两个好坏具体案例（few-shot）可显著提升 Eval 性能；
- 忘记用真实用户反馈验证 Eval 结果——你不仅是在测试代码，更是在验证 AI 能否真正解决用户的问题。
找到一个切入点，快速上手
- 为你的 AI 产品选择一个关键特性进行评估。「幻觉检测」是常见切入点；
- 编写一个简单的 Eval，检查 LLM 输出是准确引用了所提供的内容，还是在凭空捏造；
- 在 5—10 个有代表性的真实交互案例上运行；
- 复盘结果并持续迭代，直到准确率达标。
Evals 不仅是为了发现 bug，更是为了确保你的 AI 系统持续创造价值。它是生成式 AI 从原型走向成熟产品的关键一步。
