RAG mı, Fine-tuning mı? 2026 Karar Çerçevesi (LoRA, QLoRA, RFT, GRPO)

TL;DR — RAG ile fine-tuning birbirinin rakibi değil, birbirini tamamlayan iki ayrı iştir. Fine-tuning modele davranış ve biçim öğretir; güncel ya da belgeye dayalı bilgi için doğru araç RAG'dir. 2026'da benim sahadan önerdiğim sıralama net: önce Prompt, sonra RAG, sonra Fine-tune, en son Distill. En yüksek getiriyi veren kombinasyon, güçlü bir temel modelin üzerine oturtulmuş ince bir LoRA/QLoRA adaptörünü retrieval ile birlikte kullanmaktır — retrieval'ı değiştirmek değil, onunla birlikte çalıştırmak. Bu yazıda LoRA, QLoRA, RFT, GRPO, PEFT, kuantizasyon, distilasyon ve 7B–14B küçük dil modellerini; Türkiye'deki KVKK ve veri ikametgahı gerçekleriyle birlikte, karar verirken kullanabileceğiniz somut bir çerçeveye oturtuyorum.

Sahada danışmanlık yaparken en çok karşılaştığım cümle şu: "Hocam biz modeli kendi verimizle eğitelim, o zaman şirketin bütün bilgisini bilir." Kulağa mantıklı geliyor, biliyorum. Ama bu cümle, kariyerimde gördüğüm en pahalı yanlış anlamalardan birini içeriyor.

Size en baştan, hiç dolandırmadan söyleyeyim: fine-tuning modele yeni gerçek bilgiler (fact) öğretmez. Fine-tuning modele davranış ve biçim öğretir. Bir modeli şirketinizin dökümanlarıyla ince ayardan geçirdiğinizde, model o dökümanların "tarzını" taklit etmeyi öğrenir; ama o dökümanların içindeki bilgiyi güvenilir biçimde ezberlemez. Daha da kötüsü, hiç görmediği ya da sonradan değişen bir veri hakkında sorulduğunda, kendinden emin bir tonda uydurmaya (hallucination) devam eder. Yani parayı harcarsınız, ama halüsinasyon problemi çözülmez; sadece daha "sizin gibi konuşan" bir halüsinasyon makinesi elde edersiniz.

Bu yüzden 2026'da bir projeye başlarken ilk sorduğum soru hep aynı: "Sen modelden yeni bir bilgi mi istiyorsun, yoksa yeni bir davranış mı?" Bu tek soru, önünüzdeki yol haritasının yüzde sekseninin belirler.

• Eğer cevabınız "güncel bilgi, belgeye dayalı cevap, sürekli değişen SSS, ürün kataloğu, mevzuat" ise — bu RAG işidir.
• Eğer cevabınız "belirli bir ton, kurumsal bir üslup, katı bir çıktı formatı (JSON, rapor şablonu), özel bir görev davranışı" ise — bu fine-tuning işidir.

Bu ayrımı içselleştirdiğinizde, geri kalan her şey teknik detaydan ibaret. Şimdi o detaylara inelim.

RAG — açılımıyla Retrieval-Augmented Generation, yani "getirmeyle zenginleştirilmiş üretim" — aslında çok basit bir fikir üzerine kurulu. Model bir soruyu yanıtlamadan önce, dışarıdaki bir bilgi kaynağından (vektör veritabanı, arama motoru, belge deposu) konuyla ilgili parçaları getiriyor ve bu parçaları soruyla birlikte modele veriyorsunuz. Model de artık ezberinden değil, önüne konan bu güncel metinden yola çıkarak cevap üretiyor.

Bunun neden bu kadar güçlü olduğunu anlamak için şu senaryoyu düşünün: Bir bankanın ürün ekibiyle çalışıyorsunuz ve kredi faiz oranları haftada iki kez değişiyor. Bu bilgiyi modele fine-tuning ile öğretmeye kalkarsanız, her oran değişikliğinde yeniden eğitim yapmanız gerekir — hem absürt derecede pahalı hem de imkânsız derecede yavaş. Oysa RAG ile faiz tablosunu bir veri kaynağına koyar, model her sorulduğunda oradan güncel değeri çeker. Bilgi değişti mi? Sadece tabloyu güncellersiniz, modele hiç dokunmazsınız.

RAG'in güçlü olduğu yerler:

