Các mô hình lớn không thể là nông dân mã! Khám phá đáng ngạc nhiên của Princeton: GPT-4 có tỷ lệ thành công bằng 0 trong việc giải quyết các vấn đề lập trình GitHub
công cụ mã hóa AI như ChatGPT đang đe dọa và Stack Overflow lại sa thải! Tuy nhiên, Princeton và Chicago nhận thấy rằng GPT-4 có tỷ lệ phân giải 0% cho các vấn đề GitHub trong thế giới thực.
Stack Overflow, đã được tạo bởi ChatGPT!
Do các lập trình viên đổ xô đến ChatGPT và Github Copilot nên hôm nay Stack Overflow phải thông báo sa thải hơn 100 nhân viên, chiếm gần 1/3 số lượng nhân viên.
Vì vậy, các công cụ mã hóa AI như ChatGPT thực sự sẽ lật đổ toàn bộ ngành công nghiệp?
Nhưng một nghiên cứu gần đây của Princeton và Chicago cho thấy LLM không dễ thực hiện như một nông dân viết mã.
Địa chỉ giấy:
Đối mặt với 2294 vấn đề GitHub thực sự, tỷ lệ vượt qua GPT-4 giải quyết các vấn đề GitHub ngẫu nhiên hóa ra là 0%!
Ngay cả mô hình tốt nhất, Claude 2, chỉ giải quyết được 1,96% trong số đó.
Các lập trình viên có thể mất việc vì ChatGPT không? Câu trả lời là - hoàn toàn không phải vào lúc này.
** Thích nghi hoặc bị diệt vong **
Là trang web hỗ trợ mã yêu thích của mọi nhà phát triển trên thế giới, Stack Overflow đã hoạt động tốt trước đây, tạo ra một đợt tuyển dụng vào năm ngoái, tăng gấp đôi lực lượng lao động của công ty lên 540.
Tuy nhiên, mọi thứ đã thay đổi kể từ khi OpenAI phát hành ChatGPT vào tháng 11 năm ngoái.
Sự trợ giúp được cung cấp bởi các chatbot AI cụ thể hơn so với bài đăng trên diễn đàn cách đây 5 năm. Với LLM, các nhà phát triển có thể ngay lập tức sửa mã chính xác, đề xuất tối ưu hóa và mô tả về những gì mỗi dòng mã đang làm.
Mặc dù LLM không cung cấp câu trả lời đáng tin cậy 100%, nhưng khả năng duy nhất để xác thực mã ngay lập tức bằng cách kiểm tra nó trong môi trường phát triển tích hợp IDE khiến việc viết mã trở thành trường hợp sử dụng lý tưởng cho ChatGPT.
Kết quả là, lưu lượng truy cập của Stack Overflow đã giảm đáng kể và các công cụ lập trình AI như ChatGPT và Github Copilot hỗ trợ GPT-4 đã trở thành nơi mới cho các nông dân lập trình.
Hôm nay, Giám đốc điều hành Prashanth Chandrasekar thông báo rằng Stack Overflow đã sa thải hơn một trăm nhân viên, tương đương 28% lực lượng lao động.
Lời giải thích của CEO về việc sa thải là Stack Overflow đang cố gắng đạt được lợi nhuận dưới áp lực kinh tế vĩ mô và tiếp tục giới thiệu những đổi mới sản phẩm.
** Qua sông và phá bỏ cây cầu? **
Điều trớ trêu lớn nhất về tác động của ChatGPT đối với Stack Overflow là sức mạnh của mô hình ngôn ngữ lớn phần lớn đến từ việc cạo các trang web như Stack Overflow.
Điều gì xảy ra nếu các mô hình ngôn ngữ lớn làm trống dữ liệu này mà không trả lại bất cứ điều gì và nếu tất cả các nguồn dữ liệu bị buộc phải rời khỏi doanh nghiệp?
Bây giờ, nhiều công ty công nghệ đã có một vấn đề lờ mờ: nếu có ít lập trình viên hơn, sẽ có ít dữ liệu nhân tạo hơn.
Làm thế nào để bạn đào tạo các mô hình AI mới mà không cần dữ liệu cập nhật?
Bạn muốn sử dụng dữ liệu của chúng tôi? Lấy tiền**
Stack Overflow, tất nhiên, không thể ngồi yên, nó đã chọn hai cách để tự cứu mình -
Một là phát triển công cụ mã hóa AI của riêng mình, OverflowAI, và hai là tìm kiếm quan hệ đối tác trực tiếp với các công ty công nghệ như OpenAI, sử dụng dữ liệu của Stack Overflow để xây dựng các mô hình AI.
OpenAI đang phát triển các điều khiển trình thu thập dữ liệu web cho ChatGPT để dữ liệu từ các trang web như Stack Overflow không thể được thu thập dữ liệu.
Giám đốc điều hành cho biết Stack Overflow đã đưa ra lập trường của mình: bất cứ ai muốn sử dụng dữ liệu của chúng tôi để đào tạo LLM đều phải trả tiền.
Các CEO tin rằng các trang web như Stack Overflow rất quan trọng đối với sự phát triển của các mô hình ngôn ngữ lớn và để thăng tiến, họ cần được đào tạo về kiến thức mới.
Prashanth Chandrasekar, CEO của Stack Overflow
LLM muốn lấy code farmer, vẫn còn sớm
Vì vậy, các mô hình ngôn ngữ lớn có thể thực sự lấy code farmers?
Các nhóm Princeton và Chicago nhận thấy rằng điều đó không dễ dàng!
Trong bài báo mới nhất, các nhà nghiên cứu đề xuất một khuôn khổ mới, SWE-bench, để đánh giá khả năng của các mô hình lớn để giải quyết 2294 vấn đề trong thế giới thực trên GitHub.
Nó đã được tìm thấy rằng các mô hình lớn hàng đầu như GPT-4 và Claude 2 có ít hơn 5% khả năng giải quyết các vấn đề thực sự.
Cụ thể hơn, GPT-4 có thể giải quyết các vấn đề GitHub ngẫu nhiên với tỷ lệ vượt qua là 0%, trong khi mô hình tốt nhất, Claude 2, chỉ có thể giải quyết 1,96% trong số đó.
Hơn nữa, khi sử dụng BM-25 để truy xuất các tệp mã có liên quan cho từng vấn đề, chỉ có 23% các bản vá do Claude 2 viết là hợp lệ (sẵn sàng repo) và chỉ ~ 1% thực sự giải quyết được vấn đề.
Ngoài ra, hiệu suất của các mô hình khác nhau trong việc giải quyết vấn đề với 12 thư viện Python phổ biến cũng khác nhau.
Mô hình GPT-4 đã đạt được kết quả như vậy, điều này thực sự đáng ngạc nhiên, xét cho cùng, nhiều người từ lâu đã coi nó là một "vũ khí lập trình".
Nhưng để thấy rõ, sức mạnh thực sự của AI, đừng để bị chấm điểm và lo lắng.
Một số cư dân mạng cho rằng đây là câu trả lời tốt nhất cho câu hỏi "liệu nông dân code có thất nghiệp do lập trình hay không".
Cuối cùng, ai đó đã tạo ra một bộ dữ liệu thực sự cho mô hình mã và Hum chỉ là cuộc phỏng vấn leetcode của LLM. Chúng ta đều biết rằng đây là biện pháp sai lầm cho các kỹ sư con người. Ít hơn 4% nghe có vẻ đúng, vì các mô hình lớn vẫn còn lâu mới tự động hoàn toàn.
Vì vậy, đây có thực sự là trường hợp với kết quả của SWE-bench trong việc đánh giá khả năng của các mô hình lớn?
**SWE-bench: Được thiết kế cho các mô hình mã hóa **
Trong nghiên cứu này, các tác giả nhận thấy rằng nhiều điểm chuẩn hiện tại để đo lường khả năng mã hóa của các mô hình lớn đã trở nên bão hòa và không thể đo lường sức mạnh thực sự của các mô hình lớn.
Ví dụ, trong Human, bài toán thử thách quá đơn giản và LLM chỉ cần một vài dòng mã để giải quyết một vấn đề độc lập.
Tuy nhiên, kỹ thuật phần mềm không đơn giản như vậy trong thực tế.
Sửa lỗi có thể yêu cầu duyệt một thư viện tài nguyên khổng lồ, hiểu mối quan hệ giữa các hàm trong các tệp khác nhau hoặc tìm một lỗi nhỏ trong mã phức tạp.
Lấy cảm hứng từ điều này, các nhà nghiên cứu từ Princeton và Chicago đã giới thiệu SWE-bench.
SWE-bench nhận các phiên bản tác vụ từ kho lưu trữ Python thực bằng cách kết nối các vấn đề GitHub và hợp nhất các giải pháp yêu cầu để giải quyết các bài kiểm tra liên quan.
Như được hiển thị trong hình ảnh, nhiệm vụ của mô hình, thường là báo cáo lỗi hoặc yêu cầu tính năng, là giải quyết vấn đề được cam kết với kho lưu trữ GitHub.
Mỗi tác vụ yêu cầu tạo một bản vá và mô tả các thay đổi sẽ được áp dụng cho cơ sở mã hiện có.
Sau đó sử dụng khung kiểm tra của kho lưu trữ SWE-bench để đánh giá cơ sở mã đã sửa đổi.
Để tìm ra các ví dụ chất lượng cao về các nhiệm vụ quy mô lớn, các nhà nghiên cứu đã trải qua ba giai đoạn sàng lọc:
Pull request (PR) lần đầu tiên được thu thập từ 12 kho Python mã nguồn mở phổ biến trên GitHub, tạo ra tổng cộng khoảng 90.000 PR.
Các nhà nghiên cứu tập trung vào các kho lưu trữ phổ biến vì chúng có xu hướng được duy trì tốt hơn, có hướng dẫn đóng góp rõ ràng và có phạm vi thử nghiệm tốt hơn. Mỗi PR có một cơ sở mã liên quan, tức là trạng thái của kho lưu trữ trước khi PR được hợp nhất.
**Giai đoạn 2: Lọc dựa trên thuộc tính. **
Nhiệm vụ ứng viên được tạo bằng cách chọn một PR hợp nhất đáp ứng các tiêu chí sau: (1) giải quyết vấn đề GitHub; (2) Sửa đổi tệp thử nghiệm của kho lưu trữ, điều này cho biết rằng người dùng rất có thể đã đóng góp các bài kiểm tra để kiểm tra xem sự cố đã được giải quyết chưa.
**Giai đoạn 3: Lọc dựa trên thực thi. **
Đối với mỗi nhiệm vụ của ứng viên, nội dung kiểm tra của PR được áp dụng và kết quả kiểm tra có liên quan trước và sau khi nội dung khác của PR được áp dụng.
Nhà nghiên cứu lọc ra các trường hợp nhiệm vụ không có ít nhất một bài kiểm tra và trạng thái của các thử nghiệm này thay đổi từ không vượt qua được (sau đây gọi là "không vượt qua bài kiểm tra"). Ngoài ra, các trường hợp gây ra lỗi cài đặt hoặc vận hành sẽ được lọc ra.
Thông qua các giai đoạn sàng lọc này, 90.000 PR ban đầu được sàng lọc thành 2.294 trường hợp nhiệm vụ, tạo nên băng ghế dự bị SWE.
Phân loại cuối cùng của các trường hợp tác vụ này trong các kho lưu trữ khác nhau được thể hiện trong Hình 3 bên dưới, với bảng là tính năng chính của các phiên bản tác vụ SWE-bench.
Các nhà nghiên cứu nhấn mạnh rằng các cơ sở mã này lớn, chứa hàng ngàn tệp và các yêu cầu kéo tham chiếu thường sửa đổi nhiều tệp cùng một lúc.
SWE-bench cung cấp một số lợi thế so với các điểm chuẩn lập trình LM hiện có.
Chúng bao gồm các cài đặt trong thế giới thực với các vấn đề và giải pháp do người dùng gửi, đầu vào đa dạng có các câu hỏi mã duy nhất từ 12 kho, khung đánh giá dựa trên thực thi mạnh mẽ và khả năng cập nhật liên tục điểm chuẩn với các phiên bản mới với sự can thiệp tối thiểu của con người.
** Tác vụ LLM: Chỉnh sửa cơ sở mã, giải quyết vấn đề **
Nhà nghiên cứu sẽ cung cấp cho mô hình lớn một mô tả văn bản về vấn đề, cũng như một cơ sở mã hoàn chỉnh.
Nhiệm vụ của mô hình lớn là chỉnh sửa codebase để giải quyết vấn đề.
Trong thực tế, các nhà nghiên cứu đại diện cho các thay đổi dưới dạng tệp vá, chỉ định dòng nào trong cơ sở mã cần sửa đổi để giải quyết vấn đề.
Làm thế nào để đánh giá xem giải pháp được đưa ra bởi LLM có tốt hay không?
Các nhà nghiên cứu sử dụng các bản vá lỗi Unix, áp dụng các bản vá được tạo cho cơ sở mã, sau đó thực hiện các bài kiểm tra đơn vị và hệ thống liên quan đến các trường hợp tác vụ.
Nếu bản vá được áp dụng thành công và tất cả các thử nghiệm này được thông qua, sơ đồ do LLM đề xuất có thể được coi là đã giải quyết thành công vấn đề.
Số liệu của đường cơ sở, là tỷ lệ phần trăm của các trường hợp tác vụ đã giải quyết.
** Xây dựng bộ dữ liệu duy nhất cho SWE-bench**
Điểm chuẩn NLP truyền thống thường chỉ liên quan đến các chuỗi đầu vào và đầu ra ngắn và xem xét một số vấn đề "nhân tạo" được tạo riêng cho điểm chuẩn.
Ngược lại, để xây dựng SWE-bench, các nhà nghiên cứu đã đưa các thuộc tính độc đáo vào tập dữ liệu.
Ví dụ, các nhiệm vụ kỹ thuật phần mềm thực sự được sử dụng.
Vì mỗi phiên bản tác vụ trong SWE-bench chứa một cơ sở mã lớn và phức tạp và mô tả về vấn đề liên quan, việc giải quyết SWE-bench đòi hỏi các kỹ năng và kiến thức phức tạp của các kỹ sư phần mềm có kinh nghiệm, thường không được đánh giá trong các tiêu chuẩn tạo mã truyền thống.
Hơn nữa, quá trình thu thập có thể dễ dàng áp dụng cho bất kỳ kho lưu trữ Python nào trên GitHub mà không cần sự can thiệp của con người.
Do đó, các nhà nghiên cứu có thể mở rộng SWE-bench bằng cách cung cấp các trường hợp nhiệm vụ mới và đánh giá mô hình ngôn ngữ cho các vấn đề được tạo sau ngày đào tạo, đảm bảo rằng kho dữ liệu đào tạo không chứa giải pháp.
Ngoài ra, các nhà nghiên cứu đảm bảo các đầu vào dài khác nhau trong điểm chuẩn, đánh giá mạnh mẽ, chỉnh sửa mã đa ngữ cảnh, nhiều giải pháp, v.v.
Tinh chỉnh SWE-Llama
Tiếp theo, đã đến lúc đánh giá hiệu quả của các mô hình mở và độc quyền trong khung SWE-bench.
Tuy nhiên, các nhà nghiên cứu phát hiện ra rằng các mô hình tinh chỉnh CodeLlama có sẵn không thể tuân theo các hướng dẫn chi tiết để tạo các chỉnh sửa mã trên toàn thư viện, thường xuất ra các phản hồi giữ chỗ hoặc mã không liên quan.
Để đánh giá khả năng của các mô hình này, các nhà nghiên cứu đã thực hiện tinh chỉnh có giám sát (SFT) trên mô hình CodeLlama-Python 7 tỷ tham số và mô hình CodeLlama-Python 13 tỷ tham số.
Mô hình kết quả là một trình soạn thảo kho lưu trữ chuyên dụng chạy trên phần cứng cấp người tiêu dùng và giải quyết các vấn đề GitHub.
### ** Mô hình lớn thất bại **
Tiếp theo, các nhà nghiên cứu đánh giá GPT-3.5, GPT-4, Cluade 2 và các mô hình tinh chỉnh.
Hóa ra tất cả các mô hình đều thất bại - không ai trong số họ giải quyết được tất cả trừ những vấn đề đơn giản nhất.
Ví dụ, Claude 2 và GPT-4 chỉ có thể giải quyết lần lượt 4,8% và 1,7% nhiệm vụ.
Sau khi sử dụng BM25 retriever, hiệu suất của Claude 2 giảm xuống còn 1,96%.
** Các thư viện khác nhau có mức độ khó khác nhau. **
Nếu bạn chia nhỏ hiệu suất theo kho lưu trữ, bạn sẽ thấy rằng tất cả các mô hình đều thể hiện xu hướng tương tự trên các thư viện.
Tuy nhiên, các vấn đề được giải quyết bởi mỗi mô hình không nhất thiết phải chồng chéo rộng rãi. Ví dụ: trong thiết lập oracle, Claude 2 và SWE-Llama 13b hoạt động tương đương, giải quyết lần lượt 110 và 91 trường hợp trên mỗi mô hình.
**Độ khó phụ thuộc vào độ dài ngữ cảnh. **
Các mô hình có thể được đào tạo trước trên các chuỗi mã dài, nhưng thường yêu cầu một hàm duy nhất được tạo tại một thời điểm và cung cấp một khung với ngữ cảnh hạn chế để xác định vấn đề.
Như được hiển thị, bạn có thể thấy rằng hiệu suất của Claude 2 giảm đáng kể khi tổng chiều dài của bối cảnh tăng lên, điều này cũng có thể được quan sát thấy trong các mô hình khác.
Ngay cả khi việc tăng kích thước ngữ cảnh tối đa của BM25 sẽ cải thiện việc thu hồi so với các tệp Oracle, hiệu suất vẫn sẽ giảm vì mô hình đơn giản là không thể xác định vị trí mã có vấn đề trong từ điển đồng nghĩa rộng lớn.
**Độ khó không phụ thuộc vào ngày giải quyết vấn đề. **
Bảng 7 hiển thị kết quả mô hình theo ngày cho các PR được tạo trước hoặc sau năm 2023 trong cài đặt tìm kiếm "oracle".
Đối với hầu hết các mô hình, ngoại trừ GPT-4, có rất ít sự khác biệt về hiệu suất trước hoặc sau ngày này.
Ngoài ra, nghiên cứu cho thấy việc tinh chỉnh mô hình rất nhạy cảm với những thay đổi trong phân phối ngữ cảnh và việc tạo bản vá dễ dàng hơn là tạo toàn bộ tệp. Và các mô hình lớn có xu hướng tạo ra các chỉnh sửa ngắn hơn, đơn giản hơn.
**LLM không thay thế cho các lập trình viên, nhưng nó có thể tăng tốc quy trình làm việc **
Một số cư dân mạng có hy vọng và hy vọng vào tương lai của "mô hình tổng quát".
Đúng vậy, đó là những gì tôi đang nói. Mô hình tổng quát không đủ tốt để có độ dài ngữ cảnh đủ rộng để tự viết mã, ngoại trừ các đoạn mã tương đối ngắn.
Nhưng tôi nghĩ đó chỉ là vấn đề thời gian. Tôi có thể thấy trước rằng trong tương lai gần, LLM tổng quát với đào tạo cụ thể sẽ trở thành một mô hình rất chuyên nghiệp.
Mặc dù các mô hình lớn không thể thay thế cho các lập trình viên, nhưng chúng có thể tăng tốc quy trình làm việc của mình. Những gì trước đây để lấy một nhóm 10 người bây giờ có thể chỉ cần 4 người. Điều này giải phóng nguồn lực cho các mục tiêu khác do công ty chuẩn bị.
Thay vì sa thải nhân viên để tiết kiệm tiền, hãy để các nhà phát triển hoàn thành những điều tuyệt vời với tốc độ chóng mặt!
Tài nguyên:
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Các mô hình lớn không thể là nông dân mã! Khám phá đáng ngạc nhiên của Princeton: GPT-4 có tỷ lệ thành công bằng 0 trong việc giải quyết các vấn đề lập trình GitHub
Nguồn bài viết: Shin Ji Yuan
Stack Overflow, đã được tạo bởi ChatGPT!
Do các lập trình viên đổ xô đến ChatGPT và Github Copilot nên hôm nay Stack Overflow phải thông báo sa thải hơn 100 nhân viên, chiếm gần 1/3 số lượng nhân viên.
Nhưng một nghiên cứu gần đây của Princeton và Chicago cho thấy LLM không dễ thực hiện như một nông dân viết mã.
Đối mặt với 2294 vấn đề GitHub thực sự, tỷ lệ vượt qua GPT-4 giải quyết các vấn đề GitHub ngẫu nhiên hóa ra là 0%!
Ngay cả mô hình tốt nhất, Claude 2, chỉ giải quyết được 1,96% trong số đó.
** Thích nghi hoặc bị diệt vong **
Là trang web hỗ trợ mã yêu thích của mọi nhà phát triển trên thế giới, Stack Overflow đã hoạt động tốt trước đây, tạo ra một đợt tuyển dụng vào năm ngoái, tăng gấp đôi lực lượng lao động của công ty lên 540.
Tuy nhiên, mọi thứ đã thay đổi kể từ khi OpenAI phát hành ChatGPT vào tháng 11 năm ngoái.
Mặc dù LLM không cung cấp câu trả lời đáng tin cậy 100%, nhưng khả năng duy nhất để xác thực mã ngay lập tức bằng cách kiểm tra nó trong môi trường phát triển tích hợp IDE khiến việc viết mã trở thành trường hợp sử dụng lý tưởng cho ChatGPT.
Kết quả là, lưu lượng truy cập của Stack Overflow đã giảm đáng kể và các công cụ lập trình AI như ChatGPT và Github Copilot hỗ trợ GPT-4 đã trở thành nơi mới cho các nông dân lập trình.
Hôm nay, Giám đốc điều hành Prashanth Chandrasekar thông báo rằng Stack Overflow đã sa thải hơn một trăm nhân viên, tương đương 28% lực lượng lao động.
** Qua sông và phá bỏ cây cầu? **
Điều trớ trêu lớn nhất về tác động của ChatGPT đối với Stack Overflow là sức mạnh của mô hình ngôn ngữ lớn phần lớn đến từ việc cạo các trang web như Stack Overflow.
Điều gì xảy ra nếu các mô hình ngôn ngữ lớn làm trống dữ liệu này mà không trả lại bất cứ điều gì và nếu tất cả các nguồn dữ liệu bị buộc phải rời khỏi doanh nghiệp?
Bây giờ, nhiều công ty công nghệ đã có một vấn đề lờ mờ: nếu có ít lập trình viên hơn, sẽ có ít dữ liệu nhân tạo hơn.
Làm thế nào để bạn đào tạo các mô hình AI mới mà không cần dữ liệu cập nhật?
Bạn muốn sử dụng dữ liệu của chúng tôi? Lấy tiền**
Stack Overflow, tất nhiên, không thể ngồi yên, nó đã chọn hai cách để tự cứu mình -
Một là phát triển công cụ mã hóa AI của riêng mình, OverflowAI, và hai là tìm kiếm quan hệ đối tác trực tiếp với các công ty công nghệ như OpenAI, sử dụng dữ liệu của Stack Overflow để xây dựng các mô hình AI.
Giám đốc điều hành cho biết Stack Overflow đã đưa ra lập trường của mình: bất cứ ai muốn sử dụng dữ liệu của chúng tôi để đào tạo LLM đều phải trả tiền.
Các CEO tin rằng các trang web như Stack Overflow rất quan trọng đối với sự phát triển của các mô hình ngôn ngữ lớn và để thăng tiến, họ cần được đào tạo về kiến thức mới.
LLM muốn lấy code farmer, vẫn còn sớm
Vì vậy, các mô hình ngôn ngữ lớn có thể thực sự lấy code farmers?
Các nhóm Princeton và Chicago nhận thấy rằng điều đó không dễ dàng!
Nó đã được tìm thấy rằng các mô hình lớn hàng đầu như GPT-4 và Claude 2 có ít hơn 5% khả năng giải quyết các vấn đề thực sự.
Cụ thể hơn, GPT-4 có thể giải quyết các vấn đề GitHub ngẫu nhiên với tỷ lệ vượt qua là 0%, trong khi mô hình tốt nhất, Claude 2, chỉ có thể giải quyết 1,96% trong số đó.
Ngoài ra, hiệu suất của các mô hình khác nhau trong việc giải quyết vấn đề với 12 thư viện Python phổ biến cũng khác nhau.
Nhưng để thấy rõ, sức mạnh thực sự của AI, đừng để bị chấm điểm và lo lắng.
**SWE-bench: Được thiết kế cho các mô hình mã hóa **
Trong nghiên cứu này, các tác giả nhận thấy rằng nhiều điểm chuẩn hiện tại để đo lường khả năng mã hóa của các mô hình lớn đã trở nên bão hòa và không thể đo lường sức mạnh thực sự của các mô hình lớn.
Ví dụ, trong Human, bài toán thử thách quá đơn giản và LLM chỉ cần một vài dòng mã để giải quyết một vấn đề độc lập.
Tuy nhiên, kỹ thuật phần mềm không đơn giản như vậy trong thực tế.
Lấy cảm hứng từ điều này, các nhà nghiên cứu từ Princeton và Chicago đã giới thiệu SWE-bench.
SWE-bench nhận các phiên bản tác vụ từ kho lưu trữ Python thực bằng cách kết nối các vấn đề GitHub và hợp nhất các giải pháp yêu cầu để giải quyết các bài kiểm tra liên quan.
Như được hiển thị trong hình ảnh, nhiệm vụ của mô hình, thường là báo cáo lỗi hoặc yêu cầu tính năng, là giải quyết vấn đề được cam kết với kho lưu trữ GitHub.
Mỗi tác vụ yêu cầu tạo một bản vá và mô tả các thay đổi sẽ được áp dụng cho cơ sở mã hiện có.
Sau đó sử dụng khung kiểm tra của kho lưu trữ SWE-bench để đánh giá cơ sở mã đã sửa đổi.
Pull request (PR) lần đầu tiên được thu thập từ 12 kho Python mã nguồn mở phổ biến trên GitHub, tạo ra tổng cộng khoảng 90.000 PR.
Các nhà nghiên cứu tập trung vào các kho lưu trữ phổ biến vì chúng có xu hướng được duy trì tốt hơn, có hướng dẫn đóng góp rõ ràng và có phạm vi thử nghiệm tốt hơn. Mỗi PR có một cơ sở mã liên quan, tức là trạng thái của kho lưu trữ trước khi PR được hợp nhất.
**Giai đoạn 2: Lọc dựa trên thuộc tính. **
Nhiệm vụ ứng viên được tạo bằng cách chọn một PR hợp nhất đáp ứng các tiêu chí sau: (1) giải quyết vấn đề GitHub; (2) Sửa đổi tệp thử nghiệm của kho lưu trữ, điều này cho biết rằng người dùng rất có thể đã đóng góp các bài kiểm tra để kiểm tra xem sự cố đã được giải quyết chưa.
**Giai đoạn 3: Lọc dựa trên thực thi. **
Đối với mỗi nhiệm vụ của ứng viên, nội dung kiểm tra của PR được áp dụng và kết quả kiểm tra có liên quan trước và sau khi nội dung khác của PR được áp dụng.
Nhà nghiên cứu lọc ra các trường hợp nhiệm vụ không có ít nhất một bài kiểm tra và trạng thái của các thử nghiệm này thay đổi từ không vượt qua được (sau đây gọi là "không vượt qua bài kiểm tra"). Ngoài ra, các trường hợp gây ra lỗi cài đặt hoặc vận hành sẽ được lọc ra.
Thông qua các giai đoạn sàng lọc này, 90.000 PR ban đầu được sàng lọc thành 2.294 trường hợp nhiệm vụ, tạo nên băng ghế dự bị SWE.
Phân loại cuối cùng của các trường hợp tác vụ này trong các kho lưu trữ khác nhau được thể hiện trong Hình 3 bên dưới, với bảng là tính năng chính của các phiên bản tác vụ SWE-bench.
Các nhà nghiên cứu nhấn mạnh rằng các cơ sở mã này lớn, chứa hàng ngàn tệp và các yêu cầu kéo tham chiếu thường sửa đổi nhiều tệp cùng một lúc.
SWE-bench cung cấp một số lợi thế so với các điểm chuẩn lập trình LM hiện có.
Chúng bao gồm các cài đặt trong thế giới thực với các vấn đề và giải pháp do người dùng gửi, đầu vào đa dạng có các câu hỏi mã duy nhất từ 12 kho, khung đánh giá dựa trên thực thi mạnh mẽ và khả năng cập nhật liên tục điểm chuẩn với các phiên bản mới với sự can thiệp tối thiểu của con người.
** Tác vụ LLM: Chỉnh sửa cơ sở mã, giải quyết vấn đề **
Nhà nghiên cứu sẽ cung cấp cho mô hình lớn một mô tả văn bản về vấn đề, cũng như một cơ sở mã hoàn chỉnh.
Nhiệm vụ của mô hình lớn là chỉnh sửa codebase để giải quyết vấn đề.
Trong thực tế, các nhà nghiên cứu đại diện cho các thay đổi dưới dạng tệp vá, chỉ định dòng nào trong cơ sở mã cần sửa đổi để giải quyết vấn đề.
Các nhà nghiên cứu sử dụng các bản vá lỗi Unix, áp dụng các bản vá được tạo cho cơ sở mã, sau đó thực hiện các bài kiểm tra đơn vị và hệ thống liên quan đến các trường hợp tác vụ.
Số liệu của đường cơ sở, là tỷ lệ phần trăm của các trường hợp tác vụ đã giải quyết.
** Xây dựng bộ dữ liệu duy nhất cho SWE-bench**
Điểm chuẩn NLP truyền thống thường chỉ liên quan đến các chuỗi đầu vào và đầu ra ngắn và xem xét một số vấn đề "nhân tạo" được tạo riêng cho điểm chuẩn.
Ngược lại, để xây dựng SWE-bench, các nhà nghiên cứu đã đưa các thuộc tính độc đáo vào tập dữ liệu.
Ví dụ, các nhiệm vụ kỹ thuật phần mềm thực sự được sử dụng.
Hơn nữa, quá trình thu thập có thể dễ dàng áp dụng cho bất kỳ kho lưu trữ Python nào trên GitHub mà không cần sự can thiệp của con người.
Do đó, các nhà nghiên cứu có thể mở rộng SWE-bench bằng cách cung cấp các trường hợp nhiệm vụ mới và đánh giá mô hình ngôn ngữ cho các vấn đề được tạo sau ngày đào tạo, đảm bảo rằng kho dữ liệu đào tạo không chứa giải pháp.
Ngoài ra, các nhà nghiên cứu đảm bảo các đầu vào dài khác nhau trong điểm chuẩn, đánh giá mạnh mẽ, chỉnh sửa mã đa ngữ cảnh, nhiều giải pháp, v.v.
Tinh chỉnh SWE-Llama
Tiếp theo, đã đến lúc đánh giá hiệu quả của các mô hình mở và độc quyền trong khung SWE-bench.
Tuy nhiên, các nhà nghiên cứu phát hiện ra rằng các mô hình tinh chỉnh CodeLlama có sẵn không thể tuân theo các hướng dẫn chi tiết để tạo các chỉnh sửa mã trên toàn thư viện, thường xuất ra các phản hồi giữ chỗ hoặc mã không liên quan.
Để đánh giá khả năng của các mô hình này, các nhà nghiên cứu đã thực hiện tinh chỉnh có giám sát (SFT) trên mô hình CodeLlama-Python 7 tỷ tham số và mô hình CodeLlama-Python 13 tỷ tham số.
Mô hình kết quả là một trình soạn thảo kho lưu trữ chuyên dụng chạy trên phần cứng cấp người tiêu dùng và giải quyết các vấn đề GitHub.
Tiếp theo, các nhà nghiên cứu đánh giá GPT-3.5, GPT-4, Cluade 2 và các mô hình tinh chỉnh.
Hóa ra tất cả các mô hình đều thất bại - không ai trong số họ giải quyết được tất cả trừ những vấn đề đơn giản nhất.
Ví dụ, Claude 2 và GPT-4 chỉ có thể giải quyết lần lượt 4,8% và 1,7% nhiệm vụ.
Sau khi sử dụng BM25 retriever, hiệu suất của Claude 2 giảm xuống còn 1,96%.
** Các thư viện khác nhau có mức độ khó khác nhau. **
Nếu bạn chia nhỏ hiệu suất theo kho lưu trữ, bạn sẽ thấy rằng tất cả các mô hình đều thể hiện xu hướng tương tự trên các thư viện.
Tuy nhiên, các vấn đề được giải quyết bởi mỗi mô hình không nhất thiết phải chồng chéo rộng rãi. Ví dụ: trong thiết lập oracle, Claude 2 và SWE-Llama 13b hoạt động tương đương, giải quyết lần lượt 110 và 91 trường hợp trên mỗi mô hình.
**Độ khó phụ thuộc vào độ dài ngữ cảnh. **
Các mô hình có thể được đào tạo trước trên các chuỗi mã dài, nhưng thường yêu cầu một hàm duy nhất được tạo tại một thời điểm và cung cấp một khung với ngữ cảnh hạn chế để xác định vấn đề.
Như được hiển thị, bạn có thể thấy rằng hiệu suất của Claude 2 giảm đáng kể khi tổng chiều dài của bối cảnh tăng lên, điều này cũng có thể được quan sát thấy trong các mô hình khác.
Ngay cả khi việc tăng kích thước ngữ cảnh tối đa của BM25 sẽ cải thiện việc thu hồi so với các tệp Oracle, hiệu suất vẫn sẽ giảm vì mô hình đơn giản là không thể xác định vị trí mã có vấn đề trong từ điển đồng nghĩa rộng lớn.
Bảng 7 hiển thị kết quả mô hình theo ngày cho các PR được tạo trước hoặc sau năm 2023 trong cài đặt tìm kiếm "oracle".
Đối với hầu hết các mô hình, ngoại trừ GPT-4, có rất ít sự khác biệt về hiệu suất trước hoặc sau ngày này.
**LLM không thay thế cho các lập trình viên, nhưng nó có thể tăng tốc quy trình làm việc **
Một số cư dân mạng có hy vọng và hy vọng vào tương lai của "mô hình tổng quát".
Đúng vậy, đó là những gì tôi đang nói. Mô hình tổng quát không đủ tốt để có độ dài ngữ cảnh đủ rộng để tự viết mã, ngoại trừ các đoạn mã tương đối ngắn.
Nhưng tôi nghĩ đó chỉ là vấn đề thời gian. Tôi có thể thấy trước rằng trong tương lai gần, LLM tổng quát với đào tạo cụ thể sẽ trở thành một mô hình rất chuyên nghiệp.
Thay vì sa thải nhân viên để tiết kiệm tiền, hãy để các nhà phát triển hoàn thành những điều tuyệt vời với tốc độ chóng mặt!