Đánh giá hiệu năng Opus 5 trên bộ benchmark SlopCodeBench

Đánh giá Opus 5 trên SlopCodeBench

chúng tôi đã có những kết quả đánh giá tốt hơn

Tôi đã từng viết một điều gì đó đại loại như:

KHÔNG CÓ BỘ ĐÁNH GIÁ (BENCHMARK) NÀO TỐT để đo lường khả năng duy trì chất lượng codebase của một mô hình

Điều đó không hoàn toàn đúng. Tôi chẳng thích gì hơn việc cố tình giấu đi những thông tin quan trọng ngay từ đầu.

Thứ Sáu tuần trước, tôi đã tìm hiểu về SlopCodeBench, một bộ benchmark lập trình dài hạn khá mới (tháng 3 năm 2026) từ phòng thí nghiệm của @GOrlanski tại UW Madison. Nó giải quyết vấn đề khiến tôi bận tâm nhất về các bộ benchmark lập trình - đó là ngay cả những bộ benchmark "lớn" và phức tạp hơn vẫn tiết lộ toàn bộ vấn đề ngay từ đầu:

Ngược lại, mỗi thử thách trong SlopCodeBench đều có nhiều "checkpoint" (điểm kiểm tra) - mô hình không biết toàn bộ vấn đề ngay từ đầu, nó phải phát triển codebase theo thời gian khi các yêu cầu mới được đưa ra.

Đây là một bài báo hay. Nó không quá dài. Bạn nên đọc nó.

Điều thú vị về bộ benchmark này là nó chưa bị bão hòa - tại thời điểm chạy thử, các mô hình tốt nhất hiện có là GPT-5.4 và Opus 4.6 chỉ đạt tỷ lệ vượt qua nghiêm ngặt (strict pass rate) lần lượt là 11% và 17%.

đánh giá opus 5 trên slopcodebench

Vào thứ Sáu, tôi đã chạy ba mô hình claude (Opus 4.8, Sonnet 5 và Opus 5) qua một tập con của SlopCodeBench và theo dõi trực tiếp trong sáu giờ. Về mặt kỹ thuật, Opus 5 thắng nhưng theo tôi thì không mô hình nào làm tốt cả. Tôi sẽ sớm đăng thêm kết quả với sự góp mặt của Fable và 5.6 Sol.

Điểm đáng chú ý nhất là Opus 5 đạt 24% trên tập con nhỏ của bộ benchmark mà tôi đã chạy - không cao hơn nhiều so với tỷ lệ vượt qua nghiêm ngặt 17% của Opus 4.6 trong bài báo gốc. Tất cả các mô hình được thử nghiệm đều cho thấy sự gia tăng đáng kể về độ dài, độ phức tạp và một loạt các chỉ số "code smell" khác trong suốt quá trình thực hiện mỗi thử thách, với việc Opus 5 viết số lượng hàm/đối tượng có thể gọi (callables) gấp năm lần so với Opus 4.8 trong cùng một tập hợp các thử thách.

Theo cách hiểu cá nhân của tôi về tỷ lệ vượt qua 23% này, SlopCodeBench cuối cùng cũng đưa ra được một tín hiệu cho điều mà trước đây tôi chỉ có thể tranh luận dựa trên cảm tính - đó là đối với công việc kỹ thuật phần mềm thực tế, khi phải giải quyết từng vấn đề một, các mô hình ngày nay không thể được tin tưởng để vận hành tự động mà không cần sự điều hướng.

tập con của bộ benchmark

tôi đã yêu cầu claude chọn ra 3 vấn đề từ kho lưu trữ, tổng cộng 17 checkpoint, bao gồm hỗn hợp các vấn đề được gắn nhãn dễ/trung bình/khó:

Có một phụ lục ở cuối giải thích chi tiết tất cả 17 checkpoint nhưng tôi sẽ không đưa tất cả vào đây.

và sau đó tôi chạy chúng trên cả ba mô hình, song song, với một cửa sổ ngữ cảnh mới cho mỗi checkpoint. Tất cả các mô hình đều nhận được cùng một câu lệnh (prompt) và chạy trong môi trường kiểm thử (harness) của claude.

chỉ số mà tôi quyết định quan tâm là "strict pass" (vượt qua nghiêm ngặt): mọi thứ mới đều phải đúng, bao gồm cả mọi bài kiểm tra hồi quy (regression test) được kế thừa từ các checkpoint trước đó.

