LLM Fine-Tuning

Ağustos 23, 2026

| Yorumlar&nbsp0

“Biz de modeli fine-tune edelim” Gerçekten buna ihtiyacınız var mı? Varsa seçenekleriniz neler? Bu yazıda LoRA’dan QLoRA’ya, DPO’dan GRPO’ya yöntemlerin üzerinden geçeceğiz; ne zaman fine-tune etmek gerektiğini, ne zaman gerekmediğini ve birkaç dolarlık bir GPU kirasıyla neler yapılabileceğine bakacağız.

Bu yazıya “fine-tuning’in ne olduğunu duydum ama kafamda oturmadı” diyerek geldiyseniz tam yerindesiniz. Yazının sonunda, eğer sabrınız ve odağınız buna yeterse: elinizdeki problemin fine-tuning problemi olup olmadığına karar verebileceksiniz, LoRA’nın matematiğini bir kâğıda çizebilecek, rank ve alpha gibi sayıları körlemesine değil sebebini bilerek seçebilecek, DPO ile GRPO arasındaki farkı bir cümlede anlatabilecek ve en önemlisi — modelin gerçekten iyileşip iyileşmediğini ölçebileceksiniz.

1. Pre-Training ve Post-Training

Bir LLM’in hayatı iki büyük evreye ayrılır.

Pre-training (ön eğitim), base model‘i (temel model) sıfırdan var eden evredir. Binlerce GPU’dan oluşan cluster’larda, trilyonlarca token üzerinde aylarca süren, maliyeti on milyonlarca dolarla ölçülen bir iştir. OpenAI, Anthropic, Google, Meta, Alibaba gibi bir avuç şirketin yaptığı budur. Bu evrede model dünyaya dair bilgiyi öğrenir: dilbilgisini, olguları, kod yazmayı, akıl yürütmenin kalıplarını. Size, bana, ona, şuna, buna, şirketinize, falana, filana bu kapılar kapalı.

Post-training (eğitim sonrası) ise bu hazır modeli belli bir işe uyarlama evresidir. Fine-tuning (ince ayar) tam olarak bu evreye düşer. Burada model yeni bir dünya öğrenmez; zaten bildiğini nasıl kullanacağını öğrenir. Ölçek bambaşkadır: tek bir ekran kartında, birkaç saatte, birkaç dolara iş bitebilir^[12].

Şekil 1 — Pre-training bilgiyi yükler, post-training davranışı şekillendirir. Fine-tuning dediğimiz şey mavi ve turuncu kutuların içinde geçer; maliyet farkı beş-altı basamak [12].

2. Gerçekten Fine-Tuning Yapmak Gerekli Mi?

Yazının size en çok zaman ve para kazandıracak bölümü burası olabilir, çünkü fine-tuning projelerinin belki yarısı hiç başlamamalıydı.

Önce bir araştırma bulgusuyla girelim. Google ve Hebrew University ekibinin çalışması şunu gösterdi: modele fine-tuning sırasında yeni olgusal bilgi vermek, o bilgiyi öğretmekte çok yavaş kalıyor — ama öğrendiği anda modelin uydurma (hallucination) eğilimini doğrusal olarak artırıyor^[5]. Yani “şirketimizin 400 sayfalık ürün kataloğunu modele fine-tuning ile öğretelim” fikri, sadece verimsiz değil, aktif olarak zararlı. Modele bilmediği bir şeyi ezberletmeye çalıştığınızda ona öğrettiğiniz şey aslında bilmediği şeyler hakkında kendinden emin konuşmak oluyor.

O zaman kural net: bilgi eksikse RAG, davranış eksikse fine-tuning. Aşağıdaki merdiveni sırayla çıkın; her basamak bir üstündekinden kat kat ucuz ve hızlıdır^[17][18].

Şekil 2 — Merdiveni atlamak en sık yapılan hata. Her basamakta ölçün; ancak tavan yaptığınızda bir üste çıkın [17][18].

Peki fine-tuning tam olarak ne için iyi? Dört net senaryo var. Format ve tutarlılık: her seferinde aynı şemada JSON, aynı rapor iskeleti, aynı ton. Domain diline uyum: tıbbi kodlama, hukuki dilekçe, bankacılık jargonu — modelin bildiği ama alışkın olmadığı ifade biçimleri. Maliyet ve gecikme: devasa bir modelin prompt’a sığdırılmış 20 örnekle yaptığı işi, fine-tune edilmiş 8B’lik bir modele yaptırıp token maliyetini ve gecikmeyi katbekat düşürmek — buna distillation (damıtma) diyoruz ve prod’da en çok kazandıran senaryo genelde bu oluyor^[28]. Yeni beceri: modelin hiç görmediği bir çıktı yapısı, özel bir araç protokolü, kurum içi bir DSL.

Altın kural: Fine-tuning’e başlamadan önce prompt’u sonuna kadar zorlayın ve o performansı bir sayı olarak kaydedin. Yenmeye çalıştığınız rakam odur. Bu sayı elinizde yoksa fine-tuning’in işe yarayıp yaramadığını asla bilemezsiniz.

3. Nerede Fine-Tune Edeceğiz? Open Weight ve Closed Source Ayrımı

Fine-tune kararı verdiniz peki hangi model ailesiyle çalışacaksınız?

