AI产品评估:从盲目依赖工具到流程优化

AI产品评估并非依赖工具,而是持续的科学实践和流程优化。自动化评估需人工监督校准,数据驱动、迭代改进才是关键。

原文标题:姚顺雨提到的「AI下半场」,产品评估仍被误解

原文作者:机器之心

冷月清谈:

文章指出了目前AI产品评估中存在的误区,即过度依赖自动化评估工具而忽略了流程优化和人工监督的重要性。作者强调,有效的评估是一个持续的科学实践过程,包括观察数据、标注问题输出、提出假设、设计实验、测量结果和分析错误。评估驱动的开发(EDD)应该先定义成功标准,再进行功能开发,通过不断迭代评估来改进产品。自动化评估工具能够扩大监测范围,但不能取代人工监督,需要通过高质量的标注数据进行校准,并持续优化。最终,AI产品的成功依赖于科学的方法、EDD实践以及对系统输出的持续监控,而非仅仅依赖评估工具。

怜星夜思:

1、文章提到“评估驱动的开发(EDD)”,这种模式在实际应用中会遇到哪些挑战?如何克服这些挑战?
2、文章中提到“自动化评估工具(LLM-as-judge)也离不开人工监督”,那么如何设计有效的人工监督机制,以确保自动化评估的准确性和可靠性?
3、文章提到了“科学方法”在AI产品开发中的应用,你认为除了文中提到的观察、假设、实验等步骤,还有哪些科学方法可以被借鉴到AI产品的开发中?

原文内容

机器之心报道

编辑:张倩


前段时间,OpenAI 研究员姚顺雨发表了一篇主题为「AI 下半场」的博客。其中提到,「接下来,AI 的重点将从解决问题转向定义问题。在这个新时代,评估的重要性将超过训练。我们需要重新思考如何训练 AI 以及如何衡量进展,这可能需要更接近产品经理的思维方式。」(参见《》)

由于观点非常有见地,这篇博客吸引了大量从业者围观。

有意思的是,亚马逊首席应用科学家 Eugene Yan 最近也发表了一篇博客,专门介绍 AI 产品的评估,可以说是对姚顺雨博客的有力补充。

这篇博客同样得到了诸多好评。

以下是博客原文。

自动化评估救不了你的产品

你得修复你的流程

产品评估这件事,很多人根本没搞懂。总有人以为再加个工具、添个指标,或者让大语言模型当裁判(LLM-as-judge),就能解决问题拯救产品。这根本是在回避核心问题,逃避真正该做的工作。评估并非一劳永逸,也不是什么快速起效的方法 —— 它是运用科学方法的持续实践,是评估驱动开发,是 AI 输出的持续监测。

构建产品评估体系,本质上就是在践行科学方法。这才是真正的秘诀。它是一个不断提问、实验和分析的循环。

首先从观察开始,也就是「看数据」。我们要审视输入内容、AI 输出结果,以及用户与系统的交互情况。数据会告诉我们系统哪里运转良好,更重要的是,哪里会出问题。发现这些故障模式才是有效改进的起点。

接着我们标注数据,优先处理问题输出。这意味着要对成功和失败的样本进行标记,建立平衡且有代表性的数据集。理想情况下,正负样本应该五五开,并覆盖各类输入场景。这个数据集将成为针对性评估的基础,帮我们追踪已发现问题的改进情况。

然后,我们提出假设:为什么会出现这个错误?可能是 RAG 检索没返回相关上下文,也可能是模型处理复杂(有时自相矛盾)的指令时力不从心。通过分析检索文档、推理轨迹和错误输出等数据,我们能确定要优先修复的问题以及要验证的假设。

紧接着设计实验验证假设。比如重写提示词、更新检索组件或切换不同模型。好的实验要能明确验证假设是否成立,最好还设置基线对照组进行比较。

结果测量和错误分析往往是最难的环节。这不同于随意的感觉判断,必须量化实验改动是否真有效果:准确率提升了吗?缺陷减少了吗?新版本在对比测试中表现更优吗?无法量化的改进根本不算改进。

实验成功就应用更新,失败就深挖错误原因,修正假设再来一次。就在这个循环中,产品评估成了推动产品进步、减少缺陷、赢得用户信任的数据飞轮。

将科学方法应用于 AI 产品开发。

评估驱动的开发(Eval-driven development,EDD)能帮我们打造更好的 AI 产品。这类似于测试驱动的开发 —— 先写测试用例,再实现能通过测试的代码。EDD 秉持相同理念:开发 AI 功能前,先通过产品评估定义成功标准,确保从第一天就有明确目标和可衡量的指标。说个秘密:机器学习团队几十年来都在这么做,我们始终根据验证集和测试集来构建模型系统,只是说法不同而已。

在 EDD 中,评估指引开发方向。我们先评估基线(比如简单提示词)获取基准数据。之后每个提示词调整、系统更新和迭代都要评估:简化提示词提升了准确性吗?检索更新增加了相关文档召回率吗?还是反而让效果变差了?

EDD 提供即时客观的反馈,让我们看清哪些改进有效。这个「写评估 - 做改动 - 跑评估 - 整合改进」的循环确保了可衡量的进步。我们建立的不是模糊的直觉判断,而是扎根于软件工程实践的反馈闭环。

先写评估标准,再构建能通过评估的系统。