• Sürekli değişen bilgi: fiyatlar, stoklar, mevzuat, kampanyalar.
• Belgeye dayalı, kaynak gösterebilen cevaplar: "Bu bilgi hangi dökümandan geldi?" sorusuna cevap verebilmek.
• Büyük ve dağınık kurumsal bilgi tabanları: binlerce PDF, wiki sayfası, sözleşme.
• Halüsinasyonu azaltma: model önüne konan metne dayandığı için, uydurma riski belirgin biçimde düşer.

Ama RAG her derde deva değil. RAG modelin nasıl konuştuğunu değiştirmez. Modele önüne on tane mükemmel döküman koyabilirsiniz, ama model hâlâ dağınık, fazla uzun, yanlış formatta ya da markanızın ses tonuna uymayan cevaplar üretiyorsa — bu bir bilgi problemi değil, bir davranış problemidir. İşte tam bu noktada fine-tuning devreye girer.

Fine-tuning'i şöyle düşünün: RAG modele ne bileceğini söyler, fine-tuning modele nasıl davranacağını öğretir. İkisi farklı katmanlardır.

Sahadan somut örnekler vereyim, çünkü teori havada kalıyor:

• Ton ve üslup: Bir sigorta şirketinin müşteri hizmetleri asistanının her cevabı belirli bir nezaket ve netlik standardında olsun istiyorsunuz. Prompt ile bir yere kadar zorlarsınız, ama tutarlılık için fine-tuning çok daha sağlamdır.
• Katı çıktı formatı: Modelin her seferinde geçerli bir JSON, belirli alanları olan bir rapor şablonu ya da standart bir dilekçe formatı üretmesini istiyorsanız — bunu birkaç yüz iyi örnekle fine-tuning ile öğretmek, prompt'ta yalvarmaktan çok daha güvenilirdir.
• Özel görev davranışı: Belirli bir sınıflandırma mantığı, kuruma özgü bir etiketleme şeması, ya da genel modelin doğal olarak bilmediği bir akıl yürütme kalıbı.

Peki fine-tuning'e ne zaman değmez? Cevabınız "güncel bilgi lazım" olduğunda. Bir modeli mevzuatla eğitirseniz ve mevzuat değişirse, elinizde yanlış bilgiyi kendinden emin biçimde söyleyen bir model kalır. Bu tuzağa çok kurum düştü.

"

Basit bir pusula: Cevap değiştiğinde modeli mi yoksa veritabanını mı güncellemek istersiniz? Cevabınız "veritabanı" ise RAG'e, "model davranışı" ise fine-tuning'e ihtiyacınız var.

Birkaç yıl öncesine kadar "fine-tuning" demek, dev bir modelin tüm parametrelerini yeniden eğitmek demekti — yüz binlerce dolar, devasa GPU kümeleri, haftalarca süren işler. Bu, çoğu kurum için erişilemezdi. Ama işler tamamen değişti ve değiştiren şeyin adı PEFT.

PEFT — Parameter-Efficient Fine-Tuning, yani "parametre açısından verimli ince ayar" — modelin tamamını değil, çok küçük bir kısmını eğitme fikridir. En popüler PEFT yöntemi LoRA (Low-Rank Adaptation).

LoRA'nın çalışma mantığı şu: Temel modelin dev ağırlık matrislerini olduğu gibi donduruyorsunuz — onlara hiç dokunmuyorsunuz. Bunun yerine, modelin katmanlarına çok küçük, eğitilebilir "adaptör" matrisleri enjekte ediyorsunuz. Eğitim sırasında yalnızca bu küçük adaptörler güncelleniyor. Bu adaptörler tipik olarak modelin toplam parametrelerinin sadece yüzde 0,1 ile 1'i kadar. Yani milyarlarca parametreli bir modelde, siz sadece birkaç milyon parametreyi eğitiyorsunuz.

Bunun pratikteki sonuçları devrimsel:

• Bir fine-tuning işi artık birkaç yüz dolar seviyesine iniyor.
• Tek bir temel modelin üzerinde onlarca göreve özel adaptör tutmak mümkün hale geliyor. Bir adaptör hukuk metinleri için, biri müşteri hizmetleri tonu için, biri rapor formatı için — hepsi aynı temel modeli paylaşıyor, her biri birkaç megabayt.
• Adaptörleri takıp çıkarmak, yeni bir dev model deploy etmekten çok daha ucuz ve esnek.

