RAG mı, Fine-Tuning mi? RAG ve Fine-Tuning Farkı ve Karar Rehberi

Kısaca: RAG ile fine-tuning arasındaki fark, neyi değiştirdikleridir. RAG (retrieval-augmented generation) modelin ağırlıklarına dokunmaz; yanıt anında ilgili belgeleri bulup modele verir ve güncel, kaynak gösterilebilir bilgi sağlar. Fine-tuning (ince ayar) ise modeli kendi örneklerinizle eğitmeye devam ederek ağırlıklarını değiştirir ve biçim, üslup ve dar görev davranışını düzeltir. Bilgi eksikse RAG, davranış eksikse fine-tuning. Üçüncü yol olan prompting ise yalnızca talimatları değiştirir ve genellikle ilk denenmesi gereken adımdır.

Bu rehber, 22–29 Ekim 2026 haftalık yapay zeka bültenimizle aynı hafta yayımlanan karar rehberlerimizden biridir. Bilgilendirme: RuneLab, bu yazıda adı geçen prompting, RAG ve fine-tuning eğitimlerini ve RuneDesk doküman asistanını sunar.

1. Model sizin bilgilerinizi bilmiyorsa (fiyat listesi, prosedür, sözleşme), RAG’i seçin.
2. Model yeterince biliyor ama biçim, üslup ya da görev davranışı yanlışsa, fine-tuning’i düşünün.
3. İkisinden önce daha iyi bir prompt deneyin. Uzun talimatları tekrar tekrar gönderiyorsanız prompt caching’e bakın.
4. Yanıtın hangi belgeden geldiğini göstermeniz gerekiyorsa, RAG kullanın.
5. Hacim yüksek ve gecikme hedefi sıkıysa, dar bir görev için küçük bir fine-tuned model değerlendirin.

Aşağıdaki her bölüm bu kurallardan birinin gerekçesini kaynağıyla birlikte veriyor.

Kısa cevap: RAG modelin ne gördüğünü, fine-tuning ise nasıl davrandığını değiştirir. Together AI’nin karar rehberi ve Elastic’in karşılaştırması da farkı böyle tanımlıyor. RAG’de modele sorulan soruyla birlikte ilgili belge parçaları da verilir; model bu parçalara bakarak yanıt yazar. Fine-tuning’de ise model, sizin hazırladığınız giriş/çıkış örnekleriyle eğitilmeye devam eder ve öğrendiği kalıplar ağırlıklara yerleşir.

Doğru yöntemi seçmenin ilk adımı, modelin neden başarısız olduğunu anlamaktır. Together AI bunu bir destek botu örneğiyle anlatıyor: iade politikasını uyduran bir botta bilgi eksikliği vardır; politikayı bilen ama yanıtı yanlış yapıda veren bir botta ise davranış eksikliği. Retrieval ikinci sorunu çözmez; eğitim de birinci sorun için zayıf bir çözümdür.

Meta’nın uygulamalı araştırma ekibi de benzer sorular öneriyor: Uygulamanız dış bilgiye ihtiyaç duyuyor mu? Özel bir ton, kelime dağarcığı ya da üslup gerekiyor mu? Veri ne kadar durağan? Meta’ya göre fine-tuning, modele yeni bilgi eklemek için genellikle yararlı değildir; üslup ve davranış gereksinimlerinde ise genellikle doğru yaklaşımdır.

RuneLab’ın Prompting, RAG veya Fine-Tuning: LLM Uyarlama Karar Çerçevesi eğitimi de aynı teşhisle başlıyor: bilgi eksikliği (facts/context) ile beceri ve format eksikliği (form/style/reasoning) ayrımı.

Modelin hatalı yanıtlarından 50 ile 200 arası etiketli örnekten oluşan bir değerlendirme kümesi alın ve her biri için üç soru sorun:

1. Eksik olan bir bilgi mi? Model doğru rakamı, maddeyi ya da ürün adını bilmiyorsa sorun bilgidir. RAG’e yönelin.
2. Bu bilgi sık değişiyor mu? Haftalık değişen fiyatlar ve politikalar, eğitimle güncel tutulamaz. Bu da RAG’i işaret eder.
3. Hata biçimde ya da tonda mı? Bilgi doğru ama JSON şeması bozuk, üslup kurumunuza uymuyor ya da adımlar yanlış sıradaysa sorun davranıştır. Önce prompt’u, sonra fine-tuning’i deneyin.