Open weight (açık ağırlıklı) modeller — Llama, Mistral, Qwen, Gemma, DeepSeek, gpt-oss — ağırlıklarını indirip kendi donanımınızda eğitmenize izin verir. Avantajları ciddi: veri makinenizden çıkmaz, maliyeti siz kontrol edersiniz, ürettiğiniz adapter dosyası sizindir, modeli istediğiniz yerde çalıştırırsınız. Bedeli de belli: GPU’yu siz bulacak, kurulumu siz yapacak, hata ayıklamayı siz yapacaksınız.

Closed source (kapalı kaynaklı) modeller — GPT ailesi, Claude, Gemini — ağırlıkları vermez; fine-tuning’i ancak sağlayıcının kendi API’si üzerinden yaparsınız. Verinizi yüklersiniz, onlar eğitir, size özel bir model kimliği döner. Kurulum derdi yoktur, altyapı sizin sorununuz değildir; buna karşılık veri sağlayıcının tarafına gider, fiyatlandırma token başınadır ve motorun kapağını açamazsınız. Bir de kaygan zemin var: sağlayıcılar bu servisleri kendi takvimlerine göre açıp kapatabiliyor — örneğin OpenAI’ın reinforcement fine-tuning servisi, mevcut kullanıcılar için bir süre daha çalışacak şekilde kapatılmaya başlandı^[9].

	Open weight (Llama, Qwen, Mistral…)	Closed source (GPT, Gemini…)
Veri gizliliği	Veri sizin altyapınızda kalır	Veri sağlayıcıya yüklenir
Maliyet modeli	GPU saati (7B QLoRA ≈ 3 $)^[12]	Token başına (16B’ye kadar ≈ 0.48 $/1M token)^[12]
Yöntem esnekliği	LoRA, QLoRA, full FT, DPO, GRPO — hepsi	Sağlayıcının sunduğu kadarı
Kurulum yükü	Yüksek	Neredeyse yok
Taşınabilirlik	Adapter dosyası sizin, her yerde koşar	Sağlayıcıya bağlısınız

Pratikte çoğu ekip open weight tarafında başlıyor, çünkü bir deneyin maliyeti bir öğle yemeğinden ucuz. Bu yazının geri kalanı da ağırlıklı olarak o tarafı anlatacak — zaten kavramların hepsi diğer tarafta da aynı isimle geçiyor.

4. PEFT ve LoRA: Fine-Tuning’i Herkese Açan Fikir

Şimdi işin kalbine geliyoruz. PEFT (parameter-efficient fine-tuning, parametre-verimli ince ayar), modelin tamamını değil küçücük bir kısmını eğitme fikrinin genel adıdır. Ailenin en meşhur üyesi LoRA (low-rank adaptation, düşük ranklı uyarlama).

Mantığı şaşırtıcı derecede zarif. Bir modelin katmanındaki ağırlık matrisi W’yi eğitmek yerine, W’yi donduruyoruz ve yanına iki tane ince matris ekliyoruz: A ve B. Modelin çıktısı artık W·x + B·A·x oluyor. A ve B matrislerinin ortak boyutu — buna rank deniyor — 8, 16, 32 gibi minicik bir sayı. Sonuç: eğitilen parametre sayısı toplamın binde biri, hatta on binde biri seviyesine iniyor^[16].

Şekil 3 — LoRA orijinal ağırlığa dokunmaz, yanına düşük ranklı bir “fark” ekler. Eğitilen parametre oranı tipik olarak %1’in altındadır [16].

Adapter, base model’in yanına takılan ve eğitim sırasında yalnızca kendisi güncellenen küçük ek ağırlık setidir — yukarıdaki A ve B matrisleri; modele takıp çıkarabildiğiniz bir eklenti gibi düşünün.

Rank ve alpha’yı neden bu değerlerde seçiyoruz?

Tablodaki sayılar gökten inmedi. İkisini birden anlamak için tek bir formül yeterli: LoRA’nın modele eklediği fark ham haliyle B·A değil, (α/r)·B·A‘dır. Yani alpha tek başına bir ayar düğmesi değil; belirleyici olan α/r oranı. PEFT’in varsayılan davranışı da tam olarak bu ölçeklemedir [16].

Buradan iki pratik sonuç çıkıyor. Birincisi, “alpha’yı r’nin iki katı yap” tavsiyesinin gerçek anlamı “oranı 2’de sabitle” dir: r’yi 16’dan 32’ye çıkarırken alpha’yı da 32’den 64’e çıkarırsanız adapter’ın kapasitesini büyütmüş ama etkisinin şiddetini sabit tutmuş olursunuz — tek bir değişkeni oynatmış olursunuz, iki değil. İkincisi, α/r oranını 1’in altına düşürmek adapter’ın katkısını kısmak demektir; öğrendiğini yarı sesle konuşturursunuz. Bu arada eğitimden sonra alpha’yı düşürmek, overfit olmuş bir adapter’ı yumuşatmanın en ucuz yoludur — tablodaki “alpha’yı 0.5 ile ölçekle” numarası tam olarak budur [3].

Peki neden A rastgele, B sıfır başlıyor? Çünkü B sıfırken B·A = 0 olur; yani eğitimin sıfırıncı adımında model tam olarak base model’in kendisidir. LoRA hiçbir zaman “önce modeli bozup sonra toparlamaz”, her seferinde bilinen iyi bir noktadan başlar. PEFT’in varsayılanı da budur: A için Kaiming-uniform, B için sıfır [16].