QLoRA ise LoRA'nın bir adım ötesi. Buradaki "Q" kuantizasyon (quantization) demek. Kuantizasyon, modelin ağırlıklarını daha düşük hassasiyette (örneğin 16-bit yerine 4-bit) temsil ederek bellek kullanımını dramatik biçimde düşürme tekniğidir. QLoRA, temel modeli kuantize edilmiş halde bellekte tutar ve LoRA adaptörlerini bunun üzerinde eğitir. Sonuç: çok daha az GPU belleğiyle, hatta tek bir mütevazı GPU ile ciddi modelleri fine-tune edebilirsiniz. Bellek açısından çok daha ucuz.

Burada anahtar kelimeyi altını çizerek söyleyeyim: adaptör. Modern fine-tuning felsefesi, dev modeli baştan yaratmak değil, güçlü bir temelin üzerine ince, taşınabilir, ucuz katmanlar eklemektir. Bu felsefeyi kavradığınızda, fine-tuning artık korkutucu ve pahalı bir dev proje değil, ölçeklenebilir bir mühendislik pratiği haline gelir.

Birkaç yıl önce "ciddi iş" için tek seçenek en büyük, en pahalı kapalı modellerdi. Artık öyle değil. Sahada gördüğüm en heyecan verici gelişmelerden biri, 7B–14B parametre aralığındaki küçük dil modellerinin dar ve iyi tanımlı alanlarda GPT-4 sınıfı kaliteye ulaşabilmesi.

Bu cümlenin altını çizmek istiyorum çünkü ekonomik sonuçları çok büyük: Dar bir alanda — diyelim ki belirli bir sektörün müşteri destek soruları, ya da belirli bir belge türünün özetlenmesi — iyi seçilmiş 7B–14B'lik bir model, iyi bir fine-tuning ile en büyük modellerle boy ölçüşebiliyor. Ve bunu yaparken fine-tuning maliyetini bir büyüklük mertebesi (yani yaklaşık on kat) düşürüyor.

Neden önemli? Çünkü küçük model demek:

• Daha ucuz eğitim ve daha ucuz çalıştırma (inference).
• Kendi altyapınızda (on-prem) çalıştırabilme imkânı — ki bu, birazdan konuşacağımız Türkiye ve KVKK bağlamında kritik.
• Daha hızlı yanıt, daha düşük gecikme.
• Onlarca göreve özel adaptörü rahatça yönetebilme.

Yani "en büyük model her zaman en iyisidir" dogması 2026'da artık geçerli değil. Dar bir problemi çok iyi çözen küçük ve ince ayarlı bir model, çoğu kurumsal senaryoda hem daha ucuz hem de daha kontrol edilebilir.

Fine-tuning denince çoğu insanın aklına "girdi–çıktı örnekleri gösterip taklit ettirmek" gelir. Buna supervised fine-tuning (denetimli ince ayar) denir ve hâlâ en yaygın yöntemdir. Ama 2026'da cephaneliğimiz çok daha zengin.

RFT — Reinforcement Fine-Tuning (pekiştirmeli ince ayar), modeli doğru örnekleri taklit ederek değil, doğru sonuçları ödüllendirerek eğitir. Özellikle doğrulanabilir görevlerde çok güçlüdür: cevabın doğru mu yanlış mı olduğunu otomatik kontrol edebiliyorsanız — bir matematik probleminin sonucu, bir kod parçasının çalışıp çalışmadığı, bir sınıflandırmanın doğruluğu gibi — RFT modelin akıl yürütme (reasoning) becerisini belirgin biçimde iyileştirebilir. Mantık şu: model bir cevap üretir, sistem bu cevabın doğru olup olmadığını kontrol eder, doğruysa o davranışı pekiştirir. Zamanla model doğru sonuca götüren düşünme kalıplarını benimser.

DPO — Direct Preference Optimization (doğrudan tercih optimizasyonu) ise farklı bir yaklaşım. Burada modele "şu cevap şundan daha iyi" biçiminde tercih çiftleri gösterirsiniz ve model iyi olanı üretmeye, kötü olandan kaçınmaya doğru ayarlanır. Ton, üslup ve "hangi cevap daha makbul" türü tercihleri öğretmek için pratiktir.

