@LangChain: "Validate your validators." The eval advice nobody is following. Watch @sh_reya + @HamelHusain’s Interrupt keynote on t…

“Validate your validators.”

The eval advice nobody is following.

⏯️ Watch @sh_reya + @HamelHusain’s Interrupt keynote on the return of the data scientist: https://t.co/olOqyGs7a5 https://t.co/IpghaMmPBs

TL;DR: 在AI评估中，不要依赖通用指标或未经验证的LLM评判器；应像数据科学家一样，反复查看数据、设计具体故障模式、验证验证器，并做严谨的实验设计。

背景：从数据科学到AI工程的退步

演讲者指出，四年前的机器学习工程和数据科学中，团队会仔细检查数据、可视化、确保模型与人类标注对齐，并精心设计指标来匹配业务目标。今天的AI工程却在很多方面退步了——人们凭感觉判断正确性，常常问模型自己做得怎么样，很少思考指标设计，直接套用现成指标包。这导致评估（evals）和检索（retrieval）频繁失败。本次演讲聚焦评估，揭示常见错误并教大家如何戴上“数据科学家”的帽子来克服它们。

错误1：使用通用指标或现成指标

问题：很多人用“有帮助性”“幻觉”“连贯性”这类通用指标来衡量智能体的准确性。这些词听起来很重要，但非常模糊：你能准确说出“幻觉”到底是什么意思吗？不同领域（医疗、法律）对同一概念的定义完全不同，用同一套现成评估器去衡量没有意义。

如何纠正：像数据科学家一样探索数据。借助 Codex、Claude Code 或 Cursor 等AI辅助工具，构建自定义界面，加载智能体的追踪数据，逐条阅读每条消息和追踪记录，讨论哪里可能出错。假装你是用户，与产品经理交流，把发现的错误记下来作为开放笔记。一段时间后，将这些笔记分类成特定的故障模式。例如，在一个房地产智能体导览应用中，特定故障模式可能是“在用户没有要求时重新安排导览”或“为导览虚构时间”。核心是：查看你的数据，并规模化此过程。

错误2：盲目使用LLM评判器而不验证

问题：很多人发现一个故障模式后，直接问大模型“这个故障模式在我数据中出现的频率是多少？”，却没有对LLM评判器本身建立任何信任。他们让LLM以1-5尺度评分，然后看直方图并据此做业务决策，这很难信任。

如何纠正：把LLM评判器当作一个不完美的分类器。你需要为每个故障模式获取带标签的追踪示例，并把数据划分为训练集、开发集和测试集。找出哪个提示词或模型在训练/开发集上表现良好，并确保在测试集上没有过拟合。在LLM应用中，这个过程同样必要。同时，由于故障通常是少数类，不要只看准确率，要使用精确率、召回率、假阳性/假阴性等不平衡分类指标。

错误3：糟糕的实验设计

演讲者提到两种表现形式。

低质量合成数据生成

当你让大模型生成“给我一些数据”或“五个通用问题”时，容易产生千篇一律的追踪数据。解决方案是：系统化生成合成数据，让大模型只参与非常小的部分。假设用户带入系统的数据有哪些维度在变化（如用户角色：新手 vs 有经验），生成这些维度的组合，审查所有合成数据的质量，确保多样性。一个实用练习：进入你的应用，查看追踪记录，找出至少三个在不同用户之间变化的维度，用大模型为每个维度生成不同值，然后取所有维度的笛卡尔积来生成合成数据。

设计指标时的陷阱

人们常用1-5或1-100的评分尺度，这不太可解释或可操作。建议尽量将其简化为二元分类问题（成功/失败，通过/失败）。让评判器的范围非常窄，专注于二元任务，然后自己标注大量数据来衡量与该任务的一致性。很难第一次就写出好的LLM评判器提示词，但可以通过上述方法迭代。

错误4：标注数据时缺乏领域专业知识或忽略标准漂移

问题：很多团队让AI工程师或开发者来标注数据，除非你在构建编码应用，否则这通常是坏主意——这些人不具备领域专业知识。另外，不要相信任何标签，务必验证标注者的专业性，并亲自查看标签。

标准漂移：来自论文《谁验证验证器》（Shreya是作者之一）。人们除非看到一些数据，否则不知道他们想要什么。事先指定评分标准并不足够，需要反复查看数据，强迫人们去看数据。这是一种“推数据到眼前”的过程。

错误5：过度自动化

有些人想：“所有这些评估工作，能不能直接让Claude帮我做？”答案是否定的。Claude不知道所有可能出错的产品细微差别，也无法读懂你的心思。当然，LLM能找到明显错误或明显损坏的东西，但很多关键的、产品层面的失败需要你外化上下文才能发现。

其他常见陷阱（列表）

• 误用相似度分数（Rouge、Bleu等）——这些常出现在现成评估框架中，但衡量相似度不一定有意义。
• 问评判器“这个有帮助吗？” ——提示词太笼统，没有针对你的产品具体化。
• 让标注者阅读原始JSON数据 ——应消除查看数据的摩擦，构建自己的数据标注界面，让阅读数据变得愉快。
• 报告未校准的分数 ——必须研究LLM评判器与人类的对齐程度，否则只是胡乱猜测。
• 忽视标准漂移 ——确保始终理解标准在变化。
• 过度拟合评判器到数据 ——不要拿同一组数据反复进行爬山优化，要留出一部分数据确保泛化能力。
• 低效采样 ——确保有效采样数据。
• 仪表板上的空指标 ——指标要值得占用空间且有信号。

回归数据科学思维

今天讨论的许多问题，在数据科学中都有对应的技能可以缓解：

• 错误分析/数据分析 —— 查看数据，在追踪记录中找到模式，类似于探索性数据分析。
• 指标设计 —— 针对实际问题设计具体、可操作的指标。
• 验证 —— 像机器学习中验证模型一样，确保LLM评判器与人类判断对齐。
• 数据管理 —— 特别是测试数据的正确管理。
• 监控与可观测性 —— 保持持续观察。
• 整体性方法 —— 将评估视为一个系统，而不是孤立步骤。

Source: https://www.youtube.com/watch?v=QDQT99csHJQ&feature=youtu.be