Kısa cevap: RAG optimizasyonu tek bir ayar değil, altı ayrı karardır — parçalama (chunk) stratejisi, embedding modeli seçimi, hibrit arama, yeniden sıralama (reranking), sorgu dönüştürme ve bağlam penceresi yönetimi. Naive RAG'den üretim kalitesine sıçrama, bu altı kararın birlikte doğru verilmesiyle olur; en pahalı LLM'i satın almakla değil. Çünkü RAG sisteminde cevabın kalitesi çoğu zaman modelin zekâsıyla değil, modele ne gösterdiğinizle sınırlıdır.
Konu 2026'da iki sebeple güncel. Birincisi, RAG kurumsal AI'ın varsayılan deseni oldu ve kurmak kolaylaştı — ama 'kurulu RAG' ile 'doğru cevap veren RAG' arasındaki makas açıldı; fark tam olarak bu yazıdaki kararlarda. İkincisi, yüzbinlerce token bağlam alabilen modeller 'retrieval'a gerek var mı' sorusunu meşru biçimde masaya getirdi — yazının sonunda bu soruya dürüst bir cevap vereceğiz.
Naive RAG Neden Tıkanır
Önce mekanizma: klasik RAG'de dokümanlar parçalara (chunk) bölünür, her parça embedding'e — metnin anlamını temsil eden sayı dizisine — çevrilir ve vektör veritabanına yazılır. Soru geldiğinde en benzer birkaç parça bulunur, modele bağlam olarak verilir, cevap üretilir. Bu düzen üç yerde tıkanır. (1) **Düşük isabet (precision):** anlamsal benzerlik her zaman ilgililik demek değildir; getirilen beş parçanın üçü konu dışı olabilir. (2) **Düşük kapsama (recall):** kritik bilgi yanlış parçaya bölünmüşse hiç getirilmez — sistem 'bilmiyorum' bile demez, eksik bağlamla yanlış cevap üretir. (3) **Maliyet:** her sorguda binlerce token bağlam taşımak, faturayı sorgu sayısıyla çarpar.
Karar 1: Parçalama (Chunk) Stratejisi
Üç yaklaşım var. **Sabit boyutlu parçalama:** her parça eşit uzunlukta, biraz örtüşmeli. En kolay kurulan, en düşük kaliteli seçenek — cümleleri ve fikirleri ortadan keser. **Anlamsal parçalama:** cümle ve paragraf bütünlüğü korunur; anlam bölünmediği için isabet belirgin iyileşir. **Doküman-yapısı parçalaması:** başlık hiyerarşisi (H1-H2-H3) takip edilir, her parçaya başlık zinciri ve sayfa bilgisi gibi metadata eklenir; üçünün en iyisidir çünkü parça, bağlamını yanında taşır. Sahada en sık gördüğümüz gerçek şu: en iyi model bile kötü parçalanmış veriyi kurtaramıyor — parçalamaya harcanan bir gün, model değişikliğinden daha çok kalite getiriyor. Pratik uygulama: PDF ve ofis dokümanlarını Unstructured.io veya LlamaParse gibi araçlarla yapısal olarak ayrıştırın — ham metin kazıma ile başlık yapısı kaybolur — ve metadata'yı parçayla birlikte saklayın; bu bilgiler sonraki adımlarda filtreleme ve yeniden sıralama için hammaddedir.
Karar 2: Embedding Modeli
Seçenekler iki kümede toplanır: kapalı API modelleri (OpenAI, Cohere, Voyage gibi sağlayıcılar) ve açık modeller (BGE, E5 aileleri ve çok dilli varyantları). Türkçe içerik için iki kural: birincisi, çok dilli eğitilmiş bir model şarttır — yalnız İngilizce'de güçlü bir model Türkçe eklerle boğulur. İkincisi, genel liderlik tabloları Türkçe kurumsal jargonu temsil etmez; kararı kendi dokümanlarınız ve gerçek kullanıcı sorularınızla kurduğunuz küçük bir kıyas testiyle verin. KVKK hassasiyeti yüksekse açık modeli kendi altyapınızda çalıştırmak, embedding aşamasında verinin dışarı çıkmasını tümüyle engeller — bu, mimari kararı tek başına belirleyebilen bir etkendir.
Karar 3: Hibrit Arama
Anlamsal (dense) arama tek başına yetmez, çünkü bazı sorgular anlamsal değildir: 'müşteri no 12845', ürün kodları, madde numaraları, özel isimler. Bu sorgularda klasik anahtar kelime araması (BM25) anlamsal aramayı açık farkla geçer. Hibrit arama ikisini birleştirir: iki yöntemin sonuçları Reciprocal Rank Fusion gibi bir yöntemle tek sıralamaya indirgenir. Qdrant, Weaviate ve Elasticsearch hibrit aramayı yerleşik destekler; Postgres+pgvector kullanıyorsanız birleştirmeyi kendiniz kurarsınız. Kurumsal dokümantasyonda kod, numara ve isim yoğunluğu yüksekse hibrit arama 'iyileştirme' değil ön şarttır.
Karar 4: Yeniden Sıralama (Reranking)
Mekanizma iki aşamalıdır: önce geniş bir aday kümesi getirin (örneğin en benzer 20 parça), sonra küçük ama isabetli bir reranker modeliyle — iki metnin gerçekten ilgili olup olmadığını değerlendiren özel model — en iyi 5'e indirin. İlk arama hızlı ama kabaca eler; reranker yavaş ama dikkatli okur. Sonuç çift kazançtır: modele giden bağlam hem daha ilgili (kalite artar) hem daha kısa (token maliyeti düşer) olur. Aynı hamlede hem kaliteyi hem maliyeti iyileştiren tek optimizasyon adımı budur; kurumsal RAG'de standart kabul edilmesinin sebebi de bu.
Karar 5: Sorgu Dönüştürme
Kullanıcının yazdığı ham soru, arama için her zaman en iyi sorgu değildir. Üç teknik: **HyDE** — modele 'bu sorunun cevabı nasıl bir metinde olurdu' diye varsayımsal cevap ürettirip aramayı o metinle yapmak; soru ile cevap metni anlamsal olarak birbirine dokümanlardan daha yakındır. **Sorgu genişletme** — eş anlamlılarla zenginleştirme; Türkçe'de kritik, çünkü aynı kavram dokümanlarda 'çalışan', 'personel' ve 'eleman' olarak geçebilir. **Çoklu sorgu** — tek sorudan birkaç farklı sorgu üretip paralel aramak ve sonuçları birleştirmek; kullanıcının kötü ifade ettiği soruları kurtarır. Bu teknikler ucuzdur ve retrieval'ın en zayıf halkasını — soruyla dokümanın dilinin uyuşmamasını — hedefler.
Karar 6: Bağlam Penceresi Yönetimi
Modele ne kadar bağlam vermeli? Az verirseniz bilgi eksik kalır; çok verirseniz 'ortada kaybolma' (lost in the middle) etkisine çarparsınız — modeller uzun bağlamın başını ve sonunu ortasından daha iyi hatırlar. Üstelik her gereksiz parça hem para hem dikkat maliyetidir. Pratik denge: yeniden sıralanmış az sayıda kaliteli parça, ham hâlde yığılmış çok parçadan neredeyse her zaman iyidir. Uzun bağlam gerektiren istisnai işlerde model seçimini kendi 'samanlıkta iğne' testinizle doğrulayın: uzun bir bağlamın ortasına bilinen bir bilgiyi gömün ve modelin bulup bulmadığını ölçün.
Uzun Bağlam Çağında RAG Hâlâ Gerekli mi?
Dürüst cevap: her zaman değil. Doküman kümeniz küçük ve durağansa — toplamda birkaç yüz sayfa, seyrek güncellenen — tüm içeriği doğrudan bağlama koymak meşru ve daha basit bir alternatiftir; retrieval altyapısının kendisi de bir bakım yüküdür. Ama üç koşuldan biri varsa RAG kalıcıdır: veri büyükse (bağlama sığmaz), sık değişiyorsa (her sorguda güncel hâli lazım) veya erişim yetkisi kullanıcıya göre filtrelenmeliyse (herkes her dokümanı görmemeli — retrieval katmanı aynı zamanda yetki katmanıdır). Ölçekte maliyet de RAG lehinedir: her sorguda tüm arşivin token bedelini ödemek, önbellekleme ile ucuzlasa da sıfırlanmaz.
Sahada işe yarayan ipuçları
**1.** Optimizasyona ölçümsüz başlamayın: 50-100 gerçek soru ve doğru cevaptan oluşan bir değerlendirme seti kurun, her değişikliği bu sete karşı ölçün — ölçüm seti olmayan RAG projesi pusulasız rota düzeltmesidir. **2.** Retrieval'ı LLM'den ayrı test edin: getirilen parçalar doğru mu, cevabı hiç ürettirmeden bakın — kötü cevabın suçlusu çoğu zaman model değil, ona gösterilen yanlış parçalardır. **3.** Cevaplara kaynak gösterme zorunluluğu koyun (hangi doküman, hangi bölüm) — hem halüsinasyon görünür olur hem kullanıcı güvenini doğru kalibre eder. **4.** Doküman güncellenince embedding'i güncelleyen otomasyonu ilk günden kurun; sahada en sık gördüğümüz sessiz arıza budur — sistem çalışır görünür ama üç ay önceki fiyat listesinden cevap verir, ve bayat index yanlış cevaptan tehlikelidir çünkü kimse fark etmez. **5.** Maliyeti uçtan uca izleyin: en büyük kalem neredeyse her zaman LLM üretim aşamasıdır, en etkili tasarruf reranking ile bağlamı küçültmektir; açık kaynak vektör veritabanını kendi altyapınızda çalıştırmak ikinci büyük kalemdir.
Sık yapılan hatalar
Dört hata tekrar ediyor. Birincisi, kaliteyi model değiştirerek kovalamak — sorun çoğunlukla retrieval'dayken daha pahalı LLM almak, semptomu ilaçlamaktır. İkincisi, parçalama kararını varsayılanda bırakıp altı ay sonra 'RAG çalışmıyor' demek. Üçüncüsü, hibrit aramayı atlayıp numara ve kod sorgularında sistemin neden kör olduğunu anlamamak. Dördüncüsü, araç modasına kapılmak: bu alandaki ürün isimleri hızla değişiyor; mimari kararlar (yapısal parçalama, hibrit arama, yeniden sıralama, değerlendirme seti) ise kalıcı. Araca değil karara yatırım yapın. Son bir hatırlatma: RAG'i optimize etmeden önce doğru soru, RAG'in bu iş için doğru araç olup olmadığıdır — bu kararın çerçevesi için [RAG vs Fine-Tuning](/kaynaklar/rag-vs-fine-tuning) yazımıza bakabilirsiniz; modele davranış öğretmeniz gerekiyorsa [Fine-Tuning Rehberi](/kaynaklar/fine-tuning-rehberi) devamı niteliğindedir.