--- id: "gv4w23xYj-0" title: "如何写出你的第一个 AI 评测" channel: "AI Engineer" host: ["AI Engineer"] guests: ["SallyAnn DeLucia"] date: "2026-10-25" updated: "2026-10-26" duration: "35:19" duration_seconds: 2119 source_type: "youtube" youtube: "https://www.youtube.com/watch?v=gv4w23xYj-0" canonical: "https://pod-exp.pages.dev/gv4w23xYj-0/" transcript_jsonl: "https://pod-exp.pages.dev/gv4w23xYj-0/transcript.jsonl" language: "zh-CN" translation: true translated_from: "en" timestamp_precision: "block" topics: ["AI 智能体","模型评测","AI 基础设施"] series: ["AI 软件工程师"] --- # 如何写出你的第一个 AI 评测 > 中文译文，由英文原音字幕翻译整理，不是官方逐字稿；引用原话请核对英文原视频。说话人标签由整理者依上下文标注，带「未确认 / 未标注 / 不确定」等字样的标签不可靠。时间戳一般为块级（所在时间块的起点），不是逐句时间；正文自带 [hh:mm:ss] 的段落除外。 **内容提要：** SallyAnn DeLucia 通过旅行规划智能体的实例，介绍如何从“凭感觉”评估转向可重复的 AI 评测。她区分了传统单元测试与智能体评测，梳理 LLM 评审器、决策模型、代码评测、人工标注及智能体评审等方式，并强调要借助 trace 理解智能体执行过程。实际工作坊从明确成功标准开始，筛选 trace 建立数据集，再编写和迭代评测提示词。她建议从单一维度、小规模数据起步，让利益相关者共同定义成功，并将评测持续用于生产监控。 ## [0:14] 开场与议程 · YouTube **SallyAnn DeLucia：** 开始之前，我先自我介绍一下。我叫 Sally Ann，是 Arize 的产品负责人，在 Arize 工作大概四年了。我最早负责的项目之一，是把我们的 AI 智能体 Alex 集成进平台。所以我接触评测已经有一段时间，也参与打造了我们很多评测产品。我认为，评测是我们判断智能体表现的首要信号，这也包括 Arize 的所有评测。 今天结束时，我希望大家能带走三样东西：清楚理解评测是什么、又不是什么；能够自己编写评判标准；以及掌握一套思路，知道如何考虑评测，并把它应用到真实的智能体场景里。我们还会在 Arize 里实际搭建一个可用的评审器，我会介绍它的生命周期，以及如何随着时间推移改进评测。 今天的安排是先补充一些背景。我不想花太多时间讲幻灯片，但希望大家先扎实理解评测是什么、应该如何看待它。然后我们会一起查看 Arize 里的数据，编写标准，再动手构建评测。这是今天工作坊的主要部分。今天的工作坊。接下来，我会简单谈谈之后可以如何继续推进。我也希望留出一些动手协作的时间，让大家一起工作；我会尽量在现场走动，帮助大家。我还会展示一份放在 Notion 上的单页材料，大家可以打开跟着做。 我先了解一下现场情况：在座有多少人发布过聊天机器人或智能体、写过评测，或者今天只是打开过 Arize 产品？有人吗？好，现场有几位。我觉得这场工作坊对还没做过这些事的人会很有帮助；即使你做过，我想今天的内容也仍然会很实用。 ## [2:06] 凭感觉检查为何无法规模化 · YouTube **SallyAnn DeLucia：** 先从背景说起：为什么我认为凭感觉检查无法扩展。这就是我看到的“感觉派”问题。周一，你也许改了提示词并发布，整体感觉好了一些。你其实没有办法确定，只是觉得一切看起来不错。周二又发布一次；一周后，你当初修复的那个使用场景却坏掉了。再下一周，问题继续恶化，谁也没法证明问题到底修好了没有，或者系统是不是正在失败，你只能凭感觉判断。感觉。感觉。 没有评测，你就无法在修改提示词时检测回归，也无法客观比较不同提示词，甚至不同版本的模型。你不知道新模型对你的使用场景是否更好，也没法在发布智能体时把正式的质量门槛纳入 CI。没有评测，就很难真正知道智能体表现如何。 ## [3:08] 评测只是单元测试吗？ · YouTube **SallyAnn DeLucia：** 很多人会问我：评测不就是单元测试吗？我觉得人们常把 AI 评测和传统软件测试作比较，但它们确实有些不同。传统测试通常是一个输入对应一个正确输出，而且你还能读懂代码里的全部逻辑。对于 AI 智能体，你看不到这些内部逻辑；它实际执行的过程会以 trace 的形式呈现出来。 因此，你需要 AI 评测来检查多个标准。例如我这里的旅行规划器，可以看逐日行程、预算明细，或者若干项不同的评判标准。它可能有很多种有效输出，无法像传统软件那样用一个单元测试来覆盖。 我喜欢这样理解：trace 是 AI 的日志，评测才是真正的测试。我以前有个梗图，今天没放出来，但有个不太好听的事实是：要做评测，你需要 trace，也需要可观测性。 ## [4:13] 为什么智能体让评测更难 · YouTube **SallyAnn DeLucia：** 这就是智能体让评测更难的一个例子。这里展示的是一条 trace 的示意图。对不熟悉 trace 的朋友来说，它本质上记录了 AI 智能体为生成回答所采取的全部步骤。用户提出问题，图里的每个 span 就是智能体为得到答案执行的一项具体步骤。 这个例子里有一个研究智能体，它会开展研究，也许还会调用工具；另一个本地智能体可能从知识库里检索内容。过程中会发生大量来回交互。这就是我说的，你可以从 trace 里看到智能体的逻辑。我们稍后会在 Arize 界面里看一些 trace。你会看到很多大语言模型调用、很多步骤组合在一起。可以想象，只用一个像传统软件里的单元测试，无法准确涵盖智能体的全部复杂性，也无法告诉我们它表现如何。 ## [5:17] 评测的类型 · YouTube **SallyAnn DeLucia：** 评测其实有很多种。今天我们重点讲“让大语言模型担任评审”（LLM as a judge）：我们使用另一个 LLM，让它评判智能体某一方面的表现。比如问答、摘要、相关性；评审器会给出标签和解释。解释很有帮助，它呈现了给出某个标签背后的理由，让你不必只凭标签本身做判断。 除此之外还有很多种评测。我想特别提一下决策模型，这是一种比较新的方式。如果有人参加了大约两周前那场名称听起来像“Jevas a Job”的活动，以及 OpenAI 上周发布的决策模型 API，那么会知道这个话题。〔活动名称听写不确定〕我觉得决策模型未来会在评测中占很大比重。它们成本低、速度快，形式更像问答：你会得到一个概率，以及 true/false 或某种标签这样的输出。不过它不像 Arize 的 AI Judge 那样提供解释。 另一类是代码评测，适合确定性测试。比如检查输出里是否包含某个词，或者确保内容是 JSON，这些都很适合用代码评测。ROUGE 和 BLEU 分数也是常见的代码评测指标。 我也把人工标注视为一种评估方式：我们会在黄金数据集上标注真实标签，有时也会用合成数据。还有一种近六个月出现的新评测方式，叫“智能体担任评审”：让一个完整的智能体去评估另一个智能体的某个方面。我认为它适用于非常复杂的成功标准。 此外还有用户反馈和业务指标，这几类更适用于生产环境。前面提到的几类评测，则会贯穿开发和生产的整个生命周期。这一点很重要，因为评测应该随着使用场景演进；你不希望在开发阶段投入大量精力，之后却把它丢掉。评测可以随时间不断发展，并持续衡量表现。 ## [7:30] 工作坊准备 · YouTube **SallyAnn DeLucia：** 好，我们来看看数据。先停在这张幻灯片上几分钟，让大家开始准备。二维码链接到今天工作坊的单页说明。请大家打开 app.arize.com，登录 Arize。如果还没有账号，可以今天注册一个免费账号。接下来我会说明操作步骤。已经有 Arize 账号的朋友，下一步需要从模型服务商那里获取 API 密钥。我先停一下，在现场走动看看大家能不能顺利登录平台。平台。 刚才有人问，第二步是否必须使用常见服务商，能不能用自定义端点？可以，想配置哪家 LLM 服务商都行；只要能调用 LLM，我们就能测试评测。第二步基本上就是前往你选择的服务商控制台，比如 Anthropic 或 OpenAI。然后在产品设置里找到 AI 服务商，把 API 密钥添加进去。我到电脑上给大家演示一下。 在导航栏里点“设置”，然后进入账号设置。好，找到“AI 服务商”。这里有很多不同的服务商，选你常用的就行，Anthropic、OpenAI、Gemini 都可以；只要能用来发起 API 调用即可。配置时建议点击“测试集成”，确认 API 密钥可用。 大家可以通过两种方式进入我们要用的演示项目。先从这个追踪页面进入，你会看到演示项目。我这里用的是 LLM 智能体，有些人看到的可能是旧版演示模型；用哪个都不影响今天的练习。我们只需要查看一些 trace。你也可以扩大时间范围，查看更多数据。 我再多给大家几分钟，因为我只看到少数人配置好了 AI 服务商。我也看看能不能尽快提供一个大家都能用的账号。 ## [10:16] 查看旅行智能体的 Trace · YouTube **SallyAnn DeLucia：** 好，如果你已经打开旅行智能体演示项目，这是一个旅行规划智能体。用户提出需求后，它可以追问、调用工具，最后返回一份计划。从产品角度看，好的结果应该回答用户提出的后续问题，并遵守旅行天数和预算。一般的用户请求会包含目的地、旅行时长、预算，以及大致的旅行风格。这就是用户可能给旅行智能体的请求。 请大家花几分钟查看 trace，盘点一下：用户在问什么？智能体调用了什么工具？用了哪些工具？给出的回答是什么？也记一下，这个回答你愿不愿意分享给别人。先熟悉一下数据。可以打开一两条 trace，边看边想想你会测量什么。 我来产品里看一条示例 trace。这里的目的地是捷克共和国布拉格，行程三天，预算 800 美元。用户希望行程更有当地特色、少一些游客常去的景点。我们先看一些构想，然后查看旅行规划智能体做出的计划：里面有详细的第一天、第二天、第三天安排。若想看更多属性或数据，可以打开“属性”面板。 简单说一下产品的浏览方式：这里是 trace 树，显示每个具体步骤。选中某个步骤，就能查看传入的数据。比如想看传给 OpenAI 处理请求的数据，可以点选对应的 span，再查看输入和输出。稍后我们还会回到这里；现在要留意数据存在哪里，以及哪些数据可能对评测有用。大家可以继续探索几分钟，看看能发现什么。 有人问实际数据在哪里，我再演示一次。新版工作区里入口有时不太显眼，但今天主要讨论评测，不想让大家把太多时间花在追踪入口上。点击导航里的“Traces”，进入后选择演示项目，再从最近查看的项目中打开它。你也可以扩大时间范围查看更多数据。大家都找到项目并简单看过了吗？我看到有人点头了。好。 进入下一部分之前，请大家先看看这个智能体，想想如何衡量它的表现或成功。把自己想成产品负责人、工程师，或这个项目的其他实际利益相关者；观察 trace、用户如何与智能体互动、它如何回应，并记下你认为应该测量的内容。工作坊下一部分会开始定义具体标准；现在先从高层次想想要测什么。 有人问该如何阅读 trace。对不熟悉的人来说，trace 本质上是智能体为回答用户问题而执行的所有步骤的集合。 ## [14:16] 查看旅行智能体的 Trace（续） · YouTube **SallyAnn DeLucia：** 接下来我们打开这条 trace。 ## [14:20] 如何阅读 Trace · YouTube **SallyAnn DeLucia：** 顶部这个叫根 span。技术上说，它的 parent ID 等于 null，也就是没有上级节点，位于最顶层。输入和最终输出通常就在这里。 接下来是各个 span。我喜欢把每个 span 看作一个工作单元。先看第一组：从根 span 往下，这个智能体调用了研究智能体。这里是一个多智能体系统，由多个智能体分别替更大的智能体完成不同任务。这个研究智能体接下来会调用工具。每个步骤都有自己的类型，也会用不同图标表示：这是智能体 span，这是工具 span。工具 span 用来获取外部数据。比如研究时需要天气、景点之类的基本信息。 之后会调用 LLM。这里可以看到实际传给 LLM 的输入和输出。这个环节使用的是精简旅行智能体，并利用工具返回的信息做摘要，供后续步骤使用。你可以沿着 trace 树逐步往下看，了解各步骤如何连接；每个步骤都是一个工作单元，最终共同生成答案。这个应用要根据用户的旅行需求，为他们规划行程，提供符合偏好的活动安排和住宿地点。每个 span 都是生成最终行程所经历的一个单元。关于 trace 有问题吗？我可以边看边回答。 **现场提问者（身份未确认）：** 这里为什么会有两个 LLM span？ **SallyAnn DeLucia：** 有时我得回头查看具体 trace 才知道发生了什么。有些时候，这是埋点把不同操作分开记录了：LLM 先选择要用的工具，然后把信息传给工具。我们一起看看这里发生了什么。 有些内容只是埋点方式的一部分。看起来第一个 LLM 调用选择了工具，第二个 LLM 调用则接收工具数据并进行摘要。你有时得沿着 trace 先往下再往回看：这个 LLM span 选择了工具，另一个 LLM span 总结工具输出。工具获取了温度和目的地数据，第二个 LLM 再把这些信息概括出来，供后续处理。 有人问根节点是否会做出所有决策，还是有其他灵活性。灵活性很大，取决于你的智能体基础设施。你可以使用监督器或编排智能体，由它为子智能体制定计划；也可以把请求交给一个配备工具的 LLM，让它逐步处理。具体要看你使用的框架、基础设施和智能体总体架构。 我认为这个例子用的是 LangGraph 智能体，所以并没有真正采用监督器架构，而是由几个模块化智能体分别负责不同任务。问得很好。另一个问题是 Arize 支持哪些智能体框架。我们不限定框架；通过 OpenInference 追踪包提供了多种自动埋点工具。我们对框架没有偏好，目标是保持灵活，在其上提供出色的可观测性和评测。我可以把文档链接发给大家，里面列出了支持的框架。 ## [18:21] 如何阅读 Trace（续） · YouTube **SallyAnn DeLucia：** 有人问 Arize 支持哪些智能体框架。我们不绑定特定框架。我们的追踪包 OpenInference 提供了多种自动埋点工具。我们对要使用哪种框架没有偏好；目标是保持足够灵活，为各种框架提供出色的可观测性和评测能力。我可以把文档链接发给大家，里面能看到所有受支持的框架。 好，我们继续。听起来大家已经有时间查看 trace、熟悉这里的数据，也希望已经发现了可以用来衡量成功与否的方面。 ## [19:05] 定义什么是“好” · YouTube **SallyAnn DeLucia：** 定义评测的第一步，是先定义什么叫好。这对有些人来说不容易，所以我有个区分模糊标准和具体标准的小技巧：把“好”写下来，但要用非常具体的标准。不要只写“有帮助”“准确”“回答不错”，而要更具体一些，比如：回答用户的后续问题；行程天数符合要求；总花费不超过用户给出的预算。对这个应用来说，这些都是清楚具体的成功标准。如果你在为自己的应用做评测，也可以坐下来认真想想这些标准是什么。 还有一个建议：每个评测只判断一种质量。当然也有例外，尤其是决策模型和智能体评审器，可以一次处理多个标准。但有很多研究表明，LLM 评审器一次只处理一个标准时表现更好。因此，比较好的做法是先聚焦一个标准，再逐步增加更多评测。 构建评测集是一个迭代过程。不是建好之后就可以一劳永逸、用到应用生命周期结束。你得不断迭代。定义成功时，我通常先写下几个标准，开始实现，然后逐渐增加更多内容。 我参与过 Arize 里的 AI 智能体 Alex 的开发。刚开始做评测时，集合非常简单：问答正确性、用户挫败感，也包括越狱和有害内容之类的安全评测。现在 Alex 上运行着 32 个评测。你可以看到，应该从小处着手；等应用开始有真实使用量，就用生产数据来校准，再逐步完善评测，看看还需要定义哪些成功标准。 有人问，通用评测是否优于更具体的评测。我觉得要看情况。通常，为你的使用场景构建专门的评测会更好。但有评测总比没有好。比如在 Arize，很多人刚开始会用评测中心里现成的模板，例如问答正确性、幻觉、会话连贯性等。这些很适合入门，但关键是逐渐让评测贴合你的使用场景，并随着时间开发出更具体的评测。基础评测、在组织内复用评测都很有价值；先有一些评测，再让它们变得更具体。 ## [22:04] 编写通过与失败标准 · YouTube **SallyAnn DeLucia：** 先从一个评测开始，以后再加。接下来请两人一组，或者和附近的人一起，记下一些想法。我们要写下六项内容，它们会帮助我们真正搭建评测。第一项是任务：你希望评测判断什么？成功是什么样，失败又是什么样？也就是这项评测实际要评判什么。然后分别用三条要点描述通过和失败的情形。记住，描述越具体、越明确，评测效果越好。接下来我们会用这些笔记来构建评测。因此标准越具体越好。大家可以聊聊各自的想法、在 trace 里注意到什么；我会在现场走动，有问题随时告诉我。 有人问，这个应用的 trace 数据看起来很具体，包含所有请求信息，这些是开箱即用的吗，还是要按自己的场景构建？我们的开箱即用埋点会帮你抽象出许多追踪最佳实践，因此会自动记录不少常见属性，例如输入值或发给 LLM 的输入消息，这些都比较标准。但你也可以做手动埋点或混合埋点来定制。追踪方式很灵活，我们既希望它能贴合你的使用场景、提供所需信息，也希望让它容易上手。 如果你想追踪自己的应用，入门页面里有我们的“MPX evals”调用，它会带入我们全部技能。如今做追踪，这是一种很好的方式：让智能体自行判断如何埋点，你也可以逐步引导它。如果你之后要提交自己的 trace 来做评测，我很推荐这种做法。 我切到下一张幻灯片，给大家看看标准大致应该是什么样子，然后再回答刚才的问题。例子里的任务是判断用户提出旅行后续问题时，智能体的回答是否成功：成功是根据行程细节直接回答；失败是退回到通用预算。你会看到通过和失败各自的标准。有人问，为什么需要列出要点，一句话不够吗？因为我们要用这些内容编写 LLM 评审器的提示词，所以要尽量具体，让 LLM 能理解。你可以把它想成向同事或利益相关者解释成功是什么样；创建标准时也要按这个要求表达。 我再回答几个问题，然后进入下一步。如果有人想提前做，可以开始完善描述；如果标准写得太多，也可以删减。为了赶进度，我们接着往下走。 ## [25:19] 从 Trace 构建数据集 · YouTube **SallyAnn DeLucia：** 现在开始构建评测。第一步是回到 trace 页面，选一些 trace 加进数据集。比如想判断输入和行程安排是否匹配，也就是行程是否覆盖了用户的整体需求，就把这些根 span 保存到数据集。如果想测试工具调用是否返回了应有的信息，就把相应的工具调用加入数据集。 可以用筛选器来识别数据，这是最好的方式之一。比如要找根 span，可以筛选 `parent ID = null`，或者基于默认 trace 进行筛选。如果想筛某种工具调用，例如我想的是那个 essential 工具，也可以按名称过滤。然后从 span 视图里选中这些记录，添加到新数据集。这就是下一步。之后我们会进入 Playground，实际构建并测试评测。大家可以先过去，我会回答关于添加数据集和筛选的问题。我想结合剩余时间，给大家演示接下来的步骤。 ## [26:56] 构建并测试 LLM 评审器 · YouTube **SallyAnn DeLucia：** 希望大家已经写好评判标准，也找到了要用于评测的 span。这就是第一轮流程，我现在会现场演示，大家可以跟着做。刚刚我们已经筛选了需要判断的 span：查看 trace、找出要评估的 span、设置筛选器，再把结果加入数据集。 接下来进入 Prompt Playground，这是我最喜欢用来测试提示词的地方。我已经建好一个，不过现在再新建一个。产品里有两种 Playground：今天用 Prompt Playground，它适合测试评测提示词，或者智能体的其他 LLM 提示词；还有 Agent Playground，用来端到端测试智能体，今天不太相关。我给它起名叫“AI engine evals”，然后创建。 如果你是在评测中心创建评测，会看到一个侧边面板。在 Playground 里可以从下拉菜单添加评测，然后它就会显示出来。刚开始做评测的人可以选空白评测，在这里直接编写模板。基本上，你要把刚才写的标准转成提示词；很多内容可以直接粘贴，比如通过与失败的要点。但通常还应该先介绍评测任务，例如告诉评审 LLM，你要它判断应用输出的准确性。我把一个示例载入。好的。 我喜欢先用一个例子说明 LLM 应该做什么，让评审器始终围绕自身任务。你要评估的是：助手输出是否准确涵盖了请求中或输入里提供的细节。然后要提供数据。这一点很重要：查看 trace 时，先找出要使用的属性。提示词里不必写死具体字段名，因为我们有变量映射，可以把提示词变量连接到实际数据。这样评测就更灵活了：如果数据集和 trace 对同一字段使用了不同名字，就不必逐个修改所有评测，只需更新使用它的任务即可。因此不用太纠结变量名称。这是我写的示例。这里是检查项，也就是通过和失败的三条标准。 我会规定：只有输出与输入一致时才标为正确；如果目的地或住宿类型错误，就标为不正确。任务参数里设置了标签。这个示例只有“正确”或“不正确”，但也可以做多标签，例如正确、错误、部分正确。我在 Alex 上有些场景，需要区分“有些正确但不完全正确”。也可以设置“不适用”，灵活性很高。每次评测只会返回一个标签。 这里还能设置优化方向：高分代表好，还是低分代表好；也能给出解释，即模板或评测为什么返回这个结果。最后要载入数据集，也就是之前创建并保存的那些 span。 ## [30:58] 构建并测试 LLM 评审器（续） · YouTube **SallyAnn DeLucia：** 你可以把创建并保存的数据集载入。现在我们可以开始测试评测了。这里有所有输入和输出。如果需要把它们映射到不同变量，也可以在这里设置；我的变量恰好相同。 接下来运行评测。我选用 4.1 mini，觉得挺合适。然后就能在 Playground 里看到评测结果。这里很适合迭代评测模板：查看回答，看看哪些判断你认同、哪些不认同，再调整提示词，反复运行。接下来一段时间我们就会把模板调到合适的状态。 最后可以点击这里的“保存评估器”按钮。保存之后，这个评估器就能在整个 Arize 平台上使用，无论是在演示项目里，还是用于你之后构建并接入 Arize 的应用。我会到现场走动，帮大家编写模板。最后我还准备了一两张幻灯片来做总结。我想先指出…… ## [32:08] 后续步骤：对齐、在线评测与 Signal · YouTube **SallyAnn DeLucia：** 我想指出，我们也有一些工具可以帮助大家。今天我让大家写标准、写评测并进行测试，但平台里还有 Alex 可以帮忙。我特别建议大家先完成第一轮评测，再让 Alex 协助：它可以替你运行 Playground、查看结果、更新提示词，然后重复这个过程。这对编写评测很有帮助。 接下来简单补充整个循环的其余部分。今天我们主要花时间在第二步，也就是埋点和编写评测。后续还有 Signal，这是平台里的托管智能体，可以查看 trace、帮你发现问题，甚至修复问题。这些信号又能被我们的托管智能体使用，最终帮助改进你的应用。 我认为优秀团队接下来会做几件事。第一是对齐：给加入数据集的示例加注释，再运行评测，看看结果是否符合人工反馈。在线评测则是把评测放进任务里，持续运行于 trace 之上。在 Arize 中，每次提交一条 trace，系统都会按你的所有评测来判断，并自动发布结果，供你监控应用。 大家要记住，评估智能体是每个利益相关者的事，不只是某一种角色的职责。你应该让所有和智能体有关的人都参与进来，按各自的结果定义成功是什么样，包括产品、工程、支持、领域专家和安全团队。指标和评测的关键区别是：指标告诉你某处可能坏了，评测会告诉你具体的失败模式。因此两者都要用。 接下来也可以尝试新的决策评审器。把你现在的 AI Judge 评测转成一个决策评审问题，再比较两者的表现，看看哪种更好。还有，记得从小处开始：也许先用 20 条 trace、一个维度、一个评审器；阅读解释，不断迭代，然后再逐步扩展更多评测。 我们还有一些资料，比如“如何评估你的 LLM 评审器”的文档，以及决策模型基准测试的深入介绍。有人问什么时候应该用 LLM 评审器、什么时候该用决策评审器，这是个很好的问题。今天我会在这里待到活动结束。Arize 在展区有展位，我记得今天 4 点开始开放。想进一步了解评测或看看我们的产品，欢迎来找我们。如果还有问题，我也很乐意回答。谢谢大家今天来参加。