Một mô hình thất bại ở một checkpoint nếu giải pháp có lỗi - các lỗi được phát hiện bằng cách lấy đầu ra của mô hình, một CLI để chạy hoặc trong một số trường hợp ví dụ như một api server để kiểm tra, và chạy một bộ các bài kiểm tra hộp đen (black-box tests) đối với điểm truy cập (entrypoint) được tạo ra.

Một lần nữa, tiêu chí vượt qua nghiêm ngặt có nghĩa là nếu một mô hình làm hỏng điều gì đó ở checkpoint 4, nó không thể vượt qua các checkpoint tiếp theo vì phần mã bị lỗi đó sẽ tiếp tục tồn tại (trừ khi mô hình vô tình sửa được một trường hợp đánh giá ở checkpoint 6 vốn đã bị hỏng ở checkpoint 4, nhưng chúng tôi không thấy điều này xảy ra trong thực tế).

Đối với tất cả 9 lần chạy thử nghiệm, không có mô hình nào đi đến cuối bất kỳ thử thách nào với mọi thứ đều vượt qua, ngay cả ở vấn đề được đánh dấu là độ khó "dễ".

trong khi nó chạy

checkpoint đầu tiên của sonnet tốn kém hơn nhưng đến cuối vấn đề 1, sonnet trở thành mô hình rẻ nhất trong ba mô hình. (có vẻ như một khi các yếu tố cơ bản đã được xây dựng và công việc chuyển sang giai đoạn bảo trì, thì khả năng tiết kiệm chi phí bắt đầu phát huy tác dụng)

Đối với thử thách đầu tiên, các mô hình thế hệ trước tích lũy lỗi đều đặn, Opus 5 mắc một lỗi ở mỗi checkpoint 4 và 5.

trong hai giờ đầu tiên, opus 5 là mô hình duy nhất có bất kỳ lần vượt qua nghiêm ngặt nào — ba lần liên tiếp ngay từ đầu.

Mọi thứ thay đổi khi chúng tôi tiếp tục. Claude đã cập nhật html một cách chăm chỉ.

So với các mô hình khác, Opus 5 về mặt kỹ thuật tốt hơn ở vấn đề 1 (circuit_eval). Nhưng sau khi hoàn thành xuất sắc ba checkpoint đầu tiên, mọi giải pháp tiếp theo đều có ít nhất một lỗi (trường hợp kiểm thử thất bại).

kết quả cuối cùng

Nếu định nghĩa của chúng tôi về thành công là "đạt đến checkpoint cuối cùng mà không có lỗi" thì opus 5 đã thất bại ở cả ba vấn đề, nhưng nó thất bại ít tệ hơn một chút so với các mô hình khác.

Đối với báo cáo chi phí so với lỗi, tôi thực sự ghét những kiểu diễn đạt đặc trưng của claude (claude-isms) nhưng tôi quyết định giữ lại câu này:

mỗi đô la đều đổi lấy sự chính xác. không ai mua đủ lượng sự chính xác đó.

(rõ ràng là tập con nhỏ này của bộ benchmark không thể cho chúng ta biết chắc chắn rằng việc chi nhiều tiền hơn sẽ dẫn đến tỷ lệ vượt qua cao hơn)

về các lần vượt qua nghiêm ngặt, Opus 5 đạt được bốn lần (tỷ lệ vượt qua 24%) (ba checkpoint đầu của circuit_eval, cộng với ck1 của database_migration).

cả opus 4.8 và sonnet 5 đều đạt được một lần vượt qua nghiêm ngặt (tỷ lệ vượt qua 6%), đó chính là ck1 của database_migration mà opus 5 cũng đạt được.

vì vậy người chiến thắng đã vượt qua 4/17, và 3 trong số đó là các checkpoint mở đầu của một vấn đề. Có vẻ như chúng ta đang có một bộ benchmark chưa bị bão hòa cho thế hệ mô hình tiếp theo. làm tốt lắm @GOrlanski và đội ngũ.

thước đo sự cẩu thả (slop meter)

Tôi vẫn chưa hoàn toàn bị thuyết phục về việc "dùng linter để loại bỏ sự cẩu thả", bởi vì tôi không nghĩ rằng hiện tại có thể phân tích một cách xác định "khả năng bảo trì" của một checkpoint codebase cụ thể. Nhưng chúng là những thứ thú vị để theo dõi

Các chỉ số chất lượng mã là những thứ thú vị để theo dõi, và chúng có lẽ đúng về mặt định hướng, và

Với SlopCodeBench, bạn nhận được kết quả sau mỗi checkpoint trên nhiều chỉ số chất lượng khác nhau. Có 41 chỉ số trong tệp kết quả. Được nhóm lại một cách đại khái: