SallyAnn DeLucia：如何编写你的第一个 AI 评估

我是 SallyAnn，Arize 的产品负责人。我在这里大约四年了，最早参与的项目之一，就是把我们的 AI 智能体 Alex 做进平台。我既做过智能体，也做过评估产品。我把评估看作智能体的主要信号：它告诉我们，智能体实际表现得怎么样。

我希望你离开时，能清楚地定义什么是评估，掌握一套编写标准的方法，并拥有一个可以运行的裁判。我们会先建立基础，再在 Arize 里探索数据，确定想衡量什么，然后构建评估。过程中，我也会展示这个评估如何融入测试与改进的整个生命周期。

凭感觉检查为什么无法规模化？假设周一你修改了提示词，因为感觉更好就上线了。一周后，你以为已经修好的用例又出问题。随着情况恶化，没人能证明它之前究竟修好了没有，现在是否真的失败。你手里只有印象。

没有评估，你就无法可靠地发现提示词修改后的回归，客观比较不同提示词或模型版本，也无法知道新模型对你的具体用例是否更好。你同样无法在 CI 中设置有意义的质量门槛。即使不断发布改动，也很难说清智能体表现如何。

经常有人问，评估不就是单元测试吗？传统软件测试通常有输入和一个正确输出，而且你能从代码中看出逻辑。智能体不一样：它的许多逻辑只有事后通过追踪记录才能看见。旅行规划器可以给出许多有效行程，因此我们需要检查具体标准，例如行程本身及其预算明细。

我喜欢把追踪看作 AI 的日志，把评估看作测试。让人有点为难的是，要把这些测试做好，就需要可观测性。追踪记录了智能体为回答用户而执行的全部步骤，其中每个 span 代表一块独立工作，让我们看到从请求到最终回复之间发生了什么。

智能体可能调用研究智能体、使用工具、从知识库检索信息，并组合多次模型调用，中间有大量来回交互。智能体的逻辑就体现在这里。只用一个传统测试检查最终结果，未必能覆盖所有复杂性，也未必能告诉你究竟哪部分表现不佳。

今天我们聚焦“大模型充当裁判”：拿另一个模型，给智能体的某一方面打分。可以评问答正确性、摘要质量或相关性。结果包括一个标签和一段解释。解释很重要，因为它能让我们了解为什么会这样判断，而不是要求我们直接接受标签。

还有其他评估类型。决策模型是正在兴起的一种选择，可能又便宜又快：提出一个问题，得到一个概率，以及 true/false 结果或标签之类的输出。与大模型裁判不同，它们通常不提供解释。代码评估适合确定性检查，比如输出是否包含某个词，或是否为有效 JSON；ROUGE 和 BLEU 也是例子。

标注也是一种评估方式，可以使用带标签的样本或黄金数据集，有时也包含合成数据。智能体还能评判另一个智能体，这对复杂的成功标准可能有帮助。用户反馈和业务指标则提供生产信号。开发阶段的评估应该随着应用一起成长，而不是投入一批测试，上生产时又把它们丢掉。

这场工作坊使用 Arize AX 和一个演示项目。你需要能访问某个模型供应商，这样测试评估器时才能调用模型。自定义端点也可以，不必选定某一家。关键是要有一个能正常工作的模型连接，供裁判使用。

在产品里进入 Settings，再进入 AI Providers。选择你想用的供应商，比如 Anthropic、OpenAI、Gemini 或其他支持的选项，并添加 API key。点击测试集成的按钮，确认连接正常。追踪页面还提供了演示项目，旧版本的演示也可以用于这次练习。

我们的演示是一个旅行规划智能体。它接收请求，可以追问、调用工具，并返回计划。从产品角度看，好的表现意味着回答用户的后续问题，遵守指定天数和预算。请求里包括目的地、旅行时长、预算和总体旅行风格等细节。

写评估之前，先查看几条追踪记录，盘点一下：用户在问什么？智能体做了什么？用了哪些工具，给出了什么答案？问问自己，这真的是你愿意交给用户的回复吗？这番探索能帮助你决定哪些东西值得衡量。

