StarCoder İncelemesi

“StarCoder: May the source be with you!” makalesinin Türkçe özeti niteliğindeki incelemesi.

Not: Zamanınız yoksa başlıkları ve koyu renkli metinleri okuyup tablo ve görsellere bakabilirsiniz.

Özet

Code LLM’lerin sorumlu bir şekilde geliştirilmesi üzerinde çalışan açık bilimsel işbirliği olan BigCode topluluğu 8K bağlam uzunluğuna, boşluk doldurma yeteneklerine ve çoklu sorgu dikkatiyle sağlanan hızlı büyük toplu çıkarıma sahip 15.5B parametre olan StarCoder ve StarCoderBase modellerini tanıtıyor:

StarCoderBase, denetim araçlarına ve devre dışı bırakma sürecine sahip, izin verilen lisanslı GitHub repolarından oluşan geniş bir koleksiyon olan The Stack’tan elde edilen 1 trilyon token üzerinde eğitilmiştir. StarCoder’ın oluşturulması için StarCoderBase’i 35B Python tokenları üzerinde finetune yaptık.

Code LLM’lerin bugüne kadarki en kapsamlı değerlendirmesini gerçekleştiriyoruz ve StarCoderBase’in, birden fazla programlama dilini destekleyen ve OpenAI code-cushman-001 modeliyle eşleşen veya ondan daha iyi performans gösteren her açık Code LLM’den daha iyi performans gösterdiğini gösteriyoruz. Ayrıca StarCoder, Python’da ince ayar yapılan her modelden daha iyi performans gösterir, HumanEval’de pass@1 ölçümünde %40 elde etmesi beklenebilir ve diğer programlama dillerindeki performansını da korur.

Güvenli bir açık erişim modeli sürümüne yönelik birkaç önemli adım atıyoruz. Bu adımlar arasında geliştirilmiş bir bir kişisel veri (PII) azaltma hattı ve yeni bir ilişkilendirme izleme aracı yer alıyor. StarCoder modellerini, Açık Sorumlu Yapay Zeka Modeli lisansının ticari açıdan daha uygun bir sürümü altında kamuya açık hale getiriyoruz.

Giriş

Büyük Dil Modelleri (LLM’ler), iş dünyasını ve günlük hayatımızı hızla değiştiriyor. ChatGPT gibi LLM’ler, piyasaya sürülmesinden sadece iki ay sonra 100 milyondan fazla kullanıcıya ulaştı ve bu da onu tarihin en hızlı büyüyen internet uygulamalarından biri haline getirdi. Benzer şekilde, Microsoft Copilot gibi LLM’ler, kodlama görevlerini %55'e kadar hızlandırarak profesyonel geliştiriciler arasında giderek daha popüler hale geliyor. LLM’ler, önümüzdeki yıllarda iş gücünü önemli ölçüde etkileyeceği tahmin edilen, heyecan verici yeni üretkenlik arttırıcı araçlardır.

LLM’ler, yanlış bilgi üretmek veya mevcut önyargıları güçlendirmek gibi bir dizi güvenlik endişesi de beraberinde getiriyor. Bu endişeler, eğitim sonrasında çeşitli teknikler kullanılarak ele alınmaktadır. Örneğin,LLM eğitimi, LLM’leri insani değerlerle uyumlu hale getirmeye yardımcı olabilir.

LLM’ler, eğitim öncesi aşamada da yasal ve etik endişeler yaratmaktadır. Bu endişelerin bir kısmı, dil modelini eğitmek için kamuya açık verileri kullanan içerik oluşturucuların haklarıyla ilgilidir. Bu veriler, ABD ve AB de dahil olmak üzere birçok yargı bölgesindeki telif hakkı yasalarına tabidir. Bu tür veriler üzerinde eğitilen makine öğrenimi modellerinin ABD’deki adil kullanım doktrini gibi muafiyetler kapsamına girip girmediği sorgulanmıştır.

Bir modelin eğitim setinde bulunmayan yeni içerik üretmesi, telif hakkıyla korunan materyalin dönüştürücü bir kullanımı olduğundan büyük olasılıkla adil kullanım olarak kabul edilir. Ancak modelin, özellikle içerik oluşturucuların ekonomik pazarını etkileyen senaryolarda, telif hakkıyla korunan verilere benzer çıktılar üretmesi durumunda, adil kullanım artık geçerli olmayabilir.

LLM geliştiricileri, bu modellerin mevcut telif hakkı yasalarına uygun olmasını sağlamak için adımlar atmalıdır. Örneğin, geliştiriciler, LLM’lerin ürettiği içeriğin telif hakkıyla korunan materyalden ayırt edilmesini kolaylaştıran araçlar sağlayabilir.

LLM’ler, tamamen kapalı veya tamamen açık olarak geliştirilebilir. Tamamen kapalı geliştirme, gücün yüksek kaynaklara sahip kuruluşlar arasında yoğunlaşmasına neden olabilir ve küçük geliştirme ekiplerinin modelin etkisini ve uzun vadeli sonuçlarını tam olarak anlamalarını zorlaştırabilir. Ayrıca, kapalı geliştirme sistemleri genellikle dış uzmanlar tarafından daha az denetlenebilir ve bilimsel ilerlemeyi engelleyebilir.

Tamamen açık geliştirme, topluluk araştırmasına olanak tanır, modellere erişimi demokratikleştirir ve tüm geliştirme süreci boyunca tam denetimlere olanak tanır. Bununla birlikte, uygun korkuluklar olmadan açık LLM geliştirme, daha yüksek bir kötüye kullanım riski oluşturur. Çünkü artan model erişimi, modelin neden olduğu zarar olasılığını da artırır. Serbest bırakılan bir API kapatılabilse de model ağırlıkları serbest bırakıldığında bunları geri çekmek neredeyse imkansızdır.

LLM’ler, iş gücünü önemli ölçüde etkileyebilecek güçlü araçlardır. Ancak bu araçların güvenli ve etik bir şekilde geliştirilmesi için dikkatli olunmalıdır. LLM geliştiricileri, güvenlik ve etik endişeleri ele almak için adımlar atmalı ve açık geliştirmenin avantajlarını ve dezavantajlarını dikkatlice değerlendirmelidir.

Açık kaynak kod için büyük dil modellerinin (LLM’ler) sorumlu bir şekilde geliştirilmesi ihtiyacının farkında olarak, BigCode projesi başlatıldı. BigCode, Hugging Face ve ServiceNow tarafından ortaklaşa yönetilmektedir ve çeşitli akademik enstitülerden ve endüstri laboratuvarlarından 600'den fazla üyeyi bir araya getirmiştir. Topluluk, veri kümelerinin toplanması, hızlı çıkarım yöntemlerinin uygulanması, değerlendirme paketi oluşturulması ve bu modeller için en iyi etik uygulamaların geliştirilmesi gibi konularda çalışma grupları oluşturmuştur.

Topluluk daha önce, 384 farklı programlama dilinde yazılmış izinli kaynak kodu içeren 6,4 TB’lık bir veri kümesi olan The Stack’i yayınladı. Veri kümesinin v1.2 sürümünde 54 GB GitHub sorunları ve depo düzeyinde meta veriler de yer almaktadır. Stack, geliştiricilerin kaynak kodlarının veri kümesinin bir parçası olup olmadığını kontrol etmelerine yönelik bir yönetim aracı olan “Ben Yığında mıyım” ve kodlarının veri kümesinden kaldırılmasını isteyenler için bir devre dışı bırakma süreci ile birlikte gelir.