GRPO — Group Relative Policy Optimization ise pekiştirmeli öğrenme ailesinden, akıl yürütme odaklı modellerin eğitiminde öne çıkan bir yöntem. Aynı soru için bir grup cevap üretip, bunları birbirine göre değerlendirerek modeli daha iyi cevaplar üretmeye yönlendirir.

İşin pratik tarafı şu: 2026'da büyük sağlayıcılar (major providers) artık supervised, DPO ve reinforcement fine-tuning yöntemlerinin üçünü de destekliyor. Yani bu teknikler artık sadece araştırma laboratuvarlarının oyuncağı değil; kurumsal bir ekibin erişebileceği, yönetilebilir servisler haline geldi.

Şunu da dürüstçe söyleyeyim: Çoğu kurumsal proje için hâlâ supervised fine-tuning + iyi bir RAG kombinasyonu yeterli. RFT ve GRPO gibi yöntemlere, doğrulanabilir ve karmaşık akıl yürütme gerektiren özel problemleriniz olduğunda uzanırsınız. Aracı problemine göre seçin; en gösterişli tekniği değil, işi çözeni.

Karar çerçevesinin son parçası distilasyon (distillation). Distilasyon, büyük ve yetenekli bir "öğretmen" modelin davranışını, daha küçük ve ucuz bir "öğrenci" modele aktarma tekniğidir. Öğretmen model bir sürü örnek üretir, siz de küçük modeli bu örneklerle eğitirsiniz. Sonuçta küçük model, büyük modelin belirli bir görevdeki yeteneğinin çoğunu, çok daha düşük maliyetle taklit edebilir hale gelir.

Distilasyon neden karar çerçevesinin en sonunda yer alır? Çünkü distilasyon bir optimizasyon adımıdır — çözümü bulduktan sonra ucuzlatmak içindir. Önce büyük bir modelle işin doğru cevabı verdiğini kanıtlarsınız, sonra o kaliteyi küçük ve ucuz bir modele damıtarak üretimde ölçeklersiniz. Henüz doğru çözümü bulmadan distilasyona girişmek, olmayan bir şeyi ucuzlatmaya çalışmaktır.

Şimdi bütün parçaları tek bir yol haritasında birleştirelim. Sahada bana defalarca kanıtlanmış olan sıralama şu ve bu sıralamaya sadık kalmanızı içtenlikle öneriyorum:

1. Prompt. Her zaman en ucuz ve en hızlı adımla başlayın. İyi yazılmış bir sistem prompt'u, birkaç örnek (few-shot) ve net talimatlarla şaşırtıcı derecede yol alırsınız. Problemlerin ciddi bir kısmı buradan çözülür. Hiçbir GPU, hiçbir eğitim, hiçbir maliyet.

2. RAG. Prompt yetmediğinde ve eksik olan şey bilgi ise, retrieval ekleyin. Kurumsal dökümanlarınızı, SSS'lerinizi, kataloglarınızı modele erişilebilir kılın. Bilgi problemlerinin büyük çoğunluğu bu katmanda, modele hiç dokunmadan çözülür.

3. Fine-tune. Prompt ve RAG'e rağmen hâlâ bir davranış problemi kalıyorsa — model doğru bilgiye sahip ama yanlış biçimde, yanlış tonda ya da tutarsız konuşuyorsa — o zaman ince bir LoRA/QLoRA adaptörü eğitin. Ama dikkat: bunu RAG'in yerine değil, RAG ile birlikte yapın.

4. Distill. En sonunda, çözümünüz kanıtlandıktan ve maliyeti düşürmek istediğinizde, kaliteyi küçük bir modele damıtın.

Bu sıralamanın en kritik cümlesini kalınlaştırarak söyleyeyim: En yüksek getirili (ROI) fine-tuning, güçlü bir temel modelin üzerine oturtulmuş ince bir LoRA/QLoRA adaptörüdür ve bu adaptör retrieval ile eşleştirilir — retrieval'ı değiştirmez. Yani ideal kurumsal mimari şudur: sağlam bir açık temel model + davranışı ayarlayan ince bir adaptör + güncel bilgiyi getiren bir RAG katmanı. Üçü bir arada.

Çok gördüğüm bir hata da şu: ekipler doğrudan 3. adıma atlıyor. "Fine-tuning" kelimesi kulağa daha ciddi, daha "yapay zeka" geldiği için, önce prompt ve RAG'i düzgün denemeden pahalı eğitime giriyorlar. Neredeyse her seferinde, geri dönüp önce bu iki ucuz katmanı düzgün kurduğumuzda problemin yarısının zaten çözüldüğünü görüyoruz.

