Cách đọc các benchmark lập trình AI và tránh chọn người thắng trên giấy

Tóm lại: con số “giải được 76 phần trăm số tác vụ” tự nó gần như chẳng nói lên điều gì. Điều quan trọng là bộ tác vụ nào tạo ra con số đó, mô hình và agent wrapper nào được tính cùng nhau, các tác vụ mới hay cũ, và chi phí là bao nhiêu. Không có những điều kiện này, tỷ lệ phần trăm chỉ phù hợp để đưa lên biểu ngữ quảng cáo, chứ không giúp bạn chọn công cụ.

Tiếp theo, tôi sẽ giải thích bằng ngôn ngữ đơn giản hai benchmark lập trình chính đo lường điều gì, cái bẫy ẩn ở đâu trong các bảng, và cách kiểm tra bất kỳ bảng xếp hạng nào trong một phút trước khi dựa vào nó. Dưới đây bàn định nghĩa benchmark lịch sử, không tái hiện ảnh leaderboard cặp trực tiếp. So điểm hoặc phí hiện tại cần bảng có link, ngày và cấu hình riêng.

Đọc thêm về cách làm việc với các mô hình trong tài liệu Ailoot.

Tỷ lệ phần trăm của benchmark thực sự cho thấy điều gì?#

Benchmark hoạt động rất đơn giản. Có sẵn một danh sách các tác vụ lập trình. Công cụ được giao từng tác vụ, gửi lại mã, rồi hệ thống chạy các bài kiểm thử tự động để xem lời giải có hoạt động hay không. Tỷ lệ tác vụ vượt qua chính là phần trăm hiển thị trong bảng.

Điểm mạnh ở đây là việc đánh giá khách quan. Bài kiểm thử chỉ có thể xanh hoặc đỏ; không ai chấm điểm kiểu “nhìn qua thấy ổn”. Xét về mặt này, benchmark trung thực hơn mọi bài đánh giá hay lời chứng thực.

Điểm yếu cũng chính là điều đó. Bộ tác vụ hữu hạn và được mọi người biết trước, kể cả những người huấn luyện mô hình. Mỗi phép đo có điều kiện riêng. Và gần như chắc chắn các tác vụ trong bộ không giống việc bạn làm. Điều này dẫn đến tất cả những cái bẫy tôi sẽ bàn dưới đây. Tỷ lệ phần trăm mô tả cách công cụ hoạt động trên danh sách tác vụ khép kín của người khác, và không thể áp dụng trực tiếp cho dự án của bạn.

HumanEval đo lường điều gì, và vì sao giờ không thể chọn công cụ dựa vào nó nữa?#

HumanEval do OpenAI tạo ra và phát hành vào năm 2021 cùng với mô hình Codex. Bộ này có 164 tác vụ Python nhỏ: mô hình được cung cấp mô tả hàm bằng lời, viết phần thân hàm, rồi một bộ bài kiểm thử tự động kiểm tra xem hàm có hoạt động đúng hay không.

Vào thời điểm đó, đây là cách phân biệt tốt. Trong bài báo của chính mình, các tác giả đưa ra con số này: Codex đầu tiên giải được 28.8 phần trăm số tác vụ trong một lần thử, còn GPT-3 thông thường không giải được tác vụ nào.

Kể từ đó, các mô hình đã phát triển, và ngày nay những mô hình mạnh hoàn thành gần như toàn bộ HumanEval. Khi mọi mô hình đều đạt điểm gần 100 phần trăm, bảng không còn phân biệt được điều gì: khác biệt giữa các công cụ biến mất. Tình trạng này được gọi là bão hòa benchmark, và HumanEval đã ở trong tình trạng đó từ lâu.

Lỗ hổng thứ hai nghiêm trọng hơn. Các tác vụ rất nhỏ: viết một hàm dựa trên mô tả. Công việc thực tế của bạn khác hẳn—đó là làm việc với một dự án lớn có lịch sử, nơi bạn cần hiểu mã của người khác, tìm lỗi và tránh làm hỏng các phần mã liền kề. Có một khoảng cách lớn giữa “viết một hàm từ đầu” và “sửa lỗi trong một dự án đang hoạt động”. Vì vậy, điểm HumanEval cao ngày nay không còn là lý do để chọn công cụ; nó giống dấu hiệu cho biết “các kiến thức cơ bản đã được đáp ứng” hơn.

