2026 Uyarlama Sırası: Prompt → RAG → Fine-tune → Distilasyon ve LoRA/QLoRA

TL;DR — 2026'da doğru soru "fine-tune mü, RAG mı?" değil; doğru soru "hangi sırayla?" Sahada işleyen sıralama net: önce prompt mühendisliği, sonra RAG, sonra fine-tuning, en son distilasyon. Fine-tuning'i davranış, şema ve ton için kullanın; bilgi için değil. Bilgi değişiyorsa RAG; davranış sabitse fine-tune. En yüksek getirili yaklaşım, güçlü bir temel modelin üzerine ince bir LoRA veya QLoRA adaptörü eğitip bunu retrieval ile birlikte kullanmak; yani ya-ya-da değil, katmanlı bir yığın. QLoRA sayesinde büyük bir modeli tek bir tüketici GPU'sunda ince ayarlayabiliyorsunuz. KVKK açısından kritik nokta: kişisel veriyi model ağırlıklarına gömmeyin; onu retrieval katmanında, silinebilir ve denetlenebilir şekilde tutun.

Geçen ay üst üste üç farklı ekiple aynı sahneyi yaşadım. Üçü de bana "hocam biz modeli fine-tune edelim, kendi verimizle eğitelim" diye geldi. Üçünde de birkaç soru sorunca ortaya çıkan tablo aynıydi: aslında fine-tuning'e ihtiyaçları yoktu. Birinin problemi bir sistem promptuyla çözülüyordu. Diğerinin ihtiyacı klasik bir RAG kurulumuydu. Sadece üçüncüsünde fine-tuning gerçekten mantıklıydı ve orada bile önce başka şeyleri denememiz gerekti.

Bu yüzden bu yazıyı yazıyorum. Çünkü "fine-tuning" kelimesi 2026'da bir tür statü sembolü haline geldi. Sanki modeli eğitmek daha ciddi, daha kurumsal, daha "biz gerçekten yapay zeka yapıyoruz" demekmiş gibi bir hava var. Oysa sahada gördüğüm gerçek şu: fine-tuning çoğu zaman yanlış katmanda çözülmeye çalışılan bir problemin pahalı cevabıdır. Doğru soruyu sorduğunuzda, çoğu ihtiyaç daha ucuz, daha hızlı ve daha az riskli bir katmanda çözülür.

Bu yazıda size 2026'nın uyarlama sırasını anlatacağım: Prompt → RAG → Fine-tune → Distilasyon. Her katmanın ne zaman durup ne zaman bir sonrakine geçmeniz gerektiğini, LoRA ile QLoRA'nın ne olduğunu sade bir dille, bir karar tablosuyla ve sahadan mini senaryolarla göstereceğim. Sonunda da elinizde bir karar çerçevesi ve bir kontrol listesi olacak.

Her şeyden önce bir ayrım yapmanızı istiyorum. Bu ayrımı içselleştirdiğinizde, bundan sonraki kararların yarısı kendiliğinden çözülüyor.

Fine-tuning davranışı şekillendirir. RAG bilgi sağlar.

Bunu bir çalışan gibi düşünün. Fine-tuning, o çalışana yeni bir çalışma tarzı, bir refleks, bir konuşma tonu, bir çıktı formatı öğretmektir. "Sen her yanıtı şu JSON şemasında ver", "Sen her zaman şu kurumsal tonda konuş", "Sen bu tür soruları hep şu adımlarla çöz" gibi. Bunlar davranıştır. Sabittir. Sık değişmez.

RAG ise o çalışana masasının üstünde güncel bir dosya bırakmaktır. "Bu haftanın fiyat listesi burada", "Şu müşterinin son sözleşmesi bu", "Bu ayki mevzuat değişikliği şu" gibi. Bunlar bilgidir. Değişkendir. Sürekli güncellenir.

Şimdi kritik hatayı söyleyeyim: insanlar değişen bilgiyi modele fine-tune etmeye çalışıyor. Yani masanın üstüne bırakılması gereken dosyayı, çalışanın beynine kalıcı olarak kazımaya çalışıyorlar. Sonuç? Fiyat listesi değiştiğinde modeli yeniden eğitmeniz gerekiyor. Mevzuat değiştiğinde yeniden eğitmeniz gerekiyor. Bu hem pahalı hem de yanlış. Değişen bilgi RAG'in işidir. Fine-tuning'i sadece gerçekten sabit olan şeyler için saklayın: davranış, şema ve ton.