"Ne zaman fine-tuning yapmalıyım?" sorusunun teknik cevabı, büyük ölçüde elinizdeki veriyle ilgili. Şunları göz önünde bulundurun:

• Kalite, hacimden önce gelir. Fine-tuning'de birkaç yüz gerçekten temiz, tutarlı ve doğru etiketlenmiş örnek, on binlerce dağınık ve çelişkili örnekten daha iyi sonuç verir. Model, verinizdeki tutarsızlıkları da öğrenir — çöp girerse çöp çıkar.
• Tutarlılık kritiktir. Fine-tuning'in amacı bir kalıp öğretmekse, o kalıbın örneklerde tutarlı olması gerekir. Farklı örneklerde çelişen tonlar ya da formatlar varsa, model kafası karışık bir davranış öğrenir.
• Veri, öğretmek istediğiniz davranışı temsil etmeli. Ton öğretiyorsanız örnekler o tonu taşımalı; format öğretiyorsanız örnekler tam istediğiniz formatta olmalı.
• Hacim eşiği görece düşüktür. LoRA/QLoRA çağında, birkaç yüz ila birkaç bin kaliteli örnekle anlamlı davranış değişimi elde edebilirsiniz. Bu, eskisi kadar ürkütücü bir veri yükümlülüğü değil.

Pratik kural: Elinizde belirli bir davranışı temsil eden, temiz ve tutarlı birkaç yüz örnek varsa ve prompt/RAG bu davranışı sağlayamıyorsa — fine-tuning haklıdır. Ama verileriniz dağınıksa, önce veriyi temizlemeye yatırım yapın; kötü veriyle yapılan fine-tuning, iyi niyetli para yakmaktır.

Şimdi bu yazının Türkiye'de çalışan bir profesyonel için belki de en önemli kısmına geldik. Çünkü teknik doğrular evrenseldir, ama uygulama her zaman yereldir.

Türkiye'de kurumsal yapay zeka projelerinde en sık karşılaştığım kısıt teknik değil, hukuki ve düzenleyici: KVKK (Kişisel Verilerin Korunması Kanunu) ve veri ikametgahı (data residency) gereklilikleri. Birçok kurum — özellikle bankacılık, sağlık, sigorta, kamu ve savunma — hassas verisinin yurt dışındaki bir bulut modeline gitmesini istemez ya da hukuken isteyemez. Verinin sınırların içinde, kontrol edilebilir bir altyapıda kalması gerekir.

İşte bu kısıt, bu yazıda anlattığım teknik tercihleri doğrudan şekillendiriyor:

• Açık modellerin on-prem fine-tuning'i büyük avantaj. Açık ağırlıklı (open-weight) bir temel modeli kendi veri merkezinizde ya da Türkiye'deki bir bulutta çalıştırıp, kendi verinizle fine-tune edebilirsiniz. Veri hiçbir zaman kurumun kontrolünden çıkmaz. KVKK açısından bu, kapalı bir yurt dışı API'sine hassas veri göndermekten çok daha savunulabilir bir konumdur.
• Küçük modeller bu senaryoyu mümkün kılıyor. 7B–14B'lik modellerin dar alanlarda büyük modellerle yarışabilmesi, on-prem dağıtımı gerçekten uygulanabilir hale getiriyor. Devasa bir modeli kendi altyapınızda çalıştırmak çoğu kurum için ağır bir yük; ama iyi ayarlanmış küçük bir model, mütevazı donanımla çalışır.
• LoRA/QLoRA'nın ucuzluğu yerel ekiplerin işine yarıyor. Birkaç yüz dolarlık fine-tuning maliyeti ve tek GPU ile çalışabilme, Türkiye'deki orta ölçekli kurumların bile kendi adaptörlerini üretebilmesi demek. Dev bütçelere ihtiyaç yok.
• Türkçe-alan adaptörleri. Genel modeller Türkçede iyileşse de, spesifik bir sektörün Türkçe terminolojisi (hukuk, tıp, finans mevzuatı, kamu yazışma üslubu) için Türkçe-alan adaptörleri eğitmek çok mantıklı. Güçlü bir temel modelin üzerine, kurumunuzun Türkçe belgeleriyle eğitilmiş ince bir adaptör; işte KVKK dostu, yerel ve ekonomik mimari tam olarak budur.