Son bir uyarı: α/r ölçeklemesinin bilinen bir zayıflığı var. r büyüdükçe bu bölme gradyanların büyüklüğünü sistematik olarak küçültüyor ve yüksek rank’lerde eğitim fiilen duruyor. rsLoRA bunu ölçeği α/√r yaparak çözüyor; böylece gradyanlar rank’ten bağımsız olarak aynı mertebede kalıyor [30]. Pratik karşılığı şu: r’yi 64–128 gibi değerlere çıkaracaksanız use_rslora=True verin, yoksa “rank’i büyüttüm ama hiçbir şey değişmedi” tuzağına düşersiniz.

Üç cümlelik özet: r kapasiteyi belirler, α/r şiddeti belirler. B’nin sıfırdan başlaması eğitimin base model’den başlamasını garanti eder. Yüksek rank’e çıkarken ölçeklemeyi √r’ye çevirin.

QLoRA: aynı fikir, dörtte bir bellekle

QLoRA, LoRA’nın üzerine bir kat daha atar: donmuş base model’i 4-bit’e quantize eder, LoRA adapter’larını ise normal hassasiyette eğitir. Orijinal makale üç yenilik getiriyor: normal dağılıma göre optimize edilmiş NF4 (4-bit NormalFloat) veri tipi, quantization sabitlerinin kendisini de sıkıştıran double quantization ve bellek zirvelerini yöneten paged optimizers. Sonuç çarpıcı: 65 milyar parametreli bir modeli tek bir 48 GB’lık GPU’da fine-tune etmek mümkün hale geliyor ve 16-bit tam fine-tuning kalitesi korunuyor. Aynı çalışmadaki Guanaco modeli, tek GPU’da 24 saatlik eğitimle o günün ChatGPT’sinin performansının %99.3’üne ulaşmıştı^[2].

Bugün pratikte varsayılan tercih QLoRA’dır. Bellek kısıtınız yoksa saf LoRA biraz daha hızlı ve bir tık daha kaliteli olur; ama tek kart üzerinde çalışıyorsanız QLoRA’nın açtığı kapı çok daha geniş^[1].

Full fine-tuning: ne zaman gerçekten gerekir?

Full fine-tuning (tam ince ayar), modelin her parametresini günceller. Kalitesi tavan yapar ama bedeli ağırdır: 70B’lik bir modelin tam fine-tuning’i 11 adet H100 üzerinde ~32 saat, yani yaklaşık 1.785 dolar — aynı modelin QLoRA’sı ise ~20 dolar^[12]. Üstelik çıktı, base model kadar büyük yepyeni bir model dosyasıdır; her müşteri için ayrı bir tane tutmayı düşünün.

Peki kalite farkı gerçekten var mı? Var, ama sandığınız yerde değil. “LoRA Learns Less and Forgets Less” başlıklı kapsamlı çalışma iki şeyi birden gösterdi: LoRA, kod ve matematik gibi modelin gerçekten yeni bir beceri kazanması gereken alanlarda full fine-tuning’in gerisinde kalıyor — ama buna karşılık base model’in diğer yeteneklerini çok daha iyi koruyor ve üretim çeşitliliğini kaybetmiyor. Araştırmacılar ayrıca full fine-tuning’in tipik LoRA ayarlarından 10–100 kat yüksek etkin rank’lerde değişim yaptığını buldu; performans farkının kaynağı büyük ölçüde bu^[4]. Yani “LoRA yetmezse rank’i yükselt” tavsiyesinin arkasında sağlam bir gerekçe var.

Pratik karar: Domain uyarlaması, format, ton, araç kullanımı → QLoRA ile başla. Modelin gerçekten yeni bir beceri kazanması gerekiyorsa (yeni bir programlama dili, çok özel bir muhakeme biçimi) önce rank’i 64–128’e çıkarmayı dene; hâlâ yetmiyorsa full fine-tuning’i konuş.

5. Alignment: Modele “Hangi Cevap Daha İyi” Öğretmek

Önce terimi netleştirelim, çünkü bu kelime ortalıkta çok dolaşıyor ama ne dediği pek anlatılmıyor. Alignment (hizalama), modelin davranışını insanın istediği yöne çekme işidir. SFT’den farkı şu: SFT’de modele “işte doğru cevap, bunu yaz” dersiniz. Alignment’ta ise doğru cevap diye tek bir şey yoktur; elinizde iki cevap vardır ve “şu, şundan daha iyi” dersiniz. Model de tek tek cevapları değil, tercihinizi öğrenir.

Neden ayrı bir aşamaya ihtiyaç duyuyoruz? Çünkü bazı nitelikleri örnekle göstermek imkânsıza yakındır. “Daha kibar”, “daha güvenli”, “gereksiz uzatmayan”, “emin olmadığında emin değilim diyen” — bunların hiçbirinin tek bir doğru metni yoktur. Ama iki cevabı yan yana koyduğunuzda hangisinin daha iyi olduğunu bir insan saniyesinde söyler. Alignment tam olarak bu sinyali kullanır. ChatGPT’yi ham GPT’den ayıran şeyin büyük kısmı da budur.

Bu işi yapmanın üç yolu var ve aralarındaki fark, “iyi cevap” sinyalini nereden aldıklarında yatıyor.

