在 API 中推出 GPT-4.1

# 在 API 中推出 GPT-4.1 来源：https://openai.com/index/gpt-4-1/ 新系列 GPT 模型，在编码、指令遵循和长上下文方面有重大改进——加上我们首个超小型模型。 今天，我们在 API 中推出三个新模型：GPT‐4.1、GPT‐4.1 mini 和 GPT‐4.1 nano。这些模型在各方面都优于 GPT‐4o 和 GPT‐4o mini，在编码和指令遵循方面有重大进展。它们还具有更大的上下文窗口——支持高达 100 万个 token 的上下文——并能够更好地利用该上下文，具有改进的长上下文理解能力。它们的知识截止日期更新为 2024 年 6 月。 GPT‐4.1 在以下行业标准指标中表现卓越： - **编码**：GPT‐4.1 在 SWE‐bench Verified (https://openai.com/index/introducing-swe-bench-verified/) 上的得分为 54.6%，相比 GPT‐4o 提高 21.4 个百分点，相比 GPT‐4.5 提高 26.6 个百分点——使其成为编码领域的领先模型。 - **指令遵循**：在 Scale 的 MultiChallenge (https://scale.com/leaderboard/multichallenge) 基准上，用于衡量指令遵循能力，GPT‐4.1 得分为 38.3%，相比 GPT‐4o 提高 10.5 个百分点。 - **长上下文**：在 Video‐MME (https://video-mme.github.io/home_page.html)（多模态长上下文理解的基准）上，GPT‐4.1 创造了新的最先进成果——在无字幕长视频类别中得分 72.0%，相比 GPT‐4o 提高 6.7 个百分点。 虽然基准提供了有价值的见解，但我们训练这些模型的重点是实际效用。与开发者社区的紧密合作和伙伴关系使我们能够为对其应用最重要的任务优化这些模型。 为此，GPT‐4.1 模型系列以更低的成本提供了卓越的性能。这些模型在延迟曲线的每个点都推进了性能。 GPT‐4.1 mini 是小型模型性能的重大飞跃，甚至在许多基准上击败了 GPT‐4o。它在智能评估上与 GPT‐4o 相当或更优，同时将延迟降低近一半，成本降低 83%。 对于需要低延迟的任务，GPT‐4.1 nano 是我们最快、最便宜的可用模型。它以小型尺寸提供了出色的性能，具有 100 万 token 的上下文窗口，在 MMLU 上得分 80.1%，在 GPQA 上得分 50.3%，在 Aider polyglot 编码上得分 9.8%——甚至高于 GPT‐4o mini。它非常适合分类或自动完成等任务。 指令遵循可靠性和长上下文理解能力的这些改进也使 GPT‐4.1 模型在为代理提供支持（或可以代表用户独立完成任务的系统）方面效果更佳。当与 Responses API (https://platform.openai.com/docs/api-reference/responses) 等基础工具结合时，开发者现在可以构建在现实世界软件工程、从大型文档中提取见解、以最少的人工干预解决客户请求以及其他复杂任务方面更有用且更可靠的代理。 请注意，GPT‐4.1 仅可通过 API 获得。在 ChatGPT 中，指令遵循、编码和智能方面的许多改进已逐步融入到最新版本 (https://help.openai.com/en/articles/6825453-chatgpt-release-notes) GPT‐4o 中，我们将继续在未来版本中融入更多改进。 我们还将开始在 API 中弃用 GPT‐4.5 Preview，因为 GPT‐4.1 在许多关键能力上提供改进或相似的性能，成本和延迟大幅降低。GPT‐4.5 Preview 将在三个月后（2025 年 7 月 14 日）关闭，以便为开发者留出过渡时间。GPT‐4.5 作为研究预览版引入 (https://openai.com/index/introducing-gpt-4-5/)，用于探索和试验大型、计算密集型模型，我们从开发者的反馈中学到了很多。我们将继续将你告诉我们你欣赏的 GPT‐4.5 中的创意、写作质量、幽默和细微差别融入到未来的 API 模型中。 下面，我们分析了 GPT‐4.1 在多个基准上的表现，以及来自 Windsurf、Qodo、Hex、Blue J、Thomson Reuters 和 Carlyle 等 alpha 测试人员的示例，展示了它在生产中对特定领域任务的表现。 GPT‐4.1 在各种编码任务上明显优于 GPT‐4o，包括代理解决编码任务、前端编码、进行更少的多余编辑、可靠地遵循 diff 格式、确保一致的工具使用等。 在 SWE‐bench Verified（衡量现实世界软件工程技能）上，GPT‐4.1 完成了 54.6% 的任务，而 GPT‐4o（2024‐11‐20）为 33.2%。这反映了模型探索代码存储库、完成任务以及生成既能运行又能通过测试的代码的能力的改进。 *对于 SWE‐bench Verified (https://openai.com/index/introducing-swe-bench-verified/)，模型被给予一个代码存储库和问题描述，必须生成补丁来解决问题。性能高度依赖于所使用的提示和工具。为了帮助重现和背景化我们的结果，我们在此 (https://cookbook.openai.com/examples/gpt4-1_prompting_guide) 描述了我们对 GPT‐4.1 的设置。我们的得分省略了 500 个问题中的 23 个，其解决方案无法在我们的基础设施上运行；如果这些保守地评分为 0，54.6% 的得分变为 52.1%。* 对于希望编辑大型文件的 API 开发者，GPT‐4.1 在各种格式的代码 diff 方面要可靠得多。GPT‐4.1 在 Aider 的 polyglot diff 基准 (https://aider.chat/docs/leaderboards/) 上的得分是 GPT‐4o 的两倍多，甚至比 GPT‐4.5 高出 8 个百分点。此评估既是对各种编程语言的编码能力的衡量，也是对模型以整体和 diff 格式生成更改的能力的衡量。我们特别训练了 GPT‐4.1 以更可靠地遵循 diff 格式，这允许开发者通过仅让模型输出更改的行而不是重写整个文件来节省成本和延迟。为了获得最佳代码 diff 性能，请参考我们的提示指南 (http://platform.openai.com/docs/guides/text?api-mode=responses#prompting-gpt-4-1-models)。对于更喜欢重写整个文件的开发者，我们增加了 GPT‐4.1 的输出 token 限制到 32,768 token（从 GPT‐4o 的 16,384 token 增加）。我们还建议使用预测输出 (https://platform.openai.com/docs/guides/predicted-outputs) 来降低完整文件重写的延迟。 GPT‐4.1 还在前端编码方面比 GPT‐4o 有了实质性的改进，能够创建功能更齐全且美观的网络应用。在我们的对头评测中，付费人工评估者在 80% 的情况下更喜欢 GPT‐4.1 的网站而非 GPT‐4o 的。 除了上述基准外，GPT‐4.1 在更可靠地遵循格式方面更好，进行多余编辑的频率也更低。在我们的内部评估中，代码上的多余编辑从 GPT‐4o 的 9% 下降到 GPT‐4.1 的 2%。 **Windsurf** (https://windsurf.com/editor)：GPT‐4.1 在 Windsurf 的内部编码基准上比 GPT‐4o 高出 60%，这与代码更改在首次审查中被接受的频率密切相关。他们的用户指出它在工具调用上效率提高了 30%，进行不必要的编辑或以过于狭隘的、递进式步骤阅读代码的可能性降低了约 50%。这些改进转化为工程团队更快的迭代和更顺畅的工作流程。 **Qodo** (https://www.qodo.ai/)：Qodo 对 GPT‐4.1 与其他领先模型进行了对标测试，对使用受其微调基准启发的方法从 GitHub pull requests 生成高质量代码审查。在 200 个有意义的真实世界 pull requests 中使用相同的提示和条件，他们发现 GPT‐4.1 在 55% 的情况下提供了更好的建议 (https://www.qodo.ai/blog/benchmarked-gpt-4-1/)。值得注意的是，他们发现 GPT‐4.1 在精确性（知道何时不做建议）和全面性（在需要时提供彻底分析）方面都表现出色，同时保持对真正关键问题的关注。 GPT‐4.1 更可靠地遵循指令，我们在各种指令遵循评估中测量到了显著改进。 我们为指令遵循开发了内部评估，以跟踪模型在多个维度和几个关键指令遵循类别的性能，包括： - **格式遵循**。提供指定模型响应的自定义格式的指令，如 XML、YAML、Markdown 等。 - **负面指令**。指定模型应避免的行为。（例如："不要要求用户联系支持"） - **有序指令**。提供模型必须按给定顺序遵循的一组指令。（例如："首先询问用户的名字，然后询问他们的电子邮件"） - **内容要求**。输出包含某些信息的内容。（例如："在撰写营养计划时始终包括蛋白质含量"） - **排序**。以特定方式排序输出。（例如："按人口数量排序响应"） - **过度自信**。指示模型在请求的信息不可用或请求不属于给定类别时说"我不知道"或类似内容。（例如："如果你不知道答案，请提供支持联系电子邮件"） 这些类别是开发者反馈的结果，关于指令遵循的哪些方面与他们最相关和最重要。在每个类别中，我们将提示分为简单、中等和困难。GPT‐4.1 在特别是困难提示上比 GPT‐4o 有显著改进。 *我们的内部指令遵循评估基于真实的开发者用例和反馈，涵盖了不同复杂程度的任务，以及关于格式、详细程度、长度等方面的指令。* 多轮指令遵循对许多开发者至关重要——模型在深入对话中保持连贯性并跟踪用户之前告诉它的内容很重要。我们训练了 GPT‐4.1，使其能更好地从对话中的过去消息中挑出信息，从而实现更自然的对话。Scale 的 MultiChallenge 基准是衡量此能力的有用指标，GPT‐4.1 的性能比 GPT‐4o 高出 10.5 个百分点。 GPT‐4.1 在 IFEval 上的得分也是 87.4%，而 GPT‐4o 为 81.0%。IFEval 使用包含可验证指令的提示（例如，指定内容长度或避免某些词汇或格式）。 更好的指令遵循使现有应用更可靠，并启用了之前因可靠性差而受限的新应用。早期测试人员指出，GPT‐4.1 可能更加字面意思，所以我们建议在提示中明确和具体。有关 GPT‐4.1 的提示最佳实践的更多信息，请参考提示指南。 **Blue J** (https://www.bluej.com/)：GPT‐4.1 在 Blue J 最具挑战性的真实世界税务场景的内部基准上的准确率比 GPT‐4o 高 53%。这种准确性的跳跃——对系统性能和用户满意度都至关重要——突出了 GPT‐4.1 对复杂法规的改进理解以及它在长上下文中遵循微妙指令的能力。对于 Blue J 用户，这意味着更快、更可靠的税务研究和更多时间用于高价值咨询工作。 **Hex** (https://hex.tech/)：GPT‐4.1 在 Hex 最具挑战性的 SQL 评估集 (https://hex.tech/blog/im-sorry-but-those-are-vanity-evals) 上实现了接近 2 倍的改进，展示了指令遵循和语义理解的重大进展。该模型在从大型、模糊的模式中选择正确表格方面更可靠——这是一个直接影响整体准确性的上游决策点，很难仅通过提示调整来微调。对于 Hex，这导致了手动调试的可衡量减少和更快的生产级工作流路径。 GPT‐4.1、GPT‐4.1 mini 和 GPT‐4.1 nano 可以处理高达 100 万个 token 的上下文——高于之前 GPT‐4o 模型的 128,000。100 万个 token 是整个 React 代码库的 8 倍多，所以长上下文非常适合处理大型代码库或许多长文档。 我们训练了 GPT‐4.1 以可靠地关注整个 100 万上下文长度的信息。我们还训练它在长短上下文长度中比 GPT‐4o 更可靠地注意到相关文本并忽视干扰因素。长上下文理解是法律、编码、客户支持和许多其他领域应用的关键能力。 下面，我们展示了 GPT‐4.1 检索位于上下文窗口内各个点的小隐藏信息块（"针"）的能力。GPT‐4.1 在所有位置和所有上下文长度上一致地准确检索针，直到 100 万 token。无论其在输入中的位置如何，它都能有效地提取任务所需的相关细节。 *在我们的内部needle in a haystack 评估中，GPT‐4.1、GPT‐4.1 mini 和 GPT‐4.1 nano 都能在上下文中的所有位置检索针直到 1M。* 然而，很少有真实世界的任务像检索单个明显的针答案那样简单。我们发现用户经常需要我们的模型检索和理解多条信息，并理解这些信息之间的关系。为了展示此能力，我们开源了一个新的评估：OpenAI‐MRCR（多轮共指消解）。 OpenAI‐MRCR 测试模型在上下文中查找和区分多个隐藏很深的针的能力。评估由用户和助手之间的多轮合成对话组成，其中用户要求助手写关于某个主题的文章，例如"写一首关于貘的诗"或"写一篇关于岩石的博客文章"。然后我们在整个上下文中插入两个、四个或八个相同的请求。模型必须检索对应于特定实例的响应（例如，"给我第三首关于貘的诗"）。 挑战来自这些请求与上下文其余部分的相似性——模型可能很容易被细微差别误导，例如关于貘的短篇故事而不是诗，或关于青蛙而不是貘的诗。我们发现 GPT‐4.1 在长达 128K token 的上下文长度上都优于 GPT‐4o，甚至在高达 100 万 token 时仍保持强劲性能。 但这项任务仍然很难——即使对于高级推理模型也是如此。我们正在共享评估数据集 (https://huggingface.co/datasets/openai/mrcr) 以鼓励进一步进行真实世界长上下文检索的工作。 我们也发布了 Graphwalks (https://huggingface.co/datasets/openai/graphwalks)，一个用于评估多跳长上下文推理的数据集。许多开发者对长上下文的用例需要在上下文内进行多个逻辑跳跃，例如在编写代码时在多个文件之间跳跃或在回答复杂法律问题时交叉引用文档。 模型（甚至人类）理论上可以通过一遍或阅读提示来解决 OpenAI‐MRCR 问题，但 Graphwalks 的设计目的是需要在上下文中的多个位置进行推理，并且不能按顺序解决。 Graphwalks 用由十六进制哈希组成的有向图填充上下文窗口，然后要求模型从图中的随机节点执行广度优先搜索 (BFS)。然后我们问它