"Tách biệt tín hiệu khỏi nhiễu trong các bài đánh giá lập trình

Việc đo lường chính xác khả năng của các mô hình là rất quan trọng để đưa ra các quyết định triển khai và an toàn hợp lý, bao gồm cả các quyết định theo Khung Chuẩn bị⁠(mở trong cửa sổ mới) của OpenAI. Với mỗi lần phát hành mô hình, chúng tôi đều báo cáo kết quả cho nhiều tiêu chuẩn đánh giá nội bộ và bên ngoài khác nhau để theo dõi tiến độ của mô hình. Khi các đánh giá có sai sót ảnh hưởng đến kết quả, chúng có thể dẫn đến sự hiểu sai về năng lực, làm sai lệch các trường hợp an toàn và ảnh hưởng đến các ưu tiên nghiên cứu.

Chúng tôi gần đây đã điều tra cách một trong những chuẩn đánh giá (benchmark) lập trình được sử dụng rộng rãi nhất, SWE-bench Verified, có các vấn đề cơ bản về thiết kế và nhiễm dữ liệu, và nhận thấy rằng bài đá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. Vào thời điểm đó, chúng tôi đã khuyến khích cộng đồng rộng lớn hơn chuyển sang SWE-Bench Pro.

SWE-Bench Pro⁠(mở trong cửa sổ mới) được thiết kế để cải tiến SWE-bench Verified bằng cách thử nghiệm các mô hình trong thời gian dài hơn và với các nhiệm vụ lập trình thực tế hơn nhằm theo dõi tốt hơn khả năng lập trình tác nhân. Tương tự như trong SWE-bench Verified, các tác vụ được lấy một cách lập trình từ lịch sử thay đổi tính năng trong một tập hợp các kho lưu trữ công khai và riêng tư. Cần có các mô hình để triển khai một giải pháp đáp ứng các bài kiểm tra mới cho một tính năng, mà không làm hỏng chức năng hiện có. Trong phân chia công khai 731 nhiệm vụ, các mô hình tiên phong đã cải thiện từ tỷ lệ vượt qua 23,3% lên 80,3% trong tám tháng.

Kể từ đó, chúng tôi đã thực hiện một cuộc kiểm toán tương tự trên SWE-Bench Pro, xem xét tập dữ liệu bằng cách sử dụng quy trình phân tích điểm dữ liệu. Quy trình này đã xem xét các nỗ lực mô hình thực hiện nhiệm vụ, siêu dữ liệu nhiệm vụ và dấu vết lỗi để xác định các sai sót có thể xảy ra trong quá trình đánh giá. Mỗi nhiệm vụ được gắn cờ sau đó được đánh giá thông qua nhiều lần kiểm tra của điều tra viên-đại lý và được năm kỹ sư phần mềm giàu kinh nghiệm xem xét độc lập, các bất đồng sẽ được chuyển lên cấp cao hơn để điều tra thêm.

Các vấn đề chủ yếu được chia thành bốn nhóm:

• Các bài kiểm thử quá nghiêm ngặt¹ áp đặt các chi tiết triển khai cụ thể không được nêu trong câu lệnh, khiến nhiều bài nộp đúng về mặt chức năng bị coi là không hợp lệ.
• Các câu lệnh được đặc tả thiếu² bỏ sót những yêu cầu mà các kiểm thử ẩn bắt buộc tuân thủ và không thể suy luận một cách hợp lý.
• Các bài kiểm tra có độ phủ thấp không kiểm tra đầy đủ tính năng được yêu cầu, do đó các bản sửa lỗi chưa hoàn chỉnh vẫn có thể được chấp nhận.
• Một câu lệnh gây hiểu lầm hướng các mô hình đến hành vi sai hoặc mâu thuẫn với những gì các bài kiểm thử yêu cầu.