RLHF (reinforcement learning from human feedback, insan geri bildirimiyle pekiştirmeli öğrenme) klasik yöntemdir ve üç aşamalıdır: insanlar cevap çiftlerini karşılaştırıp hangisini tercih ettiklerini işaretler; bu verilerle ayrı bir reward model (ödül modeli) eğitilir — yani “insan bu cevaba kaç puan verirdi” sorusunu tahmin eden ikinci bir model; sonra PPO ile ana model, ödül modelinden yüksek puan alacak şekilde güncellenir.

PPO’yu (proximal policy optimization) da açalım, çünkü yazının geri kalanında karşımıza çıkacak. Pekiştirmeli öğrenmenin standart algoritmalarından biridir; modelin davranışını ödüle göre iterek iyileştirir ama bunu yaparken her adımda ne kadar değişebileceğini sınırlar — “proximal” (yakın) kelimesi buradan geliyor. Bu fren olmadan model, ödülü avlamak uğruna dil yeteneğini bozacak kadar savrulur. PPO ayrıca critic adı verilen üçüncü bir modele daha ihtiyaç duyar; critic’in işi “bu noktadan sonra ortalama ne kadar ödül gelir” tahminini yapmaktır. Yani RLHF eğitimi sırasında bellekte aynı anda dört model dolaşır: eğitilen model, referans kopyası, reward model ve critic. Güçlü ama hantal; kararsız eğitim ve bol hiperparametre demek^[20].

DPO (direct preference optimization, doğrudan tercih optimizasyonu) bu zincirin ortasındaki halkayı çıkarır. Ödül modeli de eğitmez, critic de kullanmaz; tercih verisini doğrudan bir loss function‘a (kayıp fonksiyonu — eğitim sırasında “ne kadar yanlıştayım” sayısını üreten formül) çevirir ve modeli tek adımda optimize eder. Model “iyi” işaretli cevabın olasılığını artırırken “kötü” işaretlininkini düşürür; arada ödül modeli yoktur, doğrudan tercih verisiyle çalışır — adındaki “direct” tam olarak bunu anlatıyor. Basit, kararlı ve ucuzdur; bu yüzden bugün çoğu ekibin ilk tercihi^[21]. Ailenin DAPO, KTO, ORPO gibi başka üyeleri de var; ama omurgayı anladıysanız hepsi aynı fikrin varyasyonu^[8].

GRPO (group relative policy optimization) ise muhakeme (reasoning) modelleri çağının yıldızı. Az önce anlattığımız critic’i tamamen atar — “bu cevap ne kadar iyi” sorusunu ayrı bir modele sordurmak yerine, cevapları birbiriyle yarıştırır. Bunun yerine her prompt için bir grup cevap üretir — tipik olarak 16 ila 64 tane — ve her cevabın avantajını grubun ortalamasına göre hesaplar: ortalamayı çıkar, standart sapmaya böl, bitti. Critic’i atmak eğitim belleğini kabaca yarıya indiriyor (1B parametre başına ~32 GB yerine ~16 GB)^[6].

GRPO’nun asıl gücü RLVR (reinforcement learning with verifiable rewards, doğrulanabilir ödüllü pekiştirmeli öğrenme) ile birleştiğinde ortaya çıkıyor. Fikir çok sade: ödülü bir sinir ağına sordurmayın, hesaplayın. Matematik sorusunda cevabı ground truth ile karşılaştırın; kod sorusunda test’leri sandbox’ta koşturun; format kuralına uyulmuşsa puan verin. DeepSeek-R1 tam olarak böyle eğitildi: ~1.000 uzun chain-of-thought örneğiyle bir “cold start” SFT, ardından doğrulanmış matematik ve kod üzerinde büyük ölçekli GRPO, sonra rejection sampling ile veri üretimi ve son olarak karma bir RL turu. Bu süreçte model, kimse öğretmeden kendi cevabını gözden geçirmek ve alternatif yollar denemek gibi davranışlar geliştirdi^[6][7].

Şekil 4 — RLHF ödül modelini eğitir, DPO onu atlar, GRPO hem ödül modelini hem critic’i atıp ödülü doğrudan hesaplar. Sağa gittikçe altyapı hafifler ama “ödülü nasıl hesaplayacağım” sorusu ağırlaşır [6][20][21].

Buradan pratik bir seçim kuralı çıkıyor. Cevabın doğruluğu otomatik kontrol edilebiliyorsa (test geçiyor mu, sayı tutuyor mu, şema geçerli mi) → GRPO/RLVR. Doğru/yanlış yoksa ama “bu cevap şundan iyi” diyebiliyorsanız → DPO. İkisi de yoksa ve elinizde sadece ideal cevaplar varsa → düz SFT yeter, alignment aşamasına hiç girmeyin.

Bu arada kapalı kaynaklı taraf da aynı fikri paketliyor: OpenAI’ın reinforcement fine-tuning servisinde siz bir grader (puanlayıcı) tanımlıyorsunuz — string karşılaştırması, başka bir modele puanlatma ya da bunların ağırlıklı bileşimi — sistem her prompt için birden çok cevap üretip puanlıyor ve yüksek puanlıları güçlendiriyor. Servis, birkaç düzine ile birkaç yüz örnek arasında denemeye başlamanızı öneriyor^[9]. Yani kavram aynı, ambalaj farklı.

6. Veri: Projeyi Yapan da Bozan da Bu

