RAG'de Reranking ve Hibrit Arama: Cross-Encoder ile Üretim Kalitesi (2026)

TL;DR — RAG projelerinde kalitenin büyük kısmı üretim (generation) aşamasında değil, geri getirme (retrieval) aşamasında kaybolur. Sahada gördüğüm gerçek şu: modeli değiştirmeden önce aramayı düzeltin. Doğru reçete iki aşamalı bir mimari — önce hızlı bir bi-encoder ile BM25 + dense (yoğun) aramayı birleştirip Reciprocal Rank Fusion (RRF) ile ~100 aday çıkarın, sonra bir cross-encoder reranker ile bunları en iyi 10'a indirin. Türkçe için bu, tercih değil neredeyse zorunluluk: dilimiz eklemeli (agglutinative) olduğu için BM25 bir güvenlik ağı gibi çalışır, cross-encoder ise anlamı yakalar. KVKK dünyasında ise reranker seçimi bir veri egemenliği kararıdır: BGE gibi açık kaynak, kendi sunucunuzda çalışan modeller mi, yoksa verinin ortamdan çıktığı yönetilen API'ler mi? Bu yazıda sahadan örneklerle bütün boru hattını (pipeline) tek tek açıyorum.

Kurumsal RAG projelerinde en sık duyduğum cümle şu: "Modeli GPT'nin son sürümüne çektik ama cevaplar hâlâ tatmin etmiyor." Ardından uzun bir tartışma başlar — belki prompt'u değiştirmeliyiz, belki daha büyük bir bağlam penceresi (context window) alan bir modele geçmeliyiz, belki fine-tuning yapmalıyız.

