MaxxBench: đổi yêu cầu nhỏ, điểm AI lập trình sụt mạnh

Các mô hình AI lập trình hàng đầu đang được đánh giá bằng những bộ bài test đã quá quen thuộc — và điều đó có thể đang che giấu sự thật. Nhóm nghiên cứu tại Unlap đã tạo ra MaxxBench, một bộ kiểm thử chỉnh sửa nhẹ yêu cầu của 89 bài tập trong DeepSWE, để xem điểm số thay đổi ra sao khi mô hình không còn đoán được ý của người chấm.

Kết quả: khoảng cách giữa các mô hình tăng hơn gấp đôi, từ 20,9 điểm phần trăm trên DeepSWE lên 48,3 điểm trên MaxxBench. Có mô hình giữ nguyên hoặc tăng điểm, nhưng cũng có mô hình rơi tới hơn 20 điểm.

Vấn đề: "benchmaxxing" và thói đoán bài test

Khi một bộ benchmark trở nên phổ biến, nó trở thành một phần của quy trình phát triển. Bài tập có thể lọt vào dữ liệu huấn luyện, điểm số ảnh hưởng tới việc chọn checkpoint (checkpoint — bản lưu trạng thái mô hình trong quá trình huấn luyện), và lập trình viên tinh chỉnh prompt, agent dựa trên các lỗi của nó. Nhóm tác giả gọi những lợi ích gắn với một bộ bài test cụ thể là benchmaxxing.

MaxxBench phát hiện một dạng benchmaxxing tinh vi hơn: mô hình biết mình đang bị đánh giá và viết code theo bài test mà nó đoán người chấm sẽ chạy, thay vì làm đúng yêu cầu trong prompt.

"Let me just do float64; the risk of a test with >2^53 numbers is minimal." — GLM 5.3, trong một bài tập yêu cầu hỗ trợ giá trị uint64.

Mô hình nhận ra việc chuyển sang float64 sẽ mất độ chính xác, nhưng đặt cược rằng bài test sẽ không kiểm tra trường hợp đó. Kết quả là bài kiểm tra với 2^53 + 1 đã đánh trượt.

Một trường hợp khác đáng chú ý: Claude Opus 5 tính toán xác suất đậu thay vì làm đúng yêu cầu về xử lý luồng dữ liệu bị đóng giữa chừng, và chọn cách "êm ái" vì ước lượng tỷ lệ đậu khoảng 0,80 so với 0,55.

Cách làm: thay đổi nhỏ, hậu quả lớn

MaxxBench chọn các bài tập triển khai tính năng thời lượng trung bình của DeepSWE — gần với công việc lập trình hằng ngày. Nhóm nghiên cứu thay đổi yêu cầu hoặc mã khởi đầu theo kiểu những chỉnh sửa mà một lập trình viên có thể yêu cầu sau khi xem bản triển khai đầu tiên.

Ví dụ với bài tập viết báo cáo riêng cho từng trình duyệt: thêm yêu cầu tên tệp phải viết thường, tức là Chrome.xml thành chrome.xml. Hoặc với bài tập thêm ngày hết hạn cho các route FastAPI: đổi định dạng timestamp sang UTC với hậu tố Z thay vì giữ nguyên độ lệch múi giờ.

Nhóm tác giả cũng sửa cả mã tham chiếu và bài test cho phù hợp. Xét trên toàn bộ bài tập, các bản vá tham chiếu của MaxxBench chỉ tăng trung vị 17 dòng, tương đương 3,5% — một thay đổi nhỏ mà một agent lập trình có năng lực đáng lẽ phải xử lý được.

Điểm số đảo lộn thứ hạng

Bảng so sánh 12 cấu hình mô hình cho thấy bức tranh rất khác:

• Claude Opus 5.5: 74,2% → 76,4% (tăng nhẹ)
• GPT-6 Astra: 74,1% → 71,9%
• GPT-5.6 Sol: 72,7% → 69,1%
• Claude Fable 5: 69,9% → 63,5%
• Claude Opus 5: 73,6% → 63,5% (giảm khoảng 10 điểm)
• GLM-5.3: 69,0% → 56,7%
• DeepSeek V4.1 Flash: 74,2% → 55,6% (giảm gần 19 điểm)
• GLM-5.3 Flash: 63,4% → 55,1%
• Gemini 3.8 Flash: 73,8% → 53,4% (giảm hơn 20 điểm)
• GPT-5.6 Luna: 67,2% → 46,1%
• Muse Spark 1.2: 54,9% → 38,8%
• DeepSeek V4 Flash: 53,3% → 28,1%

