OpenAI ra mắt các tiêu chuẩn mới cho lập trình AI trong các ngôn ngữ có nguồn lực hạn chế

OpenAI công bố hai bài đánh giá mới dành cho các ngôn ngữ lập trình "có nguồn lực thấp": MultiLangBench yêu cầu mô hình triển khai từ đầu một cơ chế cơ sở dữ liệu tương thích SQLite bằng 20 ngôn ngữ khác nhau; bài đánh giá khác yêu cầu mô hình chuyển đổi chương trình COBOL sang C++, Java, Kotlin, Python hoặc Rust, đồng thời duy trì hành vi ban đầu. Kết quả chính thức cho thấy GPT‑6 Astra đạt tỷ lệ vượt qua trung bình 87,4% trên MultiLangBench, trong khi GPT‑6.1 Sol đạt độ chính xác 97,9% khi thực hiện chuyển đổi COBOL trong điều kiện yêu cầu suy luận cao. Điều này cho thấy khả năng lập trình của AI đang mở rộng từ các ngôn ngữ phổ biến như Python, JavaScript sang các công nghệ cũ vẫn được các ngân hàng, chính phủ và tổ chức nghiên cứu sử dụng. Tuy nhiên, những thành tích này đến từ các bài đánh giá do OpenAI tự thiết kế và thực hiện; 87,4% đại diện cho tỷ lệ các trường hợp kiểm thử được vượt qua, không có nghĩa là mô hình đã hoàn thành một phiên bản SQLite có thể triển khai sản xuất, và 97,9% cũng không thể hiểu là các ngân hàng có thể chuyển đổi hệ thống lõi mà không cần kiểm tra thủ công.

Tác giả bài viết, nguồn: OpenAI

Trong lĩnh vực lập trình AI, các ngôn ngữ ít tài nguyên là những ngôn ngữ có ít mã nguồn công khai, tài liệu và tài liệu hỏi đáp để mô hình học tập, không có nghĩa là những ngôn ngữ này thiếu giá trị thực tế.

Python và JavaScript có hệ sinh thái mã nguồn mở khổng lồ, giúp mô hình tiếp xúc với lượng lớn mã nguồn, báo cáo lỗi và hồ sơ sửa chữa trong quá trình huấn luyện. Trong khi đó, các tài liệu công khai cho COBOL, Fortran, Visual Basic và OCaml ít hơn nhiều, và nhiều mã nguồn còn bị lưu trữ trong các hệ thống nội bộ doanh nghiệp.

Đồng thời, những ngôn ngữ này vẫn đảm nhiệm những nhiệm vụ then chốt. OpenAI trích dẫn dữ liệu từ IBM cho biết, COBOL hỗ trợ hơn 40% hệ thống ngân hàng trực tuyến, 80% giao dịch thẻ tín dụng ngoại tuyến và 95% giao dịch ATM; Fortran vẫn tiếp tục được sử dụng trong dự báo thời tiết và phân tích an toàn lò phản ứng hạt nhân.

Việc duy trì các hệ thống này không chỉ khó vì ngữ pháp đã lỗi thời. Các nhà phát triển ban đầu có thể đã nghỉ việc, tài liệu không đầy đủ, và các quy tắc kinh doanh thực sự chỉ tồn tại trong mã nguồn. Một đoạn chương trình vì sao lại cắt bỏ số thập phân, hoặc xử lý thế nào các bản ghi tài khoản không tồn tại, có thể không có bất kỳ giải thích nào, nhưng lại ảnh hưởng trực tiếp đến kết quả tính toán tài chính.

Do đó, điều mà AI thực sự cần chứng minh không phải là “có thể dịch COBOL sang Python trông hiện đại hơn không”, mà là sau khi di chuyển, liệu các quy tắc kinh doanh có vẫn được thực thi hoàn toàn giống nhau không.

OpenAI đã phát hành MultiLangBench. Nó yêu cầu mô hình xây dựng một cơ sở dữ liệu engine tương thích với SQLite bằng ngôn ngữ được chỉ định trong một quá trình lập trình kéo dài.

Chương trình ứng cử sẽ nhận một tệp cơ sở dữ liệu ban đầu và một truy vấn SQL, sau khi thực thi sẽ tạo ra cơ sở dữ liệu đã được sửa đổi. Hệ thống đánh giá sẽ gọi lại triển khai SQLite chính thức để kiểm tra xem nội dung cơ sở dữ liệu có nhất quán với kết quả chuẩn hay không. Nhờ vào giao diện chung là tệp cơ sở dữ liệu, cùng một nhóm chức năng có thể được so sánh qua các ngôn ngữ khác nhau.

