Back to latest
OpenAI2026/7/8AI 中文译文 · 待人工复核

在编程评测中分离信号与噪声

英文标题:Separating signal from noise in coding evaluations

OpenAI 审计发现 SWE-Bench Pro 编程基准测试中约 30% 的任务存在缺陷,导致评测结果不可靠。

跳到主要内容

登录试用 ChatGPT(在新窗口打开)

在编程评测中分离信号与噪声 | OpenAI

2026年7月8日

研究出版物

在编程评测中分离信号与噪声

通过一次详细的审计,我们发现 SWE-Bench Pro 中存在广泛的任务问题,并估计约有 30% 的任务是有缺陷的。

收听文章7:06

分享

方法论

准确衡量我们模型的能力,对于做出合理的部署和安全决策至关重要,包括 OpenAI 的 准备框架(在新窗口打开) 下的决策。每次发布新模型时,我们都会报告各种外部和内部基准测试的结果,以追踪模型的进展。当评测存在影响结果的缺陷时,它们可能会让我们对能力产生错误的理解,错误地描述安全状况,并影响研究重点。

我们最近调查了 最广泛使用的编程基准测试之一——SWE-bench Verified,发现它存在根本性的设计和污染问题,并且该评测不再能提供关于软件开发能力的有意义信号。当时,我们鼓励更广泛的社区转向使用 SWE-Bench Pro。

SWE-Bench Pro(在新窗口打开) 旨在改进 SWE-bench Verified,通过在更长的时间范围和更真实的编程任务上测试模型,来更好地追踪智能体编程能力。与 SWE-bench Verified 一样,任务是从一组公共和私有仓库的功能变更历史中通过程序化方式获取的。模型需要实现一个解决方案,使其能够通过针对新功能的测试,同时不破坏现有功能。在包含 731 个任务的公开子集中,前沿模型在八个月内通过率从 23.3% 提高到了 80.3%。

此后,我们对 SWE-Bench Pro 进行了类似的审计,使用一个数据点分析流程来审查数据集。该流程审查了模型对任务的尝试、任务元数据和失败轨迹,以标记可能的评测缺陷。每个被标记的任务随后通过多次调查智能体(investigator-agent)的审查进行评估,并由五位经验丰富的软件工程师独立复核,存在分歧的情况会升级进行进一步调查。

按问题类型标记的数据集比例

过于严格的测试低覆盖率的测试误导性的提示其他问题规定不明确的提示0%5%10%15%20%占总数据集的百分比14.4%17.8%4.1%9.4%6.3%7.5%1.9%1.2%0.6%0.8%人工监督的智能体审查人工标注

我们发现数据集中有相当一部分任务存在严重问题。我们的数据点分析流程标记了 200 个(27.4%)有缺陷的任务,而人工标注活动则识别出 249 个(34.1%)。

这些问题主要分为四类:

  • 过于严格的测试1 强制要求了提示中未指定的具体实现细节,导致许多功能正确的提交被判定为无效。
  • 规定不明确的提示2 遗漏了隐藏测试所强制要求且无法合理推断出的需求。
  • 低覆盖率的测试 对请求的功能检查不足,因此不完整的修复也能通过。
  • 误导性的提示 引导模型走向错误的行为,或者与测试的要求相矛盾。

我们的发现指出了策划困难但公平的基准测试的难度,以及智能体在可扩展的数据质量检查中日益增长的实用性。基于这些结果,我们估计 SWE-Bench Pro 中约有 30% 的任务是有缺陷的,并建议模型开发者仔细检查结果。

方法论

我们的目标是确保任务失败能反映模型的真实局限性,而任务成功则代表对提示要求的完整且有效的解决方案。为了检查评测中使用的数据质量,我们创建了一个质量保证流程,以评估每个数据点是否准确反映了模型的能力。

结合自动化筛选和人工审查来评估任务质量的质量保证工作流程。

一个初始的数据质量流程会标记问题以供审查。我们通过更深入的智能体辅助审计(针对被标记的任务)和与经验丰富的工程师合作进行的人工标注活动来验证。