Bu ayrımı bir cümleye sıkıştırayım, aklınızda kalsın: Değişen şeyi getir (retrieve), sabit olan şeyi göm (fine-tune).

2026'nın önerilen sıralaması bir merdiven gibi çalışıyor. En alttan başlayın, ancak gerçekten gerektiğinde bir üst basamağa çıkın. Her basamak bir öncekinden daha pahalı, daha yavaş kuruluyor ve daha fazla bakım istiyor. O yüzden acele etmeyin.

Birinci basamak — Prompt mühendisliği. Her zaman buradan başlayın. Şaşırtıcı derecede çok problem, iyi yazılmış bir sistem promptu, birkaç örnek (few-shot) ve net talimatlarla çözülür. Maliyeti neredeyse sıfır, değişiklik yapması anında. Bir davranışı promptla elde edebiliyorsanız, onu asla fine-tune etmeyin.

İkinci basamak — RAG (retrieval). Modelin bilmediği, sizin kurumunuza özel veya güncel bilgiye ihtiyaç duyduğunda buraya geçin. Ürün kataloğunuz, iç dokümantasyonunuz, müşteri kayıtlarınız, mevzuat metinleriniz... Bunlar promptun içine sığmayan ya da sürekli değişen bilgilerdir. RAG bunları arayıp modele o an sunar. Model yeniden eğitilmez; sadece doğru bağlamı görür.

Üçüncü basamak — Fine-tuning. Prompt ve RAG ile ulaşamadığınız bir davranış tutarlılığına, bir uzmanlığa, bir formata veya bir hız/maliyet kazancına ihtiyacınız olduğunda buraya çıkın. Burada da tercihiniz genellikle ince bir LoRA veya QLoRA adaptörü olmalı; tüm modeli baştan eğitmek değil.

Dördüncü basamak — Distilasyon. En son basamak. Büyük ve pahalı bir modelin davranışını, daha küçük ve ucuz bir modele taşımak istediğinizde buraya gelirsiniz. Amaç: büyük modelin kalitesine yakın çıktıyı, çok daha düşük gecikme ve maliyetle üretmek.

Şimdi bunu bir karar tablosuna dökeyim, çünkü sahada en çok bu tabloyu istiyorlar.

İhtiyaç	En iyi teknik	Neden
Talimatı netleştirmek, format vermek, birkaç örnekle yönlendirmek	Prompt mühendisliği	En ucuz ve en hızlı; anında değiştirilir
Güncel veya kuruma özel bilgiye erişim	RAG	Bilgi değiştikçe modeli yeniden eğitmeden günceller
~200.000 token altındaki sabit bir bilgi tabanı	Tam bağlam + prompt caching	Retrieval altyapısı kurmadan daha hızlı/ucuz olabilir
Sabit, ölçekte tekrarlanan bir davranış veya çıktı şeması	Fine-tuning (LoRA/QLoRA)	Davranışı modele gömer, her seferinde promptla tarif etmeye gerek kalmaz
Dar bir uzmanlık becerisi (nadir alan, özel jargon)	Fine-tuning (LoRA/QLoRA)	Modelin genelde zayıf olduğu bir beceriyi güçlendirir
Düşük gecikme, düşük maliyetle büyük modelin kalitesi	Distilasyon	Küçük model, büyük modelin çıktısını taklit eder
Güncel bilgi + tutarlı davranış aynı anda	Fine-tune + RAG (katmanlı)	İkisi birlikte, çoğu zaman tek başına her birinden iyidir

Bu tablodaki son satır 2026'nın en önemli mesajı; birazdan ayrı bir başlıkta açacağım.

Fine-tuning deyince çoğu insanın gözünde canlanan sahne yanlış. "Milyonlarca parametreyi baştan eğiteceğiz, dev GPU çiftlikleri lazım" diye düşünüyorlar. 2026'da bu artık istisna; kural değil.

