Fine-tuning ve RAG Farkı: Doğru Yöntemin Karar Ağacı

Üç dolar. Sekiz milyar parametrelik açık kaynak bir modeli kiralık bir GPU üzerinde LoRA yöntemiyle fine-tune etmenin ham işlem maliyeti 2026'da bu seviyeye indi; iş birkaç saat sürüyor. Rakam o kadar makul görünüyor ki çoğu şirket doğrudan oraya koşuyor.

Oysa o üç dolar, toplam maliyetin yüzde biri bile değil. Geri kalanı veri toplama, etiketleme, değerlendirme döngüsü kurma ve altı ay sonra "model neden saçmalıyor" diye harcanan mesai. Daha can sıkıcı olanı şu: fine-tuning çoğu vakada zaten yanlış alet. Şirketlerin fine-tuning'den bekledikleri şeyin büyük kısmını (kendi verilerinizden doğru cevap üretmek) o yöntem prensip olarak yapmıyor.

Aşağıda üç yöntem arasında (iyi kurulmuş bir prompt, RAG ve fine-tuning) seçim yapmanızı sağlayacak bir karar ağacı var: hangi soru sizi hangi düğüme götürüyor, her düğüm ne kadar para ve karmaşıklık getiriyor. Dört temel AI altyapı kararının bütününü teknik kararların patron özeti yazımızda ele almıştık; burada bunlardan birine, model seçimi kararına yakından bakıyoruz.

Fine-tuning, RAG ve prompt tam olarak neyi değiştirir?

Üçü farklı katmana dokunur. Fine-tuning modelin nasıl davrandığını değiştirir: tonunu, çıktı formatını, talimat izleme alışkanlıklarını. RAG modelin ne bildiğini değiştirir; cevap vermeden önce sizin belgelerinizi okur. Prompt mühendisliği ise altyapıya hiç dokunmadan ikisini de şekillendirir. Karar ağacının tamamı bu ayrımın üstünde duruyor.

Somutlaştıralım. Modelinizin müşteri e-postalarına şirketinizin resmî üslubuyla, hep aynı beş başlıklı yapıda cevap vermesini istiyorsanız bu bir davranış talebidir. Modelinizin 2026 fiyat listenizdeki iskonto oranını bilmesini istiyorsanız bu bir bilgi talebidir. İlkinde fine-tuning masada, ikincisinde değil.

Microsoft'un kendi geliştirici rehberi de aynı ayrımı yapıyor: RAG modelin girdisini zenginleştirir, fine-tuning modelin kendisini değiştirir. Bu cümleyi aklınızda tutarsanız satış toplantılarında size sunulan çözümlerin yarısını daha ilk dakikada eleyebilirsiniz.

"Fine-tuning modele bilgi öğretir" neden yanlış?

Çünkü ölçüldü ve öyle çıkmadı. Technion ve Google Research ekiplerinin EMNLP 2024'te yayımlanan çalışması, modellerin fine-tuning yoluyla yeni olgusal bilgiyi çok zor edindiğini gösterdi. Dahası: modelin ön eğitiminde bulunmayan bilgileri içeren örnekler sonunda öğrenildikçe, modelin halüsinasyon eğilimi lineer olarak artıyor.

Modeller olguları büyük ölçüde ön eğitim sırasında öğrenir. Fine-tuning onlara yeni olgu öğretmez; sahip oldukları bilgiyi daha verimli kullanmayı öğretir.

Mekanizması aslında sezgisel. Modele bilmediği bir olguyu kendinden emin bir cümleyle tekrar tekrar gösterirseniz, model o olguyu değil kendinden emin cümle kurma alışkanlığını öğrenir. Nitekim bilimsel makalelerle fine-tune edilen modeller üzerine yapılan bir çalışma tam bunu buldu: model bilimsel dilin iddialı üslubunu benimsiyor, altındaki titizliği değil, ve halüsinasyon oranı yükseliyor.

Nüansı atlamayalım: modelin zaten iyi bildiği konularda soru-cevap örnekleriyle fine-tune etmek olgusal doğruluğu iyileştiriyor. Yani fine-tuning bilgi eklemek için değil, var olan bilgiyi düzgün biçimde dışarı çıkarmak için işe yarıyor. Sektörde yıllardır dolaşan özet cümle hâlâ geçerli: fine-tuning form içindir, olgu için değil.

Karar ağacı: üç soru, üç düğüm