Prompting, en ucuz ve en hızlı geri alınabilen adımdır. Sistem prompt’unu netleştirmek, birkaç örnek (few-shot) eklemek ya da çıktıyı bir şemaya bağlamak, “fine-tuning gerekiyor” denen birçok sorunu eğitim yapmadan çözebilir. Together AI, bozuk JSON şikâyetinde önce yapılandırılmış çıktıları (structured outputs) denemeyi öneriyor. Meta da few-shot öğrenmenin (in-context learning) her fine-tuning denemesinden önce test edilmesini tavsiye ediyor.

Prompt caching (prompt önbellekleme), aynı uzun talimatları her istekte tekrar gönderdiğinizde, sağlayıcının bu tekrar eden kısmı önbellekten okumasıdır. Böylece uzun sistem prompt’larının istek başına maliyeti ve gecikmesi azalabilir.

Prompting’in yetmediğini gösteren üç işaret vardır:

• Prompt o kadar uzadı ki her istekte ciddi maliyet ve gecikme ekliyor.
• Aynı talimatlara rağmen davranış tutarsız kalıyor.
• Sorun aslında bilgi eksikliği; bu durumda prompt’a belge yapıştırmak yerine RAG kurmak gerekir.

RAG üç durumda öne çıkar: bilgi sık değişiyorsa, yanıtın kaynağını göstermeniz gerekiyorsa ve her kullanıcının yalnızca yetkili olduğu belgeleri görmesi gerekiyorsa.

AWS Prescriptive Guidance bu farkı açıkça yazıyor: RAG yeni belgeleri dakikalar içinde sisteme katabilir (“RAG can incorporate the latest documents in a few minutes”), buna karşılık fine-tuned modeller yanıtlarında kaynağa atıf vermez (“Fine-tuned models do not provide a reference to the source in their responses”). RAG’in adım adım nasıl çalıştığını RAG yanıtları nasıl bulur? yazımızda, kurumsal retrieval kalitesinin nasıl ölçüleceğini ise Türkçe RAG nasıl test edilir? (Ekim 2026) rehberimizde anlattık.

Fine-tuning, modelin nasıl çalıştığını değiştirmek istediğinizde anlamlıdır. Together AI’nin saydığı durumlar şunlar: tutarlı biçim ve şema, kurum üslubu ve tonu, kendi sınıflandırmanıza göre etiketleme, çıkarım ve yönlendirme gibi dar görevler ve uzun prompt’lu büyük model yerine kısa prompt’lu küçük bir modelle daha ekonomik çıkarım.

Maliyeti düşürmenin yaygın yolu LoRA’dır. Together AI’ye göre LoRA, tam bir eğitimin güncellediği parametrelerin yaklaşık %0,1 ile %1’ini eğitir. LoRA’nın mantığını LoRA ile dev modelleri hafifletmek mümkün mü? yazımızda anlattık; uygulamalı tarafı LoRA ve QLoRA ile Uygulamalı Model Özelleştirme eğitiminin konusudur. Ayrıca açık ağırlıklı bir modeli fine-tune ederken ticari kullanım hakkının lisansa bağlı olduğunu unutmayın; ayrıntılar için Ekim 2026 açık ağırlıklı model lisansları yazımıza bakın.

Together AI’nin tablosuna göre fine-tuning en az yüzlerce yüksek kaliteli etiketli örnek, çoğunlukla binlerce örnek (“hundreds of high-quality labeled examples at minimum, usually thousands”) gerektirir. Bu örnekleri güvenilir biçimde üretmenin bir yolu yoksa fine-tuning planı da yoktur.

Evet. AWS ve Meta, çoğu olgun kurumsal senaryoda iki yaklaşımın birleştirilebileceğini belirtir. Yaygın hibrit yaklaşımlar şunlardır:

• RAFT (Retrieval-Augmented Fine-Tuning): Modeli bir soru, ilgili belge ve yanıltıcı (alakasız) belgelerle birlikte eğiterek doğru belgeyi kullanmayı ve ötekileri yok saymayı öğretmek (Zhang ve arkadaşları, 2024).
• Retriever’ı ya da reranker’ı uyarlamak: Üretici modele dokunmadan önce embedding modelini fine-tune etmek veya aday kümesi üzerinde reranker kullanmak.
• Davranış için fine-tuning, bilgi için RAG: Model biçimi, atıf stilini ve tonu eğitimle öğrenir; güncel bilgiler indekste kalır.
• Distillation (damıtma): Büyük bir modelin belirli bir görevdeki becerisini daha küçük bir modele aktarmak (bkz. Model distillation nedir?).

Türkçe sondan eklemeli bir dil olduğu için hem retrieval aşamasında (kullanıcı sorusundaki eklerle belgedeki kök/ek biçimlerinin eşleşmesi) hem de maliyet aşamasında (Türkçe metnin kaç tokene bölündüğü) kendi kurum belgelerinizden hazırlanmış bir değerlendirme setiyle ölçüm yapılmalıdır (Türkçe için Dil Modelleri: Tokenizasyon, Değerlendirme ve Uyarlama).

Ölçüt	Prompting	RAG	Fine-tuning	RAG + Fine-tuning
Ne değişir?	Talimatlar ve örnekler	Modele verilen bağlam (bulunan belgeler)	Modelin ağırlıkları	Bağlam ve ağırlıklar
Neyi çözer?	Basit biçim ve görev sorunları	Bilgi eksikliği	Davranış eksikliği (biçim, üslup, dar görev)	İkisi birden ölçüldüğünde
Bilgi sık değişiyorsa	Uygun değil	Uygun; yeni belgeler dakikalar içinde eklenir	Zayıf; her değişiklikte yeniden eğitim gerekir	RAG tarafı güncel tutar
Kaynak gösterme zorunluysa	Yok	Var (madde ve belge atfı)	Yok; ağırlıklar kaynağa referans vermez	RAG tarafından gelir
Gereken veri	Birkaç iyi örnek	İndekslenebilir belge derlemi + değerlendirme seti	En az yüzlerce, çoğunlukla binlerce etiketli örnek	İkisi birden
Bakım	Prompt sürümleri	Değişen belgeleri yeniden indekslemek	Temel model değişince yeniden eğitmek	İki akış, iki değerlendirme

RuneLab bu kararı veren ekipler için Prompting, RAG veya Fine-Tuning: LLM Uyarlama Karar Çerçevesi ve RAG eğitimi programlarını, kaynak gösteren kurumsal doküman asistanı arayan kurumlar için ise RuneDesk ürününü sunar.

Teorik karşılaştırma tabloları net görünse de gerçek projelerde ekipler genellikle aynı sistem içinde hem bilgi hem de davranış sorunlarıyla karşılaşır. Sahada tekrar eden dört kurumsal senaryo, hangi adımın ne zaman devreye alınması gerektiğini somutlaştırır.

Şirket içi yönetmelikler, tedarikçi sözleşmeleri ve İK prosedürleri yıl içinde sıkça güncellenir ve çalışanların yanıtta ilgili madde numarasını görmesi gerekir.

Bu senaryoda modeli şirket belgeleriyle fine-tune etmeye çalışmak hem güncel olmayan yanıtlara hem de kaynak gösterememe sorununa yol açar.

Doğru mimari, belge yetkilerini koruyan ve her yanıtı ilgili pasaja bağlayan bir RAG hattıyla başlamak, yalnızca üslup veya özet formatı tutarsız kalırsa sonradan hafif bir LoRA uyarlaması eklemektir.

Günde on binlerce müşteri mesajını departman, aciliyet ve konu başlığına göre JSON şemasına ayıran bir yönlendirme servisinde dış belge aramasına ihtiyaç yoktur.

Bu görevde uzun kuralları her seferinde büyük bir modele prompt olarak göndermek hem gecikmeyi hem de token maliyetini artırır.

Geçmişten doğrulanmış 1.000–2.000 etiketli örnekle fine-tune edilmiş küçük bir yerel model, aynı işi çok daha düşük gecikme ve sabit donanım maliyetiyle yürütür.

