Các công cụ mã hóa AI như ChatGPT đang ra đời mạnh mẽ và StackOverflow lại đang sa thải nhân viên! Tuy nhiên, Princeton và Đại học Chicago phát hiện ra rằng khi đối mặt với các vấn đề GitHub trong thế giới thực, tỷ lệ phân giải của GPT-4 thực sự là 0%. StackOverflow đã được ChatGPT ra mắt! Vì các lập trình viên đang đổ xô vào ChatGPT và GithubCopilot với số lượng lớn nên StackOverflow không còn cách nào khác ngoài việc hôm nay phải thông báo sa thải hơn 100 nhân viên, chiếm gần 1/3 số nhân viên của mình.


Vậy, liệu các công cụ mã hóa AI như ChatGPT có thực sự sẽ lật đổ toàn bộ ngành công nghiệp không?

Tuy nhiên, một nghiên cứu gần đây của Princeton và Đại học Chicago cho thấy LLM không dễ dàng thay thế các lập trình viên.


Địa chỉ trên giấy: https://arxiv.org/abs/2 310.06770

Đối mặt với 2294 vấn đề thực tế trên GitHub, tốc độ vượt qua của GPT-4 trong việc giải quyết các vấn đề GitHub ngẫu nhiên thực tế là 0%!

Ngay cả mô hình tốt nhất Claude2 cũng chỉ có thể giải quyết được 1,96% trong số đó.


Liệu các lập trình viên có bị 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 diệt vong

Là trang web hỗ trợ mã hóa yêu thích của mọi nhà phát triển trên thế giới, StackOverflow trước đây vẫn ở tình trạng tốt. Nó đã gây ra một đợt tuyển dụng điên cuồng vào năm ngoái và tăng gấp đôi số lượng nhân viên trong toàn công ty lên 540 người.

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 do chatbot AI cung cấp cụ thể hơn bài đăng trên diễn đàn từ 5 năm trước. Thông qua LLM, các nhà phát triển có thể sửa ngay lập tức mã chính xác, đề xuất tối ưu hóa và mô tả về chức năng của từng dòng mã.

Mặc dù các câu trả lời do LLM cung cấp không đáng tin cậy 100% nhưng mã này có khả năng duy nhất là xác minh mã ngay lập tức bằng cách kiểm tra mã đó trong môi trường phát triển tích hợp IDE. Tất cả điều này làm cho việc viết mã trở thành một trường hợp sử dụng lý tưởng cho ChatGPT.

Do đó, lưu lượng truy cập StackOverflow đã giảm đáng kể và các công cụ lập trình AI như ChatGPT và GithubCopilot dựa trên GPT-4 đã trở thành địa điểm mới cho các lập trình viên.

Hôm nay, CEO Prashanth Chandrasekar thông báo StackOverflow sẽ sa thải hơn 100 nhân viên, chiếm 28% tổng số nhân viên.


Lời giải thích của CEO về việc sa thải là dưới áp lực kinh tế vĩ mô, StackOverflow đang nỗ lực để đạt được lợi nhuận và liên tục tung ra các cải tiến sản phẩm.

Đốt cầu?

Điều trớ trêu lớn nhất về tác động của ChatGPT đối với StackOverflow là khả năng mạnh mẽ của các mô hình ngôn ngữ lớn phần lớn đến từ việc thu thập dữ liệu các trang web như StackOverflow.

Các mô hình ngôn ngữ lớn hút dữ liệu này mà không trả lại bất cứ điều gì. Điều gì sẽ xảy ra nếu tất cả các nguồn dữ liệu bị buộc rời khỏi doanh nghiệp?

Bây giờ, nhiều công ty công nghệ đã phải đối mặt với một vấn đề sắp xảy ra: nếu có ít lập trình viên hơn thì sẽ có ít dữ liệu nhân tạo hơn.

Làm cách nào để đào tạo mô hình AI mới nếu không có dữ liệu mới nhất?

Bạn muốn sử dụng dữ liệu của chúng tôi? Lấy tiền

StackOverflow chắc chắn không thể ngồi yên chờ chết. Họ đã chọn hai cách để tự cứu mình——

