AI产品经理必会:让AI产品从“能用”到“好用”的评估方法论

多客科技

作者：微信文章
对于每个正在从事AI产品开发的产品经理而言，如何评估一个不稳定的概率输出产品，成了今天每个AI产品经理都需要掌握的知识。

以下，翻译了Lennys Newsletter 04-08期的帖子，阿曼·汗（Aman Khan）详细介绍AI产品评估的方法和流程。

阿曼·汗是Arize AI产品总监，并且曾是Spotify，Cruise，Zipline和Apple的产品负责人，并和Andrew Ng一起开发了 AI产品的评估课程。

全文5K字，烦请收藏+点赞，再慢慢阅读吧。


在多年构建 AI 产品的过程中，我注意到一个令人惊讶的现象：每个 AI 产品经理都痴迷于设计更好的提示词、采用最新的 LLM，却几乎无人掌握每个卓越 AI 产品背后的隐形杠杆——评估体系。

评估是唯一能拆解AI系统每个环节、精准衡量单项改动对产品影响的方法，从而为你的产品迭代提供数据支撑和决策信心。提示词或许能够引人瞩目，但评估体系才是默默决定着产品生死关键。

事实上，我认为撰写优质AI产品评估方案的能力不仅重要——而且正在成为 2025 年及未来每一个 AI 产品经理的必备技能。


如果你不积极锻炼这种技能，很可能就会错失打造具有影响力的 AI 产品的机会。
现在，让我来告诉你为什么。

为什么评估（evals）很重要

假设你正在为一个旅游预订网站构建一个行程规划 AI 助手。

设想是这样的：用户输入自然语言请求，比如“我想要预算在 1000 美元以内、安排一个临近旧金山的轻松周末游”；AI 助手就会根据用户的偏好去研究最佳的航班、酒店和为他们量身打造的当地体验。

在构建这个智能体时，我们通常需要先选定一个 LLM（例如 GPT-4o、Claude 或 Gemini），然后设计提示词（具体指令）来引导 LLM 解读用户请求并作出恰当响应。

你可能会直接将用户的问题丢给大模型获得响应，然后再逐步添加功能，使其看起来更像一个真正的智能体；然后，为“LLM + 提示词”组合接入外部工具，如航班 API、酒店数据库或地图服务等，让它能够完成信息检索、动态响应用户需求。至此，一个简单的“LLM + 提示词”组合就进化成了能处理复杂多步骤交互的 AI 智能体。在内测过程当中，你通过枚举常见的场景来校验Agent的输出是否合理。

尽管看起来这一切都还不错，但是直到面世那天捅了篓子：客服的投诉接踵而来，你的Agent给客户预定了前往圣地亚哥而非旧金山的航班。这些Bug是如何发生的？更重要的是，我们该如何提前捕获和防止这些错误的发生呢？

这，就是评估重要的原因。

什么是评估（evals）？

评估是我们衡量AI系统质量和有效性的方式，它就像回归测试或基准测试，评估定义了AI产品“什么是好”。

评估 AI 系统不同于传统的软件测试，可以通过软件延迟或结果的对错评估，它更像是给人类进行的一场驾驶考试：

意识：它是否可以正确解读信号，并对不断变化的条件做出适当反应？

决策：它在不可预测的情况下，能否可靠地做出正确选择？

安全：它能否始终遵循指示，安全抵达预定目的地，而不偏离轨道？

正如你不会让未通过驾照考试的人开车上路一样，你也不应让未通过深思熟虑、有意识评估的 AI 产品上线。


尽管AI产品的评估在某些方面和单元测试类似，但是两者存在重要差异。

传统软件的单元测试就像检查火车是否始终运行在轨道上：足够直接、确定性高、有明确的通过/失败场景。而基于 LLM 系统的评估则更像在繁忙的城市中驾驶汽车：环境多变，系统具有不确定性。

与传统软件测试不同，当你多次向 LLM 提供相同的提示时，可能会看到略有不同的响应——就像司机在城市交通中的行为可能不同一样。通过评估，你通常需要处理更定性或开放式的指标（比如输出的相关性或连贯性）这些可能无法直接套用传统软件的测试模型。



入门指南

不同的评估方法
人工评估（Human evals）： 你可以在产品中设计用户反馈机制（例如，在 LLM 响应旁边显示点赞/点踩或评论框，供用户提供反馈）。你也可以让人类标注员或领域专家来提供他们的标注和反馈，并通过提示优化或微调模型（基于人类反馈的强化学习，或 RLHF）来使其与人类偏好对齐。

