Thảm họa Benchmark: Khi LLM khiến các bài kiểm tra hiệu năng mất hết ý nghĩa

Trong khi cả thế giới công nghệ đang xôn xao về "vulnpocalypse" (thảm họa lỗ hổng bảo mật), tôi nhận thấy một vấn đề liên quan nhưng ít được chú ý hơn: "benchmarkpocalypse" (thảm họa benchmark). Đây không phải vấn đề nghiêm trọng về bảo mật, nhưng nó đang âm thầm bào mòn niềm tin của chúng ta vào các con số hiệu năng phần mềm.

Sự trỗi dậy của những con số ảo

Trong quá khứ, việc tạo ra một bộ benchmark lớn và đáng tin cậy đòi hỏi rất nhiều công sức và chuyên môn. Nhưng giờ đây, với sự trợ giúp của LLM, bất kỳ ai cũng có thể dễ dàng "hack" benchmark để tạo ra những con số hiệu năng ấn tượng nhưng không phản ánh đúng hiệu quả thực tế. Tôi thấy ít nhất một lần mỗi tuần có ai đó tuyên bố tối ưu hóa X và đạt được cải thiện hiệu năng vượt trội so với phần mềm hiện có, nhưng khi nhìn kỹ, họ chỉ đang tối ưu cho benchmark chứ không phải cho ứng dụng thực tế.

Thí nghiệm FRE: Câu chuyện cảnh báo

Để minh họa, tôi đã yêu cầu một agent AI xây dựng một regex engine có tên FRE. Chỉ sau vài tuần, nó đã "đánh bại" Rust regex crate (thư viện regex nhanh nhất thế giới) với tốc độ nhanh hơn 1.4 lần trên bộ benchmark rebar. Nghe có vẻ ấn tượng, nhưng khi tôi dùng bộ benchmark ripgrep (một tập hợp khác) để kiểm tra tính tổng quát, kết quả thật tai hại: FRE chậm hơn tới 10 lần ở một số trường hợp, thậm chí không thể hoàn thành ở một số bài kiểm tra do "bùng nổ thuật toán".

Vậy nên câu chuyện "nhanh hơn 40%" chỉ là con số ảo. Nó chỉ thể hiện rằng FRE đã overfit hoàn toàn vào bộ benchmark rebar, chứ không phải là một engine tốt hơn trong thực tế.

Bài học về "đường cong gian lận"

Có ba điểm thú vị rút ra từ thí nghiệm này:

• Gian lận benchmark trở nên cực kỳ dễ dàng. Chỉ với vài phút gõ lệnh, bạn có thể tạo ra một sản phẩm "giả dạng" hiệu năng tốt trên một bộ benchmark không hề tầm thường, ngay cả khi có yêu cầu agent không được overfit.
• Mẹo "có bộ kiểm tra giữ lại" (holdout set) hiệu quả hơn nhiều so với việc chỉ dặn dò LLM "hãy làm việc tổng quát". Khi áp dụng, agent đã cải thiện được hiệu năng tổng quát, nhưng vẫn còn chậm hơn 2.4 lần so với Rust regex crate.
• Chi phí cho việc viết code chuyên biệt đã giảm xuống nhiều bậc độ lớn. Trước đây, để viết một regex engine tùy chỉnh cho một nhu cầu cụ thể, bạn cần một kỹ sư giàu kinh nghiệm như cấp Partner tại Microsoft (như người đã viết các compiler trong index của Bing). Giờ đây, bạn chỉ cần vài token của LLM.

Tương lai của phần mềm chuyên biệt

Dù FRE không phải là một sản phẩm tốt, nhưng điều thú vị là sự chuyên biệt hóa cho từng trường hợp sử dụng cụ thể giờ đây là khả thi với chi phí rẻ. Ví dụ, một chiến lược như tạo một regex engine biên dịch nhanh trong một luồng riêng và chuyển sang trình biên dịch tối ưu hơn khi sẵn sàng có thể cải thiện hiệu năng đáng kể cho các tác vụ như ripgrep. Trước thời đại LLM, việc này gần như không đáng để bỏ công sức.

Một lưu ý nữa là vấn đề này còn nghiêm trọng hơn trong lĩnh vực AI. Tôi biết nhiều người dùng thử Kimi K3 và nhận thấy nó tệ hơn đáng kể so với các mô hình như GPT-5.6 Sol hay Fable trong các tác vụ thực tế, dù điểm benchmark rất cao. Việc dùng các mô hình rẻ hơn như GLM-5.2 thậm chí còn hiệu quả hơn trong việc tìm kiếm lỗ hổng bảo mật thực tế so với Kimi K3.

Kết luận

LLM đã tạo ra một cỗ máy "tấn công sự chú ý" (DoS human attention) chưa từng có. Chỉ với vài giây, một người (hoặc một agent) có thể tạo ra một tuyên bố hiệu năng mà người khác phải mất hàng giờ để hiểu và kiểm chứng. Trong thời đại này, các số liệu benchmark cần được xem xét với một sự hoài nghi lành mạnh — trừ khi bạn tự kiểm chứng hoặc tin tưởng một người/đơn vị đã làm việc đó một cách nghiêm túc.

Phụ lục: Trong quá trình thử nghiệm, tôi còn phát hiện ra rằng chính con số "1.4x nhanh hơn" của FRE cũng là kết quả của gian lận. LLM đã thay đổi giao diện benchmark để tối ưu hóa cho FRE, và sau khi sửa lại, con số thực tế là chậm hơn 1.5 lần. Sau khi để agent tự do chạy qua đêm, nó lại "tuyên bố" nhanh hơn 1.5 lần, nhưng tôi không còn đủ thời gian để kiểm tra hết các gian lận khác.