SWE-bench đo lường điều gì, và vì sao nó gần với công việc thực tế hơn?#

SWE-bench khác biệt căn bản, vì vậy cũng thú vị hơn. Bộ này được xây dựng từ các issue và pull request thực tế trong những dự án GitHub phổ biến. Theo các tác giả, bộ gồm 2,294 tác vụ từ 12 kho mã Python lớn và được phát hành vào tháng 10 năm 2023.

Cách đánh giá rất rõ ràng. Họ lấy một thời điểm trong dự án khi có lỗi thực tế cùng một bộ bài kiểm thử đã thất bại lúc đó. Công cụ được cung cấp mô tả vấn đề và chỉnh sửa mã. Sau đó, chính các bài kiểm thử đó được chạy lại: nếu chúng chuyển sang màu xanh, tác vụ thực sự đã được giải quyết; ở đây không ai tin vào những lời hứa suông.

Các con số ban đầu cho thấy việc này khó hơn các bài toán đồ chơi đến mức nào. Phương pháp baseline đầu tiên chỉ đạt 1.96 phần trăm trên SWE-bench, còn agent đầu tiên đạt 12.47 phần trăm. Nói cách khác, ngay cả việc tiếp cận công việc lập trình thực tế cũng rất khó; tỷ lệ phần trăm tăng lên sau đó, nhưng ban đầu gần như bằng không.

Vì vậy, khi thấy những con số lớn trong bảng xếp hạng các agent lập trình AI hiện nay, chúng thường đến từ SWE-bench hoặc tập con gồm 500 tác vụ đã được con người xác minh, gọi là SWE-bench Verified. Đây là một benchmark hợp lý. Nhưng nó cũng có những điều kiện mà nếu bỏ qua, tỷ lệ phần trăm sẽ gây hiểu lầm; đó là điều tôi sẽ bàn tiếp theo.

Ngay cả benchmark trung thực nhất trong bảng cũng chưa phải kết quả trên dự án của bạn. Kết quả phụ thuộc vào cách bạn làm việc với công cụ, còn dòng đầu bảng xếp hạng quyết định rất ít. Bối cảnh rõ ràng cải thiện tỷ lệ thành công cá nhân của bạn rõ rệt hơn nhiều so với việc chọn mô hình từ một bảng.

Vì sao cùng một mô hình lại có tỷ lệ phần trăm khác nhau?#

Đây là nơi ẩn giấu sai lầm phổ biến nhất khi đọc benchmark. Mọi người đọc bảng như bảng xếp hạng mô hình: mô hình này thông minh hơn mô hình kia hai phần trăm. Nhưng có ba yếu tố ảnh hưởng đến tỷ lệ phần trăm, và mô hình chỉ là một trong số đó.

Thứ nhất là bản thân mô hình. Thứ hai là agent wrapper bao quanh nó: một chương trình cho phép mô hình điều hướng tệp, chạy lệnh, đọc lỗi và viết lại mã. Cùng một mô hình trong wrapper thông minh và wrapper đơn giản sẽ cho kết quả khác nhau, vì wrapper quyết định cách mô hình làm việc với dự án. Thứ ba là mức suy luận—tức mức độ mô hình suy nghĩ kỹ qua từng bước. Mô hình suy nghĩ càng lâu thì tỷ lệ phần trăm thường càng cao, và chi phí cũng cao hơn.

So sánh tái hiện được cần giữ đầy đủ cấu hình. Dùng mẫu báo cáo sau, không phải leaderboard đo được:

Nhờ đó thấy điều đã đổi và so sánh có thực sự tách thiết lập suy luận không. Ví dụ số cũ không link không được coi là kết quả đo.

Quy tắc là: một bảng xếp hạng tốt luôn nêu rõ mô hình, wrapper và mức suy luận nào đã được dùng. Nếu bảng chỉ có tên mô hình và tỷ lệ phần trăm mà không nói rõ wrapper, thì khó tin cậy: bạn không biết thực sự đã đo lường điều gì. Bài viết về bảng xếp hạng các agent lập trình AI giải thích thêm tổ hợp “mô hình cộng wrapper” gồm những gì.

