AI评估:产品团队的实战指南

AI评估一直是“它”技能的所在产品团队已经超过一年了。我甚至把评估称为新发现习惯.

但我仍然遇到的产品团队,他们对评估的概念很模糊。这不是他们的错。关于这个话题的大部分写作都是写给工程师的,或者内容不够具体。

我今天的目标是解释什么是评估,以及为什么产品团队可以且应该创建评估。我会让这个过程实用、动手操作且易于理解。

AI评估(评估的缩写)是衡量AI产品或工作流程表现良好的方法。评估让团队有信心他们的AI应用正在达到预期效果。它们帮助团队保持质量,并在问题触及用户之前及时发现。

类似于其他发现习惯,比如面试以及假设测试,评估可以作为反馈环确保我们走在正确的道路上。

为什么产品团队需要学会构建评估

如果你用AI来写PRD,就综合你从中学到的东西客户反馈或客户访谈,分析行为分析理解会议记录,或者其他任何事情与日常工作相关你可以从评估中受益。

如果你想知道你的AI生成PRD是否包含你要求的所有内容,评估可以帮你衡量。如果你想知道AI使用的客户报价是否是伪造的,评估可以告诉你。

如果你想确保数据分析从正确的问题开始,且在复杂计算中没有偏离,评估可以监控这一点。

当我使用ChatGPT帮助我写出所有可爱我为这篇博客文章我想知道如何相信AI能准确讲述每个参与者的故事。我通过加入一些评估来建立对总结的信心——一个事实核查员和幻觉警卫。

我稍后会给你讲讲两者的运作方式。

如果你正在构建面向客户的人工智能产品或服务,并且曾问自己:“我如何知道这在所有客户和所有目标用例中是否始终有效?”你可以从评估中受益。

我遇到过这种情况我人生中的第一个人工智能产品.我用我的初创面试教练结果看起来相当不错。但我开始思考,“我怎么知道这是否足够好,可以推广给所有学生?”

了解我们的AI产品和工作流程是否好用,唯一的方法是通过评估。

评估帮助我们定义和衡量什么是美好

AI Evals: A Hands-On Guide for Product Teams

传统软件是我们编写需求文档,工程师实施,并使用自动化测试确保符合验收标准。当它达到预期时,我们就知道它按预期工作。

但当涉及大型语言模型时,判断软件是否能正常工作就更难了。这有两个原因。首先,对于相同的输入,大型语言模型可能会给出不同的答案。

其次,我们倾向于给出LLMs。语义任务这可能有不止一个正确答案——甚至更好或更差的答案。

前者使得使用我们传统的测试方法变得困难。而传统软件的工作是预先确定的。我们可以查看代码,准确知道每次会得到什么。而大型语言模型则没那么简单。

大型语言模型是概率性.这意味着即使输入相同,它们的输出也可能有所不同。

代码总是给出相同的答案,LLMs不会

AI Evals: A Hands-On Guide for Product Teams

这里有个简单的思考方式:如果我写一个函数,取两个数字返回和,我可以写成单元测试适用于各种情况。如果PRD要求它能支持整数(整数)、浮点数(小数)、负数以及整数和浮点数的混合,那么我可以编写涵盖所有这些情况的单元测试。

  • 为了测试函数是否能很好地处理整数,我可以写一个测试,调用带有2和3的函数,并检查是否正确返回5。
  • 为了测试函数是否能处理浮点,我可以发送3.2和4.1,并确认返回7.3。
  • 要测试负数,我可以发送-1和-3,然后检查是否返回-4。
  • 为了测试整数和浮点数的混合,我可以发送2和3.1,并检查是否返回5.1。

我可以写一次测试,每次修改代码时都运行。如果所有测试都通过,我就能放心代码按预期运行。

但如果我创建一个LLM服务来做同样的事情,这个策略就行不通。第一次发送2和3时,可能返回5。但第二次可能返回4。测试一次是不够的。

可能一次有效,下一次又出问题。

评估让我们能够衡量LLM返回正确答案的频率。这与单元测试不同。单元测试中,我们期望它始终正确。而评估则是衡量它正确频率。

