TB
← Tüm yazılar

Fine-tuning ne zaman gerekir?

LLM fine-tuning'in gercekten gerekli olduğu senaryolari, maliyet-fayda analizini ve prompt veya RAG ile cozulebilecek durumlari ayirt eden pratik bir cerceve sunuyoruz.

Fine-tuning, on egitilmis bir büyük dil modelinin agirliklarini özel veri seti uzerinde guncelleyerek davranisini kalıcı olarak değiştirme islemidir. Pazarlamada her problem icin ilk çözüm gibi sunulsa da fine-tuning pahali, yavas iterasyonlu ve bakimi zor bir yoldur. Doğru soru su degildir: fine-tuning yapabilir miyiz? Doğru soru: fine-tuning olmadan hedef metriklerimize ulasamaz miyiz?

Fine-tuning turleri

Full fine-tuning tüm model agirliklarini gunceller; en yüksek esneklik, en yüksek GPU bellek ve egitim maliyeti. LoRA (Low-Rank Adaptation) düşük rankli matrisler ekleyerek yalnizca küçük bir alt kumeyi egitir; tuketici sinifi GPU'larda bile calisabilir. QLoRA quantize edilmis taban model uzerinde LoRA uygular; bellek ihtiyacini daha da dusurur. RLHF ve DPO tercih hizalama icin kullanılır; kurumsal chatbot tonu ve güvenlik icin ileri asama tekniklerdir.

Çoğu kurumsal kullanımda LoRA veya QLoRA yeterlidir. Taban model seçimi kritiktir: Türkçe performans, context limiti, lisans kosullari ve inference maliyeti birlikte degerlendirilir. Açık kaynak Llama, Mistral veya ticari API fine-tuning hizmetleri farklı veri gizliligi profilleri sunar.

Gercekten gerekli olduğu senaryolar

Fine-tuning asagidaki durumlarda anlamli fayda sağlar:

  1. Dar domain dili: Tip sagligi, hukuk veya telekom standartlarinda kısaltma ve terminoloji tutarlılığı prompt ile saglanamiyorsa.
  2. Sabit çıktı formati: Karmaşık şema, tablo veya rapor yapisi structured output ile bile sık bozuluyorsa ve binlerce örnek mevcutsa.
  3. Stil ve marka sesi: Belirli hitap, uzunluk ve kisitlama kurallari tutarlı şekilde uygulanmali ve sistem promptu asiri uzuyorsa.
  4. Düşük gecikme küçük model: Büyük model + uzun prompt yerine küçük fine-tuned model ayni kaliteyi daha hızlı verebilir.
  5. Offline veya özel deployment: Hassas veri dışarı cikamaz; RAG icin embedding API kullanılamaz ve bilgi egitim verisine gomulebilir.

Bu listelerin hicbir maddesi otomatik fine-tuning emri degildir. Her biri once prompt optimizasyonu, RAG veya daha güçlü taban model ile test edilmelidir.

Ne zaman gerekli degildir

Güncel bilgi gereksinimi fine-tuning ile cozulmez; model egitim anindaki bilgiyle sinirlidir. Doküman tabanli soru-cevap icin RAG standart cozumdur. Genel mantık, çeviri ve ozetleme gibi evrensel yetenekler icin fine-tuning nadiren deger katar. Veri setiniz yuz ornekten azsa overfitting riski cok yüksektir. Hedef metrikleriniz zaten GPT-4 sinifi model + iyi prompt ile saglaniyorsa operasyonel karmasiklik icin fine-tuning gereksizdir.

Veri seti gereksinimleri

Kaliteli fine-tuning verisi az ama temiz olmalidir. Instruction tuning formati genelde sistem/user/assistant mesaj ucgenidir. Örnek basina ortalama iki yuz ile bin token arasi hedeflenir. Veri ceşitliligi: farklı soru tipleri, kenar durumlar ve olumsuz örnekler (reddedilmesi gereken istekler). Data leakage test seti ile egitim seti arasinda benzerlik olmamasi icin deduplication uygulanir.

Sentetik veri uretimi (büyük model ile etiketleme) olceklendirir ama kalite kontrol gerektirir. Her sentetik batch'in yüzde onu insan tarafindan gozden gecirilmelidir. Dengesiz siniflar (örneğin yalnizca olumlu cevaplar) model davranisini carpitir.

Örnek instruction kaydi

{
  "messages": [
    {"role": "system", "content": "Sen banka musteri hizmetleri ozetleyicisisin."},
    {"role": "user", "content": "Musteri IBAN degisikligi ve sikayet kaydi acti."},
    {"role": "assistant", "content": "Ozet: IBAN guncelleme talebi alindi. Sikayet no: 4521..."}
  ]
}

Maliyet-fayda analizi

Maliyet bilesenleri: veri hazirlama (insan saati), GPU egitim saati, hyperparameter arama tekrarlari, değerlendirme, model hosting ve sürüm yönetimi. LoRA egitimi tek GPU'da birkaç saatten birkaç gune uzayabilir. Inference tarafinda özel model barindirma API taban genel modele gore sabit maliyet ekler.

Fayda olcumleri net olmalidir: otomasyon orani, insan duzeltme suresi, format hatasi orani, müşteri memnuniyeti. Fine-tuning yüzde bes iyilesme sagliyor ama aylik bakım maliyeti RAG pipeline'inin uzerindeyse ROI negatiftir. Basit formul: (kazanç x hacim) - (egitim + inference + operasyon) > 0 en az on iki ay horizonunda.

Değerlendirme ve güvenlik

