- SWE-bench Verified, từng là chỉ số tiêu biểu cho các tác vụ kỹ thuật phần mềm tự chủ, nay không còn phù hợp để đo năng lực của các mô hình frontier
- Khi mức cải thiện hiệu năng cao nhất gần đây chỉ giới hạn từ 74.9% lên 80.9%, ngày càng khó phân biệt các thất bại còn lại là do giới hạn của mô hình hay do lỗi của bộ dữ liệu
- Trong 138 bài toán được kiểm toán, 59.4% được xác nhận có lỗi nghiêm trọng trong thiết kế test hoặc mô tả bài toán; các test quá hạn chế hoặc quá bao quát còn loại cả những lời giải đúng về mặt chức năng
- Vì phép đánh giá dựa trên dữ liệu và codebase công khai, rất khó tránh ô nhiễm dữ liệu huấn luyện; một số mô hình gần như tái tạo nguyên vẹn gold patch chỉ từ mô tả tác vụ hoặc ID
- Vì vậy, việc báo cáo điểm SWE-bench Verified đã bị dừng lại, và trọng tâm đánh giá đang chuyển sang SWE-bench Pro cùng các benchmark không công khai
Vì sao benchmark này không còn đo được nữa
- SWE-bench Verified từng được dùng rộng rãi như chỉ số chuẩn để đo hiệu năng mô hình trong các tác vụ kỹ thuật phần mềm tự chủ, nhưng hiện nay đã giảm mạnh về mức độ phù hợp để đo năng lực của các mô hình frontier ở trình độ hiện tại
- Khi mức cải thiện hiệu năng cao nhất trong 6 tháng gần đây chỉ tăng từ 74.9% lên 80.9%, ngày càng khó phân biệt liệu các thất bại còn lại là do giới hạn của mô hình hay do khuyết tật của bộ dữ liệu
- Phân tích mới cho thấy test lỗi và ô nhiễm dữ liệu huấn luyện là hai vấn đề cốt lõi, khiến điểm số phản ánh mức độ mô hình đã tiếp xúc với benchmark nhiều hơn là năng lực lập trình thực tế
- Vì thế OpenAI đã ngừng báo cáo điểm SWE-bench Verified, đồng thời khuyến nghị các công ty phát triển mô hình khác cũng làm như vậy
- Là phương án thay thế, OpenAI khuyến nghị dùng SWE-bench Pro, vốn ít bị ô nhiễm hơn, và cũng đang xây dựng thêm các chỉ số đánh giá mới không bị ô nhiễm
Bối cảnh
- SWE-bench nguyên bản được công bố vào năm 2023, được tạo bằng cách ghép các GitHub issue đã được giải quyết với PR tương ứng từ 12 repository Python mã nguồn mở
- Với mỗi bài toán, mô hình chỉ được cung cấp codebase trước khi sửa và nội dung issue, rồi phải tạo ra thay đổi mã; tiêu chí đỗ là vượt qua toàn bộ test sau khi áp dụng bản sửa
- Có các test phải thất bại trước khi sửa và phải vượt qua sau khi sửa đúng
- Cũng bao gồm regression test để kiểm tra xem chức năng cũ có bị phá vỡ hay không
- Bản đánh giá gốc có các vấn đề như test quá cụ thể đến mức từ chối cả bản sửa đúng, đặc tả không đủ rõ dẫn đến nhiều cách diễn giải, hoặc test thất bại tùy theo khác biệt môi trường
- Để giảm các vấn đề này, SWE-bench Verified đã được tạo vào năm 2024, sàng lọc 1,699 bài toán bằng quy trình rà soát của chuyên gia để tạo thành bộ 500 bài toán
- Mỗi bài toán được 3 chuyên gia rà soát độc lập
Lỗi trong thiết kế test
- OpenAI chọn 138 bài toán mà o3 không thể giải quyết một cách nhất quán ngay cả sau 64 lần chạy độc lập để làm đối tượng kiểm toán, và mỗi trường hợp được ít nhất 6 kỹ sư phần mềm giàu kinh nghiệm rà soát độc lập
- Kết quả cho thấy trong 138 bài toán này, 59.4% có lỗi nghiêm trọng trong thiết kế test hoặc mô tả bài toán, đến mức ngay cả mô hình rất mạnh hoặc con người cũng rất khó hoặc không thể giải được
- 35.5% tác vụ trong diện kiểm toán chứa các test mang tính hạn chế, ép buộc chi tiết triển khai cụ thể
- Điều này có thể làm vô hiệu nhiều lời giải khác nhau nhưng vẫn đúng về mặt chức năng
- 18.8% tác vụ trong diện kiểm toán chứa các test quá bao quát, đòi hỏi thêm chức năng không hề có trong mô tả bài toán
- 5.1% còn lại gặp các vấn đề khác không thuộc rõ ràng vào hai nhóm trên
-
Trường hợp test mang tính hạn chế
- Trong pylint-dev__pylint-4551, test của PR import trực tiếp hàm
get_annotation, nhưng tên hàm này không xuất hiện trong đặc tả bài toán
- Vì vậy, ngay cả khi giải đúng về mặt chức năng, bài làm vẫn có thể trượt test do lỗi import nếu không triển khai đúng tên hàm cụ thể đó
-
Trường hợp test quá bao quát
- sympy__sympy-18199 thực chất được lấy từ một PR sửa đồng thời ba issue là #17373, #17377 và #18212
- Nhưng mô tả tác vụ trong SWE-bench Verified chỉ đề cập #18212, nên dù triển khai đúng theo mô tả, mô hình vẫn có thể trượt ở các test kiểm tra hai issue còn lại
Vấn đề ô nhiễm
- SWE-bench Verified cùng codebase của các repository liên quan và release note đều được công khai, sử dụng rộng rãi và thảo luận nhiều, nên rất khó tránh ô nhiễm dữ liệu
- OpenAI cũng xác nhận các dấu hiệu ô nhiễm trong chính mô hình nội bộ của mình, bao gồm cả trường hợp GPT‑5.2 giải được 31 tác vụ mà họ cho là gần như không thể giải bằng suy luận thuần túy
- Trong django__django-14725, test yêu cầu tham số
edit_only dù nó không xuất hiện trong đặc tả bài toán, nhưng GPT‑5.2 trong quá trình suy luận đã chỉ ra chính xác rằng tham số này được đưa vào ở Django 4.1
- Để đánh giá mức độ nghiêm trọng của ô nhiễm, OpenAI đã xây dựng môi trường red team tự động
- Với mỗi bài toán trong SWE-bench Verified, GPT‑5 điều tra dấu hiệu ô nhiễm của GPT‑5.2‑Chat, Claude Opus 4.5 và Gemini 3 Flash Preview
- GPT‑5 được cung cấp ID tác vụ, mô tả, gold patch và PR test, đồng thời được phép thay đổi prompt và chiến lược dẫn dắt trong tổng cộng 15 lượt
- Sau mỗi lượt, một mô hình đánh giá sẽ phân loại mức độ nghiêm trọng của ô nhiễm từ không có đến mạnh dựa trên lượng thông tin đặc thù của tác vụ mới bị lộ ra
- Các trường hợp ô nhiễm mạnh được một mô hình đánh giá bổ sung kiểm tra xem có rò rỉ thông tin quá mức hay không, rồi cuối cùng được rà soát thủ công
Các trường hợp ô nhiễm nghiêm trọng theo từng mô hình
-
GPT‑5.2
- Trong django__django-11451, chỉ với một đoạn mô tả tác vụ ngắn, mô hình đã xuất ra gold patch chính xác
- Nó tái hiện cả điều kiện trả về sớm khi
ModelBackend.authenticate() gặp username is None or password is None, cùng đường dẫn tệp và tên phương thức
-
Claude Opus 4.5
- Trong astropy__astropy-13236, mô hình trích dẫn nguyên văn đường dẫn tệp cần sửa
astropy/table/table.py, phương thức _convert_data_to_col, và cả chú thích inline trong diff
- Nó cũng khôi phục chính xác 4 dòng mã từng tự động chuyển structured ndarray thành
NdarrayMixin
-
Gemini 3 Flash
- Trong django__django-11099, ngay cả khi gần như không có thêm thông tin ngoài ID tác vụ, mô hình vẫn xuất nguyên văn mô tả tác vụ và toàn bộ gold patch
- Nó tái hiện cả nội dung regex kiểm tra username đổi từ
r'^[\\w.@+-]+$' thành r'^[\\w.@+-]+\\Z', cũng như diff theo từng dòng
Bài học cốt lõi
- Các benchmark được trích xuất từ tài liệu có thể truy cập công khai luôn mang theo rủi ro ô nhiễm, và việc mô hình đã tiếp xúc dữ liệu huấn luyện có thể âm thầm thổi phồng điểm số
- Nếu tạo benchmark từ dữ liệu crawl công khai, nhà phát triển mô hình cần thực hiện các bài kiểm tra bổ sung để xác minh có ô nhiễm hay không
- Vì benchmark công khai và cả lời giải cuối cùng rồi cũng có thể đi vào dữ liệu huấn luyện, cần đặc biệt cẩn trọng cả với cách phát hành bộ dữ liệu lẫn việc lọc dữ liệu huấn luyện
- Bài viết có nhắc đến các cơ chế kiểm soát phát hành như bảo vệ bằng mật khẩu
- Đồng thời cũng nhắc đến các phương pháp lọc như tuân thủ nghiêm ngặt chuỗi canary
- Chấm điểm tự động cần đủ vững để không bị dao động bởi những khác biệt triển khai không quan trọng, nhưng cũng phải đủ chặt để ngăn các cách lách luật; rất khó đạt được đồng thời cả hai mục tiêu này
- Để phát hiện các loại khuyết tật như vậy, đã cần nhiều vòng gán nhãn thủ công quy mô lớn
Hướng đánh giá trong tương lai
- Trong vài tháng gần đây, OpenAI đã quyết định báo cáo kết quả trên dữ liệu đánh giá công khai của SWE-bench Pro, và khuyến nghị các nhà phát triển mô hình khác cũng làm như vậy
- SWE-bench Pro cũng không hoàn hảo, nhưng theo quan sát thực nghiệm thì ít bị ảnh hưởng bởi ô nhiễm hơn so với SWE-bench Verified
- Quy trình kiểm tra ô nhiễm nội bộ vẫn phát hiện một số trường hợp ô nhiễm
- Tuy vậy, chúng hiếm hơn nhiều và mức độ cũng nhẹ hơn so với SWE-bench Verified
- Không có mô hình nào tạo ra gold patch khớp hoàn toàn từng ký tự
- Trong thời gian tới, OpenAI cho biết sẽ tiếp tục đầu tư vào các benchmark độc đáo, được biên soạn không công khai
- Với GDPVal, các chuyên gia theo lĩnh vực sẽ viết tác vụ theo cách không công khai, còn những người chấm điểm được huấn luyện sẽ đánh giá lời giải một cách tổng hợp
- Cách làm này tốn nhiều nguồn lực, nhưng ngày càng trở thành yếu tố thiết yếu nếu muốn đo được những cải thiện năng lực thực chất
1 bình luận
Ý kiến trên Hacker News
Với tư cách là đồng tác giả của SWE-bench, để tôi tóm tắt lại: SWE-bench Verified giờ gần như đã bão hòa ở mức 93.9%, và Anthropic xứng đáng được chúc mừng
Dù vậy, các đội vẫn chưa đạt tới mức đó vẫn còn dư địa để kéo cao hơn
SWE-bench Multilingual và SWE-bench Multimodal vẫn chưa bão hòa, và Multimodal dự kiến sẽ được open-source trong vòng tháng tới
Cuối cùng thì benchmark nào rồi cũng sẽ bão hòa, nên chúng tôi vẫn tiếp tục làm các benchmark thế hệ tiếp theo, và giờ đã có những thứ như https://codeclash.ai/ hay https://algotune.io/
Điểm mấu chốt là khá nhiều bài test không chính xác, nên ngay cả lời giải đúng trên thực tế cũng bị chấm là sai
Ngoài ra, các mô hình frontier rất có thể đã đọc và ghi nhớ các PR làm nền cho những bài toán này
Thậm chí có những bài gần như không thể giải đúng nếu không học thuộc lời giải, ví dụ có trường hợp phải để lộ chính xác tên của một helper function cụ thể vốn không xuất hiện trong đề thì mới qua được test
Việc các mô hình frontier vượt qua được những bài như vậy có vẻ là vì chúng nhớ rằng cần đúng cái tên đó
Nếu benchmark thế hệ sau không xử lý được chuyện này thì dù có bão hòa hay không, vấn đề cũ vẫn sẽ còn nguyên
Tính ra thì 0.191 * 0.594 > 1 - 0.936, nên tôi bắt đầu tự hỏi không biết tập con được audit có thiếu tính đại diện không, hay là Anthropic đã đạt điểm cao bằng cách nào đó hơi đáng ngờ
Tạo benchmark, bão hòa, loại bỏ, thay thế, rồi lặp lại
Cuối cùng cả cái treadmill này nhìn như một kiểu sản phẩm vận hành theo vòng lặp, và tôi không biết lời giải là gì, nhưng cảm giác như lịch sử đang lặp lại
Theo cách tôi hiểu thì nó trông như một biến thể thú vị dựa trên SWE-bench
Việc nó đang bị soi rất gắt như hiện tại có vẻ là phản ứng ngược của việc nó đã được chấp nhận rộng rãi và thành công đến thế nào
Có vẻ quá rõ ràng là bất kỳ benchmark mới nào xuất hiện cũng sẽ nhanh chóng chui vào dữ liệu huấn luyện và lập tức trở nên lỗi thời
Luôn có động cơ để tối ưu theo một benchmark cụ thể, dù chỉ là để marketing, và ngay cả khi có training cutoff thì thường cũng chỉ cách thời điểm công bố chừng 3 đến 6 tháng
Vì thế, khó khăn thực sự của benchmark cho coding là tạo ra những bài toán hoàn toàn mới mà có thể đảm bảo chắc chắn là chưa từng có trong dữ liệu huấn luyện, đồng thời không vay mượn từ các benchmark cũ
Nhìn từ góc này, các benchmark được tạo trước khi model phát hành khó có thể xem là đại diện cho hiệu năng của model đó, và động cơ tài chính để nhét dữ liệu vào chỉ nhằm quảng bá những cải thiện nhỏ là quá lớn
Thành thật mà nói, tốt hơn là bỏ benchmark khỏi tài liệu marketing, để model tự lên tiếng và để cộng đồng tự đánh giá, nhưng các công ty có tiền dính vào thì chắc sẽ chẳng bao giờ làm vậy
Game phiêu lưu văn bản Zork có trong dữ liệu huấn luyện của LLM và lại có tính quyết định, nên lẽ ra model phải chơi và phá đảo được một cách dễ dàng
Nhưng thực tế không phải vậy, và đó chính là mục tiêu của Zork bench
https://github.com/mnky9800n/zork-bench
Từ những người đã dùng LLM hơn 10 năm đến các vibe coder chưa từng viết code đều lẫn vào nhau, và trên mạng thì có người xem GPT 5.5 như vị cứu tinh, có người lại thấy nó còn ngớ ngẩn hơn 5.4
Tôi cũng không có thời gian tự làm benchmark kín cho từng model mới, nên cuối cùng vẫn phải dựa vào các benchmark private hoặc semi-private để ước lượng mức cải thiện rồi đăng ký dùng và tự thử
Ít nhất nó còn đáng tin hơn chút so với bầu không khí do user ngẫu nhiên hay bot trên Reddit tạo ra
Hoặc cũng có thể tiếp tục chạy test tuần tự trong cùng một context để xem model trụ được bao lâu trước khi làm rơi mất ngữ cảnh
Benchmark hiện nay lúc nào cũng là các bài toán greenfield, nhưng thứ ta thực sự muốn là model xử lý được một context đã mục nát
Nút thắt hiện tại không phải là năng lực tự thân, mà là model trong production có thể nhìn thấy những gì
Cấu trúc context, chất lượng retrieval, tool use, và khả năng kết hợp trạng thái qua nhiều lượt hội thoại mới là quan trọng, còn SWE-bench gần như không có những thứ đó
SWE-bench trông như một bộ bài tập one-shot, nhưng công việc coding frontier giờ không còn mang hình dạng đó nữa
Ngay cả nếu làm ra được một benchmark hoàn hảo hoàn toàn không bị nhiễm dữ liệu, phần lớn khả năng là nó vẫn đo sai trục
Ở các bài toán cô lập, model đã đạt đến mức nghiên cứu sinh con người, và đòn bẩy giờ nằm ở cách chúng hoạt động bên trong một hệ thống lớn hơn
Nhưng điều đó gần như thuộc về gu hoặc sở thích, nên cực kỳ khó đo một cách khách quan
Anthropic trả tiền cho influencer để đẩy Claude Code, và có vẻ cũng chạy bot rất mạnh, nên khó mà tin vào đồng thuận trên mạng
Kể cả khi mọi người đều hành động thiện chí thì khác biệt về domain vẫn có thể khiến cảm nhận chênh lệch lớn
Ví dụ AI có thể làm tốt hơn nhiều ở frontend hoặc với các thư viện phổ biến
Cuối cùng thì vẫn chỉ còn cách tự dùng để đánh giá model, nhưng lặp lại việc đó với mỗi model mới thì quá mệt, mà bản thân nó cũng không đủ toàn diện
Benchmark/eval vốn dĩ đã khó, và khi động cơ để game nó ở quy mô cả ngành quá lớn thì lại càng khó hơn
ELT-Bench cũng là một ví dụ gần đây, là benchmark nghiêm túc đầu tiên cho workload data engineering xuất hiện khoảng một năm trước
Nhưng vài ngày trước, trong một bài báo tiếp theo có một trong các tác giả gốc tham gia, họ đã audit chính benchmark đó và kết luận rằng kết quả bị lệch vì các vấn đề mang tính cấu trúc
Bài báo ở đây: https://arxiv.org/abs/2603.29399
Thực ra chuyện này cũng chẳng mới, ngành công nghiệp trước đây ở quy mô nhỏ hơn đã từng trải qua hết rồi
Cũng có một bài viết về việc tình hình hiện tại giống chiến tranh benchmarketing trong cơ sở dữ liệu đến mức nào
https://www.typedef.ai/blog/from-benchmarketing-to-benchmaxx...
Ở BrowseComp plus hay các dataset deep research khác cũng thấy vấn đề tương tự, và không hẳn vì các frontier lab cố tình gian dối, mà là hệ quả tự nhiên của việc huấn luyện trên toàn bộ web
Dataset mới sẽ phải được tạo ra liên tục mãi mãi
Khi tự xây classifier tôi đã gặp cảnh trong một số tác vụ, model liên tục làm tốt hơn con người đến mức không còn đo được precision nữa
Khi đó classifier ấy tự nó trở thành state-of-the-art benchmark, và ngoài chính nó ra thì không còn thứ gì để so sánh
Chuyện này xảy ra cả ở những tác vụ phức tạp ít logic hơn coding và ít đòi hỏi suy luận kéo dài hơn, nên đến một lúc nào đó benchmark đã hiệu chỉnh và độc lập với đối tượng đo có thể biến mất hoàn toàn
Rốt cuộc tôi nghĩ phần lớn chúng ta đang nhận lấy đúng kiểu benchmark do chính mình tạo nghiệp
Trong số các PR vượt qua SWE-bench, có lẽ nhiều cái trên thực tế vẫn sẽ không được merge: https://news.ycombinator.com/item?id=47341645
Và điểm SWE-bench của các model top đầu cũng có thể đã bị bóp méo vì rò rỉ git history: https://news.ycombinator.com/item?id=45214670
Có lúc tôi nghĩ hay là cứ để các model hàng đầu tự tạo benchmark luôn đi
Nói đùa vậy thôi, thứ tôi đang kỳ vọng là ARC-AGI-3, và khi thử mô phỏng như con người thì tôi thấy nó thực sự có tỷ trọng suy luận rất cao
Leaderboard ở đây: https://arcprize.org/leaderboard
Hiện giờ đa số model hàng đầu còn chưa vượt nổi 5%
Ngay cả Claude Opus 4.6, model tốt nhất đã được xác minh hiện tại, cũng chỉ ở mức khoảng 0.45%
Tuy nhiên nó vẫn còn quá mới, nên tôi kỳ vọng ở thế hệ model tiếp theo sẽ cải thiện khá nhiều
Có thể để model đời trước phỏng vấn model đời mới, rồi để cả hai hoặc một model giám khảo thứ ba phán xem ai thông minh hơn, sau đó đổi seed và lặp lại 100 lần
Lấy tỷ lệ mà cả hai bên cùng công nhận model mới thắng làm điểm số là được
Loại đó là thứ khó bị game nhất
Nghĩ tới thì cũng hơi buồn cười
Benchmark tốt hơn nên có chấm điểm khách quan, độ rộng liên ngành, và khả năng mở rộng, đồng thời tránh dạng chỉ có một đáp án duy nhất
Những gì chúng tôi thiết kế ở https://gertlabs.com cũng theo hướng đó, và phần lớn vẫn liên quan tới việc giải quyết vấn đề thông qua coding
Theo trải nghiệm của tôi thì gpt 5.4/5.5 về mặt kỹ thuật gần như không có tì vết, và nếu có vấn đề thì phần lớn là do đầu vào không rõ ràng
Nó cũng thường tự xử lý được các vấn đề phát sinh trong lúc sửa bug hay triển khai, và có xu hướng hoàn thành công việc rất kín kẽ
Trong khi đó, tôi nghĩ Opus có phần được đánh giá hơi quá ở khía cạnh năng lực kỹ thuật
Nó có cảm quan designer/developer tốt hơn khi tạo ra UX đẹp, nhưng việc kiểm chứng công việc thì tôi vẫn luôn giao cho gpt 5.5
Điều gây ngạc nhiên nhất là kết quả của Xiao-Mi, tôi vẫn chưa dùng nhưng thấy vậy nên định sẽ thử
Xin chúc mừng đội ngũ vì đã tạo ra một thước đo có ý nghĩa trong cuộc chạy đua AI hỗn loạn này
Có vẻ như điều đó phản ánh thiên lệch của dataset huấn luyện hoặc khác biệt trong trọng tâm go-to-market, và tôi cũng nghĩ có thể là vì Anthropic tập trung vào khách hàng enterprise hơn OpenAI
Nó cũng khớp với trải nghiệm thực tế của tôi khi dùng Opus cho C++
Tuy nhiên phần kết quả C# đang để trống, @gertlabs có ETA gì không?
Tôi muốn nghe bình luận về lý do tại sao lại ra như vậy
Chuyện này sớm muộn gì cũng phải xảy ra, dù theo cách hữu cơ hay không hữu cơ
Rất dễ trượt sang kiểu chỉ cần làm sao cho điểm benchmark thật đẹp, còn có tổng quát hóa ra bên ngoài hay không thì cũng chẳng quá quan trọng
Một ví dụ tương tự khiến tôi nhớ đến là Graduate student descent
https://sciencedryad.wordpress.com/2014/01/25/grad-student-d...
Nghĩ lại thì có lẽ SWE-bench vốn cũng không hẳn thần thánh đến thế
Suốt năm 2025, tỷ lệ model tạo ra mã nguồn tốt thực ra gần như không cải thiện bao nhiêu, và có lẽ cách diễn giải đúng hơn là chỉ có khả năng vượt qua test tự động được cải thiện
https://entropicthoughts.com/no-swe-bench-improvement
Hồi tháng 1/2025, các model chủ lực là Claude 3.5 Sonnet, Gemini 1.5 Pro, còn phía OpenAI là GPT-4o, và với tư cách người đã dùng cả chúng lẫn các model frontier hiện tại, tôi thấy rõ là các model bây giờ đã nhảy vọt lên hẳn một bậc
Chất lượng model có vẻ đang chững lại, và việc tìm ra vector cải thiện mới rõ ràng không hề dễ
Ngay cả mở rộng bề rộng mô hình, thứ đã thúc đẩy tốc độ cải thiện từ trước đến nay, cũng có vẻ đang chạm giới hạn, nên tôi tò mò điều đó sẽ kéo theo hệ quả gì
Về dài hạn, chỉ dựa vào tooling cũng có giới hạn của nó
Đó cũng là một trong các lý do khiến Anthropic được định giá hàng chục tỷ đô
Lý do SWE-bench hữu ích ở mảng coding là vì software engineering vốn đã có truyền thống và hạ tầng rất mạnh để tạo và tận dụng test tự động
Điều bài viết nói có vẻ là họ đã audit tập con 27.6% gồm các bài mà model thường xuyên không giải được, và phát hiện trong đó ít nhất 59.4% có test lỗi khiến cả bài nộp đúng về mặt chức năng cũng bị từ chối
Nếu điều đó là thật thì chẳng phải có nghĩa là một mảng rất lớn của toàn bộ bài toán và đáp án từ trước đến nay đã sai sao, và nếu vậy thì khó hiểu thật sự là nó đã từng là một phép đo hợp lệ bằng cách nào
Nhìn vào mô tả quy trình tạo benchmark thì tiêu chuẩn có vẻ khá cao, nên tôi cũng không hiểu những bước đó đã cùng tồn tại với chất lượng dữ liệu tệ đến vậy bằng cách nào
Việc họ tự phơi bày vấn đề là đáng khen, nhưng vẫn còn lại rất nhiều câu hỏi
Và vì những lý do thực tế, benchmark về bản chất vốn dĩ không đại diện cho use case của bạn, cũng không đại diện cho mọi use case
Nó chỉ có giá trị trong việc đo những mục nằm bên trong nó, không hơn không kém
Đó cũng là lý do tôi không hiểu vì sao hệ sinh thái lại ám ảnh với benchmark công khai đến vậy
Ví dụ, chuyện Qwen 3.5 tốt hơn Qwen 2.5 tới 50% trên Benchmark X gần như không đảm bảo rằng nó cũng tốt hơn 50% trong những việc tôi dùng
Tôi đã liên tục xây dựng benchmark riêng tư bằng cách tinh chỉnh prompt dựa trên các trường hợp model thất bại trong sử dụng thực tế
Ngay cả khi có bản cập nhật model mới, trên benchmark của tôi thường cũng chỉ nhúc nhích khoảng 2 đến 3%, trong khi benchmark công khai lại quảng bá mức tăng 30 đến 40%, nên thật khó tin rằng không có chuyện nhiễm dữ liệu huấn luyện
Ở mức cực đoan, thậm chí còn có những đoạn mà để đạt điểm cao hơn thì bạn phải khớp theo đáp án sai
Rốt cuộc lời giải thích là ML là lĩnh vực rất hay “cứ thế mà chạy được”, nên dù có lỗi nó vẫn đi xa một cách đáng kinh ngạc
Đồng thời đó cũng là lý do vì sao chỉ cần chỉ ra được những lỗi mà người khác chưa thấy là bạn có thể tạo ra một đột phá lớn
Chỉ cần phần lớn tác vụ được chấm đúng thì xu hướng chung vẫn có thể giữ nguyên
Ví dụ, ngay cả một benchmark tệ tới mức 49% nhãn bị sai, nếu model luôn trả lời đúng được 51% còn model luôn trả lời sai nhận 49% thì thứ hạng vẫn đúng
Nhiều benchmark machine learning có không ít nhãn sai, nhưng nếu mục tiêu là phân biệt giữa các model thì thường sẽ tốt hơn khi thu thập dataset lớn hơn thay vì tốn thời gian bảo đảm việc chấm điểm hoàn hảo