LoRA (Low-Rank Adaptation) şunu yapar: temel modeli dondurur, hiç dokunmaz. Onun yanına küçük, düşük ranklı "adaptör" katmanları ekler ve sadece bu minik katmanları eğitir. Yani devasa modelin milyarlarca parametresini değil, ona takılan küçük bir eklentiyi eğitiyorsunuz. Sonuç: maliyet keskin biçimde düşüyor, eğitim hızlanıyor ve aynı temel modelin üstünde farklı görevler için farklı adaptörler tutabiliyorsunuz. Bir müşteri için bir adaptör, başka bir görev için başka bir adaptör; hepsi aynı temel modeli paylaşır.

QLoRA, LoRA'nın üstüne bir numara daha ekler: temel modeli 4-bit'e kuantize eder, yani bellekte çok daha küçük bir hale sıkıştırır. Bu sayede normalde büyük bir sunucu gerektirecek bir modeli tek bir tüketici GPU'sunda ince ayarlayabilirsiniz. Karşılığında küçük bir doğruluk (fidelity) ödünü verirsiniz, ama pratikte çoğu kurumsal senaryoda bu ödün fark edilmeyecek kadar küçüktür.

Sahadan basit bir çeviri yapayım: LoRA "tüm modeli değil, ince bir katmanı eğit" demek. QLoRA "üstelik bunu ucuz bir donanımda yap" demek. İkisi birlikte, fine-tuning'i büyük şirketlerin ayrıcalığı olmaktan çıkarıp, orta ölçekli bir ekibin bile bir hafta sonunda deneyebileceği bir şey haline getirdi.

Önemli bir vurgu: en yüksek getirili fine-tuning, güçlü bir temel modelin üstüne ince bir LoRA/QLoRA adaptörü eğitip bunu retrieval ile eşleştirmektir. Retrieval'i değiştirmek için değil, onunla birlikte çalışmak için. Bunu bir sonraki başlıkta açıyorum.

Burada 2026'da çok az konuşulan ama pratikte çok işe yarayan bir gerçek var. Herkes reflekssel olarak "bilgi mi var, hemen RAG kuralım" diyor. Ama küçük bilgi tabanları için bu bazen gereksiz mühendislik.

Eğer bilgi tabanınız yaklaşık 200.000 token'ın altındaysa, o bilginin tamamını doğrudan modelin bağlamına verip prompt caching kullanmak, çoğu zaman bir retrieval altyapısı kurmaktan daha hızlı ve daha ucuz olur. Modern modellerin bağlam pencereleri artık bunu kaldırıyor. Prompt caching sayesinde aynı büyük bağlamı tekrar tekrar gönderirken maliyet çarpıcı biçimde düşüyor.

Bunu şöyle düşünün: 50 sayfalık bir el kitabınız var ve chatbotunuzun buna göre cevap vermesi lazım. Bunun için vektör veritabanı kurmak, embedding hesaplamak, chunk'lamak, retrieval'i tune etmek... çoğu zaman gereksiz. El kitabının tamamını bağlama koyun, önbelleğe alın, bitti. Retrieval altyapısı, bilgi tabanınız gerçekten büyüdüğünde ve tamamı bağlama sığmadığında anlam kazanır.

Sahada gördüğüm en yaygın israf tam burada: küçük bir bilgi tabanı için koca bir RAG mimarisi kurulması. Önce şunu sorun: "Bu bilgi tek bir bağlama sığar mı?" Sığıyorsa, retrieval'e girmeden önce tam bağlam + caching yolunu deneyin.

Şimdi 2026'nın en büyük trendine geldik. En çok yanlış anlaşılan da bu, çünkü herkes bunu bir "ya-ya-da" seçimi sanıyor. Değil.

Fine-tune edilmiş bir model, aynı zamanda retrieval de yapıyorsa, çoğu zaman iki tekniğin de tek başına ulaşamayacağı bir performansa çıkar.

Neden? Çünkü ikisi farklı problemleri çözüyor ve çakışmıyorlar, tamamlıyorlar. Fine-tuning modele davranışı, tonu, çıktı şemasını ve dar uzmanlığı öğretir. RAG ise ona o an gereken güncel, kuruma özel bilgiyi getirir. Bunları birleştirdiğinizde şu ortaya çıkar: doğru şekilde davranan, doğru formatta cevap veren ve üstelik güncel bilgiyle konuşan bir sistem.

Somut bir senaryo vereyim. Bir sigorta şirketi için müşteri hizmetleri asistanı kurduğunuzu düşünün.

