GPT-6.1 Sol trên COBOL: 86,6% so với 5,4%, và chỉ một trong hai bài kiểm tra có thể được chạy lại

Vào 19 tháng 10 năm 2026, O​penAI đã công bố hai bài đánh giá lập trình cho các ngôn ngữ ít tài nguyên, và con số nổi bật thuộc về GPT-6.1 Sol: 86,6% các tác vụ di trú COBOL đạt ở mức nỗ lực suy luận thấp, so với 5,4% của GPT-5.6 Sol ở cùng thiết lập, tăng lên 97,9% khi mức nỗ lực tăng lên. Bài đánh giá thứ hai, MultiLangBench, là câu chuyện của một mô hình khác — GPT-6 Astra đạt trung bình 87,4% trên hai mươi ngôn ngữ ở mức nỗ lực tối đa — nhưng đây là nửa hữu ích hơn của đợt phát hành, vì O​penAI đã đưa bộ khung kiểm thử của mình lên GitHub theo Apache-2.0 và bạn có thể tự chạy nó vào chiều nay. Bài đánh giá di trú COBOL, bài mang con số 86,6%, lại là chuyện khác: các bài kiểm thử của nó bị ẩn, tiêu chí đạt là đầu ra khớp từng byte với những trường hợp mà không ai bên ngoài O​penAI từng thấy, và chưa có bên thứ ba nào tái lập được nó. Sự bất đối xứng đó chính là toàn bộ câu chuyện, và đáng được nói thẳng ra trước khi một trong hai con số được trích dẫn trong một luận chứng kinh doanh cho việc di trú. Các lỗi AI và sự cố tác nhân được ghi nhận đằng sau những bản phát hành như bản này được tập hợp trong OrcaRouter AI Incident Archive, nơi mỗi mục đều có nguồn riêng, mức độ nghiêm trọng, cấp độ tin cậy và cờ tranh chấp riêng.

Một ngày cần nhớ cho chính xác. Bản thân GPT-6.1 Sol là từ 29 tháng 9, 2026 — đây không phải là một đợt ra mắt, và không có gì ở đây thay đổi trọng số, giá hay bảng giá của mô hình. Điều xảy ra vào ngày 19 tháng 10 là O​penAI đã công bố bằng chứng về những gì mô hình có thể làm trong một hạng mục mà trước đó họ chưa từng ghi nhận, và phát hành một bộ đánh giá chuẩn mà bất kỳ ai cũng có thể chạy lại. Đó là sự kiện mà bài viết này nói tới.

Điều gì thực sự đã được công bố, và mỗi nửa là để làm gì

Hai đánh giá trả lời những câu hỏi khác nhau, và cách tự định khung của OpenAI tách biệt chúng. MultiLangBench hỏi liệu một mô hình có thể xây dựng một thứ gì đó bằng một ngôn ngữ mà không ai huấn luyện trên đó: triển khai SQLite 3.40.1 từ đầu bằng một trong hai mươi ngôn ngữ lập trình, sau đó vượt qua bộ kiểm thử tuân thủ cơ sở dữ liệu. Đánh giá chuyển đổi COBOL hỏi liệu một mô hình có thể di chuyển một thứ gì đó: dịch các chương trình COBOL sang C++, Java, Kotlin, Python hoặc Rust trong khi bảo toàn chính xác hành vi quan sát được.

Đầu tiên là một bài kiểm tra mức năng lực tối thiểu. Thứ hai là điều mà các doanh nghiệp thực sự quan tâm, bởi vì COBOL không phải là một sự tò mò mang tính kiểm chuẩn — các ước tính lâu nay của IBM cho rằng COBOL đứng sau hơn 40% hệ thống ngân hàng trực tuyến và khoảng 95% giao dịch ATM, và mã nguồn này được duy trì bởi một lực lượng lao động không được thay thế.