优点：直接与终端用户相关。

缺点：反馈非常稀疏（大多数人不会点击点赞/点踩），信号不强（点赞或点踩代表什么？），且成本高昂（雇佣人工标注员）。

基于代码的评估（Code-based evals）： 代码评估对API调用的调用是否正确、检查生成的代码是否“有效”且能够运行。

优点：编写此评估既便宜又快速。

缺点：信号不强；非常适合基于代码的 LLM 生成，但不适用于更细微的响应或评估。

基于 LLM 的评估（LLM-based evals）： 这种方法引入一个外部的 LLM 系统（即一个“法官”LLM），对智能体的输出进行评分。基于 LLM 的评估中，你可以用自动化方式生成分类标签，这些标签类似于人工标注的数据——无需用户或领域专家为所有数据打标签。

优点：可扩展（类似人工标注但成本低得多）且使用自然语言，产品经理可直接编写提示词。还能让 LLM 生成解释说明。

缺点：需要创建一个“法官”LLM（仍然需少量初始启动数据）。

基于LLM的评估需要构建提示词，构建你的Agent也是需要提示词的，你想要评估这个Agent就需要你能够明确描述"你需要评估什么 或 捕捉什么错误"。

回到前述的旅行计划的AI助手，在这个系统中，很多环节都可能出错，我们需要为每个步骤选择正确的评估方法。


标准评估标准

作为用户，您需要的评估标准应具备以下特点：(1) 具体明确，(2) 经过实战检验，(3) 针对特定成功领域进行测试。以下是评估可能关注的几个常见领域示例：

幻觉检测Hallucination：智能体是否准确使用了提供的上下文，还是在凭空捏造？

适用场景：当用户提供了文档或数据，供智能体基于其进行推理时。

有害信息/语气控制Toxicity/tone：智能体是否输出了有害的信息或不受欢迎的语气？

适用场景：终端用户应用，用于判断用户是否试图利用系统或 LLM 是否作出了不当的回应。

整体正确性Overall correctness：系统在实现核心目标上的表现如何？

适用场景：端到端的有效性评估，例如问答准确性，代理回答用户提问的实际正确率有多高？

其他常见的评估领域包括：

Code generation 代码生成

Summarization quality 摘要质量

Retrieval relevance 检索相关性

Phoenix（开源项目）维护了一个现成评估工具库；Ragas（开源项目）同样维护了一个专门针对 RAG 的评估工具库。

评估公式

每个优秀的 LLM 评估都包含四个不同的部分：

设定角色。您需要为“法官” LLM 设定一个角色（例如"你正在审阅书面文本"），以便系统可以应用于特定任务。提供上下文。上下文是你实际要发送给“法官”LLM 进行评估的数据，这些数据将来自你的应用程序（例如消息链，或由智能体生成的消息）。明确目标。清晰阐述你希望评判“法官”LLM衡量的内容。这不仅仅是流程中的一个步骤，更是区分平庸 AI 产品 与优秀AI 产品的关键。你需要向“法官”LLM 明确定义成功与失败的标准，将微妙的用户期望转化为“法官”LLM能够遵循的精确准则。你希望“法官”LLM 测量什么？如何表述“好”或“坏”的结果？培养出这种精准表达能力需要练习和专注。定义术语和标签。例如，“毒性Toxicity”在不同语境下可能有不同含义。你需要具体说明，以便评判 LLM 能根植于于你所关注的术语体系中。

以下是 给旅行规划智能体进行 有害信息/语气评估 的具体示例。


编写有效评估的流程


AI产品的评估并非一次性检查，而是一个从开发伊始持续到上线后的持续过程。整个流程包含 数据集构建、评估编写、结果分析、评估反馈等环节。

让我们用之前提到的旅行规划智能体来说明这个从零开始构建评估的过程。
第一阶段：数据集构建