• Fine-tuning ona şunu öğretir: her yanıtı şirketin kurumsal tonuyla ver, her poliçe açıklamasını şu üç adımlı yapıda anlat, hukuki uyarıyı her zaman şu formatta ekle. Bu davranış sabittir, her müşteride aynıdır.
• RAG ona şunu getirir: bu müşterinin güncel poliçesi, bu haftanın kampanyaları, geçen ay değişen bir mevzuat maddesi. Bu bilgi değişkendir, her müşteride farklıdır.

Fine-tuning'i tek başına kullansanız, model doğru tonda konuşur ama müşterinin güncel poliçesini bilemez. RAG'i tek başına kullansanız, güncel bilgiyi getirir ama tutarlı bir davranış ve format garantisi vermez, her seferinde promptta uzun uzun tarif etmeniz gerekir. İkisini birleştirdiğinizde her iki dünyanın da en iyisini alırsınız. İşte "composable adaptation stack" dedikleri şey bu.

Bu yüzden fine-tuning kararını verirken hep şunu hatırlayın: fine-tuning retrieval'in yerine geçmez, onunla birlikte çalışır. Modeli eğitirken bile "bu, retrieval katmanının üstüne oturacak ince bir davranış katmanı" diye düşünün.

Merdivenin en üst basamağı distilasyon. Buraya genellikle en son gelirsiniz, çünkü önce çözmeniz gereken başka şeyler vardır.

Distilasyonun mantığı şu: elinizde büyük, güçlü ama pahalı ve yavaş bir model var. Bu model işini çok iyi yapıyor ama her çağrı size hem para hem de gecikme olarak pahalıya patlıyor. Distilasyonda, bu büyük modeli bir "öğretmen" olarak kullanıp onun çıktılarını taklit eden daha küçük bir "öğrenci" model eğitirsiniz. Öğrenci model, öğretmenin kalitesine yakın sonuçlar üretir ama çok daha hızlı ve çok daha ucuzdur.

Bunu ne zaman yaparsınız? Belirli, dar bir görevi çok yüksek hacimde çalıştırıyorsanız. Örneğin günde milyonlarca kez aynı tür sınıflandırmayı veya özetlemeyi yapıyorsanız, büyük modeli her seferinde çağırmak hem yavaş hem pahalıdır. Büyük modelin o dar görevdeki davranışını küçük bir modele damıtırsanız, gecikme düşer, maliyet düşer ve kalite kabul edilebilir seviyede kalır.

Distilasyon aslında fine-tuning'in özel bir hali: küçük bir modeli, büyük bir modelin çıktılarını taklit edecek şekilde ince ayarlıyorsunuz. Bu yüzden merdivende fine-tuning'den hemen sonra gelir. Ama unutmayın, distilasyon dar ve iyi tanımlı görevler için işe yarar; genel amaçlı, geniş bir asistanı damıtmaya çalışmak genellikle hayal kırıklığıyla biter.

Bütün bu merdivenden sonra net bir liste vereyim. Fine-tuning şu dört durumdan biri varsa gerçekten haklıdır:

1. Ölçekte tekrarlanan katı bir davranış. Her yanıtın aynı şemada, aynı tonda, aynı yapıda olması gerekiyor ve bunu promptla her seferinde tarif etmek hem token hem tutarlılık açısından pahalıya geliyorsa.
2. Dar bir uzmanlık becerisi. Modelin genelinde zayıf olduğu, nadir bir alan veya özel bir jargon var ve prompt/RAG ile istediğiniz kaliteye ulaşamıyorsanız.
3. Daha düşük gecikme. Davranışı modele gömdüğünüzde, her çağrıda uzun promptlar ve örnekler göndermeniz gerekmez; bu da gecikmeyi ve token maliyetini düşürür.
4. Daha küçük bir model, büyüğü taklit etsin. Yani distilasyon; büyük modelin bir görevdeki çıktısını küçük ve ucuz bir modele taşımak.

Bu dördünden hiçbiri sizin durumunuza uymuyorsa, muhtemelen fine-tuning'e ihtiyacınız yok. Prompt ya da RAG katmanında kalın. Bunu bir uyarı olarak değil, bir tasarruf tavsiyesi olarak alın; kendinize hem bütçe hem de bakım yükü kazandırıyorsunuz.

