- Genel amaçlı LLM’ler, aşırı özelleşmiş görevlerde, Llama-2’yi doğrudan fine-tuning yaparak daha küçük ve daha ucuz bir modelle kalite, maliyet ve gecikmeyi birlikte iyileştirmeyi mümkün kılabilir
- Llama-2 13B, fine-tuning sonrasında ViGGO işlevsel gösterimi doğruluğunu %58’den %98’e, SQL üretimini %42’den %89’a, GSM8k’yi ise %28’den %47’ye çıkardı
- ViGGO ve SQL üretimi gibi çıktı biçiminin önemli olduğu görevlerde küçük Llama-2 modelleri GPT-4’ten daha iyi sonuç verdi, ancak matematiksel akıl yürütmede GPT-4 seviyesine ulaşamadı
- Deneyler Ray Train, Ray Data, DeepSpeed ve Accelerate tabanlı betiklerle yürütüldü; 7B·13B modeller 16xA10G, 70B model ise 32xA10G üzerinde eğitildi
- Performans artışının anahtarı model boyutundan çok veri kalitesi ve değerlendirme hattı; prompt engineering ile fine-tuning arasındaki maliyet/kalite trade-off’u görev bazında karşılaştırılmalı
Üç görevde görülen fine-tuning etkisi
- GPT-4 ve Claude-2 gibi büyük genel amaçlı modeller hızlı prototipleme için faydalı olsa da, destek bileti özetleme ve sınıflandırma gibi dar kapsamlı ihtiyaçlar için maliyet ve performans açısından fazla gelebilir
- Deney, Llama-2 modellerini üç gerçekçi göreve göre tam parametre fine-tuning yaptığında elde edilen iyileşme miktarını karşılaştırıyor
- ViGGO: yapılandırılmamış metinden işlevsel gösterim çıkarma
- SQL-create-context: doğal dil ve
CREATE TABLEbağlamından SQL üretme - GSM8k: ilkokul düzeyi matematik problem çözme
- Llama-2 13B için doğruluk değişimi şöyle oldu
- ViGGO işlevsel gösterimi: %58 → %98
- SQL üretimi: %42 → %89
- GSM8k: %28 → %47
- ViGGO ve SQL üretiminde küçük Llama-2 modelleri GPT-4’ten daha iyi sonuç verdi; GSM8k gibi matematiksel akıl yürütme görevlerinde ise fine-tuning sonrasında bile GPT-4 performansına ulaşamadı
Fine-tuning yöntemi ve eğitim altyapısı
- Üç görevin tamamında standart tam parametre fine-tuning kullanıldı
- Eğitim, sonraki token tahmini yöntemiyle yapıldı
- Modelin tüm parametreleri gradyan güncellemesine tabi tutuldu
- LoRA veya bazı transformer block’larını sabitleyen yöntemler deney kapsamı dışında bırakıldı
- Deney betikleri Ray Train, Ray Data, DeepSpeed ve Accelerate üzerine kuruldu
- Llama-2 7B, 13B ve 70B çalıştırmalarını destekliyor
- Ray Train’in TorchTrainer bileşeni, eğitim döngüsünü birden çok worker süreci ve GPU kaynağına dağıtıyor
- Veri sharding işlemi Ray Train tarafından yapılıyor; her worker,
session.get_dataset_shard("train"),session.get_dataset_shard("valid")ile kendisine atanan veri parçasına erişiyor
- Model sharding, DeepSpeed ZeRO stage 3 ve optimizer state offloading ile gerçekleştirildi
- Model parçaları birden fazla worker’a dağıldığı için, checkpoint kaydetme gibi tüm modele erişim gerektiren durumlarda modelin
accelerator.unwrap_model(model)ile açılması gerekiyor
- Model parçaları birden fazla worker’a dağıldığı için, checkpoint kaydetme gibi tüm modele erişim gerektiren durumlarda modelin
- Hesaplama kaynakları şöyleydi
- 7B·13B: 16xA10G
- 70B: 32xA10G, 4 adet
g5.48xlargeinstance - Ray kullanıldığında tam parametre fine-tuning için mutlaka A100 gerekmiyor
- Eğitim en fazla 10 epoch sürdü ve doğrulama kümesinde perplexity değeri en düşük olan checkpoint seçildi
Özel token’larla giriş/çıkış yapısını sabitleme
- Fine-tuning verisi, komut biçimli prompt’lar yerine görev yapısını özel token’larla ifade etti
- Örnek:
<START_Q>{question}<END_Q><START_A>{answer}<END_A>
- Örnek:
- Özel token’lar, modelin giriş ve çıkış bölümlerini ayırmasına ve çıktının nerede duracağını açık biçimde öğrenmesine yardımcı oldu
- Örnekte
<END_A>stopping token olarak tanımlanarak görev tamamlandığında üretimin durması sağlandı
- Örnekte
- Llama tokenizer varsayılan olarak 32.000 token ID üretir
- Dört özel token eklenince 32.004 ID üretir
<START_Q>için 32000,<END_Q>için 32001 gibi yeni ID’ler atanır
- Betikler,
tokenizer.add_tokens(special_tokens, special_tokens=True)ile özel token’ları ekliyor vemodel.resize_token_embeddings(len(tokenizer))ile yeni eğitilebilir parametreler oluşturuyor
ViGGO: yapılandırılmamış metni işlevsel gösterime dönüştürme
- ViGGO, aslında özellik-değer tabanlı işlevsel gösterimi doğal dil metnine çeviren İngilizce bir veri kümesi; deneyde ise yön tersine çevrilerek yapılandırılmamış metin yapılandırılmış işlevsel gösterime dönüştürüldü
- Alan, video oyunu görüşleri
- Sonuç gösterimi indeksleme ve sonraki uygulamalarda kullanılabilir
- Modelin, cümleye uygun işlevi ve özellik değerlerini üretmesi gerekiyor
- İşlev adayları arasında
inform,request,give_opinion,confirm,verify_attribute,suggest,request_explanation,recommend,request_attributebulunuyor - Özellik adayları arasında
name,release_year,esrb,genres,platforms,available_on_steam,has_linux_release,has_mac_release,specifier,rating,player_perspective,has_multiplayer,developer,exp_release_dateyer alıyor
- İşlev adayları arasında
- Örnek giriş
What's a really fast-paced game with multiplayer that you like to play?için beklenen çıktırequest(has_multiplayer[yes], specifier[fast-paced]) - Genel amaçlı modeller hedeflenen çıktı biçimine iyi uymadı ve uzun giriş bağlamı nedeniyle çıktı üretmekten çok girdiyi işleme süresi yüksek kaldı
- Bu görev, karmaşık mantıksal akıl yürütmeden çok örüntü tanıma ve temel dil anlama üzerine kurulu
- Gerekli tüm bilgiler girdide yer alan grounded bir görev
- Few-shot prompt’ların yardımcı olması, küçük Llama-2 modellerinin de fine-tuning ile iyileşebileceğine işaret ediyor
ViGGO değerlendirmesi ve sonuçlar
- Değerlendirmede yalnızca tam karakter eşleşmesi kullanılmadı
- Çıktı işlevinin doğru olup olmadığı kontrol edildi
- Özellik türlerinin doğru olup olmadığı kontrol edildi
- İşlev içindeki özelliklerin belirlenmiş öncelik sırasını izleyip izlemediği kontrol edildi
- GPT ve Llama-2-chat gibi instruction-following modellere yönelik prompt’larda özellik sırası kuralı açıkça belirtildiği için, değerlendirme de bu kurala uyulmasını şart koştu
- Değerlendirme hızını artırmak için Ray’in batch inference API ile Anyscale’in Aviary aracı birlikte kullanıldı
- LLM üretimi ve son işlemler birbirine bağlandı ve birden fazla makineye dağıtıldı
- 7B ve 13B modellerin doğruluğu fine-tuning sonrasında büyük ölçüde arttı
- GPT-4’ün doğruluğu, özellik önceliği değerlendirmeye katıldığında belirgin biçimde düştü
- Fine-tuning yapılmış modeller her zaman öncelik sırasına uydu ve bu kısıt eklendiğinde doğruluk değişmedi
- ViGGO sonuçları, yapılandırılmış biçim gerektiren görevlerde fine-tuning’in istikrarlı ve verimli bir yöntem olabileceğini gösteriyor
- Bu, yalnızca basit regex ya da JSON biçimi uydurma değil; hangi argümanların dahil edileceğine karar verme ve dahil edilenlerin sırasını da koruma görevi
- Sonuçlar 7B·13B modellerle elde edildiği için, servis maliyeti GPT-4 endpoint çağrısından daha düşük olabilir
SQL üretimi: doğal dil ve tablo bağlamından sorgu oluşturma
- SQL üretim görevi, doğal dilde bir sorgu ve SQL
CREATE TABLEifadesini girdi olarak alıp çalıştırılabilir SQL sorgusu üretmektir - Kullanılan veri kümesi b-mc2/sql-create-context, WikiSQL ve Spider veri kümelerini birleştiren bir Hugging Face veri kümesidir
- Her veri noktası doğal dil sorgusu, SQL
CREATE TABLEifadesi ve buna karşılık gelen SQL sorgusundan oluşur - Toplam 78.577 veri noktası bulunur
- Her veri noktası doğal dil sorgusu, SQL
- Veri kümesinde doğru SQL ile ilgili sorunlar vardı
CREATE TABLEiçinde tamsayı özellikleriVARCHARolarak gösterilmesine rağmen, SQL sorgularında bunlar çoğu zaman tamsayı gibi işlendi- Tamsayı özelliği varsayan tüm SQL sorguları çıkarılarak veri kümesi yaklaşık 70k’den 45k seviyesine indirildi
- Bu görev de doğal dili SQL gibi yapılandırılmış bir gösterime dönüştürdüğü için fine-tuning’e uygun
- Ancak ViGGO’dan farklı olarak, doğru yürütme sonucunu veren birden çok SQL mümkün olduğu için daha belirsiz bir yapı taşıyor
SQL değerlendirmesi ve sonuçlar
- SQL üretimi değerlendirmesinde basit string karşılaştırması uygun değil
- Karakter düzeyinde karşılaştırma çok sayıda false negative üretebilir
- AST karşılaştırması da değişken adı sırası gibi unsurlara duyarlı olabilir
- En güvenilir yöntem, kodu sentetik bir veri kümesinde çalıştırıp çıktıların aynı olup olmadığını karşılaştırmaktır
- Deneyde OpenAI GPT-3.5 endpoint kullanılarak yüzlerce örnek için birim testi amaçlı sahte tablolar üretildi
- GPT-3.5, soru, tablo şeması ve doğru cevabı görerek 10 veri noktasından oluşan sahte tablolar oluşturdu
sqlglot.executor.executeile doğru SQL ve model SQL’i çalıştırılarak sonuçlar karşılaştırıldı
- GPT-3.5’in ürettiği veri tablolarının kalitesini doğrulamak için önce doğru SQL çalıştırıldı
- Sonuç tablosu boşsa ya da özgün tabloyla aynı uzunluktaysa ilgili örnek atıldı
- Bu süreçte GPT’nin oluşturduğu veri tablolarının yaklaşık %50’si filtrelendi
- Fine-tuning yapılmış Llama-2 7B ve 13B, 70B-chat ve GPT-4’ten daha yüksek performans gösterdi
- Llama chat modellerinde sık görülen hata, prompt talimatına rağmen SQL’i tutarlı biçimde
<SQL>etiketleri içine yerleştirmemekti - Bu sorun 7B·13B chat modellerinde 70B’ye kıyasla daha yaygındı
- Llama chat modellerinde sık görülen hata, prompt talimatına rağmen SQL’i tutarlı biçimde
- SQL veri kümesindeki bazı doğal dil sorguları kusursuz İngilizce değildi; bu gürültü GPT-4 sonuçlarını etkilemiş olabilir
- Fine-tuning yapılmış modeller, veri kümesinin sıra dışı alışkanlıklarına hızla uyum sağladı
GSM8k: yapı öğreniminden daha zor matematiksel akıl yürütme
- GSM8k, matematiksel akıl yürütme ve anlama yeteneğini değerlendiren standart bir akademik benchmark’tır
- İlk iki görev daha çok yapı öğrenimine dayanırken, GSM8k modelin matematik problemlerini çözmek için akıl yürütme sürecini ne kadar geliştirebildiğini ölçüyor
- Örnek problem, nisan ayında 48 adet satıp mayısta bunun yarısını sattığında toplam satışın ne olduğunu soruyor; doğru cevap ara hesaplarla birlikte
#### 72biçiminde bitiyor - Güncel LLM’ler, son cevabı yalnızca içsel olarak hesaplayıp doğrudan vermektense, üretimin bir parçası olarak düşünce sürecini de oluşturmak zorunda; böylece sonraki token üretimi mantıksal sürece dayanabiliyor
- Bu görev, sadece basit hesap değil, öncüllerden ara sonuçlara ve oradan nihai cevaba giden mantıksal bir chain of thought gerektiriyor
GSM8k değerlendirme yöntemi ve baseline’lar
- Değerlendirme için model çıktısından nihai doğru cevabı güvenilir biçimde çıkaracak bir yönteme ihtiyaç var
- Genel amaçlı dil modelleri istenen çıktı biçimine tutarlı şekilde uymayabildiğinden otomatik değerlendirme zorlaşabiliyor
- Bunun için OpenAI function calling API kullanıldı
gpt-3.5-turbo-0613, diğer modellerin ürettiği yanıtlardan son tamsayı cevabı çıkarmak üzerereport_answerfonksiyonunu çağırdı- Örneğin model “The answer is four” yazsa bile bu yöntem
4olarak parse edebiliyor
- Bu yöntem, veri kümesinin doğru cevapları üzerinde test edilerek doğrulandı ancak değerlendirme sırasında OpenAI token maliyeti oluşturması dezavantajdı
- Fine-tuning yapılmış modeller hedeflenen yanıt örüntüsünü hızla öğrendiği için, yanlış olduklarında bile çıktı yapıları öngörülebilir kaldı
- Fine-tuning yapılmış modellerin değerlendirmesi
#### {answer}regex’i ile işlendi; böylece OpenAI endpoint tabanlı son işlemden kaçınıldı
- Fine-tuning yapılmış modellerin değerlendirmesi
- Baseline’lar şunlardı
- Makalede yayımlanan base pre-trained modellerin 8-shot prompting sonuçları
- Meta’nın RLHF ile genel amaçlı asistan olacak şekilde eğittiği Llama-2 chat-tuned varyantları için çeşitli prompt-engineered şablonlar
GSM8k sonuçları ve iki aşamalı fine-tuning
- Base model fine-tuning, GSM8k performansını tutarlı biçimde artırdı ancak her zaman chat-tuned modellerden açık ara daha iyi sonuç vermedi
- Chat modeller, chat-tuning sürecinde matematik örnekleriyle eğitilmiş olabileceği için base modellere göre daha doğruydu
- Fine-tuning yapılmış modele prompt ekleme yaklaşımı her zaman base modelden daha iyi sonuç vermedi
- Örneğin Llama-2-70B-chat, 8-shot örnek prompt verilen base modelden daha düşük kalabiliyor
- Fine-tuning yapılmış modeller ise 8-shot prompt’lu base modellere kıyasla tutarlı biçimde daha iyiydi
- Servis maliyeti açısından fine-tuning yapılmış modeller avantajlı olabilir
- Prompt tabanlı yaklaşımda her istekte prompt token maliyeti oluşur
- Fine-tuning yapılmış modelde ise maliyet fiilen yalnızca soru token sayısına yansır
- GSM8k eğitim verisi görece küçük, yaklaşık 8k örnekten oluştuğu için Llama-13B’nin potansiyelini tam olarak ortaya çıkarmakta yetersiz görüldü
- Llama-13B base modelin önce MathQA ile fine-tuning yapılıp ardından GSM8k ile yeniden fine-tuning yapılması ek iyileşme sağladı
- Yalnızca GSM8k ile fine-tuning, base modele göre 10 puanlık artış getirdi
- MathQA ardından GSM8k ile yapılan iki aşamalı fine-tuning, ilk fine-tuning sonucunun üzerine ek 10 puan ve base modele göre toplam 20 puan artış sağladı
- MathQA, 30.000 soru/cevap çiftinden oluşsa da GSM8k’ye göre daha gürültülü ve farklı bir yapıya sahipti
- Yanıt kalitesi daha düşüktü ve nihai cevap multiple choice biçimindeydi
- Buna rağmen iki aşamalı fine-tuning, MathQA’yı kullanarak GSM8k nihai sonucunu iyileştirmede etkili oldu
Pratik uygulamada bakılması gereken ölçütler
- GPT-4 ve Claude-2 gibi kapalı modeller, prototipleme ve ilk değer doğrulama için güçlü olsa da, production LLM uygulamalarını işletmek için her zaman yeterli olmayabilir
- Niche görevlere yönelik LLM fine-tuning, yalnızca gizlilik açısından değil, gecikme, maliyet ve kalite açısından da değerli olabilir
- ViGGO ve SQL örneklerinde kalite açısından da GPT-4’ten daha iyi sonuçlar elde edildi
- Fine-tuning’de asıl odak, altyapı ayrıntılarından çok veri toplama ve değerlendirme hattı kurmak olmalı
- Değerlendirme hattı, farklı yaklaşımların trade-off’larını iş gereksinimlerine göre karşılaştırmanın temelini oluşturur
- Deneyler Anyscale fine-tuning ve serving platformu ile Anyscale Endpoints kullanılarak yürütüldü
- Aynı süreç, Ray üzerindeki Anyscale fine-tuning ve serving çözümü sayesinde kendi veriniz ve kendi bulutunuzda tekrarlanabilecek şekilde yapılandırıldı
1 yorum
Hacker News yorumları
Birkaç hafta önce bir kodlama canlı yayınında kendi veri kümenizle Llama 2 ince ayarı yapmayı epey ele aldım; bunu Colab’da tek GPU ile yaptım.
Benim örneğimde veri kümesi kendi kodlarımdı.
Fine-tuning Llama yayını: https://www.youtube.com/watch?v=TYgtG2Th6fI&t=2282s
QLoRA ince ayarıyla ilgili birkaç oturum daha var; yakın zamanda makine öğrenmesine geçen 8 yıllık bir yazılım mühendisi olarak, kendi kendime öğrendiğim bakış açısından kavramları açıklıyorum.
QloRa fine-tuning yayını: https://www.youtube.com/watch?v=LitybCiLhSc&t=4584s
Kişisel projelerde ve şu anda üzerinde çalıştığım yapay zeka tabanlı girişimde buna nasıl yaklaştığımı olabildiğince anlaşılır biçimde anlatmaya çalışıyorum. En küçük web geliştirme LLM’ini ince ayarlama serisi de fena ilgi görmüyor gibi; yaklaşık bir aydır yayın yapıyorum ve ileride daha fazlasını paylaşmayı planlıyorum.
İnce ayarlı modelleri bölüp kullanma yaklaşımını da tam anlamıyorum. Ayrı ayrı Terraform LLM, SQL LLM, Python LLM mi gerekir, yoksa tek bir “kod” LLM’i yeterli mi, merak ediyorum.
Çok fazla uygulama ayrıntısı gerekiyor; bu da anlamlı bir kullanım alanı olmadığı sürece erişilebilirliği düşürüyor. privateGPT’nin yavaş yavaş o noktaya geleceğini düşünüyorum.
Diğer eğitimlerin çoğunun atladığı kısım bu. Özellikle güvenlik, doğruluk gibi farklı hedeflere göre bunun nasıl hazırlanacağını merak ediyorum.
Llama 2’de de aynı sorunu yaşıyorum. Yalnızca istediğim metni çıktı olarak vermesini sağlamak neredeyse imkânsız; yanıtın başına ya da sonuna sürekli bir şeyler ekliyor.
Bunu düzeltebilecek bir prompt tekniği var mı merak ediyorum.
airoboros, backtick’lerden, açıklamalardan vb. kaçınıp yalnızca kod çıktısı vermek için PLAINFORMAT token’ını destekliyor.
https://huggingface.co/TheBloke/airoboros-l2-70B-GPT4-2.0-GG...
Garanti etmek istiyorsanız, küçük bir veri kümesiyle, kabaca 1.000 örnekle ince ayar yapıp oradan iyileştirmek en iyisi.
Benim kullanım alanım yaratıcı yazımdan çok, metinden bilgi çıkarma/sentezleme gibi basit bir işti. Temel model her işe uygun olmayabilir.
contentdizgesi veya JSON içinde çıktılaması için prompt verebilirsiniz.JSON ise başlangıç ve bitişi belirleyebileceğiniz için JSON dışındaki içeriği temizleyebilirsiniz.
Böyle bir yazı görmek sevindirici. İnternette model özelleştirme hakkında çok fazla tartışma vardı; bu yazı gürültüyü epey iyi ayıklıyor.
Değerlendirme metodolojisi de hoşuma gitti; yazı da iyi yazılmış görünüyor.
LoRA ve kuantize eğitimin daha ciddi ele alınmaması garip. Çok daha ucuz, daha az zaman alıyor ve oldukça iyi olduğuna dair bolca kanıt var.
Bence sonradan denenecek ek bir seçenek gibi kenara itilmemeli.
NER benzeri işlerin en iyi performansı verdiğini görmek sevindirici. İnce ayarlı bir BERT modeliyle karşılaştırmak için benzer bir testi tam yapmak üzereydim.
Bu işin eğitim maliyetinin ne kadar olduğunu merak ediyorum.
Blok boyutu düşürülebilirdi ama kodu değiştirmemek daha kolay olduğu için aynı bıraktık. 7B, 16xA10G üzerinde epoch başına yaklaşık 15 dakika; 13B ise yaklaşık 25 dakika sürdü. Dolayısıyla isteğe bağlı maliyet epoch başına 7B için yaklaşık $7.2, 13B için yaklaşık $12. Bu değer yalnızca eğitimde geçen süreye göre; kümenin başlatma/kapatma süresi dahil değil.
7B ve 13B için 16xA10G, 70B içinse 4 g5.48xlarge instance’a bölünmüş 32xA10G kullandıkları belirtilmiş. Ray kullanınca bu modellerin tüm parametre ince ayarı için A100 bulundurmanız gerekmiyor ve aynı süreç her iş için tekrarlanıyor. GSM8k veri kümesinde bağlam uzunluğu 512 ve epoch başına 3,7 milyon etkin token temelinde örnek bir çalıştırma gösteriliyor.
En fazla 10 epoch’a kadar eğitip doğrulama setinde en düşük perplexity gösteren checkpoint’i seçtikleri söyleniyor.
Bir zorluk şu: Yeterince büyük özel bir veri kümesi oluşturmak için küçük bir ordu kadar insan gücü ya da çok güçlü mevcut bir model gerekiyor.
Sonunda OpenAI kullanma olasılığınız yüksek; ama OpenAI ile başka modellerin eğitim materyalini üretmek kullanım şartlarına aykırı. Bu konuda hiç dava açılıp açılmadığını merak ediyorum. Bunu sadece haksız bulup görmezden mi geliyorlar?
Son zamanlarda NER örnekleri daha sık görünüyor; bu tür işler için neden spaCy kullanılmadığını merak ediyorum.
Anyscale’de çalışıyorum.
Bu blog iyi ilgi görmüş gibi, bu yüzden Ray Summit’e eklemeyi planlıyoruz: https://raysummit.anyscale.com/agenda
Ray Summit’te ne tür içerikleri daha fazla görmek istediğinize dair fikirleriniz varsa paylaşırsanız sevinirim.
3,5 milyon token temelinde 7B’nin 1 epoch’u yaklaşık 14 dakika, 13B’nin 1 epoch’u yaklaşık 26 dakika sürüyor denmiş.
Hem 7B hem 13B için head node olarak en az 1xg5.16xlarge, worker node olarak 15xg5.4xlarge gerektiği söyleniyor; AWS’de maliyeti ne olur merak ediyorum.
us-east-1’de çalıştırırsanız saatte yaklaşık $30 olarak düşünebilirsiniz.
https://instances.vantage.sh/?selected=g5.16xlarge,g5.4xlarg...
M1 Ultra 64GB üzerinde Llama-2’yi yerel olarak ince ayarlamanın mümkün olup olmadığını merak ediyorum. Kaynakların çoğu bulutta ya da Linux’ta Nvidia CUDA kullanıyor; başvurulabilecek materyal olsa iyi olurdu.
Eğitim için biraz RunPod kredisi almayı düşünüyorum; birkaç on dolarla mümkün olacak gibi.