原始标题: How to Build AI Evals in 2026 (Step-by-Step, No Hype)

发布日期: 2026-01-15 | 来源频道: @growproduct

📝 深度摘要

1. 对话背景与核心主题

本视频由AI产品增长频道@growproduct发布，聚焦AI产品评估体系建设这一核心议题。视频针对AI产品经理在生产环境中面临的错误识别与优先级排序难题，提出了一套基于可观测性工具与人工编码的三步评估方法。核心元问题在于：如何突破通用评分指标的局限，建立能够捕捉产品细节问题的量化评估体系。视频以NurtureBoss物业管理AI助手为案例，演示了从trace采集、人工标注到自动化评估的完整流程，强调AI产品迭代应依赖产品直觉而非单纯追求指标完美，百条数据即可为产品改进提供有效指导。

核心干货概览 (Key Takeaways & Stack)

类别 名称 核心用途 / 战略意义
工具/模型 Brain Trust / Langmith / Arise 可观测性平台，用于捕获和查看AI应用的trace
工具/模型 Google Sheets + Gemini 快速搭建LLM Judge评估流程，无需复杂工程
思维模型 Open Coding（开放编码） 人工扫描trace并记录观察笔记，捕捉产品细节问题
思维模型 Axial Coding（轴向编码） 将开放编码的笔记归类为可操作的错误类别
思维模型 Pivot Table Analysis（透视表分析） 统计各类错误频率，识别最高优先级的产品问题
关键指标 错误分类频率 用于决定产品迭代优先级的量化依据
关键指标 Binary Score（二元评分） LLM Judge应返回True/False，而非1-5评分

深度逻辑拆解 (Deep Dive / SOP)

核心挑战

AI产品在生产环境中表现与demo差距巨大。demo可以完美展示，但生产环境中存在大量" messy"（混乱）情况：拼写错误、用户意图模糊、多轮对话、跨渠道交互（语音/短信/聊天机器人）、工具调用失败、RAG检索错误等。产品经理需要一套系统化方法来识别、分类和优先处理这些错误。

步进 SOP

Step 1: trace采集与可视化

  • 使用可观测性工具（Brain Trust、Langsmith、Arise）捕获应用的完整trace
  • 不需要立即使用昂贵平台，CSV/JSON文件也可作为起点
  • NurtureBoss案例展示：AI租务助手应用，包含工具调用、RAG、多轮对话、跨渠道（语音/短信/聊天）交互

Step 2: Open Coding（开放编码）

  • 扫描每条trace，人工记录观察到的问题
  • 示例记录格式：
    • “告诉用户会检查浴室但未执行”
    • “未遵循用户指令：用户要非连通浴室但推荐了连通浴室”
    • “在短信中渲染了markdown格式”
  • 关键原则：不追求完美，30秒内快速扫描一条trace，记录最重要的问题
  • 建议样本量：约100条trace

Step 3: Axial Coding（轴向编码）

  • 使用AI（如ChatGPT/Claude）辅助将开放编码的笔记分类
  • 创建5-6个核心类别，示例：
    • Human Handoff Issues（人工交接问题）
    • Conversational Flow Issues（对话流程问题）
    • Capability Limitations（能力限制）
    • Temporal Context Issues（时间上下文问题）
  • 关键要点：类别定义必须具体可操作，避免"质量"这类模糊术语
  • 迭代修正类别定义，添加"以上都不是"选项以发现遗漏

Step 4: Pivot Table统计与优先级排序

  • 使用数据透视表统计各类错误的出现频率
  • 结合产品判断决定优先级：高频错误不一定最高优先级，需考虑错误的影响程度
  • 数据支撑的决策：不再凭直觉或"vibe check"决定工作优先级

Step 5: LLM Judge构建与迭代

  • 针对高优先级错误类别编写评估Prompt
  • 核心原则：使用Binary Score（True/False）
    • 原因1：多选项评分（如1-5分）容易出现对齐偏差
    • 原因2：业务决策本身就是二元决策（修或不修）
    • 原因3：只需验证True和False两种情况，对齐更容易
  • Prompt结构示例：
    • 角色定义：租赁助手评估员
    • 规则说明：什么情况算handoff failure
    • 示例：提供正例和反例
    • 输出要求：仅返回True或False
  • 关键迭代：不要完全依赖LLM生成的类别定义，需人工审核和调整

案例/细节支撑

NurtureBoss案例细节

  • 产品定位：物业管理AI助手，处理租户交互、营销和销售
  • 交互渠道：语音、短信、聊天机器人
  • 真实trace问题案例：
    1. 用户要求"一居室，浴室不连通"，AI推荐了"浴室连通"的房源
    2. 用户要求虚拟看房，但该平台不支持虚拟看房，AI仍承诺并安排了实地看房
    3. AI承诺"检查浴室"但未执行任何工具调用
    4. 短信回复中使用markdown格式（星号、粗体），导致短信显示异常
    5. 日期理解错误：用户说"今天22号"，AI理解为"明天"并重复预约，导致用户有两个预约

讲师背景

  • 讲师：HL Hussein 和 Shrea Shunker
  • 课程：Maven上的AI PM课程，学员包括OpenAI、Anthropic、Google、Meta等公司
  • 核心理念：AI evals是产品经理最重要的新技能

核心干货运用 (Hard Assets / Prompts)

LLM Judge Prompt模板

你是一个租赁助手评估员，负责判断是否存在人工交接失败（handoff failure）。

请根据以下规则判断，返回仅True或False：

交接失败的情况包括：
1. 用户明确要求转人工但被忽略
2. 根据政策应该转人工但未执行
3. 涉及敏感问题（账单纠纷、法律问题）未转人工
4. 当日看房请求未转人工

非失败情况：
1. AI能够正确处理用户请求
2. 用户请求属于AI能力范围内

请仅返回"True"或"False"，不要返回其他内容。

逻辑注释

  1. 为什么用Binary而非Likert Scale：当使用1-5分评分时，需要验证所有可能的分数都与人类偏好对齐，这非常繁琐。而Binary只需验证"True对齐"和"False对齐"两种情况，大幅降低对齐难度。

  2. 为什么需要具体例子：示例可以帮助LLM理解规则的边界情况，减少误判。

  3. 为什么要迭代Prompt：初始Prompt通常不够精确，需要通过实际运行结果不断调整。“不要完全把方向盘交给AI”——要批判性思考AI输出的质量。

PM 避坑与实战洞察 (Insights & Reflections)

反直觉结论

  1. 通用指标（如helpfulness score）几乎无用：试图用"帮助性评分"、“简洁性评分"等通用指标来评估AI，你会发现AI根本无法捕捉产品层面的细微问题。PM的"产品品味”（taste）无法被通用指标替代。

  2. 不用等到"完美"才开始：很多PM追求完美的评估体系而陷入瘫痪。实际上，只需要扫描100条trace，记录观察到的问题，就能获得足够信息指导产品决策。

  3. AI辅助分类需要人工复核：让AI将开放编码的笔记分类到类别中，但类别定义必须足够具体。“质量问题"这样的模糊类别毫无意义，应该定义为"对话流程问题"或更具体的"未遵循用户偏好”。

  4. 不是所有问题都需要写Eval：有些错误（如markdown格式问题）可能只需在Prompt中加一行指令就能修复，不需要复杂的评估流程。

适用边界

  • 该方法适用于有具体产品场景的AI应用，不适用于纯通用能力评估
  • 对于超大 scale 公司（如Meta、Google），可能需要更大规模的自动化评估和团队协作
  • 如果应用场景非常简单（单一功能），可能不需要完整的error analysis流程

实战陷阱

  1. 不要只依赖LLM判断：把trace丢给ChatGPT问"这个回答正确吗"，AI通常会说"是的，听起来正确"，但会遗漏所有产品层面的细节问题。

  2. 不要使用模糊的类别名：如"质量"、“用户体验"这类类别无法指导具体行动。

  3. 不要在trace中追求完美复现：真实生产环境的trace包含各种"噪音”（拼写错误、格式问题），这是正常的。

  4. 不要跳过Prompt实验：NurtureBoss通过vibe coding构建了自己的trace查看工具，简化了error analysis流程。对于PM来说，拥有能快速查看和标注trace的界面非常重要。

金句

  • “Evals是产品经理最重要的新技能。”
  • “你的AI agents在生产环境中做的事情，往往与demo展示的完全不同。这就是为什么查看trace如此重要。”
  • “通用指标无法捕捉产品层面的细微问题。PM的产品品味无法被AI替代。”
  • “不要把方向盘完全交给AI。要批判性思考AI输出的质量。”
  • “业务决策本身就是二元决策——修或不修。所以评估也应该用Binary Score。”
  • “只需要30秒，你就能扫描一条trace并记录关键问题。完美不是关键，看到问题并记录下来才是关键。”
  • “当你有了这些数据，你就不再是在黑暗中写邮件。你可以根据实际问题来驱动产品决策。”

📺 视频原片

视频ID: J7N9FMouSKg