一个反复出现的矛盾几乎每个做AI产品的团队都会在某个阶段说出这句话“我们的产品很难做eval。”这句话通常出现在产品已经上线、开始被质疑质量的时候。团队花了几周甚至几个月试图搭建一套自动评测系统发现标注成本高、评分标准模糊、人工判断一致性差。最终得出结论这个场景天然就很难评测。原文配图Hamel Husain在最近一篇长文中给出了一个尖锐的判断难以评测本身就是一种产品异味product smell。你很难验证的东西用户往往也很难验证。最糟的情况是用户必须从头重做一遍工作才能确认AI的输出是否正确。这个判断的价值在于它把评测困难从工程基础设施不足重新定义为产品设计有缺陷。在构建评测流水线之前更应该做的事是让产品本身就面向可验证性设计。一个数字就是全部输出数据Agent的典型反模式Hamel在文章中举的第一个例子非常普遍——内部AI数据Agent。用户用自然语言提问比如Product A上个季度的净收入是多少Agent去找数据源、写查询、返回答案。许多团队把这个产品做成了最简形态用户提问Agent回答一个数字。比如$4.21M。问题显而易见用户拿到这个数字后除了重新做一遍分析没有任何手段验证它的正确性。这意味着Agent本应节省的人力在验证环节又被消耗掉了。Hamel引用了一条来自Lenny Rachitsky的观察某数据科学团队现在的主要工作变成了审核PM和工程师从AI那里拿到的半成品分析——其中一半是错的。这就是难以eval的根源。不是评测技术不行是产品输出本身就没有提供足够的可验证信号。面向验证的设计一个数据Agent应该长什么样Hamel基于自己作为数据科学家的实际验证习惯列出了专家验证一个数字时会做的几件事与可信来源交叉对比。比如一个经过审核的dashboard、一份同事做过的分析报告。如果Agent能告诉用户它参考了哪份已有分析信任成本立刻降低。确认指标的精确定义。净收入这个词在不同语境下含义不同——是否扣除退货是否扣除折扣如果Agent使用的定义来自公司治理层governed metrics layer就应该明确展示。用关联指标做合理性检查。如果没法直接验证净收入拉一个应该与之同向变动的量——比如销售数量或独立客户数——看组合是否合理。打开聚合数看下层分布。一个总数可能掩盖问题。按区域、按时间段拆开检查分布是否异常。看查询本身。对于重要数字直接读SQL确认它做的是你以为它做的事。标记无法验证的部分。如果某个步骤没有可信来源可以交叉验证就应该标记出来而不是把它当作已确认的事实呈现。基于这些原则Hamel给出了重新设计后的产品草图。核心变化有几层渐进式信息披露。聊天界面仍然给出简洁回答但附带关键上下文——数据来源、使用的指标定义、发现的异常。用户可以选择打开完整的交互式notebook查看全部分析过程。可追溯的分析链。Agent生成的notebook按验证逻辑组织先展示假设和定义来源然后是查询和结果接着按维度拆解做合理性检查最后列出无法验证的项目。每个无法验证的项目被保留为可运行的代码单元用户可以自己探查。来源透明。如果Agent检索了已有的经过审核的分析界面会显示是哪一份、谁写的、什么时候写的。知识飞轮。用户可以把Agent生成的notebook发布回知识库供未来的分析检索使用。这形成了一个正向循环——Agent越用越有可信来源可以引用。Hamel特别提到Hex这个产品认为它在notebook和chat的融合上做得最好。Hex的AI负责人Bryan Bischof本身就是数据科学家——也就是产品的目标用户。Hamel认为这是它设计合理的一个重要原因。第二个例子体育课程计划生成器Hamel辅导的另一个产品是面向K-12体育老师的AI课程计划工具。老师输入约束条件——年级、课时长度、室内还是室外、有什么器材——工具生成一份课程计划。这类产品的评测难点在于课程计划是一大段结构化文本标注者需要完整阅读才能判断质量标注成本高一致性差。Hamel的方案同样是从产品设计入手。与其让AI生成一整份课程计划让用户从头审阅不如把输出拆解为可独立验证的模块。比如热身环节是否符合年级体能水平、主活动是否使用了指定器材、总时长是否匹配课时、活动之间的过渡是否合理。当产品把输出结构化为可逐项核查的模块时两件事同时发生用户的验证成本降低了评测的设计也变得自然——你可以针对每个模块设计独立的评测维度而不是对着一整份计划给一个模糊的1-5分。背后的通用模式原文配图从这些例子中可以提取出一个清晰的设计原则产品输出的结构应该匹配领域专家的验证流程。具体来说有几个层次第一层让用户能看到中间过程。不要只给最终答案。数据Agent应该展示查询和数据来源代码生成工具应该展示修改的具体位置和原因内容生成工具应该展示使用的参考素材。第二层按可验证单元组织输出。把一个大的输出拆成多个可以独立判断对错的小单元。每个单元应该尽可能有可比对的参考。第三层主动标记不确定性。哪些部分有可信来源支撑哪些没有应该在界面上明确区分。把无法验证的部分标记出来比假装一切已确认要好得多。第四层提供交互式验证工具。给用户修改、调整、重新运行的能力而不只是展示一个静态结果。这个设计原则的底层逻辑其实来自认知科学。Hamel引用了一篇关于sensemaking成本结构的经典论文——人验证信息的成本主要由信息的呈现方式决定。同样的信息组织方式不同验证成本可以相差数量级。对评测工程的直接影响回到eval本身。当产品面向可验证性设计之后评测会发生几个变化标注成本下降。标注者不需要从头重做工作来判断输出质量。他们可以针对每个可验证单元快速判断甚至可以借助产品本身提供的验证工具。评测信号更丰富。你不再只能给整体输出一个分数而是可以获得细粒度的维度评分。哪一步出了问题、哪个假设不成立可以精确定位。自动评测变得可行。当输出是结构化的、有明确的中间步骤和引用来源时自动化检查比如SQL是否使用了正确的表、指标定义是否匹配治理层变得有据可依。用户反馈质量提高。用户的负面反馈不再是模糊的答案不对而是第三步的区域拆分显示International的数据缺失这样的精确信号。这种反馈可以直接用于改进系统。换句话说产品设计和评测不是两件独立的事。好的产品设计让评测变得自然而不是需要额外搭建一套复杂的评测基础设施来弥补。工程启发在产品设计阶段就引入可验证性思考。不要等到需要做eval了才发现输出无法评测。在定义产品输出格式时就应该问领域专家会怎么验证这个输出需要哪些辅助信息让领域专家参与产品设计。Hamel反复强调的一个观点是产品的AI部分应该模拟领域专家的工作流程而不是替代它。Hex的AI负责人本身就是数据科学家这不是巧合。如果你的产品服务于律师、教师或分析师设计团队里应该有人真正做过这个工作。不确定性是特性不是缺陷。许多AI产品试图隐藏不确定性表现得好像每个输出都是确定的。这实际上增加了用户的验证成本——他们不知道该重点检查哪里。主动标记这部分我无法验证反而建立信任。考虑知识复用机制。Hamel提到的知识飞轮概念值得注意。用户验证并确认的输出如果能被系统保存并在未来引用Agent的可信度会随使用量增长而提升。这类似Airbnb内部的Knowledge Repo——数据科学家发布经过验证的分析notebook供其他人检索和引用。评测策略应该从产品输出结构自然推导。如果你发现评测维度设计困难、标注指南写不清楚先回头看产品输出是否足够结构化。评测困难往往是产品输出过于模糊的信号。边界在哪里这个框架不是万能的。有几个限制需要注意。有些任务的验证本身就需要专业判断。比如创意写作、视觉设计或复杂的医学诊断。即使做了结构化拆解每个子单元的判断仍可能需要深度专业知识。产品设计可以降低验证成本但不能消除专业门槛。过度结构化可能伤害用户体验。把所有中间过程都暴露给用户可能带来信息过载。渐进式披露很重要——默认展示关键信息详细过程在需要时才展开。这个平衡点因用户群体而异。面向验证的设计有工程成本。让Agent不仅生成答案还要组织分析过程、检索可信来源、标记不确定性这比只生成一个答案复杂得多。需要权衡这个投入是否值得——对高风险决策场景通常值得对低风险的日常查询可能过度。可验证性不等于正确性。即使产品设计得容易验证如果用户不具备领域知识或没有动力去验证错误仍然会被接受。产品设计解决的是验证成本问题不是验证意愿问题。重新理解评测的位置Hamel这篇文章真正有价值的地方不在于它提供了某个具体的评测方法论而在于它重新定义了评测在产品开发中的位置。传统思路是先做产品再做评测。评测是一个独立的工程模块负责在产品上线后持续监测质量。Hamel提出的思路是产品设计本身就应该包含可验证性。当产品为验证而设计时评测不是一个需要额外搭建的系统而是产品结构的自然延伸。评测信号从产品的结构化输出中自然流出而不是从外部强行注入。更进一步说如果你的AI产品输出了一个东西用户无法高效判断它是否正确那这个产品在商业上也是脆弱的。因为用户要么盲目信任然后在某次错误后彻底失去信任要么花大量时间验证然后质疑这个工具到底节省了什么。难以评测不是你的技术债是你的产品在告诉你用户也很难用。