Türkiye'de bir mimari kurarken benim tavsiyem net: hassas veriyle çalışıyorsanız, açık temel model + on-prem/yerel bulut + LoRA/QLoRA adaptörü + yerel bir vektör veritabanıyla RAG kombinasyonunu ciddi biçimde değerlendirin. Bu yapı, hem regülasyona uyar hem de teknik olarak 2026'nın en verimli yaklaşımıdır. İkisi çelişmez; tam tersine, düzenleyici kısıtlar sizi zaten teknik olarak en akıllı mimariye doğru itiyor.

Aşağıdaki tabloyu bir başvuru pusulası olarak kullanabilirsiniz. Sahada ekiplere dağıttığım pratik özet budur:

İhtiyaç / Durum	Doğru araç	Neden
Güncel, sık değişen bilgi (fiyat, stok, mevzuat)	RAG	Bilgiyi güncellemek modeli değil veritabanını güncellemektir
Kaynak gösterebilen, belgeye dayalı cevap	RAG	Model önüne konan metne dayanır, izlenebilirlik sağlar
Halüsinasyonu azaltma (bilgi tabanı üzerinde)	RAG	Model ezberden değil, getirilen metinden konuşur
Belirli bir ton / kurumsal üslup	Fine-tune (LoRA)	Davranış öğretmek fine-tuning'in işidir
Katı çıktı formatı (JSON, rapor şablonu)	Fine-tune (LoRA)	Tutarlı biçim, birkaç yüz örnekle sağlamca öğrenilir
Özel akıl yürütme, doğrulanabilir görevler	Fine-tune (RFT/GRPO)	Doğru sonucu ödüllendirmek reasoning'i iyileştirir
Yurt dışına veri gönderilemeyen KVKK senaryosu	On-prem açık model + LoRA + RAG	Veri kurumun kontrolünde kalır
Kanıtlanmış çözümü ucuzlatmak	Distilasyon	Kaliteyi küçük/ucuz modele damıtır
Henüz hiçbir şey denenmemiş	Önce Prompt	En ucuz, en hızlı; sorunun bir kısmını çözer

Bu tabloya bakarken şunu unutmayın: çoğu gerçek projede tek bir hücreyi değil, birkaç satırı aynı anda işaretlersiniz. "Hem güncel bilgi hem kurumsal ton lazım" dediğinizde cevap "RAG mı fine-tuning mi" değil, "RAG ve fine-tuning"dir. Zaten bu yazının ana tezi de bu: bunlar rakip değil, katman.

Somutlaştırmak için, sahada defalarca kurduğumuz tipik bir mimariyi anlatayım. Diyelim ki bir sigorta şirketi için müşteri hizmetleri asistanı kuruyoruz.

Önce prompt ile başlarız: modele rolünü, sınırlarını ve genel üslubunu net talimatlarla veririz. Bir hafta içinde, basit soruların önemli bir kısmı zaten makul biçimde yanıtlanır hale gelir.

Sonra RAG ekleriz: poliçe belgeleri, teminat tabloları, SSS'ler ve güncel kampanya bilgileri bir vektör veritabanına konur. Artık asistan "benim poliçemde diş tedavisi var mı?" gibi belgeye dayalı soruları, güncel ve kaynak göstererek yanıtlayabilir. Bilgi değiştiğinde belgeleri güncelleriz, modele dokunmayız.