Fine-tuning'e karar verdiniz diyelim. Şimdi sizi en çok yaralayacak yer burası: veri.

Fine-tuning'in kalitesi, verdiğiniz eğitim verisinin kalitesiyle sınırlıdır. Kötü, tutarsız, çelişkili örneklerle eğitirseniz, modele tutarsızlığı öğretmiş olursunuz. Sahada gördüğüm klasik tuzaklar şunlar:

• Çok az ama kirli veri. Birkaç yüz örnek yeter diye başlarlar ama örnekler birbiriyle çelişir. Model kafası karışmış bir davranış öğrenir. Az veriyle çalışacaksanız, o azın tertemiz ve tutarlı olması şart.
• Değişen bilgiyi eğitim verisine koymak. Fiyatları, tarihleri, güncel gerçekleri eğitim setine gömmek. Bunlar RAG'in işi; modele gömerseniz bilgi eskir ve yeniden eğitim gerekir.
• Değerlendirme setinin olmaması. Modeli eğitirsiniz ama "gerçekten daha iyi mi oldu?" sorusunu ölçecek bir test setiniz yoktur. Fine-tuning'e girmeden önce, başarıyı nasıl ölçeceğinizi tanımlayın.
• Aşırı uyum (overfitting). Adaptörü çok uzun eğitirseniz, model eğitim örneklerini ezberler ama yeni durumlarda esnekliğini kaybeder. LoRA/QLoRA burada nispeten toleranslıdır ama yine de dikkat gerekir.
• Temel modeli zayıf seçmek. Zayıf bir temel modelin üstüne fine-tuning yaparak güçlü bir modelin yerini tutmaya çalışmak. En yüksek getiri, güçlü bir temel modelin üstüne ince bir adaptör; tersi değil.

Pratik tavsiyem: fine-tuning'i bir deney gibi ele alın. Küçük başlayın, temiz bir veri setiyle bir LoRA adaptörü eğitin, değerlendirme setinizde ölçün, prompt/RAG bazlı çözümünüzle karşılaştırın. Gerçekten daha iyiyse ölçekleyin; değilse bir alt basamağa geri dönün.

Kararlarınızın çoğu aslında maliyet kararı, o yüzden bunu açık konuşalım. Fine-tuning'in görünür maliyeti eğitim; ama asıl maliyet çoğu zaman bakımda saklı.

Prompt mühendisliğinin maliyeti neredeyse sadece sizin zamanınız. RAG'in maliyeti altyapı: vektör veritabanı, embedding hesaplama, retrieval'i tune etme, bakım. Fine-tuning'in maliyeti eğitim GPU'su artı, ki bu daha önemli, her bilgi güncellemesinde yeniden eğitim riski. İşte tam da bu yüzden değişen bilgiyi fine-tune etmek pahalıdır: her değişiklik yeni bir eğitim demektir.

LoRA ve QLoRA bu tabloyu ciddi biçimde değiştirdi. LoRA sadece küçük adaptörleri eğittiği için eğitim maliyetini keskin biçimde düşürür. QLoRA, 4-bit kuantizasyonla, büyük bir modeli tek bir tüketici GPU'sunda eğitilebilir hale getirir; yani bulut faturaları da düşer. Bu yüzden 2026'da fine-tuning artık sadece büyük bütçeli ekiplerin işi değil.

Ama şu tuzağa düşmeyin: ucuzladı diye gereksiz yere fine-tune etmeyin. Ucuz bir yanlış çözüm, pahalı bir yanlış çözümden daha az acıtır ama yine de yanlıştır. Her katmanın maliyetini karşılaştırın: bir sistem promptu güncellemek dakikalar sürer ve bedavadır; bir adaptörü yeniden eğitmek saatler sürer ve para yakar. Aynı sonucu daha alt katmanda alabiliyorsanız, orada kalın.

Şimdi Türkiye'de çalışan herkesin özellikle dikkat etmesi gereken bir noktaya geliyorum. Fine-tuning'in en sinsi riski KVKK açısından ortaya çıkıyor ve bunu sahada yeterince konuşmuyoruz.

