OpenAI 推出針對低資源語言 AI 編程的新基準

OpenAI 發布了兩項針對「低資源程式語言」的新評測：MultiLangBench 要求模型分別使用 20 種語言從零實現一個與 SQLite 兼容的資料庫引擎；另一項評測則要求模型將 COBOL 程式遷移至 C++、Java、Kotlin、Python 或 Rust，同時保持原有行為。官方結果顯示，GPT‑6 Astra 在 MultiLangBench 上的平均測試通過率達 87.4%，GPT‑6.1 Sol 在高推理強度下完成 COBOL 遷移的準確率達 97.9%。這表明 AI 程式設計能力正從 Python、JavaScript 等主流語言延伸至銀行、政府及科研機構仍在使用的舊技術棧。不過，這些成績來自 OpenAI 自行設計和運行的評測；87.4% 代表測試用例通過比例，並不代表模型已完成一個可投入生產的 SQLite 實現，97.9% 也不能理解為銀行可不經人工審查直接遷移核心系統。

文章作者、來源：OpenAI

在 AI 編程領域，低資源語言指的是可供模型學習的公開代碼、文檔和問答資料相對較少的語言，並不意味著這些語言缺乏現實價值。

Python 和 JavaScript 擁有龐大的開源生態，模型在訓練時可以接觸到大量代碼、錯誤報告和修復記錄。COBOL、Fortran、Visual Basic 和 OCaml 的公開資料則少得多，其中不少代碼仍封存在企業內部系統中。

與此同時，這些語言仍承擔著關鍵任務。OpenAI 引用 IBM 的數據稱，COBOL 支撐著超過 40% 的網上銀行系統、80% 的線下信用卡交易和 95% 的 ATM 交易；Fortran 則繼續用於天氣預報與核反應堆安全分析。

維護這些系統的難點不僅在於語法古老。原始開發者可能已離職，文檔並不完整，真正的業務規則僅存在於代碼中。一段程序為何截斷小數、如何處理不存在的賬戶記錄，可能完全沒有說明，卻直接影響金融計算結果。

因此，AI 真正需要證明的並不是「能否把 COBOL 翻譯成看起來更現代的 Python」，而是遷移後是否仍然執行完全相同的業務規則。

OpenAI 為此發布了 MultiLangBench。它要求模型在一次較長的程式設計過程中，使用指定語言構建一個兼容 SQLite 的資料庫引擎。

候選程式會收到一個初始資料庫檔案和一條 SQL 查詢，執行後產生修改過的資料庫。評測系統再調用官方 SQLite 實現，檢查資料庫內容是否與標準結果一致。藉助資料庫檔案這一共同介面，同一組功能可以跨語言比較。

測試涵蓋 C、C++、COBOL、Fortran、Java、JavaScript、Lean、OCaml、Python、Rust、Visual Basic 和 Zig 等 20 種語言，評估模型組織程式碼庫、管理狀態、處理錯誤、新增功能並避免破壞舊功能的能力。測試用例改編自 SQLite 現有的測試套件。

在最高推理強度下，GPT‑6 Astra 的平均測試通過率為 87.4%，而 GPT‑5.6 Sol 為 26.8%。OpenAI 表示，Astra 在全部 20 種語言中均有提升：

COBOL 從 10.9% 升至 72.1%，OCaml 從 25.6% 升至 85.8%，Fortran 從 21.4% 升至 83.5%，Visual Basic 從 27.5% 升至 89.4%。20 種語言中有 19 種超過 83%，COBOL 仍然是最困難的一種。

（此處有可切換的 20 種語言互動結果模組，可查看不同模型在每種語言上的成績與成本。）

這些數字需要正確理解。87.4% 是評測用例的平均通過比例，不代表模型有 87.4% 的機率生成一個完整、穩定且符合 SQLite 全部規範的資料庫。剩餘約 12.6% 的測試失敗，仍可能對應事務、錯誤處理或資料一致性等足以阻止生產部署的問題。

它證明的是模型可以在陌生語言中持續構建較複雜的軟體，而不是 SQLite 已經可以由 AI 一次性重寫。