TAGPH 112Đầu tiên là phát triển công cụ mã hóa AI OverflowAI của riêng mình, và thứ hai là trực tiếp tìm kiếm sự hợp tác với các công ty công nghệ như OpenAI, vì các công ty này sẽ sử dụng dữ liệu StackOverflow để xây dựng các mô hình AI.


Có thông tin cho rằng OpenAI đang phát triển các biện pháp kiểm soát trình thu thập dữ liệu web cho ChatGPT để dữ liệu từ các trang web như StackOverflow sẽ không bị thu thập thông tin.

Giám đốc điều hành cho biết StackOverflow đã nêu rõ quan điểm của mình: bất kỳ ai muốn sử dụng dữ liệu của chúng tôi để đào tạo LLM sẽ phải trả tiền.

Giám đốc điều hành tin rằng các trang web như StackOverflow 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à để tiến bộ, họ cần được đào tạo về kiến ​​thức mới.


Giám đốc điều hành StackOverflow Pra shanthChandrasekar

LLM muốn trở thành nông dân lập trình nhưng vẫn chưa thực hiện được sớm

Vậy liệu các mô hình ngôn ngữ lớn có thể thực sự đánh bại được các lập trình viên?

Đội ngũ của Đại học Princeton và Chicago đã phát hiện ra rằng điều đó không hề dễ dàng!


Trong bài báo mới nhất, các nhà nghiên cứu đã đề xuất một khung SWE-bench mới để đánh giá khả năng của các mô hình lớn trong việc giải quyết 2294 vấn đề GitHub thực tế.

Người ta nhận thấy rằng khả năng dẫn đầu các mô hình lớn như GPT-4 và Claude2 để giải quyết các vấn đề thực tế chỉ là 5%.

Nói 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% và mô hình tốt nhất, Claude2, chỉ có thể giải quyết được 1,96% trong số đó.



Giá trị hơn Điều đáng nói là khi sử dụng BM-25 để truy xuất các file mã liên quan cho từng vấn đề thì chỉ có 23% số bản vá được viết bởi Claude2 có hiệu quả (có thể được sử dụng trong repo) và chỉ ~ 1% thực sự giải quyết được vấn đề.

Ngoài ra, các mô hình khác nhau cũng có hiệu suất giải quyết 12 vấn đề thư viện Python phổ biến khác nhau.


Mẫu lớn GPT-4 đã đạt được kết quả như vậy, điều này thực sự đáng ngạc nhiên. Suy cho cùng, nhiều người đã coi nó như một "công cụ lập trình".

Nhưng bạn phải nhìn rõ sức mạnh thực sự của AI và đừng lo lắng vì xếp hạng bị trượt.


Một số cư dân mạng cho rằng đây là câu trả lời đúng nhất cho câu hỏi "liệu lập trình viên có bị thất nghiệp vì lập trình không?"


Cuối cùng ai đó đã tạo ra một tập dữ liệu đánh giá thực sự cho các mô hình mã, HumEval chỉ là cuộc phỏng vấn leetcode của LLM. Tất cả chúng ta đều biết đây là một thước đo sai lầm đối với 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 chưa thể tự chủ hoàn toàn.


Vậy kết quả SWE-bench đánh giá khả năng của các mô hình lớn có thực sự đúng không?

SWE-bench: Được thiết kế dành riêng cho các mô hình mã hóa

Trong nghiên cứu này, tác giả nhận thấy nhiều tiêu chuẩn hiện tại để đánh giá 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ể đánh giá được sức mạnh thực sự của các mô hình lớn.

Ví dụ: trong HumanEval, bài toán thử thách quá đơn giản và LLM có thể giải các bài toán độc lập chỉ với một vài dòng mã.

Tuy nhiên, công nghệ phần mềm trên thực tế không đơn giản như vậy.


Việc sửa lỗi có thể yêu cầu duyệt qua một thư viện tài nguyên khổng lồ, hiểu mối quan hệ giữa các chức năng 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ừ Đại học Princeton và Chicago đã giới thiệu băng ghế dự bị SWE.

SWE-bench lấy các phiên bản tác vụ từ cơ sở mã 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 với các thử nghiệm liên quan.

Như được hiển thị trong hì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 các vấn đề được gửi tới kho lưu trữ GitHub.

Mỗi nhiệm vụ yêu cầu tạo một bản vá và mô tả những thay đổi sẽ được áp dụng cho cơ sở mã hiện có.