Şimdi bütün deneyimli insanların aynı şeyi söylediği bölüme geldik: fine-tuning’de sonucu belirleyen tek en büyük etken veri kalitesidir. Algoritma seçimi, hiperparametreler, GPU markası — hepsi veri kalitesinin yanında ikinci plandadır. Kötü veriyle en iyi yöntem bile size kötü bir model verir; iyi veriyle mütevazı bir yöntem bile şaşırtır.

Kaç örnek lazım?

En sık sorulan soru bu ve cevabı “duruma göre” değil, aslında oldukça somut. Görev tipine göre kabaca şu aralıklar geçerli^[10]:

Görev tipi	Örnek sayısı	Not
Sınıflandırma (classification)	Kategori başına 100–300	Temiz 200–300 örnekle doğruluk %90’ların üstüne çıkabiliyor
Yapılandırılmış çıkarım (extraction)	200–500	Şema tutarlılığı en kritik nokta
İçerik üretimi	500–2.000	Ton ve üslup çeşitliliği önemli
Karmaşık domain görevleri	1.000–5.000	Uzman doğrulaması şart

Ve altını çizelim: özenle seçilmiş 200 örnek, aceleyle toplanmış 2.000 örneği yener. Tek bir bozuk örnek bile modele yanlış bir kalıp öğretebilir ve bu kalıp eğitim boyunca kalıcılaşır^[10]. QLoRA makalesinde 1.000’den fazla model eğiten ekip de aynı sonuca varmıştı: küçük ama yüksek kaliteli veri seti, büyük ve dağınık olana fark atıyor^[2].

Maliyet tarafında bir uyarı: insan etiketlemesi basit görevlerde örnek başına 1–5 dolar, uzmanlık gerektiren domain’lerde 10–50 dolar bandında^[10]. Yani 2.000 örneklik bir tıbbi veri seti, GPU maliyetinizin yüz katına mal olabilir. Bu yüzden ilk bakacağınız yer sıfırdan etiketleme değil, kurumunuzun zaten ürettiği kayıtlar olmalı: kapanmış destek talepleri, onaylanmış raporlar, insan tarafından düzeltilmiş çıktılar.

Verinin şekli

Veri formatı yöntemle birlikte değişir ve karıştırmak en yaygın hatalardan biri:

# SFT — ideal cevabı gösterirsin
{"messages": [
  {"role": "system",    "content": "Sen bir sigorta hasar uzmanısın."},
  {"role": "user",      "content": "Aracım dolu yağdı, poliçem kasko."},
  {"role": "assistant", "content": "{\"hasar_tipi\":\"dogal_afet\",\"kapsam\":\"kasko\",...}"}
]}

# DPO — iki cevabı karşılaştırırsın
{"prompt": "Aracım dolu yağdı, poliçem kasko.",
 "chosen":   "Dolu hasarı kasko kapsamındadır. Şu adımları izleyin: ...",
 "rejected": "Sigortacınızla görüşmenizi öneririm."}

# GRPO / RLVR — cevabı değil, DOĞRULANABİLİR hedefi verirsin
{"prompt": "Şu poliçe için ödenecek tutarı hesapla: ...",
 "answer": "14750.00"}   # ödül fonksiyonu bunu kontrol eder

Üç teknik detay hayat kurtarır. Birincisi, chat template: her model ailesi mesajları kendi özel formatıyla bekler; yanlış şablon kullanırsanız model eğitim sırasında hiç görmediği bir yapıya bakar ve sonuç berbat olur. Kullandığınız kütüphanenin şablonu tokenizer’dan doğru çektiğinden emin olun. İkincisi, loss masking: kaybı sadece assistant cevabı üzerinden hesaplayın, kullanıcı mesajını modele ezberletmeyin. Üçüncüsü, ayrıştırma: veriyi daha ilk günden eğitim / doğrulama (validation) / test diye ayırın ve test setine eğitim boyunca asla bakmayın. Kapalı kaynaklı sağlayıcıların SFT rehberleri de aynı üç noktayı ilk teşhis adımı olarak sayıyor^[29].

7. Hiperparametreler: Hangi Vida Ne İşe Yarıyor?

LoRA’da ayarlanacak sayı aslında çok az, ama her biri anlamlı. Unsloth’un derlediği pratik değerler, sahadaki fiili başlangıç noktası sayılabilir^[3]:

Parametre	Önerilen	Ne yapar?
`r` (rank)	16 veya 32 ile başla (8–128 aralığı)	Adapter’ın kapasitesi. Büyütmek daha çok öğrenir ama daha çok bellek ve overfitting riski
`lora_alpha`	`r` ya da `2r`	Adapter’ın etkisinin ölçeği. alpha/r oranını 1’in altına düşürmeyin
`learning_rate`	2e-4 (LoRA/QLoRA) 5e-6 (DPO/GRPO)	RL yöntemlerinde çok daha düşük olması şart, yoksa model dağılır
`num_epochs`	1–3	3’ün ötesi genelde ezberleme demek
Etkin batch size	16 (örn. batch 2 × grad. accum. 8)	Gradient accumulation ile küçük kartlarda büyük batch taklit edilir
`target_modules`	`q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj`	Sadece attention’a değil, MLP katmanlarına da uygulamak kaliteyi belirgin artırır
`lora_dropout`	0	Modern kütüphanelerde varsayılan; regularizasyonu weight decay ile yapın
`weight_decay`	0.01 – 0.1	Overfitting’e karşı ilk savunma hattı
Warmup	Toplam adımın %5–10’u	Eğitimin ilk anlarındaki sarsıntıyı yumuşatır