Aralık 2022'de BigCode topluluğu, The Stack’tan Java, JavaScript ve Python koduyla eğitilmiş, güçlü performanslı bir 1.1B parametre modeli olan SantaCoder’ı da yayınladı.

Bu teknik raporda, The Stack’ın izin verilen lisanslı verileriyle eğitilmiş iki 15.5B parametre modeli olan StarCoder ve StarCoderBase’i geliştirme çabalarımızı açıklıyoruz. StarCoderBase’i 80'den fazla programlama dilinden, GitHub sorunlarından, Git taahhütlerinden ve Jupyter not defterlerinden elde edilen 1 trilyon token üzerinde eğittik. StarCoderBase’i başka bir 35B Python tokenı üzerinde ince ayar yaparak StarCoder modelini oluşturduk. Her iki StarCoder modeli de 8K bağlam uzunluğu, Ortadaki Doldurma yoluyla doldurma özellikleri ve Çoklu Sorgu Dikkati aracılığıyla hızlı büyük toplu çıkarım gibi mimari özelliklerin yeni bir kombinasyonuyla birlikte gelir.

BigCode projesinin genel olarak yaptığı katkıları şu şekilde özetleyebiliriz:

• 80'den fazla programlama dili üzerinde eğitilmiş, yeni yetenekler ve mimari özellikler sunan iki açık erişimli Kod LLM modelini piyasaya sürüyoruz: StarCoderBase ve StarCoder.
• StarCoder, birden fazla programlama dilini destekleyen kod konusunda tüm açık LLM’lerden daha iyi performans gösterir.
• StarCoder, OpenAI code-cushman-001 modelinden daha iyi performans gösterir.
• Python’da ince ayar yapıldığında StarCoder, Python’da da ince ayar yapılmış olan mevcut LLM’lerden önemli ölçüde daha iyi performans gösterir.
• 8K token bağlamından yararlanan StarCoder, talimat ayarlaması veya RLHF olmadan sanal bir teknik asistan gibi davranabilir.
• StarCoder’ı, belirlenen kritik senaryolara bir dizi kullanım kısıtlaması eklerken modelin telifsiz erişimine, kullanımına ve dağıtımına izin veren bir OpenRAIL-M lisans sözleşmesi kapsamında piyasaya sürüyoruz.
• Lisans sözleşmesinin şu özelliklere sahip bir versiyonu üzerinde çalıştık:

(i) Modeli kullanmak ve dağıtmak isteyen şirketler için ticari olarak daha uygun olan

(ii) Model kartları gibi yapay zeka belgelerinin paylaşılması yoluyla şeffaflığı ve anlayışı teşvik eden

• VSCode demosuna, kullanıcıların eğitim setinden kopyalanmış olabilecek model nesillerini tespit edip bulmalarına yardımcı olabilecek yeni bir ilişkilendirme aracı ekledik.
• Bu, hafif bir üyelik kontrolünü ve ardından BM25 endeksi üzerinde bir aramayı içeren iki adımlı bir süreç aracılığıyla gerçekleştirilir.
• Bir kişisel veri (PII) redaksiyon hattını önemli ölçüde geliştirdik.
• 22.950 açıklamalı varlık bulunduran 12.000 dosya içeren bir bir kişisel veri (PII) veri kümesi topladık.
• Bu veri kümesi üzerinde kodlayıcı modelimize (StarEncoder) ince ayar yaptık ve sonuçta sağlam bir kişisel veri (PII) tespit modeli elde ettik.

Alakalı Çalışma

Transformer mimarisi, makine çevirisinde büyük ilerleme sağladıktan sonra, dil modelleme alanında da devrim yarattı. Transformer mimarisi, kelimelerin bağlamını dikkate alarak anlamlarını daha iyi anlamamızı sağlıyor. Bu da, kelime yerleştirmelerin ve Üretken Önceden Eğitimli Transformatörlerin geliştirilmesine yol açtı.

Son yıllarda model performansını iyileştirmek için, model parametrelerinin ve eğitim verilerinin ölçeklendirilmesi yaygın olarak kullanılmaktadır. Model boyutu, eğitim belirteçlerinin sayısı ve işlem bütçesi gibi faktörlerin model performansı üzerindeki etkisini inceleyen teorilere ölçekleme yasaları denir.

Ölçekleme yasaları, test kaybı ile model boyutu, eğitim belirteçlerinin sayısı ve işlem bütçesi gibi çeşitli faktörler arasında öngörülebilir bir güç yasası ilişkisi olduğunu göstermiştir. Bununla birlikte, model ölçeğinin arttırılması, modelin aritmetik akıl yürütme gibi belirli görevleri yerine getirme yeteneğinde ani sıçramalar ile birlikte ortaya çıkan davranışlara da yol açabilir.

Veri Arındırma ve Temizleme

Bu bölümde StarCoderBase’in eğitim verilerini nasıl işlediğimiz açıklanmaktadır. Eğitim setini, yalnızca izin verilen lisansa sahip GitHub repolarından gelen verileri içeren Stack v1.2 ile sınırlandırıyoruz. Verilerin işlendiği sırada 44 kişi repo’sunu The Stack verisetinden çıkardı. Aşağıda buluşsal filtrelemeyi ve manuel incelemeyi birleştirerek verileri nasıl daha da temizlediğimizi açıklıyoruz.

Programlama Dilleri

Programlama dillerinin seçimi:

The Stack’taki 358 programlama dilinden 86 dili seçtik. Verilerin programlama dillerine atanması yalnızca dosya uzantısına göre gerçekleştirildi. 500 MB’tan fazla veriye sahip tüm programlama dillerinin yanı sıra Githut 2.0'da veya Aralık 2022 TIOBE programlama dili popülerlik endeksinde ilk 50'de yer alan dilleri dahil ettik. Konfigürasyon dillerini (Nix, Puppet vb.) ve artık aktif olarak desteklenmeyen dilleri (ActionScript) hariç tuttuk. JSON ve YAML gibi veri formatlarını da dahil ettik ancak veri hacmini sınırladık. Swift için insan hatası nedeniyle nihai dil listesine dahil edilmedi.