Sau đó, sử dụng khung thử nghiệm SWE-bench của kho để đánh giá cơ sở mã đã sửa đổi.


Để tìm ra các ví dụ nhiệm vụ quy mô lớn chất lượng cao, các nhà nghiên cứu đã trải qua ba giai đoạn Sàng lọc:


Giai đoạn 1: Lựa chọn kho hàng và tìm kiếm dữ liệu.

lần đầu tiên thu thập các yêu cầu kéo (PR) từ 12 kho lưu trữ mã Python 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ì những kho lưu trữ này có xu hướng được duy trì tốt hơn, có nguyên tắc dành cho người đóng góp rõ ràng và có phạm vi kiểm tra tốt hơn. Mỗi PR có một cơ sở mã liên quan, đó là trạng thái của kho trước khi PR được hợp nhất.

Giai đoạn thứ hai: lọc dựa trên thuộc tính.

Tạo nhiệm vụ ứng viên bằng cách chọn các PR hợp nhất đáp ứng các tiêu chí sau: (1) Vấn đề GitHub đã được giải quyết; (2) Các tệp thử nghiệm của kho lưu trữ đã được sửa đổi, cho thấy rằng người dùng có thể đã đóng góp các thử nghiệm để kiểm tra xem sự cố đã được giải quyết hay chưa.

Giai đoạn thứ ba: 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 PR sẽ được áp dụng và kết quả kiểm tra liên quan trước và sau khi áp dụng nội dung PR khác sẽ được ghi lại.

