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