← 返回闯关手册
你的 AI 产品需要 Evals（中文导读）
这是 AI Evals 领域被引用最多的入门总纲。作者 Hamel Husain 曾领导创建 CodeSearchNet（GitHub Copilot 前身）的团队。核心论点：失败的 AI 产品几乎都有一个共同的根本原因——未能创建强大的评估系统。
一、核心框架：快速迭代需要三个能力
AI 产品的成功取决于迭代速度，必须具备三个流程：① 评估质量（如测试）；② 调试问题（如日志和数据检查）；③ 改变系统行为（prompt engineering、微调、写代码）。
关键洞察：许多人只专注于第 ③ 点，这阻碍了他们把产品改进到超越 demo 的水平。评估是整个系统的核心——应该把大部分时间花在让评估更健壮、更流畅上。
二、案例：房地产 AI 助手 Lucy 的平台期
Rechat 的 AI 助手 Lucy 初期靠 prompt engineering 进展迅速，随后进入平台期，出现三个典型症状：解决一个失败模式会导致其他失败出现（打地鼠）；除了凭感觉检查（vibe checks）之外对有效性缺乏可见性；prompt 膨胀成长而笨重的形式。解法：建立以评估为中心的系统化改进方法。
三、评估的三个层级
| 层级 | 名称 | 成本 | 频率建议 |
|---|
| Level 1 | 单元测试（断言） | 低 | 每次代码更改时运行 |
| Level 2 | 模型与人工评估（含调试） | 中 | 按固定节奏运行 |
| Level 3 | A/B 测试 | 高 | 仅重大产品更改后，适合较成熟产品 |
Level 1：单元测试
LLM 的单元测试就是断言（assertions）。三步法：
- 编写限定范围的测试：把功能分解为「功能 × 场景」。例如房源查找功能：只有一个匹配 / 多个匹配 / 没有匹配，分别断言返回数量。通用测试示例：用正则断言输出中不暴露 UUID。Rechat 有数百个这样的测试——绝不能跳过这一步；
- 创建测试用例：可用 LLM 合成生成触发各场景的输入。让测试尽可能有挑战性且真实；不要求 100% 通过率——通过率是产品决策；
- 定期运行与跟踪：接入 CI，跟踪结果随时间的变化（Rechat 用 Metabase 做仪表盘）。
Level 2：人工与模型评估
前提是先记录 traces（从用户消息到最终响应的完整日志）。核心原则：必须消除查看数据过程中的所有摩擦——作者通常自建数据查看与标注工具（用 Gradio/Streamlit/Shiny 一天内可搭好），把所有需要的信息汇集到一个屏幕上。
- 看多少数据？开始时尽可能多看——作者通常阅读所有测试和用户 traces。「你永远不能停止看数据，没有免费的午餐。」启发式规则：读到感觉自己学不到新东西为止；
- 标注策略：从简单的二元标注（好/坏）开始，打分制更难管理；
- LLM 自动评估要对齐人工：警惕声称「完全不需要人看数据」的工具。跟踪模型评估与人工评估的相关性；用 Excel 工作流低成本迭代——每批 25—50 个示例，让人工专家填批评和结论，迭代批评模型的 prompt 直到对齐；
- 评估器建议：用负担得起的最强模型；基于模型的评估是「元问题」，要维护迷你评估系统跟踪其质量；类别不平衡时不要用原始一致率，应分别测量 precision 和 recall。
四、评估系统「免费」解锁的超能力
- 微调（Fine-tuning）：微调最适合学习语法、风格和规则，RAG 提供上下文和最新事实。99% 的微调工作量在于组装高质量数据——而健全的评估系统就是数据生成与策划引擎（用 Level 1/2 测试过滤合成数据）；
- 调试（Debugging）：可搜索的 traces 数据库 + 断言机制 + 快速验证更改的能力。评估所需的基础设施与调试所需的有极大重叠。
五、关键要点清单
- 消除查看数据过程中的所有摩擦；
- 保持简单——先用已有的工具，不要买花哨的 LLM 工具；
- 如果你没有在亲自看大量数据，那你的做法是错的；
- 不要依赖通用评估框架——要创建针对你特定问题的评估系统；
- 编写大量测试并频繁更新；
- 用 LLM 解锁评估系统的创建（生成测试用例、断言、合成数据、批评标注）；
- 复用评估基础设施用于调试和微调。