Kişisel veriyi model ağırlıklarına fine-tune ettiğinizde, o veri artık modelin içine gömülür. Bunun birkaç ciddi sonucu var. Birincisi, KVKK'nın verdiği silme hakkı (unutulma hakkı). Bir kişi verisinin silinmesini talep ettiğinde, RAG mimarisinde bunu yapmak kolaydır: ilgili kaydı veritabanından silersiniz, retrieval artık onu getirmez. Ama veriyi model ağırlıklarına gömdüyseniz, o veriyi "silmek" pratikte modeli yeniden eğitmek anlamına gelir. Bu hem çok pahalı hem de teknik olarak temiz bir silme garantisi vermek zordur.

İkincisi, denetlenebilirlik. RAG'de hangi verinin hangi cevaba katkı yaptığını izleyebilirsiniz; kaynak bellidir. Ağırlıklara gömülü veride bu şeffaflık kaybolur. KVKK'nın istediği hesap verebilirlik ilkesi açısından bu ciddi bir dezavantaj.

Bu yüzden sahadaki tavsiyem net: kişisel veriyi fine-tuning'e değil, retrieval katmanına koyun. Retrieval katmanı silinebilir, denetlenebilir, erişimi kontrol edilebilir. Fine-tuning'i kişisel veri içermeyen davranış, ton ve şema için saklayın. Yani "müşterilere nasıl cevap verileceğini" fine-tune edin; "hangi müşterinin ne verisi olduğunu" retrieval'de tutun.

Bir de veri yerelliği ve barındırma tarafı var. Türkiye'de birçok kurum, hassas veriyi yurt dışındaki bir API'ye göndermek istemiyor; bazıları mevzuat gereği gönderemiyor da. İşte QLoRA'nın sessiz ama büyük faydası burada: güçlü açık kaynak bir modeli kendi sunucunuzda (self-hosted) tek bir GPU'da ince ayarlayabildiğiniz için, veriyi hiç dışarı çıkarmadan uyarlama yapabilirsiniz. Açık ağırlıklı modeller + QLoRA + self-hosting, KVKK'ya duyarlı senaryolar için 2026'nın en pratik kombinasyonu. Veri kurumun içinde kalır, uyarlama kurumun içinde yapılır, kontrol kurumda kalır.

Özetle KVKK açısından iki kuralı aklınızda tutun: değişen ve kişisel veriyi ağırlıklara gömmeyin, retrieval'de tutun; hassas veriyle çalışıyorsanız açık model + self-hosting yolunu ciddi biçimde değerlendirin.

Şimdi tüm bunları uygulanabilir bir çerçeveye indirgeyeyim. Bir sonraki yapay zeka projenizde bir davranış ya da bilgi ihtiyacıyla karşılaştığınızda, şu sırayla ilerleyin.

Adım 1 — Önce sınıflandırın. İhtiyacınız davranış mı, bilgi mi? Değişen bir şey mi, sabit bir şey mi? Bu tek soru, kararınızın yönünü belirler. Değişen bilgi ise doğrudan RAG'i düşünün; sabit davranış ise fine-tuning masada.

Adım 2 — Promptla deneyin. İhtiyacı iyi bir sistem promptu, net talimatlar ve birkaç örnekle çözebiliyor musunuz? Çözebiliyorsanız, durun. Buradan öteye geçmeyin.

Adım 3 — Bilgi lazımsa, önce boyutu ölçün. Bilgi tabanınız ~200.000 token'ın altında mı? Öyleyse tam bağlam + prompt caching yolunu deneyin; RAG altyapısı kurmadan önce. Daha büyükse RAG kurun.

Adım 4 — Davranış tutarlılığı prompt/RAG ile gelmiyorsa, fine-tuning'i düşünün. Ama önce şu dört gerekçeden en az birinin geçerli olduğundan emin olun: katı ve ölçekli bir davranış, dar bir uzmanlık, düşük gecikme ihtiyacı, ya da distilasyon. Yoksa geri dönün.

Adım 5 — Fine-tune edecekseniz, ince ve katmanlı yapın. Güçlü bir temel model seçin, LoRA veya QLoRA ile ince bir adaptör eğitin ve bunu retrieval'in üstüne oturtun. Fine-tuning'i RAG'in yerine değil, onunla birlikte kurun.

Adım 6 — Yüksek hacim ve gecikme baskısı varsa, distilasyonu değerlendirin. Büyük modelin dar bir görevdeki çıktısını küçük bir modele damıtın; kaliteyi değerlendirme setinizde doğrulayın.

