ChatGPT gibi > yapay zeka kodlama araçları tehditkar ve Stack Overflow tekrar işten çıkarılıyor! Ancak Princeton ve Chicago, GPT-4'ün gerçek dünyadaki GitHub sorunları için %0 çözünürlük oranına sahip olduğunu buldu.
Stack Overflow, ChatGPT tarafından zaten oluşturuldu!
Kodlayıcılar ChatGPT ve Github Copilot'a akın ettiğinden, Stack Overflow bugün 100'den fazla çalışanın işten çıkarıldığını duyurmak zorunda kaldı ve bu da çalışan sayısının neredeyse 1/3'ünü oluşturuyor.
Peki, ChatGPT gibi yapay zeka kodlama araçları gerçekten tüm sektörü alt üst edecek mi?
Ancak Princeton ve Chicago tarafından yakın zamanda yapılan bir araştırma, LLM'nin bir kod çiftçisi olarak yapılmasının o kadar kolay olmadığını buldu.
Bildiri Adresi:
2294 gerçek GitHub problemi karşısında, rastgele GitHub problemlerini çözen GPT-4'ün geçme oranı %0 çıktı!
En iyi model olan Claude 2 bile bunların sadece %1.96'sını çözüyor.
Kodlayıcılar ChatGPT yüzünden işlerini kaybedebilir mi? Cevap - şu anda kesinlikle değil.
Uyum sağla ya da yok ol
Dünyadaki her geliştiricinin en sevdiği kod destekli site olan Stack Overflow, geçen yıl bir işe alım çılgınlığı başlatarak şirketin işgücünü ikiye katlayarak 540'a çıkardı.
Ancak, OpenAI'nin geçen Kasım ayında ChatGPT'yi piyasaya sürmesinden bu yana her şey değişti.
AI sohbet robotları tarafından sağlanan yardım, 5 yıl önceki forum gönderisinden daha spesifiktir. LLM ile geliştiriciler, tam kodu, optimizasyon önerilerini ve her bir kod satırının ne yaptığının açıklamasını anında düzeltebilir.
LLM %100 güvenilir yanıtlar sağlamasa da, kodu IDE entegre geliştirme ortamında test ederek hemen doğrulama konusundaki benzersiz yetenek, kod yazmayı ChatGPT için ideal bir kullanım durumu haline getirir.
Sonuç olarak, Stack Overflow'un trafiği büyük ölçüde azaldı ve ChatGPT ve GPT-4 destekli Github Copilot gibi yapay zeka programlama araçları, kod çiftçileri için yeni yerler haline geldi.
Bugün CEO Prashanth Chandrasekar, Stack Overflow'un yüzden fazla çalışanını veya işgücünün %28'ini işten çıkardığını duyurdu.
CEO'nun işten çıkarmalarla ilgili açıklaması, Stack Overflow'un makroekonomik baskı altında kârlılığa giden yolda ilerlemeye çalıştığı ve ürün yenilikleri sunmaya devam ettiği yönünde.
** Nehri geçip köprüyü yıkmak mı? **
ChatGPT'nin Stack Overflow üzerindeki etkisinin en büyük ironisi, büyük dil modelinin gücünün büyük ölçüde Stack Overflow gibi kazıma sitelerinden gelmesidir.
Büyük dil modelleri hiçbir şey vermeden bu verileri boşaltırsa ve tüm veri kaynakları işten çıkarılırsa ne olur?
Şimdi, birçok teknoloji şirketinin zaten baş gösteren bir sorunu var: daha az programcı varsa, daha az yapay veri olacaktır.
Güncel veriler olmadan yeni yapay zeka modellerini nasıl eğitirsiniz?
Verilerimizi kullanmak ister misiniz? Parayı al**
Stack Overflow elbette yerinde duramıyor, kendini kurtarmak için iki yol seçti -
Biri kendi yapay zeka kodlama aracı OverflowAI'yi geliştirmek, diğeri ise yapay zeka modelleri oluşturmak için Stack Overflow'un verilerini kullanan OpenAI gibi teknoloji şirketleriyle doğrudan ortaklıklar aramak.
OpenAI, Stack Overflow gibi sitelerden gelen verilerin taranamaması için ChatGPT için web tarayıcısı kontrolleri geliştiriyor.
CEO, Stack Overflow'un duruşunu belirlediğini söyledi: LLM'yi eğitmek için verilerimizi kullanmak isteyen herkes öder.
CEO'lar, Stack Overflow gibi sitelerin büyük dil modellerinin geliştirilmesi için kritik öneme sahip olduğuna ve ilerlemek için yeni bilgiler konusunda eğitilmeleri gerektiğine inanıyor.
Prashanth Chandrasekar, Stack Overflow CEO'su
LLM çiftçi kodunu almak istiyor, hala erken
Peki, büyük dil modelleri gerçekten kod çiftçilerini alabilir mi?
Princeton ve Chicago ekipleri bunun o kadar kolay olmadığını gördü!
En son makalede, araştırmacılar, büyük modellerin GitHub'daki 2294 gerçek dünya problemini çözme yeteneğini değerlendirmek için yeni bir çerçeve olan SWE-bench'i öneriyorlar.
GPT-4 ve Claude 2 gibi önde gelen büyük modellerin gerçek sorunları çözme yeteneğinin %5'ten daha az olduğu bulundu.
Daha spesifik olmak gerekirse, GPT-4 rastgele GitHub sorunlarını %0'lık bir geçiş oranıyla çözebilirken, en iyi model olan Claude 2 bunların yalnızca %1.96'sını çözebilir.
Dahası, her sorun için ilgili kod dosyalarını almak için BM-25'i kullanırken, Claude 2 tarafından yazılan yamaların yalnızca %23'ü geçerliydi (depoya hazır) ve yalnızca ~%1'i sorunu gerçekten çözdü.
Ayrıca 12 popüler Python kütüphanesi ile farklı modellerin problem çözme performansı da değişkenlik göstermektedir.
GPT-4 modeli böyle bir sonuç elde etti, bu gerçekten şaşırtıcı, sonuçta birçok insan onu uzun zamandır bir "programlama silahı" olarak görüyor.
Ancak AI'nın gerçek gücünü açıkça görmek için puanlanmayın ve endişelenmeyin.
Bazı netizenler, "kod çiftçilerinin programlama nedeniyle işsiz olup olmadığı" sorusuna en iyi cevabın bu olduğunu söyledi.
Sonunda birisi kod modeli için gerçek bir veri seti yaptı ve Hum sadece LLM'nin leetcode röportajıydı. Hepimiz bunun insan mühendisler için yanlış bir önlem olduğunu biliyoruz. Büyük modeller hala tamamen özerk olmaktan uzak olduğu için %4'ten daha azı kulağa doğru geliyor.
Peki, SWE-bench'in büyük modellerin yeteneklerini değerlendirmede elde ettiği sonuçlarda durum gerçekten böyle mi?
SWE-bench: Kodlama modelleri için tasarlanmıştır
Bu çalışmada yazarlar, büyük modellerin kodlama yeteneğini ölçmek için mevcut birçok kriterin doygun hale geldiğini ve büyük modellerin gerçek gücünü ölçemediğini bulmuşlardır.
Örneğin, İnsan'da, meydan okuma problemi çok basittir ve LLM'nin tek başına bir problemi çözmek için yalnızca birkaç satır koda ihtiyacı vardır.
Ancak, yazılım mühendisliği gerçekte o kadar basit değildir.
Bir hatayı düzeltmek, büyük bir kaynak kitaplığına göz atmayı, farklı dosyalardaki işlevler arasındaki ilişkileri anlamayı veya karmaşık kodda küçük bir hata bulmayı gerektirebilir.
Bundan ilham alan Princeton ve Chicago'dan araştırmacılar SWE-bench'i tanıttı.
SWE-bench, GitHub sorunlarını bağlayarak ve ilgili testleri çözmek için istek çözümlerini birleştirerek gerçek bir Python deposundan görev örneklerini alır.
Görüntüde gösterildiği gibi, modelin görevi (genellikle bir hata raporu veya özellik isteği), GitHub deposuna işlenen bir sorunu çözmektir.
Her görev, bir yama oluşturmayı ve mevcut kod tabanına uygulanacak değişiklikleri açıklamayı gerektirir.
Ardından, değiştirilen kod tabanını değerlendirmek için deponun test çerçevesi SWE-bench'i kullanın.
Büyük ölçekli görevlerin yüksek kaliteli örneklerini bulmak için, araştırmacılar üç tarama aşamasından geçtiler:
**Aşama 1: Depo seçimi ve veri arama. **
Çekme istekleri (PR'ler) ilk olarak GitHub'daki 12 popüler açık kaynak Python deposundan toplandı ve toplamda yaklaşık 90.000 PR oluşturuldu.
Araştırmacılar, daha iyi korunma eğiliminde oldukları, açık katılımcı yönergelerine sahip oldukları ve daha iyi test kapsamına sahip oldukları için popüler depolara odaklandılar. Her PR'nin ilişkili bir kod tabanı vardır, yani PR birleştirilmeden önce deponun durumu.
**2. Aşama: Öznitelik tabanlı filtreleme. **
Aday görev, aşağıdaki ölçütleri karşılayan birleştirilmiş bir çekme isteği seçilerek oluşturulur: (1) GitHub sorununu çözer; (2) Deponun test dosyası, kullanıcının sorunun çözülüp çözülmediğini kontrol etmek için büyük olasılıkla testlere katkıda bulunduğunu gösterir.
**Aşama 3: Yürütme tabanlı filtreleme. **
Her aday görev için, PR'nin test içeriği uygulanır ve PR'nin diğer içeriğinden önceki ve sonraki ilgili test sonuçları uygulanır.
Araştırmacı, en az bir testi olmayan görevlerin örneklerini filtreler ve bu testlerin durumu başarısız olarak değişir (bundan böyle "testi geçemedi" olarak anılacaktır). Ayrıca, yükleme veya işlem hatalarına neden olan örnekler filtrelenir.
Bu tarama aşamaları boyunca, orijinal 90.000 PR, SWE tezgahını oluşturan 2.294 görev örneğinde taranır.
Bu görev örneklerinin farklı depolardaki son sınıflandırması aşağıdaki Şekil 3'te gösterilmiştir ve tablo SWE-bench görev örneklerinin ana özelliğidir.
Araştırmacılar, bu kod tabanlarının büyük olduğunu, binlerce dosya içerdiğini ve referans çekme isteklerinin genellikle aynı anda birden fazla dosyayı değiştirdiğini vurguluyor.
SWE-bench, mevcut LM programlama kıyaslamalarına göre çeşitli avantajlar sunar.
Bunlar, kullanıcı tarafından gönderilen sorunlar ve çözümler içeren gerçek dünya ayarlarını, 12 depodan benzersiz kod soruları içeren çeşitli girdileri, sağlam bir yürütme tabanlı değerlendirme çerçevesini ve minimum insan müdahalesiyle yeni örneklerle karşılaştırmaları sürekli güncelleme yeteneğini içerir.
LLM Görevi: Kod Tabanını Düzenleyin, Sorunları Çözün
Araştırmacı, büyük modele sorunun metinsel bir tanımını ve eksiksiz bir kod tabanını verecektir.
Büyük modelin görevi, sorunu çözmek için kod tabanını düzenlemektir.
Uygulamada, araştırmacılar değişiklikleri, sorunu çözmek için kod tabanındaki hangi satırların değiştirileceğini belirten yama dosyaları olarak temsil eder.
LLM tarafından verilen çözümün iyi olup olmadığı nasıl değerlendirilir?
Araştırmacılar Unix yamalarını kullanır, oluşturulan yamaları kod tabanına uygular ve ardından görev örnekleriyle ilgili birim ve sistem testleri gerçekleştirir.
Yama başarılı bir şekilde uygulanırsa ve tüm bu testler geçilirse, LLM tarafından önerilen şemanın sorunu başarıyla çözdüğü düşünülebilir.
Çözümlenen görev örneklerinin yüzdesi olan taban çizgisinin ölçümü.
SWE tezgahı için benzersiz bir veri kümesi oluşturma
Geleneksel NLP kıyaslamaları tipik olarak yalnızca kısa girdi ve çıktı dizilerini içerir ve özellikle kıyaslamalar için oluşturulmuş bazı "yapay" sorunları dikkate alır.
Buna karşılık, SWE tezgahını oluşturmak için araştırmacılar veri kümesine benzersiz özellikler enjekte ettiler.
Örneğin, gerçek yazılım mühendisliği görevleri kullanılır.
SWE-bench'teki her görev örneği, büyük ve karmaşık bir kod tabanı ve ilişkili sorunun bir tanımını içerdiğinden, SWE-bench'i çözmek, genellikle geleneksel kod oluşturma kıyaslamalarında değerlendirilmeyen deneyimli yazılım mühendislerinin karmaşık becerilerini ve bilgilerini gerektirir.
Dahası, toplama işlemi GitHub'daki herhangi bir Python deposuna çok az insan müdahalesi ile veya hiç müdahale olmadan kolayca uygulanabilir.
Sonuç olarak, araştırmacılar yeni görev örnekleri sağlayarak SWE tezgahını genişletebilir ve eğitim tarihinden sonra oluşturulan problemler için dil modelini değerlendirerek eğitim külliyatının bir çözüm içermemesini sağlayabilir.
Buna ek olarak, araştırmacılar kıyaslamada farklı uzun girdileri, sağlam değerlendirmeyi, bağlamlar arası kod düzenlemeyi, geniş çözüm yelpazesini vb. garanti eder.
SWE-Llama'ya ince ayar yapmak
Ardından, SWE-bench çerçevesindeki açık ve tescilli modellerin etkinliğini değerlendirmenin zamanı geldi.
Bununla birlikte, araştırmacılar, kullanıma hazır CodeLlama ince ayar modellerinin, kitaplık genelinde kod düzenlemeleri oluşturmak için ayrıntılı talimatları takip edemediğini, genellikle yer tutucu yanıtları veya alakasız kodlar çıkardığını buldular.
Bu modellerin yeteneklerini değerlendirmek için araştırmacılar, 7 milyar parametreli CodeLlama-Python modeli ve 13 milyar parametreli CodeLlama-Python modeli üzerinde denetimli ince ayar (SFT) gerçekleştirdiler.
Ortaya çıkan model, tüketici sınıfı donanım üzerinde çalışan ve GitHub sorunlarını çözen özel bir depo düzenleyicisidir.
### Büyük modeller başarısız olur
Daha sonra araştırmacılar GPT-3.5, GPT-4, Cluade 2 ve ince ayarlı modelleri değerlendirdi.
Tüm modellerin başarısız olduğu ortaya çıktı - hiçbiri en basit problemler dışında hepsini çözmedi.
Örneğin, Claude 2 ve GPT-4, görevlerin sırasıyla yalnızca %4,8 ve %1,7'sini çözebilir.
BM25 retriever'ı kullandıktan sonra, Claude 2'nin performansı %1.96'ya düştü.
**Farklı kütüphanelerin farklı zorluk seviyeleri vardır. **
Performansı depoya göre ayırırsanız, tüm modellerin kitaplıklar arasında benzer eğilimler sergilediğini görürsünüz.
Yine de, her modelin ele aldığı sorunların kapsamlı bir şekilde örtüşmesi gerekmez. Örneğin, bir oracle kurulumunda Claude 2 ve SWE-Llama 13b, model başına sırasıyla 110 ve 91 örneği çözerek benzer bir performans gösterir.
**Zorluk, bağlam uzunluğuna bağlıdır. **
Modeller uzun kod dizileri üzerinde önceden eğitilebilir, ancak genellikle bir kerede tek bir işlevin oluşturulmasını gerektirir ve sorunu belirlemek için sınırlı bağlam içeren bir çerçeve sağlar.
Gösterildiği gibi, Claude 2'nin performansının, bağlamın toplam uzunluğu arttıkça önemli ölçüde düştüğünü görebilirsiniz, bu da diğer modellerde de gözlemlenebilir.
BM25'in maksimum bağlam boyutunun artırılması Oracle dosyalarına göre geri çağırmayı iyileştirse bile, model sorunlu kodu geniş eş anlamlılar sözlüğünde bulamadığı için performans yine de düşecektir.
**Zorluk, sorunun çözüm tarihinden bağımsızdır. **
Tablo 7, "oracle" arama ayarları altında 2023'ten önce veya sonra oluşturulan PR'ler için tarihe göre model sonuçlarını göstermektedir.
GPT-4 hariç çoğu model için bu tarihten önce veya sonra performansta çok az fark vardır.
Buna ek olarak, çalışma, modele ince ayar yapmanın bağlam dağılımındaki değişikliklere duyarlı olduğunu ve bir yama oluşturmanın tüm bir dosyayı oluşturmaktan daha kolay olduğunu buldu. Ve büyük modeller daha kısa, daha basit düzenlemeler üretme eğilimindedir.
LLM, programcıların yerine geçmez, ancak iş akışlarını hızlandırabilir
Bazı netizenlerin "genel modelin" geleceği için umutları ve umutları var.
Doğru, ben de öyle söylüyorum. Genelci model, nispeten kısa kod parçacıkları dışında, kendi başına kodlamak için yeterince geniş bir bağlam uzunluğuna sahip olacak kadar iyi değildir.
Ama bence bu sadece bir zaman meselesi. Yakın gelecekte, özel eğitim almış genel LLM'nin çok profesyonel bir model olacağını öngörebiliyorum.
Büyük modeller programcıların yerini tutmasa da iş akışlarını hızlandırabilirler. Eskiden 10 kişilik bir ekip için kullanılan şey artık sadece 4 kişiye ihtiyaç duyabilir. Bu, şirket tarafından hazırlanan diğer hedefler için kaynakları serbest bırakır.
Paradan tasarruf etmek için çalışanları işten çıkarmak yerine, geliştiricilerin son derece hızlı bir şekilde harika şeyler başarmasına izin verin!
Kaynaklar:
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Büyük modeller kod çiftçisi olamaz! Princeton'ın şaşırtıcı keşfi: GPT-4, GitHub programlama problemlerini çözmede 0 başarı oranına sahip
Makale kaynağı: Shin Ji Yuan
ChatGPT gibi > yapay zeka kodlama araçları tehditkar ve Stack Overflow tekrar işten çıkarılıyor! Ancak Princeton ve Chicago, GPT-4'ün gerçek dünyadaki GitHub sorunları için %0 çözünürlük oranına sahip olduğunu buldu.
Stack Overflow, ChatGPT tarafından zaten oluşturuldu!
Kodlayıcılar ChatGPT ve Github Copilot'a akın ettiğinden, Stack Overflow bugün 100'den fazla çalışanın işten çıkarıldığını duyurmak zorunda kaldı ve bu da çalışan sayısının neredeyse 1/3'ünü oluşturuyor.
Ancak Princeton ve Chicago tarafından yakın zamanda yapılan bir araştırma, LLM'nin bir kod çiftçisi olarak yapılmasının o kadar kolay olmadığını buldu.
2294 gerçek GitHub problemi karşısında, rastgele GitHub problemlerini çözen GPT-4'ün geçme oranı %0 çıktı!
En iyi model olan Claude 2 bile bunların sadece %1.96'sını çözüyor.
Uyum sağla ya da yok ol
Dünyadaki her geliştiricinin en sevdiği kod destekli site olan Stack Overflow, geçen yıl bir işe alım çılgınlığı başlatarak şirketin işgücünü ikiye katlayarak 540'a çıkardı.
Ancak, OpenAI'nin geçen Kasım ayında ChatGPT'yi piyasaya sürmesinden bu yana her şey değişti.
LLM %100 güvenilir yanıtlar sağlamasa da, kodu IDE entegre geliştirme ortamında test ederek hemen doğrulama konusundaki benzersiz yetenek, kod yazmayı ChatGPT için ideal bir kullanım durumu haline getirir.
Sonuç olarak, Stack Overflow'un trafiği büyük ölçüde azaldı ve ChatGPT ve GPT-4 destekli Github Copilot gibi yapay zeka programlama araçları, kod çiftçileri için yeni yerler haline geldi.
Bugün CEO Prashanth Chandrasekar, Stack Overflow'un yüzden fazla çalışanını veya işgücünün %28'ini işten çıkardığını duyurdu.
** Nehri geçip köprüyü yıkmak mı? **
ChatGPT'nin Stack Overflow üzerindeki etkisinin en büyük ironisi, büyük dil modelinin gücünün büyük ölçüde Stack Overflow gibi kazıma sitelerinden gelmesidir.
Büyük dil modelleri hiçbir şey vermeden bu verileri boşaltırsa ve tüm veri kaynakları işten çıkarılırsa ne olur?
Şimdi, birçok teknoloji şirketinin zaten baş gösteren bir sorunu var: daha az programcı varsa, daha az yapay veri olacaktır.
Güncel veriler olmadan yeni yapay zeka modellerini nasıl eğitirsiniz?
Verilerimizi kullanmak ister misiniz? Parayı al**
Stack Overflow elbette yerinde duramıyor, kendini kurtarmak için iki yol seçti -
Biri kendi yapay zeka kodlama aracı OverflowAI'yi geliştirmek, diğeri ise yapay zeka modelleri oluşturmak için Stack Overflow'un verilerini kullanan OpenAI gibi teknoloji şirketleriyle doğrudan ortaklıklar aramak.
CEO, Stack Overflow'un duruşunu belirlediğini söyledi: LLM'yi eğitmek için verilerimizi kullanmak isteyen herkes öder.
CEO'lar, Stack Overflow gibi sitelerin büyük dil modellerinin geliştirilmesi için kritik öneme sahip olduğuna ve ilerlemek için yeni bilgiler konusunda eğitilmeleri gerektiğine inanıyor.
LLM çiftçi kodunu almak istiyor, hala erken
Peki, büyük dil modelleri gerçekten kod çiftçilerini alabilir mi?
Princeton ve Chicago ekipleri bunun o kadar kolay olmadığını gördü!
GPT-4 ve Claude 2 gibi önde gelen büyük modellerin gerçek sorunları çözme yeteneğinin %5'ten daha az olduğu bulundu.
Daha spesifik olmak gerekirse, GPT-4 rastgele GitHub sorunlarını %0'lık bir geçiş oranıyla çözebilirken, en iyi model olan Claude 2 bunların yalnızca %1.96'sını çözebilir.
Ayrıca 12 popüler Python kütüphanesi ile farklı modellerin problem çözme performansı da değişkenlik göstermektedir.
Ancak AI'nın gerçek gücünü açıkça görmek için puanlanmayın ve endişelenmeyin.
SWE-bench: Kodlama modelleri için tasarlanmıştır
Bu çalışmada yazarlar, büyük modellerin kodlama yeteneğini ölçmek için mevcut birçok kriterin doygun hale geldiğini ve büyük modellerin gerçek gücünü ölçemediğini bulmuşlardır.
Örneğin, İnsan'da, meydan okuma problemi çok basittir ve LLM'nin tek başına bir problemi çözmek için yalnızca birkaç satır koda ihtiyacı vardır.
Ancak, yazılım mühendisliği gerçekte o kadar basit değildir.
Bundan ilham alan Princeton ve Chicago'dan araştırmacılar SWE-bench'i tanıttı.
SWE-bench, GitHub sorunlarını bağlayarak ve ilgili testleri çözmek için istek çözümlerini birleştirerek gerçek bir Python deposundan görev örneklerini alır.
Görüntüde gösterildiği gibi, modelin görevi (genellikle bir hata raporu veya özellik isteği), GitHub deposuna işlenen bir sorunu çözmektir.
Her görev, bir yama oluşturmayı ve mevcut kod tabanına uygulanacak değişiklikleri açıklamayı gerektirir.
Ardından, değiştirilen kod tabanını değerlendirmek için deponun test çerçevesi SWE-bench'i kullanın.
Çekme istekleri (PR'ler) ilk olarak GitHub'daki 12 popüler açık kaynak Python deposundan toplandı ve toplamda yaklaşık 90.000 PR oluşturuldu.
Araştırmacılar, daha iyi korunma eğiliminde oldukları, açık katılımcı yönergelerine sahip oldukları ve daha iyi test kapsamına sahip oldukları için popüler depolara odaklandılar. Her PR'nin ilişkili bir kod tabanı vardır, yani PR birleştirilmeden önce deponun durumu.
**2. Aşama: Öznitelik tabanlı filtreleme. **
Aday görev, aşağıdaki ölçütleri karşılayan birleştirilmiş bir çekme isteği seçilerek oluşturulur: (1) GitHub sorununu çözer; (2) Deponun test dosyası, kullanıcının sorunun çözülüp çözülmediğini kontrol etmek için büyük olasılıkla testlere katkıda bulunduğunu gösterir.
**Aşama 3: Yürütme tabanlı filtreleme. **
Her aday görev için, PR'nin test içeriği uygulanır ve PR'nin diğer içeriğinden önceki ve sonraki ilgili test sonuçları uygulanır.
Araştırmacı, en az bir testi olmayan görevlerin örneklerini filtreler ve bu testlerin durumu başarısız olarak değişir (bundan böyle "testi geçemedi" olarak anılacaktır). Ayrıca, yükleme veya işlem hatalarına neden olan örnekler filtrelenir.
Bu tarama aşamaları boyunca, orijinal 90.000 PR, SWE tezgahını oluşturan 2.294 görev örneğinde taranır.
Bu görev örneklerinin farklı depolardaki son sınıflandırması aşağıdaki Şekil 3'te gösterilmiştir ve tablo SWE-bench görev örneklerinin ana özelliğidir.
Araştırmacılar, bu kod tabanlarının büyük olduğunu, binlerce dosya içerdiğini ve referans çekme isteklerinin genellikle aynı anda birden fazla dosyayı değiştirdiğini vurguluyor.
SWE-bench, mevcut LM programlama kıyaslamalarına göre çeşitli avantajlar sunar.
Bunlar, kullanıcı tarafından gönderilen sorunlar ve çözümler içeren gerçek dünya ayarlarını, 12 depodan benzersiz kod soruları içeren çeşitli girdileri, sağlam bir yürütme tabanlı değerlendirme çerçevesini ve minimum insan müdahalesiyle yeni örneklerle karşılaştırmaları sürekli güncelleme yeteneğini içerir.
LLM Görevi: Kod Tabanını Düzenleyin, Sorunları Çözün
Araştırmacı, büyük modele sorunun metinsel bir tanımını ve eksiksiz bir kod tabanını verecektir.
Büyük modelin görevi, sorunu çözmek için kod tabanını düzenlemektir.
Uygulamada, araştırmacılar değişiklikleri, sorunu çözmek için kod tabanındaki hangi satırların değiştirileceğini belirten yama dosyaları olarak temsil eder.
Araştırmacılar Unix yamalarını kullanır, oluşturulan yamaları kod tabanına uygular ve ardından görev örnekleriyle ilgili birim ve sistem testleri gerçekleştirir.
Çözümlenen görev örneklerinin yüzdesi olan taban çizgisinin ölçümü.
SWE tezgahı için benzersiz bir veri kümesi oluşturma
Geleneksel NLP kıyaslamaları tipik olarak yalnızca kısa girdi ve çıktı dizilerini içerir ve özellikle kıyaslamalar için oluşturulmuş bazı "yapay" sorunları dikkate alır.
Buna karşılık, SWE tezgahını oluşturmak için araştırmacılar veri kümesine benzersiz özellikler enjekte ettiler.
Örneğin, gerçek yazılım mühendisliği görevleri kullanılır.
Dahası, toplama işlemi GitHub'daki herhangi bir Python deposuna çok az insan müdahalesi ile veya hiç müdahale olmadan kolayca uygulanabilir.
Sonuç olarak, araştırmacılar yeni görev örnekleri sağlayarak SWE tezgahını genişletebilir ve eğitim tarihinden sonra oluşturulan problemler için dil modelini değerlendirerek eğitim külliyatının bir çözüm içermemesini sağlayabilir.
Buna ek olarak, araştırmacılar kıyaslamada farklı uzun girdileri, sağlam değerlendirmeyi, bağlamlar arası kod düzenlemeyi, geniş çözüm yelpazesini vb. garanti eder.
SWE-Llama'ya ince ayar yapmak
Ardından, SWE-bench çerçevesindeki açık ve tescilli modellerin etkinliğini değerlendirmenin zamanı geldi.
Bununla birlikte, araştırmacılar, kullanıma hazır CodeLlama ince ayar modellerinin, kitaplık genelinde kod düzenlemeleri oluşturmak için ayrıntılı talimatları takip edemediğini, genellikle yer tutucu yanıtları veya alakasız kodlar çıkardığını buldular.
Bu modellerin yeteneklerini değerlendirmek için araştırmacılar, 7 milyar parametreli CodeLlama-Python modeli ve 13 milyar parametreli CodeLlama-Python modeli üzerinde denetimli ince ayar (SFT) gerçekleştirdiler.
Ortaya çıkan model, tüketici sınıfı donanım üzerinde çalışan ve GitHub sorunlarını çözen özel bir depo düzenleyicisidir.
Daha sonra araştırmacılar GPT-3.5, GPT-4, Cluade 2 ve ince ayarlı modelleri değerlendirdi.
Tüm modellerin başarısız olduğu ortaya çıktı - hiçbiri en basit problemler dışında hepsini çözmedi.
Örneğin, Claude 2 ve GPT-4, görevlerin sırasıyla yalnızca %4,8 ve %1,7'sini çözebilir.
BM25 retriever'ı kullandıktan sonra, Claude 2'nin performansı %1.96'ya düştü.
**Farklı kütüphanelerin farklı zorluk seviyeleri vardır. **
Performansı depoya göre ayırırsanız, tüm modellerin kitaplıklar arasında benzer eğilimler sergilediğini görürsünüz.
Yine de, her modelin ele aldığı sorunların kapsamlı bir şekilde örtüşmesi gerekmez. Örneğin, bir oracle kurulumunda Claude 2 ve SWE-Llama 13b, model başına sırasıyla 110 ve 91 örneği çözerek benzer bir performans gösterir.
**Zorluk, bağlam uzunluğuna bağlıdır. **
Modeller uzun kod dizileri üzerinde önceden eğitilebilir, ancak genellikle bir kerede tek bir işlevin oluşturulmasını gerektirir ve sorunu belirlemek için sınırlı bağlam içeren bir çerçeve sağlar.
Gösterildiği gibi, Claude 2'nin performansının, bağlamın toplam uzunluğu arttıkça önemli ölçüde düştüğünü görebilirsiniz, bu da diğer modellerde de gözlemlenebilir.
BM25'in maksimum bağlam boyutunun artırılması Oracle dosyalarına göre geri çağırmayı iyileştirse bile, model sorunlu kodu geniş eş anlamlılar sözlüğünde bulamadığı için performans yine de düşecektir.
Tablo 7, "oracle" arama ayarları altında 2023'ten önce veya sonra oluşturulan PR'ler için tarihe göre model sonuçlarını göstermektedir.
GPT-4 hariç çoğu model için bu tarihten önce veya sonra performansta çok az fark vardır.
LLM, programcıların yerine geçmez, ancak iş akışlarını hızlandırabilir
Bazı netizenlerin "genel modelin" geleceği için umutları ve umutları var.
Doğru, ben de öyle söylüyorum. Genelci model, nispeten kısa kod parçacıkları dışında, kendi başına kodlamak için yeterince geniş bir bağlam uzunluğuna sahip olacak kadar iyi değildir.
Ama bence bu sadece bir zaman meselesi. Yakın gelecekte, özel eğitim almış genel LLM'nin çok profesyonel bir model olacağını öngörebiliyorum.
Paradan tasarruf etmek için çalışanları işten çıkarmak yerine, geliştiricilerin son derece hızlı bir şekilde harika şeyler başarmasına izin verin!