Rank ve alpha ilişkisi kafa karıştırıcı olabiliyor; en yalın haliyle şöyle düşünün: r adapter’ın ne kadar şey öğrenebileceğini, alpha ise öğrendiğinin ne kadar dinleneceğini belirler. Pratikte pek çok kişi alpha’yı r’nin iki katında sabitleyip sadece r ile oynuyor^[19].

Eğitim ekranına bakarken ne göreceksiniz?

İki tehlike sinyalini ezberleyin. Overfitting (aşırı uyum): training loss 0.2’nin altına iniyorsa model veriyi ezberliyor demektir; gördüğü örneklerde mükemmel, görmediklerinde berbat olacaktır. Çare: epoch sayısını 1–2’ye indirin, weight decay’i 0.1’e çıkarın, learning rate’i düşürün, veriyi çeşitlendirin. Underfitting (yetersiz uyum): loss bir yerde takılıp kalıyorsa ya rank’i büyütün, ya learning rate’i yükseltin, ya da veri ekleyin^[3]. Eğitim loss’u ile validation loss’unun makas açması da klasik overfitting işaretidir.

8. En Kritik ve En Çok İhmal Edilen Adım: Evaluation

Bir itirafla başlayalım: fine-tuning projelerinin çoğu, modelin gerçekten iyileşip iyileşmediğini hiçbir zaman öğrenemiyor. Sebep şu — insanlar 20-30 örneğe bakıp “vay, çok daha iyi olmuş” diyor ve prod’a çıkıyor. Bu ölçüm değil, izlenim.

Sağlam bir değerlendirme kurgusu dört ayrı sete ihtiyaç duyar^[13]:

Göreve özel holdout seti: Modelin hiç görmediği, hedef görevden örnekler. Overfitting’i burada yakalarsınız.
Yetenek kayması (capability drift) seti: MMLU, GSM8K, IFEval gibi genel benchmark’lar. Modelin eski yeteneklerini kaybedip kaybetmediğini burada görürsünüz.
Güvenlik ve reddetme seti: Fine-tuning, base model’in güvenlik eğitimini zayıflatabilir. Jailbreak ve prompt injection denemelerini burada koşturun.
Base model’e karşı eşli karşılaştırma (arena): Gerçek prod örneklerinde eski ve yeni modelin cevaplarını yan yana koyup hangisinin kazandığını sayın. En güçlü sinyal budur.

Kaç örneğe bakmak lazım? Bir örnekle anlatalım

Diyelim 200 gerçek soruda eski ve yeni modeli yarıştırdınız; yeni model 106’sında kazandı, yani %53. Sevinip prod’a çıkmak var, bir de şunu sormak var: “Aynı testi 200 başka soruyla tekrarlasam yine %53 mü çıkardı?”

Cevap: hayır. Bu ölçekte sonucun doğal oynama payı kabaca ±7 puan. Yani gerçek başarı oranınız %46 ile %60 arasında herhangi bir yerde olabilir — %50’nin altı da bu aralığın içinde. Başka deyişle elinizdeki veri, yeni modelin eskisinden kötü olma ihtimalini bile eleyemiyor. Ölçtüğünüz şey iyileşme değil, zar atışı^[13].

Kural şu: sonucu tek bir sayı olarak değil, bir aralık olarak okuyun ve aralığın en kötü ucu hâlâ berabere çizgisinin üstündeyse kazandınız demektir. Yukarıdaki örnekte alt uç %46 olduğu için karar veremezsiniz. 500 soruya çıkarsanız oynama payı ±4.5 puana iner; %53’ün alt ucu %48.5 olur — hâlâ yetersiz. Ama 500 soruda %58 çıkarsa alt uç %53.5’e gelir ve artık “bu model gerçekten daha iyi” diyebilirsiniz.

Aynı mantık diğer setler için de geçerli: 50 örnekte gördüğünüz 0.3 puanlık iyileşme neredeyse kesinlikle gürültüdür. Pratik hedef, eşli karşılaştırma için 300–500 örnek^[13].

Catastrophic forgetting: modelin sessizce unutması

İkinci setin neden gerekli olduğunu anlatan somut bir bulgu: art arda birden fazla göreve fine-tune edilen bir modelde, ilk görevin doğruluğu üç görev sonra %89.3’ten %67.2’ye düşüyor — 24.8 puanlık bir kayıp. Mekanizmayı inceleyen çalışma, katmanlardaki attention head’lerin %15–23’ünün ciddi biçimde yeniden düzenlendiğini gösteriyor; ve unutmanın şiddetini en iyi öngören şey görevlerin birbirine benzerliği (r=0.87)^[14]. Yani “zaten yakın konularda eğitiyoruz, bir şey olmaz” sezgisi tam tersine çalışıyor.

Çareler ne? İlk savunma zaten LoRA’nın kendisi: orijinal ağırlıklara dokunmadığı için full fine-tuning’e kıyasla belirgin biçimde daha az unutturuyor^[4]. İkincisi, eğitim verisine genel yetenekleri koruyan bir miktar “karışık” örnek serpiştirmek. Üçüncüsü, katman dondurma ve ortogonal alt uzayda eğitim gibi daha yeni teknikler — kurumsal tarafta OSFT gibi yaklaşımlar tam bu problemi hedefliyor^[22].

