我们最新的模型进展为使用 COBOL、Fortran 和 Visual Basic 等低资源编程语言构建和迁移软件带来了更强的能力。与 Python 和 JavaScript 等语言相比，可供模型学习的这些语言的代码和文档较少，但它们支撑着世界各地关键的基础设施和基本服务。COBOL 支撑(opens in a new window) 了超过 40% 的在线银行系统、80% 的线下信用卡交易和 95% 的 ATM 交易，而 Fortran 则被用于 天气预报(opens in a new window) 和 核反应堆安全分析(opens in a new window)。提升 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%，接近评估的上限。
这些结果共同表明，我们的模型在处理多种编程语言方面正在显著进步，同时成本效益也在提高。
1. 从零构建 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%。
我们正在 MultiLangBench 评估设置和测试套件发布在 GitHub(opens in a new window)上，同时提供每种语言的结果。开发者可以查看该评估测试的内容，审查他们所使用语言的性能，并找出对他们自身工作重要的差距。
2. 迁移 COBOL 代码库
我们的第二项评估要求模型将 COBOL 程序迁移到 C++、Java、Kotlin、Python 或 Rust，同时保留每个程序的功能。
成功的迁移需要同时理解程序的业务逻辑和 COBOL 特定的语言行为。COBOL 程序通常处理金融交易和业务记录，其中舍入规则和缺失记录处理等细节反映了业务需求。例如，COBOL 的定点算术会丢弃多余的十进制数字，除非明确要求舍入。如果重写时对这些值进行舍入，程序可能无错误地运行，却产生不同的财务结果。
为了检验这些行为是否得以保留，我们在需要对可观察输出做到逐字节一致的隐藏测试上评估我们的模型。只有所有测试通过，迁移才算成功。这类保留行为的能力对于维护和现代化旧系统的团队非常有用，不过将其应用于生产软件仍需要专家审查，并针对系统的业务规则和依赖进行测试。
在这项评估中，GPT‑6.1 Sol 在低推理力度下达到 86.6% 的准确率，而 GPT‑5.6 Sol 在相同设置下仅为 5.4%，且后者的成本只有 61% 的 API 费用。在更高的推理力度下，准确率达到 97.9%，使该评估接近饱和。这些评估结果表明，在为正在现代化其业务所依赖软件的团队提供更准确、更实惠的代码迁移方面取得了进展。
推进企业软件能力
这些评估，连同开发者和企业客户的直接反馈，帮助我们看清模型在哪些方面正在进步，以及在哪些方面仍有不足。
我们的目标是帮助模型将软件工程技能应用到更多语言中：理解陌生的代码库、规划更改、使用构建工具、运行测试以及调试失败。
您可以通过 API 在您的团队所使用的语言的编码任务中试用我们的最新模型。您关于哪些方面有效、模型在哪里遇到困难，以及我们接下来应关注哪些语言或工作流程的反馈，将有助于塑造我们训练和评估模型的方式，从而更好地支持您所依赖的软件。