我们最新的模型进展为在诸如 COBOL、Fortran 和 Visual Basic 等低资源编程语言中构建和迁移软件带来了更强的能力。这些语言可供模型学习的代码和文档比 Python 和 JavaScript 等语言少，但却支撑着全球关键基础设施和基本服务。COBOL 支持超过 40% 的在线银行系统、80% 的当面信用卡交易以及 95% 的 ATM 交易，而 Fortran 则用于天气预报和核反应堆安全分析。提升 AI 在这些语言中的工作能力，有助于团队维护和现代化基本服务所依赖的软件。
这项工作受到开发者和企业客户反馈的指导，他们告诉我们编码模型往往在这些语言上表现吃力。维护和现代化此类软件可能很困难：文档可能不完整，原开发者可能已离开公司，重要的业务规则可能仅存在于代码中。无论团队是在修复错误还是迁移到另一种语言，他们都需要保留其系统所依赖的行为。
为衡量进展，我们开发了两项评估。MultiLangBench 测试模型能否从零开始在 20 种不同编程语言中构建与 SQLite 兼容的数据库引擎。我们的 COBOL 迁移评估测试模型能否将现有程序迁移到另一种语言，同时保留其行为。两者共同测试两项互补技能：构建新软件以及保留现有软件的功能。
我们的最新模型在两项评估中均表现出显著改进，以更低成本实现了更高得多的准确率。
在 MultiLangBench 上，GPT‑6 Astra 在 20 种编程语言上的平均测试通过率达到 87.4%，高于 GPT‑5.6 Sol 的 26.8%，并且在所有测试语言中均有提升。GPT‑6 Luna 也优于 GPT‑5.6 Sol，达到 40.3%，同时估计 API 成本约低 78%。
在我们的 COBOL 迁移评估中，GPT‑6.1 Sol 在低推理努力下达到 86.6% 的准确率，而 GPT‑5.6 Sol 仅为 5.4%，同时成本低 39%。在更高推理努力下，准确率达到 97.9%，几乎饱和该评估。
综合来看，这些结果表明我们的模型在处理广泛编程语言方面正变得显著更好，同时也变得更具成本效益。
- 从零开始构建 SQLite（MultiLangBench）
MultiLangBench 要求模型用指定的编程语言构建一个与 SQLite 兼容的数据库引擎。模型必须组织代码库、管理状态、处理错误，并在保留现有功能的同时添加新特性。
为了跨语言比较实现，我们使用数据库文件作为共享接口。候选程序接收初始数据库和一条 SQL 查询，然后生成修改后的数据库。我们使用参考 SQLite 实现来检查生成的数据库是否具有预期内容。这让我们能够应用相同的测试，无论用于构建引擎的语言是什么。
我们将来自 SQLite 现有测试套件的测试适配到这种格式。该评估衡量模型在延长的编码会话中能够构建多少可用功能，同时报告测试通过率和 API 成本。
在最大推理努力下，GPT‑6 Astra 在 20 种语言上的平均测试通过率达到 87.4%，高于 GPT‑5.6 Sol 的 26.8%。改进覆盖所有测试语言，包括 COBOL（从 10.9% 到 72.1%）、OCaml（从 25.6% 到 85.8%）、Fortran（从 21.4% 到 83.5%）和 Visual Basic（从 27.5% 到 89.4%）。Astra 在 20 种语言中的 19 种得分超过 83%，COBOL 仍是最难的，为 72%。
GPT‑6 Luna 提供了一个成本更低的选项，在所有测试语言中也优于 GPT‑5.6 Sol。在最大推理努力下，它达到平均测试通过率 40.3%。提升包括 COBOL（从 10.9% 到 17.1%）、OCaml（从 25.6% 到 34.1%）、Fortran（从 21.4% 到 31.4%）和 Visual Basic（从 27.5% 到 41.6%）。这些改进的估计平均 API 成本为每样本 0.77 美元，而 GPT‑5.6 Sol 为 3.48 美元，约低 78%。
我们正在 GitHub上发布 MultiLangBench 评估设置和测试套件，以及每种语言的结果。开发者可以检查评估测试的内容，查看他们使用语言中的性能，并识别与自身工作相关的差距。
- 迁移 COBOL 代码库
我们的第二项评估要求模型将 COBOL 程序迁移到 C++、Java、Kotlin、Python 或 Rust，同时保留每个程序的功能。
成功的迁移需要理解程序的业务逻辑以及 COBOL 的特定语言行为。COBOL 程序通常处理金融交易和业务记录，其中舍入规则和缺失记录处理等细节反映了业务要求。例如，COBOL 的定点算术会丢弃多余的小数位，除非明确请求舍入。如果改写后对这些值进行舍入，则可能无错误运行，却产生不同的财务结果。
为测试这些行为是否被保留，我们在隐藏测试上评估模型，这些测试要求可观察输出达到字节级一致。只有所有测试通过，迁移才被视为成功。此类保留行为的能力对维护和现代化旧系统的团队很有用，不过将其应用于生产软件仍需要专家审查，并根据系统的业务规则和依赖进行测试。
在此评估中，GPT‑6.1 Sol 在低推理努力下达到 86.6% 的准确率，而 GPT‑5.6 Sol 在相同设置下仅为 5.4%，且 API 成本仅为后者的 61%。在更高推理努力下，准确率达到 97.9%，使评估接近饱和。这些评估结果表明，我们在为现代化业务所依赖软件的团队提供更准确、更经济的代码迁移方面取得了进展。
推进企业软件能力
这些评估，加上来自开发人员和企业客户的直接反馈，帮助我们了解模型在哪些方面正在改进，以及在哪些方面仍然不足。
我们的目标是帮助模型在更多语言中应用软件工程技能：理解不熟悉的代码库、规划变更、使用构建工具、运行测试以及调试故障。
您可以通过 API 在团队使用的语言中进行编码任务，试用我们最新的模型。您关于哪些有效、模型在哪些方面遇到困难，以及我们接下来应重点关注哪些语言或工作流程的反馈，有助于塑造我们如何训练和评估模型，以更好地支持您所依赖的软件。