假设你已经发布了旅行规划助手产品，并开始收集用户反馈。以下是利用这些反馈构建评估数据集的方法：
1.收集真实用户互动：记录用户实际使用应用时的数据，如直接反馈、数据分析或手动检查应用内的交互来实现。 例如：从用户与助手的互动中获取人工反馈（点赞/点踩）。尽量构建一个包含真实案例且附带人工反馈的数据集。如果还未未从应用中收集到反馈，也可以抽取数据样本并请领域专家进行标注。2. 记录边缘案例：识别用户与 AI 交互中不寻常或意料之外的方式，以及智能体的任何非典型响应。 在检查具体示例时，您可能需要一个主题分布均衡的数据集，包括如： 预订酒店、预订航班、请求旅行规划建议等场景。3.构建典型数据集：将这些数据梳理成为结构化数据集，理想情况下需标注"真实值"（人工标签）以确保准确性。根据经验法则，初始阶段需要准备 10 到 100 个带人工标签的样本作为评估基准。我的建议是：在起步阶段，选用开源且易用的工具来记录 LLM 应用数据和提示词。第二阶段：初步评估




在构建出包含真实案例的数据集后，就可以开始编写评估方案来测量特定指标了，并针对该数据集测试评估效果。

例如：你可能想确认智能体是否语气不佳，你希望即便平台用户给出负面反馈，智能体也能以友善的语调回应。

编写初始评估提示：参考上述公式的四个部分，明确说明你要测试的具体场景。

例如，初始评估可能看起来像这样：

设定角色： “你是一名评估书面文本的法官。”

提供上下文： “以下是文本：{text}” → 这里的{text}是一个变量，代表“LLM 智能体的回答”。

提供目标： “判断 LLM 智能体的回应是否友好。”

定义术语与标签： “‘友好’将被定义为在回应中使用感叹号，总体上乐于助人。回答绝不应带有负面语气。”

2.对数据集运行评估：将评估提示词 和 LLM 智能体的回应作为变量发送给 “法官”LLM 来执行评估，并为数据集中的每一行获取返回的标签。 目标是与人工标注的基准真相相比至少达到 90%的准确率。3.识别失败的处理：评估在哪些方面存在不足？迭代优化你的提示词。 比如，在以下示例中：评估结果与最后一条人工标注意见相左。我们上文提到的 LLM 代理的回应必须包含感叹号才能被视为友好，这一要求可能过于严苛了？

第三阶段：迭代循环

优化评估提示词：根据结果持续调整提示词内容，直至性能达到预期标准。 Tip: 可在提示中添加若干"优质"与"劣质"评估示例，通过"少量样本提示"（few shot）方式锚定 LLM 的响应质量。扩展你的数据集：定期添加新样本和边缘案例，以测试你的评估提示是否能有效泛化。迭代优化你的代理提示：评估能帮助你在底层 AI 系统变更时测试产品效果——某种程度上，它们是你为 AI 系统进行提示 A/B 测试的终极考验。

例如，当你对代理做出调整（如将模型从 GPT-4o 更换为 Claude 3.7 Sonnet），你可以通过更新后的代理重新运行收集的问题数据集，并用你的评估代理来评判新输出（即 Claude 3.7）的质量。目标是通过持续改进，使新代理的评估分数超越初始代理（GPT-4o）的基准水平。


第四阶段：线上监控

持续评估：将评估设定为在实时用户互动中自动运行。 例如：您可以持续对所有传入请求和代理响应运行“友好度”评估，以获取随时间变化的评分。这有助于回答 如“用户是否随着时间的推移变得更加沮丧？”或“我们对系统所做的更改是否影响了 LLM 的友好程度？”等问题。将评估结果与实际用户结果进行对比：寻找评估结果与真实表现（即人工标注的真实数据）之间的差异。利用这些洞察来优化你的评估框架，并逐步提高准确性。构建可用的评估仪表板：评估有助于向团队中的利益相关者传达 AI 指标，甚至可以与业务成果挂钩。它们可以作为系统变更的优先评估指标。

团队在评估时常犯的错误

早期的评估过于复杂，往往容易产生“噪声”信号（并导致团队对该方法失去信任）。应专注于具体输出而非复杂评估，在后续的迭代中不断增加精细度。没有覆盖边缘案例。在提示中提供一两个“好”与“坏”评估的具体示例（少样本提示）可提升评估效果。这有助于让评判 LLM 明确优劣标准。没有根据真实用户反馈验证评估结果。记住，在AI产品评估中你不仅仅是在测试代码，你是在验证你的 AI 是否能真正解决用户问题。

撰写高质量的评估报告能让你站在用户的角度思考——它们是你发现“糟糕”场景并明确改进方向的关键工具。

随着 AI 产品的日益复杂，编写优质评估的能力将变得愈发关键。

评估不仅关乎发现缺陷，更能确保您的 AI 产品能够持续创造价值、为用户带来惊喜！

评估是 AI产品从原型走向量产的关键步骤。