语义输出的独特挑战

AI Evals: A Hands-On Guide for Product Teams

在我们衡量LLM得到正确答案的频率之前,我们需要先定义什么是正确答案。

当我们谈论简单加法时,定义正确答案很容易。2 + 3 = 5 是正确的。2 + 3 = 4 则不正确。

但我们往往会依赖LLM来处理语义任务——这正是它们的优势所在。而且语义任务往往更难判断。我们很少能断然断言这是对的,那是错的。

相反,我们可能会说这更好,那个更差。有很多灰色地带。

如果你请一个大型语言模型写一个笑话,你如何判断这个回答是对还是错?你的主要标准可能是,“它让你笑了吗?”但你也可能会问,“它聪明吗?”或者,“这适合我的孩子吗?”

在评估回答之前,你必须先定义什么是正确答案。而且,正确答案往往没有明确的界限。一个笑话可能比另一个笑话更好笑。另一个可能更聪明。

诸如此类。

你会看到,评估的任务之一是理清正确答案的样子,即使直觉觉得答案模糊。

当我让ChatGPT帮我总结《可爱的》采访中的真实故事时,我对正确性的定义如下:

  • 故事跟随参与者的叙述展开。
  • 所有关键时刻都被收录。
  • 没有任何报价是捏造或不准确的。

对于我的面试教练,我还定义了多维度的正确性:

  • 经纪人有没有把每个面试问题都归类到正确的反馈区?
  • 它是否避免提出引导性问题或笼统性问题?
  • 每个辅导建议是否适合面试官的要求?
  • 它对每个属性的评分都正确吗?
  • 特工的语气合适吗?

每一个,我都必须花时间定义什么是好,然后想办法测量它。我们稍后会详细讲解如何做到这一点。

不要把什么样的好外包给别人

AI Evals: A Hands-On Guide for Product Teams

但首先,我想强调的是,我们通常不能把这项工作外包。一些重要的评估工具服务商提供内置的评估工具,帮助你入门。例如,他们可能会根据你的经纪人简洁或帮助性进行评估。

他们为每种情况都制定了自己的正确定义。

但很容易看出,为什么一个定义并不适用于所有环境。如果我是想学习天体物理的学生,可能需要冗长且详细的回答来教学。但如果我是天体物理教授,问类似问题,我不需要所有的教学细节。

正确性取决于上下文。不要让供应商为你的产品定义正确性。这是产品团队的工作。

那么,我们如何定义对错答案呢?

第一步:看看LLM在做什么

当我们在聊天界面我们不断评估模型。我们提出请求,得到回应,然后根据该回应是否满足我们的需求进行修正。

但当我们构建工作流程或产品时,目标是让LLM在我们不注意时做出正确的选择。要达到这一步,我们必须观察一系列输入,然后评估LLM对这些输入的响应。

这个过程通常被称为误差分析——我们手动评估LLM犯了哪些类型的错误。

我们做多少错误分析取决于LLM每次输出正确的重要性。对于个人工作流程,错误反应只影响我们自己,我们可能会做一些轻量级错误分析。

但对于生产产品,错误反应影响真实客户,我们应该做更多错误分析。

个人工作流程的错误分析

AI Evals: A Hands-On Guide for Product Teams

写作的时候我可爱的博客文章我有17份文字稿,想转换成小品。我本可以逐条写。但我写了一个提示,指导ChatGPT如何写每一个。我的提示包括每个故事的结构、语气和写作风格,以及期望的长度。

提示准备好后,我把第一份文字稿交给了ChatGPT,让它写故事。但我不仅仅信任输出。我花时间阅读了完整的文字稿。我进行了采访,但我想提醒自己刚才说了什么。

然后我确定了我会包含在故事中的关键时刻,并与ChatGPT的内容进行核对。我逐句检查,确保它们是逐字逐字的。这花了不少时间。