• MultiLangBench, nỗ lực tối đa — GPT-6 Astra 87.4%, GPT-6 Luna 40.3%, GPT-5.6 Sol 26.8%. Astra đạt 83% ở 19/20 ngôn ngữ; COBOL là điểm yếu nhất của nó ở mức 72.1% so với 10.9% của GPT-5.6 Sol, điều đó cho thấy ngôn ngữ khó nhất trong bộ vẫn là ngôn ngữ có công cụ lâu đời nhất.

• Chuyển đổi mã COBOL, nỗ lực thấp — GPT-6.1 Sol 86,6%, GPT-5.6 Sol 5,4%, với chi phí API ước tính bằng 61% so với mô hình cũ hơn cho lượt đánh giá, tức ít hơn 39%.

• Di trú COBOL, nỗ lực cao hơn — GPT-6.1 Sol 97,9%, mà OpenAI mô tả là gần mức bão hòa.

• Chi tiết theo từng ngôn ngữ mà O​penAI đã công bố — Fortran 83,5% cho Astra so với 21,4% của GPT-5.6 Sol; Visual Basic 89,4% so với 27,5%; OCaml 85,8% so với 25,6%; GPT-6 Luna đạt 17,1% ở COBOL, 31,4% ở Fortran, 34,1% ở OCaml và 41,6% ở Visual Basic.

• Chi phí mỗi mẫu trên MultiLangBench — ước tính 0,77 USD cho GPT-6 Luna so với 3,48 USD cho GPT-5.6 Sol, thấp hơn khoảng 78%, và đây chính là con số khiến mô hình yếu nhất trên bảng trở thành đối tượng đáng chú ý cho một pipeline tạo bản dựng.

Bài đánh giá mà bạn có thể chạy lại: MultiLangBench thực sự yêu cầu điều gì

Kho lưu trữ là github.com/openai/MultiLangBench, Apache-2.0, và đọc bộ khung kiểm thử còn cung cấp nhiều thông tin hơn là đọc bảng xếp hạng. Tác vụ đủ cụ thể để một mô hình không thể đánh lừa: tạo ra một tệp thực thi nhận đường dẫn cơ sở dữ liệu làm đối số dòng lệnh, đọc truy vấn SQL từ stdin, và hoạt động giống SQLite 3.40.1. Các bài kiểm thử đến từ chính bộ TCL của SQLite — tổng cộng khoảng 51.000 bài kiểm thử, trong đó khoảng 24.000 bài được chuyển đổi thành các bộ ba mà harness sử dụng: một cơ sở dữ liệu ban đầu, một truy vấn của người dùng và một truy vấn xác thực. Tên bài kiểm thử là hash SHA-256 của các thành phần đó, nên không thể ghi nhớ bộ kiểm thử theo tên.

Khó khăn nằm ở chính các quy tắc, và mỗi quy tắc đều chặn lại một lối tắt:

• Không có internet và không có SQLite ở bất kỳ đâu trong môi trường. Bộ khung kiểm thử nói rằng trước tiên phải xóa mọi dấu vết của SQLite. Một mô hình không thể gọi ra engine thật thông qua shell, và nó cũng không thể tải một bản triển khai.

• Kiểm thử xác thực chạy trên SQLite 3.40.1 thật. Phần triển khai của bạn sửa đổi cơ sở dữ liệu; bộ khung kiểm thử trích xuất nó và kiểm tra bằng bản gốc thật. Hành vi gần đúng sẽ thất bại.

• Sáu mươi giây cho mỗi bài kiểm tra, và câu trả lời sai ngôn ngữ sẽ nhận điểm không. Trộn lẫn ngôn ngữ sẽ không đạt, và bộ khung kiểm thử lưu ý rằng có thể dùng một mô hình khác để kiểm tra xem bạn thực sự đã viết bằng ngôn ngữ nào. Quy tắc cuối cùng đó tồn tại vì trò gian lận hiển nhiên — viết bằng Python rồi bọc lại — là điều đầu tiên một mô hình có năng lực thử làm.