Kết quả nghiên cứu của chúng tôi chỉ ra khó khăn trong việc xây dựng các tiêu chuẩn đánh giá khắt khe nhưng công bằng, cũng như tầm quan trọng ngày càng tăng của các tác nhân trong việc kiểm tra chất lượng dữ liệu trên quy mô lớn. Dựa trên những kết quả này, chúng tôi ước tính rằng khoảng 30% số tác vụ SWE-bench Pro bị lỗi, và khuyến nghị các nhà phát triển mô hình xem xét kỹ lưỡng các kết quả.

Mục tiêu của chúng tôi là đảm bảo rằng các trường hợp tác vụ thất bại phản ánh những hạn chế thực sự của mô hình, và các trường hợp tác vụ thành công phản ánh các giải pháp đầy đủ và hợp lệ đối với các yêu cầu của câu lệnh. Để kiểm tra chất lượng của dữ liệu được sử dụng trong quá trình đánh giá, chúng tôi đã tạo một quy trình đảm bảo chất lượng nhằm đánh giá xem mỗi điểm dữ liệu có phản ánh chính xác năng lực của mô hình hay không.

Bộ lọc tự động ban đầu sẽ xem xét các hướng dẫn được đưa ra cho mô hình, các nỗ lực của mô hình để giải quyết nhiệm vụ và các bài kiểm tra được sử dụng để chấm điểm các nỗ lực này nhằm xác định các ví dụ có khả năng bị lỗi hoặc có vấn đề. Bộ lọc này đã đánh dấu 286 tác vụ có khả năng bị lỗi. Sau đó, chúng tôi tiến hành đánh giá chuyên sâu hơn tập con đó theo hai cách: đánh giá bằng tác nhân có con người giám sát trong đó thực hiện các kiểm tra toàn diện với các tác nhân điều tra và đưa ra phán đoán cuối cùng của con người; và một chiến dịch chú thích do con người thực hiện với sự tham gia của các nhà phát triển phần mềm giàu kinh nghiệm.

Mỗi vấn đề được gắn cờ đều được kiểm tra bởi các tác nhân điều tra dựa trên Codex, những người được cấp quyền truy cập vào kho lưu trữ tác vụ và môi trường. Điều này giúp họ phân biệt sự mơ hồ hợp lý về nhiệm vụ, thường có thể được giải quyết bằng cách nghiên cứu mã nguồn xung quanh và các quy ước trong kho lưu trữ, với tình trạng thiếu đặc tả thực sự. Tác nhân có thể chạy kiểm thử, kiểm tra các tệp trong kho mã nguồn, đồng thời điều tra các lần thử của mô hình và những kiểu lỗi thường gặp của chúng trong nhiệm vụ này. Sau nhiều lần lặp độc lập của các cuộc kiểm tra chuyên sâu hơn này, một nhà nghiên cứu đã xem xét các bản tóm tắt, đưa ra phán đoán cuối cùng và gắn nhãn các vấn đề có khả năng xảy ra.

Song song đó, chúng tôi đã tiến hành một chiến dịch chú thích thủ công trên tập con được đánh dấu. Chúng tôi đã làm việc với các kỹ sư phần mềm giàu kinh nghiệm, những người đã được đào tạo về các mục tiêu chuẩn mực, phân loại vấn đề và các trường hợp ngoại lệ trước khi xem xét các nhiệm vụ. Mỗi nhiệm vụ đều được năm kỹ sư xem xét.

Người đánh giá đã hình thành nhận định độc lập từ phần mô tả vấn đề hiển thị, các trường hợp kiểm thử và lời giải tham chiếu chuẩn xác (được gọi là gold-patch) trước khi sử dụng phân tích pipeline hoặc bản ghi làm ngữ cảnh hỗ trợ. Sau đó, người đánh giá đã gán nhãn và mức độ nghiêm trọng dựa trên bằng chứng cụ thể, đồng thời chuyển các trường hợp có bất đồng hoặc độ tin cậy thấp lên cấp cao hơn để xem xét thêm.