Sahada onlarca RAG sistemi kurduktan ve daha fazlasını denetledikten sonra size çok net bir şey söyleyebilirim: sorunların büyük çoğunluğu üretim modelinde değil, geri getirme katmanında. Yani model kötü cevap veriyorsa, çoğu zaman ona verdiğiniz belge parçaları (chunk'lar) baştan yanlış. Modele çöp verirseniz, dünyanın en iyi modeli bile size cilalı bir çöp döndürür.

Bunu bir benzetmeyle anlatayım. Diyelim ki çok yetenekli bir avukatınız var ama ona davayla ilgili yanlış dosyaları veriyorsunuz. Avukat ne kadar zeki olursa olsun, elindeki belgeler alakasızsa savunması da alakasız olacaktır. RAG'da üretim modeli o avukattır; retrieval katmanı ise ona hangi dosyaların gittiğini belirleyen asistandır. Biz genelde avukatı değiştirmeye çalışıyoruz, oysa asistanı düzeltmemiz gerekiyor.

Bu yazının ana tezi tam olarak bu: RAG kalitesinin çoğu, retrieval aşamasında kazanılır ya da kaybedilir. Ve retrieval'i düzeltmenin en etkili, en somut yolu iki aşamalı bir arama mimarisi kurmaktır. Gelin bunu adım adım açalım.

Klasik RAG mimarisinde tek bir aşama vardır: sorguyu bir embedding modeline verirsiniz, vektör veritabanında en yakın komşuları ararsınız, ilk k parçayı alırsınız, modele verirsiniz. Buna "bi-encoder ile arama" diyoruz.

Bi-encoder ne yapar? Sorguyu ve belgeleri ayrı ayrı vektöre çevirir. Belgeleri önceden vektörleştirip veritabanına koyar, sorgu geldiğinde sadece sorguyu vektörleştirip benzerlik hesaplar. Bu çok hızlıdır çünkü belgeler önceden hesaplanmıştır. Milyonlarca belge arasında milisaniyeler içinde arama yapabilirsiniz.

Ama bu hızın bir bedeli var. Bi-encoder sorgu ile belgeyi hiç yan yana görmez. Her ikisini de kendi başına, diğerinden habersiz vektörleştirir. Bu yüzden ince anlam farklarını, sorgu ile belge arasındaki gerçek etkileşimi yakalayamaz. "Kredi kartı borcunun yapılandırılması" ile "kredi kartı başvurusunun reddi" bi-encoder'ın gözünde tehlikeli derecede benzer görünebilir çünkü kelimeler örtüşüyor ama niyet tamamen farklı.

İşte burada cross-encoder devreye giriyor. Cross-encoder sorgu ile belgeyi birlikte, aynı anda işler. İkisini tek bir girdi olarak modele verir ve model kelimelerin birbiriyle nasıl etkileştiğini görerek çok daha nüanslı bir alaka skoru üretir. Sonuç: çok daha isabetli bir sıralama.

Peki neden her şeyi cross-encoder ile yapmıyoruz? Çünkü çok pahalı. Cross-encoder her sorgu-belge çifti için ayrı bir hesaplama gerektirir. Bir milyon belgeniz varsa, her sorguda bir milyon çift işlemeniz gerekir — bu imkansız derecede yavaştır. Bu yüzden akıllı çözüm ikisini birleştirmektir:

1. Birinci aşama (retrieve): Hızlı bi-encoder ve BM25 ile milyonlarca belge arasından hızlıca ~100 aday çıkar.
2. İkinci aşama (rerank): Yavaş ama isabetli cross-encoder ile sadece o 100 adayı yeniden sırala, en iyi 10'u seç.

Benchmark'lar bu yaklaşımı net biçimde destekliyor: iki aşamalı retrieval (bi-encoder ile getir + cross-encoder ile yeniden sırala), tek aşamalı saf vektör aramasını çeşitli test setlerinde belirgin biçimde geçiyor. Özellikle karmaşık sorgular reranking'den daha çok fayda görüyor — basit bir anahtar kelime aramasında fark küçük olabilir ama çok kriterli, uzun, muğlak sorularda reranking cevabı kurtarıyor.

Şimdi birinci aşamayı derinleştirelim çünkü çoğu ekip burada eksik yapıyor. Birçok RAG sistemi sadece dense (vektör) aramaya güvenir. Ama saf vektör araması iki durumda zayıftır:

• Nadir, spesifik terimler: Ürün kodları, kanun madde numaraları, özel isimler, kısaltmalar. "KVKK 6698 sayılı kanun madde 11" gibi bir sorguda vektör araması genel anlamı yakalar ama tam terim eşleşmesini kaçırabilir.
• Tam ifade eşleşmesi gereken durumlar: Kullanıcı belirli bir cümleyi ya da kodu arıyorsa, semantik benzerlik yeterli değildir.

Burada eski ama güçlü bir dost devreye giriyor: BM25. BM25 klasik bir anahtar kelime (lexical) arama algoritmasıdır. Kelimelerin tam eşleşmesine bakar, nadir kelimelere daha çok ağırlık verir. Vektör aramanın kaçırdığı tam terim eşleşmelerini yakalar. Dense arama "anlamı", BM25 "kelimeyi" yakalar. İkisi birbirini tamamlar.

Önerdiğim ve sahada uyguladığım desen şu:

• BM25 ile ilk 50 belge
• Dense (vektör) arama ile ilk 50 belge
• Bu ikisini Reciprocal Rank Fusion (RRF) ile birleştirip ~100 adaya indir
• Cross-encoder reranker ile bu 100 adayı en iyi 10'a düşür

RRF Neden Bu Kadar İşe Yarıyor?

Reciprocal Rank Fusion, iki farklı sıralama listesini birleştirmenin şaşırtıcı derecede basit ve dayanıklı bir yoludur. Mantığı şu: her belge için, her listedeki sırasına bakılır ve 1 / (k + sıra) formülüyle bir skor verilir (k genelde 60 alınır). Belgenin iki listedeki skorları toplanır. Böylece hem BM25'te hem dense'te üst sıralarda çıkan belgeler doğal olarak en yükseğe tırmanır.

RRF'nin güzelliği, iki sistemin skorlarını normalize etmeye çalışmamasıdır. BM25 skoru ile kosinüs benzerliği skoru tamamen farklı ölçeklerdedir — birini diğerine çevirmek baş ağrıtıcıdır. RRF bu sorunu tamamen atlar; sadece sıralamalara bakar, ham skorlara değil. Bu yüzden pratikte çok sağlam çalışır ve ayar gerektirmez.

Yaklaşım	Güçlü Yanı	Zayıf Yanı	Ne Zaman Kullanılır
Sadece BM25	Tam terim, nadir kelime, kod eşleşmesi	Eş anlamlıları, anlamı kaçırır	Yasal metin, ürün kodu ağırlıklı aramalar
Sadece Dense	Anlam, eş anlamlı, parafraz	Nadir terim, tam eşleşme zayıf	Doğal dil, kavramsal sorular
Hibrit (RRF)	İkisinin de gücü	Biraz daha karmaşık altyapı	Neredeyse her ciddi RAG sistemi
Hibrit + Rerank	En yüksek isabet	Ek gecikme ve maliyet	Kalitenin kritik olduğu üretim sistemleri

Şimdi bu yazının Türkiye'de çalışan herkes için en kritik kısmına geliyoruz. Türkçe eklemeli (agglutinative) bir dildir. Bir kök kelimeye üst üste ekler yığarak yeni anlamlar üretiriz. "Ev" kelimesinden "evlerimizdekilerden" gibi tek bir kelime türetebiliriz ve bu, İngilizce'de koca bir cümleye karşılık gelir.

Bu morfolojik zenginlik, tam terim eşleşmesini (lexical matching) ciddi biçimde zorlaştırır. "Sözleşme" arayan bir kullanıcı, belgede "sözleşmenin", "sözleşmeye", "sözleşmelerdeki" gibi çekimli hâllerle karşılaşır. Naif bir BM25, bu çekimleri farklı kelimeler sanabilir ve eşleşmeyi kaçırabilir. Bu yüzden Türkçe'de BM25'i doğru kurmak — kök bulma (stemming), Türkçe'ye uygun analizör, ekleri normalize eden bir tokenizer — çok önemlidir.

Buradan çıkan pratik sonuç net: Türkçe için hibrit arama tercih değil, neredeyse zorunluluktur. Dense arama Türkçe'de morfolojik varyasyonlara daha dayanıklıdır çünkü anlamı yakalar; ama nadir terimlerde ve tam eşleşmede zayıflar. BM25 ise güvenlik ağı görevi görür ama Türkçe morfolojisi için özenle ayarlanmalıdır. İkisini birleştirdiğinizde Türkçe'de gerçekten iş gören bir arama elde edersiniz.

Bir uyarı daha, ve bunu kalın harflerle söylüyorum: Reranker'ları mutlaka bir Türkçe test seti üzerinde değerlendirin. İngilizce benchmark'larda parlayan bir reranker, Türkçe'de hayal kırıklığı yaratabilir. Model, çekimli Türkçe cümleleri ne kadar iyi anlıyor? Deyimleri, resmî dili, sektör jargonunu (bankacılık, sağlık, hukuk) yakalıyor mu? Bunu ancak kendi Türkçe verinizle test ederek anlarsınız. Başkasının İngilizce lider tablosuna güvenmeyin.

Sahada en çok karşılaştığım üç reranker ailesi var ve seçim genelde teknik kaliteden çok veri egemenliği ile ilgili oluyor. Özellikle KVKK kapsamındaki müşterilerimde bu karar en başta netleşmeli.

• BGE (BAAI): Açık kaynak ve kendi sunucunuzda barındırılabilir (self-hostable). KVKK ve veri egemenliği açısından en güvenli seçenek. Veri hiçbir zaman ortamınızdan çıkmaz. Bankacılık, sağlık, kamu gibi verinin yurt dışına ya da üçüncü taraf API'ye gidemeyeceği sektörlerde ilk bakacağınız aile budur. Kalite/maliyet dengesi de çok iyidir.
• Jina: Çok dilli (multilingual) desteğiyle öne çıkar. Türkçe için mutlaka test edilmeye değer, çünkü çok dilli eğitilmiş modeller Türkçe morfolojisini bazen sürpriz derecede iyi yakalar. Kendi Türkçe test setinizde deneyin, karar verin.
• Cohere Rerank: Yönetilen (managed) bir API olarak sunulur. Kurulum kolaydır, kalitesi yüksektir, ama veri ortamınızdan çıkar. Bu, KVKK açısından ciddi bir değerlendirme gerektirir. Verinin işleneceği yer, aktarım güvenliği, sözleşmesel güvenceler — hepsi masaya yatırılmalı. Halka açık ya da hassas olmayan verilerde pratik bir tercih olabilir; ama kişisel veri ya da özel nitelikli kişisel veri söz konusuysa iki kez düşünün.

"

Sahadan bir kural: Müşteriye reranker önermeden önce sorduğum ilk soru teknik değildir. "Bu veri ortamdan çıkabilir mi?" diye sorarım. Cevap "hayır" ise, tartışma açık kaynak ve self-hosting üzerinden yürür. Cevap "evet, sorun yok" ise, yönetilen API'ler de masaya gelir. Mimari kararı hukuk belirler, sonra teknik gelir.

Kalite tarafında beklenti şu: iyi kurulmuş bir cross-encoder reranking, MTEB/BEIR gibi benchmark'larda tipik olarak NDCG@10 metriğinde +5 ile +15 puan arası bir iyileşme getirir. Bu küçük bir rakam değil — sıralamanın tepesindeki belgelerin ne kadar isabetli olduğunu doğrudan gösterir ve bu da üretim modeline giden bağlamın kalitesini doğrudan belirler.

Şimdi çoğu ekibin atladığı, ama benim "görünmez temel" dediğim konuya geliyoruz: chunking, yani belgeleri parçalara ayırma stratejisi. Reranker'ınız dünyanın en iyisi olabilir ama parçalarınız kötüyse, iyi bir parçayı asla sıralayamaz çünkü baştan yoktur.

Chunking'de sahada uyguladığım prensipler şunlar:

• Yapısal chunking (structural): Belgeyi rastgele karakter sayısına göre değil, doğal yapısına göre bölün — başlıklar, paragraflar, bölümler. Bir cümlenin ortasından ya da bir tablonun yarısından kesmeyin. Yapıya saygı gösteren chunk'lar, anlamı koruyan chunk'lardır.
• Örtüşen (overlapping) chunk'lar: Parçalar arasında bir miktar örtüşme bırakın. Böylece bir cümlenin başı bir chunk'ta, sonu diğerindeyse, bağlam kopmaz. Sınırda kaybolan bilgi RAG'ın sessiz katilidir.
• Bağlamsal chunking (contextual): Her chunk'ın başına, o parçanın nereden geldiğini belirten bir önek ekleyin — kaynak belge adı, bölüm başlığı, tarih. Böylece "madde 11'e göre..." diyen bir chunk, hangi kanunun madde 11'i olduğunu kendi içinde taşır. Bu, hem retrieval'i hem reranking'i belirgin biçimde güçlendirir.

Bir örnekle netleştireyim. Diyelim bir bankanın kredi yönetmeliğini parçalıyorsunuz. Naif yaklaşım: her 500 karakterde bir kes. Sonuç: "...faiz oranı yıllık" diye biten bir chunk ve "%2,5 olarak uygulanır..." diye başlayan başka bir chunk. İkisi de tek başına anlamsız. Yapısal + örtüşen + bağlamsal yaklaşımda ise: "[Kredi Yönetmeliği > Bölüm 3: Faiz] İhtiyaç kredilerinde faiz oranı yıllık %2,5 olarak uygulanır." Tek chunk, tam anlamlı, kaynağı belli. Reranker bunu sevgiyle sıralar.

Birinci aşamanın kalbi embedding modelidir. Seçimi üç eksende düşünün:

1. Boyut (dimension) vs maliyet: Daha yüksek boyutlu embedding'ler teorik olarak daha çok bilgi taşır ama depolama ve hesaplama maliyeti artar, arama yavaşlar. Sahada gördüğüm tatlı nokta 768-1024 boyut aralığı. Bunun üstüne çıkmak çoğu kurumsal senaryoda maliyeti haklı çıkarmaz.
2. Türkçe / çok dilli destek: Model Türkçe'yi ne kadar iyi biliyor? Sadece İngilizce'de eğitilmiş bir embedding modeli Türkçe'de zayıf kalır. Çok dilli ya da Türkçe'ye özel eğitilmiş modelleri tercih edin ve — yine — kendi Türkçe verinizle test edin.
3. Veri egemenliği: Bankacılık, sağlık, kamu gibi alanlarda embedding modelini de self-hosted, açık kaynak seçmeniz gerekebilir. Verinin embedding API'sine gitmesi bile KVKK açısından bir aktarımdır ve değerlendirilmelidir.

Bu üç eksen sık sık çatışır. En yüksek boyutlu, en kaliteli model bir yönetilen API'de olabilir ama veriniz ortamdan çıkamıyorsa o modeli kullanamazsınız. O zaman self-hosted, biraz daha düşük boyutlu ama egemenlik açısından güvenli bir modele razı olursunuz. Bu bir mühendislik değil, bir hukuk-mühendislik dengesi kararıdır.

Şimdi en çok ihmal edilen ama en çok değer üreten konuya geliyoruz: ölçüm. "Cevaplar daha iyi görünüyor" bir metrik değildir. RAG'ın her katmanını ayrı ayrı ölçmeniz gerekir, çünkü sorunun hangi katmandan geldiğini ancak böyle anlarsınız.

Katman katman metrikler:

• Retrieval katmanı — recall@k: Doğru cevabı içeren belge, ilk k aday içinde geldi mi? Recall düşükse, sorun reranker'da değil, birinci aşamada. Reranker olmayan bir belgeyi sıralayamaz.
• Reranking katmanı — NDCG@10 ve MRR: İlk 10 sonuç ne kadar iyi sıralandı? NDCG@10 sıralamanın kalitesini, MRR (Mean Reciprocal Rank) ilk doğru cevabın ne kadar üstte olduğunu ölçer.
• Generation katmanı — faithfulness ve answer relevancy: Model, verilen bağlama sadık mı kaldı yoksa uydurma mı yaptı (faithfulness)? Cevap gerçekten soruya cevap veriyor mu (answer relevancy)?

Bütün bunların çalışması için tek bir şeye ihtiyacınız var: 50-100 sorudan oluşan bir golden test seti. Kendi alanınızdan, gerçek kullanıcı sorularını yansıtan, doğru cevabı ve doğru kaynak belgeyi elle işaretlenmiş sorular. Bu test seti olmadan her değişiklik bir tahmindir. Bu test setiyle her değişiklik bir ölçümdür.

"

Müşterilerime hep şunu söylüyorum: RAG projesine golden test seti kurmadan başlamak, pusulasız denize açılmaktır. İlk hafta 50 soru hazırlamak sıkıcı gelir, ama sonraki üç ay boyunca "acaba düzeldi mi?" belirsizliğinden sizi kurtarır.

Golden test setini nasıl kurarsınız? Gerçek kullanıcı loglarından başlayın. Sık sorulan soruları toplayın. Zor, muğlak, çok kriterli soruları özellikle dahil edin — çünkü sistem tam da orada çöker. Her soru için doğru cevabı ve o cevabın geçtiği kaynak belgeyi işaretleyin. Bu emek yoğun bir iştir ama RAG projenizin en değerli varlığıdır.

2026'da modellerin bağlam pencereleri devasa boyutlara ulaştı. Bazı ekipler bundan yanlış bir sonuç çıkarıyor: "Madem bu kadar çok belge sığdırabiliyorum, retrieval'e neden uğraşayım? İlgili olabilecek her şeyi modele tıkıştırırım, o halleder."

Bu, sahada gördüğüm en pahalı yanılgılardan biri. Modele körü körüne belge yığmak (blind stuffing) birkaç açıdan zararlıdır:

• Maliyet ve gecikme: Her token para ve zamandır. Gereksiz belgeler faturayı şişirir ve cevabı yavaşlatır.
• Dikkat dağılması: Model, alakasız belgeler arasında gerçekten önemli olanı gözden kaçırabilir. Bağlam ne kadar dolarsa, sinyal-gürültü oranı o kadar düşer.
• "Ortada kaybolma" etkisi: Uzun bağlamlarda modeller ortadaki bilgiyi başa ve sona göre daha zor hatırlar.

Bunun yerine bağlam budama (context pruning) ve bilgi kazancı (information gain) yaklaşımını benimseyin: modele sadece gerçekten işine yarayacak, yüksek alakalı parçaları verin. Akıllı retrieval, kör doldurmayı her zaman yener. Reranker'ın en iyi 10'u zaten bunu yapmanın yolu — 100 adaydan gerçekten değerli olanları süzüp modele temiz bir masa sunmak.

Kısaca: uzun bağlam penceresi bir lüks, bir güvenlik marjıdır — kötü retrieval'i örtbas etmek için bir bahane değil.

RAG sistemleri genelde tek soru üzerinde iyi çalışır ama gerçek kullanıcılar sohbet eder. İkinci, üçüncü soru genelde muğlaktır ve önceki bağlama yaslanır:

• Kullanıcı: "KVKK'da veri sorumlusunun yükümlülükleri neler?"
• Kullanıcı: "Peki ihlal olursa?"

İkinci soru tek başına anlamsızdır. "Peki ihlal olursa?" cümlesini olduğu gibi retrieval'e verirseniz, sistem neyin ihlalinden bahsettiğinizi bilemez. İşte burada sorgu yeniden yazma (query rewriting) devreye girer. Retrieval'den önce, muğlak takip sorularını bağımsız (standalone) sorgulara çevirirsiniz:

• "Peki ihlal olursa?" → "KVKK'da veri sorumlusunun kişisel veri ihlali durumundaki yükümlülükleri nelerdir?"

Bu yeniden yazılmış, kendi kendine yeten sorgu retrieval'e gider ve çok daha isabetli belgeler getirir. Küçük bir adım gibi görünür ama çok turlu diyaloglarda RAG kalitesini uçurumdan kurtaran şey tam olarak budur. Sahada çok turlu sohbet destekleyen her sistemde query rewriting'i standart bir katman olarak koyuyorum.

Son olarak, olgun bir RAG sisteminin sırrına geliyoruz: kademeli (cascading) mimari. Her soru aynı ağır işlemeyi hak etmez. Basit bir soruya tam boru hattını çalıştırmak para ve zaman israfıdır.

Mantık şu:

• Basit sorgular: Sadece hibrit arama (BM25 + dense + RRF) yeterli. Reranking'e gerek yok. Hızlı ve ucuz cevap.
• Karmaşık sorgular: Tam boru hattı — hibrit arama + cross-encoder reranking + gerekiyorsa query rewriting. Yavaş ama isabetli.

Sorgunun karmaşıklığını hafif bir sınıflandırıcı ya da basit sezgisel kurallarla (uzunluk, birden fazla kriter içeriyor mu, muğlak mı) belirleyebilirsiniz. Basit olanları hızlı yoldan geçirir, zorları ağır yola yönlendirirsiniz.

Kademeli mimarinin yanına iki performans pratiği daha ekleyin:

• Embedding ve sık sonuçları önbelleğe alın (cache): Aynı ya da benzer sorgular tekrar tekrar gelir. Embedding hesabını ve sık sonuçları önbellekte tutmak maliyeti ve gecikmeyi ciddi biçimde düşürür.
• Her zaman kaynak gösterin (citations): Modelin verdiği cevabın hangi belgeye dayandığını mutlaka gösterin. Bu hem güveni artırır hem de KVKK dünyasında denetlenebilirlik (auditability) açısından çoğu zaman zorunludur. Kullanıcı "bu bilgi nereden geldi?" diye sorabilmeli, siz de gösterebilmelisiniz.

Bütün bunları bir araya getirdiğimizde ortaya çıkan resim şu: RAG bir "model seçme" problemi değil, bir retrieval mühendisliği problemidir. Chunking'i doğru yapın, hibrit arama kurun, RRF ile birleştirin, cross-encoder ile yeniden sıralayın, her katmanı golden test setiyle ölçün, Türkçe'ye ve KVKK'ya özel kararları en baştan verin. Modeli en son değiştirin — çünkü büyük ihtimalle sorun orada değildi.

Yazıyı bir öğütle değil, bir sıralı eylem listesiyle bitirelim. Yarın sabah RAG sisteminize dönerseniz, sırasıyla şunları yapın:

1. Golden test setini kurun. 50-100 gerçek soru, doğru cevap, doğru kaynak. Her şeyden önce bu.
2. Mevcut retrieval'in recall@k'sını ölçün. Düşükse, sorun büyük ihtimalle chunking ve birinci aşamada; reranker eklemeden önce burayı düzeltin.
3. Chunking'i yapısal + örtüşen + bağlamsal hâle getirin. Görünmez temeli sağlamlaştırın.
4. Hibrit aramaya geçin. BM25 (Türkçe'ye ayarlı) + dense, RRF ile birleştirin. Türkçe için bu neredeyse zorunlu.
5. Cross-encoder reranker ekleyin. BGE / Jina / Cohere arasından, önce veri egemenliği kararınıza göre eleyin, sonra kendi Türkçe test setinizde ölçün.
6. Query rewriting ekleyin (çok turlu diyalog varsa).
7. Kademeli mimariye geçin ve önbellek kurun. Basit sorulara hafif yol, zor sorulara ağır yol.
8. Her zaman kaynak gösterin. Güven ve KVKK denetlenebilirliği için.

Bu sırayla ilerlerseniz, her adımda golden test setiniz size ne kadar ilerlediğinizi rakamla söyleyecek. Ve büyük ihtimalle şunu fark edeceksiniz: en büyük sıçramalar modeli değiştirdiğinizde değil, aramayı düzelttiğinizde geldi. Sahadan söylüyorum — retrieval'i onaran, RAG'ı onarır.

Boru hattını tasarlarken sık atlanan bir katman da vektör veritabanının kendisidir. Hangi veritabanını seçtiğiniz, hem hibrit aramayı ne kadar kolay kuracağınızı hem de KVKK uyumluluğunuzu doğrudan etkiler. Sahada dikkat ettiğim birkaç nokta var.

Birincisi, seçtiğiniz veritabanı hem dense hem de BM25 (lexical) aramayı yerel olarak destekliyor mu? Bazı modern vektör veritabanları hibrit aramayı ve hatta RRF birleştirmesini kutudan çıkar çıkmaz sunuyor. Bu, ayrı bir arama motoru (örneğin bir metin arama altyapısı) ile vektör deposunu elle senkronize etme yükünden sizi kurtarır. İki ayrı sistemi elde tutmak, iki ayrı yerde tutarlılık, iki ayrı yerde güncelleme demektir; tek sistemde hibrit destek, operasyonel yükü ciddi biçimde azaltır.

İkincisi, veri egemenliği yine karşınıza çıkar. Yönetilen bir bulut vektör veritabanı çok pratiktir ama verinizin nerede tutulduğu, hangi ülkede işlendiği KVKK açısından kritik bir sorudur. Bankacılık, sağlık ve kamu müşterilerimde çoğu zaman kendi altyapımızda (on-premise ya da özel bulut) barındırılabilen bir çözüm tercih ediyoruz. Verinin fiziksel konumu bir mimari değil, bir uyumluluk kararıdır.

Üçüncüsü, filtreleme ve meta veri (metadata) desteği. Gerçek dünyada retrieval hiçbir zaman sadece "en benzer belgeyi getir" değildir. Genelde "bu departmana ait, şu tarihten sonra yayınlanmış, şu erişim yetkisine sahip kullanıcının görebileceği belgeler arasından en benzerini getir" dersiniz. Bu yüzden vektör veritabanınızın zengin meta veri filtrelemesi desteklemesi şarttır. Erişim kontrolü (access control) özellikle kurumsal RAG'da hayati önemdedir: bir kullanıcının görmemesi gereken bir belgenin cevaba sızması, hem güvenlik hem KVKK ihlali olabilir.

"

Sahadan bir uyarı: RAG sistemlerinde en tehlikeli hatalardan biri, erişim yetkisi olmayan bir belgenin retrieval yoluyla cevaba sızmasıdır. Kullanıcı belgeyi doğrudan göremiyor ama RAG sistemi onun içeriğini cevapta özetliyorsa, yetki modelinizi baştan kırdınız demektir. Retrieval katmanına yetki filtresini en baştan, en derine gömün.

Sahada aynı hataları tekrar tekrar görüyorum. Bir kontrol listesi olarak paylaşayım, çünkü bunları baştan bilmek aylarca zaman kazandırır.

• Hata 1 — Önce modeli değiştirmek. En baştaki tezimize dönüyoruz. Cevaplar kötüyse ilk refleks modeli yükseltmek oluyor. Oysa önce retrieval'i ölçün. Recall düşükse model masum.
• Hata 2 — Golden test seti olmadan ilerlemek. "Daha iyi görünüyor" bir kanıt değildir. Ölçmediğiniz şeyi iyileştiremezsiniz; sadece iyileştirdiğinizi sanırsınız.
• Hata 3 — Türkçe için İngilizce ayarlarla çalışmak. İngilizce için varsayılan BM25 analizörü, İngilizce embedding modeli, İngilizce reranker benchmark'ı. Türkçe eklemeli bir dil; bu varsayılanlar Türkçe'de sessizce başarısız olur.
• Hata 4 — Chunking'i sonradan düşünmek. Ekipler genelde önce arama motorunu kurar, chunking'i baştan savar. Oysa kötü chunk, iyi retrieval'i imkansız kılar. Temel önce gelir.
• Hata 5 — Kaynak göstermemek. Kullanıcı cevabın nereden geldiğini göremiyorsa güven oluşmaz, hata da denetlenemez. KVKK dünyasında bu çoğu zaman doğrudan bir uyumluluk eksikliğidir.
• Hata 6 — Her sorguya tam boru hattını çalıştırmak. Basit bir "merhaba" ya da tek kelimelik bir aramaya cross-encoder reranking çalıştırmak, para ve gecikme israfıdır. Kademeli mimari tam da bunun için var.
• Hata 7 — Reranker'ı hiç değerlendirmeden üretime almak. "Herkes bunu kullanıyor" bir gerekçe değildir. Kendi Türkçe verinizde NDCG@10 ve MRR ile ölçmeden hiçbir reranker'a güvenmeyin.

Bu yedi hatanın ortak paydası şu: hepsi ölçüm ve disiplin eksikliğinden doğuyor. RAG heyecan verici bir teknoloji ama sahada iş gören RAG, sıkıcı mühendislik disiplininin ürünüdür — ölç, düzelt, tekrar ölç. Parlak model değil, sağlam boru hattı kazandırır.