Nhà phát minh của SWE-Bench vừa tung ra một bài kiểm tra hiệu năng mới, cực kỳ khó nhằn.
Kết quả khá sốc:
Claude Opus 4.7, GPT-5.4, GPT-5 mini, Gemini 3.1 Pro, Gemini 3 Flash—hầu hết các mẫu máy quét mạnh nhất thuộc thế hệ này đều có tỷ lệ hoàn thành 0%.
Không có mô hình đơn lẻ nào có thể thực sự và hoàn toàn tái tạo lại một dự án phần mềm.
Điều đó có nghĩa là gì?
Những người mẫu hàng đầu hiện nay rất giỏi viết mã, nhưng vẫn chưa thể làm được công việc kỹ thuật phần mềm.
Gần đây, MetaFAIR, hợp tác với các tổ chức như Stanford và Harvard, đã công bố một tiêu chuẩn đánh giá mới rất thú vị, về cơ bản định nghĩa lại cách đánh giá khả năng lập trình của trí tuệ nhân tạo:
ProgramBench: Liệu các mô hình ngôn ngữ có thể xây dựng lại chương trình từ đầu?
Các bài kiểm tra hiệu năng lập trình quy mô lớn trước đây chủ yếu kiểm tra các khả năng cục bộ: hoàn thiện hàm, sửa lỗi, triển khai tính năng, v.v. Về bản chất, chúng vẫn chỉ là những sửa đổi cục bộ đối với cấu trúc mã hiện có.
Lần, ProgramBench đã đưa câu hỏi lên tầm kỹ thuật phần mềm thực thụ: nếu AI chỉ được cung cấp mô tả chức năng và tài liệu hướng dẫn sử dụng cho một chương trình, liệu nó có thể xây dựng lại một hệ thống phần mềm thực sự, có thể chạy được từ đầu, giống như một kỹ sư thực thụ? Ví dụ: ffmpeg, SQLite hoặc ripgrep.
Hơn nữa, nó không thể kết nối với internet.
Nói cách khác: Liệu mô hình đó thực sự sở hữu trí thông minh kỹ thuật?
Để kiểm tra điều này, đội ngũ nghiên cứu đã xóa mã nguồn và các bài kiểm tra gốc, chỉ giữ lại Executable và tài liệu hướng dẫn sử dụng. Mô hình phải tự quyết định ngôn ngữ, kiến trúc, phân chia mô-đun, cấu trúc dữ liệu và thậm chí cả cách tổ chức toàn bộ kho lưu trữ.
Quan trọng hơn, ProgramBench không còn chấm điểm dựa trên sự tương đồng về mã nguồn nữa. Nó sử dụng sự tương đương về hành vi. Điều này có nghĩa là bạn có thể triển khai nó bằng các ngôn ngữ, thuật toán, kiến trúc hoàn toàn khác nhau, và thậm chí cả các phương pháp kỹ thuật hoàn toàn khác nhau. Miễn là hành vi đầu vào và đầu ra cuối cùng nhất quán với chương trình gốc, nó sẽ vượt qua bài kiểm tra.
Đội ngũ nghiên cứu thậm chí còn sử dụng phương pháp làm mờ dựa trên tác nhân để tự động tạo ra lượng lớn các bài kiểm tra hành vi từ đầu đến cuối.
Lần, một bài kiểm tra hiệu năng thực sự bắt đầu giống với kỹ thuật phần mềm thực tế, chứ không chỉ đơn thuần là giải quyết các bài toán lập trình. Sau khi kết quả được công bố, toàn bộ cộng đồng AI đều im lặng.
Tất cả các mô hình: Tỷ lệ hoàn thành 0%.
Bảng 2 tạo ra ấn tượng ban đầu, trong khi Hình 4 giải thích chi tiết hơn. Nó cho chúng ta biết rằng các mô hình không hoàn toàn không có khả năng thực hiện các nhiệm vụ; ngược lại, chúng thường có thể hoàn thành một phần nhiệm vụ, thậm chí gần như hoàn hảo ở một vài nhiệm vụ. Tuy nhiên, tất cả các mô hình sụp đổ khi yêu cầu sự tương đương về hành vi 100%. Chặng cuối cùng này chính xác là sự khác biệt lớn nhất giữa kỹ thuật phần mềm và việc tạo mã thông thường. Hơn nữa, nếu chúng ta chọn ra cái tốt nhất trong số những cái tệ nhất, thì sê-ri Claude (đặc biệt là Opus 4.7 và 4.6) hoạt động tương đối tốt nhất.
Mặc dù bài báo đã bổ sung thêm chỉ số "Gần như "—chỉ số này đếm nhiệm vụ có tỷ lệ hoàn thành trên 95%—nhưng Claude Opus 4.7, phiên bản hiện đang hoạt động tốt nhất, chỉ có 3% nhiệm vụ gần hoàn thành.
Có một câu đặc biệt quan trọng trong bài báo:
Các mô hình này ưu tiên các triển khai nguyên khối, một tệp duy nhất, khác biệt rõ rệt so với mã do con người viết.
Nói cách khác, mô hình này cực kỳ dễ tạo ra mã nguồn nguyên khối. Lượng lớn logic được nhồi nhét vào một tệp duy nhất; cấu trúc mục lục rất nông; việc chia tách mô-đun rất hạn chế; các hàm quá dài; toàn bộ kho lưu trữ trông giống như một kịch bản khổng lồ.
Điều này gần như hoàn toàn trái ngược với thói quen của những kỹ sư giỏi.
Phương pháp thứ hai thường nhấn mạnh sự tách biệt mô-đun và các mối quan tâm, và phân chia mã một cách thanh lịch — cấu hình được đặt trong config.json, các hàm tiện ích trong utils.py, các thao tác cơ sở dữ liệu trong db.py, và sau đó chúng được gọi lẫn nhau thông qua import.
Điều này thực sự phơi bày một vấn đề cốt lõi: AI giỏi trong việc tạo mã cục bộ, nhưng không giỏi trong việc lập kế hoạch hệ thống toàn cục. Về bản chất, kỹ thuật phần mềm thực sự chính là cái sau.
Đây là lý do tại sao mô hình này rất mạnh trong các bài kiểm tra LeetCode, SWE-Bench và Copilot, nhưng nó nhanh chóng gặp khó khăn khi được áp dụng vào các hệ thống kỹ thuật quy mô lớn trong thực tế.
Điểm nghẽn thực sự trong lập trình AI hiện nay không còn là khả năng tạo ra mã nguồn, mà là khả năng xây dựng hệ thống phần mềm dài hạn.
Một phát hiện thú vị khác là sự khác biệt về hiệu suất giữa các ngôn ngữ khác nhau.
Đội ngũ nghiên cứu đã phân tích thống kê hiệu suất của mô hình trên các dự án bằng nhiều ngôn ngữ khác nhau, bao gồm C/C++, Go và Rust. Rõ ràng là các dự án C/C++ truyền thống đạt tỷ lệ hoàn thành cao nhất, trong khi Rust có hiệu suất thấp nhất.
Các mô hình khác nhau cho thấy sắp xếp khá nhất quán về độ khó nhiệm vụ : nhìn chung, các mô hình đạt tỷ lệ thành công cao hơn với các công cụ CLI tương đối đơn giản như nnn, fzf và gron; tuy nhiên, hầu hết các mô hình đều gặp khó khăn khi xử lý các hệ thống phức tạp như FFmpeg, php-src, typst và ast-grep. Điều này cho thấy hiệu suất của ProgramBench không phải do sự thất bại ngẫu nhiên của mô hình, mà là do sự kìm hãm ổn định của mô hình hiện tại bởi chính hệ thống phần mềm phức tạp.
Điều này không có gì đáng ngạc nhiên.
Trên internet có rất nhiều mã lịch sử, các quy trình kỹ thuật và nội dung trên Stack Overflow về C/C++ đến nỗi mô hình này đã được tiếp thu những khuôn mẫu đó trong nhiều năm.
Triết lý kỹ thuật của Rust nhấn mạnh mô-đun, quyền sở hữu, hệ thống đặc tính và khả năng bảo trì lâu dài, chính xác là những điều mà các mô hình hiện tại còn yếu nhất.
Nói một cách nào đó, điều mà Rust đo lường không phải là khả năng lập trình, mà là khả năng kỹ thuật.
Khi ProgramBench gây ra những cuộc tranh luận sôi nổi, cuộc tranh luận xung quanh bài kiểm tra hiệu năng này cũng lan rộng nhanh chóng. Một trong đó những lời chỉ trích chính là: liệu đây chỉ là việc kiểm tra xem mô hình đã ghi nhớ FFmpeg hay chưa? Xét cho cùng, nhiều dự án trong ProgramBench là phần mềm mã nguồn mở mở.
Đáp lại, nhà đầu tư có tiếng ở Thung lũng Silicon, Deedy Das, đã viết một bài báo khẳng định rằng bất kỳ tiêu chuẩn nào cũng có thể bị quá khớp (overfitting).
SWE-Bench có thể ghi nhớ lỗi, các bài toán trên LeetCode có thể được ghi nhớ, và thậm chí ARC-AGI có thể ngăn chặn rò rỉ bộ nhớ trong tương lai bằng cách ẩn đi tập hợp bài toán của nó. Việc chỉ thảo luận về sự tồn tại của bộ nhớ không làm giảm giá trị của các bài kiểm tra hiệu năng.
Ông cho rằng rằng nếu một mô hình thực sự cố gắng ghi nhớ các chương trình này bằng phương pháp vét cạn, nó thường sẽ suy giảm đáng kể ở các lĩnh vực khác.
Bởi vì việc huấn luyện một mô hình quy mô lớn không chỉ đơn giản là nhồi nhét toàn bộ thư viện FFmpeg vào các tham số. Hơn nữa, các nhà nghiên cứu có thể phát hiện sự hiện diện của việc ghi nhớ trực tiếp bằng cách so sánh độ tương đồng giữa mã được tạo ra và mã nguồn gốc.
Điều ông ấy thực sự muốn nhấn mạnh là việc xây dựng lại một hệ thống phần mềm thực tế từ đầu là một nhiệm vụ phức tạp, có tính ứng dụng cao và tốn nhiều thời gian. Nếu mô hình có thể thực sự suy luận và hoàn thành loại nhiệm vụ này, thì khả năng đó có thể được khái quát hóa cho lượng lớn tình huống kỹ thuật khác .
Một loại tranh cãi khác thậm chí còn thú vị hơn. Một số người phàn nàn rằng ngay cả con người cũng không thể viết lại FFmpeg từ đầu, vì vậy tiêu chuẩn này hoàn toàn không hợp lý.
Deedy Das đáp lại, "Vậy thì sao? Ngày nay, các chuyên gia luật có thể làm được nhiều việc mà người bình thường không thể làm được."
Mục tiêu của các bài kiểm tra chuẩn mực không bao giờ là mô phỏng khả năng trung bình của người bình thường, mà là thúc đẩy các mô hình tiến gần hơn đến mức độ thông minh cao hơn. Chỉ vì con người không thể làm được điều đó không có nghĩa là các bài kiểm tra chuẩn mực là vô giá trị.
Ví dụ, kỹ năng chơi cờ vượt trội của AlphaGo so với đại đa số mọi người không làm giảm đi đóng góp của nó vào sự phát triển của trí tuệ nhân tạo; tương tự, một tiêu chuẩn vượt xa khả năng của các kỹ sư thông thường có thể là một vấn đề mà các hệ thống tác nhân trong tương lai phải vượt qua.
Tất nhiên, ông cũng thừa nhận rằng ProgramBench vẫn còn nhiều thiếu sót. Ví dụ, hiện tại nó không kiểm tra các bộ khung tác nhân hoàn chỉnh như Claude Code và Codex; nó chỉ theo dõi trạng thái hoàn thành và không cung cấp các phép đo tiến độ chi tiết hơn.
Nó cũng hạn chế kết nối internet để ngăn chặn hành vi gian lận rõ ràng.
Deedy Das đồng ý, điều này có thể dẫn đến việc mô hình "leo dốc" vào những yếu tố sai lầm khi cố gắng đạt điểm cao trên một chỉ báo cụ thể. Tuy nhiên, người ta luôn có thể thêm một bài kiểm tra hiệu năng với quyền truy cập mạng để so sánh.
Một số người đề xuất: Tại sao không sử dụng một bài toán hoàn toàn mới mà chưa ai từng giải quyết trước đây? Deedy Das trả lời rằng điều đó sẽ khiến việc xây dựng bộ dữ liệu chuẩn gần như bất khả thi.
Thật khó để thiết kế một bài kiểm tra toàn diện cho một câu hỏi không có đáp án chuẩn; cũng khó để xác định liệu nhiệm vụ thực sự thuộc về một nhiệm vụ kỹ thuật thực tế hay là một thử thách do các nhà nghiên cứu tạo ra từ hư không.
Tuy nhiên, những vấn đề này thực tế có thể được khắc phục khi tiêu chuẩn đánh giá được cải tiến.
Điều thực sự quan trọng là ProgramBench, lần, đã nâng đánh giá lập trình AI từ cấp độ chức năng lên cấp độ hệ thống. Nó phơi bày khoảng trống lớn nhất hiện đang tồn tại trong ngành: phát triển phần mềm thực sự không bao giờ chỉ là viết một hàm, mà là tạo ra một hệ thống kỹ thuật có thể được bảo trì, mở rộng và triển khai hợp tác bởi đội ngũ.
Các mô hình quy mô lớn hiện nay rất giỏi trong việc tạo ra mã cục bộ. Tuy nhiên, chúng vẫn thiếu khả năng duy trì các hệ thống phức tạp một cách nhất quán và ổn định trong thời gian dài.
Vì vậy, bạn sẽ thấy rằng gần đây toàn bộ ngành công nghiệp đã bắt đầu nghiên cứu một loạt từ khóa mới một cách điên cuồng: bộ nhớ, tác nhân, suy luận cấp kho lưu trữ, lập kế hoạch dài hạn và kỹ thuật phần mềm tự động.
Cuộc cạnh tranh ở giai đoạn tiếp theo có thể không còn xoay quanh việc ai có thể tạo ra đoạn mã dài hơn cùng một lúc, mà là về việc ai có thể duy trì một hệ thống phần mềm hoạt động ổn định và liên tục trong thời gian dài, thông qua nhiều vòng tương tác và trong các bối cảnh phức tạp.
Liên kết bài báo:
https://programbench.com/static/paper.pdf
Bài viết này được đăng tải từ tài khoản WeChat công cộng "Machine Heart" (ID: almosthuman2014) , tác giả: Sia, với sự cho phép của 36Kr.