Doğru yöntemi seçmek için üç soruyu sırayla sormanız yeterli. Her soru sizi bir sonraki maliyet basamağına geçirir ya da orada durdurur. Kural şu: bir üst basamağa ancak alt basamağın yetmediğini ölçtükten sonra çıkarsınız. Sahada gördüğümüz en pahalı hatalar, bu ölçüm yapılmadan doğrudan en karmaşık çözüme atlamaktan doğuyor.

Birinci soru: Model bunu bilmiyor mu, biliyor da yanlış mı söylüyor? Bilmiyorsa (fiyat listeniz, sözleşmeleriniz, ürün kataloğunuz) cevap RAG'dir; fine-tuning bu problemi çözmez. Biliyor ama yanlış formatta, dağınık ya da şirket üslubunuza uymayan şekilde söylüyorsa yola prompt ile devam edersiniz.

İkinci soru: Bilgi ne sıklıkta değişiyor ve kaynak göstermeniz gerekiyor mu? Bilgi haftalık ya da daha sık değişiyorsa fine-tuning zaten mantıksızdır; her güncellemede yeniden eğitim gerekir. Cevabın hangi belgeden geldiğini göstermeniz gerekiyorsa da fine-tuning masadan kalkar, çünkü ağırlıklara gömülmüş bilgi kaynak gösteremez. Atıf ve izlenebilirlik yapısal olarak retrieval mimarisine ait bir özelliktir.

Üçüncü soru: Elinizde en az 50 gerçek "doğru cevap" örneği var mı? OpenAI'ın kendi rehberi teknik minimumu 10 örnek olarak veriyor, anlamlı iyileşmenin 50-100 örnekten sonra başladığını söylüyor; iş uygulamalarında pratik bant 100-500. Bu örnekleri üretecek zamanı ayıramıyorsanız fine-tuning tartışması burada biter.

Bu üç sorunun arasına bir de ara adım sıkıştırın: çıktı formatı tutarsızlığı yaşıyorsanız fine-tuning'den önce yapılandırılmış çıktı (JSON şeması zorunlu kılma) deneyin. Kıyas kabul etmeyecek kadar ucuz ve bu problemi çoğu zaman tek başına çözüyor.

Hangi yöntem kaça mal oluyor?

Kabaca mertebeler şöyle: prompt tarafı birkaç günlük işçilik; RAG kurulumu kapsamına göre orta ölçekli bir yazılım projesi; fine-tuning ise ham işlem tarafında ucuz ama veri tarafında pahalı. Asıl para hiçbirinde donanımda değil, veride ve entegrasyonda harcanıyor.

Rakamlarla bakalım. LoRA/QLoRA ile 7-8 milyar parametrelik bir modelin eğitimi kiralık GPU'da 3-10 dolar bandında. Aynı modelin klasik yöntemle tam fine-tune edilmesi 100 GB'ın üzerinde VRAM istiyor, yani onbinlerce dolarlık donanım. Kalite farkı ise sanıldığı kadar açık değil: QLoRA tam eğitimin yüzde 80-90'ını, standart LoRA yüzde 90-95'ini yakalıyor. Ucuz yöntem artık yeterince iyi.

RAG tarafında kurumsal projelerin uluslararası fiyat bantları 15 bin dolardan (tek kaynak, basit arayüz) 150 bin dolara (çok kaynaklı, rol bazlı erişim kontrollü, denetim kayıtlı kurumsal kurulum) kadar uzanıyor. Bu bantlar Türkiye fiyatlarına birebir oturmaz; ama içindeki dağılım her yerde aynı ve asıl öğretici kısım o: 89 üretim RAG kurulumunu inceleyen bir analiz, toplam maliyetin yüzde 30-50'sinin veri temizliği ve ön işleme olduğunu buldu. En büyük kalem dil modeli faturası değil, erişim kontrolü katmanı ve entegrasyonlar.

Hız tarafında da bir bedel var: RAG, arama adımı yüzünden yanıt süresine 50-200 milisaniye ekliyor, uzun bağlamın işlenmesiyle birlikte toplam gecikme yüzde 30-50 artabiliyor. Fine-tune edilmiş bir model bu adımı atladığı için sorgu başına daha ucuz ve daha hızlı çalışır. Ancak bu tasarrufun kurulum maliyetini amorti etmesi için aylık sorgu hacminin milyonlar mertebesine çıkması gerekiyor. Türkiye'deki tipik bir KOBİ kullanımında bu eşiğe yaklaşan işlem hacmi neredeyse hiç görülmüyor.

