LLM'leri kurumsal bilgilerle zenginleştirmenin iki ana yolu var: RAG ve Fine-Tuning. Her ikisinin de yeri var.
RAG (Retrieval Augmented Generation)
Model çağrılmadan önce, ilgili dokümanlar veritabanından çekilerek prompt'a eklenir.
Avantajları:
Dezavantajları:
Fine-Tuning
Model, domain verileri üzerinde ek eğitimden geçirilir.
Avantajları:
Dezavantajları:
Karar Matrisi
| Senaryo | Öneri |
|---------|-------|
| Sık güncellenen bilgi | RAG |
| Tutarlı çıktı formatı | Fine-Tuning |
| Hızlı başlangıç | RAG |
| Domain jargonu | Fine-Tuning |
| Kaynak gösterme önemli | RAG |
| Düşük latency kritik | Fine-Tuning |
Hibrit Yaklaşım
En iyi sonuçlar genellikle ikisinin kombinasyonuyla alınır:
1. Fine-tuned model (format, stil, terminoloji)
2. RAG ile güncel bilgi enjeksiyonu
Başlangıç için RAG deneyin. Yetersiz kalırsa fine-tuning ekleyin.
Üç Eksende Karar: Maliyet, Güncellik, Veri Gizliliği
Yukarıdaki matris "hangisi" sorusuna hızlı cevap verir; ancak kurumsal bir kararı sağlıklı vermek için üç ekseni ayrı ayrı tartmak gerekir. Çoğu ekip yalnızca ilk kurulum maliyetine bakar ve iki yıl sonra sürdürme maliyetinde sürprizle karşılaşır. Aşağıdaki üç başlık, kararı duyguyla değil ölçütle vermenizi sağlar.
**Maliyet ekseni.** RAG'in görünür maliyeti düşüktür (embedding üretimi + vektör veritabanı + retrieval), fakat her sorguda prompt'a eklenen bağlam token'ları çalışma maliyetini kalıcı olarak yükseltir; uzun dokümanlarla çalışan sistemlerde sorgu başı token tüketimi katlanabilir. Fine-tuning'de ise maliyet öne yığılır: veri hazırlama, etiketleme ve eğitim tek seferlik büyük kalemdir, buna karşılık çalışma anında daha kısa prompt kullandığınız için sorgu başı maliyet düşer. Kaba bir kural: düşük hacimli ama sık değişen bilgi için RAG, yüksek hacimli ve kararlı görevler için fine-tuning genellikle daha ekonomiktir. Bu hesabı lisans/eğitim fiyatıyla değil, Yazılım Koçu Üç-Boyutlu ROI Modeli (3DR) çerçevesinde üç yıllık toplam sahip olma maliyetiyle yapın.
**Güncellik ekseni.** RAG'in en güçlü olduğu yer burasıdır: bilgi değiştiğinde tek yapmanız gereken kaynak dokümanı veya veritabanı kaydını güncellemektir; model dokunulmadan kalır. Fiyat listesi, stok, mevzuat, ürün kataloğu gibi haftalık hatta günlük değişen bilgilerde fine-tuning pratik değildir — her değişiklik yeniden eğitim demektir. Fine-tuning, aylarca sabit kalan format, ton ve terminoloji için doğru araçtır. Bilginin "yarı ömrü" ne kadar kısaysa terazi o kadar RAG'e kayar.
**Veri gizliliği ekseni.** İki yaklaşım farklı riskler taşır. RAG'de hassas veri çalışma anında prompt'a girer; harici bir API kullanıyorsanız bu veri her sorguda dışarı çıkar. Fine-tuning'de ise hassas veri modelin ağırlıklarına gömülür ve dikkatli kurgulanmazsa çıktı sırasında geri sızabilir (data leakage). KVKK 6698 kapsamında çalışan Türkiye'deki işletmeler için pratik sonuç: kişisel veri içeren senaryolarda ya on-premise/özel bulut barındırma ya da retrieval katmanında maskeleme/anonimleştirme şarttır. Kararı KVKK Uyumlu AI Mimarisi rehberimizdeki veri minimizasyonu ilkesiyle birlikte alın.
Kurumsal Senaryolar: Terazi Nereye Kayar?
Soyut karşılaştırma yerine dört temsili senaryo, teraziyi somutlaştırır:
Karar Akışı: Dört Soruyla Netleşin
Pratikte kararı şu sıralı sorularla verin — ilk "evet" sizi yönlendirir:
1. **Bilgi ne sıklıkla değişiyor?** Haftalar içinde değişiyorsa → RAG.
2. **Cevabın kaynağını göstermeniz gerekiyor mu?** Evetse → RAG.
3. **Çıktının tonu/formatı/terminolojisi kritik ve kararlı mı?** Evetse → Fine-tuning ekleyin.
4. **Sorgu hacmi çok yüksek ve gecikme kritik mi?** Evetse → Fine-tuning'in düşük inference maliyeti öne çıkar.
Çoğu kurumsal projede birden fazla soruya "evet" gelir; bu da sizi doğal olarak baştan bahsettiğimiz hibrit mimariye götürür: fine-tuned taban model + RAG ile güncel bilgi.
Nereden Başlamalı?
Neredeyse tüm kurumsal senaryolarda doğru başlangıç RAG'dir: düşük risk, hızlı geri bildirim, ölçülebilir sonuç. Önce RAG ile bir pilot kurun, retrieval kalitesini ölçün (RAG Optimizasyonu yazımızdaki chunk stratejisi, reranking ve hybrid search kararları burada devreye girer). Yalnızca RAG'in çözemediği somut bir eksik — tutarsız format, öğrenilemeyen jargon veya kabul edilemez latency — ortaya çıktığında fine-tuning'i ekleyin. Bu "önce en ucuz ve en esnek olanı dene, kanıtla, sonra karmaşıklık ekle" yaklaşımı, Yazılım Koçu 4VS Yönteminin (Keşif → Strateji → Geliştirme → Optimizasyon) doğal bir uygulamasıdır. Hangi senaryonun sizin için doğru olduğundan emin değilseniz, bir dijital olgunluk değerlendirmesiyle başlayıp TBAM raporu üzerinden yol haritanızı netleştirebilirsiniz.