Testlerde görürüz ki model doğru bilgiyi veriyor ama cevapları bazen fazla uzun, bazen fazla teknik, bazen şirketin sıcak ama net üslubuna uymuyor. Bu bir davranış problemi. Burada fine-tune devreye girer: birkaç yüz örnek ideal cevabı — doğru tonda, doğru uzunlukta, doğru formatta — hazırlar, güçlü bir açık temel modelin üzerine ince bir LoRA adaptörü eğitiriz. KVKK gereği bunu kendi altyapımızda yaparız. Artık asistan hem doğru bilgiyi (RAG'den) hem de doğru üslubu (adaptörden) birleştirir.

Sistem üretimde olgunlaşıp trafik arttığında, maliyeti düşürmek için distilasyona bakarız: büyük kurulumun ürettiği kaliteli cevaplarla daha küçük bir modeli eğitir, üretimde onu çalıştırırız.

Dikkat edin: her adım bir öncekinin üzerine ekleniyor, hiçbiri diğerini iptal etmiyor. Prompt → RAG → Fine-tune → Distill. İşte 2026'nın kurumsal yapay zeka omurgası bu.

Sahada bu konuyu anlattığımda hep aynı itirazlar geliyor. En sık duyduklarımı ve onlara verdiğim samimi cevapları buraya bırakayım, çünkü büyük ihtimalle sizin aklınızda da benzerleri var.

"Ama biz modelin her şeyi ezberden bilmesini istiyoruz, her seferinde döküman getirmesi yavaş değil mi?" Modern RAG kurulumlarında getirme adımı milisaniyeler sürer ve modelin ezberine güvenmenin bedeli, o ezberin eskimesi ve halüsinasyona dönüşmesidir. Hız için güvenilirliği feda etmek, kurumsal bir asistanda genellikle kötü bir takas olur. Üstelik doğru cevabı kaynağıyla gösterebilmek, çoğu regüle sektörde bir lüks değil, zorunluluktur.

"Fine-tuning yaparsak RAG'e gerek kalmaz, değil mi?" Hayır. Bu, bu yazının en çok tekrarladığım noktası. Fine-tuning davranışı ayarlar, bilgiyi taze tutmaz. İyi kurulmuş bir sistemde ikisi yan yana durur; fine-tune edilmiş model doğru üslupla konuşur, RAG katmanı ona güncel gerçekleri besler. Birini diğerinin yerine koymak, tam da baştaki pahalı yanlış anlamaya geri dönmektir.

"Küçük model kalite kaybı demek değil mi?" Dar ve iyi tanımlı bir alanda, hayır. Genel amaçlı bir sohbet için en büyük model hâlâ öndedir; ama sizin probleminiz "şu sektörün şu tip sorularını yanıtlamak" gibi dar bir alansa, iyi ayarlanmış 7B–14B'lik bir model çoğu zaman ihtiyacınızın tamamını, kesrine mal olarak karşılar. Önemli olan modeli probleme oturtmaktır; en büyüğü kovalamak değil.

"Bütün bunları kurmak için dev bir ekip lazım." Birkaç yıl önce doğruydu, artık değil. PEFT, tek GPU ile QLoRA, hazır RAG çatıları ve sağlayıcıların yönetilen fine-tuning servisleri sayesinde, orta ölçekli bir ekip bile bu mimariyi ayağa kaldırabiliyor. Engel artık teknoloji değil, çoğu zaman doğru teşhis ve disiplinli sıralama.

Eğer bu yazıdan tek bir eylem planı çıkaracaksanız, şu olsun:

1. Problemi doğru adlandırın. Elinizdeki eksik bilgi mi yoksa davranış mı? Bu tek soruyu dürüstçe yanıtlayın; çünkü yanlış teşhis, yanlış ve pahalı tedaviye götürür.
2. Ucuzdan pahalıya ilerleyin. Önce prompt, sonra RAG. Ancak bunlar gerçekten yetmediğinde fine-tune'a geçin. Fine-tuning kelimesinin cazibesine kapılıp sırayı atlamayın.
3. Fine-tune yapacaksanız ince yapın. Tüm modeli değil, LoRA/QLoRA adaptörü. Güçlü bir temel seçin, birkaç yüz temiz örnek hazırlayın, adaptörü RAG ile birlikte çalıştırın.
4. Türkiye'de regülasyonu mimariye çevirin. KVKK ve veri ikametgahı bir engel değil, bir tasarım kılavuzu. Açık model + on-prem + adaptör + yerel RAG; hem uyumlu hem verimli.
5. Veriye yatırım yapın. Fine-tuning'in kalitesi verinizin kalitesidir. Birkaç yüz mükemmel örnek, on bin dağınık örnekten iyidir.

Bütün bu tabloya yukarıdan baktığınızda göreceğiniz şey şu: 2026'da doğru soru artık "RAG mı, fine-tuning mi?" değil. Doğru soru, "bu iki katmanı — ve altındaki prompt ile üstündeki distilasyonu — kendi problemim ve kendi regülasyonum için hangi sırayla ve hangi dozda birleştireceğim?" Bu soruyu netçe yanıtlayabilen ekip, hem parasını hem de zamanını en doğru yere koyar; ve sahadaki tecrübem bana defalarca gösterdi ki, bu netlik en pahalı GPU'dan çok daha değerlidir.