一个初始的自动化过滤器会审查给模型的指令、模型解决任务的尝试,以及用于评分的测试,以标记可能有问题或存在缺陷的示例。这个过滤器标记了 286 个可能有缺陷的任务。然后,我们通过两种方式对该子集进行了更深入的审查:一种是人工监督的智能体审查,它使用调查智能体进行广泛检查,并做出最终的人工判断;另一种是与经验丰富的软件开发人员合作进行的人工标注活动。

人工监督的智能体审查

每个被标记的问题都会使用基于 Codex 的调查智能体进行审计,这些智能体可以访问任务仓库和环境。这有助于他们区分合理的任务歧义(通常可以通过研究附近的代码和仓库约定来解决)和真正的不明确性。智能体可以运行测试、检查仓库中的文件,并调查模型在任务上的尝试及其常见的失败模式。在多次独立重复这些更深入的审计之后,一位研究人员审查了摘要,做出最终判断,并标记出可能的问题。

人工标注活动

与此同时,我们对被标记的子集进行了一次人工标注活动。我们与经验丰富的软件工程师合作,他们在审查任务之前接受了关于基准测试目标、问题分类和边缘情况的培训。每个任务由五位工程师审查。

审查员在查看可见的问题陈述、测试用例和真实参考解决方案(称为 gold patch)后,形成独立判断,然后再使用流程分析或记录作为辅助背景信息。然后,审查员根据具体证据分配标签和严重性评级,并将分歧或低置信度的案例升级以进行进一步审查。

与调查智能体相比,人工审查员更倾向于将任务标记为有缺陷。两种审查路径在分类上也存在一些分歧,但在被标记的任务中,“没有缺陷”从未成为最常见的人工标签。在智能体流程标记的类别中,审查员的判断在 74% 的情况下是重叠的。

与智能体流程相比,人工审查员也更倾向于为一个任务选择多个标签,这表明他们认为任务存在多种缺陷,或者不能干净地归入单一类别。这表明智能体加审查员的流程导致了保守的标记:它捕捉到了人类识别出的相同的主要失败模式,同时低估了审查员看到额外或重叠问题的情况。最大的差异在于低覆盖率的测试,人类将其选为基准测试中最常见的问题,占 9.4%,而智能体流程仅为 4.1%。

失败模式

误导性的提示过于严格的测试规定不明确的提示低覆盖率的测试

在一些案例中,任务提示规定了具体的实现方式,但隐藏的测试用例却期望不同的行为。

OpenLibrary-77c16d5

这个任务涉及规范化目录条目,并通过 TocEntry.to_markdown() 将它们渲染回 Markdown 格式。任务提示详细说明了序列化到字符级别的间距,描述了如何强制执行精确的间距和竖线,并给出了诸如 " | Chapter 1 | 1""** | Chapter 1 | 1" 的例子:

`1

"[space]| Chapter 1 | 1"

2

"**[space]| Chapter 1 | 1"

3

"[space]| Just title | "

`

而隐藏的 test_to_markdown 断言却要求 " | Chapter 1 | 1""** | Chapter 1 | 1"

`1

"[space][space]| Chapter 1 | 1"

2

"**[space][space]| Chapter 1 | 1"

3

"[space][space]| Just title | "

`

隐藏测试中有两个前导空格,但给模型的例子中只有一个前导空格。如果模型正确地遵循了给定的提示,这一个字符的差异就会导致隐藏测试用例失败,任务就会被标记为不正确。

讨论

我们识别出的问题,加上 SWE-bench Verified 中的类似案例,突显了严格检查基准测试的重要性。来自开源仓库的问题和拉取请求最初是为了人类协作而创建的,通常通过维护者和贡献者之间长时间的来回沟通。因此,问题描述、合并的代码和单元测试并不总是能对齐,形成干净、独立的任务来可靠地评估模型。特别是,拉取请求中包含的测试可能过于严格,因为它们是为了验证特定的更改而编写的,而不是为了定义一个与实现无关的标准来解决任务。