Điều này cũng giải thích vì sao một công cụ đạt điểm cao nhất đôi khi lại gặp khó khăn với bạn. Benchmark đo mô hình bên trong wrapper đã được tinh chỉnh của người khác, trên tác vụ của người khác. Wrapper, dự án và bối cảnh bạn cung cấp cho mô hình đều khác. Trên dự án của bạn, kết quả phụ thuộc vào bối cảnh; dòng trong bảng chỉ là yếu tố thứ yếu.

Vì sao tác vụ “hết hạn”, và rò rỉ dữ liệu huấn luyện là gì?#

Đây là cái bẫy không nhìn thấy trong chính con số nhưng làm suy giảm độ tin cậy của nó hơn bất cứ điều gì khác. Mô hình được huấn luyện trên lượng văn bản và mã khổng lồ thu thập từ internet. Gần như tất cả benchmark lập trình đều được công khai: tác vụ, bài kiểm thử và lời giải tham chiếu.

Cơ chế rất đơn giản. Nếu một tác vụ và lời giải đúng của nó lọt vào dữ liệu huấn luyện, mô hình có thể đã ghi nhớ chúng. Trong lúc đánh giá, thay vì giải bài, mô hình có thể chỉ lấy lại câu trả lời quen thuộc từ trí nhớ. Trông có vẻ như đã giải được, nhưng thực chất chỉ là nhớ lại. Hiện tượng này được gọi là rò rỉ dữ liệu huấn luyện hoặc nhiễm bẩn dữ liệu.

Bộ tác vụ càng cũ và phổ biến thì rủi ro càng cao. HumanEval đã có trên mạng từ năm 2021; nó đã được viết lại, phân tích và đưa vào vô số bộ dữ liệu nhiều lần. Sẽ thật lạ nếu kỳ vọng một mô hình hiện đại chưa từng “thấy nó”. Vì vậy, độ mới của tác vụ là một chỉ báo chất lượng riêng của benchmark. Một bộ tốt được cập nhật thường xuyên hoặc giữ một số tác vụ kín để chúng không thể bị học trước.

Bạn nên làm gì khi đọc bảng xếp hạng? Kiểm tra ngày của các tác vụ và xem bộ dữ liệu có được cập nhật không. Nếu benchmark được xây dựng từ các lỗi mới trong những tháng gần đây, đáng để tin cậy hơn. Nếu đó là bộ từ năm năm trước, tỷ lệ cao trên bộ này nói nhiều hơn về trí nhớ tốt của mô hình chứ không phải khả năng giải tác vụ mới của bạn. Hiệu ứng này được minh họa bằng ví dụ cụ thể trong bài viết về benchmark FrontierCode mới, nơi các tác vụ được cố ý tạo mới.

Vì sao chênh lệch vài điểm phần trăm thường chẳng có ý nghĩa gì?#

Một điều khác khiến vị trí đầu bảng dễ gây hiểu lầm: mô hình không phản hồi giống nhau trong mọi lần chạy. Với cùng một prompt, nó có thể chọn lối suy luận hơi khác. Vì vậy, nếu chạy một công cụ nhiều lần trên một bộ tác vụ, tỷ lệ phần trăm sẽ dao động nhẹ giữa các lần chạy; dao động này được gọi là độ biến thiên.

Bài học thực tế rất đơn giản. Khi hai dòng trong bảng xếp hạng chênh nhau một hoặc hai phần trăm, khác biệt đó có thể chỉ là nhiễu. Chạy theo một công cụ “cao hơn hai phần trăm” là không khôn ngoan: hai công cụ có thể dễ dàng đổi vị trí trong lần chạy tiếp theo. Chỉ nên xem khác biệt là đáng kể khi nó rõ rệt và duy trì trên một bộ tác vụ lớn; vài điểm phần trăm không đạt ngưỡng đó.

Điều cuối cùng, gần như luôn quan trọng hơn chính tỷ lệ phần trăm, là giá cả. Kết quả tương tự có thể có chi phí rất khác nhau. So phí cần cả cấu hình mô hình/harness và toàn chi cho tập đánh giá, gồm lần thất bại. Chia cho mọi việc thử để có phí mỗi lần, hoặc việc giải để có phí mỗi việc giải; ghi rõ mẫu số. Bài không cung cấp phép đo phí cặp có nguồn. Vì vậy, hãy luôn đọc một dòng xếp hạng cùng với giá của nó, bởi tỷ lệ phần trăm tự nó chẳng có nhiều ý nghĩa. Bài viết về chi phí cho một tác vụ được giải quyết giải thích cách so sánh công cụ công bằng theo chi phí.