2026'da fine-tuning kapısı daralıyor mu?

Kısmen evet, en azından kapalı modeller tarafında. OpenAI self-servis fine-tuning platformunu kademeli olarak kapatıyor: Mayıs 2026'dan itibaren daha önce hiç fine-tuning yapmamış organizasyonlar yeni eğitim işi açamıyor, Ocak 2027'de mevcut müşteriler için de yeni iş açma kapanıyor. Halihazırda eğitilmiş modeller çalışmaya devam ediyor, ama yeni özellik gelmeyecek.

Anthropic tarafında ise public API'de hiçbir zaman fine-tuning uç noktası olmadı; sınırlı bir seçenek yalnızca Amazon Bedrock üzerinden sunuluyor. Bunun yerine öne çıkarılan araçlar dikkat çekici: 1 milyon token'lık bağlam penceresi, prompt önbellekleme, bağlam düzenleme. Yani sektörün büyük oyuncuları "modeli değiştir" yerine "modele doğru bağlamı ver" yönüne ağırlık veriyor.

Prompt önbelleklemenin ekonomisi bu tercihi açıklıyor: önbellekten okuma maliyeti normal girdi fiyatının kabaca onda biri. Beş yıl önce "uzun sistem promptu pahalıya patlar, bilgiyi modele gömelim" argümanı mantıklıydı; bugün büyük ölçüde geçerliliğini yitirdi. Fine-tuning kapısı tamamen kapanmış değil ama artık açık kaynak modeller ve LoRA tarafından geçiliyor.

KVKK açısından hangisi daha savunulabilir?

RAG. Sebebi teknik ama sonucu doğrudan hukuki: RAG mimarisinde kişisel veri bir veritabanında durur, silmek bir sorgu işidir ve ertesi gün model o kaydı bilmez. Fine-tuning'de veri milyarlarca parametrenin içine dağılır; oradan bir kişinin verisini geri çekmek pratikte modeli sıfırdan eğitmek demektir.

Bu ayrımın önemi, KVKK'nın 24 Kasım 2025'te yayımladığı Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi ile birlikte arttı. Kanunun 7. maddesi işleme sebebi ortadan kalktığında verinin silinmesini, 11. maddesi ise ilgili kişiye silme talep etme hakkını veriyor. Kişisel veriyi model ağırlıklarına gömdüğünüzde bu iki yükümlülüğü teknik olarak yerine getiremez hale geliyorsunuz.

Pratik kural: müşteri adı, iletişim bilgisi, sağlık ya da finansal veri içeren hiçbir veri setini eğitim verisi yapmayın. Bu tür veriye ihtiyaç duyan bir uygulama kuruyorsanız veriyi dışarıda tutan bir mimari seçin; nasıl kurulduğunu RAG'ın patron özeti yazısında adım adım anlatmıştık. Buradaki değerlendirme genel bilgilendirmedir, hukuki görüş yerine geçmez; özel nitelikli veri işleyen projelerde bir hukuk danışmanıyla çalışın.

Türkçe için özel bir model eğitmek gerekir mi?

Çoğu iş uygulaması için hayır. Güncel büyük modeller Türkçeyi yeterince iyi işliyor; "Türkçe anlamıyor" gerekçesiyle fine-tuning'e girmek 2023'ten kalma bir refleks. Ama Türkçenin gerçek bir maliyet etkisi var ve bu, tokenizasyondan geliyor.

Türkçe sondan eklemeli bir dil olduğu için model metni parçalara ayırırken İngilizceye göre daha fazla parça üretiyor. Ölçümler kelime başına token sayısını İngilizcede 1,2-1,4 bandında, Türkçede kullanılan modele göre 1,8-2,5 bandında gösteriyor. Sonuç: aynı içerik Türkçede kabaca 1,5-2 kat daha fazla token, yani doğrudan daha yüksek API faturası.

Bunun karar üzerindeki etkisi ilginç. Türkçe çalışan bir sistemde uzun bağlam göndermek İngilizce çalışan bir sisteme göre daha pahalı olduğu için, iyi retrieval (az ama doğru belge getirmek) ve prompt önbellekleme Türkiye'de daha kritik. Yani doğru cevap yine fine-tuning değil, daha disiplinli bir RAG kurulumu oluyor.

Somut senaryo: 60 kişilik bir sigorta acentesi

Bir sigorta acentesi düşünün. İki şikayeti var: müşteri temsilcileri poliçe şartlarını bulmak için sürekli birbirine soruyor, ve gönderilen teklif e-postaları temsilciden temsilciye tamamen farklı görünüyor.