9. Araç Kutusu ve Maliyet

Önce şu araçların ne işe yaradığını netleştirelim. Bir fine-tuning koşusunda yapılması gereken işler kabaca şunlar: base model’i belleğe yükle, doğru chat template ile veriyi token’lara çevir, LoRA adapter’larını modele tak, eğitim döngüsünü çevir (ileri geçiş, loss hesabı, geri yayılım), belleği kartın kapasitesine sığdır, birden fazla GPU varsa işi aralarında böl, aralıklarla checkpoint yaz ve sonunda adapter’ı kaydet. Bunların hepsini PyTorch ile elle yazabilirsiniz — ama kimse yazmıyor, çünkü bu araçlar tam olarak bu zinciri hazır veriyor. Sizin yazdığınız şey birkaç satırlık bir config dosyasına iniyor; gerisini onlar hallediyor.

Aralarındaki fark da bu zincirin hangi halkasını iyileştirdiklerinden geliyor: kimi eğitim döngüsünü hızlandırıyor, kimi çok GPU’ya bölmeyi kolaylaştırıyor, kimi de hiç kod yazmadan çalıştırmanızı sağlıyor. Dört isim öne çıkıyor ve seçim büyük ölçüde kaç GPU’nuz olduğuna bağlı^[11]:

Araç	Güçlü yanı	Kim için?
Unsloth	Elle yazılmış Triton kernel’leriyle tek GPU’da rakipsiz: Llama 3.1 8B’de ~2x, MoE modellerde 7.3x’e varan hızlanma; 8 GB VRAM’de rakipleri OOM verirken 2.972 token’lık context ile eğitim yapabiliyor	Tek kart, LoRA/QLoRA
Axolotl	YAML ile FSDP2, DeepSpeed, tensor/context/expert paralelliği — çok GPU’da en derin yapılandırma	2–8 GPU, uzun context
TRL (Hugging Face)	SFT, DPO, GRPO trainer’larının referans implementasyonu; diğerleri bunun üstüne kuruluyor	Kendi eğitim döngüsünü yazanlar
LLaMA-Factory	100+ model desteği, Gradio arayüzüyle kod yazmadan eğitim	Hızlı başlangıç, geniş model yelpazesi

İyi haber şu ki bunlar birbirini dışlamıyor: LLaMA-Factory arka planda Unsloth’u çalıştırabiliyor, TRL’in de Unsloth entegrasyonu var^[11]. Hangisiyle başlarsanız başlayın, resmi dokümantasyonlarındaki hazır örnekler bir saat içinde ilk koşunuzu attırır^[25]^[26]^[27].

Rakamlarla konuşalım: bu iş kaça patlıyor?

Fine-tuning’in bu kadar yaygınlaşmasının sebebi maliyetin sandığınızdan çok düşük olması. Güncel GPU kiralama fiyatlarıyla tipik koşular şöyle^[12]:

İş	Donanım	Süre	Maliyet
7B QLoRA (50K örnek, 2 epoch)	1× RTX 5090	~3 saat	~2.76 $
70B QLoRA (25K örnek)	1× H100 PCIe	~10 saat	~20 $
70B LoRA	2× H100 SXM5	8–14 saat	81–142 $
70B full fine-tuning	11× H100 SXM5	~32 saat	~1.785 $

Aynı işi API üzerinden yaptırmak genelde daha pahalı: 7B’lik bir QLoRA işi (~51M token) kendi GPU’nuzda 2.76 dolarken, token bazlı servislerde 24–26 dolar bandına çıkıyor — yaklaşık 9 kat^[12]. Buna karşılık API tarafında hiç kurulum derdi yok; küçük ölçekte bu fark çoğu ekip için kabul edilebilir.

Buradan çıkan mesaj: Bir fine-tuning denemesi artık bir öğle yemeği kadar tutuyor. O yüzden “acaba işe yarar mı” diye aylarca tartışmak yerine küçük bir veri setiyle bir gecede deneyin. Pahalı olan GPU değil, veri hazırlama ve değerlendirme emeği.

10. Eğitim Bitti, Peki Nasıl Servis Edeceğiz?

Elinizde artık bir adapter dosyası var. İki yol ayrılıyor.

Merge (birleştirme): Adapter’ı base model’e kaynaştırıp tek bir model çıkarırsınız. Çıkarım (inference) sırasında sıfır ek maliyet olur, her araçla çalışır; ama her varyant için base model boyutunda ayrı bir dosya taşımanız gerekir.

Adapter olarak servis: Base model bellekte tek kopya durur, adapter’lar üstüne dinamik olarak takılır. vLLM bunu --enable-lora ile yapıyor; max_loras ile aynı anda kaç adapter’ın aktif olacağını, max_lora_rank ile hangi rank’e kadar destekleneceğini belirliyorsunuz, adapter’ları çalışırken ekleyip çıkarabiliyorsunuz^[15]. Bu mimarinin en güzel tarafı çok kiracılı (multi-tenant) senaryolarda ortaya çıkıyor: tek bir GPU’da tek base model üzerinde onlarca müşteriye özel adapter servis edebilirsiniz — her müşteri için ayrı model kopyası tutmaya kıyasla bellek tasarrufu dramatik^[23]^[24].