与此同时,评测缺陷现在比不久之前更容易检测到。随着模型能力的提升,我们可以利用这些模型以更深入和更一致的方式检查提示、测试、补丁、轨迹和边缘情况,这有助于发现以前大规模发现成本高昂或不切实际的基准测试问题。

我们希望更广泛的评测社区能够开发出由经验丰富的软件开发人员专门为测试模型能力而构建的新基准测试。这种方法可以保持我们想要衡量模型能力的高标准和现实性,并允许在整个过程中进行更好的人工监督。鉴于本分析中发现的问题,我们撤回之前关于采用 SWE-Bench Pro 的建议。

最终,一个评测应该通过难以被操纵、易于信任且真正反映模型能力或对齐的基准测试来提供有意义的信号。由于这些结果会影响 OpenAI 的部署和安全决策,我们追踪的评测必须是有效且信息丰富的。

作者

OpenAI

脚注

  1. 1
    我们之前 将此类问题称为“狭窄测试”。
  2. 2
    我们之前将此类问题称为“宽泛测试”。

继续阅读

查看全部

介绍 GeneBench-Pro > 封面图片

介绍 GeneBench-Pro研究2026年6月30日

一个近乎自主的 AI 化学家改进了一个具有挑战性的反应

一个近乎自主的 AI 化学家改进了药物化学中的一个具有挑战性的反应研究2026年6月17日

LifeSciBench 1x1

介绍 LifeSciBench研究2026年6月17日

研究

最新进展

安全

产品

API 平台

商业

开发者

公司

支持

更多

条款与政策

(在新窗口打开)(在新窗口打开)(在新窗口打开)(在新窗口打开)(在新窗口打开)(在新窗口打开)(在新窗口打开)

OpenAI © 2015–2026您的隐私选择

英语美国

阅读英文原文

Markdown / MDX 原稿

包含 frontmatter、中文正文和英文来源链接,可直接复制或保存为 .md 分发。

查看原稿下载 .md
在页面中展开原始 Markdown
---
title: "在编程评测中分离信号与噪声"
title_en: "Separating signal from noise in coding evaluations"
source: "OpenAI"
source_url: "https://openai.com/index/separating-signal-from-noise-coding-evaluations"
published_at: "2026-07-08T13:00:00.000Z"
language: "zh-CN"
topics: ["openai"]
tags: ["OpenAI","Research"]
review_status: "unreviewed"
---

# 在编程评测中分离信号与噪声

> OpenAI 审计发现 SWE-Bench Pro 编程基准测试中约 30% 的任务存在缺陷,导致评测结果不可靠。

## 内容摘要

OpenAI 对广泛使用的编程基准测试 SWE-Bench Pro 进行了详细审计,发现约 30% 的任务存在缺陷,包括过于严格的测试、规定不明确的提示、低覆盖率的测试和误导性的提示。这些问题导致模型能力被错误评估,影响部署和安全决策。OpenAI 因此撤回之前推荐使用 SWE-Bench Pro 的建议,并呼吁社区开发更高质量的基准测试。

## 为什么值得关注

如果编程基准测试有缺陷,AI 模型的能力可能被高估或低估,导致不安全的部署决策。这就像用有问题的考试来评判学生,成绩无法反映真实水平。

## 核心要点

- OpenAI 审计发现 SWE-Bench Pro 中约 30% 的任务有缺陷。
- 主要问题包括过于严格的测试、规定不明确的提示、低覆盖率的测试和误导性的提示。
- 有缺陷的评测可能导致对模型能力的错误理解,影响安全决策。
- OpenAI 撤回之前推荐使用 SWE-Bench Pro 的建议。
- 呼吁社区开发由专家构建的高质量基准测试。