Bunlar tek problem gibi duruyor ama iki farklı düğüme düşüyor. Poliçe şartları bilgi problemidir ve şartlar sürekli değişir, üstelik hangi poliçenin hangi maddesinden geldiğinin gösterilmesi gerekir: RAG. E-posta üslubu ise davranış problemidir; ama önce prompt ile çözülmeye çalışılır. Acentenin en iyi 30 teklif e-postası bir şablon ve birkaç örnekle sisteme verildiğinde tutarlılık sorunu genelde biter.

Fine-tuning bu senaryoda ne zaman gündeme gelir? Ancak şu üçü birlikte doğruysa: prompt ile denendi ve ölçülebilir şekilde yetmedi, elde 200-300 onaylanmış örnek e-posta birikti, ve hacim gerçekten yüksek. Türkiye'deki orta ölçekli işletmelerde bu üçünün aynı anda sağlandığını sahada nadiren görüyoruz. Çoğu proje birinci ve ikinci basamakta çözülüp kapanıyor, bu da iyi haber: en ucuz iki basamak aynı zamanda en hızlı kurulan ikisi.

Sık sorulan sorular

İkisini birlikte kullanabilir miyim?

Evet, üstelik olgun kurulumların çoğu böyle çalışıyor. Meta ve Microsoft'un birlikte duyurduğu RAFT yaklaşımında model, fine-tuning sırasında hem doğru hem de alakasız belgelerle birlikte eğitiliyor; böylece getirilen bilgiyi kullanmayı, kaynak göstermeyi ve alakasız bağlamı yok saymayı öğreniyor. Tipik olgun mimari şudur: içerik için RAG, üslup için hafif bir fine-tune.

Fine-tuning yaptığımda verim modelin içine mi giriyor?

Evet, tam olarak bu yüzden KVKK açısından riskli. Eğitim verisi ağırlıkların içine dağılır ve geri çıkarılamaz. RAG'de veri dışarıda bir veri tabanında kalır.

Uzun bağlam pencereleri RAG'ı gereksiz kılmadı mı?

Hayır. 1 milyon token'lık pencereler işleri kolaylaştırdı ama "her şeyi içine at" stratejisi çalışmıyor; modeller uzun bağlamın ortasındaki bilgiyi kaçırma eğiliminde. 2026'nın yaygın yaklaşımı hibrit: önce ilgili belgeleri getir, sonra geniş bağlamda üzerinde akıl yürüt.

Fine-tuning yanıt süresini kısaltır mı?

Evet, arama adımı olmadığı için sorgu başına daha hızlı ve ucuzdur. Ancak bu avantaj kurulum maliyetini ancak çok yüksek hacimlerde geri öder.

Açık kaynak modelde fine-tuning yapmak mantıklı mı?

Dar ve tekrarlayan bir görev varsa evet; küçük bir modeli tek bir işte iyi hale getirmek maliyet açısından cazip olabiliyor. Genel amaçlı bir asistan hedefliyorsanız hayır.

Peki siz ne yapmalısınız?

• Problemi tek cümleyle yazın ve sorun: model bunu bilmiyor mu, biliyor da yanlış mı söylüyor? Cevabınız yöntemin yarısını belirliyor.
• Fine-tuning'i bir başlangıç seçeneği olarak değil, ölçülmüş bir yetersizliğin ardından gelen son adım olarak değerlendirin.
• Format ve tutarlılık sorunlarında önce yapılandırılmış çıktıyı deneyin; bu adım çoğu tutarsızlığı ücretsize yakın bir maliyetle çözüyor.
• Kişisel veri içeren hiçbir veri setini eğitim verisine dönüştürmeyin; silme yükümlülüğü teknik olarak imkânsız hale geliyor.
• Bütçeyi donanıma göre değil veriye göre planlayın; hem RAG hem fine-tuning projelerinde paranın büyük kısmı veri hazırlığında harcanıyor.

Bu üç yöntem arasındaki seçim, aslında bir teknoloji tercihi olmaktan çok bir teşhis meselesi. Doğru teşhisi koyduğunuzda seçenek genelde kendiliğinden belirginleşiyor, hatta çoğu zaman en ucuz olanı yeterli çıkıyor. Elinizdeki problemin hangi düğüme düştüğünden emin değilseniz, karar vermeden önce yarım günlük bir teşhis çalışması sizi aylarca sürecek yanlış bir kurulumdan kurtarır.