Người nghiên cứu sẽ 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 có trạng thái thay đổi từ không đạt thành vượt qua (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 chạy đều được lọc ra.

Qua các giai đoạn sàng lọc này, 90.000 PR ban đầu đã được lọc thành 2.294 trường hợp nhiệm vụ, tạo thành SWE-bench.

Như được hiển thị trong Hình 3 bên dưới, nó hiển thị phân loại cuối cùng của các phiên bản tác vụ này trong các thư viện tài nguyên khác nhau. Bảng này là đặc điểm chính của các phiên bản nhiệm vụ băng ghế dự bị SWE.

Các nhà nghiên cứu nhấn mạnh rằng các cơ sở mã này rất lớn, chứa hàng nghì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.

So với các tiêu chuẩn lập trình LM hiện có, băng ghế dự bị SWE có một số ưu điểm.

Điều này bao gồm tận dụng các cài đặt trong thế giới thực cho các vấn đề và giải pháp do người dùng gửi, đầu vào đa dạng bao gồm các vấn đề về mã duy nhất từ ​​12 kho lưu trữ, 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.

LLM Nhiệm vụ: chỉnh sửa cơ sở mã và giải quyết vấn đề

Nhà nghiên cứu sẽ cung cấp cho mô hình lớn một văn bản mô tả vấn đề cũng như cơ sở mã hoàn chỉnh.

Nhiệm vụ của mô hình lớn là chỉnh sửa cơ sở mã để giải quyết vấn đề.

Trong thực tế, các nhà nghiên cứu biểu diễn các sửa đổi dưới dạng tệp bản vá, trong đó chỉ định những dòng nào trong cơ sở mã sẽ được sửa đổi để khắc phục sự cố.


Làm thế nào để đánh giá giải pháp LLM đưa ra có tốt hay không?

Các nhà nghiên cứu sẽ sử dụng các bản vá unix, áp dụng các bản vá được tạo vào cơ sở mã, sau đó thực hiện các thử nghiệm đơn vị và hệ thống liên quan đến phiên bản 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 đều vượt qua, giải pháp do LLM đề xuất có thể được coi là đã giải quyết thành công vấn đề. Số liệu cho điểm chuẩn

là tỷ lệ phần trăm của các trường hợp tác vụ được giải quyết.

Xây dựng tập 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 đặc biệt cho điểm chuẩn.

Ngược lại, để xây dựng băng ghế SWE, các nhà nghiên cứu đưa các thuộc tính duy nhất vào tập dữ liệu.

Ví dụ: sử dụng các tác vụ kỹ thuật phần mềm thực tế.


Vì mỗi phiên bản nhiệm vụ trong SWE-bench chứa một cơ sở mã lớn và phức tạp cũng như mô tả vấn đề liên quan nên việc giải SWE-bench đòi hỏi các kỹ sư phần mềm có kinh nghiệm phải có kỹ năng và kiến ​​thức phức tạp nhưng những kỹ năng và kiến ​​thức phức tạp này thường không được đánh giá trong các điểm chuẩn tạo mã truyền thống.

Hơn nữa, quy 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 hoặc ít cần can thiệp thủ công.

Do đó, các nhà nghiên cứu có thể mở rộng SWE-bench bằng cách liên tục cung cấp các phiên bản nhiệm vụ mới và đánh giá mô hình ngôn ngữ về các vấn đề được tạo ra sau ngày đào tạo, đảm bảo rằng kho ngữ liệu đào tạo không chứa lời giải.

Ngoài ra, các nhà nghiên cứu còn đả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, phạm vi giải pháp rộng, v.v.

Tinh chỉnh SWE-Llama

Tiếp theo, đã đến lúc đánh giá tác động của các mô hình mở và mô hình độc quyền trong khung SWE-bench.

Tuy nhiên, các nhà nghiên cứu nhận thấy rằng mô hình tinh chỉnh CoDELLama sẵn có 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 bộ thư viện tài nguyên và thường đưa 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 thu được là trình chỉnh sửa 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.


Các mô hình lớn bị đánh bạiTAG PH48

Tiếp theo, các nhà nghiên cứu đã đánh giá GPT-3.5, GPT-4, Cluade2 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 - chúng không thể giải quyết được tất cả trừ những vấn đề đơn giản nhất.

Ví dụ: Claude2 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 chó săn BM25, hiệu suất của Claude2 tiếp tục giảm xuống còn 1,96%.

Các thư viện tài nguyên khác nhau có mức độ khó khác nhau.

Nếu bạn chia nhỏ hiệu suất theo thư viện tài nguyên, bạn sẽ thấy rằng tất cả các mô hình đều hiển thị xu hướng tương tự trên các thư viện tài nguyên khác nhau.

Tuy nhiên, các vấn đề mà mỗi mẫu máy giải quyết không nhất thiết phải chồng chéo lên nhau. Ví dụ: trong cài đặt oracle, Claude2 và SWE-Llama13b hoạt động tương đương nhau, với mỗi mô hình lần lượt giải quyết được 110 và 91 trường hợp.

Độ khó liên quan đến độ 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 tạo một hàm duy nhất tại một thời điểm và cung cấp ngữ cảnh hạn chế để định hình vấn đề.

Như trong hình, có thể thấy rằng khi tổng chiều dài của bối cảnh tăng lên thì hiệu suất của Claude2 sẽ giảm đáng kể. Tình trạng này cũng có thể được quan sát thấy ở 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 tỷ lệ thu hồi so với các tệp Oracle, hiệu suất vẫn sẽ giảm do mô hình đơn giản là không thể xác định được mã có vấn đề trong kho từ vựng rộng lớn.


Khó khăn không liên quan đến ngày giải quyết vấn đề.

Trong Bảng 7, kết quả mô hình theo ngày được hiển thị 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 kiểu máy, ngoại trừ GPT-4, không có nhiều 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 cũng cho thấy mô hình tinh chỉ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 các bản vá dễ dàng hơn 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 thể thay thế 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ó tầm nhìn và hy vọng vào tương lai của "mô hình tổng quát".

Vâng, đây cũng là trải nghiệm của tôi. Mô hình tổng quát không đủ tốt và không 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, các LLM tổng quát được đào tạo cụ thể sẽ trở thành những mô hình rất chuyên biệt.


Mặc dù các mô hình lớn không thể thay thế người lập trình nhưng chúng có thể tăng tốc quy trình làm việc của họ. Một đội trước đây cần 10 người giờ 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 mà công ty có trong đầu.

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 độ đáng kinh ngạc!


Tham khảo:

https ://www.reddit.com/r/MachineLearning/comments/1795iiz/can_ai_replace_developers_p rinceton_and/

https://twitter.com/_carlosejimenez/status/1711 714120175681552

https://www.swebench.com/

https://futurism.com/the-byte/stack-overflow-layoffs-ai

https://arstechnica.com/gadgets/2023 /10/after-chatgpt-disruption-stack-overflow-lays-off-28-percent-of-staff/?comments=1&comments-page=1