[跳到主要内容](#main)

* [研究](https://openai.com/research/index/)
* 产品
* [商业](https://openai.com/business/)
* [开发者](https://openai.com/api/)
* [公司](https://openai.com/about/)
* [基金会(在新窗口打开)](https://openaifoundation.org/)

登录[试用 ChatGPT(在新窗口打开)](https://chatgpt.com/?openaicom-did=0a4655c1-fba5-4de7-a263-24cfa06d4e8c&openaicom%5Freferred=true)

* 研究
* 产品
* 商业
* 开发者
* 公司
* [基金会(在新窗口打开)](https://openaifoundation.org/)

在编程评测中分离信号与噪声 | OpenAI

2026年7月8日

[研究](https://openai.com/news/research/)[出版物](https://openai.com/research/index/publication/)

# 在编程评测中分离信号与噪声

通过一次详细的审计,我们发现 SWE-Bench Pro 中存在广泛的任务问题,并估计约有 30% 的任务是有缺陷的。

收听文章7:06

分享

方法论

* [方法论](#methodology)
* [人工监督的智能体审查](#human-supervised-agent-review)
* [人工标注活动](#human-annotation-campaign)
* [讨论](#discussion)

* [方法论](#methodology)
* [人工监督的智能体审查](#human-supervised-agent-review)
* [人工标注活动](#human-annotation-campaign)
* [讨论](#discussion)

准确衡量我们模型的能力,对于做出合理的部署和安全决策至关重要,包括 OpenAI 的 [准备框架(在新窗口打开)](https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf) 下的决策。每次发布新模型时,我们都会报告各种外部和内部基准测试的结果,以追踪模型的进展。当评测存在影响结果的缺陷时,它们可能会让我们对能力产生错误的理解,错误地描述安全状况,并影响研究重点。

我们[最近调查了](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/) 最广泛使用的编程基准测试之一——SWE-bench Verified,发现它存在根本性的设计和污染问题,并且该评测不再能提供关于软件开发能力的有意义信号。当时,我们鼓励更广泛的社区转向使用 SWE-Bench Pro。

[SWE-Bench Pro(在新窗口打开)](https://scale.com/blog/swe-bench-pro) 旨在改进 SWE-bench Verified,通过在更长的时间范围和更真实的编程任务上测试模型,来更好地追踪智能体编程能力。与 SWE-bench Verified 一样,任务是从一组公共和私有仓库的功能变更历史中通过程序化方式获取的。模型需要实现一个解决方案,使其能够通过针对新功能的测试,同时不破坏现有功能。在包含 731 个任务的公开子集中,前沿模型在八个月内通过率从 23.3% 提高到了 80.3%。

此后,我们对 SWE-Bench Pro 进行了类似的审计,使用一个数据点分析流程来审查数据集。该流程审查了模型对任务的尝试、任务元数据和失败轨迹,以标记可能的评测缺陷。每个被标记的任务随后通过多次调查智能体(investigator-agent)的审查进行评估,并由五位经验丰富的软件工程师独立复核,存在分歧的情况会升级进行进一步调查。

按问题类型标记的数据集比例

过于严格的测试低覆盖率的测试误导性的提示其他问题规定不明确的提示0%5%10%15%20%占总数据集的百分比14.4%17.8%4.1%9.4%6.3%7.5%1.9%1.2%0.6%0.8%人工监督的智能体审查人工标注

我们发现数据集中有相当一部分任务存在严重问题。我们的数据点分析流程标记了 200 个(27.4%)有缺陷的任务,而人工标注活动则识别出 249 个(34.1%)。

这些问题主要分为四类:

* **过于严格的测试**[1](#citation-bottom-1) 强制要求了提示中未指定的具体实现细节,导致许多功能正确的提交被判定为无效。
* **规定不明确的提示**[2](#citation-bottom-2) 遗漏了隐藏测试所强制要求且无法合理推断出的需求。
* **低覆盖率的测试** 对请求的功能检查不足,因此不完整的修复也能通过。
* **误导性的提示** 引导模型走向错误的行为,或者与测试的要求相矛盾。

我们的发现指出了策划困难但公平的基准测试的难度,以及智能体在可扩展的数据质量检查中日益增长的实用性。基于这些结果,我们估计 SWE-Bench Pro 中约有 30% 的任务是有缺陷的,并建议模型开发者仔细检查结果。

## 方法论

我们的目标是确保任务失败能反映模型的真实局限性,而任务成功则代表对提示要求的完整且有效的解决方案。为了检查评测中使用的数据质量,我们创建了一个质量保证流程,以评估每个数据点是否准确反映了模型的能力。

![结合自动化筛选和人工审查来评估任务质量的质量保证工作流程。](https://images.ctfassets.net/kftzwdyauwt9/4uTrAMFq4ZJu9wXWZ9gifK/44cf7007c7a81c4bb6214d0cab6a3221/Quality_assurance_pipeline_desktop_light.svg?w=3840&q=90)

一个初始的数据质量流程会标记问题以供审查。我们通过更深入的智能体辅助审计(针对被标记的任务)和与经验丰富的工程师合作进行的人工标注活动来验证。

一个初始的自动化过滤器会审查给模型的指令、模型解决任务的尝试,以及用于评分的测试,以标记可能有问题或存在缺陷的示例。这个过滤器标记了 286 个可能有缺陷的任务。然后,我们通过两种方式对该子集进行了更深入的审查:一种是人工监督的智能体审查,它使用调查智能体进行广泛检查,并做出最终的人工判断;另一种是与经验丰富的软件开发人员合作进行的人工标注活动。

## 人工监督的智能体审查

每个被标记的问题都会使用基于 Codex 的调查智能体进行审计,这些智能体可以访问任务仓库和环境。这有助于他们区分合理的任务歧义(通常可以通过研究附近的代码和仓库约定来解决)和真正的不明确性。智能体可以运行测试、检查仓库中的文件,并调查模型在任务上的尝试及其常见的失败模式。在多次独立重复这些更深入的审计之后,一位研究人员审查了摘要,做出最终判断,并标记出可能的问题。

## 人工标注活动

与此同时,我们对被标记的子集进行了一次人工标注活动。我们与经验丰富的软件工程师合作,他们在审查任务之前接受了关于基准测试目标、问题分类和边缘情况的培训。每个任务由五位工程师审查。

审查员在查看可见的问题陈述、测试用例和真实参考解决方案(称为 gold patch)后,形成独立判断,然后再使用流程分析或记录作为辅助背景信息。然后,审查员根据具体证据分配标签和严重性评级,并将分歧或低置信度的案例升级以进行进一步审查。

与调查智能体相比,人工审查员更倾向于将任务标记为有缺陷。两种审查路径在分类上也存在一些分歧,但在被标记的任务中,“没有缺陷”从未成为最常见的人工标签。在智能体流程标记的类别中,审查员的判断在 74% 的情况下是重叠的。

与智能体流程相比,人工审查员也更倾向于为一个任务选择多个标签,这表明他们认为任务存在多种缺陷,或者不能干净地归入单一类别。这表明智能体加审查员的流程导致了保守的标记:它捕捉到了人类识别出的相同的主要失败模式,同时低估了审查员看到额外或重叠问题的情况。最大的差异在于低覆盖率的测试,人类将其选为基准测试中最常见的问题,占 9.4%,而智能体流程仅为 4.1%。

### 失败模式

误导性的提示过于严格的测试规定不明确的提示低覆盖率的测试

在一些案例中,任务提示规定了具体的实现方式,但隐藏的测试用例却期望不同的行为。

## OpenLibrary-77c16d5

这个任务涉及规范化目录条目,并通过 `TocEntry.to_markdown()` 将它们渲染回 Markdown 格式。任务提示详细说明了序列化到字符级别的间距,描述了如何强制执行精确的间距和竖线,并给出了诸如 `" | Chapter 1 | 1"` 和 `"** | Chapter 1 | 1"` 的例子:

#### 无

`1

"[space]| Chapter 1 | 1"

2

"**[space]| Chapter 1 | 1"

3

"[space]| Just title | "

`

而隐藏的 `test_to_markdown` 断言却要求 `" | Chapter 1 | 1"` 和 `"** | Chapter 1 | 1"`:

#### 无

`1

"[space][space]| Chapter 1 | 1"

2

"**[space][space]| Chapter 1 | 1"

3

"[space][space]| Just title | "

`

隐藏测试中有两个前导空格,但给模型的例子中只有一个前导空格。如果模型正确地遵循了给定的提示,这一个字符的差异就会导致隐藏测试用例失败,任务就会被标记为不正确。

## 讨论

我们识别出的问题,加上 [SWE-bench Verified](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/) 中的类似案例,突显了严格检查基准测试的重要性。来自开源仓库的问题和拉取请求最初是为了人类协作而创建的,通常通过维护者和贡献者之间长时间的来回沟通。因此,问题描述、合并的代码和单元测试并不总是能对齐,形成干净、独立的任务来可靠地评估模型。特别是,拉取请求中包含的测试可能过于严格,因为它们是为了验证特定的更改而编写的,而不是为了定义一个与实现无关的标准来解决任务。

与此同时,评测缺陷现在比不久之前更容易检测到。随着模型能力的提升,我们可以利用这些模型以更深入和更一致的方式检查提示、测试、补丁、轨迹和边缘情况,这有助于发现以前大规模发现成本高昂或不切实际的基准测试问题。

我们希望更广泛的评测社区能够开发出由经验丰富的软件开发人员专门为测试模型能力而构建的新基准测试。这种方法可以保持我们想要衡量模型能力的高标准和现实性,并允许在整个过程中进行更好的人工监督。鉴于本分析中发现的问题,我们撤回之前关于采用 SWE-Bench Pro 的建议。

最终,一个评测应该通过难以被操纵、易于信任且真正反映模型能力或对齐的基准测试来提供有意义的信号。由于这些结果会影响 OpenAI 的部署和安全决策,我们追踪的评测必须是有效且信息丰富的。

* [2026](https://openai.com/news/?tags=2026)
* [软件与工程](https://openai.com/news/?tags=software-engineering)

## 作者

OpenAI

## 脚注

1. 1  
我们[之前](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/) 将此类问题称为“狭窄测试”。
2. 2  
我们之前将此类问题称为“宽泛测试”。

## 继续阅读

[查看全部](https://openai.com/news/)

![介绍 GeneBench-Pro > 封面图片](https://images.ctfassets.net/kftzwdyauwt9/7sbJaKBi5qLXAqbewh72aK/93197556e903eac9df6f077eb12b7581/GenebenchPro_Blog_ArtCard.png?w=3840&q=90&fm=webp)

[介绍 GeneBench-Pro研究2026年6月30日](https://openai.com/index/introducing-genebench-pro/)

![一个近乎自主的 AI 化学家改进了一个具有挑战性的反应](https://images.ctfassets.net/kftzwdyauwt9/QgPPg4etNE5C4Ao0G94sk/e5f2a50e5de4619d0e0fe8483698718b/molecule-one-art-card.png?w=3840&q=90&fm=webp)

[一个近乎自主的 AI 化学家改进了药物化学中的一个具有挑战性的反应研究2026年6月17日](https://openai.com/index/ai-chemist-improves-reaction/)

![LifeSciBench 1x1](https://images.ctfassets.net/kftzwdyauwt9/1iV0eZRf28MZRvIxYY4eLf/4379e20807f5ff44efccf518a97e480a/LifeSciBench_1x1.png?w=3840&q=90&fm=webp)

[介绍 LifeSciBench研究2026年6月17日](https://openai.com/index/introducing-life-sci-bench/)

研究
* [研究索引](https://openai.com/research/index/)
* [研究概览](https://openai.com/research/)
* [经济研究](https://openai.com/signals/)

最新进展
* [GPT-5.6](https://openai.com/index/gpt-5-6/)
* [GPT-5.5](https://openai.com/index/introducing-gpt-5-5/)
* [GPT-5.4](https://openai.com/index/introducing-gpt-5-4/)

安全
* [安全方法](https://openai.com/safety/)
* [部署安全(在新窗口打开)](https://deploymentsafety.openai.com/)
* [安全与隐私](https://openai.com/security-and-privacy/)
* [信任与透明度](https://openai.com/trust-and-transparency/)

产品
* [ChatGPT(在新窗口打开)](https://chatgpt.com/?openaicom-did=0a4655c1-fba5-4de7-a263-24cfa06d4e8c&openaicom%5Freferred=true)
* [ChatGPT 商业版(在新窗口打开)](https://chatgpt.com/business/?openaicom-did=0a4655c1-fba5-4de7-a263-24cfa06d4e8c&openaicom%5Freferred=true)
* [ChatGPT 企业版(在新窗口打开)](https://chatgpt.com/business/enterprise/?openaicom-did=0a4655c1-fba5-4de7-a263-24cfa06d4e8c&openaicom%5Freferred=true)
* [ChatGPT 教育版(在新窗口打开)](https://chatgpt.com/business/education/?openaicom-did=0a4655c1-fba5-4de7-a263-24cfa06d4e8c&openaicom%5Freferred=true)
* [Codex](https://openai.com/codex/)
* [发布说明](https://openai.com/products/release-notes/)

API 平台
* [概览](https://openai.com/api/)
* [API 登录(在新窗口打开)](https://platform.openai.com/login)
* [文档(在新窗口打开)](https://developers.openai.com/api/docs)

商业
* [概览](https://openai.com/business/)
* [解决方案](https://openai.com/solutions/)
* [资源](https://openai.com/business/learn/)
* [客户案例](https://openai.com/business/customer-stories/)
* [合作伙伴网络](https://openai.com/business/partners/)
* [联系销售](https://openai.com/contact-sales/)

开发者
* [应用 SDK(在新窗口打开)](https://developers.openai.com/apps-sdk)
* [开放模型](https://openai.com/open-models/)
* [文档(在新窗口打开)](https://developers.openai.com/)
* [资源(在新窗口打开)](https://developers.openai.com/learn)
* [开发者论坛(在新窗口打开)](https://community.openai.com/)

公司
* [关于我们](https://openai.com/about/)
* [我们的章程](https://openai.com/charter/)
* [职业机会](https://openai.com/careers/)
* [新闻](https://openai.com/news/)

支持
* [帮助中心(在新窗口打开)](https://help.openai.com/)

更多
* [故事](https://openai.com/stories/)
* [学院](https://openai.com/academy/)
* [直播](https://openai.com/live/)
* [播客](https://openai.com/podcast/)
* [RSS](https://openai.com/news/rss.xml)

条款与政策
* [使用条款](https://openai.com/policies/terms-of-use/)
* [隐私政策](https://openai.com/policies/privacy-policy/)
* [其他政策](https://openai.com/policies/)

[(在新窗口打开)](https://x.com/OpenAI)[(在新窗口打开)](https://www.youtube.com/OpenAI)[(在新窗口打开)](https://www.linkedin.com/company/openai)[(在新窗口打开)](https://github.com/openai)[(在新窗口打开)](https://www.instagram.com/openai/)[(在新窗口打开)](https://www.tiktok.com/@openai)[(在新窗口打开)](https://discord.gg/openai)

OpenAI © 2015–2026您的隐私选择

英语美国

![](https://bat.bing.com/action/0?ti=187204252&Ver=2&mid=02230c6b-0754-4053-9976-d4de69c35df6&bo=1&sid=b7beebb07dc411f1a327814e359ce76a&vid=b7bf90607dc411f18688411d9d9661f9&vids=1&msclkid=N&pi=918639831&lg=en-US&sw=800&sh=600&sc=24&nwd=1&tl=Separating%20signal%20from%20noise%20in%20coding%20evaluations%20%7C%20OpenAI&p=https%3A%2F%2Fopenai.com%2Findex%2Fseparating-signal-from-noise-coding-evaluations%2F&r=&lt=12645&evt=pageLoad&sv=2&cdb=AQAQ&rn=115235)

---

英文原文:[Separating signal from noise in coding evaluations](https://openai.com/index/separating-signal-from-noise-coding-evaluations)