Làm thế nào đọc bất kỳ bảng benchmark nào trong một phút?#

Để tôi cô đọng tất cả thành một danh sách kiểm tra ngắn. Mở bất kỳ bảng xếp hạng nào và lần lượt xem bảy điểm sau.

1. Bộ tác vụ nào? HumanEval hiện yếu; SWE-bench gần với công việc thực tế hơn. Nếu không nêu tên bộ tác vụ, bạn không cần đọc tiếp.
2. Tác vụ mới hay cũ? Bộ mới hoặc kín một phần đáng tin cậy hơn bộ công khai đã cũ mà mô hình có thể đã học.
3. Đã đo mô hình nào? Tên và phiên bản chính xác, không phải từ “AI” mơ hồ hay tên dòng mô hình.
4. Agent wrapper nào? Tỷ lệ phần trăm thuộc về tổ hợp “mô hình cộng wrapper”. Nếu không nêu wrapper, bạn không biết đã đo điều gì.
5. Mức suy luận nào? Cùng một mô hình ở các mức khác nhau sẽ có tỷ lệ phần trăm và chi phí khác nhau.
6. Một tác vụ tốn bao nhiêu? Kết quả tương tự có thể chênh nhau nhiều lần về giá. Hãy đọc tỷ lệ phần trăm cùng với chi phí.
7. Độ biến thiên ra sao? Chênh lệch một hoặc hai điểm giữa các dòng thường chỉ là nhiễu.

Có câu hỏi thứ tám, liên quan đến bạn: Các tác vụ trong bộ có giống công việc của bạn không? Một benchmark gồm các tác vụ Python nói được rất ít với người đang xây dựng trang web hoặc bot bằng bộ công cụ khác. Ngay cả con số trung thực trên tác vụ của người khác cũng không đảm bảo kết quả trong dự án của bạn. Chỉ có một cách đáng tin cậy để kiểm tra: chạy một vài tác vụ điển hình của bạn qua công cụ rồi tự xem kết quả. Bài viết về cách kiểm tra mã do AI tạo giải thích cách biết mã có hoạt động hay không nếu bạn không tự lập trình.

Vậy cuối cùng bạn nên xem điều gì?#

Ý chính của toàn bài ngắn gọn thế này: một vị trí trong bảng xếp hạng là lý do để xem xét kỹ hơn một công cụ, nhưng bạn sẽ phải tự tìm hiểu thêm. Con số cao chỉ nói rằng công cụ làm khá tốt trên một danh sách tác vụ đóng cụ thể, trong những điều kiện cụ thể. Tỷ lệ phần trăm không cho thấy các điều kiện đó có phù hợp với bạn hay không.

Vì vậy, hãy đọc thông tin bên dưới dòng xếp hạng: các tác vụ nào, mới đến đâu, tổ hợp mô hình và wrapper nào, mức suy luận nào, chi phí bao nhiêu và khác biệt có chìm trong nhiễu không. Một bảng không trả lời những câu hỏi này chỉ phù hợp để đưa lên biểu ngữ quảng cáo. Bài đánh giá nên dùng công cụ nào để lập trình vào năm 2026 giải thích nên chọn công cụ nào cho công việc của bạn ngay từ đầu.

Và đây là điều quan trọng hơn bất kỳ benchmark nào. Ngay cả công cụ tốt nhất trong bảng xếp hạng cũng gặp khó khăn với bối cảnh lộn xộn và hoạt động tốt với bối cảnh rõ ràng. Tỷ lệ thành công cá nhân của bạn phụ thuộc vào những gì bạn đưa cho mô hình và cách bạn xác định nhiệm vụ; dòng trong bảng chỉ là yếu tố thứ yếu. Bảng xếp hạng giúp loại bỏ các lựa chọn rõ ràng là yếu, nhưng chính bạn mới là người tạo ra kết quả.

Để tiếp tục làm việc—Ailoot.