但它也让我看到了ChatGPT犯了哪些类型的错误。我注意到两个明显的错误:

  1. 它会在一些具体细节上出错——比如幻觉对方的职位,或者编造一些没有出现在成绩单里的产品细节。
  2. 它会产生幻觉引用。它会将参与者说的两句不同的陈述合并成一个不在文字记录中的新含义。

这足以让我意识到我需要两个评估:一个事实核查员和一个幻觉警卫。

这个过程慢吗?是的。但从长远来看,这帮我节省了时间吗?是的。我本可以自己手动审查全部17个故事。但我只深入审查了一个故事,识别出LLM犯的错误类型,然后用这些错误来确定需要哪些评估。

接下来的16份转录,我运行了评估以发现LLM的错误。评估让我能够信任输出。我们将在下一节中介绍我如何定义这些评估。

如果我要把这份工作做成制作产品,我可能会想看多份成绩单。但就我个人工作流程来说,这已经足够了。

面向客户的产品错误分析

AI Evals: A Hands-On Guide for Product Teams

对于我的面试教练我最初是用自己客户的访谈记录来测试的。教练做得很好。但我的采访记录格式和风格完全符合教练的预期。

要真正考验教练,我需要在学生采访中测试。我决定放手我的面试教练测试版给我2025年4月的同学,尽管我不确定它是否准备好了。我需要痕迹评估。

痕迹是对人工智能交互.其中包括用户输入,系统提示,工具调用、中间步骤和最终阶段LLM的回应.在多回合对话中,通常包括用户与LLM之间的所有来回交流。

对于面试教练来说,追踪是系统提示、面试文字记录以及面试教练对该文字记录的反馈。

为了减少在准备前就把东西展示给学生的风险,我告诉学生教练并不完美,但我会审核所有回复。如果出错,我会发邮件告知他们。

我通过审核每份提交来进行错误分析。每当面试教练犯错时,我都会记录下来。然后我将这些错误分类,这些错误成为我评估的候选对象。

因为这是一个生产产品,我看了数百个案例。我想深入了解在广泛的客户输入中发生的错误。即使我的面试教练已经上线一年多,我仍然在做这些评审。

在做错误分析时,可能会想一次性修复所有问题。但我建议把这些问题分成几个阶段。先做注释,分类错误,然后决定哪些值得处理。否则,你可能会在发现更明显的错误之前,就花时间去修正不那么重要的错误。

如果你在做面向客户的产品,就用你的发现习惯找出哪些错误对客户最重要。这些错误需要评估。

现在轮到你了

花点时间把你学到的东西付诸实践。选择个人工作流程你在日常工作中使用的这些。你如何判断正确性?你在回答中发现了哪些错误?

使用工作流程时,不要轻描淡写地忽略LLM的错误。相反,要记录它们。尽量识别最常见的类别。有些类别比其他的更重要。考虑哪些错误你可以接受,哪些是你希望消失的。

对于那些你希望消失的病房,这些都是很好的评估候选人。

步骤2:确定统计错误发生频率的最佳方法

既然我们已经确定了最关心的错误,接下来是定义一些评估的时候了。记住,评估是公制.它帮助我们统计特定错误在LLM输出中出现的频率。

评估有四种常见类型。

  1. 黄金数据集- 一组用于测试LLM的已知输入
  2. 代码断言- 帮助我们评估质量的程序化规则
  3. 法学博士作为评审- 第二个模型判断输出
  4. 客户反馈- 客户告诉我们反应是否足够好

黄金数据集评估是一个常见的起点(但数量有限)

AI Evals: A Hands-On Guide for Product Teams

当团队刚接触评估时,通常会从黄金数据集评估开始。要创建数据集评估时,你只需定义一组输入,期望它们代表你在生产中可能看到的内容,然后定义理想输出.理想输出就是你对正确性的定义。

当你听到产品经理谈论评估时,比如在电子表格中工作,他们通常指的是黄金数据集评估。

它们可以成为帮助你的好方式制定评分标准关于“好”的样子。错误分析帮助我们通过识别错误来了解“坏”是什么样子。如果我们修正这些错误并将其添加到我们的黄金数据集中,就能开始整理“好”的样子。