有个例子里，用户想用 800 美元预算去布拉格旅行三天，并希望行程更当地化、少一些游客扎堆的内容。智能体给出了第一、第二和第三天的详细计划。我们可以阅读最终行程，也可以打开属性，查看与请求和回复关联的其他数据。

追踪树展示每一个独立步骤。想知道某次模型调用用了哪些信息，就选中对应 span，查看输入和输出。要留意数据存在哪里。稍后评估需要正确的证据，而这些证据可能在追踪的根部，也可能藏在某个子 span 里。

探索时，把自己当作这个旅行智能体的相关方：产品人员、工程师，或者任何对其结果负责的人。看看用户怎样与它互动，它又怎样回应。先在心里列出一份清单：你会衡量什么，以判断它是否成功？工作坊下一部分会把这些观察变成明确的标准。

一条追踪，是回答用户问题所经历的全部步骤的集合。最上面是根 span，它的 parent ID 为 null，表示上方没有父节点，通常包含总体输入和最终输出。下面是各个 span，每个代表一个工作单元。

在这个例子里，主智能体调用了研究智能体，构成一个多智能体系统。研究智能体又调用工具，获取天气或目的地细节等外部信息。图标区分了智能体 span、工具 span 和模型 span。沿着它们看，就能了解信息如何在应用中流动。

一次模型调用可以接收工具返回的信息，整理成摘要，供后续步骤使用。你可以查看这次调用的真实输入输出，再沿树逐步往下看。相互连接的工作单元，最终支撑起一份符合用户旅行安排、偏好、活动和住宿需求的行程。

有位观众问，为什么一次工具调用前后各有一个模型 span？有时埋点会把模型选择工具，与模型处理工具结果分开记录。在这条追踪中，第一次模型调用选择工具，工具获取温度和目的地数据等信息，后续模型调用再总结输出，供下一步使用。

根节点负责作出全部决定吗？这取决于架构。你可能有监督或编排智能体，为子智能体制定计划；也可能是一个带工具的模型，逐步决定下一步做什么。这个例子看起来是 LangGraph 智能体，由模块化智能体分别处理不同任务，而不是监督者架构。

Arize 不限定框架。我们的 OpenInference 追踪包为不同框架提供自动埋点工具，目标是无论你选择什么框架，都能获得有用的可观测性与评估。熟悉追踪记录、发现值得衡量的行为后，就可以开始定义评估了。

第一步是定义什么叫好。不要停在“有帮助”“准确”或“好的回复”这样的词上，要具体。对旅行智能体来说，好的表现可能是回答用户的后续问题、符合要求的天数，或者总花费不超过预算。这些才是与应用实际任务相关的具体标准。

每个评估只判断一种质量。有例外：决策模型和智能体裁判有时能同时处理多个标准。但对大模型裁判来说，好的实践是先选一个标准，再逐渐添加其他评估。评估是迭代过程，不是建好一套后，就假定它能覆盖应用的整个生命周期。

最初给 Alex 做评估时，我们的集合很简单：问答正确性、用户挫败感，以及越狱和有害内容等安全检查。现在，Alex 运行着 32 个评估。从小处开始，以真实的生产使用为依据，随着你了解还需要什么才能定义成功，持续完善评估套件。

通用评估比特定评估更好吗？总体上，针对具体用例定制更好，但有评估总比没有好。Arize 的 eval hub 提供正确性、幻觉、会话连贯性等常见问题的模板。它们是很好的起点，也可以在组织内共享，之后再逐步对齐、细化。

接下来的练习，请写下六项内容：任务是什么、成功是什么样、失败是什么样、正在判断哪种质量，以及分别最多三条通过条件和失败条件。这些笔记会成为你的评估。写得越具体，越容易转化成有用的提示词。

有人问，追踪记录里看到的请求信息是开箱即有，还是需要自定义埋点？自动埋点会捕获常见属性，例如发送给模型的输入消息。手动或混合埋点则允许加入应用特有的信息。目标是在让常见配置足够简单的同时，取得具体用例所需的证据。

