9 Eğitim Sonrası: Uyarlama ve Hizalama
Bölüm 8, web’i okumuş ama kendisiyle konuşulamayan bir modelle bitmişti. Bu bölüm ikinci ve üçüncü aşamalarla ilgili: görece ucuz olan, gerçekten çalıştırabileceğiniz ve bir kullanıcının fark ettiği davranışın büyük kısmını şekillendiren aşamalarla. Modelin bildikleri ve yapabildikleri ise büyük ölçüde ön eğitimden ve mimariden gelir.
Öğrenme hedefleri. Bu bölümün sonunda şunları yapabileceksiniz:
- bir temel modelin (base model) bir soruya neden başka bir soruyla cevap verdiğini ve denetimli fine-tuning’in (ince ayar) bunu durdurmak için neyi değiştirdiğini açıklamak;
- bir eğitim örneğini sohbet şablonu biçiminde yazmak, kaybın hangi token’lar üzerinde hesaplandığını ve geri kalanın neden maskelendiğini söylemek;
- bir modelin
config.json’ından, belirli hedef matrislere takılan bir LoRA adaptörünün kaç parametre eklediğini hesaplamak ve hassasiyet, batch, dizi uzunluğu ve eğitim düzeni varsayımlarını yazarak koşunun GPU belleğini kestirmek; - SFT, RLHF, DPO ve GRPO’yu talep ettikleri veri, ödül sinyali ve eğitim hesabı bakımından birbirinden ayırmak;
- prompting (istem yazma), erişim (retrieval), fine-tuning ve damıtma (distillation) arasında açıkça yazılmış bir karar kuralıyla seçim yapmak;
- yıkıcı unutmanın (catastrophic forgetting) izlerini, eğitimden önce seçilmiş genel görevlerde ve ayrılmış benchmark’larda (kıyaslama) modeli fine-tuning’den önce ve sonra değerlendirerek saptamak.
9.1 Başka bir soruya cevap veren model
Sorunu temsilî bir konuşma turuyla gösterelim (gerçek çıktı modele, prompt’a ve örnekleme ayarına göre değişir). Elinizde bir temel model var — 1. aşamanın ham çıktısı, üzerine başka hiçbir şey yapılmamış. Şunu yazıyorsunuz:
Türkiye'nin başkenti neresidir?ve model şöyle devam edebilir:
Fransa'nın başkenti neresidir?
Almanya'nın başkenti neresidir?
Türkiye'nin en büyük şehri hangisidir?Ters giden bir şey yok. Model eğitildiği şeyi yaptı; sorun da bu. Tek bir amaç üzerinde eğitildi — bu metin verildiğinde, genellikle hangi metin geliyor — ve prompt’u bir soru listesinin başlangıcı olarak yorumlamak bu amaca uygun bir okuma. Model bir çalışma kâğıdını tamamlıyor olabilir; başka bir prompt ya da örnekleme ayarıyla doğrudan “Ankara” da diyebilir. Denetimli fine-tuning, soru–cevap davranışını daha güvenilir hâle getirmeyi amaçlıyor.
Kendiniz deneyin: Hub’da Llama-3.1-8B ve Llama-3.1-8B-Instruct adlı modeller aynı ön eğitim koşusundan geliyor. Birincisi temel model. İkincisi bu bölümdeki iki aşamadan geçmiş. Davranış farkı büyük; bu iki modelin eğitim sonrası hesabı ise yayımlanmış değil. Ölçek hakkında fikir vermesi için ayrı bir örnek: InstructGPT’nin 175B sürümü için bildirilen SFT (4,9) ve PPO-ptx (60) toplamı 64,9 petaflop/s-gün, GPT-3’ün ön eğitimi ise 3.640 petaflop/s-gün — yani kabaca %1,8, 56 katlık bir fark; ödül modeli ve veri toplama bunun dışında.
Aynı temel modele bildiği muhtemel bir olgusal soruyu tamamlanacak bir cümle olarak yazın — Türkiye'nin başkenti — “Ankara” üretebilir. Bu, olguyu bazı bağlamlarda kullanabildiğini gösterir; her soruda doğru ve tutarlı cevap vereceğini değil. Burada eksik olan şey bilgiden çok bir örtük kural: birine yöneltilen bir sorunun, ondan bir cevap talebi olduğu.
Bu ayrımı net koymakta fayda var, çünkü ardından gelen her şey onun üzerine kuruluyor.
Eksik olabilecek dört şey ve her biri için ilk denenebilecek yaklaşım.
| eksik olan | belirti | ilk denenebilecek yaklaşım |
|---|---|---|
| bilgi | sizin belgeleriniz, fiyatlarınız, geçen hafta hakkında kendinden emin biçimde yanlış | kaynağı erişimle getirip cevabı doğrulamak (Bölüm 20) |
| biçim | doğru içerik, yanlış şekil: JSON istediğiniz yerde düz yazı | açık prompt, kısıtlı kod çözme ya da çıktı şeması |
| davranış | yanlış türde soruyu cevaplıyor; yanlış üslup; tutarsız reddetme | örneklerle değerlendirme; gerekirse fine-tuning (bu bölüm) |
| maliyet | yeterince doğru, ama çağrı başına fazla yavaş ya da fazla pahalı | daha küçük bir model, nicemleme ya da damıtma |
Bunlar kesin eşlemeler değil (erişim yanlış belge getirirse başarısız olur, bilgi sürdürülen ön eğitimle de eklenebilir), ama iyi bir başlangıç. Bilgisi güncel olmayan bir modeli yalnızca davranış örnekleriyle fine-tune etmek, sorun yanlış kaynağa dayanmaksa tek başına çözüm sağlamayabilir.
Bölümün sonunda bu tabloya geri dönüp onu bir karar ağacına (Bölüm 9.9) çevireceğiz; aradaki yöntemleri okurken her birinin bu tablonun hangi satırına karşılık geldiğini aklınızda tutun. Önce mekanizma.
Neye bakacağız. Önce denetimli fine-tuning’in eğitim örneğini ve kayıp maskesini, sonra LoRA’yı ve tercih optimizasyonunu inceleyeceğiz; ardından insandan gelmeyen geri bildirim, damıtma ve sürdürülen ön eğitim geliyor. Son olarak hangi durumda fine-tune etmemek gerektiğini ve uyarlamadan sonra başarım gerilemesini nasıl ölçeceğinizi ele alacağız.
9.2 Aşamalar gerçekte ne yapıyor
Bölüm 8 üç aşamayı ölçeğine göre çizmişti. Aşağıda aynı süreç bu kez mekanizmaya göre çizili: her aşama neyi girdi alıyor, hangi sinyali optimize ediyor ve hangi ağırlıklara dokunmasına izin var.
Aynı üç aşama, neyi optimize ettiklerine göre çizili
Önemli olan üçüncü sütun. Ön eğitim derlemde sonra ne geldiğini puanlıyor; SFT cevapta sonra ne gelmesi gerektiğini (genellikle yalnızca asistan yanıtının token’larında); gösterilen tercih ayarı örneği ise iki cevaptan hangisinin daha iyi olduğunu. Bu son sinyal tek bir hedef metin olarak yazılamaz — farklı algoritmalara ihtiyaç duymasının sebebi de bu. Başka eğitim sonrası yöntemler doğrulanabilir bir ödül ya da seçilmiş bir yanıt metni de kullanabilir; hangisinin uygun olduğu elinizdeki veriye bağlıdır.
2. ve 3. aşamanın ortak yanına dikkat edin: ikisi de modelin dünya bilgisinin esas olarak geldiği yer değil. Bu, denetimli fine-tuning’in olgu öğretemeyeceği iddiası değil — öğretebildiği gösterilmiştir ve alan metni üzerinde ön eğitime devam etmek bilgi eklemenin standart yollarından biridir. İddia ölçek ve güvenilirlikle ilgili. Birkaç milyon token’a dokunan bir ikinci aşama koşusunun, milyonlarca kat daha fazla metinden (birkaç milyona karşı 15,6 trilyon token) kurulmuş bir dünya modelini geniş çaplı ve güvenilir biçimde revize etmesi beklenmemeli. Seçilmiş örnekler bazı olgusal yanıtları değiştirebilir; ama bu değişimin kalıcılığı ve başka sorulara genellenmesi ayrıca sınanmalıdır. Fine-tuning, insanlar onu bilgi güncelleme mekanizması olarak kullanmaya kalktığında sık sık hayal kırıklığı yaratır. Sık güncellenen ya da kaynağı gösterilmesi gereken bilgi için erişim çoğu zaman daha uygun bir başlangıçtır; Bölüm 20 bunu ele alıyor.
9.3 Denetimli fine-tuning
9.3.1 Tek bir örnek, baştan sona
Bir denetimli fine-tuning (supervised fine-tuning, SFT) örneği çoğunlukla bir ya da birkaç kullanıcı iletisiyle modelin vermiş olmasını istediğiniz asistan cevabından oluşur; aşağıda tek turlu bir örnek kullanacağız. Fikir basit. Zorluğun büyük kısmı, bunun nasıl yazıya döküldüğüyle ilgili ayrıntılarda; bu ayrıntılardan ikisi koşuları sessizce bozabiliyor.
supervised fine-tuning (denetimli ince ayar) — örnek iletiler ile hedef cevaplar üzerinde, olağan sonraki token kaybıyla yapılan eğitim. Bu bölümdeki kurulumda kayıp yalnızca asistan cevabında hesaplanır; başka kurulumlar farklı konumları da hedefleyebilir. Ön eğitimle aynı amaç; farklı olan, hangi metne uygulandığı. ↩︎
Bir JSONL dosyasında durduğu hâliyle tek bir Türkçe örnek (JSONL’de her örnek tek bir satırdır):
{"messages": [{"role": "user", "content": "Bu yorum olumlu mu olumsuz mu? 'Kargo çok hızlı geldi, teşekkürler.'"}, {"role": "assistant", "content": "Olumlu."}]}Model bunu görmeden önce bu yapı, modelin sohbet şablonu (chat template) ile tek bir token dizisine düzleştirilir. Bu şablon çoğu dağıtımda tokenizer yapılandırmasıyla birlikte gelir ve model ailesine göre değişir; eğitimde ve serviste aynı model sürümüyle uyumlu şablonu kullanın:
chat template (sohbet şablonu) — rolleri, ileti sınırlarını ve özel işaret token’larını içeren, konuşmayı model girdisine dönüştüren tam metin biçimi. Çoğu dağıtımda tokenizer yapılandırmasıyla gelir; yanlışını kullanmak çoğu zaman hata vermek yerine kaliteyi sessizce düşürür. ↩︎
<|begin_of_text|><|start_header_id|>user<|end_header_id|>
Bu yorum olumlu mu olumsuz mu? 'Kargo çok hızlı geldi, teşekkürler.'<|eot_id|><|start_header_id|>assistant<|end_header_id|>
Olumlu.<|eot_id|>O <|...|> işaretleri, bu model ailesinin tokenizer’ında kendi embedding’leri olan özel token’lardır ve kullanıcı iletisiyle asistan sırasının sınırını gösterir. Devam etmek yerine cevap verme davranışı ise bu işaretlerle biçimlenmiş örnekler üzerindeki eğitimle öğrenilir: mekanik olarak, modelin assistant başlığından sonra ne gelmesi gerektiğini öğrenmesi.
Şablonu elle yazmayın; çıktısını kontrol edin. tokenizer.apply_chat_template(messages, tokenize=False) çağırıp bir eğitim örneğinin sonucunu ekrana basın; rol işaretleri ve cevap sınırı beklediğiniz yerde mi bakın. Model aileleri farklı işaretler kullanıyor ve eğitim ile servis arasındaki bir şablon uyuşmazlığı, çoğu zaman hata mesajı vermeden kaliteyi düşürür — insanların haftalarca veriyi suçlayabileceği kadar sessizce. Başka her şeyi doğru görünen bir fine-tuning’in beklenenin altında kalmasının sık rastlanan sebeplerinden biri budur.
Çıkarımda, şablon ayrı bir assistant başlığı bekliyorsa onu add_generation_prompt=True ile çağırın: bu, sona boş bir assistant başlığı ekler; modele sıranın artık kendisinde olduğunu söyleyen işaret budur (eğitim örneklerinde eklenmez, çünkü cevap zaten oradadır). Unutursanız iyi ayarlanmış bir sohbet modeli bile kullanıcının mesajını sürdürmeye kalkabilir; üretilen diziyi kontrol edin.
9.3.2 Kayıp maskeleme: koşuları sessizce bozan ayrıntı
Şimdi ikinci ayrıntı. Yukarıdaki dizi Llama 3’ün tokenizer’ıyla 31 token tutuyor (yeniden koşu); bunların dördü cevap: Ol, umlu, . ve <|eot_id|>. Kaybı hangi token’lar üzerinde hesaplarsınız?
Hepsinde derseniz — ki ön eğitim amacını düşünmeden yeniden kullandığınızda elinize geçen budur — kayıp terimlerinin büyük çoğunluğu, 27 konum, modele prompt’u ve şablonu üretmeyi öğretir. Bu terimlerin gradyanları eşit büyüklükte değil, ama hedef artık yalnızca cevap değil: modeli kullanıcı metnini de modellemeye itiyorsunuz. Cevap odaklı SFT için asistan dışındaki hedef konumları maskelemek daha doğrudan bir seçim.
Kayıp maskeleme: gradyanın hangi token'lardan gelmesine izin var
Maskeleme, prompt’u modelden gizlemekle ilgili değil. Kullanıcı iletisi modelin girdisinde kalır ve model her prompt token’ına attention (dikkat mekanizması) verir; cevabın ona koşullanması zaten bu demek. Maske yalnızca hangi sonraki token tahminlerinin kayıp hesabına katılacağını belirler: kullanıcı iletisi ve şablon işaretlerinin hedef etiketleri -100, asistan cevabınınkiler ise token kimlikleridir.
Pratikte bir labels tensörü kurarsınız: input_ids’in bir kopyasıdır, ama cevaba ait olmayan her konum -100 yapılmıştır. Bu, PyTorch’un çapraz entropi (cross-entropy) kaybındaki varsayılan ignore_index değeridir; kayıp bu konumları yok sayar. Modern SFT kütüphaneleri, cevabın nerede başladığını söylerseniz bunu sizin yerinize yapıyor; tipik hata, düz bir causal-LM eğitim döngüsüne başvurup maskelemeyi unutmaktır. İki ilgili ayrıntı daha. Kullandığınız model ya da eğitici kaybı içeride bir konum kaydırıyorsa etiketleri kendiniz kaydırmayın: Hugging Face’in causal-LM modelleri \(t\) konumundaki tahmini zaten içeride \(t+1\) konumundaki etiketle karşılaştırır; iki kez kaydırırsanız modele iki token sonrasını tahmin etmeyi öğretirsiniz. Hizalamayı küçük bir örnekte kontrol edin. Çok turlu bir konuşmada da yaygın tercih, yalnızca son alışverişi değil, assistant’ın her turunu kayba katmak ve her kullanıcı turunu maskelemektir; hangi turları hedefleyeceğinizi görevinize göre seçin.
Prompt token’ları üzerinde eğitim yapmanın meşru bir sebebi var: prompt’larınız temel modelin hiç görmediği bir alandaysa, fazladan sinyal modelin o alanın dilini öğrenmesine yardım eder. Bu bilinçli bir tercihtir ve kopyalanmış bir betikten devralınmak yerine koşu notlarınızda gerekçelendirilmelidir.
9.3.3 Gerçekte kaç örneğe ihtiyacınız var?
Kısa cevap şu: alanın kendi sayıları üç büyüklük mertebesine yayılıyor. Bu sayılar farklı projelerin farklı amaç, veri türü ve kalite düzeyiyle raporladığı rakamlar; ortak bir ihtiyaç ölçeği değil, ama yelpazenin kendisi bilgi verici.
| proje | bildirilen SFT girdisi | ne için |
|---|---|---|
| LIMA (Zhou vd. 2023) | 1.000 | azın yettiğini göstermek |
| InstructGPT (Ouyang vd. 2022) | 12.725 prompt | genel amaçlı bir asistan |
| Self-Instruct (Wang vd. 2023) | ~52.000 talimat | sentetik veri; yalnızca 175 insan yazımı tohum görev |
| Tülu 3 (Lambert vd. 2025) | 939.344 prompt | rekabetçi, açık bir tarif |
Son satır asıl emeği gizliyor. Tülu 3 ekibi 23.327.961 aday prompt topladı ve bunların 939.344’ünü denetimli fine-tuning için tuttu — yirmi dörtte birinin altında — ayrıca 425.145’ini tercih ayarına yönlendirdi (Lambert vd. 2025). Yayımlanan ürün, bir toplama çabası olmaktan çok bir filtreleme kararı.
İlginç satır LIMA. Yazarları 65B’lik bir LLaMA’yı tam olarak 1.000 özenle seçilmiş prompt-cevap çifti üzerinde fine-tune etti — 750’si topluluk soru-cevap sitelerinden (Stack Exchange, wikiHow, Reddit) toplandı, 250’sini yazarlar kendileri yazdı ya da uyarladı — hiç pekiştirmeli öğrenme ve hiç tercih modellemesi olmadan. GPT-4 karşısında insan değerlendiriciler LIMA’nın cevaplarını karşılaştırmaların %43’ünde eşit ya da daha iyi buldu; Bard karşısında %58, RLHF ile eğitilmiş DaVinci003 karşısında %65 (Zhou vd. 2023).
Küçük bir kümenin bu kadar yol alabilmesinin, LIMA’dan önce, 2021’de FLAN çalışmasıyla ortaya konmuş ikinci bir sebebi var: talimat biçiminde yazılmış görevlerden oluşan bir koleksiyon üzerinde fine-tune edilen bir model — instruction tuning (talimat ayarı) denen yöntem — o fine-tuning sırasında hiç görmediği görevlerde de iyileşiyor (Wei vd. 2022). SFT’nin kurduğu şey bir cevap listesi değil, bir talimatı talimat olarak ele alma alışkanlığı.
LIMA yazarları kendi deneylerini açıklamak için Yüzeysel Hizalama Hipotezini öneriyor: bir modelin bilgisinin ve yeteneğinin neredeyse tamamı ön eğitim sırasında ediniliyor ve hizalama esas olarak ona, kullanıcılarla etkileşirken hangi biçim alt dağılımını kullanacağını öğretiyor. Bu doğruysa, bir biçimi belirtmek için bin iyi örnek yetebilir. Hipotez, fine-tuning’in hiç olgu öğretemeyeceği ya da bin örneğin her görev için yeteceği anlamına gelmez; kendi görevinizde ölçmeniz gerekir.
Pratikteki anlamı. Hedef girdilerinizi temsil eden küçük ve temiz bir örnek kümesiyle bir başlangıç koşusu yapın; sonra örnek ekledikçe ayrı bir doğrulama kümesindeki kazancı ölçün. Kaba bir sezgi olarak: küçük kümelerde eklenen örnekler hâlâ biçim kazandırır, büyüdükçe girdilerin çeşitliliğini kapsamaya, daha da büyüdükçe uzun kuyrukta sağlamlığa yarar. Kazanç azaldığında, daha fazla örnek toplamakla etiketleri düzeltmek, nadir durumları kapsamak ve değerlendirmeyi genişletmek arasında seçim yapın; ek bir kalite kontrol saati çoğu zaman ek bir örnekten değerlidir.
LIMA ve Tülu 3, veri seçiminin sonucu etkileyebildiğine iki farklı ölçekten örnek: ikisinde de ayıklama, toplama kadar önemli bir rol oynadı.
9.4 Parametre-verimli fine-tuning
Buraya kadarki her şey, eğitim adımını çalıştırabildiğinizi baştan varsaydı. Model büyüdükçe, elinizde olma ihtimali yüksek tek bir GPU’da tam bir eğitim adımı hızla sığmaz hâle gelir. Sınırı model boyutu kadar optimizer durumu, aktivasyonlar, dizi ve batch uzunluğu ve GPU belleği belirler: aşağıdaki örnek düzende 1B parametre, aktivasyonlardan önce yalnızca parametreyle ilgili durum için yaklaşık 16 GB ister. Sebebin büyük kısmı modelin ağırlıkları değil, onları eğitmenin getirdiği ek durumdur.
9.4.1 Bellek gerçekte nereye gidiyor
Karma hassasiyetli AdamW eğitimi sırasında tek bir parametrenin kaç bayta mal olduğunu yaygın bir örnek düzende sayalım: bf16 hesap ağırlıkları ve gradyanlar, fp32 ana kopya ve iki fp32 Adam momenti. Kullandığınız uygulamanın hangi kopyaları gerçekten tuttuğunu, aktivasyonları ve geçici tamponları ayrıca denetleyin. Başka düzenler de var ve maliyetleri farklı: 8 bitlik optimizer durumları, fp32 kullanmayan birleştirilmiş (fused) şemalar ve parçalanmış optimizer’lar bu tabloyu değiştirir. 16 bir varsayılandır, bir yasa değil.
| ne saklanıyor | parametre başına bayt | neden var |
|---|---|---|
| bf16 ağırlık | 2 | modelin kendisi |
| bf16 gradyan | 2 | eğitilebilir parametre başına bir tane |
| fp32 ana ağırlık | 4 | bf16’nın 7 bitlik mantisi, minik güncellemeleri biriktirmeye yetmiyor |
| fp32 Adam \(m\) | 4 | gradyanın hareketli ortalaması (moving average) |
| fp32 Adam \(v\) | 4 | gradyanın karesinin hareketli ortalaması |
| toplam, eğitilebilir | 16 | |
| toplam, donmuş | 2 | hiç güncellemediğiniz bir ağırlığın yalnızca okunması gerekir |
fp32 ana kopya, en az bariz olan ve insanların ilk silmeye çalıştığı satır. O olmadan, \(1\) büyüklüğündeki bir ağırlığa eklenen \(10^{-5}\) büyüklüğündeki bir güncelleme bf16’da doğrudan \(1\)’e yuvarlanır — fp32 ise onu 1,00001 olarak tutar — ve eğitim sessizce durur. Örneği dikkatli seçin: \(10^{-8}\) fp32’de de kaybolurdu, çünkü tek hassasiyette kabaca yedi ondalık hane vardır. Bu düzende küçük güncellemeleri biriktiren şey fp32 ana kopyadır. Bu, fp32 kopyanın her düşük hassasiyetli eğitimde zorunlu olduğu anlamına gelmez: başka optimizer ve güncelleme düzenleri bu sorunu farklı çözer ve o zaman bellek hesabı da değişir.
İki toplamı birbiriyle karşılaştırın. Bu örnek düzende modelin kendisi parametre faturasının sekizde biri. fp32 satırları — ana kopya ile Adam’ın iki momenti — dörtte üçü, gradyan da kalan sekizde bir. Parametre-verimli fine-tuning’in (PEFT) parametre durumu tarafındaki kazancı bu orandan geliyor: bir parametreyi dondurun, sekiz taksidinin yedisi buharlaşır; geriye yalnızca yine de okumanız gereken bf16 ağırlık kalır. Aktivasyonlar ve hesap ise kalır; bu kazancı toplam GPU belleğine 8 kat olarak taşımayın (laboratuvarda, Bölüm 9.11, ölçülen fark 1,40 kat).
parameter-efficient fine-tuning (parametre-verimli ince ayar) — LoRA’nın ait olduğu aile: ağırlıkların küçük bir kesrini (ya da birkaç yeni ağırlığı) eğitin, gerisini donmuş bırakın. Genelde PEFT diye yazılır. ↩︎
Bu aritmetiği yayımlanmış bir rakamla sınayabilirsiniz. QLoRA, 65B’lik bir LLaMA’yı 16 bitte fine-tune etmenin “780 GB’tan fazla GPU belleği gerektirdiğini” söylüyor (Dettmers vd. 2023). Bu büyüklüğü açıklayan bir örnek hesap:
\[ 65 \times 10^9 \;\text{parametre} \times 12 \;\text{bayt} = 780 \;\text{GB} \]
Parametre başına on iki bayt; yukarıdaki tablodaki on altı baytın büyük kısmı. Makale bellek kalemlerinin dökümünü vermiyor; bu çarpım olası bir ayrıştırma, makalenin kendi dökümü değil. Aşağıdaki iki olası okumada da manşet rakamın büyük kısmı, yalnızca parametre eğitildiği için var olan durum. LoRA makalesinin GPT-3 rakamı da aynı mantıkla okunabilir; iki rakamın ayrıntılı ayrıştırması aşağıdaki kutuda.
NotAyrıntı: 780 GB ve 1,2 TB nasıl ayrıştırılır
Yukarıdaki tabloya göre on iki baytın bir okuması üç fp32 satırıdır: ana ağırlık, \(m\) ve \(v\). 16 baytlık düzende bunlara bf16 ağırlık ile gradyan eklenince yalnızca parametreyle ilgili durum \(65 \times 16 = 1{.}040\) GB eder; aktivasyonlar ve tamponlar bunun üstüne gelir. Bu, “fazla” ifadesiyle tutarlı. İkinci bir okuma da aynı on ikiye tam oturuyor: bf16 ağırlık, bf16 gradyan, fp32 \(m\), fp32 \(v\), ana kopya yok; bu kez “fazla” ifadesini aktivasyonlar dolduruyor.
Yayımlanmış bir bellek rakamını yeniden kurmak, genelde birden fazla çözümü olduğu için öğreticidir. Makaleler kalem kalem dökümü değil toplamı raporlar; dökümü toplamdan yola çıkarak tahmin edersiniz ve hangisini varsaydığınızı da söylemeniz gerekir.
LoRA makalesinin rakamı ters yönde ilerliyor: GPT-3 175B’de eğitim VRAM’i “1,2 TB’tan 350 GB’a” düşüyor (Hu vd. 2022). Bitiş noktası temiz —
\[ 175 \times 10^9 \times 2\;\text{bayt} = 350\;\text{GB} \]
ifadesi donmuş bf16 ağırlıkların ham boyutudur. Başlangıç noktası daha az temiz. 175B parametre üzerinde 1,2 TB, parametre başına yaklaşık 6,9 bayt eder; tablonun öngördüğü 16’nın epey altında. Yani o rakam, makalenin açıkça yazmadığı bir kurulumda ölçülmüş. Onu ya parametre başına daha ucuz bir durum (8 ya da 16 bitlik optimizer momentleri, fp32 ana kopyanın olmaması) ya da durumun bir kısmının GPU dışında tutulması (örneğin CPU’ya aktarma) açıklayabilir; makale hangisi olduğunu söylemiyor. Çok sayıda karta bölme (sharding) ve aktivasyon checkpoint’lemesi (ara kayıt alma) tek başına açıklamaz: bölme aynı baytları daha çok GPU’ya dağıtır, checkpoint’leme ise parametre başına durumu değil aktivasyonları kırpar. 350 GB da donmuş bf16 ağırlıkların ham boyutuna denk geliyor; adaptör ve aktivasyonlar da yer tuttuğundan bu eşitlik makalenin bütün kalemlerini açıklamaz. İki rakamı da onların raporu olarak aktarın; 350 GB’ın neye denk geldiğini yeniden hesaplayabilirsiniz, 1,2 TB’ın dökümünü ise bu iki toplamdan çıkaramazsınız.
9.4.2 Düşük ranklılık hipotezi
Yani ağırlıkları dondurmak istiyoruz. Ama donmuş bir model öğrenmez. Soru şu: ucuz olacak kadar küçük, işe yarayacak kadar da ifade gücü yüksek olan neyi yan tarafa ekleyebilirsiniz?
LoRA’nın cevabı, fine-tuning’in ne yaptığına dair bir varsayımdan başlıyor. Ön eğitimden gelmiş bir ağırlık matrisi \(W_0\), çok çeşitli metinlerden kurulmuş genel amaçlı bir öznitelik haritasıdır. Tek bir görev için gereken değişimin ise çoğu zaman çok daha dar olduğu düşünülebilir. Hipotez (Hu vd. 2022) şu: bu \(\Delta W\) ayarlaması şekil olarak tam bir \(d \times k\) matrisi olsa da, düşük ranklı bir çarpımla yeterince iyi yaklaşıklanabilir — içsel rankı düşüktür. Bu, her görevde ve her katmanda tam fine-tuning farkının gerçekten düşük ranklı olduğunun garantisi değil; LoRA’nın yararlı bulduğu bir kısıt.
Bu doğruysa, onu iki ince matrisin çarpımı olarak yazabilirsiniz:
\[ W_0 + \Delta W = W_0 + BA, \qquad B \in \mathbb{R}^{d \times r},\; A \in \mathbb{R}^{r \times k}, \qquad r \ll \min(d,k) \]
LoRA (düşük ranklı uyarlama) — ön eğitimden gelen bir ağırlık matrisini dondurup, çarpımı ona eklenen küçük bir matris çifti öğrenmek. Çiftin \(dk\) yerine \(r(d+k)\) parametresi vardır. Uyumlu bir sunum düzeninde güncelleme özgün ağırlıkla birleştirilebilir ve ek matris çarpımı ortadan kalkar; birleştirilmemiş ya da nicemlenmiş bir modelin gecikmesini ayrıca ölçün. ↩︎
Bunun ne kazandırdığını sayalım. Llama 3.1 8B’nin \(4096 \times 4096\)’lık query izdüşümlerinden biri için \(\Delta W\)’nin tamamı \(16{.}777{.}216\) parametre taşır. \(r = 8\)’de \(BA\) ise \(8 \times (4096 + 4096) = 65{.}536\) taşıyor — aynı çıktı şekli için 256 kat az.
9.4.3 \(A\) ile \(B\) gerçekte neyi tutuyor
İki matrisin rolü simetrik değil ve asıl anlaşılması gereken de bu asimetri.
Donmuş yol ve eğitilebilir sapak
Sapağı \(x\)’ten \(h\)’ye doğru izleyin: \(A\) girdiyi \(r\) boyutlu bir ara uzaya indirger, \(B\) o \(r\) sayıyı çıktı boyutuna geri taşır. Sezgisel bir okumayla \(A\) girdinin hangi birkaç yönünün kullanılacağını, \(B\) de o yönlerden çıktıya ne yazılacağını belirler. Ama bu hesap akışının yorumu; öğrenilmiş \(A\) ile \(B\)’nin her birine tekil bir anlam yükleyemeyiz, çünkü farklı faktör çiftleri aynı çarpımı verir: tersinir bir \(R\) için \((BR^{-1})(RA) = BA\).
İlkleme seçimi de, başka türlüsünde ne olacağını sorduğunuz an anlam kazanıyor. \(h = W_0x + BAx\) için \(\partial\mathcal{L}/\partial B\), \(Ax\) ile; \(\partial\mathcal{L}/\partial A\) ise \(B\) ile orantılıdır (üstten gelen kayıp gradyanı sıfır değilse):
| \(A\) ilklemesi | \(B\) ilklemesi | ne oluyor |
|---|---|---|
| sıfır | sıfır | \(BA = 0\) ve iki gradyan da sıfır: gradyan inişi çifti sıfırdan çıkaramıyor |
| rastgele | rastgele | 0. adımda \(BA\) genellikle \(\neq 0\), yani eğitim ön eğitimli modeli değiştirerek başlıyor |
| rastgele | sıfır | 0. adımda \(BA = 0\), \(\partial \mathcal{L} / \partial B\) genellikle \(\neq 0\): koşu tam olarak ön eğitimli modelden başlayıp önce \(B\) güncelleniyor |
| sıfır | rastgele | 0. adımda yine \(BA = 0\), \(\partial \mathcal{L} / \partial A\) genellikle \(\neq 0\): bu da sıfırdan kurtuluyor, önce \(A\) güncelleniyor |
Dördünün biri değil, ikisi işe yarıyor. Alttaki iki satırda da uyarlanmış model birebir ön eğitimli modelden başlıyor ve gidecek bir yeri var; çünkü her matrise göre gradyan diğeriyle orantılı — dolayısıyla çiftin yalnızca birinin sıfırdan farklı olması yetiyor. Başlangıç çıktısı için önemli olan çarpım; rastgeleliği hangi çarpanın taşıdığı değil. Eğitim yörüngesi için ise iki seçim aynı olmak zorunda değil: gradyan ve optimizer dinamikleri farklı olabilir.
LoRA üçüncü satırı seçiyor: “\(A\) için rastgele bir Gauss ilklemesi ve \(B\) için sıfır” (Hu vd. 2022). Makale bu seçimi belirtiyor ama onu dördüncü satıra tercih etmek için gerekçe sunmuyor; bu kitap da sunmayacak. \(B = 0\) ilklemesinin kazandırdığı şey, adaptörün 0. adımda ön eğitimli modeli bozmaması: zaten çalışan bir modelden başlarsınız. Rastgele–rastgele ilkleme ise koşuyu ön eğitimli modelden farklı bir noktadan başlatırdı.
9.4.4 Rank ve alfa: neden iki ayar düğmesi var
Güncelleme ham hâliyle eklenmiyor. \(\alpha / r\) ile ölçekleniyor; buradaki \(\alpha\) sizin seçtiğiniz bir sabit (Hu vd. 2022):
\[ h = W_0 x + \frac{\alpha}{r} B A x \]
\(r\)’ye bölmenin belirtilen amacı kuramsal değil, pratik. Yazarlar bu ölçeklemenin “\(r\)’yi değiştirdiğimizde hiperparametreleri yeniden ayarlama ihtiyacını azaltmaya yardım ettiğini” yazıyor (Hu vd. 2022). Amaç, bir rank taramasının aynı anda bir öğrenme oranı taramasına dönüşmesini azaltmak. Bu, farklı ranklarda gradyan büyüklüğünün ya da en iyi öğrenme oranının eşit kalacağı anlamına gelmez (Kalajdzievski (2023), \(1/r\) ölçeklemesinde yüksek rankta gradyanların küçüldüğünü gösteriyor); rank taramasını doğrulama verisiyle yapın.
\(\alpha\) ise adaptör yolunun tamamına uygulanan sabit bir çarpan ve makale onu nasıl gördüğünü söylüyor: “\(\alpha\)’yı ayarlamak kabaca öğrenme oranını ayarlamakla aynı şey” (Hu vd. 2022). Kabaca: \(\alpha\) ileri geçişte adaptörün katkısını ölçekler, öğrenme oranıyla etkileşir ama onunla özdeş değildir; en iyi değeri öğrenme oranı, rank ve hedef modüllerle birlikte değerlendirilmeli. Yaygın \(\alpha = 2r\) geleneği ileri geçişte “adaptörü 2 ile ölçekle” demek.
Üstelik bu gelenek topluluğun, yazarların değil. Yazarlar \(\alpha\)’yı “denediğimiz ilk \(r\)’ye” eşitleyip bir daha dokunmadıklarını bildiriyor; yani onu hiç ayarlamamışlar. Bunun her rankta \(\alpha = r\) demek olmadığına da dikkat edin: ilk denediğiniz \(r = 8\) olduğu için \(\alpha\)’yı 8’de sabitlerseniz, \(r = 16\) artık \(\alpha/r = 0{,}5\) ile koşar. \(\alpha = 2r\)’yi bir sonuç değil, başkasının sizin yerinize seçtiği bir varsayılan olarak görün.
İki düğme, iki soru; ikisini de ölçerek ayarlayın.
- \(r\) adaptörün parametre sayısını ve izin verilen güncelleme rankını belirler: bu uyarlamanın ne kadar kapasiteye ihtiyacı var? Görev ön eğitimdekinden uzaksa (yeni bir dil, yeni bir gösterim) daha yüksek bir rank denemeye değer.
- \(\alpha/r\) adaptörün katkısını ölçekler: adaptör ne kadar sert itmeli?
Yetersiz uyum ya da kendinden emin saçmalık yalnızca rank ya da alfadan değil; veriden, öğrenme oranından, epoch sayısından ve hedef modüllerden de gelebilir. Sabit veri ve öğrenme oranıyla küçük bir rank/ölçek ızgarası deneyin ve sonuçları hem görev başarısıyla hem başlangıç modeline göre gerilemeyle değerlendirin. \(\alpha = 2r\) ikisini birlikte hareket ettirdiği için sık sık karıştırılıyorlar; tarama yaparken geleneği bozun.
9.4.5 Bir adaptörün aritmetiği
\(d_{\text{giriş}} \times d_{\text{çıkış}}\) boyutlu bir matris üzerindeki bir LoRA adaptörü tam olarak \(r(d_{\text{giriş}} + d_{\text{çıkış}})\) adaptör parametresi ekler. Gerisi hesap kitap işi: hangi matrislere bağladığınız ve kaç katman olduğu. Toplam eğitilebilir sayıya ayrıca açık bırakılan bias’lar, sınıflandırma head’i ya da başka modüller de girebilir; aşağıdaki tablo yalnızca adaptörleri sayıyor (laboratuvar tablosu head’i de ekliyor).
Aşağıdaki üç yapılandırma her modelin kendi config.json’ından hesaplandı (her satırı yeniden hesapladık):
| model | hedefler | \(r\) | eğitilebilir | modele oranı |
|---|---|---|---|---|
| BERTurk base (110,6M, 12 katman) | query, value | 8 | 294.912 | %0,267 |
| + key, output | 8 | 589.824 | %0,533 | |
| + MLP | 8 | 1.327.104 | %1,200 | |
| Llama 3.1 8B (32 katman, \(d\)=4096) | q_proj, v_proj | 8 | 3.407.872 | %0,042 |
| bütün attention katmanları | 8 | 6.815.744 | %0,085 | |
| attention + MLP | 8 | 20.971.520 | %0,261 | |
| Qwen 2.5 7B (28 katman, \(d\)=3584) | q_proj, v_proj | 8 | 2.523.136 | %0,033 |
| attention + MLP | 8 | 20.185.088 | %0,265 |
LoRA, parametre-verimli tek yöntem değil; bugün en yaygın olanlardan biri. Prompt tuning (Lester vd. 2021) girdinin başına eklenen bir avuç sanal token’ın temsillerini eğitiyor ve temel modelin ağırlıklarına dokunmuyor; yazarların deneylerinde model büyüdükçe tam fine-tuning ile rekabet edebilir hâle geliyor. Yöntemlerin bellek, kalite ve gecikme dengesi model boyutuna ve göreve göre değişir.
Qwen’in q_proj, v_proj adaptörleri Llama’nın 3,41M’ine karşılık 2,52M ediyor; bunu grouped-query attention’a (GQA; Bölüm 7.6) yormak cazip — Qwen 2.5 7B, Llama’nın 8’ine karşılık 4 key-value head kullanıyor ve bu v_proj’u \(4096 \times 1024\) yerine \(3584 \times 512\)’lik bir matris yapıyor. Qwen’e 8 KV head verin, sayı 2,64M’ye çıkıyor; yani GQA, 884.736 parametrelik farkın yalnızca yaklaşık %13’ünü açıklıyor. Gerisi 4096’ya karşı \(d = 3584\) ve 32’ye karşı 28 katmandan geliyor.
İki şey ortaya çıkıyor. Birincisi, MLP matrislerini attention adaptörüne eklemek tablodaki en büyük sıçrama: BERTurk’te 2,25×, Llama’da 3,08× (yalnızca q_proj, v_proj’a göre BERTurk’te 4,5×, Llama’da 6,2×, Qwen’de 8,0×). Bu artış hedef matrislerin sayısından ve boyutundan geliyor; ayrıca MLP bu modellerde ağırlıkların büyük bir kısmını tutuyor (hesapladığımız kadarıyla Llama 3.1 8B’de ~%70, Qwen 2.5 7B’de ~%75, BERTurk’te ~%51). İkincisi, buradaki en cömert ayar bile 8B’lik bir modelin %0,3’ünün altında. \(r\)’nin 1’den 128’e çıkması aynı hedeflerde adaptör sayısını 128 kat artırır — kalite kazancının aynı oranda artması beklenmez — ama bu aralığın tepesi bile modelin yüzde birinin epey altında kalıyor:
| \(r\) | 1 | 4 | 8 | 16 | 32 | 64 | 128 |
|---|---|---|---|---|---|---|---|
| eğitilebilir (yalnızca q,v) | 425.984 | 1,70M | 3,41M | 6,82M | 13,6M | 27,3M | 54,5M |
| Llama 3.1 8B’ye oranı | %0,005 | %0,021 | %0,042 | %0,085 | %0,170 | %0,340 | %0,679 |
\(r = 128\)’de bile modelin yüzde birinin üçte ikisini eğitiyorsunuz.
9.4.6 Kendi koşunuzu hesaplayın
Yukarıdaki aritmetik tek bir yapılandırma için. Sizinki farklı olacak ve sayılar, sezginin yetişebileceğinden hızlı değişiyor. Bu yüzden pratik bir kurala güvenmek yerine kendi model boyunuzu ve rankınızı girin. Araç, seçtiğiniz parametre sayısı ve saklama düzeni için ağırlık, gradyan ve optimizer durumunun yaklaşık alt toplamını verir; gereken GPU belleği aktivasyonlara, dizi ve batch uzunluğuna, geçici tamponlara ve uygulamaya da bağlıdır. Sonucu bir sığma garantisi olarak kullanmayın.
Varsayılanlar, attention ve MLP katmanları üzerinde \(r{=}16\) adaptörü olan Llama 3.1 8B (8,03B parametre) — 41.943.040 parametre, yani modelin %0,52’si. Aracın yalnızca statik durum hesabı: tam fine-tuning 119,7 GiB, yaygın 24–80 GB’lık tek GPU yapılandırmalarının tamamının ötesinde; bf16 tabanlı LoRA 15,5 GiB; 4 bit ham tabanlı QLoRA 4,3 GiB. Bu sayılara aktivasyonlar, geçici tamponlar ve QLoRA’nın ölçek bilgisi eklenmeden belirli bir karta sığacakları söylenemez; aşağıdaki uyarı bunun neden önemli olduğunu gösteriyor.
Bu aracın dışarıda bıraktığı şey sizi şaşırtacak olan kısım. Ağırlıkları, gradyanları ve optimizer durumunu sayıyor; çünkü LoRA’nın ortadan kaldırdığı şeyler bunlar. Aktivasyonları saymıyor ve optimizer gittikten sonra geriye kalan da onlar. QLoRA’nın yazarları bunu ölçmüş: batch boyu 1 olan 7B’lik bir LLaMA’da, “özgün model ağırlıklarının yaygın kullanılan %0,2’si” büyüklüğünde bir adaptörle, LoRA girdi gradyanları 567 MB yer kaplarken LoRA parametreleri 26 MB kaplıyor; gradyan checkpoint’lemesiyle ilk kalem dizi başına ortalama 18 MB’a iniyor (Dettmers vd. 2023). Bu örnekte LoRA girdi gradyanları, eğittiğiniz adaptörün yaklaşık yirmi iki katı yer tutuyor. Bu değerler o modele, batch boyuna ve dizi uzunluğuna ait; başka bir kuruluma taşınmaz.
Gradyan checkpoint’lemesinin yaygın LoRA tariflerinde yer almasının ve bu aracın sayılarının bir kestirim değil bir alt toplam olmasının sebebi bu. Kart seçmeden önce hedef kurulumda kısa bir pilot koşu yapıp tepe belleği ölçün. Bölümün sonundaki labın, buradaki aritmetiğin öngördüğünden çok daha az çarpıcı bir oran ölçmesinin sebebi de aynı.
9.4.7 QLoRA: eğitmediğiniz kısmı nicemleyin
Son adım için bir fikir daha gerekiyor. Yukarıdaki LoRA satırında 15,5 GiB’lık statik alt toplamın neredeyse tamamı artık donmuş bf16 taban — adaptörün optimizer durumu bir yuvarlama hatası. Öyleyse tabanı sıkıştıralım.
QLoRA (Dettmers vd. 2023) bunu yapıyor: donmuş ağırlıkları NF4 adlı 4 bitlik bir formatta saklıyor ve her bloğu yalnızca ileri ve geri geçişte gerektiği anda bf16’ya geri açıyor. Üç parça işi yürütüyor:
- 4 bit NormalFloat, 16 seviyesi normal dağılımın kantillerine (quantile) yerleştirilmiş bir veri tipi — eğitilmiş ağ ağırlıkları normale yakın dağıldığı için seçilmiş, böylece seviyeler ağırlıkların gerçekten bulunduğu yere denk geliyor;
- çift nicemleme (double quantization), blok başına ölçekleme sabitlerinin kendisini de nicemler; çünkü blok boyu küçüldükçe bu sabitler toplamın azımsanmayacak bir payını tutmaya başlar;
- paged optimizer’lar (sayfalanmış optimizer’lar), desteklenen birleşik bellek düzeninde, bellek kullanımı sıçramaları (memory spikes) sırasında optimizer durumunun CPU belleğine taşmasına izin vererek bu sıçramaların bir kısmını yönetir; kazancı ve hız bedeli uygulamaya göre ölçülmelidir.
Öne çıkan sonuç: 65B’lik bir modeli fine-tune etmek için gereken bellek, “16 bitlik, tamamen fine-tune edilmiş bir baseline’a (karşılaştırma koşusu) kıyasla çalışma süresini ya da tahmin başarımını düşürmeden >780 GB GPU belleğinden <48 GB’a” iniyor (Dettmers vd. 2023); bu, makalenin kendi görev karşılaştırmaları için bildirilen bir sonuç. Yazarların bu şekilde, tek bir GPU’da 24 saatte eğittiği Guanaco 65B, 80 soruluk Vicuna benchmark’ında ChatGPT’nin skorunun %99,3’üne ulaştı; bu puanları insanlar değil, hakem olarak GPT-4 verdi ve bu oran genel bir doğruluk ya da insan tercihi ölçüsü değil (LLM hakemliğinin sınırları için bkz. Bölüm 22.4).
“Düşürmeden” iddiası tam fine-tuning’e göre; düz LoRA’ya göre değil. Makale çalışma süresini de düşürmediğini söylüyor, ama kıyası 16 bitlik tam fine-tuning’le yapıyor. Düz LoRA’yla kıyaslandığında her ileri ve geri geçişte blokları geri açmak ek hesaplama getirir; öte yandan daha düşük bellek kullanımı bazı kurulumlarda başka darboğazları hafifletebilir. QLoRA size küçük bir kartta hiç olmazsa çalışabilme imkânı verir; düz LoRA’nın zaten sığdığı bir kartta adım süresini iki yöntemle aynı donanım ve batch üzerinde ölçün.
9.4.8 Nöbet tutmaya başlayınca fark edilen avantaj
LoRA’nın, bir şirket içinde eğitim tasarrufundan çok daha önemli olan operasyonel bir özelliği var: adaptör taban ağırlıklara geri kaynaştırılabilir. \(h = W_0x + \frac{\alpha}{r}BAx = (W_0 + \frac{\alpha}{r}BA)x\) olduğuna göre bu toplamı uygun bir doğrusal katmanda bir kez hesaplayıp sıradan bir model yayına alabilirsiniz; ayrı adaptör çarpımının yükü ortadan kalkar — makalenin deyişiyle “ek çıkarım gecikmesi yok” (Hu vd. 2022). Gerçek gecikme yine de sunum yığınına, hassasiyete ve nicemlemeye bağlıdır; ölçün. Fazladan katman ekleyen darboğaz (bottleneck) adaptörlerine (Houlsby vd. 2019) göre önemli bir avantaj bu.
Ya da hiç kaynaştırmadan tabanı bellekte paylaşımlı tutabilir, adaptörleri istek başına takıp çıkarabilirsiniz:
| kiracı (tenant) | tek paylaşımlı taban + adaptörler | her birine ayrı bir 8B kopya | oran |
|---|---|---|---|
| 10 | 15,7 GiB | 149,6 GiB | 9,5× |
| 100 | 22,8 GiB | 1.495,7 GiB | 65,7× |
| 1.000 | 93,1 GiB | 14.957,0 GiB | 160,7× |
Bu satırların varsaydığı adaptör boyu, attention ve MLP üzerinde \(r{=}16\)’lık, bf16 kaydedilmiş bir adaptör: \(41{.}943{.}040 \times 2\) bayt, tam olarak 80 MiB. İki tercihten birini değiştirin, rakam epey oynar — aynı rankta yalnızca q_proj, v_proj 6,82M parametre, 13 MiB eder; peft ise aynı adaptörü seve seve fp32 kaydedip beklediğiniz her şeyi ikiye katlar. Bir adaptör boyu söylerken hedef modülleri ve dtype’ı da mutlaka söyleyin; rank tek başına neredeyse hiçbir şey anlatmaz.
Cömert uçta bile, bin müşterinin kendi fine-tune edilmiş modelinin ağırlıkları — bir bf16 taban ve bin adaptör — 93,1 GiB’a sığıyor. Bu bir ağırlık depolama hesabı; bin kiracıya tek düğümde istenen eşzamanlılık ve gecikmeyle hizmet verilebileceğini göstermez: KV önbelleği, adaptör yükleme, çalışma alanı ve trafik ayrıca hesaplanmalı. Yine de fine-tuning’in bir araştırma tekniği olmanın ötesinde bir ürün olabilmesinin sebeplerinden biri bu — ve makalenin 2021’de GPT-3 için aynı noktaya işaret ettiğini görmek de ilginç: 100 ayrı kopya 35 TB tutarken 100 uyarlanmış model 350 GB + 35 MB × 100 ≈ 354 GB tutuyor (Hu vd. 2022).
9.5 Tercih ve ödül optimizasyonu
9.5.1 Denetimli fine-tuning’in yapamadığı şey
Tek bir doğru cevabı olmayan bir soru alın:
Kredi kartı borcumu nasıl kapatabilirim?Tek bir zorunlu cevap yok. Kabul edilebilir bin tane cevap var ve bunlar tanıyabildiğiniz ama kurala dökmesi zor eksenlerde farklılaşıyor: fazla sert, fazla uzun, sizin mali durumunuz hakkında fazla kendinden emin, vermeyi reddetmesi gereken bir tavsiyeyi veriyor, doğru ama broşür gibi okunuyor. Yine de seçilmiş, güvenli ve yararlı bir cevap SFT hedefi olarak yazılabilir. Asıl ayrım elinizdeki denetimin türünde: kabul edilebilir cevap örnekleri yazabiliyorsanız SFT uygundur; iki adayın göreli niteliğini daha güvenilir değerlendirebiliyorsanız tercih çiftleri ek bir sinyal sağlar.
Yine de yapabileceğiniz bir şey var: iki aday cevabı bir insana gösterip hangisinin daha iyi olduğunu sormak. Çıkan şey bir tercih çifti (preference pair). Bazı görevlerde böyle bir çift üretmek ideal cevabı yazmaktan daha kolay bir yargıdır ve iki cevaptan hiçbirini kendisi yazamayacak insanlardan toplanabilir; ama etiketçilere açık ölçütler, gerektiğinde uzmanlık ve uyuşmazlık denetimi gerekir.
preference pair (tercih çifti) — bir prompt, iki aday cevap ve hangisinin tercih edildiğini söyleyen bir etiket. İkili tercih tek başına cevapların mutlak yeterliliğini ölçmez; ikisi de yetersiz olabilir. ↩︎
Tercih optimizasyonu, iki adayın göreli sırasını doğrudan bir eğitim sinyaline dönüştürür (Christiano vd. 2017). Seçilen cevaplar SFT için de kullanılabilir; fark, karşılaştırmanın ve reddedilen cevabın bilgisinin kayba nasıl girdiğinde.
9.5.2 RLHF: dört modelli dans
Özgün reçete, yani insan geri bildiriminden pekiştirmeli öğrenme (RLHF) (Stiennon vd. 2020; Ouyang vd. 2022), bu karşılaştırmaları iki adımda bir eğitim sinyaline dönüştürüyor: önce tercihler üzerinde bir ödül modeli (reward model) eğitiliyor, sonra dil modeli ona karşı optimize ediliyor.
Buradan itibaren pekiştirmeli öğrenmeden iki kelime karşımıza çıkacak. Policy (politika; bu bölümde İngilizce adıyla kullanıyoruz), eğitilen modelin ta kendisi; bir prompt verildiğinde olası cevaplar üzerinde (token token) bir olasılık dağılımı tanımlayan model olarak görülüyor. KL ıraksaması \(\mathbb{D}_{\text{KL}}[\pi \,\|\, \pi_{\text{ref}}]\) ise bir olasılık dağılımının diğerinden ne kadar uzaklaştığını ölçer: iki dağılım aynıysa sıfırdır, ayrıştıkça büyür. Burada policy’nin cevap dağılımını donmuş referansınkiyle karşılaştırıyor; eğitim hedefinde bu uzaklık promptlar üzerinde ortalanıyor.
reward model (ödül modeli) — insan karşılaştırmaları üzerinde eğitilmiş, bir prompt ile bir cevabı okuyup tek bir sayı döndüren model. A, B’den iyidir’i bir optimizer’ın maksimize edebileceği bir şeye çevirmek için vardır. ↩︎
RLHF ve hesaba katılması gereken bileşenler
Buradaki ilginç nesne ödül modeli: bir sıralamayı — A, B’yi yendi — bir skalere çeviriyor ve pekiştirmeli öğrenme algoritmasının ihtiyaç duyduğu şey de bu. Şema, InstructGPT türü PPO tabanlı RLHF’in dört işlevini gösteriyor: güncellenen policy, donmuş referans, ödül modeli ve avantaj kestirimi için değer bileşeni. Bunların ayrı ağlar olması ya da aynı anda tek bir GPU’da tutulması zorunlu değil (değer kestiricisi gövdeyi paylaşabilir, bileşenler farklı cihazlara dağıtılabilir); bellek maliyeti uygulamaya bağlı. Ortadaki pekiştirmeli öğrenme algoritması PPO (Schulman vd. 2017), policy’yi güncellemek için kullanılan yöntemlerden biri.
Sonuç küçük bir fark değildi. Bu süreçten geçirilen InstructGPT’nin 1,3B’lik modelinin çıktılarını insan etiketleyiciler, incelenen promptlarda 175B’lik GPT-3’ünkilere tercih etti — “100 kat daha az parametresi olmasına rağmen” (Ouyang vd. 2022). Bu, belirli bir cevap tercihi; genel bir yetenek üstünlüğü değil. Maliyet tarafında ayrı bir rakam var ve o, çalışmanın 175B sürümüne ait: 175B SFT modelini eğitmek 4,9 petaflop/s-gün, 175B PPO-ptx modelini eğitmek 60 petaflop/s-gün gerektirdi; “GPT-3 için 3.640 petaflop/s-güne kıyasla” (Ouyang vd. 2022). Bildirilen SFT ve PPO-ptx maliyetlerinin toplamı, ön eğitim maliyetinin yaklaşık %1,8’i; ödül modelinin eğitimi bu toplama dâhil değil.
Bu karşılaştırma, bu bölümde eğitim sonrasını ciddiye almak için verilebilecek en güçlü argümanlardan biri. Aynı zamanda, parametre sayısının tek başına bir modelin ne yapabileceğini söylediğine inanmamak için de iyi bir argüman.
9.5.3 DPO: kestirmeyi türetip çıkarmak
Şemaya tekrar bakın ve hangi kutunun vazgeçilmez bir iş yaptığını sorun. Ödül modeli yalnızca PPO sırasında örnekleri puanlamak için var. Policy’nin olasılıkları, referansa göre log-oranı olarak bir ödül gibi okunabilseydi, o kutuyu ayrıca eğitmek gerekmezdi.
KL ile düzenlenmiş tercih hedefinde okunabiliyor. Bu, direct preference optimization (doğrudan tercih optimizasyonu) sonucu (Rafailov vd. 2023): ödülü policy ile referansın log-olasılık oranı üzerinden yeniden ifade ediyor, böylece tercih çiftleriyle ayrı bir ödül ağı ve PPO örnekleme döngüsü olmadan eğitim yapılabiliyor. İnsan tercihi verisi ya da ödül modelleme varsayımı ortadan kalkmıyor. Türetimi anlatacağız; çünkü kısa, üstelik onu bilmeden bakınca sonuç akıl almaz görünüyor.
direct preference optimization (doğrudan tercih optimizasyonu) — tercih çiftleri üzerinde, KL ile düzenlenmiş ödül hedefinin yeniden parametrelenmesinden türetilen bir kayıpla policy’yi eğitmek. Ayrı bir ödül ağı ya da eğitim içi örnekleme gerektirmez; başarısı yöntemin varsayımlarına ve veri uyumuna bağlıdır. Genelde DPO yazılır. ↩︎
Kestirmeye geçmeden önce, onun etrafından dolandığı iki hedefe bakalım; çünkü aşağıdaki türetim ikisine de yaslanıyor. Birincisi, ödül modeli karşılaştırmalar üzerinde Bradley–Terry olabilirliğiyle eğitiliyor — bir insanın \(y_w\)’yi \(y_l\)’ye \(\sigma(r(x,y_w) - r(x,y_l))\) olasılığıyla tercih ettiği varsayımı. Burada \(y_w\) tercih edilen (kazanan), \(y_l\) reddedilen (kaybeden) cevap, \(\sigma\) de lojistik fonksiyon. Satrançtaki Elo puanlarını biliyorsanız bu, aynı model: kimin kazanmasının beklendiğine yalnızca iki puan arasındaki fark karar verir.
\[ \mathcal{L}_{\text{RM}} = -\,\mathbb{E}_{(x, y_w, y_l)}\left[\log \sigma\!\left(r_\phi(x, y_w) - r_\phi(x, y_l)\right)\right] \]
Bradley–Terry yalnızca farklara baktığı için, aynı prompt’un bütün cevaplarına aynı \(f(x)\) sabitini eklemek hiçbir şeyi değiştirmez. Birazdan \(Z(x)\) teriminin sadeleşmesini sağlayacak olan da bu.
Bu serbestlik yalnızca toplamsal: ödüller, \(x\)’e bağlı bir sabit dışında tek türlü belirli, ama ölçekleri keyfî değil. Bağlantı (link) fonksiyonunun sıcaklığını da buna göre yeniden ölçeklemediğiniz sürece, bütün ödülleri iki ile çarpmak modeli değiştirir: \(\sigma(1) = 0{,}731\)’e karşı \(\sigma(2) = 0{,}881\).
İkincisi, policy o donmuş ödüle karşı optimize ediliyor; referans modelden uzaklaştıkça da cezalandırılıyor:
\[ \max_{\pi_\theta}\; \mathbb{E}_{x \sim \mathcal{D}}\Big[\mathbb{E}_{y \sim \pi_\theta(\cdot \mid x)}\big[r_\phi(x, y)\big] \;-\; \beta\, \mathbb{D}_{\text{KL}}\!\left[\pi_\theta(\cdot \mid x) \,\|\, \pi_{\text{ref}}(\cdot \mid x)\right]\Big] \]
\(\beta\) sayısı tasmanın gücüdür. Büyük bir \(\beta\) policy’yi referansa yakın tutar ve ödülün bir kısmından vazgeçer; küçük bir \(\beta\) ise ödülün peşinden daha uzağa gitmesine izin verir — öğrenilmiş bir ödül modeliyle de ödül istismarına (reward hacking) daha çok yaklaşır.
PPO, bu hedef üzerinde adım atmanın bir yolu: tek bir batch’in policy’yi uzağa taşıyamaması için kırpılmış bir vekil hedefi maksimize ediyor (Schulman vd. 2017). O kırpma aralığı, aşağıdaki tablonun PPO’nun hesabına yazdığı hiperparametrelerden biri.
O hedefin — ödülü maksimize et, ama referanstan KL ıraksaması kadar ceza al — bilinen bir kapalı form optimumu var:
\[ \pi^{*}(y \mid x) = \frac{1}{Z(x)} \, \pi_{\text{ref}}(y \mid x) \, \exp\!\left( \frac{1}{\beta} r(x, y) \right) \]
\(r\) için düzenleyin:
\[ r(x, y) = \beta \log \frac{\pi^{*}(y \mid x)}{\pi_{\text{ref}}(y \mid x)} + \beta \log Z(x) \]
Bu türetimde ödül, policy ile referansın log-oranı olarak, yalnızca prompt’a bağlı bir terim dışında temsil edilir. Öğrenilmiş ödül modellerinin gereksiz olduğu anlamına gelmez; bu varsayımlar altında, tercih çiftleriyle ayrı bir ödül modeli eğitmeden policy’nin güncellenebileceği anlamına gelir. Ve o baş belası \(Z(x)\) — mümkün her cevap üzerinden bir toplam, kimsenin hesaplamamasının sebebi de bu — yalnızca prompt’a bağlı; yani aynı prompt’a verilen iki cevabı karşılaştırdığınız anda sadeleşiyor. Tercih verisinin size verdiği şey de tam olarak bu.
Bunu ikili tercihin Bradley–Terry modeline yerleştirince geriye, tercih çiftleri \((x, y_w, y_l)\) üzerinde sıradan bir denetimli kayıp kalıyor:
\[ \mathcal{L}_{\text{DPO}} = -\,\mathbb{E}\left[ \log \sigma\!\left( \beta \log \frac{\pi_\theta(y_w \mid x)}{\pi_{\text{ref}}(y_w \mid x)} - \beta \log \frac{\pi_\theta(y_l \mid x)}{\pi_{\text{ref}}(y_l \mid x)} \right) \right] \]
Kelimelerle okuyun, korkutuculuğu kalmaz: tercih edilen cevabın referansa göre log-olasılık oranını, reddedilenin oranından daha büyük hâle getirin; böylece referansla aynı fikirde olduğunuz için değil, doğru yönde hareket ettiğiniz için ödüllendirilirsiniz. Kayıp, tek tek olasılıkların hangi yöne gideceğini belirlemez.
“Yükseltin” ve “düşürün” konusunda bir incelik. Kayıp yalnızca iki log-oran arasındaki farkın açılmasını ister. Pratikte DPO sırasında iki olasılık da çoğu zaman düşer, reddedilenin olasılığı daha hızlı; yani kayıp iyileşirken tercih edilen cevabın kendi olabilirliği azalıyorsa şaşırmayın.
\(\pi_{\text{ref}}\)’in ne iş yaptığına dikkat edin, çünkü ileride karşılaşacağınız “temel modele DPO uygulamaktan kaçının” önerisinin sebebi o.
DPO’nun kurulumu, tercih çiftlerinin referanstan örneklendiğini varsayıyor; bu yüzden makale, ortada bir SFT modeli olduğu her durumda \(\pi_{\text{ref}} = \pi_{\text{SFT}}\) alıyor. SFT modeli yoksa önce tercih edilen tamamlamalar üzerinde fine-tune edip onu kullanmayı öneriyor. Gerekçesi açık: “erişilemeyen gerçek referans dağılımı ile DPO’nun kullandığı \(\pi_{\text{ref}}\) arasındaki dağılım kaymasını hafifletmek için” (Rafailov vd. 2023).
Böylece olası bir başarısızlığın kaynağı da belli oluyor. Kayıp hiçbir zaman örnekleme yapmaz; tercih çiftleri talimat izleyen bir modelden geliyorsa, temel model zayıf bir referanstır ve sorun “sıralayamamak” değil, referans ile veri arasındaki uyumsuzluktur. Temel model üzerinde DPO matematiksel olarak tanımlı; başarısını veri kapsamı, referans seçimi ve görev değerlendirmesi belirler.
DPO’nun kaldırmadığı. Güvenilir tercih etiketleri ve bunların kapsamını değerlendirmek hâlâ gerekir; etiketleme insanla, bir modelle ya da bir doğrulayıcıyla yapılabilir ve maliyeti yönteme bağlıdır. DPO algoritmayı ucuzlatır, veriyi değil. Ayrıca daha ince bir sorunu da miras alır: çiftler tek seferde ve başka bir modelin çıktılarından toplandıysa, policy’niz onları üreten şeyden uzaklaştıkça temsil güçleri azalabilir. Tülu 3 çalışmasında on-policy tercih verisi — eğitilen modelin kendisinin ürettiği veri — yeniden kullanılan off-policy çiftlere kıyasla görev sonuçlarını iyileştirdi (Lambert vd. 2025); aynı kazancı her derlem için varsaymayın.
9.5.4 GRPO: bunun yerine değer modelini silin
DPO ödül modelini siliyor. GRPO (Shao vd. 2024) öteki yolu tutuyor: pekiştirmeli öğrenmeyi koru, ama değer modelini (value model) sil.
Değer modeli, bir baseline (beklenen ödülün tahmini) sağlamak için var. Policy gradyanı (policy-gradient) yöntemlerinde ham ödülü istemezsiniz — bir eylemin beklenenden iyi olup olmadığını bilmek istersiniz; çünkü 8’lik bir ödül, olağan skorunuz 2 iken başka bir şey, 9 iken başka bir şey ifade eder. Bu beklentiyi tahmin eden bir kestirici eğitmek standart çözümdür ve maliyetlidir: ayrı bir model ya da policy ile gövde paylaşan bir head olabilir; bellek maliyeti eğitim düzenine göre değişir.
GRPO’nun gözlemi şu: nasıl olsa policy’den örnekleme yapacaksanız, baseline’ı ayrı bir değer kestiricisi eğitmeden de elde edebilirsiniz — ama aynı prompt için birden çok cevap üretip puanlamanın kendi hesap maliyeti var. Aynı prompt’a \(G\) tane cevap örnekleyin, hepsini puanlayın ve beklenti olarak grubun kendi ortalamasını kullanın:
\[ A_i = \frac{r_i - \operatorname{mean}(r_1, \ldots, r_G)}{\operatorname{std}(r_1, \ldots, r_G)} \]
\(A_i\)’ye \(i\). cevabın avantajı (advantage) denir: pozitifse “bu grubun ortalamasından iyi” demektir ve güncelleme o cevabı daha olası kılar; negatifse daha az olası kılar. Standart sapmaya bölmek her prompt’u aynı ölçeğe getirir; böylece kolay ve zor prompt’lar benzer güçte çeker. Akılda tutulacak bir sonuç: \(G\) cevabın hepsi aynı ödülü alırsa — hepsi doğru ya da hepsi yanlış — bütün \(A_i\)’ler sıfır olur (uygulamalar sıfıra bölmemek için paydaya çok küçük bir sabit ekler ya da grubu atlar) ve o prompt’tan ödül karşılaştırmasına dayalı bir sinyal gelmez; KL gibi diğer terimler yine etkili olabilir.
Soru artık bu cevap mutlak olarak ne kadar iyi değil, bu deneme aynı soruya yaptığım diğer denemelerden iyi miydi oluyor; ayrı bir değer modeli gerektirmeyen göreli bir sinyal. Bu sinyalin kararlılığı \(G\)’ye, ödül dağılımına ve normalleştirmeye bağlı; küçük bir \(G\) yüksek varyans getirebilir. GRPO donmuş referansı ve KL tasmasını yine de tutar; ayrıca yine bir ödüle ihtiyaç duyar — bir ödül modeline ya da, hemen aşağıda göreceğimiz gibi, bir doğrulayıcıya. Makalenin deyişiyle (critic, değer modelinin öbür adı) GRPO “critic modelden vazgeçer, bunun yerine baseline’ı grup skorlarından kestirir ve eğitim kaynaklarını belirgin biçimde azaltır” (Shao vd. 2024). DeepSeekMath-Instruct 7B üzerinde, yalnızca elde zaten bulunan instruction tuning verisini kullanarak GSM8K’yı %82,9’dan %88,2’ye, MATH’i %46,8’den %51,7’ye taşıdı; bu kazanç o kurulumun sonucu ve yalnızca grup ortalamasına bağlanamaz.
9.5.5 Ödül nereden geliyor ve asıl soru neden bu
Bir hamle daha var; alanı yakın zamanda en çok etkileyenlerden biri de o. Yukarıdaki yöntemlerin çoğu, ödülün insan karşılaştırmalarından öğrenildiğini varsayıyordu. Dolayısıyla ödül, öğrenilmiş bir modelin bütün kusurlarını miras alıyordu; kandırılabilir olmak da buna dâhil.
Bazı görevlerde ödülü öğrenmeye gerek yok. Cevap bir sayıysa sayıyı kontrol edin. Kodsa testleri çalıştırın. DeepSeek-R1-Zero — denetimli bir ısınma olmadan, doğrudan pekiştirmeli öğrenmeyle eğitilen varyant — iki türlü “kural tabanlı ödül” kullanıyor: matematik ve kod gibi görevlerde nihai cevabın doğruluğunu değerlendiren ödüller (cevabın denetlenebilmesi için belirtilen bir biçimde verilmesi isteniyor) ve akıl yürütmenin istendiği yere konup konmadığını denetleyen format ödülleri (Guo vd. 2025). Tülu 3 aynı fikri RLVR — doğrulanabilir ödüllerle pekiştirmeli öğrenme — adıyla açık bir reçeteye dönüştürüyor (Lambert vd. 2025).
En keskin kısıt da bu. Doğrulanabilir ödüller bir doğrulayıcı ister ve insanların bir dil modelinden istediği şeylerin çoğunun — bu özet sadık mıydı, bu ton uygun muydu, bu reddediş doğru muydu — doğrulayıcısı yoktur. Matematik ve kod alışılmadık ölçüde şanslı alanlar. Bölüm 10 bu fikri sonuna kadar zorlarsanız ne olduğunu izliyor.
Ödünleşim (trade-off) kabaca şöyle: öğrenilmiş bir ödül modeli açık uçlu nitelikleri yaklaşık olarak değerlendirebilir, ama etiketlerin kapsamıyla sınırlıdır ve istismar edilebilir; bir kural tabanlı doğrulayıcı, doğruluğu belirli bir ölçütle sınanabilen dar bir görev kümesinde güçlü bir sinyal verir ve kandırılması genellikle daha zordur — ama ancak şartnamesi ve uygulaması ne kadar sağlamsa o kadar. Boşlukları olan bir test paketi, görünen vakalar için sabit cevap döndüren bir programı ödüllendirir; gevşek bir cevap ayrıştırıcısı, regex’ine uyan her şeyi ödüllendirir (Bölüm 10 bunun pratikte canı yakan hâlini içeriyor). İki tür ödül farklı biçimlerde çuvalladığı için birçok reçete ikisini birden, verinin farklı alt kümelerinde kullanıyor; hangisinin kullanılacağını görevin doğrulanabilir kısmı ve hedeflenen davranış belirler.
9.5.6 Elinizdeki veriye göre seçmek
Kısaltmaları bir kenara bırakın; yukarıdaki her yöntem, neyi toplayabildiğinize dair bir iddiadan ibaret.
| elinizde | denenebilecek yöntem | size maliyeti, ayrıca gereken |
|---|---|---|
| ideal cevapları yazılmış prompt’lar | SFT | cevapları yazmak; görev değerlendirmesi |
| “hangisi daha iyi” etiketli cevap çiftleri (insan, model ya da doğrulayıcı etiketi) | DPO | etiketleme; uyumlu bir referans ve etiket kapsamı |
| bir tercih/ödül sinyali ve çevrimiçi RL bütçesi | RLHF/PPO | üretim döngüsü, ödül ve değer hesabı; ayarlaması zor |
| cevapları puanlanabilen prompt’lar | GRPO (çoğu zaman doğrulanabilir ödüllerle) | bir ödül işlevi ve bol örnekleme |
| kullanmanıza izin verilen daha güçlü bir model | damıtma (Bölüm 9.7) | çıkarım faturaları, lisans ve kalite ölçümü |
Bir-iki kişilik bir ekip için deneme sırası. Önce prompt, çıktı şeması ve gerekiyorsa erişimle bir başlangıç ölçümü kurun (Bölüm 9.9). Davranış örnekleriniz varsa SFT’yi deneyin. DPO’yu, SFT modelinin davranışına dair çiftler hâlinde ifade edebileceğiniz belirli bir şikâyetiniz olduğunda karşılaştırın — “bunu reddetmeliydi”, “daha kısa olmalıydı”. Bir RL döngüsü ancak ek üretim ve ödül değerlendirme hesabı karşılığında hedef göreve ölçülebilir katkı veriyorsa gündeme gelsin; ödül bir doğrulayıcıdan ya da denetlenmiş bir ödül modelinden gelebilir, ama ikincisinde bir policy’nin yanında bir de ödül modelinin bakımını üstlenirsiniz.
9.6 Constitutional AI ve insandan gelmeyen geri bildirim
Kural tabanlı ödüllerin uygulanamadığı yerlerde darboğaz çoğu zaman etiketleme. Constitutional AI (anayasal yapay zekâ) (Bai vd. 2022), zararsızlık geri bildirimini insan etiketlerine daha az bağımlı biçimde, bir modele ürettirmenin yolunu inceliyor.
Yöntemin iki yarısı var. Denetimli yarıda model bir red-team prompt’unu (modeli zararlı bir cevaba itmek için bilerek yazılmış bir prompt’u) cevaplıyor, sonra kendi cevabını yazılı bir ilkeye göre eleştiriyor, sonra da düzeltiyor; düzeltilmiş hâli eğitim hedefi oluyor. RL yarısında ise aynı ilkeler zararsızlık için tercih çiftlerini etiketlemekte kullanılıyor ve orada insan etiketleyicinin yerini alıyor — yapay zekâ geri bildiriminden pekiştirmeli öğrenme, yani RLAIF. (Makalede yardımseverlik karşılaştırmalarını hâlâ insanlar etiketledi.)
Anthropic ekibi zararsızlık deneyleri için 16 ilke yazdı ve her eleştiri-düzeltme adımında rastgele birini örnekledi (Bai vd. 2022). Rastgele seçimin amacı adillik değildi. Ekip, ilkelerin bir topluluğunu (ensemble) kullanmanın, bütün etiketler için tek bir ilke kullanmaya kıyasla tercih modelinin davranışını belirgin biçimde daha sağlam (bozulmalara dayanıklı) hâle getirdiğini gördü.
Burada birbirinden ayırmamız gereken iki şey var; çünkü genelde birlikte övülüyorlar ve yalnızca biri tartışmasız.
Açıkça iyi olan: ilkeler bir nesne. Bir metin dosyası. Okuyabilir, tartışabilir, sürümleyebilir ve bir düzenleyici kuruma teslim edebilirsiniz. İnsan tercih verisinin arkasında da yönergeler ve kalite denetimi olabilir, ama yayımlanmadıklarında değerleri ancak bitmiş modeli yoklayarak çıkarabilirsiniz. Şartnameyi bir belgeye taşımak, tekniğin daha iyi çalışıp çalışmadığından bağımsız olarak hesap verebilirliğe katkı sağlar; yine de yazılı bir ilke, davranışın gerçekten ona uyduğunu tek başına kanıtlamaz.
Netleşmemiş olan: yapay geri bildirim, değerlendirici modelin hatalarını ve yanlılıklarını eğitim sinyaline taşıyabilir. Değerlendirici ile eğitilen model sık sık aynı model ya da yakın akrabası; o zaman ortak kör noktalar özellikle incelenmeli. Değerlendirici bir cevabın ince bir şekilde yanlış olduğunu fark edemiyorsa, eğitim sinyali de kendinden emin biçimde yanlış olur ve döngünün iki tarafının paylaştığı bir yanlılığı yalnızca ölçeği büyütmek düzeltmez. Makul bir beklenti, yapay geri bildirimin bir modelin denetleyebileceği özelliklerde (bu kaba mı, istenen kısım bunda var mı, bu reddediyor mu) daha güvenilir, alan uzmanlığı gerektiren özelliklerde daha az güvenilir olması; ama bunu her ölçüt için insan ve uzman denetimli örneklerle ayrı ayrı ölçün.
9.7 Parasını ödeyebileceğiniz bir modele damıtma
Şimdiye kadarki her şey modeli daha iyi yaptı. Bilgi damıtma (knowledge distillation) (Hinton vd. 2015) ise büyük bir öğretmenin davranışını daha küçük bir öğrenciye aktarmayı amaçlıyor; öğrenci daha düşük bir sunum maliyeti sağlayabilir. Toplam kazancı, öğretmen verisini üretme ve öğrenciyi eğitme maliyetiyle birlikte ölçün.
knowledge distillation (bilgi damıtma) — küçük bir öğrenciyi, öğretmenin olasılık dağılımı ya da seçilmiş çıktılarıyla eğitmek. Öğrencinin hangi davranışları öğrendiği veriye, kapasiteye ve değerlendirmeye bağlıdır; öğretmenin hatalarının aktarılması bir risktir, çıktılar süzülerek azaltılabilir. ↩︎
Kurulum şöyle: büyük bir öğretmen çıktı üretir, küçük bir öğrenci bu çıktıları yeniden üretmek üzere eğitilir. Klasik biçimde öğrenci, öğretmenin bütün çıktı dağılımını — “yumuşak hedeflerini” (soft targets) — taklit eder; bu, örnek başına sert bir etiketten fazla bilgi taşıyabilir. Öğretmenin olumlu’ya %70, nötr’e %25, olumsuz’a %5 verdiğini bilmek, öğrenciye bu örneğin sınırda olduğunu söyler; olumlu diyen one-hot bir etiket söylemez. Bu bilginin ne kadar yararlı olduğu, öğretmenin kalibrasyonuna ve göreve bağlıdır.
Üretken modellerde modern biçim daha kaba ama iyi çalışıyor: öğretmene büyük bir prompt kümesini cevaplatın, cevapları süzün ve öğrenciyi bunlar üzerinde, sıradan SFT verisiymiş gibi fine-tune edin. DeepSeek-R1’in yazarları bunu yaptı; büyük modellerinden ayıklanmış 800.000 örnekle küçük yoğun modelleri eğittiler (Guo vd. 2025).
Öğretmen çıktısını kullanmadan önce koşulları doğrulayın. Barındırılan hizmetlerin kullanım koşulları ve açık ağırlıklı modellerin lisansları, çıktıların başka bir modeli eğitmekte kullanılmasına farklı koşullar koyabilir; kimi kısıtlar, kimi izin verir, kimi türetilmiş modelin adında atıf ister (Llama 3.1 lisansı bunlardan biri, Bölüm 8.6.2). Bu teknik değil hukuki bir soru: kullanacağınız modelin, hizmetin ve veri kümesinin ilgili sürümündeki şartları okuyun, gerekirse kurumunuzun hukuk değerlendirmesini alın.
9.8 Sürdürülen ön eğitim ve Türkçe meselesi
“Eğitim sonrası, bilgi eklemenin güvenilir yolu değildir” ilkesinin esnediği bir durum var: eksik olan şey bir olgu değil bir dağılım olduğunda. Az Türkçe görmüş bir modelin eksiği, Türkçe hakkında tek bir olgu değil, dilin örüntüleridir. Ama bir modelin Türkçe başarımı düşükse nedenini önce hedef görevlerde ölçün: veri dağılımı, tokenizer, model boyutu ve talimat uyumu ayrı ayrı etkiler.
Bunun aracı sürdürülen ön eğitim: temel modeli alıp aşama 1’i bir alan derlemi üzerinde, aynı sonraki-token hedefiyle ve hiçbir talimat biçimi kullanmadan çalıştırmaya devam etmek (Gururangan vd. 2020). Aşamaların arasında duruyor — ön eğitimin hedefi; veri ve hesap gereği ise derleme ve hedefe göre değişir, önceden sabit değildir.
continued pretraining (sürdürülen ön eğitim) — mevcut bir temel modelden başlayarak ön eğitim hedefini daha dar bir derlem üzerinde yeniden çalıştırmak. Eksik olan şey bir görev ya da format değil, bütün bir alan veya dil olduğunda kullanılır. ↩︎
Türkçe için üç seçeneğiniz var ve Bölüm 8.4 bunlardan birinin token tarafını sizin için zaten ölçtü:
| yol | olası yarar | ölçülmesi gereken risk ve maliyet |
|---|---|---|
| çok dilli bir modeli görevde uyarlamak | en hızlı yol; hazır modelin mevcut yeteneklerinden yararlanmak | Türkçe görev kalitesi; o modelin tokenizer’ında Türkçenin token sayısı; uyarlama hesabı |
| Türkçe bir derlem üzerinde sürdürülen ön eğitim, sonra görev uyarlaması | dil ve alan örüntülerini güçlendirme olasılığı | derlem ve eğitim maliyeti (küçük de olsa gerçek bir ön eğitim koşusu); genel yeteneklerde gerileme |
| Türkçe öncelikli bir modelle başlamak | hedef metinde daha az token (daha düşük fertility) ve daha uygun temsil olasılığı | görev kalitesi, lisans, boyut ve sunum maliyeti; mevcut Türkçe öncelikli modeller çoğunlukla küçük |
Token tarafı ölçülebilir ve biz onu Bölüm 8’de ölçtük: aynı Türkçe metinde Llama 3’ün tokenizer’ı kelime başına 2,12 token üretirken BERTurk’ün tokenizer’ı 1,59 üretiyor; yaklaşık %33’lük bir token sayısı farkı. Bunlar farklı modellere ait; BERTurk’ün tokenizer’ını Llama 3’e takamazsınız. Yani bu fark aynı model için otomatik bir %33 fatura ya da gecikme artışı değil, iki aday arasındaki token farkı; kararı her adayın kendi tokenizer’ı, görev kalitesi ve gerçek fiyatıyla verin. (Bu, Bölüm 8.4’teki %23’ten farklı bir kıyas: orada aynı içeriği Türkçe ve İngilizce olarak karşılaştırmıştık, burada aynı Türkçe metni iki tokenizer’la karşılaştırıyoruz.) Türkçe öncelikli modellerin somut bir haritası ve çok dilli ile tek dilli model arasında ölçümle karar vermek için Bölüm 16.6 ve Bölüm 16.7’ye bakın.
Göreve göre karşılaştırın. Kısa metinlerde sınıflandırma ya da bilgi çıkarma işlerinde Türkçe öncelikli ve çok dilli adayları aynı ayrılmış veride kalite, gecikme ve maliyetle karşılaştırın; Bölüm 9.11, 110M parametreli bir Türkçe öncelikli modelin bir görevde iyi iş çıkardığını gösteriyor, ama yalnızca o görev için. Görev geniş bilgi ya da akıl yürütme istiyorsa ilgili testleri ekleyin; karşılayabileceğiniz boyuttaki Türkçe öncelikli modeller bu konuda çok dilli modellerin gerisinde kalabilir. Sürdürülen ön eğitimi, yeterli bir Türkçe derleminiz ve ölçülmüş bir kalite açığınız varsa bir pilot koşuyla değerlendirin; mevcut yeteneklerdeki gerilemeyi de ölçün.
9.9 Ne zaman fine-tune edilmemeli
Bu bölümün büyük kısmı nasıl sorusuyla ilgiliydi. Bu kısım ise yapmalı mı sorusuyla ilgili; bölümden tek bir kısmı hatırlayacaksanız bu kısmı hatırlayın.
Sık görülen bir hata biçimi var. Bir ekibin, kendi işleri hakkında yanlış şeyler söyleyen bir modeli vardır. Fine-tuning de kulağa “modele işimizi öğretelim” gibi gelen tekniktir. Örnekleri toplarlar, bir LoRA koşusu çalıştırırlar ve karşılarına daha akıcı ama hâlâ yanlış bir model çıkabilir — çünkü örnekler ona dokümantasyonlarının üslubunu öğretmiş, güncel içeriği ise güvenilir biçimde geri çağrılabilecek şekilde vermemiştir. Önce yanlış bilginin nereden geldiğini ve doğru kaynağın modele nasıl sunulacağını sınayın.
Hangi teknik ve neden — yukarıdan aşağı yürüyün
Ağaç, hazırlık maliyeti düşük seçeneklerden başlayarak sorunun türünü ayırıyor ve 4. sorudan önceki her çıkış, bir eğitim işi çalıştırmamanın bir yolu; dallar evrensel bir fiyat sırası değil. Bir fine-tuning, eğitim verisi ve gerileme değerlendirmesiyle birlikte bakım ister: temel model güncellendiğinde yeniden değerlendirilmesi, çoğu zaman yeniden eğitilmesi gerekir. Model sürümü değiştiğinde prompt, erişim ve şema düzenleri de yeniden sınanmalı, ama bu bakım genellikle daha hafiftir.
2. dal bir formalite değil. “Daha iyi bir prompt denediniz mi”, arkasında geniş bir literatür olan bir soru — bir derleme, yalnızca metin tabanlı 58 ayrı prompting tekniğini katalogluyor (Schulhoff vd. 2025). Önemli olanları ise prompting bölümü (Bölüm 17) tek tek ele alıyor. Fine-tuning’e başvuran ekipler çoğu zaman bu tekniklerin yalnızca birkaçını denemiş olur.
Ağacın kodladığı iki kural.
- Bilgi için önce erişim, davranış için gerekirse fine-tuning. Hata güncel ya da kuruma özgü bilginin eksikliğinden geliyorsa önce kaynağı erişimle sağlayıp doğrulayın; davranış için prompt’u, gerekirse fine-tuning’i deneyin. Bunlar alternatif değil, birlikte çalışabilen şeyler: yaygın ve güçlü bir mimaride, biçiminizi ve tonunuzu öğrenmiş bir model, erişimle getirilen ve olgularınızı sağlayan belgelere dayanarak cevap verir. Bu bir başlangıç sezgisi, kesin bir ayrım değil: bilgi sürdürülen ön eğitimle de eklenebilir, davranış prompt’la da değişebilir.
- Doğrudan temel modelden DPO’ya geçmeyin. DPO’nun kaybı, policy’yi donmuş bir referansla iki sabit tamamlama üzerinden karşılaştırır. En iyi sonucu da bu tamamlamalar referansın üretebileceği şeylere benzediğinde verir. Talimat izleyen bir modelin yazdığı tercih verisi için temel model zayıf bir referanstır; eğitim hedefi de gücünü tercihe değil bu uyumsuzluğa harcar. Kayıpta bunu yasaklayan hiçbir şey yok — bu, tanımlılık koşulu değil, dağılım uyumu hakkında bir tespit — ama işe yarayan reçete önce SFT’dir.
9.10 Yıkıcı unutma
Bir maliyet daha var ve hiçbir faturada görünmüyor.
Fine-tuning ağırlıkları oynatır ve ağırlıklar ortak kullanılan temsilleri taşır: bir Türkçe yorumun nasıl sınıflandırılacağını temsil etmeye yarayan parametreler, Türkçeyi temsil etmeye de katkıda bulunabilir. Model yeni görevde iyileşirken daha önce iyi yaptığı görevlerde gerileyebilir; bu olguya yıkıcı unutma (catastrophic forgetting) deniyor (Kirkpatrick vd. 2017). Büyük dil modellerinde art arda yapılan fine-tuning’ler (continual fine-tuning) sırasında da gözlenmiş (Luo vd. 2025); büyüklüğü eğitime ve değerlendirmeye bağlı.
catastrophic forgetting (yıkıcı unutma) — yeni bir görev üzerinde eğitim yapmanın, modelin daha önce üstesinden geldiği görevlerdeki başarımını düşürmesi; çünkü iki görev ortak temsilleri kullanıyordu. Eski görevi bilerek değerlendirmedikçe görünmez. ↩︎
Tehlikeli olmasının sebebi, bunun gerçekleşmesi değil. Sebep, değerlendirmenizin bunu göstermeyecek olması. Göreviniz için bir test kümesi kurdunuz. Fine-tune edilmiş modeliniz o test kümesinde iyileşiyor. Baktığınız her sayı yükseliyor. Bir şey düştüyse, ölçmediğiniz bir şeydir ve bunu bir kullanıcıdan öğrenebilirsiniz. Korumak istediğiniz yetenekleri uyarlamadan önce seçin ve aynı ayrılmış örneklerde önce ve sonra ölçün.
9.10.1 Kendi modelimiz üzerinde ölçmek
Bunu iddia etmekle kalmayıp ölçebiliriz. Bölüm 4’teki aynı BERTurk modelini ve aynı Türkçe yorum görevini alalım, onu iki farklı şekilde fine-tune edelim ve sonra duygu analiziyle hiç ilgisi olmayan bir soru soralım: encoder (kodlayıcı) Türkçeyi hâlâ ne kadar iyi modelliyor?
Probe (yoklama aracı), orijinal ön eğitim hedefinin kendisi. Ayrılmış Türkçe metindeki token’ların %15’ini maskeleyin ve modelin kendi masked-language head’inin (maskeli dil modelleme çıktı katmanı) bu konumlardaki ortalama çapraz entropisini ölçün; fine-tuning’den önce ve sonra. Bu bir maskeli dil modelleme yoklaması; Bölüm 6’daki otoregresif perplexity değeriyle doğrudan karşılaştırılamaz.
Sayıların bir anlam taşıyıp taşımadığını tek bir yöntem kararı belirliyor. LoRA satırında adaptör etkin: bu çalışmada taban ağırlıklara kaynaştırılarak yoklandı. (Kaynaştırma şart değil; yeniden koşuda kaynaştırılmış model ile adaptörü etkin model arasındaki logit farkı fp32’de en fazla \(4{,}8\times10^{-6}\) çıktı.) Adaptörü silmek ise başlangıç modelini geri getirirdi ve ölçüm bir totoloji olurdu. Sorulan şey şu: LoRA ile uyarlanmış modeli dağıttığınızda, o modelin Türkçeye hâkimiyeti zayıflamış mıdır?
Probe’un bir sınırını sayılardan sonra değil önce söyleyelim. Masked-language head’i ön eğitimden gelen ağırlıklarında dondurulmuşken altındaki encoder hareket ediyor. Dolayısıyla yükselen kayıp, encoder’ın o head’den uzaklaşmasını ölçüyor. Bu ölçüm iki şeyi birbirine karıştırır: gerçek dilsel bilgi kaybını ve eski head’in artık okuyamadığı bir temsili. İkisi aynı şey değil ve bu tasarım onları ayıramaz. Ayıracak olan şey, her encoder’ın üstüne yeniden eğitilmiş bir probe ya da encoder’ın üzerinde ayarlanmadığı bir Türkçe alt görev olurdu. Tabloyu, mevcut donmuş head ile görülen bir uyum değişimi olarak okuyun; Türkçe bilgisinin ne kadarının kaybolduğunun ölçümü olarak değil.
İki probe kümesi var, çünkü farklı sorulara cevap veriyorlar. Genel Türkçe, paralel bir derlemden alınmış 1.826 cümlelik sıradan düzyazı (Zhang vd. 2020) — yorumlarla da duygu analiziyle de ilgisi yok. Ayrılmış yorumlar ise aşağıdaki labın (Bölüm 9.11) test bölümü: fine-tuning ile aynı alan; sonucun bir alan kayması yan etkisi diye geçiştirilememesi için dâhil edildi. Maskeli tensörler bir kez üretilip üç encoder için de yeniden kullanılıyor; böylece örnekleme farkı ortadan kalkıyor. Değerlendirme modu, MLM head ve sayısal hassasiyet de üçünde aynı tutulmalı.
| encoder | genel TR kaybı | top-1 | yorumlarda kayıp | top-1 |
|---|---|---|---|---|
| ön eğitimli, dokunulmamış | 2,523 | %50,7 | 2,660 | %48,3 |
| tam fine-tuning sonrası | 2,837 (+%12,5) | %46,4 | 4,564 (+%71,6) | %28,9 |
| LoRA \(r=8\) sonrası, kaynaştırılmış | 2,592 (+%2,7) | %49,6 | 3,276 (+%23,2) | %42,0 |
Kayıp, maskeli konumlar üzerinden nat cinsinden ortalama çapraz entropi — genel Türkçe için 5.406, yorumlar için 9.893 konum — top-1 ise modelin tek en iyi tahmininin gerçekten orada olan token’a ne sıklıkta denk geldiği. Düşük kayıp da yüksek top-1 de iyidir; ilk satır ise modelin Hub’dan geldiği hâli.
Yoklamanın kodu kaydedilmemişti; onu metinden yeniden yazıp çalıştırdık (yeniden koşu, Ekim 2026). Genel Türkçe kümesi olarak OPUS-100 en-tr test bölümünün Türkçe tarafını (tekilleştirilmiş 1.976 cümle, 2.860 maskeli konum), yorumlar için test bölümünün ilk 2.000 yorumunu (9.753 konum) kullandık; tam fine-tuning satırı bizim 2e-5’lik koşumuz (85,34 macro-F1), LoRA \(r=8\) ise kitabın lab satırını birebir yeniden üreten koşu. Ön eğitimli model genel Türkçede 2,897 kayıp ve %47,0 top-1, yorumlarda 2,602 ve %49,1 aldı. Tam fine-tuning sonrası kayıp genel Türkçede +%9,7 (top-1 %44,1), yorumlarda +%55,5 (%35,0) arttı; kaynaştırılmış LoRA’da artışlar +%1,7 (%46,2) ve +%25,9 (%42,2). Metin ve tam fine-tuning ayarı farklı olduğu için büyüklükler kitabın tablosundan ayrılıyor; sıralama ve alan içi örüntü aynı.
Tablodan üç ders çıkıyor ve üçü de tabloyu tanıtan paragraftan daha önemli.
Donmuş eski head üzerinden bakıldığında iki uyarlama da kaybı artırıyor; tam fine-tuning’de artış çok daha büyük. Oranı ve neyi ifade ettiğini açıkça söyleyelim: %12,5’e karşı %2,7 — yaklaşık 4,6 kat — donmuş bir head üzerinden ölçülmüş göreli kayıp artışlarının oranıdır; bir modelin 4,6 kat daha fazla Türkçe unuttuğunun ölçümü değil. Görevle hiç ilgisi olmayan metinde tam fine-tuning, donmuş head ile ölçülen masked-language kaybını %12,5 artırıyor, top-1 doğruluğunu da dört puan düşürüyor. Bu, dramatik anlamda yıkıcı değil ama bu yoklama düzeninde anlamlı bir gerileme; modelin genel Türkçe yeteneğinin aynı oranda kaybolduğunu göstermez. Korumak istediğiniz ürün becerilerini ayrıca test edin.
Bu deneyde LoRA’nın kayıp artışı tam fine-tuning’den küçük, ama sıfır değil. +%2,7 küçük bir sayı ama sıfır değil. Kaynaştırılmış model, başlangıçtaki head üzerinden okunduğunda ölçülebilir biçimde daha kötü sonuç veriyor. Parametre-verimli fine-tuning’de unutma olamayacağını söyleyen biri, aslında geri alınabilirlik argümanını tekrarlayıp ona unutma argümanı adını veriyordur.
Alan içi yoklamada gerileme daha büyük. İnsanları şaşırtan satır bu: tam fine-tuning’in kaybı genel Türkçede %12,5, ayrılmış yorumlarda ise %71,6 artıyor — üzerinde eğitildiği alanda neredeyse altı katı (yeniden koşuda %9,7’ye karşı %55,5). Olası bir okuma şu: model, verinizin en çok dokunduğu temsilleri görev için yeniden düzenliyor — yorum metninin temsili “bir cümlenin anlatabileceği her şey”den “iki düğmeden hangisine basılacağı”na kayıyor — ve masked-language head’i bunu eskisi kadar okuyamıyor. Ama bunun ne kadarının temsil değişimi, ne kadarının eski head ile uyumsuzluk olduğu bu düzenle ayrılamaz. Pratik sonuç yine de önemli: bu deneyde gerilemeye en duyarlı yoklama alan içi olandı ve bu, görevin kendi test kümesi dururken gereksiz görünüp kurulmayan türden bir yoklama.
Sizin izlediğiniz sayı iyileşirken iki probe’da da sonuç kötüleşti. Her satırda ve her probe kümesinde kayıp yükseldi, top-1 düştü; duygu skoru ise ters yöne gitti. Tam fine-tuning, aşağıdaki labın en iyi duygu modeli — 83,90 macro-F1 ile oradaki tablonun tepesinde — ama bu probe’da üçünün en zayıfı, hem de iki kümede birden. İki olgunun hiçbiri, ötekinin değerlendirmesine bakarak görülemez. Tuzağın tam biçimi bu: kötüleşen bir model değil, ölçtüğünüz tek şeyde iyileşen bir model.
9.10.2 Bu konuda ne yapmalı
Alanın standart cevabı, InstructGPT’nin kullandığı cevap. Yazarlar “açık NLP veri kümelerinde başarım gerilemeleri” — yani hizalama vergisi — tespit edince ön eğitim gradyanlarını RLHF güncellemesine geri karıştırdılar. Böylece PPO-ptx dedikleri varyantı elde ettiler ve bunun belirli açık NLP görevlerindeki gerilemeleri en aza indirdiğini bildirdiler (Ouyang vd. 2022). Bu, eski veriyle karıştırmanın yararlı olabileceğine bir örnek; hangi veri oranının hangi beceriyi koruyacağı hedef görevlerde yeniden ölçülmeli.
Pratikte üç alışkanlık işe yarar:
| alışkanlık | maliyeti | neyi sağlar |
|---|---|---|
| eğitimden önce belirlenmiş birden fazla eski görevde önce/sonra değerlendirme | ek değerlendirme koşuları | seçilen becerilerdeki gerilemeyi görünür kılar |
| genel veriyi uyarlama verisine kontrollü oranlarda karıştırmak | ek veri ve ayar koşuları | korunması hedeflenen becerilerde etkisi ölçülebilir |
| tam fine-tuning ile LoRA’yı aynı kalite ve hesap koşulunda karşılaştırmak | ek koşular | bu görevde kalite–gerileme dengesini gösterir; bizde LoRA, macro-F1’de 1,2 puan (yeniden koşuda ayarlı oranlarla 1,7 puan) karşılığında donmuş head ile ölçülen genel Türkçe kayıp artışını %12,5’ten %2,7’ye indirdi (yeniden koşuda %9,7’den %1,7’ye) |
Birinci satırdaki kilit ifade “eğitimden önce”. Fine-tune edilmiş modelin hatalarını gördükten sonra seçilen bir benchmark, modeli tam da tesadüfen fark ettiğiniz hatalarda iyi göstermek için seçilmiş bir benchmark’tır.
9.11 Lab: Türkçe bir görevde LoRA, ölçülmüş hâliyle
Bu kısımda Bölüm 4’teki aynı Türkçe ürün yorumu görevini, tek bir Apple M serisi GPU üzerinde yedi farklı şekilde çalıştırılmış koşuların raporlanan sonuçlarıyla inceliyoruz. Sayılar bu kurulumun gözlemleri; başka donanıma ya da veri bölünmesine doğrudan taşınmamalı.
Kurulum bilinçli olarak mütevazı, çünkü mesele bunun ulaşılabilir olması. BERTurk base (dbmdz/bert-base-turkish-cased, 110,6M parametre), Bölüm 4 bölünmesi — 40.000 eğitim yorumu, 10.000 ayrılmış, seed (rastgelelik tohumu) 42 — iki epoch, dizi uzunluğu 128, batch boyu 32, bir Apple M serisi GPU üzerinde. LoRA adaptörleri yalnızca query ve value üzerinde, \(\alpha = 2r\), dropout 0,05. Özgün koşuların kodu, yazılım sürümleri ve öğrenme oranı kayda geçirilmemişti; aşağıdaki yeniden koşu, eksik ayrıntıları nasıl tamamladığımızı söylüyor.
Karşılaştırmanın sınırı. Bütün satırlar ortak tek bir öğrenme oranıyla çalıştırıldı; bu yüzden tam fine-tuning ile LoRA arasındaki fark, yöntemlerin ayrı ayrı ayarlanmış en iyi sonuçlarını göstermiyor. Rank satırları ortak oranla karşılaştırılabilir, ama rankın en iyi oranı da değişebilir. Güvenilir bir yöntem kıyası için eğitim verisinden ayrılmış bir doğrulama diliminde her yöntemin oranını arayın; test kümesini seçimde kullanmayın. Yeniden koşu bu sınırın ne kadar önemli olduğunu ölçtü (aşağıda).
| neyi eğittik | eğitilebilir | pay | macro-F1 | F1(olumsuz) | doğruluk | gerçek süre | tepe GiB |
|---|---|---|---|---|---|---|---|
| yalnızca head (doğrusal probe) | 1.538 | %0,001 | 48,37 | 0,00 | 93,68 | 3 dk 35 sn | 0,41 |
| tam fine-tuning | 110.618.882 | %100 | 83,90 | 70,16 | 95,62 | 11 dk 59 sn | 6,07 |
| LoRA \(r=1\) | 38.402 | %0,035 | 80,47 | 63,01 | 96,09 | 10 dk 01 sn | 4,32 |
| LoRA \(r=4\) | 148.994 | %0,135 | 80,50 | 62,97 | 96,26 | 9 dk 46 sn | 4,32 |
| LoRA \(r=8\) | 296.450 | %0,267 | 82,69 | 67,23 | 96,50 | 10 dk 04 sn | 4,32 |
| LoRA \(r=16\) | 591.362 | %0,532 | 82,59 | 66,99 | 96,58 | 10 dk 03 sn | 4,33 |
| LoRA \(r=64\) | 2.360.834 | %2,090 | 82,39 | 66,60 | 96,55 | 10 dk 30 sn | 4,37 |
Karşılaştırma için: Bölüm 4’ün aynı bölünmedeki, yapay sinir ağı kullanmayan en iyi modeli — kelime 1-2 gramları üzerinde tf-idf, GPU yok — 76,21 macro-F1 ve 56,47 F1(olumsuz) almıştı.
“Tepe GiB”, bu çalışmada ölçülen en yüksek canlı MPS bellek tahsisi; her satır için ayrı bir süreçte ölçüldü. İşletim sisteminin bildirdiği toplam GPU ya da ortak bellek kullanımına eşit değil: MPS sürücüsünün bildirdiği ayrı tepe ölçümü satırlarda yaklaşık 0,7 GiB daha yüksek. Yeniden koşu, sütunun ne zaman ölçüldüğünün de önemli olduğunu gösterdi (aşağıda). Gerçek bir cihaz planı için aynı ölçüm yöntemini ve batch/dizi koşullarını kullanın.
9.11.1 Tabloyu okumak
1. satır kontrol grubu ve başarısız oluyor. Encoder’ı dondurup yalnızca sınıflandırma head’ini — 1.538 parametre — eğitmek, macro-F1’i 48,37, doğruluğu 93,68 olan bir model üretiyor. Bunlar yeni sayılar değil; Bölüm 4’ün çoğunluk sınıfı baseline’ının birebir aynısı. Olumsuz F1’in sıfır olması çoğunluk sınıfına yönelmiş bir modelle uyumlu; yeniden koşuda tahmin sayıları bunu doğruladı: 10.000 test yorumunun hepsine olumlu dedi. %93,68’i olumlu olan bir derlemde bu, yerel olarak makul bir davranış. Eğitilebilir bir head’i olan donmuş bir encoder, adaptör tabanlı bir yöntem değil doğrusal bir probe’dur ve dengesiz bir görevde tek bir sınıfa kilitlenebilir — doğrusal probe’ları “parametre-verimli fine-tuning” başlığı altına koyup koymamanız bir adlandırma meselesi; önemli olan, hiçbir temsili değiştirmemeleri. Olumsuz sınıftaki F1 tam 0,00. Bu satırı okurken yukarıdaki öğrenme oranı çekincesini hesaba katın: satır ortak oranla çalıştırıldı. Yeniden koşuda kayıpta sınıf ağırlıkları ve daha yüksek bir oranla (1e-3 ve 1e-2) probe 63,85 ve 64,90 macro-F1’e çıktı: 48,37’den iyi, ama LoRA satırlarının 15 puandan fazla gerisinde. Aşağıdaki “Sıra sizde” kısmının ilk alıştırması bu deney.
O satır tabloda, çünkü onunla LoRA satırları arasındaki fark bütün argümanın kendisi. Doğrusal probe yalnızca son sınıflandırma head’ini eğitiyor; buradaki LoRA ise her encoder bloğunun query ve value projeksiyonlarına küçük adaptörler ekliyor, dolayısıyla gradyan encoder’ın içinden geçiyor. LoRA modelin her ağırlığını ya da her modülünü eğitmiyor; ama değişikliği encoder’ın içine, bütün bloklara yayıyor.
Bu koşuda rank çabucak önemsizleşiyor. \(r=1\)’den \(r=8\)’e çıkmak 2,2 macro-F1 puanı kazandırıyor; \(r=8\)’den \(r=64\)’e — sekiz katı parametre — skor 82,69’dan 82,39’a iniyor. Bu küçük fark tek bir koşudan; daha yüksek rankın zarar verdiğini söyleyemeyiz. Yeniden koşu da bu son adımı tekrarlamadı: üç tohumda \(r=1\) 80,55 ± 0,65, \(r=64\) 84,05 ± 0,26 aldı (\(r=8\) tek tohumda 82,66); yani bizim koşularımızda rank 2e-4’te küçük kazançlar vermeyi sürdürdü. Öte yandan \(r=8\) kendi doğrulamada seçilmiş oranıyla (1e-3) 83,68 ± 0,40’a çıktı — oranı ayarlamak, rankı sekiz katına çıkarmak kadar kazandırdı.
O satırdaki karıştırıcı etkene ad koymakta yarar var; çünkü literatürün asıl tartıştığı şey bu. \(\alpha = 2r\) ile etkin ölçek \(\alpha/r\) her rankta sabit 2; yani bu tarama, sabit bir \(\alpha\) altında olacağı gibi kılık değiştirmiş bir ölçek taraması değil. Ama \(\alpha/r\)’yi sabit tutmak da bir seçim: Kalajdzievski (2023), \(\Theta(1/r)\) ölçeklemesinin rank büyüdükçe gradyanları küçülttüğünü ve yüksek rankta kararlı öğrenmenin \(\Theta(1/\sqrt{r})\) istediğini gösteriyor — öngörülen belirti de “yüksek rank yardımcı olmuyor”. Ama bu tek tohumlu eğri, \(r=64\) sonucunun yalnızca bu ölçekleme yüzünden oluştuğunu göstermez; öğrenme oranı ve tohum da karıştırıcı. Yaygın \(\alpha = 2r\) kuralında rankın ne kadar ödediğini ve rank-kararlı ölçeklemede neyin değiştiğini ayrı bir oran ve ölçek taramasıyla, birden fazla tohumda sınamak gerekir; bu bölüm o deneyi çalıştırmadı.
Kitabın koşusunda eğri bir kez yükselip düzleşiyor; yeniden koşuda düzleşme daha yavaş. İkisinde de ortak olan: rankın getirdiği kazanç, \(r=1\)’den sonra öğrenme oranının etkisiyle aynı büyüklükte ya da ondan küçük. Bölüm 9.4’teki düşük ranklılık hipotezi de küçük ranklarla iyi bir sonucu beklemeye yöneltir, ama bu görevin eğrisini tek başına kanıtlamaz; rankı birkaç tohumda doğrulama puanı, bellek ve maliyetle seçin.
Tam fine-tuning kazanıyor ve tek bir sınıf üzerinden kazanıyor. \(r=8\)’in 82,69’una karşı 83,90, bu koşuda 1,21 puanlık bir fark ve farkın geldiği yer azınlık sınıfı: F1(olumsuz) 67,23’e karşı 70,16, o sınıfta +2,93 puan. Yine de bu, hikâyenin tamamı değil — diğer yarıyı geri hesapladığınızda tam fine-tuning’in çoğunluk sınıfında hafifçe geride kaldığını görürsünüz: F1(olumlu) 98,15’e karşı 97,64. Bir sınıftaki 2,93 puanlık kazanç ile diğerindeki 0,51 puanlık kaybın ortalaması, gördüğünüz 1,21’i veriyor. Ama doğruluk sütununa bakın — bu tabloda her bir LoRA koşusu genel doğrulukta tam fine-tuning’den daha isabetli (95,62’ye karşı 96,09–96,58). İki metrik dengesiz veride farklı tercihleri öne çıkarır; karar sınırının nasıl değiştiğini ise ancak sınıf bazlı hatalar ve olasılık dağılımı gösterir. Yeniden koşuda bu ayrım tekrarlanmadı: tam fine-tuning (2e-5) doğrulukta da önde kaldı — %96,83’e karşı ayarlanmış LoRA \(r=8\)’de %96,60. Karışıklık matrisleri (tohum 42) tam fine-tuning’in olumsuz sınıfı daha çok yakaladığını (632 olumsuzdan 415’e karşı 382) ve toplamda daha az hata yaptığını (317’ye karşı 331) gösteriyor. Yani bu tabloda gördüğünüz doğruluk–macro-F1 ayrımı bu kurulumun bir özelliği olabilir, genel bir LoRA özelliği değil. Hangisini istediğiniz yine de bir eğitim kararı değil bir ürün kararıdır.
Asıl dikkat çekici sonuç rank 1. 38.402 eğitilebilir parametre — 36.864’ü adaptörlerde, 1.538’i head’de, modelin %0,035’i, e-postayla gönderebileceğiniz bir dosya — donmuş bir encoder’ı 48,37’den 80,47 macro-F1’e taşıyor ve Bölüm 4’ün tf-idf baseline’ını dört puandan fazla geçiyor (yeniden koşuda 80,55 ± 0,65). Küçük ve katmanlara dağıtılmış bir uyarlama kapasitesi bu görev için yeterli olabiliyor; bu, kapasitenin rolü yok demek değil.
Gerçek süre (wall-clock, duvar saatiyle geçen süre) sütunu. Bu cihaz ve ayarlarda \(r=8\) 10 dk 04 sn, tam fine-tuning 11 dk 59 sn sürdü: yaklaşık 1,19 kat. Eğitilebilir parametrelerdeki 373 katlık fark süreye aynı oranda yansımadı. Yeniden koşuda (M5 Max) oran 1,42 kat çıktı (6 dk 54 sn’ye karşı 9 dk 47 sn); yani bu oran donanıma ve yazılıma bağlı. Hangi işlemlerin süreyi belirlediğini bir profil çıkararak ölçebilirsiniz.
Yalnızca head’i eğiten satır karşıtlık yoluyla bir şey gösteriyor. 3 dk 35 sn’de bitiyor (yeniden koşuda 3 dk 14 sn) — tam fine-tuning’den 3,3 kat hızlı — çünkü encoder’ın içinde eğitilebilir hiçbir şey yokken geri yayılım encoder’a hiç girmiyor. LoRA’nın adaptörleri ise blokların içinde oturuyor; adaptör gradyanları encoder’daki hesap yolunu izliyor. Donmuş ana ağırlıkların gradyanları tutulmasa da geri geçiş ortadan kalkmıyor. Bu kurulumda LoRA, bellek ve taşınabilirlik kazandırdı ama geri geçişi belirgin biçimde kısaltmadı; hız kazancını kendi modelinizde ve uygulamanızda ölçün.
Bellek sütunu ise bölümdeki aritmetiğin gerçekle sınandığı yer. 16 bayta karşı 2 bayt tablosu yalnızca seçilmiş parametre durumlarını karşılaştırıyordu; toplam tepe belleğin sekiz kat azalacağını öngörmüyordu. Ölçülen azalma 1,40 kat — 6,07 GiB’tan 4,32 GiB’a. \(r=8\)’in 4,32 GiB tepesinden bellekte duran parametreleri — ilk ileri geçişten önce ölçülen 0,41 GiB — çıkarın, geriye 3,91 GiB kalıyor. Bu farkın büyük kısmı aktivasyonlar, ama tamamı değil: gradyanlar, çalışma alanı ve geçici tensörler de orada; ayrıntılı bir bellek profili olmadan payları ayıramayız. Rank tercihi bunu pek değiştirmiyor. QLoRA’nın yazarlarının 7B’de 26 MB’lık adaptör parametresine karşı 567 MB’lık girdi gradyanı ölçmesi de aynı yöne işaret ediyor. Yeniden koşu, sütunun ne zaman ölçüldüğünün önemli olduğunu da gösterdi: LoRA’nın 4,32’si ilk ileri geçişte, optimizer durumu oluşmadan alınmış bir değerle birebir aynı; tam fine-tuning’de ise ilk ileri geçiş 3,82 GiB, Adam durumu oluştuktan sonraki adımlar 6,96 GiB tuttu (oran 1,61 kat).
Şuna da dikkat edin: tepe bellek ranklar arasında neredeyse sabit — \(r=1\)’de 4,32 GiB, \(r=64\)’te 4,37 GiB (yeniden koşuda 4,40) — aynı sebeple. Ve 0,41 GiB’taki, yalnızca head’i eğiten satıra bakın: encoder üzerinden geri geçiş yoksa saklanan aktivasyon da yoktur; sonuç, bir mertebe daha az bellek ve çalışmayan bir model.
9.11.2 Sayıların göstermediği
Üç çekince; çünkü yalnızca iyi haber üreten bir lab deney değil, gösteridir.
- Bu oranlar başka ölçeğe taşınmaz. 1,40’lık bellek oranı ve 1,19’luk hızlanma (yeniden koşuda 1,61 ve 1,42) dizüstü bilgisayarda, 110M parametre ve 32’lik batch’le alınmış sayılar; bu boyutta aktivasyonlar baskın. Parametre durumu model boyutuyla, aktivasyon ve geçici bellek ise katman sayısı, batch, dizi uzunluğu ve checkpoint’lemeyle değişir; model genişledikçe denge çoğu zaman parametrelerden yana kayar. 8B için verilen 119,7 ve 15,5 GiB ise statik durum kestirimleri, gerçek tepe bellek ölçümü değil. Bu tablonun oranlarını LoRA hakkında genel iddialar gibi aktarmayın.
- Tepe bellek, bir dağılımın yerine geçen tek bir sayı. Sabit şekilli bir batch’in 30 adımı boyunca görülen en büyük canlı bellek tahsisi. Gerçek eğitimde dizi uzunlukları değişkendir, dolayısıyla bellek profilinin bir kuyruğu vardır ve gece 3’te koşuyu asıl öldüren şey o kuyruktur. Sütuna satırlar arası bir karşılaştırma gözüyle bakın, bir kaynak planlama rakamı gibi değil.
- Tek seed, tek veri kümesi, tek dil. Tablodaki koşular tek bir bölünme üzerinde, satır başına tek seed’le yapılmış iki epoch’luk koşular. \(r=8\) ile \(r=64\)’ü ayıran 0,30 ve \(r=1\) ile \(r=4\)’ü ayıran 0,03 bunlardan bir sıralama çıkarmaya yetmez. Yeniden koşudaki tohum tekrarları ölçeği veriyor: aynı satırda tohumlar arası standart sapma 0,26–0,65 puan; MPS’te tam fine-tuning aynı tohumla bile 0,36 puan oynadı. Bu ölçekte 1. satır ile geri kalan her şey arasındaki fark ve ayarlanmış tam fine-tuning ile LoRA arasındaki 1,7 puan gürültünün üstünde; tabloda bütün LoRA satırlarında görülen doğruluk–macro-F1 ayrımı ise yeniden koşuda tekrarlanmadı. (Parametre sayıları ölçüm değil yapılandırmanın aritmetiği olduğundan hiçbir seed onları oynatamaz.)
9.11.3 Sıra sizde
- 1. satırın tek sınıfa kilitlenmesini yeniden üretin, sonra düzeltin. Yalnızca head’i eğiten baseline’ı çalıştırın ve tahminlerin sınıf dağılımına bakarak çoğunluk sınıfı sonucunu aldığınızı doğrulayın. Şimdi encoder’da hiçbir şeyi eğitime açmadan düzeltin: öğrenme oranını ve kayıptaki sınıf ağırlıklarını (ya da yeniden örneklemeyi) bir doğrulama diliminde ayarlayın. LoRA satırlarına aynı test kümesinde ne kadar yaklaştığınızı bildirin ve farkın temsil değişimiyle uyumlu olup olmadığını tartışın; eğitim düzenleri farklı olduğu için tek bir deneyden kesin bir pay çıkarmayın.
- Karşılığını vermeyi bırakan rankı bulun. \(r \in \{1, 2, 4, 8, 16, 32\}\) taramasını her biri için üç seed’le yapın. Macro-F1’i \(\log_2 r\)’ye karşı, hata çubuklarıyla çizdirin. Eğrinin düzleştiği rankı söyleyin ve — asıl önemli kısım bu — hata çubuklarınızın onu bir alttaki ranktan ayırt edip edemediğini söyleyin.
- \(\alpha = 2r\) geleneğini bilerek bozun. \(r = 8\)’i sabitleyin ve \(\alpha \in \{2, 8, 16, 64\}\) taraması yapın. LoRA kısmındaki (Bölüm 9.4) \(\alpha/r\) ölçeğinin kayıp, gradyan ve görev skoru üzerindeki etkisini izleyin ve aynı etkiyi bir öğrenme oranı taramasıyla karşılaştırın; ikisinin tam eşdeğer olduğunu varsaymayın.
- Adaptörlerin bağlandığı yeri değiştirin. \(r = 8\)’i koruyun ve adaptörleri
query, value’dan MLP’ye (intermediate.dense,output.dense) taşıyın. Yeni parametre sayısını, çalıştırmadan önce LoRA kısmındaki formülden (Bölüm 9.4) hesaplayın — yalnızca adaptör parametreleriquery, valuerakamının 2,5 katıdır ve çarpanın neden 2 değil 2,5 olduğunu söyleyebilmelisiniz (toplam eğitilebilir sayıya head de eklenince oran değişir). Skoru aynı doğrulama düzeninde karşılaştırın: skor parametreleri takip ediyor mu? - Geri almayı gösterin. Aynı revizyonun temel checkpoint’ini saklayın. LoRA ile fine-tune edin, adaptörü kaydedin, sonra temel modeli yükleyip ağırlıklarını orijinal checkpoint’le tensör tensör karşılaştırın. Sonra tam fine-tuning’den sonra görev checkpoint’inde kaç tensörün farklılaştığını sayın ve saklanan temel checkpoint’i yeniden yükleyerek tam fine-tuning’in de geri alınabildiğini gösterin. Yıkıcı unutma kısmındaki (Bölüm 9.10) operasyonel farkı açıklayın: fark geri alınabilirlik değil, görev güncellemesinin ayrı ve küçük bir dosya olarak yönetilmesi.
- Kendi unutmanızı ölçün. Fine-tune ettiğiniz encoder’ı alın ve yıkıcı unutma kısmındaki (Bölüm 9.10) masked-language probe’unu, ne sizin ne de fine-tuning’in dokunduğu bir alandan gelen Türkçe metin üzerinde çalıştırın. Tam fine-tuning’i LoRA ile karşılaştırın. Sonra fine-tuning kümenize %10 genel Türkçe karıştırıp yeniden ölçün.
- Baseline’ın gidemeyeceği yere gidin. Bölüm 4’ün tf-idf modeli hiç GPU kullanmadan 76,21 macro-F1’e ulaşmıştı. Fine-tune edilmiş modelin doğru, tf-idf’in yanlış olduğu bir girdi bulun; bir de tersinin geçerli olduğu bir girdi. İkincisini bulmak daha zordur ve bulduğunuzda daha öğreticidir.
Teslim edilecek: bizimkiyle aynı sütunlara sahip tek bir tablo, içinde kendi sayılarınız; ayrıca asgari macro-F1, olumsuz sınıf F1’i, gecikme ve bakım koşullarınızı yazıp bu eşikleri geçen en düşük toplam maliyetli yapılandırmayı gerekçelendiren bir paragraf. tf-idf baseline’ında kalmak da bir seçenek; hiçbiri eşiği geçmiyorsa dağıtımı ertelemeyi de söyleyin.
9.12 Sezgi kontrolleri
Açmadan önce cevaplayın. Bunların her biri, fine-tuning’e dair makul görünen bir zihinsel modelin yanlış mühendislik kararı ürettiği bir nokta.
Not1. LoRA ağırlıkların %0,035’ini eğitiyor. Belleğin de %0,035’ini mi kullanır ve ~3.000 kat mı hızlı çalışır?
İkisi de değil ve bu beklentilerle ölçümler arasındaki fark, bu bölümün en işe yarar şeyi.
Bellek tarafında: bu bölümün seçilmiş 16 baytlık düzeninde donmuş bir parametrenin gradyanı, ana kopyası ve Adam momentleri kalkar; ağırlığın kendisi ve adaptöre geri yayılım için gereken ara tensörler kalır. Bu laboratuvarda tepe bellek 6,07’den 4,32 GiB’a, yalnızca 1,40 kat düştü (yeniden koşuda Adam durumu oluştuktan sonra 1,61 kat).
Hız tarafında: \(r = 8\), 373 kat daha az parametre eğitiyor ve bu laboratuvarda 1,19 kat hızlı çalıştı (yeniden koşuda başka bir cihazda 1,42 kat). Başka model ve donanım için süre ve bellek oranını ayrıca ölçün; LoRA’nın bellek ve dağıtım tarafındaki avantajı, küçük bir fine-tuning’in süresinden daha belirgin.
Not2. Encoder’ı dondurup yalnızca sınıflandırma head’ini eğitmek — bu parametre-verimli fine-tuning midir?
Adaptör tabanlı bir yöntem değil, doğrusal bir probe’dur — kimileri probe’ları PEFT şemsiyesi altına koyar, kimileri koymaz; hangisini kastettiğinizi söyleyin. Asıl fark, bir probe’un hiçbir temsili değiştirmemesidir. Bu görevde ve bu labın kullandığı ortak öğrenme oranıyla probe tamamen tek sınıfa kilitleniyor.
Donmuş bir encoder üzerinde 1.538 parametre eğitmek macro-F1 48,37 ve doğruluk 93,68 üretti — birebir Bölüm 4’ün çoğunluk sınıfı baseline’ı; olumsuz sınıftaki F1 ise 0,00 (yeniden koşuda 10.000 tahminin hepsi olumlu; sınıf ağırlıklarıyla probe 64,90’a çıktı).
Bu deneyde LoRA, her encoder bloğunun query ve value projeksiyonlarında küçük uyarlamalar eğitti; probe ise encoder’ı değiştirmedi. Rank 1 — 38.402 eğitilebilir parametre, modelin %0,035’i — aynı donmuş encoder’ı 48,37’den 80,47’ye taşıyor ve tf-idf baseline’ını dört puan geçiyor. (Kaydedilen adaptör dosyasının boyutu dtype’a ve biçime bağlı; ayrıca ölçün.)
Not3. Yüksek LoRA rankı daha çok kapasite demek. Karşılayabildiğiniz en yüksek rankı mı kullanmalısınız?
Doğrudan değil; ölçün. Bu laboratuvarın tek koşusunda \(r=1 \to r=8\) 2,2 macro-F1 puanı kazandırdı, \(r=8 \to r=64\) ise 0,30 puanlık bir düşüş gösterdi. İkinci farkın güvenilirliği bilinmiyor: yeniden koşuda üç tohumla \(r=64\), \(r=1\)’den 3,5 puan önde kaldı (84,05 ± 0,26’ya karşı 80,55 ± 0,65) ve \(r=8\) kendi ayarlanmış oranında 83,68 ± 0,40 aldı. Yani rankın getirisi küçük ve öğrenme oranıyla aynı büyüklükte. Rankı birkaç tohumda doğrulama puanı, bellek ve maliyetle seçin; Bölüm 9.4’teki düşük ranklılık hipotezi bu görevin eğrisini tek başına kanıtlamaz.
Not4. Tam fine-tune edilmiş modeliniz macro-F1’de LoRA’yı yeniyor ama doğrulukta kaybediyor. Hangisi bozuk?
Büyük olasılıkla hiçbiri; iki metrik farklı şeyleri ödüllendiriyor.
Tam fine-tuning, \(r=8\)’in 82,69’una karşı 83,90 macro-F1 aldı ve farkın geldiği yer azınlık sınıfı: F1(olumsuz) 67,23’e karşı 70,16, yani +2,93 puan; buna karşılık çoğunluk sınıfında 0,51 puanlık bir kayıp var (F1(olumlu) 98,15’e karşı 97,64). Ama her bir LoRA koşusu genel doğrulukta daha isabetli — 95,62’ye karşı 96,09–96,58. (Yeniden koşuda bu ayrım tekrarlanmadı; tam fine-tuning doğrulukta da öndeydi, %96,83’e karşı %96,60.)
Dengesiz veride macro-F1 azınlık sınıfındaki başarıyı, düz doğruluk toplam hata sayısını ödüllendirir; karar sınırının nasıl değiştiğini sınıf bazlı hatalar ve olasılık dağılımı gösterir. Hangisini istediğiniz, kaçırılan bir şikâyetin yanlış alarma kıyasla neye mal olduğuna bağlıdır. Bu, eşiği bir maliyet matrisinden seçme kısmının sorusudur (Bölüm 12.7) ve hiçbir eğitim tablosu onu sizin yerinize cevaplayamaz.
Not5. 65B’lik bir modeli fine-tune etmek için “780 GB’tan fazla” gerekiyor. Bu sayı nereden geliyor?
QLoRA makalesi 65B tam fine-tuning için 780 GB’tan fazla GPU belleği bildiriyor. \(65 \times 10^9\) parametre × 12 bayt = 780 GB, büyüklüğü açıklayan varsayımsal bir parametre hesabı; makalenin kalem dökümü değil. Öğretici olan kısım şu: makale bu on iki baytın hangileri olduğunu söylemiyor ve iki farklı okuma da hesaba uyuyor.
Birinci okuma: üç fp32 satırı — ana ağırlık, Adam’ın \(m\)’i, Adam’ın \(v\)’si. Bunlara bf16 ağırlık ve gradyan eklenince bu bölümün 16 baytlık düzeni \(65 \times 16 = 1{.}040\) GB statik parametre durumu veriyor; “fazla” ifadesiyle tutarlı. İkinci okuma: bf16 ağırlık, bf16 gradyan, fp32 \(m\), fp32 \(v\), ana kopya yok; “fazla” bu kez aktivasyonları karşılıyor.
Aktivasyonlar ve dağıtım düzeni ayrıca gelir; iki farklı hesabı tek bir gerçek kurulum gibi birleştirmeyin. Yine de iki ayrıştırma da aynı yöne işaret ediyor: manşet rakamın büyük kısmı, yalnızca parametre eğitildiği için var olan durum. Parametreyi dondurun, o durum ortadan kalkar — PEFT’in tek cümlelik gerekçesi de bu.
Not6. Fine-tune ettiğiniz model, eskiden yaptığı şeylerde kötüleşti. Ne oldu ve önlenebilir mi?
Önce eski görevlerdeki düşüşün değerlendirme gürültüsü mü, gerçek bir gerileme mi olduğunu sınayın. Gerçek bir gerilemeyse olası bir açıklama yıkıcı unutma: dar bir hedef üzerinde gradyan inişi, başka yeteneklerin dayandığı ağırlıkları oynatabilir. Her fine-tuning’in zorunlu sonucu değil, ama sık görülen bir risk. Öğrenme oranını, epoch sayısını, veri karışımını (bir miktar genel veri geri katmak) ve uyarlamanın kapsamını karşılaştırın; LoRA da etkin adaptörle eski görev başarısını düşürebilir (Bölüm 9.10’da ölçüldüğü gibi).
Bunun göründüğünden daha önemli olmasının sebebi şu: unutma, değerlendirmeyi akıl ettiğiniz şeyler üzerinden ölçülür. Değerlendirme paketiniz yalnızca yeni görevi kapsıyorsa, model hiç test etmediğiniz bir yeteneği kaybedebilir ve siz de modeli bu hâliyle yayına alırsınız. Regresyon test paketini fine-tuning’den sonra değil, önce kurun.
9.13 Mülakat soruları
Aşağıdaki sorular, tekniğin nasıl çalıştığı kadar hangi durumda seçileceğini de sınıyor; her cevabın arkasında bir ölçüm ya da bir parça aritmetik var.
Bu alanda iyi bir sinyal, ne zaman fine-tune edilmeyeceğini kendiliğinden söyleyen adaydır. Karar ağacındaki (Bölüm 9.9) gibi, önce hata türünü ve ölçülebilir bir kalite eşiğini belirleyin; sonra prompt’u, erişimi ve uyarlamayı karşılaştırın.
Fine-tuning gerçekte neyi düzeltir, neyi düzeltmez? Davranışı düzeltir — biçim, üslup, görev çerçevesi, reddetme kalıpları, alana özgü dil düzeyi (register). Seçilmiş olguları da öğretebilir, ama güncel kurumsal bilgiyi güvenilir ve kaynak gösterilebilir tutmak için erişimi ayrıca değerlendirin; fine-tuning ile modele eklenmiş bir olguyu güncellemek pahalı, kaynağını göstermek zordur. Meseleyi yerine oturtan çerçeve şu: temel model bozuk değildir, başka bir soruyu cevaplıyordur — bu metin verildiğinde, sonra ne gelir. Fine-tuning ona hangi soruyu sorduğunuzu öğretir; yeni cevapları güvenilir biçimde öğretmez ve fine-tuning, tam da bir ekip onu bilgi güncelleme mekanizması olarak kullandığında sık sık hayal kırıklığı yaratır. Sonra işin pratik yarısını söyleyin: önce hatanın bilgiden mi, prompt’tan mı, çıktı şemasından mı, model yeteneğinden mi geldiğini test edin; yöntemi buna göre seçin.
LoRA’yı doğrusal cebir bilen birine anlatın. \(W\)’yi dondurun ve \(\Delta W = BA\)’yı öğrenin; burada \(B\), \(d \times r\) ve \(A\), \(r \times k\) boyutunda, \(r \ll \min(d,k)\). İleri geçiş \(Wx + \frac{\alpha}{r}BAx\) olur ve servis zamanında \(\frac{\alpha}{r}BA\)’yı \(W\)’ye katabilirsiniz; böylece ayrı adaptör çarpımının yükü ortadan kalkar. Bunu gerçekten kullandığınızı gösteren iki ayrıntı: \(A\) rastgele ilkleniyor, \(B\) sıfırlanıyor; yani adaptör hiçbir etkisi olmayan bir işlem (no-op) olarak başlıyor ve eğitim 0. adımda ön eğitimli modeli sarsamıyor. Ayrıca \(\alpha\), adaptör yolunda kabaca bir öğrenme oranı çarpanı gibi davranıyor; \(\alpha = 2r\)’nin bir yasa değil bir gelenek olmasının sebebi de bu.
Fine-tuning ne kadar bellek ister? Tahmin yürütmek yerine ayrıştırın. Seçilmiş bir karma hassasiyetli Adam düzeninde eğitilebilir parametre başına: bf16 ağırlık 2, bf16 gradyan 2, fp32 ana ağırlık 4, fp32 \(m\) ve \(v\) toplam 8 bayt — kabaca 16 bayt statik parametre durumu. Sonra bu ayrıştırmanın atladığı ve küçük ölçekte çoğu zaman baskın olan terimi adlandırın: aktivasyonlar ve geçici tamponlar; batch, dizi uzunluğu ve checkpoint’lemeyle değişirler ve parametre dondurmak onları büyük ölçüde azaltmaz (laboratuvarda LoRA tepe belleği yalnızca 1,40 kat düşürdü). Bu son cümle, LoRA hakkında okumuş biriyle LoRA’nın belleğe sığmadığını bizzat görmüş biri arasındaki farkı ortaya koyar.
SFT mi DPO mu ve tercih ayarı neden ayrı bir aşama oldu? SFT, prompt başına tek bir hedeften “işte iyi bir cevap” öğretir. Bu cevap şundan iyidir’i ifade edemez ve yardımseverlik ya da ton gibi niteliklerde yargı karşılaştırmalıdır — tercih optimizasyonunun ayrı bir aşama olarak var olmasının sebebi de budur. DPO’nun katkısı, KL ile düzenlenmiş tercih hedefini ayrı bir ödül ağı eğitmeden optimize edebileceğinizi göstermesi: bu hedefte ödül, policy ile referansın log-oranı olarak ifade edilebilir (Rafailov vd. 2023). Ekleyebileceğiniz pratik bir not: SFT başlangıcı çoğu tarifte veri–referans uyumunu sağlar; temel model üzerinde DPO matematiksel olarak tanımlı, ama tercih verisi talimat izleyen bir modelden geliyorsa çoğu zaman hayal kırıklığı yaratır.
Ne zaman fine-tune etmezsiniz? Ölçülen sorunu daha basit bir prompt, şema ya da güvenilir erişim çözüyorsa; yeterli ve temiz eğitim ve değerlendirme veriniz yoksa; hedef davranış sık değişecekse; bakım ve gerileme maliyeti kazanımdan yüksekse ya da bozabileceğiniz şeyler için bir regresyon test paketi kuramıyorsanız. Dağıtım argümanını da ekleyin: adaptörlü dağıtım depolamayı ve kopya sayısını azaltır — ama trafik yönlendirme, sürüm ve eşzamanlılık maliyetlerini de ölçün.
Fine-tune ettiniz ve skor kötüleşti. Nasıl hata ayıklarsınız? Önce veri bölmesini, etiket dağılımını ve değerlendirme kodunun doğruluğunu kontrol edin. Sonra sohbet şablonunu kontrol edin: yanlış şablonla eğitmek, modele sunucunun asla göndermeyeceği bir formatı öğretir. Sonra modelin çoğunluk sınıfına kilitlenip kilitlenmediğine bakın; dengesiz bir görevde bu, makul görünen bir doğruluk gibi durur (bizimki azınlık sınıfında 0,00 F1 alırken %93,68 doğruluk gösteriyordu). Ardından öğrenme oranını kontrol edin: fazla yüksekse ön eğitimli yapıyı yıkar, fazla düşükse hiçbir şey yapmaz. Son olarak değerlendirmenizin hiç kıpırdayıp kıpırdamadığına bakın; donmuş bir sayı genelde eğitilebilir parametrelerin sandığınız parametreler olmadığı anlamına gelir. Bunlar olası nedenler; tek bir belirtiyi kesin bir nedene bağlamadan öğrenme oranını ve sınıf dengesini ayrı doğrulama deneylerinde sınayın.
9.14 Daha derine inmek için
Herhangi bir makaleden önce şunu yapın: bir sohbet modelinin tokenizer’ını açın ve iki turluk bir konuşma için tokenizer.apply_chat_template(messages, tokenize=False) çıktısını yazdırın. Rol ve sıra sonu işaretlerini doğrulamak, eğitim ile servis arasındaki bir şablon uyumsuzluğunu erkenden yakalamaya yardım eder; bunu yapmak da birkaç saniye sürer.
| kaynak | ne olduğu |
|---|---|
| Deep Dive into LLMs like ChatGPT — Andrej Karpathy | ön eğitimden RLHF’e üç saat; her eğitim aşamasının davranışının nereden geldiğine dair mevcut en açık anlatım |
trl |
tek bir kütüphanede SFT, DPO ve PPO, okunabilir eğiticilerle — her amacın gerçekte neyi optimize ettiğini görmenin en hızlı yolu |
peft |
LoRA ve akrabaları; kaynağı okunacak kadar kısa ve rankın gerçekte neyi değiştirdiğini çözüyor |
| Interconnects — Nathan Lambert | açık tarifler yayımlayan birinden, eğitim sonrası üzerine sürekli ve iyi kaynaklanmış yazılar |
| Lil’Log on reward hacking | her tercih optimizasyonu yönteminin devraldığı arıza kipi, düzgünce taranmış |
| konu | kaynak |
|---|---|
| bu bölümün büyük ölçüde anlattığı teknik | Hu vd. (2022) |
| tek bir karta sığdırmak | Dettmers vd. (2023) |
| LoRA neyin yerini aldı ve gecikme neden önemliydi | Houlsby vd. (2019); Lester vd. (2021) |
| talimat izlemeyi standart hâline getiren reçete | Ouyang vd. (2022) |
| dil modellerinden önce tercihler | Christiano vd. (2017); Stiennon vd. (2020) |
| PPO tabanlı RLHF güncellemesi | Schulman vd. (2017) |
| ayrı ödül ağı olmadan tercih ayarı | Rafailov vd. (2023) |
| değer kestiricisi yerine grup ödülü: GRPO | Shao vd. (2024) |
| doğrulanabilir ödüllerle akıl yürütme eğitimi | Guo vd. (2025) |
| her aşaması belgelenmiş açık bir reçete | Lambert vd. (2025) |
| ne kadar az SFT verisinin yetebileceği | Zhou vd. (2023) |
| veriyi yazmak yerine üretmek | Wang vd. (2023) |
| instruction tuning’in görülmemiş görevlere genellenmesi | Wei vd. (2022) |
| etiketleyiciler yerine ilkeler | Bai vd. (2022) |
| bir modeli küçültmek | Hinton vd. (2015) |
| daha fazla ön eğitimle bir alana uyarlanmak | Gururangan vd. (2020) |
| fine-tuning’in size başka yerde neye mal olduğu | Kirkpatrick vd. (2017); Luo vd. (2025) |
| önce denemeniz gereken prompting | Schulhoff vd. (2025) |
Bu bölümdeki doğrulanabilir ödül fikrini (GRPO ve RLVR) sonuna kadar götürdüğünüzde akıl yürüten modellere varırsınız; Bölüm 10 oradan devam ediyor.
9.15 Alıştırmalar
- İki farklı model ailesinde, iki turluk bir konuşma için
apply_chat_templateçıktısını yazdırın. Farklı olan her token’ı listeleyin. Sonra B ailesinin şablonuyla eğitilmiş bir modeli A ailesinin şablonuyla servis etmenin, neden hiçbir hata vermeden kaliteyi düşürdüğünü açıklayın. Açıklamanızı SFT’nin gerçekte neyi optimize ettiğine dayandırın. - Bölüm 9.3’teki örneği Llama 3’ün tokenizer’ıyla yeniden üretin: 31 token, 4’ü cevap. Hem maskeli hem maskesiz tercih için
labelstensörünü yazın ve her biri için kayıp terimlerinin hangi kesrinin prompt ve şablon konumlarından geldiğini hesaplayın; bu payı gradyan büyüklüğü sanmayın. Sonra iki maskeyle kısa bir pilot koşu yapıp cevap davranışını aynı prompt’larda karşılaştırın. - Bölüm 9.4, QLoRA’nın “>780 GB”ı için, ikisi de parametre başına 12 bayta çıkan iki olası ayrıştırma veriyor. Makalenin raporladığı ve raporlamadığı bellek kalemlerini ayırın; aralarında seçim yapmak için hangi kanıta ihtiyacınız olacağını söyleyin. Sonra 8 bitlik Adam için (\(m\) ve \(v\) birer bayt) varsaydığınız ağırlık, gradyan, ana kopya, momentler ve ölçek bilgisini tek tek listeleyerek koşullu bir toplam hesaplayın; eğitilen ve donmuş parametre arasındaki yeni oranı ve düşük hassasiyetin size makul olarak neye mal olabileceğini söyleyin. Sonucu gerçek tepe bellek olarak sunmayın.
- LoRA tablosunda (Bölüm 9.4) olmayan bir modelin
config.jsondosyasını açın ve gerçek hedefLinearmodüllerinin giriş/çıkış boyutlarını inceleyin (head_dim, gated MLP ve modül adları modele göre değişir). (a)q_proj, v_projve (b) attention + MLP üzerinde LoRA \(r=16\) için yalnızca adaptör parametrelerini hesaplayın. Sonra modelipeftile yükleyip toplam eğitilebilir sayıyla karşılaştırın; farkın kaynağını (bias’lar, bir sınıflandırma head’i ya da açık bırakılan başka modüller) modelde doğrulayın. - LoRA, \(A\)’yı rastgele, \(B\)’yi sıfır ilkler. \(A\) sıfır ve \(B\) rastgele olduğunda ne olacağını çıkarın: 0. adımda \(\partial\mathcal{L}/\partial A\) ve \(\partial\mathcal{L}/\partial B\)’yi yazın (sıfırdan farklı girdi ve üstten gelen gradyan varsayımını belirtin) ve koşunun oradan kurtulup kurtulmadığını söyleyin. Dört kombinasyondan ikisi tam olarak ön eğitimli modelden başlar ve genellikle sıfırdan farklı gradyana sahiptir — bunları belirleyin ve gradyanların ortak yanını söyleyin. Sonra aynı başlangıç çıktısının aynı eğitim yörüngesini garanti edip etmediğini sınayan bir deney önerin.
- Bir ekip, “modelimiz ürünlerimiz için yanlış fiyat veriyor” diyor ve fine-tuning istiyor. Karar ağacında (Bölüm 9.9) onlara beş cümlede adım adım yol gösterin. Sonra şikâyetlerinin, fine-tuning’in doğru cevap olduğu varyantını kurun ve bunun hangi veriyi gerektireceğini söyleyin.
- Elinizde 4.000 prompt, her birine yazılmış birer cevap ve modelin “fazla uzun konuştuğu ve fazla kolay onayladığı” şikâyeti var. Daha fazla SFT ile DPO arasında karar verin. Her biri için neyi, kaç kalem toplayacağınızı ve işe yarayıp yaramadığını bir hafta içinde nasıl anlayacağınızı söyleyin.
- Bir meslektaşınız temel model üzerinde DPO’nun kötü sonuç verdiği bir koşuyu “model henüz cevap vermiyor, dolayısıyla sıralanacak bir şey yok” diye açıklıyor. \(\mathcal{L}_{\text{DPO}}\)’ya bakın: kayıp eğitim sırasında yeni cevap üretiyor mu, neyi sabit tutuyor? Referans log-olasılıklarının rolünü açıklayın. Sonra bir temel model ile bir SFT modelini aynı tercih çiftleri üzerinde karşılaştıran, veri kapsamını ve değerlendirme sonuçlarını ölçen bir deney tasarlayın; başarısızlığı ya da nedenini ölçmeden varsaymayın.
- GRPO, değer modelini aynı prompt’tan alınan \(G\) örneğin ortalama ödülüyle değiştiriyor. Bağımsız örnekler varsayımında grup ortalamasının varyansı \(\operatorname{Var}(r)/G\)’dir. Öğrenilmiş bir değer kestiricisinin hata varyansını ve yanlılığını da hesaba katarak, hangi kestiricinin ortalama karesel hatasının daha düşük olacağını tartışın; örnekler bağımsız değilse korelasyonun etkisini belirtin. Sonra grup ortalamasının daha kötü bir baseline olacağı bir görev tarif edin.
- Türkçe bir müşteri destek modelinin fine-tuning’i için gerçekten çalıştıracağınız unutma değerlendirmesini tasarlayın. Benchmark’ı adlandırın, neden doğru benchmark olduğunu söyleyin ve yayına almayı reddedeceğiniz eşiği belirtin. Sonra eşiğin neden fine-tune edilmiş modelin sonuçlarını görmeden önce yazıya dökülmesi gerektiğini açıklayın.