OpenAI 评测最佳实践

生成式 AI 具有变化性，同样的输入有时会产生不同输出，传统软件测试因此不足以验证 AI 架构。评测（evals）是在这种变化性下测试系统的方法。

本指南介绍评测设计原则。Evals API入门操作见评测模型表现。

OpenAI 正弃用 Evals 平台。既有内容在过渡期内仍可访问；官方时间表列明既有用户自2026年10月31日起进入只读状态，平台计划于2026年11月30日关闭。详见弃用时间表。

什么是评测

评测是衡量模型表现的结构化测试，用于在非确定性系统中检验准确性、表现和可靠性，也为通过微调改进 LLM 应用提供依据。

评测的类型

“评测”可能指：

• 单独比较模型的行业基准，例如 MMLU和 Hugging Face 榜单中的基准。
• 设计业务评测时使用的标准数值指标，如 ROUGE和 BERTScore。
• 为自己的 LLM 应用实现的具体测试。

本指南讨论第三类。

如何理解评测结果

评测分数常在0到1之间，但分数不是全部。要结合指标与人工判断，确认测试回答了真正需要回答的问题。

有效做法包括：尽早、频繁地评测，在各阶段编写范围明确的测试；面向具体任务和真实数据分布；开发时持续记录日志，从中提取案例；尽量采用可自动评分的结构；将评测视为持续过程；用人工反馈校准自动评分。

应避免只依赖困惑度或 BLEU 等过于通用的学术指标；评测数据偏离生产流量；仅凭“看起来能用”判断或上线后才开始测试；忽视人工反馈，未校准自动指标。

设计评测流程

1. 明确目标：成功标准是什么？
2. 收集数据：哪些数据能检验目标？可使用合成、领域专用、采购、人工整理、生产及历史数据。
3. 定义指标：怎样判断满足成功标准？
4. 运行并比较：持续迭代任务或系统表现。
5. 持续评测：对每次变更运行测试，监控新出现的非确定性案例，并扩充数据集。

示例：转录文本摘要

1. 目标：摘要在相关性与准确性上应能与参考摘要竞争。
2. 数据：结合生产反馈（用户对摘要的评价）和领域专家、写作者制作的优质样例。
3. 指标：来源示例要求在留出的1000组“转录文本→参考摘要”上，ROUGE-L至少0.40，G-Eval连贯性至少80%。这些是该示例阈值，不是通用合格线。
4. 运行：通过 Evals API在控制台建立和执行评测。
5. 持续：每次变更执行，监控新案例并扩充测试。

LLM 较擅长区分选项，因此优先考虑成对比较、分类、按明确标准评分，而非开放式生成。利用这种比较能力，有利于提高输出评估或模型比较的可靠性。

示例：文档问答

1. 目标：准确回答，按需召回上下文进行推理，并满足用户需求。
2. 数据：结合生产中的回答满意度反馈、专家编写的问题和标准答案、历史日志。
3. 指标：示例要求上下文召回率至少0.85、精确率大于0.7，得到正向评价的答案超过70%。
4. 使用 Evals API 运行并比较。
5. 每次变更执行持续评测，并加入新案例。

创建数据集时，可用gpt-6-astra辅助生成多场景样例及边界案例；测试应覆盖典型、边界和对抗情况，并由人工专家标注。

识别需要评测的位置

架构从简单到复杂时，评测也要覆盖更多环节。常见类型包括单轮交互、工作流、单智能体和多智能体。重点找出非确定性进入系统的位置。

单轮模型交互

用户提供输入，模型结合开发者提示词生成输出。

示例

在线零售系统要求将客户问题分为order_status（订单状态）、return_policy（退货政策）、technical_issue（技术问题）、cancel_order（取消订单）或other（其他），且只返回符合意图的标签。例如客户问“我的订单现在是什么状态？”

工作流架构

更复杂的问题可拆成多个模型调用组成的固定步骤。工作流并未引入新的非确定性类型，但每个底层交互都可单独评测。