# Adapter'ı vLLM ile servis etmek
vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --enable-lora \
  --max-loras 4 \
  --max-lora-rank 32 \
  --lora-modules hasar-uzmani=/adapters/hasar-v3 \
                 rapor-yazari=/adapters/rapor-v1

# İstekte hangi adapter'ı istediğinizi model adıyla söylersiniz
curl http://localhost:8000/v1/chat/completions -d '{
  "model": "hasar-uzmani",
  "messages": [{"role":"user","content":"Dolu hasarı kapsamda mı?"}]
}'

Bir de sürüm disiplini notu: adapter’larınızı hangi base model sürümü, hangi veri seti ve hangi hiperparametrelerle üretildiğini kaydederek versiyonlayın. Base model bir güncelleme aldığında eski adapter’ın aynı davranışı vereceğinin garantisi yoktur.

11. En Sık Yapılan On Hata

Bu bölüm, yukarıda anlattığımız her şeyin acı tarafı. Sırayla:

Baseline ölçmeden başlamak. Neyi yendiğinizi bilmiyorsanız kazandığınızı da bilemezsiniz. İlk iş, en iyi prompt’un skorunu bir yere yazmak.
Bilgi problemini fine-tuning ile çözmeye çalışmak. Modele bilmediği olguları ezberletmeye çalışmanın karşılığı daha çok uydurma oluyor^[5]. Bilgi eksikse RAG.
Emeği yanlış yere harcamak. Hiperparametre denemeleriyle geçen bir hafta, veriyi temizlemekle geçen bir güne değmez.
Yanlış chat template kullanmak. Model eğitimde bir formatı, çıkarımda başkasını görüyor; sonuç anlamsız cevaplar.
Loss masking yapmamak. Kaybı kullanıcı mesajı üzerinden de hesaplarsanız modele soruları da ezberletirsiniz.
Çok fazla epoch koşmak. Training loss 0.2’nin altına indiyse durun — o noktadan sonrası ezberleme^[3].
Sadece hedef görevde ölçmek. Model yeni işi öğrenirken eski yeteneklerini kaybediyor olabilir; genel benchmark’ları da koşturun^[13]^[14].
DPO/GRPO’da SFT’nin learning rate’ini kullanmak. 2e-4 ile RL yaparsanız model dağılır; oralarda 5e-6 civarındasınız^[3].
Test setine eğitim boyunca bakmak. Farkında olmadan ona göre optimize edersiniz ve test setiniz artık hiçbir şey ölçmez.
Veri sızıntısı (data leakage). Test örneklerinin eğitim setinde de bulunması. Ekranda mükemmel görünüp prod’da çöken modellerin bir numaralı sebebi budur.

12. Toparlayalım: Sıfırdan Bir Fine-Tuning Projesinin Yol Haritası

Bütün yazıyı tek bir akışa dizelim:

1. PROBLEMİ ADLANDIRIN
   Bilgi eksikliği mi, davranış eksikliği mi?  → Bilgi ise RAG'e gidin, buraya dönmeyin.

2. BASELINE KURUN
   En iyi prompt + few-shot ile bir sayı üretin. Yenilecek rakam budur.

3. EVAL SETİNİ ÖNCE YAZIN
   Görev holdout + genel benchmark + güvenlik + base'e karşı arena. Eğitimden ÖNCE.

4. VERİYİ TOPLAYIN
   200–2.000 temiz örnek. Mevcut kurum kayıtlarınızdan başlayın.
   Train / validation / test ayrımını ilk gün yapın.

5. QLORA İLE İLK KOŞU
   r=16, alpha=32, lr=2e-4, 2 epoch, etkin batch 16.
   Tek kart, birkaç saat, birkaç dolar.

6. ÖLÇÜN
   Dört sette de ölçün. Güven aralığının alt sınırı sıfırı geçiyor mu?
   Geçmiyorsa: önce veriye dönün, hiperparametreye değil.

7. GEREKİYORSA ALIGNMENT YAPIN
   Doğruluk otomatik kontrol edilebiliyorsa GRPO/RLVR, edilemiyorsa DPO.

8. SERVİS EDİN
   Tek varyant → merge. Çok müşteri/çok görev → vLLM ile multi-LoRA.
   Adapter'ları versiyonlayın, prod'da canary ile açın.

Kapanış

Fine-tuning’in etrafındaki sis aslında üç cümleyle dağılıyor. Fine-tuning bilgi yüklemez, davranış öğretir — yanlış problemi ona havale ederseniz elinize daha güvenle yanlış konuşan bir model geçer. Sonucu veri belirler — 200 temiz örnek, 2.000 dağınık örnekten iyidir ve GPU faturanız zaten en küçük kaleminizdir. Ölçemiyorsanız geliştiremezsiniz — eval setini eğitimden önce yazın, dört farklı açıdan bakın, tek bir tabloya güvenmeyin.

Gerisi keyifli kısım. QLoRA sayesinde bir deneyin maliyeti bir kahve parası; yani “acaba” demenin bedeli neredeyse sıfır. Küçük bir veri seti hazırlayın, bir gecelik koşu atın, sabah sonuca bakın. Bu işi öğrenmenin tek yolu, kendi verinizle kendi modelinizi bir kez baştan sona eğitmek. Loss’unuz düzgün insin, eval’iniz dürüst olsun!

Kaynaklar

Bir yanıt yazın Yanıtı iptal et

Yorum yapabilmek için oturum açmalısınız.