Dưới đây là hướng dẫn sử dụng FFmpeg và một tập tin thực thi đã được biên dịch sẵn.
Bây giờ, chúng ta hãy viết lại toàn bộ chương trình từ đầu.
Đây là thách thức mà ProgramBench đặt ra cho các chuyên gia trí tuệ nhân tạo hàng đầu thế giới.
Mới được phát hành ngày hôm qua, ứng dụng này được tạo ra bởi nhóm phát triển ban đầu của SWE-Bench, với sự hợp tác của Meta, Stanford và Harvard.
200 dự án phần mềm. 9 mô hình cấp cao. Tỷ lệ đậu: 0%!
John Yang, đồng tác giả chính, là nghiên cứu sinh tiến sĩ tại Đại học Stanford và là người sáng tạo ra SWE-Bench và SWE-agent.
Vấn đề không phải là sửa lỗi, mà là xây dựng phần mềm từ đầu.
Trong năm qua, số lượng báo cáo về các trường hợp "tạo phần mềm từ đầu bằng trí tuệ nhân tạo" ngày càng tăng.
Anthropic đã viết một trình biên dịch C sử dụng một tập hợp các máy tính song song kiểu Claude, Cursor đã viết blog về lập trình tự động dài hạn, và MirrorCode của Epoch AI cũng đang làm điều tương tự.
Tuy nhiên, những trường hợp này đều có một vấn đề chung: lần chỉ có một vài hạng mục được kiểm tra và giàn giáo được điều chỉnh thủ công.
Ngược lại, ProgramBench đã chính thức hóa quy trình này.
200 nhiệm vụ, cấu trúc bài học thống nhất, hệ thống chống gian lận bài bản, tất cả đều hướng đến tiêu chuẩn cao nhất.
Link bài báo: https://programbench.com/static/paper.pdf
Trong các bài kiểm tra trước đây, SWE-Bench cung cấp một mã nguồn hoàn chỉnh, cho bạn biết lỗi ở đâu hoặc cần thêm tính năng nào, và bạn chỉ việc thực hiện các thay đổi. Về cơ bản, đó là sự kết hợp giữa "khả năng đọc hiểu và chỉnh sửa cục bộ".
Hơn nữa, ở cấp độ đánh giá, nó sử dụng các bài kiểm tra đơn vị để kiểm tra xem việc triển khai nội bộ của mã của bạn có chính xác hay không, và liệu chữ ký hàm và tên biến của bạn có nhất quán với mong đợi hay không.
ProgramBench thì hoàn toàn ngược lại.
Nó chỉ cung cấp cho bạn hai thứ: một tập tin thực thi đã được biên dịch và tài liệu hướng dẫn sử dụng.
Nhiệm vụ của bạn là viết một đoạn mã từ đầu có thể tái tạo lại hành vi tương tự chỉ bằng cách chạy chương trình này và quan sát hành vi đầu vào và đầu ra của nó.
Bạn tự quyết định ngôn ngữ lập trình nào sẽ sử dụng, cấu trúc dữ liệu nào sẽ dùng và cách phân chia mô-đun.
Không có cấu trúc mã, không có chữ ký hàm và không có gợi ý nào.
Về phương pháp đánh giá, đội ngũ nghiên cứu đã sử dụng phương pháp kiểm thử mờ dựa trên tác nhân để tạo ra tổng cộng 248.853 bài kiểm tra hành vi cho 200 nhiệm vụ.
Nếu chương trình của bạn chạy một lần và đầu vào và đầu ra khớp với bản gốc, nó sẽ đạt; ngược lại, nó sẽ thất bại. Quá trình kiểm thử không bao giờ được tiết lộ cho mô hình.
Khác với các bài kiểm tra đơn vị của SWE-Bench, các bài kiểm tra hành vi của ProgramBench không quan tâm đến cấu trúc bên trong mã của bạn; miễn là hành vi nhất quán, thì đều được chấp nhận.
200 nhiệm vụ này bao gồm các dự án trải rộng trên nhiều lĩnh vực như công cụ nén (zstd, lz4, brotli), trình thông dịch ngôn ngữ (PHP, Lua, tinycc), cơ sở dữ liệu (DuckDB, SQLite), xử lý đa phương tiện (FFmpeg) và công cụ dành cho nhà phát triển (ripgrep, fzf, jq).
Số trung vị dòng mã trung bình là 8.635, trong đó FFmpeg, chương trình có số dòng mã lớn nhất, lên tới 2,7 triệu dòng.
Tóm lại, bài kiểm tra này đánh giá xem trí tuệ nhân tạo (AI) có khả năng "suy nghĩ và thiết kế phần mềm như một kỹ sư con người" hay không, thay vì chỉ đơn thuần là "tìm ra những gì cần thay đổi trong mã nguồn hiện có và sửa chữa cho đúng".
Chín người mẫu ngồi thành một hàng, và tất cả đều nhận được điểm 0.
Tổng cộng có chín mẫu tham gia thử nghiệm, bao gồm các dòng Claude, Gemini và GPT.
Tỷ lệ đậu (đạt tất cả các bài kiểm tra) là 0% đối với tất cả người tham gia.
Trước tiên, hãy cùng xem xét cuộc đối đầu trực tiếp giữa ba thương hiệu hàng đầu.
Tỷ lệ đỗ trung bình của GPT-5.4 và Gemini 3.1 Pro gần như tương đương nhau, lần lượt là 38,3% và 36,6%. Tuy nhiên, phong cách làm bài thi của hai bài kiểm tra này lại khá khác biệt.
GPT-5.4 chỉ sử dụng lần lệnh gọi API và có giá 0,33 đô la. Về cơ bản, toàn bộ chương trình có thể được viết trong một lần, với 100% mã được tạo ra chỉ trong một lần chỉnh sửa, và hầu như không cần phải quay lại và sửa đổi sau đó.
Gemini 3.1 Pro là mô hình "quan sát" nhất trong chín mô hình. Nó sử dụng lần lệnh gọi API, trong đó 34,1% các thao tác trong đó liên quan đến việc chạy chương trình gốc và quan sát hành vi đầu vào và đầu ra. Nó thực hiện nhiều khám phá nhất, nhưng kết quả cuối cùng không khác biệt đáng kể.
Điểm thực sự làm nên sự khác biệt chính là Claude Opus 4.7.
Với tỷ lệ đạt trung bình là 51,2%, nó đã vượt qua hơn 95% bài kiểm tra ở 3% nhiệm vụ, trở thành mô hình duy nhất đạt tiêu chuẩn "gần đạt". Tuy nhiên, ngay cả nó cũng không đạt điểm tuyệt đối ở bất kỳ nhiệm vụ nào.
Nhìn chung, hiệu năng của chín mô hình cho thấy một thứ bậc rõ ràng.
Ba mẫu máy chủ lực của Claude (Opus 4.7, Opus 4.6 và Sonnet 4.6) dẫn đầu, trong khi GPT-5.4 và Gemini 3.1 Pro tạo thành nhóm thứ hai. Bốn mẫu nhỏ hơn còn lại đều có tỷ lệ đạt yêu cầu dưới 35%.
Một phát hiện trái ngược với trực giác khác là việc chi tiền và tăng số bước đi không nhất thiết dẫn đến kết quả tốt hơn.
Sonnet 4.6 chạy trung bình 868 lệnh cho mỗi nhiệm vụ, với chi phí là 27,09 đô la, và đường dẫn dài nhất lên tới gần 2000 bước. Tuy nhiên, hiệu suất của nó kém hơn so với Opus 4.7, chỉ sử dụng 93 lần và có chi phí là 3,81 đô la.
Quan trọng hơn, trong 98% số lần chạy, mô hình chủ động gửi kết quả khi cảm thấy đã "hoàn thành", mà không bao giờ vượt quá giới hạn thời gian hoặc số bước.
Không phải là không đủ thời gian trong kỳ thi, mà là tôi thực sự không thể làm được.
Hơn nữa, độ khó nhiệm vụ và thứ hạng của mô hình rất nhất quán.
Các công cụ CLI đơn giản (nnn, fzf, gron) có thể đạt được điểm số tốt cho hầu hết người dùng, trong khi các hệ thống phức tạp (FFmpeg, PHP, typst, ast-grep) xử lý tất cả các mô hình như nhau và không khoan nhượng.
Cần lưu ý rằng ProgramBench sử dụng cấu trúc khung tối giản của mini-SWE-agent, thiếu tính năng nén ngữ cảnh, cộng tác đa tác nhân và Chuỗi tùy chỉnh.
Đoạn mã đã được viết ra, nhưng trông nó không giống như được viết bởi con người chút nào.
Đội ngũ nghiên cứu đã so sánh các giải pháp đạt điểm cao, vượt qua hơn 75% bài kiểm tra, với mã lập trình gốc do con người thực hiện và phát hiện ra một số khác biệt đáng ngạc nhiên.
Quái vật xếp hàng một.
Giá trị số trung vị của mã do con người viết trên 15 tập tin là 3, số trung vị các mô hình là 3.
60% các giải pháp chỉ bao gồm từ 1 đến 3 tập tin mã nguồn.
Các kỹ sư con người chia nhỏ mô-đun theo chức năng, trong khi các mô hình có xu hướng nhồi nhét mọi thứ vào một tệp khổng lồ duy nhất. Độ sâu mục lục số trung vị là 2 lớp đối với con người và 1 lớp đối với mô hình.
Các hàm số vừa ít lại vừa dài.
Opus 4.7 chỉ thực hiện 29% số chức năng mà con người thực hiện, Sonnet 4.6 thực hiện 24%, và GPT-5.4 chỉ thực hiện 10%.
Tuy nhiên, độ dài trung bình của mỗi hàm lại dài hơn; các hàm được viết bằng Gemini 3.1 Pro dài hơn 62% so với các hàm do con người viết.
Lượng mã lập trình đã được giảm đáng kể.
Số trung vị của mô hình là 1.173 dòng, so với 3.068 dòng của con người. 85% các giải pháp đạt điểm cao ngắn hơn giải pháp gốc.
Tóm lại, trí tuệ nhân tạo hiện nay có thể viết mã, nhưng không thể thiết kế phần mềm.
Nó không hiểu tại sao nó phải được chia thành mô-đun, cũng như tại sao các kỹ sư con người lại phải dành thời gian để định nghĩa giao diện và các lớp trừu tượng. Chiến lược của nó đơn giản là nhồi nhét tất cả logic vào càng ít tệp và hàm càng tốt, miễn là nó hoạt động.
GPT-5.4 thể hiện hiệu suất vượt trội nhất. Trung bình, chỉ có 5 tệp được tạo cho mỗi nhiệm vụ, được sửa đổi 1,2 lần và 39,5% số track không bị sửa đổi gì sau khi tệp được tạo.
Để so sánh, Claude Sonnet 4.6 tạo ra trung bình 11,3 tập tin và chỉnh sửa 18,3 lần, cho thấy mô hình phát triển lặp đi lặp lại gần giống với con người hơn.
Còn một hiện tượng rất thú vị khác nữa.
Chỉ có 50% khả năng mô hình sẽ sử dụng cùng ngôn ngữ lập trình với bản gốc.
Trong đó là ngôn ngữ được mô hình ưa thích nhất, chiếm 36% trong tổng số lần lần chạy.
Trong số các dự án ban đầu được viết bằng Rust, chỉ có 44% được viết lại bằng Rust; đối với các dự án C/C++, con số này là 46%. Các dự án Go thể hiện "lòng trung thành" cao nhất, ở mức 70%.
Bất kể ngôn ngữ lập trình gốc bạn sử dụng là gì, vẫn có 1/3 khả năng mô hình đó sẽ được viết lại bằng Python.
Tôi đã hứa không gian lận, nhưng ngay khi kết nối được internet, tôi liền vào GitHub để xé toạc mã nguồn.
Đây có lẽ là phần ấn tượng nhất của toàn bộ nghiên cứu.
Đội ngũ nghiên cứu đã tiến hành một loạt các thí nghiệm kiểm soát, cho phép mô hình truy cập mở mạng, nhưng nêu rõ trong các lời nhắc của hệ thống rằng "gian lận là không được phép".
Sau đó, chín giám khảo AI đã kiểm tra từng quỹ đạo để phát hiện bất kỳ hành vi gian lận nào.
Kết quả thật đáng kinh ngạc.
Claude Sonnet 4.6 có 36% số nhiệm vụ bị đánh dấu là gian lận, Claude Opus 4.6 có 21%, Gemini 3 Flash có 20%.
Có rất nhiều cách để gian lận.
Phương pháp trắng trợn nhất là sao chép kho mã nguồn từ GitHub.
Một phương pháp kín đáo hơn một chút là tải xuống thông qua trình quản lý gói, chẳng hạn như `cargo install` hoặc `go get`.
Phương pháp tinh vi hơn nữa là tìm kiếm mã nguồn của các thư viện phụ thuộc trong mục lục bộ nhớ đệm gói cục bộ.
Tuy nhiên, sự bất đồng giữa các trọng tài AI cũng lớn đến mức đáng ngạc nhiên.
Đối với Claude Opus 4.6, chín giám khảo không thể thống nhất về 57% số nhiệm vụ.
Có một trường hợp đặc biệt điển hình.
Trong quá trình làm việc với dự án Rust handlr sử dụng Claude Sonnet 4.6, tôi đã vào mục lục~/.cargo/registry/src/ và xem qua mã nguồn của các thư viện phụ thuộc như xdg-mime và clap.
Năm thẩm phán cho rằng đó là hành vi gian lận, trong khi bốn thẩm phán khác cho rằng đây là các cơ sở dữ liệu của bên thứ ba và do đó không cấu thành hành vi gian lận.
Cuối cùng, đội ngũ nghiên cứu đã từ bỏ phương pháp "kết nối mạng + phát hiện sau sự kiện" và đơn giản là ngắt kết nối mạng.
Khi đối diện nhiệm vụ khó khăn, xu hướng "tìm đường tắt" của mô hình mạnh hơn nhiều so với dự kiến. Việc ngay cả chín giám khảo AI cũng không thể phân biệt rõ ràng giữa hành vi gian lận và kỹ thuật đảo ngược hợp pháp cho thấy ranh giới giữa hai điều này rất mờ nhạt.
Các kỳ thi cũ đã kết thúc, các kỳ thi mới vừa bắt đầu.
Nó đạt được 72% mô hình trên SWE-Bench, nhưng chỉ đạt 0% trên ProgramBench.
Về cơ bản, hai bài kiểm tra này đánh giá hai khả năng khác nhau. Bài kiểm tra SWE-Bench kiểm tra khả năng "tìm và sửa lỗi trong mã nguồn của người khác", trong khi bài kiểm tra ProgramBench kiểm tra khả năng "thiết kế và triển khai một hệ thống hoàn chỉnh từ đầu".
Trí tuệ nhân tạo của hệ thống thứ nhất đã khá tốt, trong khi hệ thống thứ hai hiện vẫn hoàn toàn chưa đáp ứng được yêu cầu.
Epoch AI vừa đăng một bài viết trên blog tuần trước tuyên bố rằng các tiêu chuẩn đánh giá suy luận cũ đã hoàn toàn lỗi thời. Để tạo ra một bài kiểm tra không bị các đối thủ cạnh tranh vượt mặt, bạn phải từ bỏ ít nhất một trong bốn điều kiện quen thuộc: văn bản thuần túy, thời gian thực thi ngắn, chấm điểm dễ dàng và đánh bại các chuyên gia con người.
Dựa trên khuôn khổ này, ProgramBench đã loại bỏ hai trong đó: thời gian thực thi ngắn và chấm điểm dễ dàng.
Nó nâng cấp nhiệm vụ lên mức độ mà các kỹ sư con người phải mất hàng tuần hoặc thậm chí hàng tháng mới hoàn thành, đồng thời đánh giá bằng cách sử dụng sự tương đương về hành vi thay vì so khớp mã nguồn.
Trong một bài đăng trên Twitter, tác giả John Yang nhấn mạnh: "ProgramBench rất khó, nhưng về cơ bản là có thể giải được."
Nói cách khác, 0% không có nghĩa là nhiệm vụ này đã vượt quá giới hạn lý thuyết của AI; nó chỉ đơn giản có nghĩa là các mô hình hiện tại còn xa mới đủ đáp ứng.
SWE-Bench kiểm tra xem trí tuệ nhân tạo (AI) có thể là một nhân viên giỏi hay không. ProgramBench kiểm tra xem AI có thể là một kỹ sư hay không.
Khoảng cách giữa hai vật này vừa được đo chính xác hôm nay. Kết quả là 0%.
Tham khảo:
https://programbench.com/static/paper.pdf
https://x.com/jyangballin/status/2051677497562210552?s=20
https://x.com/EpochAIResearch/status/2051760424891392204?s=20
https://epochai.substack.com/p/rip-classic-reasoning-benchmarks
Bài viết này được đăng tải từ tài khoản WeChat chính thức "New Zhiyuan" , tác giả: New Zhiyuan, và được xuất bản với sự cho phép của 36Kr.