Kiểm tra bao phủ 20 ngôn ngữ như C, C++, COBOL, Fortran, Java, JavaScript, Lean, OCaml, Python, Rust, Visual Basic và Zig, đánh giá khả năng của mô hình trong việc tổ chức kho mã nguồn, quản lý trạng thái, xử lý lỗi, thêm tính năng mới và tránh làm hỏng các chức năng hiện có. Các trường hợp kiểm tra được điều chỉnh từ bộ kiểm tra hiện có của SQLite.

Ở mức độ suy luận cao nhất, tỷ lệ vượt bài kiểm tra trung bình của GPT-6 Astra là 87,4%, trong khi GPT-5.6 Sol là 26,8%. OpenAI cho biết, Astra đã cải thiện trong tất cả 20 ngôn ngữ:

COBOL tăng từ 10,9% lên 72,1%, OCaml tăng từ 25,6% lên 85,8%, Fortran tăng từ 21,4% lên 83,5%, Visual Basic tăng từ 27,5% lên 89,4%. Trong số 20 ngôn ngữ, có 19 ngôn ngữ vượt quá 83%, COBOL vẫn là ngôn ngữ khó nhất.

(Mô-đun kết quả tương tác bằng 20 ngôn ngữ có thể chuyển đổi, cho phép xem điểm số và chi phí của từng mô hình trên mỗi ngôn ngữ.)

Cần hiểu đúng các con số này. 87,4% là tỷ lệ trung bình các trường hợp kiểm tra được qua, không có nghĩa là mô hình có 87,4% xác suất tạo ra một cơ sở dữ liệu hoàn chỉnh, ổn định và tuân thủ đầy đủ tất cả các quy định của SQLite. Khoảng 12,6% còn lại bị thất bại trong kiểm tra vẫn có thể liên quan đến các vấn đề như giao dịch, xử lý lỗi hoặc tính nhất quán dữ liệu, đủ để ngăn chặn việc triển khai sản xuất.

Nó chứng minh rằng mô hình có thể liên tục xây dựng phần mềm phức tạp hơn trong ngôn ngữ chưa quen thuộc, chứ không phải SQLite đã có thể được AI viết lại hoàn toàn trong một lần.

OpenAI cũng đã thử nghiệm GPT-6 Luna với chi phí thấp hơn. Nó đạt tỷ lệ đỗ trung bình 40,3% trên 20 ngôn ngữ, cao hơn 26,8% của GPT-5.6 Sol.

Chi phí API trung bình của Luna khoảng 0,77 USD mỗi mẫu, trong khi GPT‑5.6 Sol khoảng 3,48 USD, giảm khoảng 78%. Tuy nhiên, khả năng của nó chưa đạt đến mức của Astra: Luna chỉ đạt 17,1% trên COBOL, 31,4% trên Fortran và 41,6% trên Visual Basic.

Kết quả này trình bày hai lộ trình khác nhau: Astra sử dụng nhiều tài nguyên suy luận hơn để tối đa hóa mức độ hoàn thành các nhiệm vụ phức tạp; trong khi Luna xử lý nhiều mẫu hơn với chi phí thấp hơn, phù hợp cho các thử nghiệm hàng loạt, phân tích sơ bộ và các công việc hỗ trợ có rủi ro thấp.

Chi phí được nhắc đến chỉ là ước tính chi phí API trong quá trình đánh giá, không bao gồm nhân lực cần thiết cho việc xem xét của kỹ sư, môi trường kiểm thử, nghiệm thu nghiệp vụ và sửa lỗi. Đối với các hệ thống cũ, chi phí gọi mô hình thường không phải là chi phí lớn nhất trong dự án di chuyển.

Yêu cầu đánh giá thứ hai là mô hình phải di chuyển chương trình COBOL sang C++, Java, Kotlin, Python hoặc Rust.

Trọng tâm của bài kiểm tra không phải là mã dịch có sạch sẽ hay không, mà là đầu ra có thể quan sát được của chương trình mới và cũ có nhất quán từng byte hay không. Mỗi kết quả di chuyển phải vượt qua tất cả các bài kiểm tra ẩn mới được coi là thành công.

OpenAI đã đưa ra ví dụ về số thập phân cố định: COBOL mặc định có thể trực tiếp loại bỏ các chữ số thập phân thừa, trừ khi chương trình yêu cầu làm tròn. Nếu mô hình tự ý thay đổi thành làm tròn theo thói quen lập trình hiện đại, chương trình dù vẫn chạy bình thường, nhưng kết quả tài chính đã thay đổi.

