Tách tín hiệu khỏi nhiễu trong đánh giá lập trình
(openai.com)- Việc đánh giá năng lực lập trình của mô hình AI liên quan trực tiếp đến quyết định triển khai và an toàn, nhưng trong cuộc kiểm tra của OpenAI, ước tính khoảng 30% tác vụ trong SWE-Bench Pro đang bị lỗi
- SWE-Bench Pro nhắm đến phạm vi tác vụ dài hơn và các bài toán thực tế hơn, nhưng với 731 tác vụ công khai, tỷ lệ vượt qua tăng từ 23,3% lên 80,3% chỉ trong 8 tháng khiến kết quả này khó có thể được tin nguyên trạng
- Các khiếm khuyết được chia thành kiểm thử quá nghiêm ngặt, prompt thiếu đặc tả, kiểm thử có độ bao phủ thấp và prompt gây hiểu lầm; các bài nộp đúng có thể bị đánh trượt hoặc bản sửa chưa hoàn chỉnh có thể được chấm đạt
- Cuộc kiểm tra đã đánh dấu 286 tác vụ có vấn đề tiềm ẩn dựa trên các lần thử của mô hình, siêu dữ liệu tác vụ và truy vết lỗi, sau đó trải qua quá trình rà soát độc lập bởi agent điều tra và 5 kỹ sư có kinh nghiệm
- OpenAI đã rút lại khuyến nghị áp dụng SWE-Bench Pro; các benchmark đánh giá cần cung cấp tín hiệu có ý nghĩa để không bóp méo phán đoán về năng lực và độ an toàn của mô hình
Các vấn đề được phát hiện trong cuộc kiểm tra SWE-Bench Pro
- Sau khi kiểm tra SWE-Bench Pro, OpenAI ước tính khoảng 30% tổng số tác vụ đang bị lỗi
- Việc đo lường chính xác năng lực của mô hình cũng ảnh hưởng đến quyết định triển khai và an toàn theo Preparedness Framework
- Một phép đánh giá có khiếm khuyết có thể khiến năng lực của mô hình bị hiểu sai so với thực tế, đồng thời làm lung lay phán đoán về an toàn và thứ tự ưu tiên nghiên cứu
Mục tiêu của SWE-Bench Pro và thay đổi về tỷ lệ vượt qua
- Trước đó, OpenAI đã phát hiện các vấn đề về thiết kế và nhiễm bẩn dữ liệu trong SWE-bench Verified, vốn được sử dụng rộng rãi, và kết luận rằng phép đánh giá này không còn cung cấp tín hiệu có ý nghĩa về năng lực phát triển phần mềm nữa
- Khi đó, OpenAI đã khuyến nghị cộng đồng chuyển sang SWE-Bench Pro
- SWE-Bench Pro được thiết kế để cải tiến SWE-bench Verified, theo dõi năng lực lập trình dạng agent thông qua phạm vi tác vụ dài hơn và các bài toán lập trình thực tế hơn
- Các tác vụ được trích xuất bằng lập trình từ lịch sử thay đổi tính năng của các kho lưu trữ công khai và riêng tư
- Mô hình phải triển khai một giải pháp vượt qua các bài kiểm thử cho tính năng mới mà không làm hỏng chức năng hiện có
- Trên phần chia công khai gồm 731 tác vụ, tỷ lệ vượt qua của các mô hình frontier đã tăng từ 23,3% lên 80,3% trong 8 tháng
Pipeline đảm bảo chất lượng
- OpenAI đã xây dựng một pipeline đảm bảo chất lượng để xác nhận rằng từng điểm dữ liệu thực sự phản ánh năng lực của mô hình
- Bộ lọc tự động ban đầu xem xét chỉ dẫn đưa cho mô hình, các nỗ lực giải của mô hình và các bài kiểm thử chấm điểm để đánh dấu những ví dụ bị lỗi hoặc đáng nghi
- Trong quá trình này, 286 tác vụ có vấn đề tiềm ẩn đã được đánh dấu
- Tập con đã đánh dấu được rà soát sâu hơn qua hai hướng
- Rà soát bằng agent có con người giám sát: agent điều tra thực hiện kiểm tra chi tiết, sau đó có phán quyết cuối cùng của con người
- Chiến dịch gán nhãn bởi con người: các nhà phát triển phần mềm có kinh nghiệm trực tiếp rà soát tác vụ
Cách rà soát bằng agent và con người
- Các vấn đề đã đánh dấu được kiểm tra bởi agent điều tra dựa trên Codex
- Agent có quyền truy cập vào kho lưu trữ của tác vụ và môi trường thực thi
- Có thể chạy kiểm thử, kiểm tra tệp trong kho, điều tra các lần thử của mô hình và các kiểu lỗi phổ biến
- Được dùng để phân biệt giữa sự mơ hồ hợp lý có thể giải quyết bằng mã xung quanh và quy ước của kho lưu trữ với tình trạng thực sự thiếu đặc tả
- Sau nhiều vòng kiểm tra chuyên sâu độc lập, nhà nghiên cứu rà soát bản tóm tắt rồi đưa ra phán quyết cuối cùng và gán nhãn vấn đề
- Trong chiến dịch gán nhãn bởi con người diễn ra song song, các kỹ sư phần mềm có kinh nghiệm được đào tạo về mục tiêu benchmark, phân loại vấn đề và các trường hợp ranh giới trước khi rà soát tác vụ
- Mỗi tác vụ được 5 kỹ sư rà soát
- Người rà soát trước tiên đưa ra phán đoán độc lập dựa trên mô tả vấn đề nhìn thấy được, các test case và gold patch là giải pháp tham chiếu đúng
- Sau đó sử dụng phân tích hoặc bản ghi từ pipeline làm ngữ cảnh hỗ trợ
- Gán nhãn và mức độ nghiêm trọng dựa trên bằng chứng cụ thể; các trường hợp bất đồng ý kiến hoặc độ chắc chắn thấp được chuyển lên để rà soát thêm
Bốn loại lỗi
- Các vấn đề được xác nhận trong cuộc kiểm tra chủ yếu thuộc bốn nhóm
- Kiểm thử quá nghiêm ngặt: ép buộc các chi tiết triển khai cụ thể không có trong prompt, khiến bài nộp đúng về mặt chức năng bị vô hiệu hóa
- Prompt thiếu đặc tả: bỏ sót các yêu cầu mà kiểm thử ẩn đòi hỏi nhưng khó có thể suy luận một cách hợp lý
- Kiểm thử có độ bao phủ thấp: không kiểm tra đầy đủ chức năng được yêu cầu, nên cả bản sửa chưa hoàn chỉnh cũng có thể vượt qua
- Prompt gây hiểu lầm: dẫn mô hình đến hành vi sai hoặc mâu thuẫn với yêu cầu của kiểm thử
- Trong một số tác vụ, prompt yêu cầu một cách triển khai cụ thể, nhưng các test case ẩn lại kỳ vọng hành vi khác
Khác biệt giữa rà soát của con người và rà soát bằng agent
- Người rà soát là con người có xu hướng đánh dấu tác vụ là bị lỗi cao hơn so với agent điều tra
- Dù có khác biệt về phán đoán danh mục giữa hai hướng rà soát, trong số các tác vụ được đánh dấu, không có trường hợp nào nhãn “không bị lỗi” là nhãn xuất hiện nhiều nhất trong các nhãn của con người
- Danh mục do pipeline agent đánh dấu và phán đoán của người rà soát trùng nhau trong 74% trường hợp
- Người rà soát là con người cũng thường chọn nhiều nhãn cho một tác vụ hơn
- Đây là tín hiệu cho thấy tác vụ bị lỗi theo nhiều cách hoặc không khớp gọn vào một danh mục duy nhất
- Pipeline kết hợp agent và người rà soát đã nắm bắt được các kiểu lỗi rộng mà con người tìm thấy, nhưng đếm một cách thận trọng hơn đối với các vấn đề bổ sung hoặc trùng lặp
- Khác biệt lớn nhất xuất hiện ở kiểm thử có độ bao phủ thấp
- Con người chọn đây là vấn đề phổ biến nhất, chiếm 9,4% benchmark
- Pipeline agent đánh dấu ở mức 4,1%
Vì sao xây dựng benchmark là việc khó
- Các trường hợp SWE-Bench Pro và SWE-bench Verified cho thấy benchmark cần được xác minh nghiêm ngặt
- Issue và pull request trong kho nguồn mở vốn được tạo ra cho hợp tác giữa con người, không phải để đánh giá mô hình
- Trong môi trường có nhiều trao đổi qua lại kéo dài giữa maintainer và contributor, mô tả vấn đề, mã đã được merge và unit test không phải lúc nào cũng tạo thành một tác vụ sạch và độc lập cho mục đích đánh giá mô hình
- Các bài kiểm thử có trong pull request đôi khi được viết để xác minh một thay đổi cụ thể, nên có thể ép buộc một cách triển khai cụ thể thay vì tiêu chí giải quyết độc lập với cách triển khai
Hướng đánh giá trong tương lai
- Khi năng lực mô hình cải thiện, các khiếm khuyết trong đánh giá cũng trở nên dễ tìm hơn trước
- Các mô hình đã cải thiện có thể kiểm tra sâu hơn và nhất quán hơn prompt, kiểm thử, patch, truy vết thực thi và trường hợp ranh giới, qua đó làm lộ các vấn đề benchmark từng khó hoặc tốn kém để phát hiện ở quy mô lớn
- OpenAI kỳ vọng cộng đồng đánh giá rộng hơn sẽ phát triển các benchmark mới do những nhà phát triển phần mềm có kinh nghiệm trực tiếp tạo ra nhằm kiểm thử năng lực mô hình
- Cách làm này cho phép giám sát của con người tốt hơn trong toàn bộ quá trình, đồng thời duy trì độ khó cao và tính thực tế mà phép đo muốn hướng đến
- OpenAI rút lại khuyến nghị trước đây về việc áp dụng SWE-Bench Pro do các vấn đề được phát hiện trong phân tích lần này
- Đánh giá cần khó bị thao túng, dễ tin cậy và cung cấp tín hiệu có ý nghĩa thực sự phản ánh năng lực hoặc trạng thái alignment của mô hình
1 bình luận
Các ý kiến trên Hacker News
Cần đo cả hiệu quả lẫn trí thông minh. Các mô hình nhỏ có thể dùng chiến lược như sử dụng máy tính để kiểm thử kết quả, hoặc bám vấn đề lâu hơn và xác minh đầu ra; còn các mô hình lớn có thể thiếu ngân sách tự kiểm thử, nên có lẽ sẽ xuất hiện khác biệt chiến thuật thú vị
https://artificialanalysis.ai/?cost=intelligence-vs-cost-per...
Toby Ord đã thử làm nhiều nhất có thể bằng dữ liệu công khai, nhưng kết quả trông không mấy tốt
https://www.tobyord.com/writing/hourly-costs-for-ai-agents
Ngoài ra còn có gian lận ở mức harness thực thi, reward hacking của mô hình, v.v. Điều vẫn khiến tôi bận tâm sau vài tháng là bài nộp chính thức gpt-5.5, đặc biệt là tác vụ này: https://www.tbench.ai/leaderboard/terminal-bench/2.0/codex/0...
Giới hạn thời gian của tác vụ, theo https://github.com/harbor-framework/terminal-bench-2/blob/ma..., là verifier 1200 giây, agent 1200 giây, environment build 600 giây, nên không agent nào được vượt quá 3000 giây. Thế nhưng trong 5 lần thử ở liên kết trên, 2 lần vượt xa 3000 giây, lần lượt mất 75 phút và 80 phút. Dù có thất bại đi nữa, việc chạy lâu như vậy cũng đáng ngờ. Đây là một ví dụ về định luật Goodhart đang phát huy tác dụng
Benchmark con người cũng không hiệu quả lắm. Năng lực lập trình chỉ có thể đo tương đối đúng khi tương tác trực tiếp. Nếu mô hình thực chất là trình mô phỏng con người, thì khi mô phỏng ngày càng chính xác hơn, kỳ vọng benchmark tiếp tục hữu ích mới là điều kỳ lạ. Rốt cuộc đây chỉ là cách diễn giải dài hơn của “định luật Goodhart” nói ở trên, và nó thực sự vận hành như một định luật
Vậy lập luận là mô hình tối tân không phải kỹ sư junior, mà là thực tập sinh tháng đầu tiên không có khả năng vượt qua mức đó sao?
Điều thú vị là làm sao LLM vượt quá 70% trong các benchmark kiểu này, hoặc trả lời đúng một phần các câu hỏi được cấu trúc tệ. Có phải chúng đã ngầm học phong cách của người viết test không? Hay lời giải đã rò rỉ vào dữ liệu huấn luyện?
Dù vậy, cũng đáng yên tâm là ngay cả Fable cũng dừng ở khoảng 72% trên tập ẩn mà OpenAI không chạy phân tích này. Có vẻ nó không trực tiếp học chính benchmark, trừ những cách rất gián tiếp
Các mô hình mở nhỏ chắc chắn không thể học được những thói quen kỳ quặc như vậy, nên một cách tốt để đánh giá mô hình một cách công bằng là thật sự quan trọng. Thêm nữa, OpenAI đang làm hơi nhiễu vấn đề: chỉ khoảng 20% câu hỏi bị hỏng theo cách bất công với agent, và 4–10% bị hỏng theo hướng có lợi, nên trần benchmark có lẽ gần 80–85%
Vì vậy prompt tác vụ rất hẹp thì dễ xác minh, nhưng có khả năng quá đơn giản để làm thử thách. Ngược lại, prompt tác vụ thực tế hơn thì khó xác minh hơn nhiều, và việc tạo verifier vững chắc rồi chạy với chi phí rẻ cũng trở nên khó khăn
Tất nhiên khi đó benchmark đang kiểm thử thứ khác với điều nó tuyên bố, nhưng đôi khi nó lại vô tình kiểm thử một thứ gần với thực tế hơn so với một benchmark gọn gàng, nên điều đó cũng có ý nghĩa riêng
Tuy nhiên, chuyện này chỉ đúng khi agent có thể xem các test thất bại và lặp lại. Nếu không thì chỉ là vấn đề. Và tệ hơn nữa là khi test đóng đinh các chi tiết triển khai của một lời giải cụ thể, đòi hỏi một cấu trúc nội bộ tùy ý nào đó. Ngoài đời bạn sẽ không gặp tình huống như vậy
Một mặt, việc họ thực sự làm chuyện đó là đáng khen. Mặt khác, đúng là “rác vào thì rác ra”. Việc các tác giả gốc không thật sự kiểm tra cũng hơi đáng xấu hổ, và việc tất cả những người ở downstream cũng không kiểm tra cũng đáng xấu hổ. Ngoài ra, nhìn vào bài viết thì LLM cũng tìm ra vấn đề, nhưng có xu hướng đánh giá thấp những vấn đề mà kỹ sư phần mềm chuyên nghiệp tìm được.
Các benchmark, nếu nhìn kỹ bên trong, nhìn chung khá tệ
Nói về bối cảnh, tôi đang lặp đi lặp lại cải tiến một agent giám sát để thay thế nhiều thủ tục phiền phức khi dùng Codex/Claude Code, và gần đây đã chạy agent này trên Terminal Bench 2.1
Ban đầu tôi thấy mừng. Vì bộ giám sát dựa trên đặc tả tốt hơn Codex mặc định ở nhiều tác vụ. Nhưng khi xem kỹ hơn, bản thân các tác vụ có rất nhiều vấn đề
Điểm cốt lõi là chỉ dẫn thường mơ hồ, còn test case lại quá cụ thể. Ví dụ
configure-git-webserver, do các cách diễn đạt như “so that I can run”, ranh giới giữa việc agent phải cung cấp gì và phải loại bỏ gì trở nên mập mờ. Một agent suy nghĩ quá mức sau khi cấu hình server đã cho rằng nếu người dùng chạy cùng lệnh thì sẽ xung đột, nên xóa đúng những file mà trình kiểm chứng kiểm traVới
make-mips-interpreter, do câu “I will check that you booted doom correctly”, bộ giám sát diễn giải rằng người dùng sẽ kiểm tra kết quả mà agent đã boot, chứ không phải kiểm tra Doom có boot độc lập hay không, nên đã để lại/tmp/frame.bmpđược tạo ra. Trình kiểm chứng thấy đã có/tmp/frame.bmpthì thoát, vì vậy không thể khởi động Doom, và cũng không kiểm tra xem file đó có được tạo mới trong quá trình boot hay không[0]Trong
mcmc-sampling-stan, agent giám sát nhiều lần đạt đến giá trị đúng, nhưng thay vì số thập phân đơn giản, nó xuất con số chuyên biệt theo miền ở dạng ký pháp khoa học. Trình kiểm chứng parse sai kết quả nên thất bại[1]Những bất nhất như vậy chỉ là một phần, nên tôi cho rằng Terminal Bench 2.1 đã bão hòa, và kết quả của GPT-5.6 cùng Mythos, lần lượt 88,8% và 88%, gần như đã chạm đến giới hạn trên có thể kỳ vọng. Vấn đề lớn nhất là đa số benchmark là chạy một lần, gần như không kiểm tra mô hình+harness trong các công việc lặp dài, vốn là cách chủ yếu người dùng thực sự dùng công cụ
[0] https://github.com/harbor-framework/terminal-bench-2-1/issue...
[1] https://github.com/harbor-framework/terminal-bench-2-1/issue...
Chẳng phải ngay từ đầu ai cũng biết toàn bộ SWE-Bench có lỗi sao? Ngay cả các tác giả cũng thừa nhận giới hạn và đã chuyển sang bước tiếp theo từ lâu rồi
Tôi hiểu vì sao nó có thể trở thành benchmark tệ, nhưng nếu vấn đề là các test quá nghiêm ngặt áp đặt một số chi tiết triển khai cụ thể không được nêu trong prompt, làm vô hiệu các bài nộp đúng về mặt chức năng; prompt thiếu sót bỏ qua các yêu cầu mà test ẩn áp đặt nhưng không thể suy luận hợp lý; test có độ phủ thấp kiểm tra chưa đủ chức năng được yêu cầu khiến bản sửa chưa hoàn chỉnh vẫn qua; prompt gây hiểu nhầm dẫn mô hình đến hành vi sai hoặc xung đột với yêu cầu của test, thì nếu mục tiêu là so sánh kỹ sư phần mềm thật với mô hình, đây lại là tình huống khá thực tế
Nó giống như sau khi tạo đề thi điều dưỡng, lại đánh dấu một số câu vì lẽ ra phải hỏi bác sĩ phụ trách về thông tin bổ sung không có trong hồ sơ, hoặc gia đình bệnh nhân không giải thích đầy đủ tiền sử bệnh của bà cụ cao tuổi. Có thể muốn một benchmark nghiêm ngặt hơn, nhưng nếu OpenAI đã hứa hẹn mô hình như thứ thay thế lao động thực tế, thì đây không phải bức tranh đẹp. Ngược lại, đáng ra nên muốn kiểm thử chính những điều này
Đọc giống như “đã làm hết các việc cần thiết để sửa benchmark, rồi cuối cùng quyết định bỏ benchmark”. Dữ liệu nền tảng có quý đến mức không thể vá lại sao? Đoạn cuối nói nên có cách tiếp cận chọn lọc hơn một chút khi tạo benchmark, nhưng tôi cảm thấy cách vá một cách công bằng những test bẩn và không hoàn chỉnh lấy từ dữ liệu thực tế cũng là một con đường khá vững chắc
Nếu họ nói thêm “danh sách instance bị hỏng ở đây” hoặc “đây là tập con của SWE Bench Pro sẽ dùng trong tương lai” thì tốt hơn. Họ đang để sự hoàn hảo cản trở cái tốt
Tuy nhiên, khi OpenAI phát hành SWE-Bench Verified thì họ đã làm đúng kiểu đó, nên có thể tôi đang nói nhảm
Hiện giờ nên xem state-of-the-art của benchmark SWE là gì?
Theo suy nghĩ và đánh giá cá nhân của tôi, từ khá lâu rồi, dù trần tiềm năng của một mô hình có cao hơn, nếu tôi không thật sự tự tin ký duyệt đoạn code đó thì giá trị của nó vẫn bị giới hạn
[0] https://deepswe.datacurve.ai/
[1] https://cognition.com/blog/frontier-code-1.1
[0]: https://deepswe.datacurve.ai/
Có https://cognition.ai/blog/frontier-code. Nói trước là tôi từng ở trong đội đó, nhưng ở đây cũng đã xử lý các bài toán swebench pro/deepswe
Việc đạt được AGI phải là điều gì đó vượt xa chuyện vượt qua mọi benchmark, và cũng phải tính đến cả những vấn đề chưa biết
Cách giải chỉ có thể là a) làm cho LLM nhỏ hơn với hiệu năng tương tự để chúng không thể ghi nhớ hoặc nhắm vào benchmark, hoặc b) tạo ra một benchmark bao trùm toàn bộ dữ liệu thế giới thực, nhưng phương án sau là bất khả thi