• Lần chạy nhanh có 272 bài kiểm tra, không phải 24.000. README khuyến nghị chỉ chạy những bài kiểm tra có tên bắt đầu bằng 00, 01 hoặc 02 khi bạn muốn có một con số có thể so sánh được. Đó là chi tiết cần lưu ý trước khi bạn so sánh điểm của mình với điểm của OpenAI: chạy toàn bộ bộ kiểm thử và chạy nhanh không phải là cùng một phép đo, và README có nói rõ như vậy.

Đó là một bộ đánh giá thực sự, có thể kiểm chứng. Nó cũng cho bạn biết một điều mà báo chí đưa tin đã không nói: con số nổi bật 87.4% được đo trên một bộ kiểm thử mà bạn có thể dùng để đánh giá mô hình của chính mình, điều này hiếm đến mức đáng để tải về.

Bài đánh giá mà bạn không thể chạy lại, và vì sao điều đó không tự động trở thành một vụ bê bối

Đánh giá chuyển đổi COBOL do OpenAI thiết kế, OpenAI thực hiện và OpenAI chấm điểm, và các ca kiểm thử của nó không được công bố. Ngưỡng đạt được nêu chính xác — một cuộc chuyển đổi chỉ được tính nếu mọi kiểm thử ẩn đều tạo ra đầu ra quan sát được giống hệt từng byte — và chính sự chính xác đó là điều khiến kết quả không thể được xác minh từ bên ngoài: 86,6% là phép đo của OpenAI dựa trên các ca ẩn của chính OpenAI. Chỉ một trong hai đánh giá trong bản phát hành là thứ mà người đọc có thể tái tạo.

Việc không công bố các bài kiểm thử di trú không phải là điều không thể biện hộ. Kho ngữ liệu nhiều khả năng được lấy từ các chương trình cũ thực tế, và việc công bố nó có thể làm rò rỉ mã của khách hàng hoặc trao cho các mô hình tương lai một tập huấn luyện. Tính tương đương từng byte cũng là một tiêu chí thực sự thận trọng, khắt khe hơn hầu hết các đánh giá của nhà cung cấp: nó không thưởng cho một bản dịch chỉ ở mức gần đúng.

Nhưng tiêu chí đó cũng là nơi những rắc rối thực tế bắt đầu, và chính những lưu ý của OpenAI cũng chỉ thẳng vào đó. Đầu ra của quá trình chuyển đổi vẫn cần chuyên gia đánh giá và kiểm thử dựa trên các quy tắc nghiệp vụ và phụ thuộc hệ thống trước khi đưa vào vận hành thực tế. Và tính tương đương từng byte rất khó đạt đúng ở chính những chỗ COBOL khó: ngôn ngữ này cắt cụt và làm tròn số học dấu phẩy tĩnh theo những cách mà hầu hết ngôn ngữ đích không làm, nên một bản dịch có thể trông đúng, vượt qua một bộ kiểm thử chỉ kiểm tra mức "đủ gần", mà vẫn làm lệch một số dư đi một xu. Một bộ kiểm thử ẩn yêu cầu bằng nhau chính xác sẽ xử lý được điều đó; quy trình đánh giá của bạn cũng phải xử lý được điều đó, vì điểm số của mô hình không phải là một phát biểu về các chương trình của bạn.

Con số chi phí cũng cần được cân nhắc cẩn thận tương tự. Mức tiết kiệm 39% là ước tính cho lần chạy đánh giá — token vào và ra khỏi benchmark — chứ không phải chi phí thay thế một hệ thống production, vốn chủ yếu đến từ việc tìm hiểu, rà soát chuyên gia, kiểm thử tích hợp và nhiều năm hành vi không được ghi lại mà không phép đánh giá nào lấy mẫu được.

86,6% và 97,9% nên thay đổi điều gì trong một quyết định?

Cách hiểu trung thực thì hẹp hơn các tít báo và hữu ích hơn chúng. Mức cơ sở 5,4% không phải là một mô hình hoạt động được một nửa; đó là mô hình gần như không bao giờ tạo ra bản dịch bảo toàn hành vi, nên thế hệ cũ chưa bao giờ là ứng viên cho công việc này. GPT-6.1 Sol ở mức 86,6% nằm trong vùng mà bài toán kinh tế đảo chiều: một công cụ phác thảo phần lớn bản dịch và để người đánh giá kiểm tra lại là một sản phẩm khác với một công cụ chẳng tạo ra gì dùng được.

