Model besar tidak bisa menjadi petani kode! Penemuan mengejutkan Princeton: GPT-4 memiliki tingkat keberhasilan 0 dalam memecahkan masalah pemrograman GitHub
alat pengkodean AI seperti ChatGPT mengancam, dan Stack Overflow memberhentikan lagi! Namun, Princeton dan Chicago menemukan bahwa GPT-4 memiliki tingkat resolusi 0% untuk masalah GitHub dunia nyata.
Stack Overflow, sudah dibuat oleh ChatGPT!
Karena pembuat kode berbondong-bondong ke ChatGPT dan Github Copilot, Stack Overflow harus mengumumkan PHK lebih dari 100 karyawan hari ini, terhitung hampir 1/3 dari jumlah karyawan.
Jadi, alat pengkodean AI seperti ChatGPT benar-benar akan menumbangkan seluruh industri?
Tetapi sebuah studi baru-baru ini oleh Princeton dan Chicago menemukan bahwa LLM tidak begitu mudah dilakukan sebagai petani kode.
Alamat kertas:
Dalam menghadapi 2294 masalah GitHub nyata, tingkat kelulusan GPT-4 yang memecahkan masalah GitHub acak ternyata 0%!
Bahkan model terbaik, Claude 2, hanya menyelesaikan 1,96% dari mereka.
Bisakah pembuat kode kehilangan pekerjaan karena ChatGPT? Jawabannya adalah – sama sekali tidak saat ini.
Beradaptasi atau binasa
Sebagai situs bantuan kode favorit setiap pengembang di dunia, Stack Overflow telah melakukannya dengan baik sebelumnya, memicu perekrutan tahun lalu, menggandakan tenaga kerja perusahaan menjadi 540.
Namun, semuanya telah berubah sejak OpenAI merilis ChatGPT November lalu.
Bantuan yang diberikan oleh chatbots AI lebih spesifik daripada posting forum 5 tahun yang lalu. Dengan LLM, pengembang dapat langsung memperbaiki kode yang tepat, saran pengoptimalan, dan deskripsi tentang apa yang dilakukan setiap baris kode.
Meskipun LLM tidak memberikan jawaban yang 100% andal, kemampuan unik untuk memvalidasi kode segera hanya dengan mengujinya di lingkungan pengembangan terintegrasi IDE menjadikan penulisan kode sebagai kasus penggunaan yang ideal untuk ChatGPT.
Akibatnya, lalu lintas Stack Overflow telah sangat berkurang, dan alat pemrograman AI seperti ChatGPT dan Github Copilot bertenaga GPT-4 telah menjadi tempat baru bagi petani kode.
Hari ini, CEO Prashanth Chandrasekar mengumumkan bahwa Stack Overflow telah memberhentikan lebih dari seratus karyawan, atau 28% dari tenaga kerjanya.
Penjelasan CEO untuk PHK adalah bahwa Stack Overflow sedang mencoba untuk mendapatkan jalan menuju profitabilitas di bawah tekanan ekonomi makro, dan terus memperkenalkan inovasi produk.
** Menyeberangi sungai dan merobohkan jembatan? **
Ironi terbesar dari dampak ChatGPT pada Stack Overflow adalah bahwa kekuatan model bahasa besar sebagian besar berasal dari situs pengikisan seperti Stack Overflow.
Apa yang terjadi jika model bahasa besar mengosongkan data ini tanpa mengembalikan apa pun, dan jika semua sumber data dipaksa keluar dari bisnis?
Sekarang, banyak perusahaan teknologi sudah memiliki masalah yang menjulang: jika ada lebih sedikit programmer, akan ada lebih sedikit data buatan.
Bagaimana Anda melatih model AI baru tanpa data terbaru?
Ingin menggunakan data kami? Ambil uangnya**
Stack Overflow, tentu saja, tidak bisa duduk diam, ia memilih dua cara untuk menyelamatkan dirinya sendiri -
Salah satunya adalah mengembangkan alat pengkodean AI sendiri, OverflowAI, dan yang lainnya adalah mencari kemitraan langsung dengan perusahaan teknologi seperti OpenAI, yang menggunakan data Stack Overflow untuk membangun model AI.
OpenAI sedang mengembangkan kontrol perayap web untuk ChatGPT sehingga data dari situs seperti Stack Overflow tidak dapat dirayapi.
CEO mengatakan Stack Overflow telah membuat pendiriannya: siapa pun yang ingin menggunakan data kami untuk melatih LLM membayar.
CEO percaya bahwa situs seperti Stack Overflow sangat penting untuk pengembangan model bahasa besar, dan untuk maju, mereka perlu dilatih tentang pengetahuan baru.
Prashanth Chandrasekar, CEO of Stack Overflow
LLM ingin mendapatkan petani kode, ini masih pagi
Jadi, bisakah model bahasa besar benar-benar mengambil petani kode?
Tim Princeton dan Chicago menemukan bahwa itu tidak mudah!
Dalam makalah terbaru, para peneliti mengusulkan kerangka kerja baru, SWE-bench, untuk menilai kemampuan model besar untuk memecahkan 2294 masalah dunia nyata di GitHub.
Ditemukan bahwa model besar terkemuka seperti GPT-4 dan Claude 2 memiliki kemampuan kurang dari 5% untuk memecahkan masalah nyata.
Untuk lebih spesifik, GPT-4 dapat menyelesaikan masalah GitHub acak dengan tingkat kelulusan 0%, sedangkan model terbaik, Claude 2, hanya dapat menyelesaikan 1,96% dari mereka.
Terlebih lagi, ketika menggunakan BM-25 untuk mengambil file kode yang relevan untuk setiap masalah, hanya 23% dari tambalan yang ditulis oleh Claude 2 yang valid (siap repo), dan hanya ~ 1% yang benar-benar menyelesaikan masalah.
Selain itu, kinerja model yang berbeda dalam memecahkan masalah dengan 12 pustaka Python populer juga bervariasi.
Model GPT-4 telah mencapai hasil seperti itu, yang benar-benar mengejutkan, lagipula, banyak orang telah lama menganggapnya sebagai "senjata pemrograman".
Tetapi untuk melihat dengan jelas, kekuatan sebenarnya dari AI, jangan mencetak gol dan khawatir.
Beberapa netizen mengatakan bahwa ini adalah jawaban terbaik untuk pertanyaan "apakah petani kode menganggur karena pemrograman".
Akhirnya seseorang membuat dataset nyata untuk model kode, dan Hum hanyalah wawancara leetcode LLM. Kita semua tahu bahwa ini adalah ukuran yang salah untuk insinyur manusia. Kurang dari 4% terdengar benar, karena model besar masih jauh dari otonom sepenuhnya.
Jadi, apakah ini benar-benar terjadi dengan hasil SWE-bench dalam mengevaluasi kemampuan model besar?
SWE-bench: Dirancang untuk model pengkodean
Dalam studi ini, penulis menemukan bahwa banyak tolok ukur saat ini untuk mengukur kemampuan pengkodean model besar telah menjadi jenuh dan tidak dapat mengukur kekuatan sebenarnya dari model besar.
Misalnya, di Manusia, masalah tantangan terlalu sederhana, dan LLM hanya membutuhkan beberapa baris kode untuk menyelesaikan masalah yang berdiri sendiri.
Namun, rekayasa perangkat lunak tidak sesederhana itu dalam kenyataannya.
Memperbaiki bug mungkin memerlukan penjelajahan perpustakaan sumber daya yang sangat besar, memahami hubungan antara fungsi dalam file yang berbeda, atau menemukan bug kecil dalam kode yang rumit.
Terinspirasi oleh ini, para peneliti dari Princeton dan Chicago memperkenalkan SWE-bench.
SWE-bench mendapatkan instance tugas dari repositori Python nyata dengan menghubungkan masalah GitHub dan menggabungkan solusi permintaan untuk menyelesaikan pengujian terkait.
Seperti yang ditunjukkan pada gambar, tugas model, biasanya laporan bug atau permintaan fitur, adalah menyelesaikan masalah yang dilakukan ke repositori GitHub.
Setiap tugas memerlukan pembuatan patch dan menjelaskan perubahan yang akan diterapkan ke basis kode yang ada.
Kemudian gunakan kerangka kerja pengujian repositori SWE-bench untuk mengevaluasi basis kode yang dimodifikasi.
Untuk menemukan contoh berkualitas tinggi dari tugas berskala besar, para peneliti melalui tiga tahap penyaringan:
**Tahap 1: Pemilihan gudang dan pencarian data. **
Permintaan tarik (PR) pertama kali dikumpulkan dari 12 repositori Python open-source populer di GitHub, menghasilkan total sekitar 90.000 PR.
Para peneliti berfokus pada repositori populer karena mereka cenderung lebih terpelihara, memiliki pedoman kontributor yang jelas, dan memiliki cakupan tes yang lebih baik. Setiap PR memiliki basis kode terkait, yaitu keadaan repositori sebelum PR digabungkan.
**Fase 2: Pemfilteran berbasis atribut. **
Tugas kandidat dibuat dengan memilih PR gabungan yang memenuhi kriteria berikut: (1) memecahkan masalah GitHub; (2) Memodifikasi file uji repositori, yang menunjukkan bahwa pengguna kemungkinan besar berkontribusi tes untuk memeriksa apakah masalah telah teratasi.
**Fase 3: Pemfilteran berbasis eksekusi. **
Untuk setiap tugas kandidat, konten uji PR diterapkan, dan hasil tes yang relevan sebelum dan sesudah konten PR lainnya diterapkan.
Peneliti menyaring contoh tugas yang tidak memiliki setidaknya satu tes, dan status tes ini berubah dari gagal lulus (selanjutnya disebut sebagai "gagal lulus tes"). Selain itu, contoh yang menyebabkan kesalahan instalasi atau operasi disaring.
Melalui tahap-tahap penyaringan ini, 90.000 PR asli disaring menjadi 2.294 contoh tugas, yang membentuk bangku SWE.
Klasifikasi akhir dari instance tugas ini di repositori yang berbeda ditunjukkan pada Gambar 3 di bawah ini, dengan tabel menjadi fitur utama instance tugas SWE-bench.
Para peneliti menekankan bahwa basis kode ini besar, berisi ribuan file, dan bahwa permintaan tarik referensi sering memodifikasi banyak file secara bersamaan.
SWE-bench menawarkan beberapa keunggulan dibandingkan tolok ukur pemrograman LM yang ada.
Ini termasuk pengaturan dunia nyata dengan masalah dan solusi yang dikirimkan pengguna, beragam masukan yang menampilkan pertanyaan kode unik dari 12 repositori, kerangka evaluasi berbasis eksekusi yang kuat, dan kemampuan untuk terus memperbarui tolok ukur dengan instans baru dengan intervensi manusia minimal.
Tugas LLM: Edit Basis Kode, Selesaikan Masalah
Peneliti akan memberikan model besar deskripsi tekstual masalah, serta basis kode lengkap.
Tugas model besar adalah mengedit basis kode untuk menyelesaikan masalah.
Dalam praktiknya, peneliti mewakili perubahan sebagai file tambalan, yang menentukan baris mana dalam basis kode yang akan dimodifikasi untuk memecahkan masalah.
Bagaimana cara mengevaluasi apakah solusi yang diberikan oleh LLM baik atau tidak?
Para peneliti menggunakan patch Unix, menerapkan patch yang dihasilkan ke basis kode, dan kemudian melakukan tes unit dan sistem yang terkait dengan instance tugas.
Jika patch berhasil diterapkan, dan semua tes ini lulus, skema yang direkomendasikan oleh LLM dapat dianggap telah berhasil menyelesaikan masalah.
Metrik garis dasar, yang merupakan persentase instans tugas yang diselesaikan.
Membangun dataset unik untuk SWE-bench
Tolok ukur NLP tradisional biasanya hanya melibatkan urutan input dan output pendek dan mempertimbangkan beberapa masalah "buatan" yang dibuat khusus untuk tolok ukur.
Sebaliknya, untuk membangun bangku SWE, para peneliti menyuntikkan sifat unik ke dalam dataset.
Misalnya, tugas rekayasa perangkat lunak nyata digunakan.
Karena setiap contoh tugas di SWE-bench berisi basis kode yang besar dan kompleks dan deskripsi masalah terkait, memecahkan SWE-bench memerlukan keterampilan dan pengetahuan kompleks dari insinyur perangkat lunak berpengalaman, yang sering tidak dievaluasi dalam tolok ukur pembuatan kode tradisional.
Terlebih lagi, proses pengumpulan dapat dengan mudah diterapkan ke repositori Python apa pun di GitHub dengan sedikit atau tanpa campur tangan manusia.
Akibatnya, peneliti dapat memperluas bangku SWE dengan menyediakan contoh tugas baru dan mengevaluasi model bahasa untuk masalah yang dibuat setelah tanggal pelatihan, memastikan bahwa korpus pelatihan tidak mengandung solusi.
Selain itu, para peneliti menjamin input panjang yang berbeda dalam tolok ukur, evaluasi yang kuat, pengeditan kode lintas konteks, berbagai solusi, dll.
** Fine-tuning SWE-Llama **
Selanjutnya, saatnya untuk mengevaluasi efektivitas model terbuka dan eksklusif dalam kerangka SWE-bench.
Namun, para peneliti menemukan bahwa model fine-tuning CodeLlama off-the-shelf tidak dapat mengikuti instruksi terperinci untuk menghasilkan pengeditan kode di seluruh perpustakaan, seringkali mengeluarkan respons placeholder atau kode yang tidak relevan.
Untuk menilai kemampuan model-model ini, para peneliti melakukan supervised fine-tuning (SFT) pada model CodeLlama-Python 7 miliar parameter dan model CodeLlama-Python parameter 13 miliar.
Model yang dihasilkan adalah editor repositori khusus yang berjalan pada perangkat keras tingkat konsumen dan memecahkan masalah GitHub.
### Model besar gagal
Selanjutnya, para peneliti mengevaluasi GPT-3.5, GPT-4, Cluade 2, dan model yang disetel dengan baik.
Ternyata semua model gagal - tidak satupun dari mereka menyelesaikan semua kecuali masalah yang paling sederhana.
Misalnya, Claude 2 dan GPT-4 masing-masing hanya dapat menyelesaikan 4,8% dan 1,7% tugas.
Setelah menggunakan BM25 retriever, performa Claude 2 turun lebih jauh menjadi 1,96%.
** Perpustakaan yang berbeda memiliki tingkat kesulitan yang berbeda. **
Jika Anda memecah performa berdasarkan repositori, Anda akan melihat bahwa semua model menunjukkan tren serupa di seluruh pustaka.
Namun, masalah yang ditangani oleh masing-masing model tidak selalu tumpang tindih secara luas. Misalnya, dalam pengaturan oracle, Claude 2 dan SWE-Llama 13b berkinerja sebanding, masing-masing menyelesaikan 110 dan 91 instans per model.
**Kesulitan tergantung pada panjang konteks. **
Model dapat dilatih sebelumnya pada urutan kode yang panjang, tetapi biasanya memerlukan satu fungsi untuk dihasilkan pada satu waktu dan menyediakan kerangka kerja dengan konteks terbatas untuk menentukan masalah.
Seperti yang ditunjukkan, Anda dapat melihat bahwa kinerja Claude 2 menurun secara signifikan seiring dengan meningkatnya panjang total konteks, yang juga dapat diamati pada model lain.
Bahkan jika meningkatkan ukuran konteks maksimum BM25 akan meningkatkan penarikan relatif terhadap file Oracle, kinerja masih akan menurun karena model tidak dapat menemukan kode yang bermasalah dalam tesaurus yang luas.
**Tingkat kesulitan tidak tergantung pada tanggal penyelesaian masalah. **
Tabel 7 menunjukkan hasil model berdasarkan tanggal untuk PR yang dibuat sebelum atau setelah 2023 di bawah pengaturan pencarian "oracle".
Untuk sebagian besar model, dengan pengecualian GPT-4, ada sedikit perbedaan dalam kinerja sebelum atau sesudah tanggal ini.
Selain itu, penelitian ini menemukan bahwa fine-tuning model sensitif terhadap perubahan dalam distribusi konteks, dan lebih mudah untuk menghasilkan patch daripada menghasilkan seluruh file. Dan model besar cenderung menghasilkan pengeditan yang lebih pendek dan sederhana.
LLM bukan pengganti programmer, tetapi dapat mempercepat alur kerja
Beberapa netizen memiliki harapan dan harapan untuk masa depan "model generalis".
Itu benar, itulah yang saya katakan. Model generalis tidak cukup baik untuk memiliki panjang konteks yang cukup lebar untuk kode sendiri, kecuali untuk cuplikan kode yang relatif pendek.
Tapi saya pikir ini hanya masalah waktu. Saya dapat meramalkan bahwa dalam waktu dekat, LLM generalis dengan pelatihan khusus akan menjadi model yang sangat profesional.
Sementara model besar bukan pengganti programmer, mereka dapat mempercepat alur kerja mereka. Apa yang dulu mengambil tim yang terdiri dari 10 orang sekarang mungkin hanya membutuhkan 4 orang. Ini membebaskan sumber daya untuk tujuan lain yang disiapkan oleh perusahaan.
Alih-alih memberhentikan karyawan untuk menghemat uang, biarkan pengembang mencapai hal-hal hebat dengan kecepatan sangat tinggi!
Sumber daya:
Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Model besar tidak bisa menjadi petani kode! Penemuan mengejutkan Princeton: GPT-4 memiliki tingkat keberhasilan 0 dalam memecahkan masalah pemrograman GitHub
Sumber artikel: Shin Ji Yuan
Stack Overflow, sudah dibuat oleh ChatGPT!
Karena pembuat kode berbondong-bondong ke ChatGPT dan Github Copilot, Stack Overflow harus mengumumkan PHK lebih dari 100 karyawan hari ini, terhitung hampir 1/3 dari jumlah karyawan.
Tetapi sebuah studi baru-baru ini oleh Princeton dan Chicago menemukan bahwa LLM tidak begitu mudah dilakukan sebagai petani kode.
Dalam menghadapi 2294 masalah GitHub nyata, tingkat kelulusan GPT-4 yang memecahkan masalah GitHub acak ternyata 0%!
Bahkan model terbaik, Claude 2, hanya menyelesaikan 1,96% dari mereka.
Beradaptasi atau binasa
Sebagai situs bantuan kode favorit setiap pengembang di dunia, Stack Overflow telah melakukannya dengan baik sebelumnya, memicu perekrutan tahun lalu, menggandakan tenaga kerja perusahaan menjadi 540.
Namun, semuanya telah berubah sejak OpenAI merilis ChatGPT November lalu.
Meskipun LLM tidak memberikan jawaban yang 100% andal, kemampuan unik untuk memvalidasi kode segera hanya dengan mengujinya di lingkungan pengembangan terintegrasi IDE menjadikan penulisan kode sebagai kasus penggunaan yang ideal untuk ChatGPT.
Akibatnya, lalu lintas Stack Overflow telah sangat berkurang, dan alat pemrograman AI seperti ChatGPT dan Github Copilot bertenaga GPT-4 telah menjadi tempat baru bagi petani kode.
Hari ini, CEO Prashanth Chandrasekar mengumumkan bahwa Stack Overflow telah memberhentikan lebih dari seratus karyawan, atau 28% dari tenaga kerjanya.
** Menyeberangi sungai dan merobohkan jembatan? **
Ironi terbesar dari dampak ChatGPT pada Stack Overflow adalah bahwa kekuatan model bahasa besar sebagian besar berasal dari situs pengikisan seperti Stack Overflow.
Apa yang terjadi jika model bahasa besar mengosongkan data ini tanpa mengembalikan apa pun, dan jika semua sumber data dipaksa keluar dari bisnis?
Sekarang, banyak perusahaan teknologi sudah memiliki masalah yang menjulang: jika ada lebih sedikit programmer, akan ada lebih sedikit data buatan.
Bagaimana Anda melatih model AI baru tanpa data terbaru?
Ingin menggunakan data kami? Ambil uangnya**
Stack Overflow, tentu saja, tidak bisa duduk diam, ia memilih dua cara untuk menyelamatkan dirinya sendiri -
Salah satunya adalah mengembangkan alat pengkodean AI sendiri, OverflowAI, dan yang lainnya adalah mencari kemitraan langsung dengan perusahaan teknologi seperti OpenAI, yang menggunakan data Stack Overflow untuk membangun model AI.
CEO mengatakan Stack Overflow telah membuat pendiriannya: siapa pun yang ingin menggunakan data kami untuk melatih LLM membayar.
CEO percaya bahwa situs seperti Stack Overflow sangat penting untuk pengembangan model bahasa besar, dan untuk maju, mereka perlu dilatih tentang pengetahuan baru.
LLM ingin mendapatkan petani kode, ini masih pagi
Jadi, bisakah model bahasa besar benar-benar mengambil petani kode?
Tim Princeton dan Chicago menemukan bahwa itu tidak mudah!
Ditemukan bahwa model besar terkemuka seperti GPT-4 dan Claude 2 memiliki kemampuan kurang dari 5% untuk memecahkan masalah nyata.
Untuk lebih spesifik, GPT-4 dapat menyelesaikan masalah GitHub acak dengan tingkat kelulusan 0%, sedangkan model terbaik, Claude 2, hanya dapat menyelesaikan 1,96% dari mereka.
Selain itu, kinerja model yang berbeda dalam memecahkan masalah dengan 12 pustaka Python populer juga bervariasi.
Tetapi untuk melihat dengan jelas, kekuatan sebenarnya dari AI, jangan mencetak gol dan khawatir.
SWE-bench: Dirancang untuk model pengkodean
Dalam studi ini, penulis menemukan bahwa banyak tolok ukur saat ini untuk mengukur kemampuan pengkodean model besar telah menjadi jenuh dan tidak dapat mengukur kekuatan sebenarnya dari model besar.
Misalnya, di Manusia, masalah tantangan terlalu sederhana, dan LLM hanya membutuhkan beberapa baris kode untuk menyelesaikan masalah yang berdiri sendiri.
Namun, rekayasa perangkat lunak tidak sesederhana itu dalam kenyataannya.
Terinspirasi oleh ini, para peneliti dari Princeton dan Chicago memperkenalkan SWE-bench.
SWE-bench mendapatkan instance tugas dari repositori Python nyata dengan menghubungkan masalah GitHub dan menggabungkan solusi permintaan untuk menyelesaikan pengujian terkait.
Seperti yang ditunjukkan pada gambar, tugas model, biasanya laporan bug atau permintaan fitur, adalah menyelesaikan masalah yang dilakukan ke repositori GitHub.
Setiap tugas memerlukan pembuatan patch dan menjelaskan perubahan yang akan diterapkan ke basis kode yang ada.
Kemudian gunakan kerangka kerja pengujian repositori SWE-bench untuk mengevaluasi basis kode yang dimodifikasi.
Permintaan tarik (PR) pertama kali dikumpulkan dari 12 repositori Python open-source populer di GitHub, menghasilkan total sekitar 90.000 PR.
Para peneliti berfokus pada repositori populer karena mereka cenderung lebih terpelihara, memiliki pedoman kontributor yang jelas, dan memiliki cakupan tes yang lebih baik. Setiap PR memiliki basis kode terkait, yaitu keadaan repositori sebelum PR digabungkan.
**Fase 2: Pemfilteran berbasis atribut. **
Tugas kandidat dibuat dengan memilih PR gabungan yang memenuhi kriteria berikut: (1) memecahkan masalah GitHub; (2) Memodifikasi file uji repositori, yang menunjukkan bahwa pengguna kemungkinan besar berkontribusi tes untuk memeriksa apakah masalah telah teratasi.
**Fase 3: Pemfilteran berbasis eksekusi. **
Untuk setiap tugas kandidat, konten uji PR diterapkan, dan hasil tes yang relevan sebelum dan sesudah konten PR lainnya diterapkan.
Peneliti menyaring contoh tugas yang tidak memiliki setidaknya satu tes, dan status tes ini berubah dari gagal lulus (selanjutnya disebut sebagai "gagal lulus tes"). Selain itu, contoh yang menyebabkan kesalahan instalasi atau operasi disaring.
Melalui tahap-tahap penyaringan ini, 90.000 PR asli disaring menjadi 2.294 contoh tugas, yang membentuk bangku SWE.
Klasifikasi akhir dari instance tugas ini di repositori yang berbeda ditunjukkan pada Gambar 3 di bawah ini, dengan tabel menjadi fitur utama instance tugas SWE-bench.
Para peneliti menekankan bahwa basis kode ini besar, berisi ribuan file, dan bahwa permintaan tarik referensi sering memodifikasi banyak file secara bersamaan.
SWE-bench menawarkan beberapa keunggulan dibandingkan tolok ukur pemrograman LM yang ada.
Ini termasuk pengaturan dunia nyata dengan masalah dan solusi yang dikirimkan pengguna, beragam masukan yang menampilkan pertanyaan kode unik dari 12 repositori, kerangka evaluasi berbasis eksekusi yang kuat, dan kemampuan untuk terus memperbarui tolok ukur dengan instans baru dengan intervensi manusia minimal.
Tugas LLM: Edit Basis Kode, Selesaikan Masalah
Peneliti akan memberikan model besar deskripsi tekstual masalah, serta basis kode lengkap.
Tugas model besar adalah mengedit basis kode untuk menyelesaikan masalah.
Dalam praktiknya, peneliti mewakili perubahan sebagai file tambalan, yang menentukan baris mana dalam basis kode yang akan dimodifikasi untuk memecahkan masalah.
Para peneliti menggunakan patch Unix, menerapkan patch yang dihasilkan ke basis kode, dan kemudian melakukan tes unit dan sistem yang terkait dengan instance tugas.
Metrik garis dasar, yang merupakan persentase instans tugas yang diselesaikan.
Membangun dataset unik untuk SWE-bench
Tolok ukur NLP tradisional biasanya hanya melibatkan urutan input dan output pendek dan mempertimbangkan beberapa masalah "buatan" yang dibuat khusus untuk tolok ukur.
Sebaliknya, untuk membangun bangku SWE, para peneliti menyuntikkan sifat unik ke dalam dataset.
Misalnya, tugas rekayasa perangkat lunak nyata digunakan.
Terlebih lagi, proses pengumpulan dapat dengan mudah diterapkan ke repositori Python apa pun di GitHub dengan sedikit atau tanpa campur tangan manusia.
Akibatnya, peneliti dapat memperluas bangku SWE dengan menyediakan contoh tugas baru dan mengevaluasi model bahasa untuk masalah yang dibuat setelah tanggal pelatihan, memastikan bahwa korpus pelatihan tidak mengandung solusi.
Selain itu, para peneliti menjamin input panjang yang berbeda dalam tolok ukur, evaluasi yang kuat, pengeditan kode lintas konteks, berbagai solusi, dll.
** Fine-tuning SWE-Llama **
Selanjutnya, saatnya untuk mengevaluasi efektivitas model terbuka dan eksklusif dalam kerangka SWE-bench.
Namun, para peneliti menemukan bahwa model fine-tuning CodeLlama off-the-shelf tidak dapat mengikuti instruksi terperinci untuk menghasilkan pengeditan kode di seluruh perpustakaan, seringkali mengeluarkan respons placeholder atau kode yang tidak relevan.
Untuk menilai kemampuan model-model ini, para peneliti melakukan supervised fine-tuning (SFT) pada model CodeLlama-Python 7 miliar parameter dan model CodeLlama-Python parameter 13 miliar.
Model yang dihasilkan adalah editor repositori khusus yang berjalan pada perangkat keras tingkat konsumen dan memecahkan masalah GitHub.
Selanjutnya, para peneliti mengevaluasi GPT-3.5, GPT-4, Cluade 2, dan model yang disetel dengan baik.
Ternyata semua model gagal - tidak satupun dari mereka menyelesaikan semua kecuali masalah yang paling sederhana.
Misalnya, Claude 2 dan GPT-4 masing-masing hanya dapat menyelesaikan 4,8% dan 1,7% tugas.
Setelah menggunakan BM25 retriever, performa Claude 2 turun lebih jauh menjadi 1,96%.
** Perpustakaan yang berbeda memiliki tingkat kesulitan yang berbeda. **
Jika Anda memecah performa berdasarkan repositori, Anda akan melihat bahwa semua model menunjukkan tren serupa di seluruh pustaka.
Namun, masalah yang ditangani oleh masing-masing model tidak selalu tumpang tindih secara luas. Misalnya, dalam pengaturan oracle, Claude 2 dan SWE-Llama 13b berkinerja sebanding, masing-masing menyelesaikan 110 dan 91 instans per model.
**Kesulitan tergantung pada panjang konteks. **
Model dapat dilatih sebelumnya pada urutan kode yang panjang, tetapi biasanya memerlukan satu fungsi untuk dihasilkan pada satu waktu dan menyediakan kerangka kerja dengan konteks terbatas untuk menentukan masalah.
Seperti yang ditunjukkan, Anda dapat melihat bahwa kinerja Claude 2 menurun secara signifikan seiring dengan meningkatnya panjang total konteks, yang juga dapat diamati pada model lain.
Bahkan jika meningkatkan ukuran konteks maksimum BM25 akan meningkatkan penarikan relatif terhadap file Oracle, kinerja masih akan menurun karena model tidak dapat menemukan kode yang bermasalah dalam tesaurus yang luas.
Tabel 7 menunjukkan hasil model berdasarkan tanggal untuk PR yang dibuat sebelum atau setelah 2023 di bawah pengaturan pencarian "oracle".
Untuk sebagian besar model, dengan pengecualian GPT-4, ada sedikit perbedaan dalam kinerja sebelum atau sesudah tanggal ini.
LLM bukan pengganti programmer, tetapi dapat mempercepat alur kerja
Beberapa netizen memiliki harapan dan harapan untuk masa depan "model generalis".
Itu benar, itulah yang saya katakan. Model generalis tidak cukup baik untuk memiliki panjang konteks yang cukup lebar untuk kode sendiri, kecuali untuk cuplikan kode yang relatif pendek.
Tapi saya pikir ini hanya masalah waktu. Saya dapat meramalkan bahwa dalam waktu dekat, LLM generalis dengan pelatihan khusus akan menjadi model yang sangat profesional.
Alih-alih memberhentikan karyawan untuk menghemat uang, biarkan pengembang mencapai hal-hal hebat dengan kecepatan sangat tinggi!