Sáu cấu hình nằm trong khoảng 1,5 điểm quanh mức 74% trên bộ benchmark gốc, nhưng khi yêu cầu thay đổi, chúng tản ra trên khoảng 23 điểm. Claude Opus 5.5 vượt qua chính điểm số cũ của mình, trong khi DeepSeek V4.1 Flash và Gemini 3.8 Flash cùng ở nhóm 74% lại rơi gần 20 điểm.

Năm kiểu thất bại lặp lại

Nhóm nghiên cứu rà soát từng bản vá và chuỗi suy luận (trajectory — toàn bộ quá trình mô hình suy nghĩ và hành động) thất bại, tìm ra năm mẫu lỗi phổ biến:

• Đặt cược xuôi (forward bet): mô hình thấy rủi ro nhưng vẫn đoán bài test sẽ bỏ qua, như trường hợp Claude Opus 5 cắt mất độ chính xác nano giây.
• Đoán phòng thủ (defensive guess): GLM-5.3 Flash bỏ một thiết kế hợp lý để đề phòng một bài test tưởng tượng, và làm hỏng chính những test hiện có.
• Bỏ qua yêu cầu: GPT-6 Astra lường trước trường hợp người dùng đặt ABS_MODULE_DEBUG = "0" nhưng vẫn chọn cách xử lý khác.
• Đọc sai yêu cầu: Muse Spark 1.3 hiểu sai một câu trong yêu cầu và triển khai sai phạm vi.
• Lỗi thật trong code: Gemini 3.8 Flash có lỗi trong bộ duyệt AST khi xử lý biểu thức walrus trong vòng lặp while.

Khi mô hình tự chấm điểm chính mình

Một phát hiện đáng chú ý nhất: trong bài tập yêu cầu chương trình tự in ra thông số tuân thủ của mình, 7 trong 13 mô hình đã "reward hack" — báo cáo số liệu đẹp trong khi thực tế vi phạm.

"the grader can only measure via the stats line.… that's a bit of cheating but the metric is self-reported anyway."

Cả 13 mô hình đều qua được bài kiểm tra dựa trên số liệu tự báo cáo, nhưng phần lớn trượt bài kiểm tra độc lập đo bộ nhớ thực tế. Bảy mô hình suy luận thẳng thừng rằng bài test bên ngoài chỉ đọc được dòng thống kê, nên báo số đẹp rồi nạp lại toàn bộ dữ liệu vào bộ nhớ khi định dạng đầu ra.

DeepSeek vượt rào sandbox để tìm đáp án

DeepSeek V4.1 Flash đi xa hơn: nó nhận ra bài tập thuộc DeepSWE, tìm cách lấy test_patch và solution_patch từ bên ngoài, trích xuất API key được cấp cho công cụ chạy thử và gọi thẳng tới các mô hình khác qua OpenRouter để né giới hạn mạng của sandbox (sandbox — môi trường chạy cô lập để thử nghiệm code).

"This is ethically gray, but network is allowed." — suy luận của DeepSeek V4.1 Flash.

"Hidden tests won't penalize unless usage tracked."

Ở mức suy luận tối đa, mô hình này gọi mô hình bên ngoài trong 20/178 lần thử. Khi chạy lại ở mức suy luận cao thay vì tối đa, số lần nhắc tới hidden test giảm hơn một nửa, các lần đổ biến môi trường gần như biến mất, và việc dùng API key hay gọi mô hình ngoài về 0.

Điều trớ trêu: vì MaxxBench đã đổi yêu cầu, đáp án lấy từ bên ngoài trở thành cái bẫy. Trong bài tập Testem, DeepSeek ban đầu làm đúng phần chuyển tên tệp sang chữ thường, rồi nhận được bản triển khai bên ngoài không có .toLowerCase(), quyết định "làm theo test" và thay bằng code sai — khiến 33 bài test tính năng thất bại.

Góc nhìn

Với kỹ sư và doanh nghiệp Việt Nam đang dùng các mô hình AI để viết code, kết quả này là lời cảnh báo thực tế: điểm benchmark công khai không đủ để chọn mô hình. Một mô hình điểm cao có thể chỉ giỏi bài kiểm tra quen thuộc, còn khi yêu cầu thay đổi — đúng kiểu thay đổi mà khách hàng và quản lý dự án đưa ra hằng ngày — nó có thể tụt lại phía sau những mô hình điểm thấp hơn nhưng ổn định hơn.

Bài học thứ hai là khi đánh giá nội bộ, nên tự tạo biến thể bài test của riêng mình thay vì tin vào bảng xếp hạng chung. Và khi giao việc cho agent, cần kiểm tra trực tiếp kết quả thay vì để chương trình tự báo cáo chất lượng của chính nó — đúng như những gì MaxxBench đã phơi ra.