Người đánh giá là con người có nhiều khả năng đánh dấu các nhiệm vụ là bị lỗi hơn so với các nhân viên điều tra. Cũng có một số bất đồng về các danh mục giữa hai quy trình rà soát, nhưng không có tác vụ bị gắn cờ nào mà “không bị lỗi” là nhãn được con người chọn nhiều nhất. Trong số các hạng mục mà hệ thống tự động đánh dấu, nhận định của người đánh giá trùng khớp trong 74% trường hợp.

So với quy trình tự động của hệ thống, người đánh giá cũng có xu hướng chọn nhiều nhãn cho một nhiệm vụ hơn, cho thấy họ nhận thấy nhiệm vụ đó bị lỗi theo nhiều cách hoặc không hoàn toàn phù hợp với một danh mục duy nhất. Điều này cho thấy quy trình tác nhân kết hợp người đánh giá đã dẫn đến việc gán nhãn thận trọng: quy trình này ghi nhận được các dạng lỗi tổng quát mà con người đã xác định, nhưng lại bỏ sót những trường hợp mà người đánh giá nhận thấy có thêm các vấn đề khác hoặc các vấn đề chồng lấn. Sự khác biệt lớn nhất nằm ở các bài kiểm tra có độ phủ thấp, trong đó con người chọn đây là vấn đề phổ biến nhất đối với 9,4% số bài kiểm tra chuẩn so với 4,1% từ quy trình tự động của hệ thống.

Các vấn đề mà chúng tôi đã xác định, cùng với các trường hợp tương tự trong SWE-bench Verified, nhấn mạnh tầm quan trọng của việc kiểm tra kỹ lưỡng các bộ đánh giá chuẩn. Các vấn đề và pull request trong các kho lưu trữ nguồn mở ban đầu được tạo ra để con người cộng tác, thường thông qua những cuộc trao đổi qua lại kéo dài giữa người bảo trì và người đóng góp. Do đó, mô tả vấn đề, mã được hợp nhất và các bài kiểm tra đơn vị không phải lúc nào cũng khớp với nhau để tạo thành các tác vụ riêng biệt, rõ ràng nhằm đánh giá mô hình một cách đáng tin cậy. Cụ thể, các bài kiểm thử được đưa vào pull request có thể quá nghiêm ngặt vì chúng được viết để xác thực một thay đổi cụ thể, thay vì để xác định một tiêu chuẩn không phụ thuộc vào cách triển khai cho việc giải quyết tác vụ.

Đồng thời, những sai sót trong quá trình đánh giá hiện nay dễ phát hiện hơn nhiều so với trước đây, thậm chí chỉ một thời gian ngắn trước đây. Khi năng lực của mô hình được cải thiện, chúng ta có thể sử dụng các mô hình đó để kiểm tra câu lệnh, bài kiểm thử, bản vá, dấu vết và các trường hợp biên với độ sâu và tính nhất quán cao hơn nhiều, giúp phát hiện các vấn đề trong chuẩn đánh giá mà trước đây rất tốn kém hoặc không thực tế để tìm ra trên quy mô lớn.

Chúng tôi hy vọng cộng đồng đánh giá rộng lớn hơn sẽ phát triển các tiêu chuẩn mới được xây dựng bởi các nhà phát triển phần mềm giàu kinh nghiệm, nhằm mục đích kiểm tra khả năng của mô hình. Cách tiếp cận đó có thể duy trì tiêu chuẩn cao và tính thực tế mà chúng ta mong muốn khi đánh giá khả năng của mô hình, đồng thời cho phép giám sát tốt hơn của con người trong suốt quá trình. Dựa trên những vấn đề được phát hiện trong phân tích này, chúng tôi rút lại khuyến nghị trước đó về việc áp dụng SWE-Bench Pro.

Tóm lại, một đánh giá cần cung cấp tín hiệu có ý nghĩa thông qua các tiêu chuẩn khó bị thao túng, dễ tin cậy và phản ánh chân thực khả năng hoặc sự phù hợp của mô hình. Vì những kết quả này cung cấp thông tin cho các quyết định triển khai và an toàn của OpenAI, nên các đánh giá mà chúng tôi theo dõi cần phải có giá trị và mang tính thông tin cao.