评估最佳实践

生成式 AI 具有多变性。模型有时会对相同的输入产生不同的输出，这使得传统的软件测试方法不足以应对 AI 架构。评估 (评估) 是一种测试 AI 系统的方法，即使存在这种多变性也能进行有效测试。

本指南提供了有关设计评估的高层级指导。若要开始 Evals API，请参见 评估模型性能.

什么是评估？

评估是衡量模型性能的结构化测试。尽管 AI 系统具有非确定性，评估仍有助于确保其准确性、性能和可靠性。它们也是 提升 基于 LLM 应用程序性能的少数方法之一（通过 微调).

评估类型

当你看到“评估”一词时，它可能指代以下几种事物：

• 用于独立比较模型的行业基准，例如 MMLU and those listed on HuggingFace 的排行榜
• 标准数值分数——例如 ROUGE, BERTScore——你可以在为你的用例设计评估时使用它们
• 你为衡量 LLM 应用程序性能而实现的具体测试

本指南讨论的是第三种类型：设计你自己的评估。

如何解读评估

你通常会看到介于 0 和 1 之间的数值评估分数。但评估不仅仅是分数。应将指标与人工判断相结合，以确保你正在解答正确的问题。

设计评估流程

评估工作流包含以下几个重要部分：

1. 定义评估目标. 评估的成功标准是什么？
2. 收集数据集. 哪些数据有助于您根据目标进行评估？考虑合成评估数据、特定领域评估数据、购买的评估数据、人工策划的评估数据、生产数据以及历史数据。
3. 定义评估指标. 您将如何检查是否满足成功标准？
4. 运行并比较评估结果. 迭代并改进您的任务或系统的模型性能。
5. 持续评估. 建立持续评估 (CE) 以在每次更改时运行评估，监控您的应用以识别新的非确定性情况，并随着时间的推移扩充评估集。

让我们来看几个示例。

示例：总结文本记录

为了测试基于 LLM 的应用程序总结文本的能力，你的评估设计可以是：

1. 定义评估目标
   模型在相关性和准确性方面应能与参考摘要相媲美。
2. 收集数据集
   结合使用生产数据（从生成摘要的用户反馈中收集）和由领域专家（作者）创建的数据集，以界定什么是“优秀”的摘要。
3. 定义评估指标
   在包含 1000 个参考记录文本 → 摘要的保留测试集上，该实现应达到至少 0.40 的 ROUGE-L 分数，且使用 G-Eval 的一致性得分至少为 80%。
4. 运行并比较评估结果
   使用 Evals API 以便在 OpenAI 仪表板中创建和运行评估。
5. 持续评估
   设置持续评估 (CE) 以便在每次更改时运行评估，监控你的应用以识别新的不确定性情况，并随着时间推移不断扩充评估集。

示例：基于文档的 Q&A

为了测试基于 LLM 的应用程序处理基于文档的 Q&A 的能力，你的评估设计可以是：

1. 定义评估目标
   模型应能够提供精确的答案，根据需要调用上下文来推理用户的提示，并提供满足用户需求的答案。
2. 收集数据集
   混合使用生产数据（收集自用户对其所获答案的满意度）、由领域专家编写的硬编码正确答案，以及来自日志的历史数据。
3. 定义评估指标
   上下文召回率至少为 0.85，上下文精确率超过 0.7，且 70% 以上的答案获得正面评价。
4. 运行并比较评估结果
   使用 Evals API 以便在 OpenAI 仪表板中创建和运行评估。
5. 持续评估
   设置持续评估 (CE) 以便在每次更改时运行评估，监控你的应用以识别新的不确定性情况，并随着时间推移不断扩充评估集。

确定需要评估的位置

随着你从简单架构向更复杂的架构演进，复杂性也会随之增加。以下是四种常见的架构模式：

• 单轮模型交互
• 工作流
• 单智能体
• 多智能体

阅读以下每种架构，以识别非确定性在何处进入您的系统。那就是您需要实施评估的地方。

单轮模型交互

在这种架构中，用户向模型提供输入，模型处理这些输入（以及提供的任何开发者提示）以生成相应的输出。

示例

举个例子，考虑一个在线零售场景。您的系统提示指示模型将 客户的问题进行分类 归入以下类别之一：

• order_status
• return_policy
• technical_issue
• cancel_order
• other

为确保一致、高效的用户体验，模型应 仅返回与用户意图匹配的标签. 假设客户问：“我的订单状态是什么？”

工作流架构

随着您试图解决更复杂的问题，您可能会从单轮模型交互过渡到将多个模型调用串联在一起的多步工作流。工作流不会引入任何新的非确定性元素，但它们涉及多个底层模型交互，您可以对这些交互进行单独评估。

示例

沿用前面的例子，客户询问其订单状态。工作流架构对客户请求进行分流，并通过一个分步过程对其进行路由：

1. 提取订单 ID
2. 查询订单详情
3. 将订单详情提供给模型以生成最终响应

此工作流中的每个步骤都有自己的系统提示，模型必须遵循这些提示，将所有获取的数据转化为友好的输出。

单智能体架构

与工作流不同，智能体解决的是需要灵活决策的非结构化问题。智能体拥有指令和一组工具，并动态选择要使用的工具。这引入了产生非确定性的新可能。

示例

让我们调整客户服务示例以使用单个智能体。该智能体可以访问三个不同的工具：

• 订单查询工具
• 密码重置工具
• 产品常见问题解答工具

当客户询问其订单状态时，智能体会动态决定是调用工具还是直接响应客户。例如，如果客户问“我的订单状态是什么？”，智能体现在可以通过向客户询问订单 ID 来进行追问。这有助于创造更自然的用户体验。

