评估的权威指南：从 100 次手动审查和'仁慈的独裁者'开始

观点

这是 Hamel Hussein 和 Shrea Shankar - Maven 上排名第一的评估课程的讲师，已培训了 2000+ 产品经理和工程师，包括 OpenAI 和 Anthropic 的团队。他们的流程在开始时出人意料地手动，这正是重点所在。

“最大的误解是：AI 不能自动评估吗？” 不行。当 Hamel 展示了一个 trace（LLM 交互的日志），其中 AI 安排了一个不存在的虚拟游览时，ChatGPT 会说”看起来不错”，因为它缺乏上下文来了解该功能是否存在。领域专家在几秒钟内就能发现它。LLM 会错过产品的味道。

流程：采用仁慈独裁者的开放式编码。 查看 trace（LLM 交互的日志）。快速记录有什么问题 - 只记录你看到的第一个/最上游的错误。不要试图找到所有问题。不要使用委员会。任命一个你信任品味的人（领域专家）。保持非正式：“糟糕”作为笔记是可以的。至少查看 100 个 trace，直到你达到”理论饱和” - 当你停止学习新东西时。

错误分析先于测试编写。 这与软件工程不同，软件工程中你直接跳到单元测试。对于 LLM，表面积太大，行为也太随机。你首先需要数据分析来理解要测试什么。只有在开放式编码之后，你才能将模式编入自动评估。

房地产代理的例子很完美。 用户询问可用性。AI 说”我们没有那个，祝你有美好的一天。” 从技术上讲是对的。从产品的角度？糟糕。潜在客户管理工具应该移交给人类，而不是关闭对话。这只有产品经理才能发现。

不要让评估变得昂贵。 仅二进制分数（通过/失败）。一个领域专家，不是委员会。抽样你的数据，不要审查所有内容。目标不是完美 - 而是可行的改进。如果你让流程变得昂贵，你就不会做。

关键要点

• LLM 无法进行错误分析 - 它们缺乏上下文；对明显的产品失败说”看起来不错”
• 开放式编码 - 快速记录第一个错误；不寻找所有问题；保持非正式
• 仁慈的独裁者 - 一个你信任的领域专家；不是委员会
• 最少 100 个 trace - 直到理论饱和；你会在 20 个后上瘾
• 理论饱和 - 当你停止学习新东西时停止
• 仅二进制分数 - 通过/失败；不要使用 1-5 的评级；使所有内容都可以处理
• 错误分析 → 测试 - 不同于软件工程；在编入之前理解
• 需要产品人员 - 工程师会错过产品的味道；领域专业知识至关重要
• 抽样，不要审查所有内容 - 使流程可持续
• “糟糕”是有效的 - 保持笔记非正式；具体性比优雅性更重要

大局观

AI 评估不是自动化测试 - 它是需要人类判断的数据分析。那些发布可靠 AI 产品的公司不使用复杂的框架；他们让领域专家面对 trace 并让他们培养品味。没有捷径存在。