Ở mức độ suy luận thấp, độ chính xác chuyển giao của GPT‑6.1 Sol đạt 86,6%, trong khi GPT‑5.6 Sol chỉ đạt 5,4%; chi phí API ước tính của前者 còn thấp hơn 39%. Sau khi tăng mức độ suy luận, GPT‑6.1 Sol đạt 97,9%, khiến bộ đánh giá này gần như đạt mức bão hòa.

97,9% ở đây là “tỷ lệ chương trình hoàn toàn vượt qua các trường hợp ẩn trong bộ kiểm thử của OpenAI”, chứ không phải “bất kỳ hệ thống COBOL nào cũng có 97,9% mã có thể được di chuyển tự động một cách an toàn”.

Hệ thống ngân hàng thực tế có thể kết nối với mainframe, cơ sở dữ liệu độc quyền, trình lập lịch xử lý hàng loạt và giao thức truyền thông nội bộ, đồng thời tồn tại các quy trình ngoại lệ không được bao phủ bởi các trường hợp kiểm thử. OpenAI cũng đã rõ ràng rằng việc di chuyển vào sản xuất vẫn cần sự xem xét của chuyên gia và kiểm thử lại dựa trên các quy tắc kinh doanh thực tế và các phụ thuộc liên quan.

OpenAI đã tải lên GitHub môi trường đánh giá MultiLangBench, bộ kiểm tra và kết quả theo từng ngôn ngữ, cho phép các nhà phát triển kiểm tra nội dung kiểm tra và chạy lại bằng các mô hình hoặc khung Agent khác.

Điều này có giá trị hơn nhiều so với chỉ hiển thị một bảng điểm: bên ngoài có thể quan sát xem mô hình thất bại ở những chức năng SQL nào, đồng thời so sánh xem điểm số có bị ảnh hưởng bởi từ gợi ý, quyền truy cập công cụ, ngân sách suy luận và thời gian chạy hay không.

Tuy nhiên, bài viết chính thức chỉ công bố MultiLangBench, không đề cập rằng mẫu chương trình đầy đủ cho đánh giá di chuyển COBOL cùng bài kiểm tra ẩn cũng đã được mở. Kết quả 97,9% của后者 hiện không thể được bên ngoài kiểm tra và tái tạo đầy đủ như MultiLangBench.

Hai bài đánh giá này cũng do OpenAI thiết kế và chủ yếu được sử dụng để so sánh các mô hình của chính OpenAI. Chúng chưa bao quát đủ các kho mã nguồn doanh nghiệp thực tế, chi phí duy trì dài hạn, lỗ hổng bảo mật, suy giảm hiệu suất, cũng như thời gian cần thiết để kiểm tra thủ công. Do đó, kết quả trước hết chứng minh sự tiến bộ của mô hình trên các nhiệm vụ được kiểm soát, chứ không phải là xác minh cuối cùng về việc đã giải quyết xong vấn đề hiện đại hóa phần mềm doanh nghiệp.

Trong hai năm qua, các bản trình diễn sản phẩm AI lập trình chủ yếu tập trung vào việc tạo trang web, ứng dụng di động và công cụ Python. Những kịch bản này trực quan, nhưng không phải là những vấn đề phần mềm đắt đỏ nhất của các doanh nghiệp lớn.

Những mã nguồn đã chạy trong vài chục năm và không ai dám thay đổi tùy tiện mới là điều mà các ngân hàng, công ty bảo hiểm, chính phủ và tổ chức nghiên cứu khoa học thực sự khó xử lý. Chúng có thể không hiện đại, nhưng chứa đựng các quy tắc mà tài khoản, tính toán thuế, chuỗi cung ứng và vận hành hạ tầng đều dựa vào.

Ý nghĩa của MultiLangBench chính là ở chỗ: liệu khả năng của mô hình có thể tách rời khỏi ngôn ngữ đào tạo phổ biến nhất để chuyển giao các phương pháp kỹ thuật phần mềm sang các nền tảng công nghệ có tài liệu khan hiếm, công cụ lỗi thời và chi phí sai sót cao hơn không.

Nếu khả năng này tiếp tục được cải thiện, thay vì “xóa toàn bộ COBOL chỉ với một cú nhấp chuột”, thay đổi đầu tiên mà AI mang lại có thể là giúp các kỹ sư đọc mã nguồn lạ, bổ sung bài kiểm tra, khôi phục tài liệu bị thiếu và xác định các quy tắc kinh doanh, sau đó từng mô-đun thực hiện việc di chuyển đã được xác minh. Các chuyên gia con người vẫn sẽ chịu trách nhiệm quyết định những hành vi nào phải giữ lại và khi nào có thể thực sự thay thế các hệ thống cũ.