Con số 97,9% ở mức nỗ lực cao hơn là con số bạn nên hoài nghi, không phải vì nó sai mà vì nó đã bão hòa. Khi một benchmark gần chạm trần, nó không còn phân biệt được giữa các mô hình nữa mà bắt đầu đo chính bộ đề, và O​penAI cũng nói đúng như vậy. Để lập kế hoạch, hãy coi 86,6% ở mức nỗ lực thấp là điểm vận hành rẻ và 97,9% là trần của những gì bài đánh giá có thể cho bạn thấy — chứ không phải là lời hứa về độ chính xác cho cơ sở mã của bạn.

Cũng có một bước kiểm tra chéo đáng làm, và nó đi ngược lại sự thổi phồng. Trong bài kiểm tra build, COBOL vẫn là ngôn ngữ yếu nhất của GPT-6 Astra ở mức 72,1% mặc dù Astra là mô hình mạnh hơn tổng thể với mức trung bình 87,4%. Ngôn ngữ này khó theo cả hai chiều. Một mô hình chuyển đổi COBOL tốt trong một đánh giá ẩn không vì thế mà giỏi COBOL; nó giỏi với mẫu mà đánh giá đó lấy mẫu.

Điều khác đã xảy ra trong tuần này: tuyên bố về dấu vết lý luận

Một bài đăng được chia sẻ rộng rãi vào ngày 21 tháng 10 nói rằng các dấu vết suy luận của GPT-6.1 Sol là "hoàn toàn dễ đọc, không có gì đáng lo." Không có gì trong ấn phẩm ngày 19 tháng 10 của O​penAI, và không có gì trên trang tài liệu của chính mô hình, ủng hộ điều đó như một thay đổi trong những gì API trả về. Hướng dẫn suy luận của O​penAI nói rõ rằng các token suy luận thô không được phơi bày — các mục suy luận vẫn không minh bạch — và rằng thứ bạn có thể yêu cầu là một bản tóm tắt của phần suy luận thông qua summary tham số, với nội dung suy luận được mã hóa được phát lại qua các lượt. GPT-6.1 Sol hỗ trợ dạng all_turns của việc phát lại đó. Một kênh tóm tắt không phải là một dấu vết dễ đọc, và việc coi hai thứ đó là một chính là cách một tuyên bố về an toàn được đưa ra bằng ảnh chụp màn hình.

Điều có thể đo lường được thì ở ngay bên cạnh và thú vị hơn đối với bất kỳ ai đang kiểm toán một agent. Đánh giá ngày 9 tháng 10 của Sonar về GPT-6.1 Sol, được chạy đối chiếu với GPT-6 Sol ở mức nỗ lực trung bình trên 4,444 tác vụ Java, cho thấy token suy luận giảm 51.4% — từ 2.64M xuống 1.28M — trong khi tỷ trọng của suy luận trong đầu ra giảm từ 41.8% xuống 19.5%, đầu ra tăng, và tỷ lệ vượt qua chức năng cải thiện từ 83.09% lên 85.29%. Cùng lượt chạy đó cho thấy mật độ lỗ hổng giảm 32.4% nhưng các phát hiện về độ tin cậy ở mức nghiêm trọng tăng từ 21 lên 46, trong đó lỗi đồng thời là hạng mục lớn nhất với 196 phát hiện. Đó là một đánh đổi mà người đánh giá có thể dựa vào để hành động. “Trace dễ đọc” thì không, bởi vì trace không phải là thứ đang được trả về.

Đối với một dự án di chuyển, điều này quan trọng theo một cách cụ thể: dấu vết kiểm toán của bạn là diff và đầu ra kiểm thử, không phải lời tường thuật của mô hình. Hãy dự trù năng lực rà soát cho phù hợp — phát hiện của Sonar rằng lượng mã được tạo nhiều hơn 39,4% tạo ra tổng cộng 12.982 phát hiện so với 9.859 chính là dạng chi phí ẩn sau một điểm số benchmark.