自动化评估工具(LLM-as-judge)也离不开人工监督。虽然自动化评估能扩大监测范围,但无法弥补人为疏忽。如果我们不主动审查 AI 输出和用户反馈,再多自动评估工具也救不了产品。

要评估和监测 AI 产品,通常需要采样输出并标注质量缺陷。有了足够多高质量标注数据,我们就能校准自动评估工具,使其与人类判断一致。这可能涉及测量二元标签的召回率 / 准确率,或通过两两比较决定输出之间的相关性。校准后的评估工具能有效扩展 AI 系统的持续监测能力。

但自动评估工具不能取代人工监督。我们仍需要定期采样、标注数据,分析用户反馈。理想情况下,我们应该设计能够通过用户交互获取隐式反馈的产品。不过,显式反馈虽然不那么频繁,偶尔也会有偏见,但也很有价值。

另外,自动评估工具虽扩展性强,但也不完美。不过人类标注员同样会犯错。只要持续收集更高质量的标注数据,我们就能更好地校准这些工具。保持「数据采样 - 输出标注 - 工具优化」的反馈循环,需要严格的组织纪律。

自动化评估工具本质上是人工标注与反馈流程的放大器。

虽然使用 AI 构建产品感觉很神奇,但仍然需要耗费大量精力。如果团队不应用科学的方法,实践评估驱动的开发,并监控系统的输出,那么购买或构建另一个评估工具将无法挽救产品。

原文链接:https://eugeneyan.com/writing/eval-process/

© THE END 

转载请联系本公众号获得授权

投稿或寻求报道:[email protected]

除了文中提到的,我觉得控制变量法也很重要。在AI产品开发中,影响因素很多,为了验证某个改动的影响,需要尽量控制其他变量不变。另外,可重复性原则也值得关注,实验结果应该能够被重复验证,确保不是偶然现象。还有同行评审,让其他专家参与到评估过程中,可以发现潜在的问题和偏差。

我认为“奥卡姆剃刀原则”在AI产品开发中同样适用。这个原则告诉我们,在面临多种选择时,应该选择最简单的解释。在AI模型的选择和设计上,我们应该尽量避免过度复杂化,选择那些既能满足需求,又易于理解和维护的模型。此外,“证伪主义”也很有价值,我们应该主动寻找证据来否定我们的假设,而不是一味地寻找支持证据。

与其说是“监督”,不如说是“协同”。自动化评估工具可以处理大量的重复性工作,而人工监督则可以关注那些机器难以处理的复杂场景。因此,我们需要将两者结合起来,构建一个智能化的评估体系。例如,可以让人工标注人员对自动化评估结果进行二次确认,或者让机器自动学习人工标注的模式,提升评估的准确性。这种“人机协同”的模式,可以最大限度地发挥两者的优势。

EDD的核心在于“评估先于开发”,这要求产品经理对用户需求和产品目标有非常清晰的理解。但现实中,需求往往是动态变化的,评估标准也需要随之调整,这就增加了管理的复杂性。此外,评估结果的解读也可能存在主观性,不同的团队成员可能会有不同的看法。为了应对这些挑战,建议采用更灵活的评估框架,例如OKRs,允许根据实际情况调整目标。同时,建立清晰的沟通渠道,确保所有团队成员对评估结果有统一的理解。

科学方法不仅仅是流程,更是一种思维方式。我认为批判性思维在AI产品开发中至关重要。我们需要对所有的数据、结论和方法保持怀疑,不断挑战自己的认知边界。此外,系统性思维也很重要,我们需要将AI产品看作一个复杂的系统,考虑各个组成部分之间的相互作用,避免头痛医头脚痛医脚。

EDD模式挑战还是挺多的,比如评估标准的制定,要足够精细和全面,否则容易出现偏差。再比如评估过程需要大量的标注数据,这部分成本不容小觑。而且,不同团队对“成功”的定义可能不一样,需要协调。克服的话,可以尝试分阶段评估,先快速迭代核心功能,再逐步完善细节;同时,可以利用一些半监督学习的方法,减少标注成本;最重要的还是团队内部的沟通和协作,统一目标。

人工监督机制的设计,我觉得可以从以下几个方面入手:一是建立明确的标注规范,确保人工标注的一致性;二是定期对人工标注结果进行抽查,发现问题及时纠正;三是利用统计方法,例如Kappa系数,评估人工标注的信度;四是引入专家评审,对疑难案例进行分析和判断;五是建立反馈机制,让标注人员及时了解评估结果,并根据反馈改进标注方法。

关键在于建立一个正向循环。首先,我们需要选择合适的自动化评估工具,并用人工标注的数据对其进行训练和校准。然后,定期抽样检查自动化评估的结果,如果发现偏差,就重新训练模型。同时,收集用户反馈,将这些反馈纳入到人工标注的数据中,不断完善评估体系。此外,还可以考虑引入“红队”机制,模拟恶意攻击,发现评估体系的漏洞。

从我的经验来看,EDD最大的挑战在于如何平衡评估的严谨性和开发的效率。如果评估过于繁琐,会大大拖慢开发进度,甚至导致团队失去创新热情。因此,我们需要找到一个合适的平衡点,既能保证评估的质量,又能保持开发的敏捷性。一个可行的方案是采用“最小可行评估”原则,只关注那些对产品成功至关重要的指标,避免过度评估。