Kurumsal veritabanı şemaları yüzlerce tablo içerdiği için tüm şemayı tek bir prompt içine sığdırmak çoğu zaman mümkün olmaz; önce soruyla ilgili tabloları bulan bir retrieval katmanı gerekir.

Buna karşılık modelin Türkçe iş terimlerini hatasız SQL sözdizimine ve tarih filtrelerine dönüştürmesi bir davranış ve beceri problemidir.

En yüksek doğruluk, ilgili tablo tanımlarını RAG ile getirip sorguyu SQL için fine-tune edilmiş uzman bir modelle (Hati Glint SQL gibi) üretmekten gelir.

Bazen ekipler üretici LLM’in yanlış yanıt verdiğini düşünerek hemen fine-tuning planlar; oysa loglara bakıldığında doğru sözleşme maddesinin ilk 10 arama sonucunda hiç yer almadığı görülür.

Sorun üretici modelde değil, genel amaçlı embedding modelinin kuruma özgü Türkçe kısaltmaları ve ekleri eşleştirememesindedir.

Üretici modele dokunmadan önce hibrit arama (BM25 + vektör) kurmak ve reranker katmanını iyileştirmek çok daha hızlı ve kalıcı sonuç verir.

RAG modelin ağırlıklarını değiştirmez. Yanıt anında ilgili belgeleri bulur ve modele bağlam olarak verir, bu yüzden bilgi güncel kalır ve kaynak gösterilebilir. Fine-tuning ise modeli kendi örneklerinizle eğiterek ağırlıklarını değiştirir; biçim, üslup ve dar görev davranışını düzeltmek için uygundur. Kısaca, bilgi eksikse RAG, davranış eksikse fine-tuning kullanılır.

Her zaman değil. AWS Prescriptive Guidance, soru yanıtlamak için fine-tuned model kullanıldığında halüsinasyon riskinin artabileceğini yazıyor ve kendi belgelerinize dayanan soru-cevap sistemleri için RAG ile başlamayı öneriyor. Together AI de modele bilmediği bilgileri eğitimle öğretmenin halüsinasyon eğilimini artırabildiğini gösteren bir çalışmayı aktarıyor. Biçim ve görev hatalarını ise azaltabilir.

Together AI’ye göre en az yüzlerce yüksek kaliteli etiketli örnek, çoğunlukla binlerce örnek gerekir. Gereken sayı göreve, temel modele ve örneklerin kalitesine bağlıdır. Bu örnekleri güvenilir biçimde üretmenin bir yolu yoksa, fine-tuning yerine önce daha iyi bir prompt ve RAG denenmelidir. Kararı vermeden önce ayrı bir değerlendirme seti hazırlayın.

Evet. AWS, RAG mimarisini koruyup yanıtı üreten modeli ayrıca fine-tune etmenin mümkün olduğunu belirtiyor. RAFT yöntemi de modeli ilgili ve alakasız belgelerle birlikte eğiterek doğru belgeyi kullanmayı öğretiyor. Ancak hibrit yapı iki ayrı akış ve iki değerlendirme demektir, bu yüzden ikinci tekniği yalnızca ölçülmüş bir eksiklik için ekleyin.

Çoğu durumda RAG ile başlamak gerekir. Kurum belgeleri sık değişir, yanıtların kaynağı gösterilmelidir ve her çalışan yalnızca yetkili olduğu belgeleri görmelidir; AWS de belgelere atıf yapan soru-cevap sistemleri için RAG’i öneriyor. Fine-tuning sonradan biçim ya da üslup sorunları için eklenebilir. RuneLab’ın RuneDesk ürünü bu kategoride bir seçenektir.

Önce prompting, sonra bilgi eksikse RAG, ardından davranış eksikse fine-tuning. Together AI bu sırayı öneriyor, çünkü her adımın kurulumu ve denenmesi bir öncekinden daha pahalı. İlk günden 50 ile 200 örneklik bir değerlendirme seti kurun ve her adımı aynı setle karşılaştırın. Prompt-only sonucu da her zaman kontrol grubu olarak saklayın.