RAG mi Fine-Tuning mi? Kurumsal LLM Sistemlerinde Doğru Teknik Nasıl Seçilir?

RAG ve fine-tuning çoğu zaman aynı soruya iki rakip cevap gibi sunulur: şirket belgelerini modele mi verelim, yoksa modeli kendi verimizle mi eğitelim? Bu çerçeve eksiktir. RAG, yanıt anında hangi bilginin kullanılacağını değiştirir. Fine-tuning, modelin belirli bir göreve nasıl davranacağını değiştirir. İyi bir üretim sistemi çoğu zaman bunlardan birini değil; iş kuralı, RAG, fine-tuning ve insan kontrolünün nerede gerekli olduğunu seçer.

Bu yazı TankDev'in karar çerçevesidir: güncel sözleşme, fiyat, prosedür veya müşteri kaydı gerekiyorsa önce kaynağı getirin; sabit bir çıktı biçimi, sınıflandırma eşiği veya tekrar eden davranış problemi varsa fine-tuning'i deneysel olarak değerlendirin; kesin hesap, yetki ve geri döndürülemez işlem varsa LLM'i karar verici değil yardımcı bileşen yapın.

1. Önce problemi doğru ayırın: bilgi, davranış, kural

Bir kullanıcı “Bu müşteri için iade süresi nedir?” diye soruyorsa sorun güncel bilgiye ulaşmaktır. Politika yarın değişebilir; doğru yanıtın kanıtı ilgili politika sürümüdür. Bu RAG problemidir. “Gelen e-postayı altı operasyon sınıfından birine, yalnız geçerli JSON ile ayır” isteği ise tutarlı davranış ve çıktı sözleşmesidir; fine-tuning aday olabilir. “İade tutarı 5.000 TL'yi aşarsa ikinci onay gerekir” ise belirli bir iş kuralıdır; SQL, workflow veya kural motorunda uygulanmalıdır.

2. RAG nedir; ne değildir?

Retrieval-augmented generation, kullanıcının sorusuna göre yetkili kaynaklardan kanıt seçip bu kanıtı model bağlamına ekler. Temel hat; kaynağı alma, metni ve meta veriyi hazırlama, uygun parçaları getirme, yeniden sıralama, kaynaklı yanıt üretme ve gözlem kaydıdır. Vektör veritabanı bu hattın olası bir parçasıdır; RAG'ın eş anlamlısı değildir.

İyi RAG 'PDF'yi küçük parçalara bölmekle bitmez. Belgenin sürümü, geçerlilik tarihi, ürün kapsamı, dil, erişim kontrolü, başlık hiyerarşisi ve kaynak bağlantısı korunur. Arama hem anahtar kelime hem anlam araması kullanabilir; ardından bir reranker en uygun kanıtı daraltır. Modelin görevi, kanıta dayalı yanıt vermek veya kanıt yetersizse bunu açıkça söylemektir.

{
  "query": "2026 bayi sözleşmesinde iade süresi?",
  "actor_id": "dealer-42",
  "filters": {"locale": "tr", "valid_on": "2026-09-27"},
  "retrieved": [{"doc_id": "returns-2026-07", "revision": 7, "chunk_id": "4.2", "score": 0.91}],
  "answer_policy": "cite_or_abstain"
}

Bu örnekte actor_id yalnız log alanı değildir: getirme aşaması, kullanıcının erişemeyeceği müşteri veya sözleşme parçalarını filtrelemelidir. Sonradan prompt'a 'gizli bilgiyi söyleme' yazmak erişim kontrolü değildir. Ayrıca getirme sonucu boşsa modelin olası görünen bir yanıt yazması yerine insufficient_evidence durumuna geçmesi gerekir.

3. Fine-tuning neyi değiştirir?