示例

订单查询可拆为：提取订单ID、查询详情、把详情交给模型生成最终回答。每步有自己的系统提示词，最终将取得的数据组织成友好回复。

单智能体架构

智能体通过灵活决策解决非结构化问题。它有指令和工具集，并动态决定调用哪个工具，这增加了非确定性。工具是开发者定义的代码，可从小辅助函数到现有服务 API；例如check_order_status(order_id)接收订单ID并调用查询 API。

示例

为客服智能体提供订单查询、密码重置、产品常见问题三种工具。客户询问订单状态时，智能体可以选择调用工具或先回复，例如追问订单ID，使体验更自然。

多智能体架构

单智能体增加过多工具和任务后，可能难以遵循指令或正确选工具。多智能体将职责交给不同专家，但分流与交接也引入新的非确定性。是否采用这种架构应由评测决定；一开始就引入会增加不必要的复杂度，拖慢上线。

示例

将系统拆成分流、订单、账户管理和销售四个智能体。询问订单时由分流交给订单智能体；用户转问产品后，订单智能体应交回分流，再转给销售。

创建并组合不同评估器

可按评估器在系统中承担的角色选择类型。

基于指标的评测

定量分数便于筛选、排序，也是自动回归测试的基准。例子包括精确匹配、字符串匹配、ROUGE/BLEU、函数调用准确率，以及执行代码来验证行为（如 text2sql）。缺点是可能不够贴合用例，也可能遗漏细节。

人工评测

人工判断质量较高，但慢且昂贵。可先浏览输出判断好坏，也可组织随机、盲测，让员工、承包方或标注机构排序多个答案，或按1至5分评分。专家间也可能存在分歧。

建议多轮详细复核以完善评分表；提供不同分档的实际样例（如满分10分中的1、3、8分）；数值评分之外再设通过阈值；多人结果可采用共识投票。

以 LLM 为裁判与模型评分器

模型评分比人工便宜、易扩展。需要强评判模型时，可从gpt-6-astra开始，再验证与人工标注的一致性，之后才优化费用和延迟。

可采用成对比较、单答案独立评分，或给参考标准答案作对照。常见偏差包括位置偏差（回答顺序）和长度偏差（偏好较长回答）。

建议：

• 优先使用成对比较或通过/失败判断。
• 条件允许时用能力较强的模型；以GPT-6 Astra为起点，验证专用推理模型对当前评分规则或参考集是否更好。
• 控制回答长度，避免长答案占优。
• 来源建议在评分前加入推理过程，以改善评分表现。
• 只有当模型裁判更快、更便宜且持续与人工一致后，再扩大规模。
• 将问题设计成可自动评分的形式，例如多项选择，同时保持任务本质。
• 保证评分规则清晰、详细。

没有完美策略：LLM裁判质量取决于任务情境，专家标准答案则成本高、耗时长。

处理边界情况

除正常成功路径，还要评测真实系统常见的边界案例，以检验可靠性与用户体验。

输入多样性

覆盖非英语或多语言输入、XML/JSON/Markdown/CSV等格式，以及图像等其他输入模态。指令遵循和功能正确性评测应包含用户实际可能尝试的输入。

上下文复杂性

许多失败源于误解用户上下文或历史噪声，例如：单次请求多个问题或意图；拼写错误；只说“退货”等极少上下文的短请求；长上下文或长对话；工具字段含义模糊（如"on: 123"中on表示订单号）；多次工具调用造成参数混淆；多次交接形成循环。

个性化与定制

适应用户要求也增加边界情况。明确哪些行为应支持、哪些应阻止，包括越狱尝试、JSON或列表等格式要求，以及用户提示词与系统提示词冲突的情况。

使用评测改进表现

评测成熟到能稳定衡量表现后，可利用评测数据改善应用。

其他资源

• OpenAI Cookbook。
• 评测模型表现。
• 评测摘要任务。
• 微调与模型优化。
• 评分器。
• Evals API 参考。