Adım 7 — Her katmanda KVKK filtresinden geçirin. Kişisel veri ağırlıklara gömülüyor mu? Öyleyse durun ve retrieval'e taşıyın. Hassas veri yurt dışına çıkıyor mu? Öyleyse açık model + self-hosting seçeneğini değerlendirin.

Ve son olarak, cebinizde taşıyabileceğiniz kısa kontrol listesi:

• İhtiyacı davranış/bilgi ve sabit/değişen ekseninde sınıflandırdım.
• Promptla çözülüp çözülmediğini denedim.
• Bilgi tabanı boyutunu ölçtüm; küçükse tam bağlam + caching'i denedim.
• RAG'i değişen bilgi için, fine-tuning'i sabit davranış için ayırdım.
• Fine-tuning için dört gerekçeden en az biri var mı, kontrol ettim.
• Fine-tune edeceksem güçlü temel model + LoRA/QLoRA + retrieval katmanı planladım.
• Temiz bir veri seti ve bir değerlendirme seti hazırladım.
• Kişisel veriyi ağırlıklara değil retrieval'e koydum.
• Hassas veri için açık model + self-hosting seçeneğini değerlendirdim.

Bu merdiveni ve bu listeyi bir sonraki projenizde uygularsanız, iki şey birden kazanırsınız: hem daha az para harcarsınız, hem de KVKK açısından çok daha savunulabilir bir mimari kurmuş olursunuz. 2026'da fine-tuning bir statü sembolü değil; doğru katmanda, doğru gerekçeyle, retrieval ile birlikte kullanıldığında gerçekten güçlü bir araç. Onu bu gözle kullanın, merdiveni atlamayın ve her zaman en ucuz katmanda çözebildiğiniz şeyi orada çözün.

Bu merdiveni anlattığımda ekiplerden hemen hemen hep aynı üç itiraz geliyor. Onları burada karşılayayım, çünkü sizin de aklınıza gelmiş olabilir.

"Ama fine-tune edersek promptumuz kısalır, token'dan tasarruf ederiz." Doğru, davranışı modele gömdüğünüzde her çağrıda uzun talimatlar göndermezsiniz. Ama bu tasarrufu, eğitim ve bakım maliyetiyle birlikte hesaplayın. Eğer davranışınız hâlâ oturmadıysa, sık sık değişiyorsa, her değişiklikte yeniden eğitim yaparsınız ve tasarruf ettiğiniz token'ı fazlasıyla geri ödersiniz. Davranış gerçekten oturduğunda, ölçekte çalıştığında bu argüman güçlenir; ondan önce değil.

"Rakibimiz kendi modelini eğitmiş, biz de eğitmeliyiz." Rakibinizin ne çözdüğünü bilmiyorsunuz. Belki gerçekten bir uzmanlık becerisi ya da distilasyon senaryosu var; belki de onlar da statü için yapıyor ve para yakıyorlar. Sizin işiniz rakibi taklit etmek değil, kendi ihtiyacınızı doğru katmanda çözmek. Doğru mimari, "en gösterişli" mimari değil, sizin problemi en ucuza ve en savunulabilir şekilde çözen mimaridir.

"Verimiz çok özel, prompt/RAG yetmez." Belki. Ama bunu varsaymak yerine ölçün. Önce iyi bir RAG kurun, değerlendirme setinizde ölçün, sonra fine-tuning'in üstüne ne kattığına bakın. Sahada defalarca gördüm: "verimiz çok özel" diyen ekiplerin çoğu, iyi kurulmuş bir retrieval ile hedeflerine ulaşıyor. Fine-tuning gerçekten gerektiğinde de zaten katmanlı yığında, RAG'in üstünde devreye giriyor.

Bu üç itirazın ortak noktası şu: hepsi fine-tuning'i bir varış noktası olarak görüyor. Oysa fine-tuning bir araç, hem de merdivenin üst basamaklarında duran, pahalı ve bakım isteyen bir araç. Onu bir hedef değil, gerektiğinde başvurulan bir çözüm olarak konumlandırın. Böyle baktığınızda kararlarınız hem teknik hem de ekonomik olarak çok daha sağlam olur ve ekibinizi gereksiz bir eğitim döngüsünün içine sokmamış olursunuz.