元信息
- 标题：Your AI Product Needs Evals
- 作者：Hamel Husain（曾主导 CodeSearchNet，GitHub Copilot 前身）
- 来源 URL：https://hamel.dev/blog/posts/evals/index.html
- 发表日期：2024-03-29
- 存档日期：2026-10-28
- 标签：LLM评估、AI工程、Agent系统、质量保障、方法论文
收藏理由：LLM 评估方法的开山长文（Hamel Husain, 2024-03）：以真实案例把评估拆成单元测试、人工+LLM 对齐评估、A/B 三层落地路径，核心心法是"消除查看数据的摩擦"——这是把 LLM 应用从 vibes 推向可靠产品的必读评估体系。
这篇讲什么
作者基于多年构建 LLM 产品的经验（包括房产 SaaS Rechat 的 AI 助手 Lucy），指出失败的 LLM 产品几乎共享同一个根因：没有健壮的评估系统。全文以 Lucy 为案例，给出一套可落地的三层评估体系：Level 1 单元测试（把 LLM 行为拆成"功能×场景"，写成快速便宜的断言，每次代码变更都跑）、Level 2 人工+模型评估（记录 trace、人眼看数据，再用 critique 模型对齐人工标注）、Level 3 A/B 测试（成本最高，留给成熟产品）。三层成本递增，决定了各自的执行节奏：每次提交、定期、重大变更后。
核心观点
- 迭代速度 == 成功。改进 AI 只有三件事：评估、调试、改行为。多数人只盯着改 prompt（第三件），所以产品永远停在 demo 阶段；评估体系像软件测试一样，前期投入换来长期复利。
- 消除查看数据的一切摩擦。宁可自己花一天用 Gradio/Shiny 搭数据查看工具，把 trace、CRM、标注按钮聚合到一个屏幕上——看数据的意愿直接决定产品上限。
- 评估基础设施会被"免费"复用：单元测试和标注数据既是质量闸门，又是 fine-tuning 数据的合成与清洗引擎（作者称 fine-tuning 99% 的工作量就是凑高质量数据），也是调试时的 trace 检索库。评估、微调、调试共享同一套基础设施。
最值得记住的金句与数据
- "Remove ALL friction from looking at data."——全文心法，也是结论第一条。
- "You can never stop looking at data—no free lunch exists."——起步阶段读所有 trace，之后才逐步抽样。
- "Many people focus exclusively on changing behavior, which prevents them from improving their LLM products beyond a demo."——只改 prompt 不建评估，是多数人卡住的原因。
- Rechat 积累了数百个单元测试，随新失败模式持续更新；用 Metabase 追踪错误率随时间下降。
- 模型评估对齐实操：用 Excel 走低技术路线，每次人工标注 25-50 条，迭代 critique prompt；类别不平衡时用 precision/recall 而非裸一致率。
对我的启发
- AI 编程工具 / Agent 系统：agent 的可靠化路径正是"断言先行"——先把可判定的失败模式写成廉价断言（如"输出不得暴露 UUID"），再谈 LLM-as-judge；且测试用例本身可以让 LLM 批量合成，不必等生产数据。评估系统建好后，fine-tuning 数据几乎白拿。
- 个人知识管理："消除查看数据的摩擦"同样适用于知识库：存档不是终点，降低回看笔记的摩擦（好的目录、导读、一眼可见的元信息）才会真正复用知识——本知识库的 digest 机制正合此道。
- 写作：一个具体案例（Lucy）贯穿全文、每个抽象概念都锚定在案例细节上，是技术长文值得模仿的写法。
适合谁读
正在把 LLM/Agent 应用从 demo 推向可靠产品的工程师与 PM；被"改 prompt 像打地鼠"困住的团队；以及任何想建立 AI 质量门禁但不知从何下手的人。零门槛，建议配合作者的 AI Evals 课程与后续 evals-faq 系列食用。