Manuel inceleme: Yalnızca yüksek kaliteli verileri sakladığımızdan emin olmak için görsel bir inceleme gerçekleştirdik. Bunu başarmak için, her programlama dili için The Stack’ten rastgele 30.000 dosya seçtik, bunları uzantıya göre kategorize ettik ve her uzantı için maksimum 1.000 dosya tuttuk. Daha sonra veri inceleme konusunda yardım almak için BigCode topluluğuna ulaştık. İncelemecilere 50–100 dosyayı incelemeleri ve verilerin metin, veri veya otomatik olarak oluşturulan tek bir uzun kod satırı yerine insanlar tarafından yazılan normal kod gibi görünüp görünmediğini doğrulamaları talimatını verdik. Ayrıca incelemecilerden, belirli bir dosya uzantısı için varsayılan alfa sayısal filtremizi (%25'ten fazla alfa numerik sembol gerektirir) ve uzun satır filtremizi (satırların 1.000 karakterden az olmasını gerektirir) kullanmamız gerekip gerekmediğini belirlemelerini istedik. On sekiz topluluk açıklayıcısı 300 programlama dili uzantısını değerlendirdi. İncelemenin ardından 36 genişletmeyi hariç tuttuk ve 27 genişletme için de uzun satır filtresini kaldırdık.

Kod verisi filtreleme: The Stack adlı kod dosyalarından oluşan bir veri kümesini temizlemek için 3 filtre kullanılmıştır:

• XML filtresi: Bu filtre, ilk 100 karakterde XML bildirim dizesini <?xml version=" içermeyen dosyaları kaldırır.
• Alfa filtresi: Bu filtre, %25'ten az alfabetik karaktere sahip dosyaları kaldırır. Ancak, belirli programlama dilleri için yüksek bir yanlış pozitif oranı nedeniyle, bu filtre yalnızca en yüksek sayıda algılamaya sahip 25 uzantı için uygulandı.
• HTML filtresi: Bu filtre, görünür metnin HTML kodunun %20'sinden azını oluşturduğu ve minimum 100 karakter uzunluğuna sahip dosyaları kaldırır.

JSON ve YAML dosyaları için yazar, aşağıdaki filtreleri kullanarak çoğu dosyayı kaldırdı:

• YAML filtresi: Bu filtre, 50–5000 karakter, ortalama satır uzunluğu 100'den küçük, maksimum satır uzunluğu 1000'den küçük ve %50'den fazla alfabetik karaktere sahip dosyaları tutar. Bu filtreler, veri dosyalarını kaldırmada ve veri kümesinin hacmini azaltmada etkilidir, ancak yine de en önemli kod ve belge dosyalarını korur.
• JSON filtresi: Bu filtre, 50–5000 karakter ve %50'den fazla alfabetik karakter içeren dosyaları tutar.

Jupyter Notebook’lar: Jupyter notebook’lar iki farklı veri kümesine dönüşmüştür: Jupyter — scripts ve Jupyter — structured dosyaları.

Jupyter — komut dosyaları veri kümesini oluşturmak için not defterlerini komut dosyalarına dönüştürmek amacıyla Jupytext kitaplığını kullandılar. Ancak 30.000'den fazla notebook’da herhangi bir programlama dili bilgisi eksikti, bu da bunların komut dosyası formatına dönüştürülmesini zorlaştırıyordu. Bu sorunu çözmek için not defterlerinin programlama dillerini belirlemek amacıyla Guesslang kitaplığını kullandılar. Guesslang’ı kullanarak tanımlanamayan not defterlerinin sayısını başarıyla 6.400'e düşürmeyi başardılar. Sonuçta Jupytext’i kullanarak 1.432.992 komut dosyası topladılar.

Jupyter yapılandırılmış veri kümesini oluşturmak için öncelikle herhangi bir Python kodu veya Markdown metni içermeyen not defterlerini filtrelediler. Daha sonra ardışık Markdown bloklarını veya kod bloklarını sırasıyla büyük bir Markdown veya kod bloğunda birleştirdiler. Sonunda, her not defterine göre gruplandırılmış, zamansal sıraya göre ardışık kod-metin çiftleri elde edildi. Ayrıca, çıktı hücresi boş değilse, kod bloğunun biçimlendirilmiş çıktısını da içeriyordu; aksi takdirde özel bir simgeyle işaretlenirdi. Bu ön işleme adımlarından sonra 1.045.605 adet yapılandırılmış Jupyter not defteri elde ettiler.

Aşağıda tüm dillerin tüm silme ve filtrelemelerden sonra hangi miktar ve oranda kaldığı gösterilmektedir. Java %11, markdown %9.7, Javascript %8.4 , PHP %7.9, Python %7.8, C %7, Github issue’ları %7, C++ %6.33, C# %5.8 , html %3.8, Github commit’leri %4, go %3.1, sql %1.4 ve geri kalanlar diğer dillerden oluşmaktadır.

StarCoder eğitim datasındaki dillerin oranları

Github Issue’ları

The Stack v1.2'nin bir bileşeni olarak toplanan GitHub sorunlarından ve pull requestlerden doğal dil konuşmalarını kullandık. Her konuşma, konuyu açma, yorum oluşturma veya konuyu kapatma gibi eylemler içeren bir dizi etkinlikten oluşur. Her etkinlik yazarın kullanıcı adını, mesajını, eylemini ve oluşturulma tarihini içerir. Bu verileri şu şekilde filtreledik:

1. Kullanıcıların e-posta ile yanıt verdiği sorunları silmek için, e-posta kalıplarını tanımlayan regex’leri kullandık. 200 karakterden daha kısa olan konuları da sildik ve ortadaki uzun yorumları, son 20 satırı koruyarak maksimum 100 satır olacak şekilde kestik. Bu filtre, veri kümesinin hacmini %18 oranında azalttı.
2. Daha sonra, yorumun yazarının kullanıcı adında anahtar kelimeler arayarak botların yorumlarını hariç tuttuk. Bu adım, toplam olayların %17'sini ortadan kaldırdı ve konuların %14,7'sinin boşaltılmasına neden olur. Bot tarafından oluşturulan sorunların genellikle uzun olduğunu ve çok sayıda log ve link içerdiğini gözlemledik.
3. Kalite göstergesi olarak konuşmaya katılan kullanıcı sayısını kullandık. Kriterimiz iki veya daha fazla kullanıcısı olan konuşmaları dahil etmekti. Ancak, yorumlardaki toplam metnin 7.000 karakterden (yüzde 96) az olması durumunda tek bir kullanıcının dahil olduğu konuşmaları da koruduk. Ek olarak, tek bir kullanıcı tarafından yazılan ve ondan fazla etkinlik içeren sorunları, düşük kalitede oldukları veya gözden kaçan botlardan kaynaklandıkları için hariç tuttuk. Bu filtreleri uygulayarak issue’ların %14'ünü daha ortadan kaldırdık.
4. Son olarak, hızlı fasttext kütüphanesinden bir model kullanarak İngilizce olmayan konuları filtreledik. Bu adım, bir kişisel veri (PII) tespit modeli kullanılarak adların doğru şekilde düzenlenmesini sağlamak için gerekliydi.

Git Commit’leri

Git commit verileri BigQuery’den toplanmıştır ve The Stack’te kullanılanla aynı lisanslara ve dosya uzantısına sahip repoların yalnızca tek dosyalı commitlerini içerir. The Stack’in kapsamı dışında kalmayı seçen kullanıcıların tüm repolarını kaldırdık. Ham veri kümesi yaklaşık 4 TB’tır. Yüksek kaliteli bir veri kümesi oluşturmak için dosyaların %50'sini örnekledik ve kalan verileri buluşsal yöntemlerle filtreledik. Bir committeki satır değişikliği sayısı, dosya boyutuna kıyasla çok düşük olabilir. Dosya içeriğini kopyalamayı öğrenmeye çok fazla işlem bütçesi harcamaktan kaçınmak için, dosyanın yalnızca %20'sini kullandık ve geri kalan %80'i için, ilk ve son değiştirilen satırın etrafındaki 0 ile 32 satır arasındaki bir pencereyi örnekledik. Ortaya çıkan veri kümesi 64 GB commit verisi içerir.

Git commit filtreleri

Tekilleştirme (Deduplication)

Tüm kaynak kod dosyalarının MinHash değerlerinin hesaplanmasını ve ardından benzer kod dosyalarını aynı parçaya eşlemek için Yerel Olarak Hassas Hashing’i (LSH) içeren veri tekilleştirme ardışık düzenini izledik. 5 gram ve 0,7 Jaccard benzerliği kullandık. Bu tekilleştirme sürecini tüm programlama dillerine ve Jupyter not defterlerine uyguladık. Ancak zaman kısıtlaması nedeniyle bu prosedürü Git commitlerine uygulayamadık. Ayrıca Github issue’larında yinelenen kopyalar bulmanın pek olası olmadığını düşündük, bu nedenle süreci onlara uygulamadık.

Veri Kaynaklarının Ağırlıklarının Ayarlanması

Belirli bir dildeki bir veri kaynağına tahsis edilen işlem bütçesi miktarı, modelin o dildeki performansını önemli ölçüde etkileyebileceğinden, BigCode topluluğu içinde belirli programlama dillerinde örnekleme arttırmaya mı azaltmaya mı gideleceği konusunda çeşitli tartışmalar vardı. Ancak mevcut verilerin büyük kısmının popüler programlama dillerinden geldiğini ve bu nedenle daha geniş bir son kullanıcı grubuna fayda sağlayacağını fark ettik. Üstelik veri tekilleştirme işleminden sonra C, C++, C#, Java, Javascript, Python ve PHP gibi birçok yüksek kaynaklı programlama dilinin 44–87 GB arasında değişen benzer miktarda veriye sahip olduğunu bulduk. Bu, mevcut veri dağılımını büyük ölçüde yeniden değerlendirmemize gerek olmadığı yönündeki inancımızı daha da güçlendirdi. Bu nedenle bu çalışmada eğitim sırasında verilerin doğal dağılımını takip ettik ve veri kaynaklarını hacimleriyle orantılı olarak örnekledik. Ancak, JSON, YAML ve CSS için bir istisna yaptık çünkü yalnızca LLM’nin bu tür dosyalardaki verileri ezberleyerek bilgi işlem kaynaklarını boşa harcamadan veri formatını öğrenmesini istiyoruz. Bu nedenle veri kaynağının hacmini JSON ve YAML için 1 GB, CSS için 3 GB olarak yeniden tarttık.

Kişisel Olarak Tanımlanabilir Bilgilerin Silinmesi (P.I.I Reduction)

Bu bölümde Kişisel Olarak Tanımlanabilir Bilgilerin (PII) eğitim verilerinden kaldırılmasına yönelik çabalarımız özetlenmektedir. İk olarak geniş bir kişisel veri anotasyon kümesini nasıl topladığımızı açıklıyoruz. Bu anotasyonlar, geliştirdiğimiz kodlayıcı modelinin üzerine inşa ederek bir kişisel veri tespit modelini eğitmek için çeşitli teknikleri araştırmak amacıyla kullandık.

Kaynak kodunda kişisel veri için bir veri kümesine açıklama eklemek üzere 35 ülkeden 1.399 kalabalık çalışanın katılımını sağlamak için Toloka platformunu9 kullandık. Katılımcılar ortalama 206 görevi tamamladı, yaklaşık 27 dolar kazandı ve 3,1 saat çalıştı.

Datamızdaki farklı programlama dillerindeki kişisel veri bulunduran dosya sayıları

Amacımız isimler, kullanıcı isimleri, e-postalar, IP adresleri, anahtarlar, şifreler ve kimlikler gibi çeşitli biçimlerdeki kişisel bilgileri tanımlamaktı. Kalabalık çalışanların adil ücret almasını sağlamak için, ülkeler arasındaki farklı asgari ücret oranlarını ve bunlara karşılık gelen satın alma güçlerini dikkate alarak saatlik ücret oranını 7,30 ABD doları olarak belirledik. Ek açıklama uygunluğunu, satın alma gücü paritesi açısından saatlik ücret oranının 7,30 ABD doları ile ABD’deki en yüksek asgari ücrete (16,50 ABD doları) eşit olduğu ülkelerle sınırladık. Toloka’daki kalabalık işçiler görevlerini istedikleri zaman ve istedikleri yerde yapabilirler; Belirli bir görevi tamamlama veya o işe belirli bir süre harcama zorunluluğu yoktur.
Böylece görevler üzerinde çalışırken özgür seçimden yararlanırlar. 1.399 kalabalık çalışandan 695'i görev kalitesine ilişkin bir anketi doldurdu ve 519'u anketi tamamladı. Katılımcının buna benzer başka bir projeye katkıda bulunmak isteyip istemediğini soran sorunun ortalama puanı 1–5 arası 4,92'dir.

31 programlama dilinde yazılmış yaklaşık 50 satırlık kod içeren 12.000 dosyaya manuel olarak açıklama eklenerek oluşturulan, koddaki kişisel veriden oluşan bir veri kümesi tanıtılmaktadır. Veri kümesi; adlar, e-postalar, kullanıcı adları, gizli kimlikler, IP adresleri ve anahtarlar dahil olmak üzere toplam 22.950 kişisel veriden içerir. Veri işaretleyiciler, kişisel verinin kodun lisans başlığında mevcut olup olmadığı, yer tutucu olarak kullanılıp kullanılmadığı veya gizli veri oluşturup oluşturmadığı gibi, ortaya çıktığı spesifik bağlama göre çeşitli kişisel veriden türleri arasında ayrım yaptı. Yazarlar, 300 dosyayı manuel olarak inceleyerek ve her kişisel veriden türü için geri çağırma ve kesinliği hesaplayarak veri kümesinin kalitesini değerlendirdi. Ek açıklama yapanların birçok yanlış pozitif ve negatif sonuç üretme eğiliminde olması nedeniyle, gizli kimliklere açıklama eklemenin özellikle zorlayıcı olduğunu buldular. Sonuç olarak yazarlar bu kategoriyi kişisel veriden tespit modeli eğitiminden çıkarmaya karar verdiler.

StarEncoder

Kişisel veri tespit çabalarının bir parçası olarak, yazarlar hem kod hem de metinle ilgili görevler için verimli bir şekilde finetune edilebilen bir kodlayıcı yalnızca model (yani, çift yönlü kendi kendine dikkatli Transformerlar) eğittiler. BERT’den Maskeli Dil Modelleme (MLM) ve Sonraki Cümle Tahmini (NSP) görevinin kaldıracını kullandılar ve bir giriş cümlesinden maskeli belirteçleri ve bir çift cümlenin bir belgede komşu olarak görünüp görünmediğini tahmin ettiler. Bu iki hedefe sırasıyla LMLM ve LNSP olarak diyorlar ve eğitim hedefi olan L’yi toplamları olarak tanımlıyorlar:

L = LMLM + LNSP

Kod parçalarını ayırmak ve her girdiyi şu şekilde temsil etmek için özel aıyraç belirteçler eklenir:

[CLS]{Kod Parçası-1}[SEP]{Kod Parçası-2}[SEP]

Burada iki kod parçası rastgele seçilir ve iki kod parçasının aynı kaynak dosyasından komşu olup olmadığına veya iki farklı dokümandan seçilip seçilmediğine karar verilir. Belirteçler %15 olasılıkla bağımsız olarak maskelenir ve sonuçlar, LMLM’yi hesaplamak için kullanılan giriş-çıkış çiftlerini tanımlar. Öte yandan, LNSP, “[CLS]” özel belirtecinde çıktı gösterimlerinin üstüne eğitilmiş doğrusal bir sınıflandırıcı kullanılarak hesaplanır.

Yazarlar, yaklaşık 400B belirtecin gözlemlenmesi için 1.024 maksimum uzunluğunda 4.096 dizi küresel toplu boyutu ile 100.000 adım için eğitildi. Bu, 64 NVIDIA A100 GPU kullanılarak yaklaşık iki gün sürdü.

PII türlerine ve toplanan ek açıklamaların sayısına genel bakış. 300 dosya üzerinde manuel incelemenin recall’unu ve precision’ını raporlayarak ek açıklama kalitesini araştırıyoruz. Her alt kategori, inceleme için karşılık gelen PII türüne geri eşleştirildi.

StarEncoder’ın model mimarisi

Özet olarak kişisel verilerin belirlenmesi ve çıkarılması için StarEncoder adında bir model geliştirilmiş. Anahtar değerlerde başarısız olmuş çünkü örnek azmış ve özel isimlerde başarısız olmuş çünkü onların içinde “@” sembolü varmış bunları da anotasyon/dekarotör’ler ile karıştırmış. Onun dışında regex ve NER gibi yöntemler de kullanmışlar ama en başarılısı StarEncoder olmuş. Sonuç olarak yakalanan değerler <NAME>, <EMAIL>,<KEY>,<PASSWORD> gibi etiketlerle maskelenmiş.

Bilgi işlem kaynakları GitHub issue’ları, Git commitleri ve Jupyter notebook’ları dahil olmak üzere eğitim veri kümesindeki tüm programlama dillerinde kişsel veriyi tanımlamak için kişisel veri tespit modelini kullandık. Toplam veri kümesinin boyutu 815 GB’tır. 800 GPU saati gerektiren birden fazla NVIDIA A100 80 GB GPU üzerinde çıkarım yaptık.

Model Eğitimi

StarCoderBase, seçilmiş veri kümesinden elde edilen 1 trilyon token üzerinde eğitilen ilk modeldir.

StarCoder, başka bir 35B Python tokeni üzerinde(yaklaşık 2 epoch) eğitilmiş, StarCoderBase’in finetune versiyonudur.

Veri Formatlama

Kod : Repo adını, dosya adını ve projenin yıldız sayısını kod dosyasının içeriğinin başına ekledik. Yıldızların tam sayısını aşmamak için GitHub yıldızlarını beş gruba ayırdık: 0, 1–10, 10–100, 100–1000 ve 1000+. Çıkarım sırasında modelin bu meta veriler olmadan çalışabilmesini sağlamak için, repo adını, dosya adını ve yıldızları bağımsız olarak rastgele ve her biri 0,2 olasılıkla önek ekledik.

<reponame>REPONAME<filename>FILENAME<gh_stars>STARS\nCode<eos>

Github issue’ları: Bir başlığın açılışını ve kapanışını işaretlemek için sentinel tokenları kullandık. Ayrıca yorumları ayırmak için özel bir belirteç kullandık ve hem başlığı hem de kullanıcı kimliğini metne dahil ettik. “userid”, görüşmede katılımcı sayacı görevi görür. Yorumların tarih ve saatini eklemediğimizi unutmayın.

<issue_start>title + USERID: comment<issue_comment>USERID: Comment … <issue_closed (optional)> <eos>

Git commitleri: Commit öncesi kodu, commit mesajını ve commit sonrası kodu sentinel token’larla ayırdık. İlk denemeler, daha küçük modeller için fark formatının çıktısını almanın zor olduğunu gösterdiğinden, farklar yerine değişikliklerle birlikte kodun tamamını dahil ettik.

<commit_before>code<commit_msg>text<commit_after>code<eos>

Eğitim Verisi Arındırma

Kod eğitimi verileri, HumanEval ve MBPP’den docstring’ler veya çözümler, APPS’den docstringler, GSM8K’den sorular veya DS1000'den istemler içeren dosyalar kaldırılarak temizlendi. Temizleme yoluyla kaldırılan veri miktarının bir göstergesi olarak Python, kaldırılan 558 dosyayla en yüksek eşleşme sayısına sahip dildir.

Tokenizer

Modelin tokenizer’ı, sunulan görüşlerimizi takip eder ve aynı tasarım seçimlerini kullanır: Hugging Face Tokenizers kütüphanesini, 49.152 token kelime dağarcığı boyutuna sahip bayt düzeyinde bir Bayt Çifti Kodlamayı eğitmek için kullanıyoruz. Tokenizasyon adımı, bir rakam ayırıcıyı ve GPT-2 pretokenizer’dan gelen normal ifade ayırıcıyı içerir.

Model Mimarisi

SantaCoder ile aynı mimariye sahip bir 15.5B parametre model eğittik. Bu model, Fill-in-the-Middle ve MultiQuery-Attention’a sahip, yalnızca decoder’a yönelik bir Transformatördür ve absolute positional embeddings’i öğrenmiştir.

Sentinel tokenlerine genel bakış

StarCoder Model Mimarisi

Eğitim Detayları

StarCoderBase Model, toplam bir trilyon token için 4 milyon token batch boyutunda 250 bin yineleme için eğitildi. Adam’ı β1 = 0,9, β2 = 0,95, e = 10−8 ve 0,1 weight decay kullandık. Öğrenme oranı, 2.000 iterasyonlu doğrusal bir ısınmanın ardından 3 × 10−4'ten 3 × 10−5'e bir kosinüs azalmasını takip etti.

StarCoder StarCoderBase’den başlayarak, eğitim verilerinin Python alt kümesinde 2 epoch için modelin Python varyantına ince ayar yaptık. StarCoderBase ile aynı ayarları kullandık ancak öğrenme oranını 5 × 10−5'e düşürdük ve 1000 doğrusal ısınma yinelemesinden sonra 5 × 10−6'ya düşürdük. 8.500 adım eğitim yaptık.

Çok Düğümlü GPU Kurulumu (Multi-node GPU setup)

Modelimizi 64 düğüme dağıtılmış 512 A100 80 GB GPU içeren bir GPU kümesi üzerinde eğittik. Modeli, bir replika için 16 GPU (2 node) gerektiren hem tensör hem de ardışık düzen paralelliği derece 4 ile parçalayan bir 3B paralel düzen ile bölümlendirdik. Kümenin yeteneklerinden tam anlamıyla yararlanmak için 32 kat veri paralelliği kullandık. GPU kullanımını optimize etmek ve boşta kalan bilgi işlem balonlarını azaltmak için, micro-batch iş boyutunu 1 olarak koruduk ve 16 adım boyunca biriktirdik; sonuçta 512'lik (4 milyon token’a eşdeğer) global toplu iş boyutu elde ettik. Megatron-LM’nin dağıtılmış optimizerini kullandık çünkü bunun bu konfigürasyonda biraz daha yüksek verim sağladığını gördük. FP32'de gradyan azaltma adımını gerektirdiğinden, BF16'daki eğitim FP16'ya göre %10 daha düşük verim sağlar, ancak yine de bunu eğitim kararsızlıklarından kaçınmak için kullandık.

CO2 Emisyonu

StarCoderBase StarCoderBase eğitiminin karbon ayak izini rapor ediyoruz. Eğitimin aldığı toplam GPU saati sayısına (320.256) ve GPU başına ortalama 280 W güç kullanımına bağlı olarak bu, eğitim süreci boyunca tüketilen 89671,68 kWh elektrik anlamına gelir. “us-west-2” AWS lokasyonunun enerjisinin karbon yoğunluğu (kWh başına 0,15495 kgCO2e) ve AWS veri merkezlerinde ortalama 1,2 Güç Kullanımı Verimliliği ile çarpıldığında bu, 16,68 ton CO2eq salınımına neden olur.

Finetune model olan StarCoder, eğitim süresinin %3,5'ini ekler; bu da tahmini olarak 0,58 ton CO2 eşdeğeri emisyona karşılık gelir.

Değerlendirme

Öncelikle StarCoder ve StarCoderBase’in yanı sıra değerlendirdiğimiz modellerin ana hatlarını çizelim. Daha sonra HumanEval, MBPP ve DS-1000 değerlendirme kriterlerindeki tüm modellerin Python dili performansını raporlayalım. Daha sonra çeşitli kıyaslamalar ve görevler kullanarak çoklu dil değerlendirmesini ele alıyoruz.

BigCode Değerlendirme Koşumu (The BigCode Evaluation Harness)

StarCoder ve diğer Code LLM’lerinin tekrarlanabilir ve merkezi değerlendirmesini sağlamak için, LLM’lere yönelik lm değerlendirme koşumundan ilham alan bigcode değerlendirme koşumunu geliştirdik. Bu donanım, yürütme için veri paralelliği ve docker worker container’larından yararlanarak kod modellerinin verimli bir şekilde değerlendirilmesi için bir çerçeve sağlar. Diğerlerinin yanı sıra HumanEval, MultiPL-E ve DS-1000 (StackOverflow sorularına dayanan 1.000 Python veri bilimi probleminden oluşan kod tamamlama karşılaştırması) dahil olmak üzere çeşitli kriterleri destekler.

Değerlendirme yapılan diğer modeller

StarCoder ve StarCoderBase’i şu modeller ile değerlendirdik:

• CodeGen-16B-Multi: 16B, açık erişim, 6 programlama dili destekli.
• CodeGen-16B-Mono: Yukarıdaki 16B modelin Python finetune’lu versiyonu.
• CodeGeeX: 13B, açık kaynak kodlu, 23 programlama dili.
• code-cushman-001: 12B, OpenAI, başlangıçta Copilot için tasarlandı.
• LLaMA, PALM, LAMDA (kod değil genel LLM’ler).

HUMANEVALS ve MBPP Kalite testleri (Benchmark)

HumanEval ve MBPP, Code LLM tarafından üretilen kodu doğrulamak için test senaryolarını kullanan yüzlerce Python programlama probleminden oluşan Kod LLM’ler için yaygın olarak kullanılan kriterlerdir. Kod LLM’ler çıktı dağıtımlarından örnekleme yaparak kod üretir. Performansı pass@k metriğini kullanarak raporluyoruz: k kod örneğinden herhangi biri her test senaryosunu geçerse bir kıyaslama problemi çözülmüş olarak kabul edilir. pass@1 için örnekleme sıcaklığı 0,2 ve k > 1 için sıcaklık 0,8 kullanırız. n = üretiriz Açık erişim modelleriyle yapılan tüm deneyler için 200 örnek. API modelleri için, pass@1'i tahmin etmek için yeterli olan n = 20 örnek kullanıyoruz. P’nin en basit versiyonuna odaklanıyoruz.

1. StarCoder, önemli ölçüde daha küçük olmasına rağmen PaLM, LaMDA ve LLaMA dahil en büyük LLM modellerden daha iyi performans gösterir.
2. StarCoderBase, Python konusunda da oldukça yeteneklidir ve yalnızca Python üzerinde ince ayar yapılan iki modelden daha iyi performans gösterir: CodeGen-16B-Mono ve StarCoder’ın kendisi.
3. StarCoder, OpenAI’nin code-cushman-001 (12B) modelinden daha iyi performans gösteriyor.
4. StarCoder, aşağıda açıklandığı gibi, eksik sonuçları ele alan basit bir istemle HumanEval’de rekor kıran %40 pass@1 elde eder.

DS-1000'de açık erişim ve kapalı erişim modellerinin performansı. Karşılaştırmalar aşağıdaki gibidir. Tüm modeller sıcaklık=0,2, üst p=0,5, maksimum uzunluk=1024 değerinde değerlendirildi. Puanlar, 40 örnek üzerinden ortalama 1 geçiş doğruluğunu yansıtır. ∗ : Matplotlib görev formatı doğru bağlama sahip değil, dolayısıyla ekleme ve tamamlama formatları aynı.

StarCoder için aşağıdaki prompt ön ekinin:

<filename>solutions/solution_1.py # Here is the correct implementation of the code exercise

performansı arttırdığını gözlemledik ancak StarCoderBase da dahil diğer modellerde aynı promptun performansı düşürdüğünü gözlemledik. Bu da prompt başarısının modele özgü olduğunu gösteriyor.

HumanEval ve MBPP’nin en büyük sınırlaması, çoğu programcının yazdığı kodu temsil etmeyen basit programlama bulmacaları olmalarıdır. Buna karşılık, DS-1000 kıyaslaması, yedi kütüphanede 1.000 gerçekçi ve pratik veri bilimi iş akışı paketine sahiptir ve uygulamadaki nesilleri test senaryolarına göre değerlendirir.

StarCoder’ın 19 programlama dilinde çok dilli açık erişim (örn. CodeGen-16B-Multi) ve kapalı erişim modelleriyle (örn. code-cushman-001) karşılaştırılması. MultiPL-E kullanarak Python’dan diğer dillere çevirdiğimiz HumanEval () üzerinde pass@1'i raporluyoruz

19 Programlama Dilinin Multiple-E Kullanarak Değerlendirilmesi

HumanEval ve MBPP Python kriterlerini diğer 18 programlama diline çeviren MultiPL-E’yi kullanarak StarCoder’ın doğal dili birden fazla programlama dilinde çalışan koda dönüştürme yeteneğini aşağıdaki gibi değerlendiriyoruz.

MultiPL-E, Python kıyaslamalarını her hedef programlama diline çeviren bir dizi kural tabanlı derleyiciye sahiptir. Her derleyici, HumanEval formatında bir kıyaslama bekler:

1. Bir doğal dil açıklaması (bir belge dizisinde),
2. Bir fonksiyon imzası (isim, argümanlar ve muhtemelen türler),
3. Bir dizi gizli assertion.

MultiPL-E derleyicileri, işlev imzasını, assertion’ları ve (doctest’lere sahip olabilecek) docstring’i hedef dile çevirir. Böylece MultiPL-E bize, programlama dilleri arasında model performansını karşılaştırmak için HumanEval ve MBPP’den türetilmiş paralel bir dizi kıyaslama sunar.14 MultiPL-E dilleri, hem yüksek hem de düşük kaynaklı dilleri, statik ve dinamik olarak yazılan dilleri ve çeşitli dilleri içerir.

1. 19 programlama dilinin tamamında StarCoderBase, bazen 2 kattan fazla performans göstererek diğer açık erişim modellerinden daha iyi performans gösterir.
2. StarCoderBase, değerlendirdiğimiz çoğu dilde code-cushman-001 ile rekabet halindedir. Bir kaç istisna var. Örneğin, code-cushman-001, C++, Java, Ruby ve Swift’te StarCoderBase’den %5'ten fazla performans gösterirken StarCoder, Julia’da code-cushman-001'den %5'ten fazla performans gösterir.
3. Python’da yapılan ince ayarlara rağmen StarCoder çoğu dilde rekabet gücünü koruyor ve diğer açık modellerden daha iyi performans gösteriyor. Daha da şaşırtıcı olanı, Python’da ince ayar yapılmasına rağmen StarCoder’ın belirli dillerde StarCoderBase’den biraz daha iyi performans göstermesidir. Şu anda yalnızca bunun neden böyle olduğu konusunda spekülasyon yapabiliriz ve açık eğitim verilerinin daha fazla araştırılması muhtemelen bu bulguya ışık tutmaya yardımcı olacaktır.

CodeGen-16BMulti, C#, Lua, PHP ve TypeScript dahil olmak üzere eğitim setinde yer almadığı bildirilen bazı dillerde beklenenden daha iyi performans gösteriyor. Basit JavaScript fonksiyonları genellikle tasarım gereği TypeScript ile tür kontrolü yaptığından, TypeScript’teki iyi performans daha az şaşırtıcıdır. Benzer şekilde StarCoder, eğitim setinde yer almamasına rağmen Swift üzerinde yüksek performans gösteriyor.

Doğal Dil Değerlendirme

StarCoder modelleri esas olarak Code LLM’ler olarak geliştirilmiş olsa da, önemli miktarda doğal dil metni üzerinde de eğitilmiştir. Eğitim tokenlarının yaklaşık %20'si doğal dil verileridir: Bunların %7'si GitHub sorunları, %10'u Markdown, %2'si Jupyter not defterleri ve %4'ü HTML’dir.

GSM8K matematik akıl yürütme testinde 8 atışlık doğruluk. Örnekler açgözlü kod çözme ile oluşturulur. maj1@k, k nesil boyunca çoğunluk oyu anlamına gelir. Çoğunluk oyu için bunun yerine p = 0,95 ve sıcaklık 0,7 olan çekirdek örneklemesini kullanarak örnekler oluşturuyoruz. Bir model belirli bir metrik üzerinde değerlendirilmediğinde veya metrik Dil Modeli Değerlendirme Sisteminde desteklenmediğinde “ — ” kullanırız.

Matematik Muhakemesi

Son çalışmalar, Kod LLM’Lerinin Program Destekli Dil modelleri adı verilen bir teknik kullanılarak etkili aritmetik ve sembolik akıl yürütmeler olabileceğini göstermiştir. PAL ile LLM, akıl yürütme problemini okur ve ara akıl yürütme adımları olarak Python programları üretir; bunlar daha sonra cevabı üretmek için Python yorumlayıcısı tarafından yürütülür. Buna karşılık, Düşünce Zinciri yöntemi, LLM’in cevabı oluşturmadan önce doğal dilde akıl yürütme adımlarını üretmesini teşvik eder.

MMLU dil anlama testinde 5 atımlık doğruluk.

CoQA soru cevaplama mücadelesinde sıfır atış doğruluğu.

Çıktıların Zararlılığının Ölçülmesi

Kod belgeleri veya teknik diyalog gibi açık uçlu metinler oluştururken, Kod LLM’si (yalnızca metinden oluşan LLM’lere benzer şekilde) zararlı çıktılar üretebilir. StarCoderBase’i, model tarafından üretilen metinlerde sosyal önyargıyı ve toksisiteyi ölçen karşılaştırmalı değerlendirmelerde önceki Code LLM’lerle karşılaştırıyoruz.

Sosyal Önyargı

Son zamanlarda yapılan çalışmalar, LLM’lerin sıklıkla sosyal önyargıları ve stereotipleri ön eğitim külliyatlarından yakaladığını vurguladı. Modelimiz içindeki sosyal önyargıyı ölçmek için StereoSet’i kullanıyoruz. StereoSet, dil modelleri içindeki sosyal önyargıları ölçmek için boşluk doldurma tarzı testlerden oluşan bir koleksiyondan oluşur.17 StereoSet’teki her örnek, üç olası tamamlamanın yanı sıra tamamlanmamış bir cümleden (örneğin, hizmetçimiz BOŞ) oluşur. Bu tamamlamalardan biri basmakalıptır (örneğin Meksika), diğeri kalıplaşmışlık karşıtıdır (örneğin İtalyanca) ve üçüncüsü ise ilgisizdir (örneğin bilgisayar). StereoSet üç ölçüm tanımlar: stereotip puanı, dil modelleme puanı ve ICAT puanı. Stereotip puanı, bir modelin bir cümlenin basmakalıp tamamlanmasını anti-basmakalıp tamamlama yerine tercih ettiği örneklerin yüzdesidir. Dil modelleme puanı, bir modelin ilgisiz bir tamamlama yerine anlamlı bir tamamlamayı (basmakalıp veya anti-basmakalıp) tercih ettiği örneklerin yüzdesidir. Son olarak Nadeem ve ark. (2021), bu iki ölçümü birleştiren idealleştirilmiş bir bağlam ilişkilendirme testi (ICAT) puanı tanımlar:

Yukarıda lms ve ss değişkenleri sırasıyla dil modeli skorunu ve stereotip skorunu belirtir.

LLaMA-13B ve CodeGen-Multi-16B ile birlikte StarCoderBase için StereoSet sonuçlarını Tablo 24'te rapor ediyoruz. Dört önyargı alanının tamamında, StarCoderBase’in en düşük stereotip puanlarını aldığını ancak aynı zamanda rekabetçi dil modelleme puanlarına sahip olduğunu görüyoruz. Bu, StarCoderBase’in düşük stereotip puanlarının yalnızca daha kötü dil modellemesinden kaynaklanmadığını ve aynı zamanda yüksek ICAT puanının da gösterdiği gibi olduğunu göstermektedir.

Cinsiyet, mesleki, ırksal ve dini önyargılar için StereoSet cümle içi sonuçlar. %50'ye yakın stereotip puanları en iyisidir. Dil modelleme puanları ve %100'e yakın ICAT puanları en iyisidir.

Toksiklik

Modelimiz tarafından üretilen yanıtlardaki toksisiteyi değerlendirmek için, genellikle dil modellerinden istenmeyen yanıtlar ortaya çıkaran cümle düzeyindeki istemlerin bir koleksiyonu olan RealToxicityPrompts’ı kullanırız. Minimum bir token uzunluğunda ve maksimum 128 token uzunluğunda StarCoderBase kullanarak RealToxicityPrompts’tan 10.000 örneğe yanıt üretiyoruz. Tüm yanıtlarımızı oluşturmak için p = 0,95 ile çekirdek örneklemeyi kullanıyoruz. Yanıtlardaki toksisiteyi otomatik olarak değerlendirmek için iki yöntem kullanıyoruz:

1. RoBERTa tabanlı toksisite sınıflandırıcısı.
2. Potansiyel olarak rahatsız edici kelimelerin bir listesi. 18 Toksisite dedektörü için, 0,5'lik bir eşik değeri kullanarak toksik olarak işaretlenen yanıtların yüzdesini rapor ediyoruz.

Saldırgan kelime listesi için, saldırgan kelime içeren yanıtların yüzdesini raporluyoruz. Saldırgan kelime listesinin potansiyel olarak yanıtları yanlış şekilde işaretlemesine rağmen, bariz toksisitenin kaba bir ölçüsünü sağlayabileceğini not ediyoruz. CodeGen-16B-Multi ve StarCoderBase’in her ikisinin de LLaMA-13B’den daha az toksik tepkiler ürettiğini gözlemliyoruz. Örneğin, LLaMA-13B’nin yanıtlarının %1,43'ü, StarCoderBase’in %1,12'sine kıyasla potansiyel olarak saldırgan tokenlar içeriyor. Ayrıca CodeGen-16B-Multi’nin StarCoderBase’den daha az toksik tepkiler ürettiğini de not ediyoruz.

HELM’deki Muhakeme Görevleri

StarCoderBase’i, LLM’lerin çok çeşitli görevlerdeki performanslarını raporlayarak şeffaflığını artırmayı amaçlayan bir değerlendirme paketi olan HELM ile değerlendiriyoruz.

RealToxicityTepki toksisitesi sonuçlarını ister. Toksisite sınıflandırıcısı ve rahatsız edici bir kelime listesi kullanarak toksik olarak işaretlenen yanıtların yüzdesini rapor ediyoruz. Düşük puanlar daha az toksik nesillerin göstergesidir.

HELM karşılaştırmasındaki doğal dil muhakeme görevlerine ilişkin model sonuçları, modeller görevlerdeki ortalama sıralamalarına göre sıralanmıştır. Bir model belirli bir ölçüme göre değerlendirilmediğinde veya HELM’de çalışma zamanı hataları kayıtlı olduğunda “ — “ kullanırız (örneğin, LSAT ve Yasal Destek’teki code-davinci-002 ve code-cushman-001 modelleri için “eşlenmemiş tahmin”) . StarCoder genellikle diğer açık erişim modellerinden önemli ölçüde daha iyi performans gösterir ve çoğu zaman çok daha büyük modellerden daha iyi performans gösterir.

Modelin, HELM’in doğal dil akıl yürütme görevleri için doğal dilini ve kod ön eğitimini kullanma yeteneği (kendi kapsamlı kod değerlendirmelerimiz nedeniyle kod görevleri hariç). Bu yazının yazıldığı sırada HELM testi CodeGen, CodeGeex ve LLaMA modellerini içermiyordu. Bu nedenle, StarCoderBase’i, HELM model listesinde19 sınıflandırıldığı şekliyle, her bir “sınırlı” veya “açık” erişim modeli ailesinden en büyük ve/veya en yeni modelle karşılaştırıyoruz ve bu HELM muhakeme görevlerinin çoğunda değerlendirilmiştir: 1 Mayıs 2023. Tablo 26'da sonuçları rapor ediyoruz. Her modelin her görevdeki sıralamasını hesaplıyoruz ve tablodaki modelleri, görevler arasındaki ortalama sıralamalarına göre sıralıyoruz. StarCoderBase genellikle ağırlıkları serbest bırakılan diğer tüm modellerden çok daha güçlü bir performans elde eder ve genellikle çok daha büyük modellerle karşılaştırılabilir veya onlardan daha iyi performans gösterir. Eğitim verilerindeki kod ve doğal dil karışımının, modelin bu akıl yürütme görevlerindeki güçlü performansına katkıda bulunduğunu düşünüyoruz.

Nicelikli Değerlendirme

StarCoderBase ile yaşadığımız birkaç ilginç etkileşimin altını çizeceğiz. Bunların, modelin yeteneklerini daha fazla araştırmak isteyen araştırmacılar ve geliştiriciler için bir başlangıç noktası olmasını umuyoruz. Git commit’leri, GitHub issue’ları ve Jupyter notebook’lara yönelik şablonları kullanarak ilginç model davranışının nasıl ortaya çıkarılacağına dair örnekler sağlıyoruz. Daha sonra StarCoder’ı herhangi bir talimat ayarlaması olmadan teknik asistan olarak hareket etmeye nasıl yönlendireceğimizi göstereceğiz.

Ön Eğitim Şablonlarını Kullanma

Git commit’i, GitHub issue’ları ve biçimlendirilmiş Jupyter not defterleri için ön eğitim sırasında sentinel belirteçleri içeren şablonlu bir yapı kullanırız. Bu şablon formatı, modeli belirli kullanım durumları için kolayca yönlendirmemize olanak tanır: commit formatı ve doğal dil talimatıyla modelin kodu değiştirmesini isteyebiliriz, GitHub issue’ları formatıyla teknik doğal dil sorularına yanıt verebiliriz. Jupyter kod hücrelerinin çıktısı üzerinde de eğitim aldığımız için, model temel bir yorumlayıcıymış gibi hareket etmek ve bir kod parçasının çıktısını tahmin etmek için kullanabiliriz. Boş çıktı belirtecini (<empty_output>) bastırarak modeli her zaman bir çıktıyı tahmin etmeye zorlayabiliriz.

Eğitim öncesi şablonların örnek kullanımları

Teknik Asistan

Ön incelemelerde, Anthropic’in HHH istemini kullanmanın modeli biraz yetenekli ama kırılgan bir teknik asistana dönüştürdüğünü keşfettik. Talimat ayarlaması olmadan StarCoder’ın 8k bağlam uzunluğunu kullanabildiğimize ve modelin soruları yanıtlamasına, talimatları takip etmesine ve teknik sorunların çözümüne yardımcı olmasına izin verebildiğimize şaşırdık. Programlama alanıyla ilgili daha fazla konuşma örneği ekleyerek HHH istemini daha da geliştirdik. Akıl yürütme soruları için CoT ve En Azdan En Çoka Yönlendirme dahil olmak üzere, istemi oluşturmak için çeşitli kaynaklardan örnekler kullandık. İstemin örnekleri StackExchange, PAL , Anthropic’in HHH istemi ve BigCode’un çabasından kaynaklanmaktadır. Teknik asistanın açık sınırlamaları olduğunu unutmayın: bazen yanlış çözümler önerir, yanlış gerçekleri sunar ve saldırgan yorumlarda bulunabilir.

Teknik Asistanla örnek etkileşimler

Sonuç

BigCode topluluğunun, kod üzerine eğitilmiş, açık erişimli 15.5B parametreli büyük dil modeli (LLM) olan StarCoderBase ve StarCoder’ı oluşturma çabalarını anlattık. Eğitim verileri, veri iyileştirme süreci, kişisel veri azaltma hattı ve model eğitimi de dahil olmak üzere araştırma ve geliştirme sürecinin tüm yönleriyle ilgili tam şeffaflık sağladık. Kod LLM’lerinin bugüne kadarki en kapsamlı değerlendirmesini gerçekleştirdik ve StarCoder’ın CodeGen ve CodeGeeX gibi diğer Code LLM’lerden daha iyi performans gösterdiğini ve OpenAI’nin kapalı erişim code-cushman-001 modelinden daha iyi performans gösterdiğini tespit ettik. StarCoder modellerini Açık Sorumlu Yapay Zeka Modeli lisansı ile piyasaya sürerek ve modeli GitHub’da oluşturmak için tüm kod repolarını açık kaynak haline getirerek, araştırma ve geliştirici topluluklarında Kod LLM’lerin erişimini, tekrarlanabilirliğini ve şeffaflığını artırmayı hedefliyoruz. Model lisansı, modelde yapılan değişikliklerin ve modeli kullanan uygulamaların sorumlu yapay zekanın BigCode ilkelerine uygun olmasını sağlamak için kullanım kısıtlamaları içerir. Ek olarak, Code LLM’lerin son kullanıcılarının eğitim setinden kopyalanmış olabilecek model nesillerini tespit etmelerine ve bulmalarına yardımcı olacak yeni bir ilişkilendirme araçları seti yayınladık. Bu önlemlerin güvenli bir model sürümüne katkıda bulunacağını ve güçlü performans gösteren StarCoder modellerinin iyi bir güç olarak kalmasını sağlayacağını umuyoruz.

Kaynaklar

[1] Raymond Li, Loubna Ben Allal, Yangtian Zi, Niklas Muennighoff, Denis Kocetkov, (9 Mayıs 2023), StarCoder: may the source be with you!

[https://arxiv.org/abs/2305.06161]