Fine-tuning, seçilmiş girdi-çıktı örnekleri üzerinden temel modelin davranışını belirli bir göreve yaklaştırır. Sınıflandırma etiketleri, yapılandırılmış çıktı biçimi, alan dili, kısa yanıt tarzı veya tercih edilen araç seçimi buna örnek olabilir. Bir sağlayıcının fine-tuning işi için eğitim verisini ayrı biçimde yüklemesi ve eğitim işini başlatması gerekir; örneğin OpenAI API bu veri için JSONL biçimini tanımlar. OpenAI fine-tuning referansı bu operasyonel ayrımı açıklar.

Fine-tuning, eğitim örneklerindeki gerçekleri güvenilir bir doküman deposu gibi saklamaz. Eğitim verisindeki fiyat veya politika değiştiğinde hangi yanıtların etkilendiğini tek tek bulmak zordur. Model, örneği ezberlemiş gibi görünse de bu alıntılanabilir, güncel veya yetkiye bağlı bir kaynak değildir. Bu yüzden bilgi tabanı sorularında fine-tuned modelin yanında RAG gerekebilir.

• Eğitim örneği ideal iş sonucunu ve izinli çıktı sözleşmesini temsil eder.
• Validation seti prompt, hiperparametre veya karar eşiği seçerken kullanılır.
• Test seti son karşılaştırmaya kadar dokunulmaz; aynı müşteri, şablon veya belge ailesi setler arasında sızmamalıdır.
• Model sürümü, veri sürümü, istem sürümü ve değerlendirme sonucu aynı yayın kaydında tutulur.

4. Somut örnek: bayi destek asistanı

Bir B2B destek asistanı aynı anda üç görev yapabilir. Kullanıcı güncel iade şartını sorar; sistem yetkili sözleşme sürümünü RAG ile getirir ve madde bağlantısını gösterir. Kullanıcı serbest metinli talep bırakır; model bu talebi returns, pricing, delivery, account, technical, other sınıflarından birine ayırır. Sonra iade oluşturma aracını çağırmadan önce müşteri, sipariş, süre ve yetki kontrolü deterministik servis tarafından yapılır.

Sınıflandırma görevi için baseline prompt ile 600 etiketli örneği ayrı testte karşılaştırın. Eğer hata çoğunlukla değişken politika bilgisinden kaynaklanıyorsa fine-tuning yanlış yatırımdır; getirme, filtre veya kaynak kalitesi düzeltilmelidir. Hata, her kanıt hazır olsa bile sınıf biçimi veya alan dili tutarsızlığıysa fine-tuning deneyinin anlamı vardır. Bu ayrım, maliyetli 'önce modeli eğitelim' refleksini engeller.

5. RAG kalitesini nasıl ölçersiniz?

Yanıt iyi görünüyorsa sistemin iyi olduğunu varsaymak yanıltıcıdır. RAG değerlendirmesi en az iki katmana ayrılır: retrieval doğru kanıtı getirdi mi; generation yalnız bu kanıttan doğru ve yeterli yanıt üretti mi? Yanlış belge doğru dille özetlenebilir. Doğru belge getirildiği halde model yanlış maddeye dayanabilir. Bu iki hata farklı ekipler ve farklı iyileştirmeler gerektirir.

Değerlendirme setinde kolay SSS'lerin yanında isim benzerliği, eski sürüm, çok belgeli cevap, erişim sınırı, OCR hatası, boş sonuç ve çelişkili kaynak bulunmalıdır. Google Cloud'un RAG açıklaması da retrieval kalitesinin merkezi olduğunu ve alakasız getirmenin yanıtı yanlış veya konu dışı yapabileceğini vurgular. Google Cloud RAG rehberi

6. Fine-tuning kararını değerlendirme ile verin

Fine-tuning bir dağıtım kararı değil, deneydir. Önce hedefi ölçülebilir yazın: 'JSON şeması geçerli olsun' veya 'öncelik sınıfı uzman değerlendirmesinde en az yüzde X doğrulukta olsun.' Aynı test setinde temel model + iyi sistem prompt'u, temel model + RAG ve fine-tuned sürümü kör değerlendirmeyle karşılaştırın. Bir yaklaşımın daha karmaşık olması onu daha doğru yapmaz.