OpenAI 還測試了成本更低的 GPT‑6 Luna。它在 20 種語言中的平均通過率為 40.3%，高於 GPT‑5.6 Sol 的 26.8%。

Luna 的平均 API 成本約為每個樣本 0.77 美元，GPT‑5.6 Sol 則約為 3.48 美元，降幅約 78%。但其能力提升並未達到 Astra 的水平：Luna 在 COBOL 上僅為 17.1%，Fortran 為 31.4%，Visual Basic 為 41.6%。

這組結果呈現兩條不同路線：Astra 使用更多推理資源，盡可能提升複雜任務的完成度；Luna 則以較低費用處理更多樣本，適合批量嘗試、初步分析和風險較低的輔助工作。

所謂的成本僅為評測中估算的 API 費用，不包括工程師審查、測試環境、業務驗收以及錯誤修復所需的人力。對於遺留系統，模型調用費往往不是遷移項目中最大的成本。

第二項評測要求模型將 COBOL 程式遷移至 C++、Java、Kotlin、Python 或 Rust。

The focus of the test is not whether the translated code is clean, but whether the observable outputs of the new and old programs are byte-for-byte identical. Each migration result must pass all hidden tests to be considered successful.

OpenAI 特別舉出了定點小數的例子：COBOL 預設可能會直接捨棄多餘的小數位，除非程式明確要求四捨五入。如果模型根據現代程式設計習慣擅自改為四捨五入，程式雖然能夠正常運行，財務結果卻已改變。

在低推理強度下，GPT‑6.1 Sol 的遷移準確率達到 86.6%，而 GPT‑5.6 Sol 僅為 5.4%；前者估算的 API 成本還低 39%。提高推理強度後，GPT‑6.1 Sol 達到 97.9%，使這套評測接近飽和。

這裡的 97.9% 是「在 OpenAI 這套測試中完整通過隱藏用例的程式比例」，而不是「任意 COBOL 系統都有 97.9% 的程式碼可以安全自動遷移」。

真實銀行系統可能連接大型機、專有資料庫、批次排程器和內部通訊協議，並存在測試用例未涵蓋的異常流程。OpenAI 也明確表示，生產遷移仍需專家審查，並針對實際業務規則和依賴關係重新測試。

OpenAI 已將 MultiLangBench 的評測環境、測試套件和分語言結果上傳至 GitHub，開發者可以檢查測試內容，並使用其他模型或 Agent 框架重新運行。

這比僅展示一張成績表更有價值：外界可以觀察模型在哪些 SQL 功能上失敗，也可以比較成績是否受到提示詞、工具權限、推理預算和運行時長的影響。

不過，官方文章僅宣布公開 MultiLangBench，未說明 COBOL 遷移評測的完整程式樣本與隱藏測試也已開放。後者 97.9% 的成績目前無法像 MultiLangBench 一樣由外界完整檢查和複現。

這兩項評測同樣由 OpenAI 設計，主要用於比較 OpenAI 自身的模型。它們尚未涵蓋大量真實企業代碼庫、長期維護成本、安全漏洞、性能退化，以及人工審核所需時間。因此，結果首先證明的是模型在受控任務上的進步，而非對企業軟體現代化問題已徹底解決的最終驗證。

過去兩年，AI 編程產品的演示大多集中在建立網頁、移動應用和 Python 工具。這些場景直觀，卻不是大型企業最昂貴的軟體問題。

銀行、保險、政府和科研機構真正難以處理的，是運行了數十年、無人敢輕易改動的代碼。它們可能不夠新潮，卻包含賬戶處理、稅務計算、供應鏈和基礎設施運行所依賴的規則。

MultiLangBench 的意義就在於：模型能力是否能脫離最常見的訓練語言，將軟體工程方法遷移至資料稀缺、工具陳舊、錯誤代價更高的技術堆疊。

如果這項能力持續提升，AI 最先帶來的變化可能不是「一鍵刪除所有 COBOL」，而是協助工程師閱讀陌生代碼、補充測試、恢復缺失文檔、定位業務規則，再逐個模組完成經過驗證的遷移。人類專家仍負責決定哪些行為必須保留，以及何時才能真正替換舊系統。