Egitim sonrasi otomatik benchmark: perplexity tek basina yeterli degildir. Gorev odaklı test seti uzerinde exact match, F1 ve insan değerlendirme bir arada kullanılır. Catastrophic forgetting genel yeteneklerin zayiflamasidir; egitim verisine genel yetenek ornekleri karistirilarak azaltilir. Güvenlik red team testleri fine-tune sonrasi tekrarlanir; model jailbreak'e daha açık hale gelebilir.

Model karti dokumante edilmeli: taban model, veri kaynagi, egitim tarihi, bilinen sinirlamalar. Regulasyon (finans, sağlık) audit izi ister.

Operasyonel süreç

Fine-tuned model bir ürün degil, surumlu bir artifact'tir. MLOps pipeline: veri versiyonlama (DVC), egitim scripti, otomatik eval gate, staging deploy, shadow traffic, canary yüzde bes, tam geçiş. Geri alma plani: önceki adapter checkpoint bir tik geri donulebilir olmali.

Taban model guncellendiğinde (örneğin Llama 3.1'den 3.2'ye) adapter uyumlulugu kontrol edilir; genelde yeniden egitim gerekir. Bu gizli maliyet planlamada unutulur.

Alternatiflerle karşılaştırma

Prompt engineering: Sifir egitim maliyeti, hızlı iterasyon; uzun prompt ve yüksek token maliyeti. RAG: Güncel bilgi, izlenebilir kaynak; retrieval kalitesine bağımlı. Fine-tuning: Davranis ve stil kaliciligi; güncelleme pahali. Çoğu üretim sistemi ucunu birlestirir: fine-tuned küçük model + RAG + kisa sistem promptu.

Karar akisi

Once hedefi sayisal tanimlayin. Prompt ve RAG ile baseline olusturun. Gap analizi yapin: hata turleri format mi, bilgi mi, ton mu? Bilgi gap'i RAG ile kapatilamiyorsa veri envanterini kontrol edin. Ton ve format gap'i bin plus kaliteli örnek varsa fine-tuning pilotu baslatin. Pilot basariliysa MLOps olgunlugunu dogrulayin, aksi halde güçlü model veya prompt ile devam edin. Fine-tuning son care degil ama kolay yol da degildir; ölçülebilir ihtiyaç olmadan baslatmayin.

Hyperparameter ve egitim pratikleri

LoRA egitiminde rank (r), alpha, dropout ve learning rate birlikte davranis belirler. r=8 ile r=64 arasi denemeler küçük veri setlerinde overfitting riskini artirir; r=16 çoğu kurumsal gorev icin baslangic noktasidir. Learning rate genelde 1e-4 ile 3e-4 arasinda; warmup adimlari stabilite sağlar. Epoch sayisi erken durdurma (early stopping) validation loss ile sinirlanmalidir. Batch size GPU bellegi ile orantili secilir; gradient accumulation küçük batch etkisini taklit eder.

Egitim sirasinda loss dususu yeterli degildir. Her epoch sonunda hold-out set uzerinde gorev metrigi izlenir. Loss duserken metrik kotulesiyorsa veri etiket hatasi veya hedef uyumsuzlugu suphesi dogar. Checkpoint'ler en iyi metrik aninda saklanir; son epoch her zaman en iyi model degildir.

Altyapi secenekleri

Bulut saglayicilari (Azure OpenAI fine-tune, AWS Bedrock, Google Vertex) yonetilen egitim sunar; veri gizliligi politikasi uygunsa operasyon yuku düşük kalir. On-prem açık kaynak stack (Hugging Face TRL, Axolotl, LLaMA-Factory) tam kontrol verir ama GPU kapasitesi ve uzman ekip ister. Hibrit model: egitim on-prem, inference bulutta kapali ag icinde calisabilir. Seçim maliyet, latency ve compliance ucgeninde yapilir.

Ek üretim perspektifi

Canli ortamda gozlemlenebilirlik olmadan ne RAG ne fine-tuning yatirimi savunulabilir. Her istek icin retrieval skorlari, kullanilan model surumu, prompt hash ve token sayilari yapilandirilmis log olarak yazilmalidir. Dashboard uzerinde haftalik trend analizi yaparak kalite dususleri deployment veya veri kaynagi degisikligine baglanir. On-call runbook'unda retrieval bos dondugunde kullanıcıya gosterilecek mesaj, fallback model seçimi ve cache invalidation adimlari açıkça tanimlanmalidir. Chaos testleri ile vektor veritabanı geçici kesildiginde sistemin kontrollu degradasyon gostermesi beklenir; sessiz halusinasyon üretmek kabul edilemez bir failure moddur. Maliyet optimizasyonu kalite metriklerinden koparilmamali; ucuz model veya düşük top_k seçimi anlik fatura dusurur ama faithfulness alarmi yoksa toplam is degeri zarar görür. Ekip icin ortak bir sözlük tutmak önemlidir: chunk, embedding, adapter, rerank gibi terimler herkes icin ayni anlama gelmelidir. Yeni hire onboarding dokumani bu mimari kararlari ve gerekce metriklerini icermelidir. Son olarak, kullanıcı geri bildirim dongusu kapatilmalidir: thumbs-down tiklanan cevaplar retrieval logu ile eslestirilerek haftalik kalite toplantisinda incelenir. Bu operasyonel olgunluk tek basina doğru teknoloji seciminden daha uzun vadeli başarı getirir cunku sistemler bozulduklarinda fark edilir ve duzeltilir; iyi tasarlanmis RAG veya fine-tuning pipeline'i ise ancak bu disiplinle sürekli deger üretir.