你也可以让智能体使用现成的 skills 帮应用埋点，再按需指导它。在评分标准的例子里，任务是回复用户对旅行的后续追问。成功是带着本次旅行的细节直接回答；失败则是退回到泛泛的预算回复。这比只说“答案应该好”有用得多。

为什么要列通过和失败条件，而不是只写一句话？因为我们要用它们构建大模型裁判提示词，模型需要明确知道该看什么。把它当成向同事或其他相关方解释验收标准。如果评分标准想做的事太多，就先缩减，再继续。

构建评估时，回到追踪记录，为数据集选择样本。如果评估行程是否符合用户输入，就保存根 span，因为这两份证据都在这里。如果评估某次工具调用是否返回正确的信息，就选择相关工具调用的 span。数据集应该对应评估器要回答的问题。

筛选器可以帮助找到这些样本。要找根 span，可以筛选 parent ID 为 null，或使用默认的追踪视图。要单独查看某个工具，就按名称筛选。选中相关 span，添加到新数据集。保存样本后，就能进入 playground，构建并测试评估器。

第一轮流程是：查看追踪，确定要评判的 span，创建筛选条件，把这些 span 加入数据集，然后打开新的 playground。Arize 有测试评估器提示词或其他模型提示词的 prompt playground，也有端到端测试应用的 agent playground。这次练习使用前者。

如果你已经在 eval hub 创建了评估，就从下拉菜单添加；否则，从空白评估开始。把写好的标准变成提示词，评分标准的大部分内容都能直接粘贴。先解释评估器的职责，让模型准确理解自己要判断什么。

例如，裁判的工作可以是判断助手输出是否准确涵盖了输入中要求或提供的细节，然后提供数据。相关信息就在之前查看过的属性中，但不必把那些具体属性名写死在每个提示词里。通过变量映射，可以把提示词输入连接到实际数据。

变量映射让评估器保持灵活。同一份信息在数据集和追踪记录中，可能使用不同名称；不必重写每一个评估，只需修改使用位置的映射。提示词就能专注于标准：只有输出与输入一致，才标为 correct；如果把目的地或住宿类型等关键细节弄错，就标为 incorrect。

在参数中配置评估器可以返回的标签。这个例子使用 correct 和 incorrect，如果有必要，也可以加入 partially correct 或 not applicable。Alex 的一些用例就需要区分答案是否仅部分正确。评估器会返回一个标签，你还要指定更高还是更低的结果代表更好的表现。

开启解释，了解评估为什么给出这个标签。载入所选 span 构成的数据集，把它的输入输出映射到提示词变量。证据连接好后，就运行评估。演示中我使用 GPT-4.1 mini，结果会直接显示在 playground 中。

现在开始迭代模板。阅读回复，判断自己是否认同裁判的结论，调整提示词，再运行一次。当评估器达到有用的状态，就保存下来。之后，在平台其他位置也能使用它，既能用于演示项目，也能用于你自己构建并接入 Arize 的应用。

我们已经写好标准，亲自测试了评估器，但第一轮之后，Alex 也可以帮忙。它能运行 playground、查看结果、修改提示词，再反复进行。更大的改进循环还包括我们的托管智能体 Signal，它能检查追踪记录、发现问题并进行修复。评估结果会成为这些改进工具可以使用的信号。

下一步是对齐：给数据集里的样本做标注，运行评估，再检查裁判判断是否与人工反馈一致。在线评估则把评估器放进一个持续处理新追踪记录的任务中。追踪一到，配置好的评估就自动打分，让你能够监控生产环境里的应用。

每个相关方都在评估智能体，这不只是某一个岗位的责任。把所有关心结果的人聚在一起，包括产品、工程、客服、领域专家和安全人员，让他们从各自角度定义成功。指标与评估相互配合：指标可以提醒你可能有东西坏了，评估则有助于识别具体的失败模式。

另一个值得尝试的实验，是把大模型裁判的标准改写为决策裁判的问题，再比较两者，看哪一种更适合这项任务。最重要的是从小处开始：也许是 20 条追踪记录、一个维度、一个裁判。读解释、反复调整，然后再扩展更多评估。还有文档和基准测试资源，可以帮助你在工作坊结束后继续探索。