多智能体架构

随着您在单智能体架构中添加更多的工具和任务，模型可能会在遵循指令或选择要调用的正确工具方面遇到困难。多智能体架构通过创建多个擅长不同领域的专业智能体来解决这一问题。这种在多个智能体之间的分流和交接引入了产生非确定性的新可能。

示例

将单智能体示例拆分为多智能体架构，我们将拥有四个不同的智能体：

1. 分流智能体
2. 订单智能体
3. 账户管理智能体
4. 销售智能体

当客户询问其订单状态时，分流智能体可能会将对话移交给订单智能体以查询订单。如果客户改变话题询问有关产品的问题，订单智能体应将请求交还给分流智能体，然后由分流智能体移交给销售智能体以获取产品信息。

创建和组合不同类型的评估器

在设计自己的评估时，有几种特定的评估器类型可供选择。换一种思路，也就是考虑你希望评估器扮演什么角色。

基于指标的评估

定量评估提供一个数值分数，可用于对结果进行过滤和排名。它们为自动化回归测试提供了有用的基准。

• 示例: 精确匹配、字符串匹配、ROUGE/BLEU 评分、函数调用准确率、可执行评估（通过执行来评估功能或行为——例如 text2sql）
• 挑战: 可能无法针对特定用例进行定制，可能会遗漏细微差别

人工评估

人工判断评估提供的质量最高，但速度慢且成本高。

• 示例: 浏览系统输出以了解它们看起来更好还是更糟；创建一个随机、盲测的测试，让员工、承包商或外包标注机构评判系统输出的质量（例如，对一小部分可能的输出进行排名，或给每个输出打 1-5 分）
• 挑战: 人类专家之间的意见分歧，成本高，速度慢
• 推荐:
  • 进行多轮详细的人工审查以完善评分标准
  • 实施“展示而非告知”的策略，提供不同分数级别的示例（例如，10 分制中的 1、3 和 8 分）
  • 除了数值分数外，还包括通过/未通过的阈值
  • 汇总多位评审员意见的一种简单方法是采用共识投票

LLM 裁判和模型评分器

使用模型来判断输出比人工评估运行成本更低、可扩展性更强。像 GPT-4.1 这样强大的 LLM 裁判能够匹配受控和众包的人工偏好，达成超过 80% 的一致率（与人类之间的一致水平相同）。

• 示例:
  • 成对比较：向裁判模型展示两个回答，并要求其根据特定标准判断哪个更好
  • 单答案评分：裁判模型单独评估单个回答，根据预定义的质量指标给出分数或评级
  • 参考引导评分：为裁判模型提供参考或“黄金标准”答案，作为评估给定回答的基准
• 挑战: 位置偏差（响应顺序），冗长偏差（偏好较长的响应）
• 推荐:
  • 使用成对比较或通过/未通过判定以获得更高的可靠性
  • 如果条件允许，请使用能力最强的模型进行评分（例如 o3）——o 系列模型在根据评分标准或专家参考答案集合进行自动评分方面表现出色
  • 控制回复长度，因为 LLM 通常偏向于较长的回复
  • 在评分前加入推理和思维链，因为这能提升评估表现
  • 一旦 LLM 裁判变得更快、更便宜，且与人工标注持续保持一致，就可以扩大其应用规模
  • 构建问题结构以实现自动评分，同时保持任务的完整性——一种常见的方法是将问题重新格式化为多项选择题
  • 确保评估标准清晰明确

没有任何策略是完美的。LLM 裁判的质量会因问题的上下文而异，而使用专家人工标注者提供真实标签则既昂贵又耗时。

处理边缘情况

虽然你的评估应该涵盖每种架构的主要理想路径场景，但现实世界中的 AI 系统经常会遇到挑战系统性能的边缘情况。评估这些边缘情况对于确保可靠性和良好的用户体验至关重要。

我们发现这些边缘情况可以分为以下几类：

输入多样性

由于用户向模型提供输入，我们的系统必须足够灵活以应对用户可能与我们互动的各种方式，例如：

• 非英语或多语言输入
• 文本之外的输入格式（例如 XML、JSON、Markdown、CSV）
• 输入模态（例如图像）

你对指令遵循和功能正确性的评估需要适应用户可能尝试的输入。

上下文复杂性

许多基于 LLM 的应用程序由于对请求上下文理解不佳而失败。这种上下文可能来自用户，也可能是历史对话记录中的噪音。

示例包括：

• 单个请求中包含多个问题或意图
• 拼写错误和错别字
• 缺乏上下文的简短请求（例如，用户只说：“退货”）
• 长上下文或持久的对话
• 返回数据包含不明确属性名称的工具调用（例如， "on: 123"，其中“on”是订单号)
• 多次工具调用，有时会导致参数错误
• 多次智能体移交，有时会导致循环移交

个性化和定制化

虽然 AI 通过适应特定的用户请求改善了用户体验，但这种灵活性也引入了许多边缘情况。请为你希望专门支持的使用场景明确定义评估，并阻止某些情况：

• 试图让模型执行不同操作的越狱尝试
• 格式化请求（例如，格式化为 JSON，或使用项目符号）
• 用户提示与你的系统提示冲突的情况

使用评估来提升性能

当你的评估达到能够持续衡量性能的成熟度时，请转向使用评估数据来提升应用程序的性能。

了解更多 强化微调 以创建数据飞轮。

其他资源

获取更多灵感，请访问 OpenAI Cookbook，其中包含示例代码和第三方资源链接，或者了解更多关于我们的评估工具的信息：

• 评估模型性能
• 如何评估摘要任务
• 微调
• 评分器
• Evals API 参考