但它们只适用于可以定义一个正确输出的任务。如果有很多正确输出,那么很难定义所有正确度的变体。同样,如果输入和输出相当大(比如采访记录和机会解树那么创建黄金数据集评估根本不可行。

一般来说,当输入和输出都很小且只有一个正确答案时,黄金数据集评估是好的。它们适合分类任务(例如,这是业务成果或者产品成果?)、事实性答案(例如谁是第一任美国总统?)、路由任务(例如哪种技能最适用?)等等。

它们通常不太适合测量复杂输出或处理复杂输入。

但你通常可以把复杂任务拆分成更小的任务,然后用金色数据集的评估来衡量这些小任务的性能。

例如,在我的AI生成机会解决方案树服务,代理人必须决定是否相似但措辞不同机会(来自不同来源的机会)实际上是同一个一般机会。

我可以通过定义一组面试机会作为输入,并将理想输出定义为判断它们是否足够相似以进行泛化,来创建一个黄金数据集评估来测试这种能力。

创建黄金数据集评估时需要牢记两个挑战:1. 在发布前很难知道你的生产投入会是什么样子;2. 这非常繁琐。这不是一次性的活动。你必须不断改进你的黄金数据集,确保它持续符合你的预期。

我用黄金数据集的评估来针对输入和输出简单的目标步骤,我有信心能策划出代表生产环境中的黄金数据集。

代码断言通常既便宜又快速

AI Evals: A Hands-On Guide for Product Teams

代码断言(也称为基于代码的断言)是一种AI评估,利用传统的确定性代码来评估LLM响应的质量。与单元测试类似,它们几乎免费,代码每次都能按预期工作。

好的代码断言评估的关键是,你必须找到一种固定的结构性方法来测量误差,这种方法不需要判断。

例如,我在《可爱故事》博客文章中对幻觉守卫的评估是代码断言。对于ChatGPT故事中出现的每一句话,我都会搜索原始文字记录中的准确字符串。

如果匹配,代码返回为真;如果匹配,则返回为假。

其中我的面试教练我列出了一份红旗词汇列表,表示存在一个通用问题。这次评估只是用字符串搜索这些词,如果找到了就返回为真,没有找到则返回为假。

对于我的AI生成的机会树服务我有一个代码断言评估,用于计数树上的节点并评估它们的分布情况。然后我设置了指定的阈值来定义不同的错误类别。

每当我需要评估时,我总会尝试用确定性代码来测量它。这既快又便宜。只有当评估真正需要判断时,我才会用LLM作为评判的评估。

LLM作为评判的评估衡量语义特性(但可能成本高昂)

AI Evals: A Hands-On Guide for Product Teams

作为评判的LLM评估是你使用第二个LLM来评估第一个LLM的产出。你不再仅依赖人类判断或基于代码的检查,而是将LLM的输出连同评估标准发送给另一个LLM,并要求它根据具体维度对其进行评分或判断质量。

当我第一次听说LLM作为法官时,我立刻想象的是站在上,向无尽延伸。如果我不能信任第一个LLM,那我怎么能信任第二个LLM?事实证明,确实有方法让这一切成立。

要让法官级法学硕士(LLM)发挥良好作用,我们必须:

  • 给法官一个比我们给原模型的任务简单得多。
  • 定义我们的标准,使评委能够给出二元回答:是/假,是/否。
  • 让我们的法官保持一致用我们自己的判断。
  • 请理解我们的法官总会犯错,并在报告评估时考虑这些错误错误率.

今天的文章不会涵盖所有这些步骤。但我很快会更深入地探讨LLM作为法官的评估。

对于我的可爱故事博客文章我用了 LLM 作为法官来核查 ChatGPT 生成的故事中的每个说法。法官收到了一个事实和一份文字记录,被告知如果事实有文字记录,则应回答为“true”,否则为假。

我的面试教练拥有多项法学博士评审(LLM as-a-Judge)评级:

  • 我的双重题评审会接面试官问的问题,判断问题是否同时问多个内容。
  • 我的引导性问题评估也会有一个问题,但评判标准不同。它评估问题是否假设了参与者的某些情况,或者是否表明了偏好的答案。
  • 我已经回答过的评估会得到教练建议的问题和成绩单,然后评估该问题是否已经在成绩单中回答。

当我们需要评估语义质量时,LLM作为评判者可以非常有帮助。但它们成本高昂,而且要做到准确需要付出努力。

客户反馈评估才是最终的评判(但很难让它变得可行)

AI Evals: A Hands-On Guide for Product Teams

我最喜欢评估AI产品的方法是让客户评价回应.对于面向客户的产品,这是终极评估。

然而,要让客户给出超过一个赞或否定或简单的评分,往往很难。所以我们经常需要推断出问题所在。但评分并不是我们唯一的选择。

我们也可以使用客户行为作为反馈的代理。例如,如果客户用AI生成一张图片,然后重新生成,这就是反馈,说明第一张图片对他们来说不适用。

如果他们做了提示变更在重新生成图像之前,这些更改可能会涉及出错的细节。

我正在自己的AI产品中尝试这类评估。如果你问TeresaBot一个问题然后你又提出了另一个相关问题,那就是反馈说TeresaBot第一次没有完全回答你的问题。

其中Vistaly我们计划对AI生成的编辑使用。采访快照以及机会解树作为对LLM错误之处的反馈。

这个类别是无穷无尽的,我很高兴看到随着更多团队开始设计评估,这一类别会有更多创新。

如何选择你需要哪种类型的评估

AI Evals: A Hands-On Guide for Product Teams

我从以下方法开始取得了很大成功最简单且最愚蠢的测量方式然后当它突然成功时,我感到惊喜。

我尽量尽可能使用代码断言。那只是因为它们快速且便宜。我用黄金数据集来分离和评估复杂流程中的小任务。只有在需要判断错误时,我才用LLM作为裁判。

它们成本高(即使使用小模型)。我总是尽可能多地从真实客户那里获取见解。

你甚至可以混合搭配方法。例如,我最近用代码断言和大语言模型作为裁判来测量同一个错误的两种不同方式。我试图了解机会解树代理缺失子组的频率。

我用代码断言计算每个父节点下有多少子节点。我用大型语言模型作为判断者来评估是否有语义组缺失。代码断言既便宜又快速;我可以在每个节点上运行。

如果某个节点子节点太多,我就可以对我的LLM作为判断者运行。这种组合让我降低了作为法官的LLM成本,因为它不需要查看每个节点。

错误 评估类型 原因
故事中的一句名言实际上并没有被说出口 代码断言 引用要么原文出现在文字记录中,要么不出现。无需评判。
报道中的主张在文字记录中没有依据 法学博士作为评审 模型可以用完全不同的词来创造一个主张,所以没有字符串需要搜索。
教练提出了一个通用问题 代码断言 一份简短的红旗词(“通常”、“通常”)能可靠地捕捉到这些问题。
教练提出了一个引导性问题 法学博士作为评审 需要判断问题是否假设有答案——没有固定的措辞需要寻找。
两个措辞不同的机会实际上是同一个机会 黄金数据集评估 输入小,输出小,一个正确答案。很容易标记集合并重复使用。
树枝缺少一个子分组 代码断言与法官的LLM 计算子节点足够便宜,可以在每个节点上运行。只有失败的节点才会被送交给法官。

现在轮到你了

从你的错误开始,问自己:“我怎样才能最好地统计这种情况发生的频率?”让错误的性质帮助你选择正确的评估策略。

尝试多种方法来计数同一个错误。发挥创意。在使用LLM作为裁判之前,能否用代码断言来筛选?有没有代码可以识别的结构或形状?

如果需要判决,你能给法官布置的最简单评估任务是什么?你可能需要使用不止一位法官,而不是只给一个法官做复杂的任务。

步骤3:利用你的评估来改进产品或工作流程

一旦你确定了每一次错误的计数方法,你就可以了实验为了提升你的产品。

设计输入以便收集基线

AI Evals: A Hands-On Guide for Product Teams

在做任何更改之前,一定要先获得一份基线通过将你的评估数据与一组预设输入进行对比。

如果你使用黄金数据集评估,数据集已经定义了输入和输出。如果你使用代码断言或大语言模型作为评判,则需要只定义输入。把这些输入看作一个测试。

每次你对提示词做修改时,针对配器模式、模型变更,或者其他任何东西,你都会把这些输入到产品或工作流程中,然后用你的评估来评分效果。

你的基线是你产品或工作流程当前工作的得分。你将比较你的实验变体以你的基线为基础。如果实验变体得分更高,你可以确信这是改进。

如果你在为个人工作流程设计输入,可能只识别出代表你典型使用的少量输入。但如果你在做生产产品,你会尽力确保它们代表你可能期望的真实客户输入类型。

这听起来简单,但实际上相当具有挑战性。我不断改进我的输入集,同时学习真实客户的工作。

把输入到你的产品或工作流程中

AI Evals: A Hands-On Guide for Product Teams

要获得基线,你需要一种方法让每个输入都通过你的产品或工作流程运行。

对于只有少量输入的个人工作流程,你可以手动运行。一定要把LLM的回答记录在电子表格里。你会需要它们来做评估。

或者你可以让你喜欢的模特写一个蟒蛇脚本会接收每个输入,通过你的工作流程运行,然后将输出保存到文本文件中。

对于面向客户的产品,我强烈建议自动化这一步。每次做更改(例如模型变更、提示变更、编排变更)时,你都会通过产品运行输入。我会分享更多我如何构建一个简单的流程测试线束下一节将自动化整个流程。

对输出进行评估

AI Evals: A Hands-On Guide for Product Teams

现在你收集了一组输出,你需要对这些输出进行所有评估。这样你就能知道每个错误类别的基线率。

如果你主要使用黄金数据集评估,那么你只是将LLM的实际输出与数据集中定义的理想输出进行比较,并评分LLM正确判定的频率。

对于代码断言和作为法官的LLM,你需要一种方法让输出通过代码或通过其他代码运行LLM 调用.对于LLM作为法官,有时可以作为子代理运行法典,克劳德密码,或者联合工作.

例如,对于我的可爱故事博客文章我问道克洛德在Claude Code中使用子代理和LLM作为法官提示来核查每个说法。我还让Claude写一个Python脚本,提取ChatGPT故事中的引用并在文字记录中搜索。

我拿到的每份成绩单分数如下:

  • 17个事实中有15个基于文字记录
  • 记录中4句引用中有3条被逐字验证

输出会准确告诉我哪些事实和引用未出现在文字记录中,我能手动修正。

面向客户的产品,我构建了一个简单的测试线束自动化整个过程。这是一个 Python 脚本:

  • 调用我的LLM服务,记录每个输入的输出
  • 将LLM的响应转化为每个评估的预期输入
  • 每次评估都与响应进行对比
  • 对完整运行进行评分(例如,LLM服务获得正确答案的频率是多少?)

需要帮助设置测试安全带吗?支持会员和CDH会员可以点击这里下载我的测试背带副本.

输出是每个误差类别的评分。对于我的面试教练,输出如下:

  • 引导性问题:105个建议问题中的15个
  • 一般问题:105个建议问题中的3个
  • 已回答:105个建议问题中有9个

收集完基线后,就可以进行你的第一个实验了。

设计并运行实验变体

AI Evals: A Hands-On Guide for Product Teams

既然你已经准确衡量了产品或工作流程中不同错误出现的频率,是时候尝试提高这些错误率了。

从一个错误开始。你如何减少它?以下是我们可以做的一些事情让模型性能提升:

  • 更换提示词。
  • 补充背景。
  • 换个模型。
  • 将一个复杂的LLM调用拆分成一系列更简单的LLM调用。
  • 做更高级的编排改动,比如添加代理工具调用或审计循环。

一个实验变体可以包含多个变化,但我喜欢根据理论或假说而不是尝试各种不同的方法。

重要提示:在你更改任何东西之前,先制定一个记录变更的系统。并非所有实验都有效,实验失败时你需要回滚修改。

对于个人工作流程实验,我会用我的流程笔记技能记录我的实验。你可以点击这里了解这项技能.

对于面向客户的产品,我会用一个yaml文件(纯文本配置文件)记录每个实验变体,里面包含实验ID、变化描述、提交sha(git为提交分配的唯一标识符),用来记录代码和实验提示,以及需要运行的评估来评估实验。

我的每个评估都设计成一个模块我的测试背带可以直接运行。模块的运行函数将LLM的输出转换为必要的评估输入,然后运行代码断言或调用LLM作为评判者。

我的测试线束不需要理解每个模块的工作原理。它只需要知道调用模块的运行函数。

例如,我的一般问题评估我的面试教练需要一份教练建议的问题清单。该评估的模块包含代码,将原始LLM输出解析出教练提出的所有问题,然后用代码断言代码处理每个问题。

一旦你完成并记录了变体的更改,就可以开始实验了:

  • 把你的输入到新版本里。
  • 对输出进行评估。
  • 比较一下结果。

在比较结果时,务必查看所有评估的变化。例如,一次提示性变更可能提升某一类别的错误率,但会使其他类别变差。我们的目标是让产品或工作流程在各方面都更好。

如果你的第一次尝试失败,也不要灰心。通常需要多次实验才能找到改进。在我的下一篇文章中,我将分享一个故事:经过16个变体才解决了一个客户投诉。

现在轮到你了

AI Evals: A Hands-On Guide for Product Teams

让我们把这部分应用到实践中:

  • 首先定义你的输入。如果你在做个人工作流程,这可以和你最常见的用例一样简单。如果是面向客户的产品,尽量做得全面。如果是手动运行,可以把它们收集到电子表格里,如果要自动化,可以做成markdown文件。
  • 决定你将如何产生产出。在个人工作流程中,我喜欢使用Claude Code子代理。我只需给Claude我的提示词和我定义输入的markdown文件,然后让它每次输入调用一个子代理。我确保提示词指示子代理写一个结果文件。对于面向客户的产品,我用我的测试背带.
  • 决定你将如何进行评估。同样,对于个人工作流程,我喜欢用Claude Code子代理和Python脚本来完成大部分工作。而对于面向客户的产品,我把这些都集成进了我的测试背带.
  • 收集你的基线。把你的输入到你当前的工作流程或产品里。把你的评估数据和输出对比。
  • 设计并运行你的第一个实验.把输入到变体里,然后把你的评估结果和新输出对比。
  • 比较一下结果。如果他们做不到,不要灰心。你总可以再做一次实验。
  • 反复练习直到得到理想的效果结果.听起来很像持续发现,不是吗?

为什么评估成为一种新的发现习惯

AI Evals: A Hands-On Guide for Product Teams

在持续探索习惯我列出了几个帮助我们更好地决定建造的习惯。我包括了以下习惯明确的结局,客户访谈,故事映射, 和假设测试.每一个习惯都为我们做出决策提供了一个清晰的反馈循环,帮助我们决定建造什么。

当我们定义明确的结果和衡量影响根据这些结果,我们会获得反馈,判断我们是否正在构建正确的产品。当我们采访客户并了解他们未被满足的需求,痛点和愿望,我们会得到有关我们是否正在解决正确的客户问题的反馈。 当我们绘制故事地图时 解决方案 并测试 假设 我们的想法取决于我们的解决方案是否能满足这些要求 客户需求.

当我们对客户跟踪进行错误分析、设计评估并进行实验以减少错误时,我们会得到有关更改是否有效的反馈。 如果我们的错误分析是根据我们从其他发现习惯中学到的知识来进行的,那么我们就可以建立信心,相信我们的人工智能产品将为我们的客户提供更好的服务。

我希望本指南可以帮助您开始养成这种新的发现习惯。 在您完成此过程时,如果遇到任何疑问或问题,请在评论中分享。 如果我收到足够多的问题,我将为会员举办专门的“有问必答”会议。

音频版

音频版本仅适用于付费订阅者。

添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论