我們的模型在最新進展中，進一步提升了使用 COBOL、Fortran 和 Visual Basic 等低資源程式語言開發及遷移軟件的能力。與 Python 和 JavaScript 等語言相比，這些語言可供模型學習的程式碼及文件較少，卻支撐着世界各地的關鍵基礎設施和必要服務。COBOL 支撐（在新視窗中開啟）超過 40% 的網上銀行系統、80% 的現場信用卡交易及 95% 的自動櫃員機交易，而 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%，幾乎觸及這項評估的上限。
綜合這些結果可見，我們的模型運用各種程式語言的能力正顯著提升，同時也更具成本效益。
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 程式遷移至 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 試用我們的最新模型，以團隊使用的語言執行編程任務。歡迎分享模型在哪些方面表現良好、遇到哪些困難，以及我們接下來應重點改進哪些語言或工作流程。你的意見有助我們調整模型的訓練及評估方式，讓模型更好地支援你所依賴的軟件。