Hata örneklerini sınıflandırın: yanlış bilgi, yanlış retrieval, şema hatası, yanlış araç seçimi, eksik bağlam, güvenlik ihlali veya değerlendirme belirsizliği. Eğitim verisine her hatayı eklemek veri kalitesini bozabilir. Fine-tuning için örnekler ideal davranışı temsil etmeli; kişisel veri, erişim anahtarı, çelişkili eski kural ve kontrol edilmemiş model çıktısı eğitim dosyasına girmemelidir.

7. Maliyet ve gecikme: iki farklı muhasebe

RAG'de maliyet, belge hazırlama ve indeksleme ile sorgu anındaki embedding, arama, rerank, bağlam token'ı ve üretimden oluşur. Belge değiştiğinde yalnız etkilenen parçaları yeniden işlemek mümkündür. Fine-tuning'de veri hazırlama, eğitim işi, değerlendirme ve özel modelin her çağrısındaki maliyet izlenir. Ancak gerçek maliyet, model faturası değil; yanlış yanıtın düzeltmesi, operasyon gecikmesi ve insan incelemesidir.

8. Güvenlik, erişim ve veri yaşam döngüsü

RAG sistemi belgeyi bağlama almadan önce tenant, rol, kayıt seviyesi, sözleşme kapsamı ve geçerlilik tarihi filtrelerini uygular. Kaynak parçaları, yanıt ve kullanıcı kimliği gözlem kaydında tutulurken kişisel veri minimizasyonu yapılmalıdır. Silinen veya yetkisi kaldırılan belge indeks ve önbellekten de kaldırılmalıdır.

Fine-tuning verisi için ayrıca eğitim sağlayıcısının veri saklama, kullanım ve silme kuralları incelenmelidir. Veri yönetişimi, 'fine-tuning' etiketiyle çözülmez. Hangi veri sınıfının sağlayıcıya gönderilebileceği, ne kadar saklanacağı ve model sürümünün nasıl devreden çıkarılacağı yazılı olmalıdır.

9. Hibrit mimari çoğu zaman doğru sonuçtur

Olgun sistemlerde RAG ve fine-tuning birlikte kullanılabilir: fine-tuned veya iyi prompt'lanmış model, sorguyu yapılandırır ve yanıt biçimini sabitler; RAG güncel ve yetkili kanıtı getirir; kural motoru yetki, hesap ve yan etkiyi doğrular; human-in-the-loop belirsiz veya yüksek riskli durumları kapatır. Bu, 'her şeyi modele öğretme' yerine her bileşene doğru sorumluluğu verme yaklaşımıdır.

request → authorization → query rewrite → retrieval + ACL filter → rerank
       → evidence check → LLM response → schema validation
       → deterministic business rule → action | review queue
       → audit log + evaluation event

10. Uygulanabilir karar sırası

• Başarı sözleşmesini yazın: doğru kaynak, gerekli alanlar, yan etki ve zaman sınırı nedir?
• Basit baseline kurun: iyi prompt, şema doğrulaması, kural kontrolü ve ölçülmüş örnek seti.
• Bilgi değişiyorsa sürümlü kaynak ve RAG ile başlayın; retrieval sonuçlarını ayrı ölçün.
• Davranış problemi tekrar ediyorsa fine-tuning hipotezini sabit test setiyle deneyin.
• Yüksek riskli kararı deterministik servis veya insan onayı olmadan gerçekleştirmeyin.
• Sürüm, maliyet, hatalı kabul, kaynak kanıtı ve geri dönüş planını üretimde izleyin.

TankDev için doğru soru “RAG mi fine-tuning mi?” değildir. Doğru soru, hangi iş sonucunun güncel kanıta, hangi davranışın eğitim örneklerine, hangi kararın kesin kurallara ve hangi istisnanın insan sorumluluğuna ihtiyaç duyduğudur. AI otomasyon mimarisi rehberimiz bu bileşenlerin API, kuyruk, doğrulama ve izlemeyle nasıl birleştiğini açıklar.