Tự mình vận hành cả hai nhánh

Vấn đề thực tế với một so sánh như thế này là nhánh cơ sở và nhánh mới thường là hai hợp đồng, hai khóa và hai quan hệ thanh toán, đủ ma sát đến mức không ai chạy nhánh cơ sở. Cả hai mô hình đều nằm trong danh mục của chúng tôi dưới một khóa: openai/gpt-6.1-sol và openai/gpt-5.6-sol, theo giá niêm yết của O​penAI với mức cộng thêm 0%, nên bạn sẽ trả cho nhà cung cấp đúng $2.00 cho đầu vào và $10.00 cho đầu ra trên mỗi triệu token, với đầu vào được lưu đệm ở $0.10 và ghi bộ nhớ đệm ở $2.50, và bậc trên 272K được chuyển nguyên giá ở $4.00, $0.20, $5.00 và $15.00. Thay đổi giá từ nhà cung cấp có hiệu lực tại đây ngay trong ngày được công bố, thay vì chờ đến lần xem xét hợp đồng tiếp theo.

Chính cơ chế chuyển tiếp đó là thứ khiến một bài đánh giá trong cùng ngày trở nên rẻ để chạy: chạy bộ kiểm thử nhanh MultiLangBench trên cả hai mô hình, trả theo giá niêm yết cho từng mô hình, và bạn có một con số về chính chuỗi công cụ của mình thay vì của OpenAI. Chuyển đổi dự phòng tự động là nửa còn lại của lập luận — nếu mô hình mới hơn suy giảm giữa chừng hoặc một tuyến bị giới hạn tần suất, yêu cầu không thất bại theo nó, và đó là điều cho phép bạn đặt một mô hình chưa được chứng minh trước một quy trình di chuyển trước khi bạn có bằng chứng của riêng mình.

Bộ khung MultiLangBench là công khai còn các ca di trú COBOL thì không, vì vậy phép thử trung thực duy nhất đối với con số 86,6% là phép thử do bạn tự xây dựng: lấy mẫu vài trăm chương trình COBOL của chính bạn, dịch chúng, rồi so sánh từng byte đầu ra với hành vi gốc. Việc đó tốn một tuần làm việc và đáng giá hơn bảng của nhà cung cấp.

Xem gì tiếp theo

Ba điều sẽ thay đổi bức tranh này, và chưa điều nào xảy ra. Việc OpenAI công bố các ca chuyển đổi COBOL, hoặc một phòng thí nghiệm độc lập chạy lại chúng, sẽ biến một con số của nhà cung cấp thành một phép đo. Một bên thứ ba tái tạo bảng theo từng ngôn ngữ của MultiLangBench sẽ cho chúng ta biết liệu 72,1% của COBOL là đặc tính của ngôn ngữ hay của bộ kiểm thử. Và hồ sơ benchmark độc lập của mô hình — Artificial Analysis hiện xếp GPT-6.1 Sol ở Intelligence Index 52, đứng thứ mười hai trong 214 mô hình, với 55,2 token đầu ra mỗi giây và 0,72 USD mỗi tác vụ chỉ số — là phép kiểm tra hoàn toàn không dựa vào các đánh giá của chính OpenAI.

Cho đến lúc đó, bản tóm tắt hữu ích thì ngắn gọn. GPT-6.1 Sol là một mô hình từ ngày 29 tháng 9 mà năng lực xử lý mã cũ của nó được ghi nhận vào ngày 19 tháng 10, trong một bài đánh giá bạn có thể chạy và một bài bạn không thể. Bài có thể chạy nói rằng thế hệ mới ở một đẳng cấp khác về các ngôn ngữ ít tài nguyên. Bài không thể chạy nói rằng việc chuyển đổi COBOL giờ đây đáng để làm thí điểm. Chỉ có cơ sở mã của riêng bạn mới có thể biến một trong hai điều đó thành quyết định.