Reranker Gerçekten Gerekli mi? Benchmark ve Karar Rehberi

Reranker gerçekten gerekli mi? Kısa cevap: duruma bağlıdır ve bunu ancak kendi verinizle ölçerek bilebilirsiniz. Reranker (yeniden sıralayıcı), ilk-aşama retrieval'ın getirdiği aday belge parçalarını kullanıcı sorusuyla gerçek alaka düzeyine göre yeniden puanlayıp sıralayan ikinci bir arama katmanıdır; bir RAG hattında modele giden bağlamın kalitesini yükseltmek için kullanılır. Ama her RAG sistemi bir reranker'a ihtiyaç duymaz. Bu rehber, bir reranker'ın ne zaman değer kattığını, ne zaman gereksiz olduğunu, maliyet-gecikme ödünleşimini, nasıl benchmark edileceğini ve alternatiflerini bir yapay zeka mühendisi titizliğiyle ele alır. Temel kavramı hızlıca tazelemek isterseniz reranker nedir ve hattın bütününü görmek için RAG nedir yazıları iyi bir başlangıçtır.

Bu yazının amacı, "reranker her zaman iyidir" veya "reranker gereksiz bir karmaşıklıktır" gibi iki uç dogmadan da uzak durmaktır. Gerçek, ikisinin arasındadır ve verinize, sorgularınıza ve kalite hedefinize bağlıdır. Aşağıda önce reranker'ın retrieval hattındaki rolünü ve bi-encoder ile cross-encoder farkını netleştiriyoruz; sonra değer kattığı ve katmadığı durumları, maliyet ödünleşimini, bir benchmark'ı nasıl kuracağınızı, alternatifleri, üretim mimarisini ve somut bir karar çerçevesini adım adım ele alıyoruz.

Tanım

Reranker (Yeniden Sıralayıcı)

İlk-aşama retrieval'ın döndürdüğü aday belge parçalarını, kullanıcı sorusuyla gerçek alaka düzeyine göre yeniden puanlayıp sıralayan ikinci bir arama katmanı. Reranker tipik olarak bir cross-encoder (çapraz kodlayıcı) kullanır: soru ve belgeyi birlikte değerlendirdiği için ilk-aşamadaki bi-encoder'dan daha isabetli ama daha yavaştır ve yalnızca küçük bir aday kümesine uygulanır. Reranker recall'ı değil precision ve sıralama kalitesini iyileştirir; retrieval kalitesini ve yanıt doğruluğunu artırabilir. Gerekliliği evrensel değil, kendi verinizle yapılan bir benchmark ile belirlenen bir karardır.

Ayrıca: yeniden sıralayıcı, reranking modeli, cross-encoder reranker, ikinci aşama sıralama, RAG reranker

Bir RAG sisteminde yanıtın kalitesi büyük ölçüde tek bir soruya bağlıdır: modele doğru bağlam verildi mi? Bu bağlamı sağlayan retrieval hattı genellikle iki aşamalıdır. Birinci aşama, milyonlarca parça arasından hızla bir aday listesi çeker; ikinci aşama, yani reranker, bu aday listesini alıp soruyla gerçek alaka düzeyine göre yeniden sıralar. Yani bir reranker, sıfırdan arama yapmaz; kendisine verilen küçük ve önceden seçilmiş bir aday kümesini rafine eder.

Bu iş bölümü önemlidir. İlk-aşama retrieval hız için tasarlanır ve bu hız bir bedelle gelir: aday listesindeki parçaların hepsi eşit derecede alakalı değildir ve sıralamaları her zaman doğru değildir. Reranker tam bu noktada devreye girer; adayları tek tek, daha titiz bir modelle puanlayıp en alakalıları öne, alakasızları geriye taşır. Sonuç, modele giden bağlamın daha temiz, daha odaklı ve daha az gürültülü olmasıdır. Bu, doğrudan retrieval kalitesini ve dolayısıyla yanıt doğruluğunu etkiler.

Reranker'ın yaptığı işi bir benzetmeyle netleştirelim. İlk-aşama retrieval, geniş bir ağ atan bir balıkçı gibidir: hızlı ve kapsayıcıdır ama ağa istenmeyen balıklar da takılır. Reranker ise ağdaki balıkları tek tek elden geçiren, en iyilerini seçen bir kalite kontrol adımıdır. Ağ hiç doğru balığı yakalamadıysa, reranker bir şey yapamaz; ama ağ doğru balığı yakaladıysa ve o balık diğerlerinin arasında kaybolduysa, reranker onu öne çıkarır. Bu ayrım, "reranker gerekli mi" sorusunun cevabının neden ilk-aşamanın kalitesine bağlı olduğunu da açıklar.

Reranker'ı hattın geri kalanıyla birlikte düşünmek gerekir. Chunking parçaların nasıl kesildiğini, embedding parçaların nasıl temsil edildiğini, vektör veritabanı aramanın nasıl yapıldığını belirler; reranker ise bu zincirin sonundaki bir keskinleştirme katmanıdır. Bu bileşenlerin temelini embedding nedir, vektör veritabanı nedir ve chunking nedir yazılarında ele alıyoruz. Reranker güçlüdür ama bir sihirli değnek değildir; zincirin önceki halkaları bozuksa, reranker tek başına sistemi kurtaramaz.

Reranker'ı gerçekten anlamak için, ilk-aşama retrieval ile yeniden sıralama arasındaki mimari farkı görmek gerekir. Bu fark, iki farklı model tipinden kaynaklanır: bi-encoder ve cross-encoder. İkisi de metin çiftleri arasındaki alakayı ölçer, ama tamamen farklı biçimlerde ve tamamen farklı hız-isabet profilleriyle.

Bi-encoder, soruyu ve belgeyi birbirinden bağımsız olarak, ayrı ayrı bir vektöre gömer. Sonra bu iki vektörün yakınlığına (örneğin kosinüs benzerliği) bakarak alakayı tahmin eder. Bu tasarımın büyük avantajı hızdır: belgelerin vektörleri önceden hesaplanıp vektör veritabanına indekslenebilir; sorgu geldiğinde yalnızca sorunun vektörü hesaplanır ve milyonlarca önceden hesaplanmış vektörle hızla karşılaştırılır. İşte bu yüzden bi-encoder, ilk-aşama retrieval için idealdir — ölçeklenebilir ve düşük gecikmelidir. Embedding tabanlı arama, temelde bir bi-encoder yaklaşımıdır.

Cross-encoder ise bambaşka çalışır. Soruyu ve belgeyi ayrı ayrı gömmek yerine, ikisini birlikte, tek bir girdi olarak modele verir ve model bu çiftin ne kadar alakalı olduğunu doğrudan puanlar. Model, soru ile belge arasındaki kelime düzeyinde etkileşimi görebildiği için çok daha isabetli bir alaka sinyali üretir. Ama bir maliyeti vardır: her soru-belge çifti için ayrı bir çıkarım gerekir. Bu, milyonlarca belge için imkânsızdır; ama ilk-aşamanın döndürdüğü birkaç düzine aday için gayet mümkündür. Reranker'lar tam olarak bu cross-encoder mantığıyla çalışır.

Bu ikisinin birbirini tamamlaması, iki aşamalı retrieval tasarımının kalbidir. Bi-encoder geniş ve hızlı bir aday kümesi getirir (yüksek recall hedefler); cross-encoder tabanlı reranker bu küçük kümeyi yeniden sıralar (yüksek precision hedefler). Ne yalnızca bi-encoder ne de yalnızca cross-encoder tek başına ideal değildir: bi-encoder hızlı ama kaba, cross-encoder isabetli ama yavaştır. Birlikte, hem ölçek hem isabet elde edilir. Modellerin metni nasıl işlediğinin temeli için transformer nedir yazısı bağlam sunar.

Bi-encoder ile cross-encoder karşılaştırması

Boyut	Bi-encoder (ilk-aşama)	Cross-encoder (reranker)
Nasıl çalışır	Soru ve belgeyi ayrı gömer	Soru ve belgeyi birlikte değerlendirir
Hız	Çok hızlı (önceden indekslenir)	Yavaş (aday başına çıkarım)
İsabet	İyi ama kaba	Yüksek, etkileşimi görür
Ölçek	Milyonlarca belge	Yalnızca küçük aday kümesi
Rolü	Recall'ı garanti et	Precision'ı yükselt

Bu tablo, "reranker gerekli mi" sorusunu somut bir mühendislik sorusuna dönüştürür: ilk-aşama bi-encoder'ınız doğru parçayı aday listesine sokabiliyor ama en üste çıkaramıyorsa, bir cross-encoder reranker'ın katacağı değer yüksektir. Ama bi-encoder'ınız zaten doğru parçayı en üste çıkarıyorsa, reranker'ın ekleyeceği marjinal değer düşük olabilir. Karar, bu iki aşamanın kendi verinizdeki davranışına bağlıdır.

Bir reranker'ın gerçekten değer kattığı durumlar, ortak bir örüntü paylaşır: ilk-aşama retrieval doğru parçayı aday listesine sokar ama onu en üste çıkaramaz. Bu "getirildi ama gömüldü" durumu, reranker'ın parladığı yerdir. Aşağıda bu değeri belirginleştiren tipik koşulları ele alıyoruz; bunlar illüstratiftir ve kendi sisteminizde bir benchmark ile doğrulanmalıdır.

Birinci durum, benzer belgelerin çokluğudur. Bir bilgi tabanında aynı konuyu farklı bağlamlarda anlatan çok sayıda parça varsa, bi-encoder bunların hepsini "anlamca yakın" bulur ve aralarında ince ayrımı yapmakta zorlanır. Örneğin bir sigorta bilgi tabanında onlarca poliçe, birbirine çok benzeyen dille yazılmış olabilir; doğru poliçenin ilgili maddesi aday listesine girer ama beşinci veya onuncu sırada kalır. Cross-encoder reranker, soruyla belge arasındaki ince alaka farkını gördüğü için doğru maddeyi öne çıkarabilir. Bu, reranker'ın en klasik değer senaryosudur.

İkinci durum, sorgu-belge ifade farkının yüksek olmasıdır. Kullanıcı bir şeyi bir biçimde sorarken, cevap belgede tamamen farklı bir dille yazılmış olabilir. Bi-encoder bu boşluğu bazen kapatır ama her zaman değil; cross-encoder, soru ve belgeyi birlikte değerlendirdiği için bu ifade farkını daha iyi köprüler. Özellikle uzun ve çok yönlü sorularda, sorunun hangi kısmının belgenin hangi kısmıyla eşleştiğini görmek reranker'ın gücüdür.

Üçüncü durum, yanlış yanıtın maliyetinin yüksek olmasıdır. Hukuk, finans, sağlık gibi alanlarda yanlış bir parçaya dayanan bir yanıt ciddi sonuçlar doğurabilir. Bu bağlamlarda, modele giden bağlamın son derece temiz olması kritiktir ve reranker'ın sağladığı ek precision, gecikme maliyetine değer. Buna karşılık, yanlış yanıtın maliyeti düşük bir iç arama aracında aynı yatırım gereksiz olabilir. Yanlış olmanın maliyeti, reranker kararının en belirleyici tek faktörüdür.

Dördüncü durum, geniş aday kümesiyle çalışmaktır. Eğer recall'ı garantiye almak için ilk-aşamadan çok sayıda aday (örneğin ilk 100-200 parça) çekiyorsanız, bu geniş kümeyi doğrudan modele veremezsiniz — hem context window sınırı hem gürültü buna izin vermez. Reranker, bu geniş kümeyi birkaç nitelikli parçaya indirmenin en etkili yoludur. Bağlam penceresinin sınırları için context window nedir yazısına bakabilirsiniz. Burada reranker, "geniş getir, dar besle" stratejisinin vazgeçilmez halkasıdır.

Reranker her zaman doğru cevap değildir ve bazen eklenen karmaşıklık, kattığı değerden fazladır. Bir mühendis olarak, reranker'ın gereksiz veya hatta zararlı olduğu durumları da net görmek gerekir; aksi halde her hatta reddedilemez bir varsayım olarak reranker eklemek, gecikmeyi ve maliyeti boşuna artırır.

Birinci durum, ilk-aşama retrieval'ın zaten yüksek isabetli olmasıdır. Eğer bilgi tabanınız küçük ve iyi yapılandırılmışsa, sorgular net ve tekilse ve bi-encoder doğru parçayı çoğu zaman zaten en üste çıkarıyorsa, reranker'ın ekleyeceği marjinal değer küçük olur. Bu durumda reranker, ölçülebilir bir kalite kazancı sağlamadan yalnızca gecikme ekler. Doğru parça zaten birinci sırada geliyorsa, onu yeniden sıralamanın anlamı yoktur.

İkinci durum, gecikme bütçesinin çok dar olmasıdır. Gerçek zamanlı, yüksek hacimli bir uygulamada — örneğin her tuş vuruşunda öneri üreten bir arama kutusu — reranker'ın eklediği milisaniyeler kabul edilemez olabilir. Burada ödünleşim nettir: reranker biraz daha iyi sıralama sunar ama kullanıcı deneyimini bozan bir gecikme pahasına. Böyle bağlamlarda, ya reranker'dan vazgeçilir ya da yalnızca çok seçici biçimde tetiklenir.

Üçüncü durum, kötü kurulmuş bir reranker'ın zarar vermesidir. Reranker'ın kalitesi mutlak değildir; yanlış model, yanlış dil veya yanlış yapılandırma, retrieval kalitesini iyileştirmek yerine bozabilir. Örneğin yalnızca İngilizce için eğitilmiş bir reranker, Türkçe soru-belge çiftlerinde alakayı yanlış puanlayarak doğru parçayı geriye atabilir. Bu durumda reranker eklemek, sistemi reranker'sız halinden daha kötü hale getirir. İşte bu yüzden bir reranker'ı benchmark etmeden üretime almak risklidir; kör bir "reranker her zaman iyidir" varsayımı sizi yanıltabilir.

Dördüncü durum, asıl sorunun başka bir katmanda olmasıdır. Eğer doğru parça aday listesine hiç girmiyorsa (düşük recall), sorun sıralamada değil, ilk-aşama getirmededir; reranker bunu düzeltemez çünkü olmayan bir parçayı öne çıkaramaz. Benzer şekilde, chunking kötüyse ve doğru bilgi hiçbir parçada bütün olarak yoksa, reranker çaresizdir. Bu durumlarda reranker eklemek, kök nedeni gizleyen bir yamadır. Önce recall'ı ve chunking'i düzeltmek, sonra reranker'a bakmak doğru sıradır.

Reranker ne zaman gerekli, ne zaman gereksiz

Durum	Reranker gerekli mi?	Neden
Benzer belge çok, doğru parça gömülüyor	Evet	Precision sorununu çözer
Yanlış yanıtın maliyeti yüksek	Genellikle evet	Temiz bağlam kritik
İlk-aşama zaten çok isabetli	Hayır	Marjinal değer düşük
Gecikme bütçesi çok dar	Genellikle hayır	Gecikme kaliteyi bastırır
Sorun düşük recall / kötü chunking	Hayır (önce onu çöz)	Reranker olmayan parçayı getiremez

Bu tablo, reranker kararının neden tek bir "evet/hayır" olmadığını gösterir. Doğru soru "reranker iyi mi kötü mü" değil, "benim verimde, benim sorgularımda, benim gecikme bütçemde reranker ölçülebilir bir net değer katıyor mu"dur. Bu sorunun cevabı da bir benchmark gerektirir.

Reranker'ın kattığı kalite bedavaya gelmez; iki tür maliyet taşır: gecikme (her sorgu ne kadar yavaşlıyor) ve hesaplama/para (her sorgu ne kadara mal oluyor). Bir reranker'ı üretime almadan önce bu ödünleşimi bilinçli yönetmek gerekir; aksi halde kalite kazancı, kullanıcı deneyimini bozan bir gecikmeyle veya sürdürülemez bir maliyetle gelebilir.

Maliyetin kök nedeni cross-encoder'ın doğasıdır: her aday için ayrı bir çıkarım yapılır. Bu, maliyetin doğrudan aday sayısıyla orantılı olduğu anlamına gelir. 100 adayı yeniden sıralamak, 20 adayı yeniden sıralamaktan kabaca beş kat daha pahalıdır. Bu yüzden ilk ve en etkili kaldıraç, aday sayısını akıllıca seçmektir: recall'ı garantiye alacak kadar geniş, ama gereksiz maliyet eklemeyecek kadar dar. Doğru aday sayısı bir tahmin değil, benchmark ile bulunan bir değerdir.

İkinci kaldıraç model seçimidir. Reranker modelleri boyut ve hız açısından çeşitlidir; daha büyük bir model daha isabetli olabilir ama daha yavaştır. Damıtılmış (distilled) veya daha küçük reranker modelleri, isabetten biraz ödün vererek belirgin hız kazancı sağlayabilir. Kendi bağlamınızda, daha küçük bir modelin isabet kaybının kabul edilebilir olup olmadığını benchmark ile ölçmelisiniz; çoğu zaman küçük bir model, büyük modelin kalitesinin çoğunu çok daha düşük gecikmeyle sunar.

Üçüncü kaldıraç önbelleklemedir. Popüler ve tekrar eden sorgular için reranker sonuçları önbelleğe alınabilir; aynı soru tekrar geldiğinde reranker'ı yeniden çalıştırmaya gerek kalmaz. Anlamsal önbellekleme — anlamca benzer sorulara verilen sıralamaları yeniden kullanmak — hem gecikmeyi hem maliyeti düşürür. Bu, özellikle sık sorulan soruların yoğun olduğu müşteri destek senaryolarında büyük tasarruf sağlar.

Dördüncü ve giderek popülerleşen kaldıraç, seçici tetiklemedir. Her sorgu reranker'a ihtiyaç duymaz; net ve tekil sorgular ilk-aşamadan zaten iyi yanıt alırken, belirsiz ve çok yönlü sorgular reranker'dan fayda görür. Bir yönlendirme (routing) katmanı, sorguyu sınıflandırıp yalnızca reranker'a değer katacak olanları yeniden sıralamaya gönderebilir. Bu, ortalama gecikmeyi ve maliyeti düşürürken, reranker'ın değerini en çok ihtiyaç duyulan yerde korur.

Reranker maliyet-gecikme kaldıraçları

Kaldıraç	Etkisi	Ödünleşimi
Aday sayısını daraltma	Doğrudan maliyet düşüşü	Çok darsa recall riski
Daha küçük/damıtılmış model	Gecikme düşer	Bir miktar isabet kaybı
Önbellekleme	Tekrar eden sorguda çok hızlı	Tazelik yönetimi gerekir
Seçici tetikleme (routing)	Ortalama maliyeti düşürür	Yönlendirme mantığı ek karmaşıklık

Bu kaldıraçların ortak dersi şudur: reranker bir "aç/kapa" düğmesi değil, ayarlanabilir bir katmandır. "Reranker gerekli mi" sorusu çoğu zaman "hangi maliyet ayarıyla reranker net değer katar" sorusuna dönüşür. Ve bu ayarın doğru noktası, ancak gecikme ile kalite kazancını birlikte ölçen bir benchmark ile bulunur. Token başına maliyet mantığını token nedir yazısında bulabilirsiniz.

"Reranker gerekli mi" sorusunun tek sağlam cevabı ölçümdür. Sezgi, blog yazıları veya bir modelin genel itibarı, sizin verinizde reranker'ın gerçekten değer katıp katmayacağını söyleyemez. Bu yüzden bir reranker kararı, mutlaka kendi verinizle kurulan bir benchmark üzerine oturmalıdır. İyi haber şudur: kapsamlı ve mükemmel bir benchmark gerekmez; küçük ama gerçekçi bir altın küme bile net bir yön verir. Değerlendirmenin genel çerçevesi için LLM değerlendirme nedir yazısına bakabilirsiniz.

Bir benchmark'ın ilk adımı altın küme hazırlamaktır: gerçek kullanıcı sorularından türetilmiş bir soru koleksiyonu ve her soru için hangi belge parçalarının doğru cevabı içerdiğinin işaretlenmesi. Bu işaretleme, retrieval kalitesini ölçmenin temelidir; hangi parçanın "doğru" olduğunu bilmeden ne recall ne de sıralama kalitesi hesaplanabilir. Küçük bir pilotta toplanan gerçek sorular, sentetik olarak üretilenlerden daha değerlidir çünkü sistemin gerçek kullanımını yansıtırlar.

İkinci adım, iki hattı yan yana kurmaktır: biri reranker'sız (yalnızca ilk-aşama retrieval), biri reranker'lı (ilk-aşama + yeniden sıralama). Her iki hat da aynı altın küme sorularıyla çalıştırılır. Kritik nokta, tek değişkenin reranker olmasıdır; chunking, embedding, aday sayısı gibi diğer her şey sabit tutulmalıdır ki ölçtüğünüz fark gerçekten reranker'dan gelsin. Aynı anda birden çok değişkeni değiştirmek, hangisinin etki ettiğini gizler.

Üçüncü adım, üç eksende ölçmektir. Retrieval kalitesi ekseninde recall, nDCG ve MRR gibi sıralama metrikleri; uçtan uca kalite ekseninde yanıt doğruluğu ve bağlılık; operasyon ekseninde ise gecikme ve maliyet farkı ölçülür. Karar bu üç eksenin toplamından çıkar: reranker retrieval kalitesini ve yanıt doğruluğunu ne kadar artırıyor, karşılığında ne kadar gecikme ve maliyet ekliyor? Aşağıdaki tablo bu benchmark yapısını özetler.

Reranker benchmark kurgusu: neyi, nasıl ölçmeli

Eksen	Metrik	Ne sorar
Retrieval kalitesi	Recall@k	Doğru parça ilk k aday içinde mi
Sıralama kalitesi	nDCG / MRR	Doğru parça ne kadar üstte
Uçtan uca	Yanıt doğruluğu / bağlılık	Nihai cevap doğru ve dayanaklı mı
Operasyon	Gecikme / maliyet	Reranker ne kadar yavaşlattı, pahalılaştırdı

Bir benchmark yorumlarken dikkatli olmak gerekir. Reranker retrieval metriklerini (nDCG, MRR) belirgin iyileştirdiği halde uçtan uca yanıt doğruluğunu neredeyse hiç değiştirmiyorsa, bu, ilk-aşamanın zaten yeterince iyi olduğunun işareti olabilir — sıralama düzeldi ama modelin yanıtı zaten doğruydu. Tersine, retrieval metrikleri az iyileşse bile yanıt doğruluğu belirgin artıyorsa, reranker kritik birkaç zor soruda fark yaratıyor demektir. Bu yüzden yalnızca retrieval metriklerine değil, uçtan uca sonuca da bakmak şarttır.

Bir reranker benchmark'ının kalbi doğru metriklerdir; yanlış metriğe bakmak, yanlış karara götürür. Reranker temelde bir sıralama problemini çözdüğü için, ölçümlerin çoğu sıralama kalitesine odaklanır. Ama yalnızca sıralama metrikleri yeterli değildir; uçtan uca sonuç ve operasyonel maliyet de tabloya girmelidir.

En temel metrik recall@k'dir: doğru parçanın ilk k aday içinde olup olmadığı. Bu aslında ilk-aşama retrieval'ın metriğidir ve reranker'ın onu doğrudan iyileştirmediğini hatırlamak gerekir; reranker aday listesini değiştirmez, yalnızca sıralar. Ama recall@k'yi ölçmek yine de kritiktir çünkü reranker'ın tavanını belirler: eğer recall@50 düşükse (doğru parça ilk 50'ye bile girmiyorsa), reranker'ın yapabileceği bir şey yoktur ve sorun ilk-aşamadadır.

Reranker'ın gerçek etkisini gösteren metrikler sıralama duyarlı olanlardır: nDCG (normalized discounted cumulative gain) ve MRR (mean reciprocal rank). nDCG, doğru parçaların ne kadar üstte olduğunu, alaka derecesiyle ağırlıklandırarak ölçer; reranker doğru parçaları öne çıkardığında nDCG yükselir. MRR ise ilk doğru parçanın ortalama kaçıncı sırada geldiğini ölçer; reranker doğru parçayı birinci sıraya taşıdığında MRR iyileşir. Bu iki metrik, reranker'ın "getirildi ama gömüldü" sorununu ne kadar çözdüğünü doğrudan gösterir.

Sıralama metriklerinin ötesinde, uçtan uca değerlendirme şarttır. Sonuçta kullanıcı nDCG görmez, nihai yanıtı görür. Bu yüzden yanıt doğruluğu (nihai cevap altın cevapla uyumlu mu) ve bağlılık (yanıt yalnızca getirilen bağlama mı dayanıyor) ölçülmelidir. Bu boyutları ölçmenin yaygın bir yolu, bir güçlü dil modelini hakem olarak kullanmaktır (LLM-as-judge): model, yanıtı ve bağlamı okuyup doğruluk ve bağlılık puanı verir. Son olarak, operasyonel metrikler — sorgu başına ek gecikme ve maliyet — reranker'ın bedelini gösterir. Karar, kalite kazancı ile bu bedelin karşılaştırılmasıyla verilir.

Reranker'a atlamadan önce sorulması gereken önemli bir soru vardır: sorunumu reranker olmadan, retrieval kalitesini başka bir katmanda iyileştirerek çözebilir miyim? Çünkü reranker, retrieval kalitesini artırmanın tek yolu değildir; ve bazen daha ucuz, daha basit bir alternatif aynı işi görür. Bir mühendis olarak, reranker'ı bu alternatiflerle birlikte değerlendirmek gerekir.

Birinci alternatif hybrid search'tür. Eğer sorununuz doğru parçanın aday listesine hiç girmemesi (düşük recall) ise, reranker işe yaramaz — çünkü reranker olmayan parçayı getiremez. Bu durumda çözüm, ilk-aşama recall'ını artırmaktır ve hybrid search bunun en etkili yoludur. Hybrid search, anlamsal (dense) aramayı anahtar kelime (sparse, örneğin BM25) aramasıyla birleştirir; dense aramanın kaçırdığı tam terim, ürün kodu ve nadir kelime eşleşmelerini sparse arama yakalar. Bu, doğru parçanın aday listesine girme olasılığını yükseltir ve böylece retrieval kalitesini reranker'a ihtiyaç duymadan iyileştirebilir. Anlamsal aramanın mantığını semantik arama nedir yazısında ele alıyoruz.

İkinci alternatif query rewriting'tir (sorgu yeniden yazma). Kullanıcılar soruları çoğu zaman eksik, belirsiz veya konuşma bağlamına gömülü sorar; bu ham soru doğrudan aratıldığında retrieval kalitesi düşer. Bir dil modeli, ham soruyu kendi kendine yeten, açık bir sorguya dönüştürerek retrieval'ı belirgin biçimde iyileştirebilir. Örneğin "peki ya iadesi?" sorusu "bu ürünün iade süresi ve koşulları nelerdir?" biçimine getirilir. Bazen kötü sıralamanın nedeni reranker'ın yokluğu değil, sorgunun kalitesizliğidir; query rewriting bu kök nedeni doğrudan hedefler.

Üçüncü ve en temel alternatif, hattın önceki halkalarını iyileştirmektir: daha iyi chunking ve daha iyi embedding. Eğer parçalar kötü kesildiyse veya embedding modeli diliniz için zayıfsa, hiçbir reranker bunu tam telafi edemez. Türkçe içerik için Türkçeyi iyi temsil eden bir embedding modeli seçmek, çoğu zaman bir reranker eklemekten daha yüksek getiri sağlar. Bu yüzden doğru sıra genellikle şudur: önce chunking ve embedding'i sağlamlaştır, sonra hybrid search ekle, sonra hâlâ sıralama sorunu varsa reranker'a geç.

Retrieval kalitesini artıran katmanlar: hangisi hangi sorunu çözer

Katman	Çözdüğü sorun	Reranker'a göre
Daha iyi chunking	Bilgi parçalarda bütün değil	Reranker'dan önce gelir
Daha iyi embedding	Anlam zayıf temsil ediliyor	Reranker'dan önce gelir
Hybrid search	Doğru parça listeye girmiyor (recall)	Reranker'ı tamamlar
Query rewriting	Sorgu belirsiz/eksik	Reranker'dan bağımsız
Reranker	Doğru parça listede ama gömülü (precision)	Sıralamayı keskinleştirir

Bu tablo, reranker'ın alternatiflerle rakip değil, farklı sorunları çözen tamamlayıcılar olduğunu gösterir. Olgun bir hat çoğu zaman bunları birlikte kullanır: iyi chunking + iyi embedding + hybrid search ile geniş ve isabetli bir aday kümesi getirilir, gerektiğinde query rewriting ile sorgu netleştirilir, ve reranker ile bu küme keskinleştirilir. "Reranker gerekli mi" sorusu, bu bağlamda "reranker, diğer katmanları düzelttikten sonra hâlâ gerekli mi"ye dönüşür.

"Reranker" tek bir şey değildir; farklı isabet, hız ve maliyet profillerine sahip birkaç yaklaşım vardır. Doğru reranker türünü seçmek, kararın önemli bir parçasıdır ve yine kendi verinizle benchmark edilmelidir. Aşağıda başlıca aileleri ele alıyoruz; hiçbiri her senaryo için mutlak en iyi değildir, her biri farklı bir ödünleşim sunar.

En yaygın ve en klasik aile cross-encoder reranker'lardır. Bunlar, soru ve belgeyi birlikte alıp tek bir alaka puanı üreten transformer tabanlı modellerdir. En yüksek sıralama isabetini genellikle bu modeller sunar çünkü soru ile belge arasındaki tam etkileşimi görürler. Bedeli, aday başına ayrı bir çıkarım gerektirmeleri ve dolayısıyla görece yavaş olmalarıdır. Çoğu kurumsal RAG hattında "reranker" denince akla gelen budur ve iyi bir başlangıç noktasıdır.

İkinci aile, geç etkileşimli (late-interaction) çok-vektörlü modellerdir. Bu yaklaşımda soru ve belge token düzeyinde temsil edilir ve alaka, token vektörleri arasındaki ince eşleşmelerle hesaplanır. Bu, saf bir bi-encoder'dan daha isabetli, tam bir cross-encoder'dan ise daha hızlı bir orta yol sunabilir; ayrıca belge temsillerinin kısmen önceden hesaplanmasına izin verdiği için ölçeklenmeye daha uygundur. Karşılığında, depolama ve indeksleme karmaşıklığı artar.

Üçüncü ve giderek popülerleşen aile, bir büyük dil modelini reranker olarak kullanmaktır (LLM-as-reranker). Burada model, adayları alaka düzeyine göre sıralaması veya her birine bir puan vermesi için yönlendirilir. Bu yaklaşım çok esnektir — modele alaka kriterini doğal dilde tarif edebilir, hatta çok yönlü ve nüanslı alaka tanımları verebilirsiniz. Ama maliyeti ve gecikmesi yüksek olabilir ve tutarlılığı dikkatle test edilmelidir. Bir dil modelinin nasıl çalıştığını LLM nedir yazısında ele alıyoruz.

Reranker aileleri: isabet, hız ve maliyet profilleri

Tür	İsabet	Hız	Not
Cross-encoder	Yüksek	Orta-yavaş	Klasik ve güvenilir başlangıç
Geç etkileşimli çok-vektör	Yüksek	Orta	Ölçeklenmeye uygun, depolama maliyeti
LLM-as-reranker	Değişken-yüksek	Yavaş	Esnek ama maliyetli

Tür seçiminde pratik bir yol, iyi bir cross-encoder ile taban çizgisini kurmak, sonra gecikme veya isabet gereksiniminiz onu zorlarsa diğer ailelere bakmaktır. Örneğin ölçek çok büyük ve gecikme kritikse geç etkileşimli modeller; alaka tanımı çok nüanslı ve hacim düşükse LLM-as-reranker mantıklı olabilir. Her durumda seçim, teorik üstünlükle değil, sizin benchmark'ınızdaki net kazançla yapılmalıdır.

Bir reranker'ı üretime almak, onu doğru yere yerleştirmek ve doğru gözlemlenebilirlikle sarmalamak demektir. Reranker, retrieval hattında ilk-aşama getirme ile prompt kurma adımının tam arasına oturur. Akışı net görmek, hem tasarımı hem de sorun gidermeyi kolaylaştırır.

Tipik üretim akışı şöyledir: kullanıcı sorusu gelir; isteğe bağlı olarak query rewriting ile netleştirilir; ilk-aşama retrieval (dense, sparse veya hybrid search) geniş bir aday kümesi getirir (örneğin ilk 50-100 parça); reranker bu adayları yeniden puanlar ve en alakalı birkaçını seçer (örneğin ilk 3-8 parça); seçilen parçalar bir prompt şablonuna yerleştirilir; ve dil modeli, kaynak göstererek yanıtı üretir. Bu iki aşamalı tasarımın zarafeti, reranker'ın pahalı hesaplamasını yalnızca küçük aday kümesiyle sınırlamasıdır — milyonlarca belge değil, yalnızca birkaç düzine aday yeniden sıralanır.

Nasıl Yapılır

Reranker'lı retrieval hattının üretim akışı

Bir kullanıcı sorusundan reranker'lı, kaynak gösteren yanıta kadar üretim hattının izlediği adımlar.

1. 1

   Sorguyu hazırla

   Kullanıcı sorusu alınır; gerekirse query rewriting ile bağımsız ve açık hale getirilir.

2. 2

   İlk-aşama retrieval

   Dense, sparse veya hybrid search ile geniş bir aday kümesi (örn. ilk 50-100) getirilir.

3. 3

   Reranker ile yeniden sırala

   Cross-encoder her adayı soruya karşı puanlar; en alakalı birkaç parça seçilir.

4. 4

   Bağlamı kur

   Seçilen parçalar kaynak etiketleriyle prompt şablonuna yerleştirilir.

5. 5

   Yanıt üret

   Dil modeli yalnızca bağlama dayanarak, kaynak göstererek yanıtı yazar.

6. 6

   Skorları logla

   Her adayın ilk-aşama ve reranker puanı kaydedilir; sorun gidermenin temeli budur.

Üretimde reranker'ın en çok ihmal edilen boyutu gözlemlenebilirliktir. Her sorgu için ilk-aşamanın döndürdüğü adaylar, onların ilk-aşama skorları ve reranker'ın verdiği yeni skorlar loglanmalıdır. Bu iz sayesinde bir yanıt yanlış olduğunda hatanın kaynağını ayırt edebilirsiniz: doğru parça hiç getirilmedi mi (ilk-aşama sorunu), getirildi ama reranker onu geriye mi attı (reranker sorunu), yoksa bağlam doğruyken model mi yanlış yorumladı (generation sorunu)? Bu ayrım olmadan, reranker'ı iyileştirmek körlemesine kalır. LLM sistemlerini izlemenin ayrıntısını LLMOps nedir yazısında ele alıyoruz.

İkinci üretim boyutu, reranker'ın hattın geri kalanıyla sürüm uyumudur. Reranker modelini değiştirdiğinizde, aday sayısı ve seçilen parça sayısı gibi parametreleri yeniden ayarlamanız gerekebilir; bu yüzden reranker'ı bir yapılandırma olarak yönetmek ve her değişikliği benchmark ile doğrulamak önemlidir. Ayrıca reranker bir dış API üzerinden çalışıyorsa, bu servisin kesintisi tüm hattı etkiler; bir geri dönüş (fallback) mekanizması — reranker erişilemezse ilk-aşama sıralamasıyla devam etmek — üretim dayanıklılığı için değerlidir.

Reranker kararı, Türkiye ve Türkçe bağlamında iki ek boyut kazanır: dil kalitesi ve veri egemenliği/KVKK. Bu boyutlar, küresel bir reranker tavsiyesini olduğu gibi almanın neden riskli olduğunu da gösterir; çünkü bir reranker'ın İngilizce başarımı, Türkçe başarımını garanti etmez.

Birinci boyut dil kalitesidir. Bir reranker'ın işi, soru ile belge arasındaki alakayı puanlamaktır; bu, dilin nüanslarını — eş anlamlıları, çekim eklerini, bağlamı — iyi anlamayı gerektirir. Yalnızca İngilizce için eğitilmiş bir cross-encoder, Türkçe soru-belge çiftlerinde bu alakayı zayıf puanlayabilir ve hatta doğru parçayı geriye atarak retrieval kalitesini bozabilir. Bu yüzden Türkçe ağırlıklı bir bilgi tabanında, çok dilli (multilingual) bir reranker tercih edilmeli ve mutlaka Türkçe bir altın küme ile benchmark edilmelidir. Türkçedeki morfolojik zenginlik, reranker seçiminde küçümsenmemesi gereken bir faktördür.

İkinci boyut veri egemenliği ve KVKK'dır. Bir reranker, soru ve aday belge içeriğini işler; eğer bu bir dış API üzerinden yapılıyorsa, bu içerik kurum dışına çıkar. Bilgi tabanı kişisel veya gizli veri içeriyorsa, bu durum KVKK açısından değerlendirilmelidir: verinin nereye gittiği, nasıl işlendiği ve saklanıp saklanmadığı önemlidir. Kendi altyapınızda barındırılan açık kaynak bir reranker, veriyi kurum içinde tutmayı sağlar ama operasyon ve bakım yükü getirir. KVKK'nın genel çerçevesi için KVKK nedir yazısına bakabilirsiniz. Not: bu bölüm bilgilendirme amaçlıdır, hukuki tavsiye değildir; kurumunuzun özel durumunu hukuk ve uyum birimiyle değerlendirmelisiniz.

Türkiye'de üretken yapay zeka benimsemesi hızlıdır ve bu, doğru kurgulanmış RAG sistemlerine olan talebi artırır. We Are Social "Digital 2026" verisine göre Türkiye, üretken yapay zeka araçlarından web'e yönlendirilen trafik payında öne çıkan ülkelerdendir; bu yüksek ilgi, kurumsal RAG çözümlerinde retrieval kalitesinin ve dolayısıyla reranker gibi kararların önemini artırır. Kaynak: Euronews TR / Digital 2026 (Ocak 2026). Yüksek benimseme, aynı zamanda Türkçe içerikte iyi çalışan reranker ve embedding modellerine olan ihtiyacı da görünür kılar.

Şimdiye kadar ele aldığımız her şeyi tek bir pratik karar çerçevesinde toplayalım. "Reranker gerekli mi" sorusunu, bir dizi sıralı soruyla yanıtlayabilirsiniz. Bu çerçeve bir dogma değil, düşünmeyi yapılandıran bir kılavuzdur; her adımda cevabınız, bir sonraki adıma yönlendirir.

İlk soru: ilk-aşama retrieval'ın recall'ı yeterli mi? Yani doğru parça, aday listesine (örneğin ilk 50) giriyor mu? Eğer girmiyorsa, sorununuz reranker değil; önce hybrid search, daha iyi embedding ve chunking ile recall'ı yükseltin. Reranker, olmayan parçayı getiremez. İkinci soru: doğru parça listeye giriyor ama üstte mi geliyor? Eğer doğru parça çoğu zaman zaten birinci veya ikinci sıradaysa, reranker'ın marjinal değeri düşüktür; eklemeden önce iyi düşünün. Ama doğru parça sık sık aşağı sıralarda gömülüyorsa, reranker'ın altın senaryosundasınız.

Üçüncü soru: yanlış yanıtın maliyeti nedir? Yüksek riskli bir alanda (hukuk, finans, sağlık) çalışıyorsanız, temiz bağlam kritiktir ve reranker'ın precision kazancı gecikme maliyetine değer. Düşük riskli bir iç araçta ise aynı yatırım gereksiz olabilir. Dördüncü soru: gecikme bütçem ne kadar? Çok darsa, reranker'ı ya seçici tetikleme ile ya da daha küçük bir modelle sınırlamayı düşünün; hiç yer yoksa reranker'dan vazgeçmek makul olabilir. Beşinci ve son soru: bunu benchmark ettim mi? Yukarıdaki tüm cevaplar hipotezdir; nihai karar, kendi verinizle reranker'lı ve reranker'sız hatları ölçmekten geçer.

Nasıl Yapılır

Reranker gerekli mi karar adımları

Bir RAG sisteminde reranker'a ihtiyaç olup olmadığını belirlemek için sıralı karar adımları.

1. 1

   Recall'ı kontrol et

   Doğru parça aday listesine giriyor mu? Girmiyorsa önce hybrid search ve embedding/chunking'i düzelt.

2. 2

   Sıralamayı incele

   Doğru parça listede ama gömülü mü? Öyleyse reranker'ın altın senaryosundasın.

3. 3

   Yanlışın maliyetini tart

   Yüksek riskli alanda temiz bağlam kritik; düşük riskte reranker gereksiz olabilir.

4. 4

   Gecikme bütçesini ölç

   Bütçe darsa seçici tetikleme veya küçük model; hiç yer yoksa reranker'sız devam et.

5. 5

   Alternatifleri değerlendir

   Query rewriting ve hybrid search sorunu reranker'sız çözüyor mu, önce onu dene.

6. 6

   Benchmark ile karar ver

   Reranker'lı ve reranker'sız hatları recall, nDCG ve yanıt doğruluğu açısından karşılaştır.

Bu çerçevenin özü şudur: reranker bir varsayılan değil, bir mühendislik kararıdır. Onu "herkes kullanıyor" diye eklemek de, "karmaşık" diye reddetmek de yanlıştır. Doğru yaklaşım, sistemin gerçek davranışını ölçmek ve reranker'ın net değer kattığını kanıtlamaktır. RAG hattının bütününü nasıl kuracağınızı RAG mimarisi nasıl kurulur yazısında ele alıyoruz.

Deneyimli bir gözle bakıldığında, reranker kararları benzer hatalarla bozulur. Bu hataların çoğu, reranker'ı ölçmeden ve hattın geri kalanından bağımsız düşünmekten kaynaklanır. En sık görülenler şunlardır.

• Ölçmeden eklemek: Reranker'ı bir benchmark olmadan "kalite artırır" varsayımıyla eklemek en yaygın hatadır. Bazı sistemlerde reranker net değer katar, bazılarında hiçbir fark yaratmaz, kötü kuruluysa zarar bile verir. Ölçmeden bilemezsiniz.
• Recall sorununu reranker'la çözmeye çalışmak: Doğru parça aday listesine hiç girmiyorsa, reranker çaresizdir. Bu, yanlış katmana yatırım yapmaktır; önce hybrid search ve embedding/chunking ile recall'ı düzeltmek gerekir.
• Dili göz ardı etmek: Türkçe bir sistemde yalnızca İngilizce reranker kullanmak, alakayı yanlış puanlayıp doğru parçayı geriye atabilir. Çok dilli bir reranker seçmek ve Türkçe benchmark yapmak şarttır.
• Aday sayısını yanlış ayarlamak: Çok az aday reranker'a versek recall'ı sınırlar (reranker zaten eksik bir listeyi düzeltemez); çok fazla aday gecikmeyi ve maliyeti şişirir. Doğru sayı benchmark ile bulunur.
• Gecikmeyi hesaba katmamak: Reranker'ı yalnızca kalite açısından değerlendirip eklediği gecikmeyi görmezden gelmek, kullanıcı deneyimini bozabilir. Kalite kazancı ile gecikme birlikte tartılmalıdır.
• Gözlemlenebilirlik kurmamak: Reranker skorlarını loglamadan, bir yanıt yanlış olduğunda hatanın retrieval'da mı yoksa yeniden sıralamada mı olduğunu göremezsiniz; bu, iyileştirmeyi körlemesine bırakır.
• Reranker'ı sihirli değnek sanmak: Reranker kötü chunking'i, zayıf embedding'i veya bozuk bir prompt'u telafi etmez. Sorun başka bir katmandaysa, reranker onu gizler ama çözmez.

Bir reranker'ın gerekli olup olmadığına dair nihai karar, teknik metriklerin ötesinde bir değer sorusudur: reranker'ın kattığı kalite, eklediği maliyet ve karmaşıklığa değiyor mu? Bu, bir yatırım getirisi (ROI) hesabıdır ve teknik benchmark'ı iş bağlamıyla birleştirmeyi gerektirir.

Getiri tarafında, reranker'ın kattığı değer birkaç biçimde görünür. Yanıt doğruluğundaki artış, kullanıcıların sisteme güvenini ve benimsemesini yükseltir; yanlış yanıtların azalması, özellikle yüksek riskli alanlarda maliyetli hataları önler; ve daha temiz bağlam sayesinde modele daha az parça gönderilmesi, bazen token maliyetini bile düşürür. Bu getirilerin bir kısmı doğrudan ölçülebilir (yanıt doğruluğu, çözülen soru oranı), bir kısmı ise dolaylıdır (güven, benimseme).

Maliyet tarafında, reranker'ın bedeli üç kalemdir: ek gecikme (kullanıcı deneyimine etkisi), ek hesaplama/para (sorgu başına maliyet) ve ek karmaşıklık (bakım, gözlemlenebilirlik, sürüm yönetimi). Bu maliyetlerin bir kısmı tek seferlik (kurulum, benchmark), bir kısmı süreklidir (her sorgunun maliyeti). ROI kararı, sürekli getiriyi sürekli maliyetle karşılaştırmayı gerektirir.

Pratik bir yaklaşım, reranker'ı dar bir kapsamda pilotlayıp ROI'yi ölçmektir. Reranker'ı önce en çok fayda beklediğiniz sorgu tipinde (örneğin benzer belgelerin yoğun olduğu bir alanda) devreye alın, uçtan uca yanıt doğruluğundaki değişimi ve eklediği gecikmeyi ölçün, sonra bu sonucu maliyetle karşılaştırın. Eğer reranker belirgin bir kalite kazancı sağlıyor ve gecikme kabul edilebilir sınırlarda kalıyorsa, kapsamı genişletin; sağlamıyorsa, kaynağı hattın gerçek darboğazına yönlendirin. Bu ölçülü yaklaşım, reranker'ı bir moda değil, kanıtlanmış bir yatırım olarak konumlandırır. Yapay zeka projelerinde değeri çerçevelemenin genel mantığı da bu kararı destekler.

ROI kararında sık gözden kaçan bir boyut, reranker'ın kattığı değerin zamanla değişebilmesidir. Bugün marjinal değer katan bir reranker, bilgi tabanınız büyüyüp belgeler birbirine benzedikçe kritik hale gelebilir; tersine, ilk-aşama retrieval'ınızı hybrid search ile güçlendirdiğinizde bir zamanlar vazgeçilmez olan reranker'ın marjinal değeri düşebilir. Bu yüzden reranker ROI'si tek seferlik bir hesap değil, sistemin evrimiyle birlikte periyodik olarak yeniden değerlendirilen bir karardır. Bir kez "gerekli" veya "gereksiz" demek yerine, bu kararı sisteminizin büyüme eğrisine göre düzenli aralıklarla gözden geçirmek, kaynağı her zaman gerçek darboğaza yönlendirmenizi sağlar. Reranker gibi bir katmanın değeri, statik değil bağlamsaldır ve bağlam değiştikçe karar da güncellenmelidir.

Reranker'lı bir hattın en kritik ama en çok göz ardı edilen ayarı, ilk-aşamadan kaç aday çekileceğidir. Bu tek parametre — aday sayısı, sıklıkla "k" olarak anılır — hem retrieval kalitesini hem de reranker'ın maliyetini doğrudan belirler. Yanlış ayarlandığında, en iyi reranker bile ya körelir ya da gereksiz yavaşlar. Bu bölümde bu dengenin nasıl kurulacağını ele alıyoruz.

Neden Aday Sayısı Bu Kadar Önemli?

Reranker yalnızca kendisine verilen adaylar arasından seçim yapabildiği için, ilk-aşama aday sayısı reranker'ın tavanını belirler. Eğer ilk-aşamadan yalnızca 5 aday çekiyorsanız ve doğru parça 12. sıradaysa, reranker o parçayı hiç görmez ve yeniden sıralayamaz — çünkü aday listesine hiç girmemiştir. Bu durumda reranker mükemmel çalışsa bile doğru cevap üretilemez. Yani dar bir aday penceresi, reranker'ın değerini baştan sınırlar.

Öte yandan, aday sayısını gereğinden çok geniş tutmak da bedelsiz değildir. Cross-encoder her aday için ayrı bir çıkarım yaptığından, aday sayısını iki katına çıkarmak reranker maliyetini kabaca iki katına çıkarır. 200 aday çekmek recall'ı marjinal artırabilir ama gecikmeyi ve maliyeti belirgin şişirir. Bu yüzden doğru aday sayısı, recall'ı doyuran ama gereksiz maliyet eklemeyen bir denge noktasıdır.

Doğru Aday Sayısı Nasıl Bulunur?

Doğru aday sayısını bulmanın yolu — şaşırtıcı olmayan biçimde — benchmark'tır. İlk-aşama recall@k'yi farklı k değerleri için ölçün: recall, k arttıkça bir noktaya kadar yükselir, sonra doygunluğa ulaşır. Doygunluğun başladığı k, iyi bir aday sayısı adayıdır; ondan sonra daha fazla aday çekmek recall'a çok az katkı verirken maliyeti artırır. Örneğin recall@50 ile recall@100 arasında kayda değer bir fark yoksa, 50 aday muhtemelen yeterlidir.

Bu ölçüm, reranker kararının neden ilk-aşama ile birlikte düşünülmesi gerektiğini bir kez daha gösterir. Reranker'ı eklemeden önce ilk-aşamanın recall eğrisini bilmek, hem doğru aday sayısını hem de reranker'ın potansiyel değerini ortaya koyar. Recall eğrisi düşük ve düz kalıyorsa, sorun ilk-aşamadadır ve önce hybrid search ile recall'ı yükseltmek gerekir; recall eğrisi yüksek ama sıralama kötüyse, reranker tam da bu boşluğu doldurur.

Seçilen Parça Sayısı (top-n) Ayrı Bir Karardır

Aday sayısı (reranker'a giren) ile seçilen parça sayısı (reranker'dan çıkıp modele giden) iki ayrı parametredir ve karıştırılmamalıdır. Reranker 50 adayı puanlayıp bunlardan en iyi 4'ünü seçebilir. Bu "top-n" sayısı, bağlam bütçesi ve gürültü arasında bir denge kurar: çok az parça kritik bağlamı dışarıda bırakabilir, çok fazla parça modelin dikkatini dağıtır ve token maliyetini artırır. En doğru top-n de yine benchmark ile, yanıt doğruluğuna bakılarak bulunur. Genellikle reranker'ın gücü, modele az sayıda ama yüksek nitelikli parça göndermeyi mümkün kılmasıdır.

Reranker kararının temel mantığı her yerde aynı olsa da, farklı sektörler bu kararı farklı ağırlıklarla verir; çünkü her sektörün belge yapısı, doğruluk hassasiyeti ve gecikme toleransı farklıdır. Aşağıdaki örnekler illüstratiftir ve her kurumun kendi benchmark'ı ile doğrulanmalıdır; amaç, reranker ihtiyacının bağlama göre nasıl değiştiğini göstermektir.

Hukuk ve uyum alanında reranker genellikle yüksek değerlidir. Bir hukuk bilgi tabanında çok sayıda benzer madde, fıkra ve içtihat bulunur; doğru maddeyi bunların arasından öne çıkarmak, tam da reranker'ın parladığı "benzer belge çokluğu" senaryosudur. Ayrıca yanlış bir maddeye dayanan yanıtın maliyeti çok yüksektir, bu yüzden reranker'ın sağladığı ek precision, gecikme maliyetine fazlasıyla değer. Burada retrieval kalitesi, doğrudan hukuki doğruluğa dönüşür.

Finans ve bankacılıkta reranker ihtiyacı sorgu tipine göre değişir. Ürün kodları, mevzuat maddeleri ve kesin terimler için hybrid search çoğu zaman ilk-aşamada zaten yüksek isabet sağlar; ama karmaşık, çok yönlü sorularda (örneğin farklı ürünlerin koşullarını karşılaştıran sorular) reranker sıralamayı belirgin iyileştirir. Ayrıca denetlenebilirlik gereği, reranker skorlarının loglanması bu sektörde ek değer taşır. Müşteri hizmetlerinde ise öne çıkan boyut gecikmedir: yüksek hacimli, gerçek zamanlı sorgular altında reranker'ın eklediği milisaniyeler dikkatle yönetilmeli; seçici tetikleme ve önbellekleme burada özellikle değerlidir.

İç bilgi yönetiminde (çalışanların dokümantasyona soru sorması) reranker ihtiyacı bilgi tabanının boyutuyla ölçeklenir. Küçük ve iyi yapılandırılmış bir dokümantasyonda ilk-aşama zaten yeterli olabilir; ama binlerce belgeye ulaşan, birbirine benzer içerikli büyük bir bilgi tabanında reranker retrieval kalitesini belirgin yükseltir. Tüm bu senaryolarda ortak ders şudur: reranker ihtiyacı evrensel bir kural değil, sektörün belge yapısına, doğruluk hassasiyetine ve gecikme toleransına göre kalibre edilen bir karardır. Aynı teknik katman, farklı sektörlerde farklı ağırlık taşır.

Reranker'ı yalnızca tek seferlik bir arama katmanı olarak düşünmek, giderek eksik bir bakış haline geliyor. Modern RAG sistemleri, tek bir getirme-üretme adımından çok adımlı, ajan-tabanlı akışlara doğru evriliyor; ve reranker bu akışlarda daha da kritik bir rol üstleniyor. Ajan mimarilerinin temeli için agentic AI nedir yazısına bakabilirsiniz.

Çok adımlı retrieval'da, bir ajan tek bir soruyu birden çok alt sorguya bölebilir, her alt sorgu için ayrı arama yapabilir ve sonuçları birleştirebilir. Bu senaryoda her alt sorgunun kendi aday kümesi oluşur ve bu kümelerin birleştirilip sıralanması gerekir; reranker, bu farklı kaynaklardan gelen adayları tek bir tutarlı alaka ölçütüyle yeniden sıralamak için idealdir. Farklı sorgulardan gelen parçaları ortak bir soruya karşı puanlamak, tam olarak cross-encoder'ın yaptığı iştir.

Ajan-tabanlı akışlarda reranker'ın ikinci bir rolü, adımlar arası kalite kapısı olmaktır. Bir ajan, getirdiği bağlamın yeterince iyi olup olmadığına karar verip gerekirse yeniden arama yapabilir; reranker'ın verdiği alaka puanları, bu "bağlam yeterli mi?" kararı için sinyal sağlar. Eğer en yüksek reranker puanı bile düşükse, ajan "iyi bir cevap bulamadım, sorguyu yeniden yazayım veya başka kaynağa bakayım" diyebilir. Bu, reranker'ı yalnızca bir sıralama aracından, bir karar sinyaline dönüştürür.

Ancak çok adımlı retrieval'da reranker'ın maliyeti de katlanır: her adımda yeniden sıralama, toplam gecikmeyi ve maliyeti artırır. Bu yüzden ajan-tabanlı bir RAG sisteminde reranker'ı ne zaman ve kaç kez çağıracağınızı bilinçli tasarlamak gerekir. Her alt adımda tam bir reranker koşmak yerine, yalnızca kritik birleştirme noktalarında reranker kullanmak, maliyet ile kalite arasında bir denge kurar. Bir AI agent'ın nasıl kurulduğunu AI agent nedir yazısında ele alıyoruz. Burada da ilke aynıdır: reranker güçlü bir araçtır ama her yere serpiştirilmemeli, değer kattığı noktalarda ölçülerek kullanılmalıdır.

Reranker kararını tam olarak kavramanın en iyi yolu, somut ve illüstratif bir senaryoyu adım adım izlemektir. Aşağıdaki örnek varsayımsaldır ve gerçek sayılar içermez; amacı, bir ekibin "reranker gerekli mi" sorusunu nasıl yanıtladığını göstermektir. Kendi sisteminizde bu yolculuğu kendi verinizle tekrarlamalısınız.

Bir sigorta şirketinin iç destek ekibi, poliçe dokümantasyonu üzerinde bir RAG asistanı kurmuş olsun. Kullanıcılar "X poliçesinde deprem hasarı kapsam dışı mı?" gibi sorular soruyor ama asistan sık sık yanlış poliçenin maddesine dayanan cevaplar veriyor. Ekip önce panik yapıp "daha güçlü bir model kullanalım" diye düşünüyor; ama doğru mühendislik refleksi, önce hattı ölçmek oluyor. Küçük bir altın küme hazırlıyorlar: 50 gerçek soru ve her biri için doğru poliçe maddesini işaretliyorlar.

İlk ölçüm çarpıcı: doğru madde, vakaların çoğunda ilk-aşama aday listesine (ilk 50) giriyor — yani recall yüksek. Ama doğru madde çoğu zaman 6. ile 15. sıralar arasında kalıyor; ilk-aşama bi-encoder, birbirine çok benzeyen poliçe maddeleri arasında ince ayrımı yapamıyor. Bu tam olarak reranker'ın altın senaryosu: "getirildi ama gömüldü." Ekip, bir cross-encoder reranker'ı hatta ekleyip aynı altın kümeyle yeniden ölçüyor. Sonuç: doğru madde artık çoğu vakada ilk 3 içinde geliyor, nDCG ve MRR belirgin yükseliyor ve uçtan uca yanıt doğruluğu iyileşiyor.

Ama ekip burada durmuyor; maliyeti de ölçüyor. Reranker, sorgu başına bir miktar gecikme ekliyor. Bu gecikme, bir iç destek aracı için kabul edilebilir sınırlarda kalıyor — kullanıcılar birkaç yüz milisaniyelik farkı fark etmiyor bile. Karar nettir: bu sistemde, bu veride, bu gecikme bütçesinde reranker net değer katıyor ve üretime alınıyor. Kritik nokta şudur: aynı ekip, farklı bir sistemde (örneğin ilk-aşamanın zaten çok isabetli olduğu küçük bir SSS asistanında) aynı ölçümü yapıp reranker'ın değer katmadığını görseydi, onu eklemezdi. Karar, dogmadan değil, ölçümden geldi — ve reranker sorusunun tek doğru yanıtlanma biçimi budur.

Reranker'ı kullanmaya karar verdikten sonra, hangi reranker modelini seçeceğiniz ayrı bir karardır. Piyasada açık kaynak ve ticari birçok seçenek vardır ve doğru seçim, ürün adından çok gereksinimlerinize bağlıdır. Aşağıdaki sorular, bir reranker modelini değerlendirirken sormanız gereken temel kriterleri özetler; hepsinin cevabı, sonunda kendi benchmark'ınızla doğrulanmalıdır.

Birinci soru dil kapsamıdır: model Türkçeyi ne kadar iyi destekliyor? Türkçe ağırlıklı bir bilgi tabanı için çok dilli veya Türkçeye özel eğitilmiş bir reranker şarttır; yalnızca İngilizce bir model, alakayı yanlış puanlayabilir. İkinci soru dağıtım modelidir: reranker bir API üzerinden mi çalışacak, yoksa kendi altyapınızda açık kaynak olarak mı barınacak? API kolaydır ama veri dışarı çıkar ve hacimle maliyet büyür; kendi barındırma veri egemenliği sağlar ama operasyon yükü getirir. Bu seçim, KVKK ve maliyet açısından önemlidir.

Üçüncü soru gecikme profilidir: modelin bir aday kümesini yeniden sıralaması ne kadar sürüyor ve bu, gecikme bütçenize sığıyor mu? Dördüncü soru bağlam uzunluğudur: reranker, uzun belge parçalarını değerlendirebiliyor mu, yoksa girdiyi kısaltmak zorunda mı kalıyor? Uzun parçalarla çalışıyorsanız, modelin işleyebileceği maksimum girdi uzunluğu kritik olur. Beşinci soru maliyet ölçeklenmesidir: sorgu hacminiz büyüdükçe reranker maliyeti nasıl davranıyor? Bir reranker'ın küçük ölçekte makul olan maliyeti, yüksek hacimde sürdürülemez hale gelebilir.

Bu soruların ortak dersi şudur: reranker modeli seçimi bir "en iyi model" arayışı değil, bir uygunluk değerlendirmesidir. Sizin diliniz, veriniz, gecikme bütçeniz ve maliyet kısıtınız için en uygun model, bir başka kurum için en uygun olandan farklı olabilir. Bu yüzden birkaç aday modeli aynı Türkçe altın küme üzerinde benchmark etmek, teorik karşılaştırmalardan çok daha güvenilir bir karar verdirir.

Reranker'ı bir kez kurup unutmak, bir RAG sisteminin sessizce bozulmasına yol açan yaygın bir hatadır. Bilgi tabanı büyür, kullanıcı soruları evrilir, yeni belge türleri eklenir; bu değişiklikler, bir zamanlar iyi çalışan reranker yapılandırmasının zamanla optimal olmaktan çıkmasına neden olabilir. Bu yüzden reranker, bir kez alınan bir karar değil, sürekli izlenip iyileştirilen bir katman olarak yönetilmelidir.

Sürekli iyileştirme döngüsünün ilk adımı izlemedir. Üretimde reranker skorlarını, seçilen parçaları ve uçtan uca yanıt kalitesini loglamak, sistemin gerçek davranışını görünür kılar. Özellikle değerli olan, düşük reranker puanıyla sonuçlanan sorgulardır: bunlar, sistemin iyi bir bağlam bulamadığı durumları işaret eder ve hem chunking/retrieval iyileştirmeleri hem de altın kümeyi büyütmek için doğrudan girdi sağlar. Başarısız sorgular, bir reranker sisteminin en değerli geri bildirim kaynağıdır.

İkinci adım, altın kümeyi yaşayan bir varlık olarak büyütmektir. Üretimde ortaya çıkan zor ve başarısız sorular düzenli olarak altın kümeye eklenmeli, bilgi tabanı değiştikçe işaretlemeler güncellenmelidir. Zamanla zorlaşan bir altın küme, reranker'ın gerçek dünya karmaşıklığına karşı ne kadar dayandığını daha iyi ölçer. Üçüncü adım, düzenli yeniden benchmark'tır: model sürümleri, aday sayısı veya top-n gibi parametreler değiştiğinde, aynı altın küme üzerinde bir regresyon testi çalıştırmak, bir değişikliğin kaliteyi bozup bozmadığını erken yakalar.

Bu döngü, reranker kararını statik bir "var/yok" sorusundan, dinamik bir kalite yönetimi pratiğine dönüştürür. En olgun ekipler, reranker'ı retrieval kalitesinin sürekli iyileştirildiği daha geniş bir LLMOps disiplininin parçası olarak görür. Bir RAG sisteminin uzun vadeli başarısı, tek bir doğru reranker seçiminden çok, bu ölçme-öğrenme-iyileştirme döngüsünü kurumsal bir alışkanlık haline getirmekten gelir. Reranker, bu döngü içinde sürekli kanıtını yeniden veren bir katman olduğunda gerçek değerini üretir.

Reranker gerçekten gerekli mi?

Duruma bağlıdır. Reranker, ilk-aşama retrieval'ın getirdiği adayları yeniden sıralayarak en alakalıları öne alır ve modele giden bağlamın kalitesini yükseltir. Doğru parça aday listesine giriyor ama üstte gelmiyorsa, bilgi tabanında birbirine benzer çok sayıda belge varsa ve yanlış yanıtın maliyeti yüksekse reranker belirgin değer katar. Buna karşılık ilk-aşama getirme zaten yüksek isabetliyse, gecikme bütçesi çok darsa veya sorgular basit ve tekilse reranker gereksiz olabilir. En doğru cevap, kendi verinizle bir benchmark kurup reranker'lı ve reranker'sız hatları karşılaştırmaktır; varsayım değil, ölçüm karar verir.

Bi-encoder ile cross-encoder arasındaki fark nedir?

Bi-encoder, soruyu ve belgeyi ayrı ayrı bir vektöre gömer ve bu iki vektörün yakınlığına bakar; hızlıdır çünkü belge vektörleri önceden hesaplanıp indekslenebilir, bu yüzden ilk-aşama retrieval için idealdir. Cross-encoder ise soruyu ve belgeyi birlikte, tek bir girdi olarak modele verir ve aralarındaki alakayı doğrudan puanlar; çok daha isabetlidir ama her aday için ayrı bir çıkarım gerektirdiğinden yavaştır. Reranker'lar tipik olarak cross-encoder mantığıyla çalışır. Bu yüzden mimari, bi-encoder ile geniş ve hızlı bir aday kümesi getirip, cross-encoder ile bu küçük kümeyi yeniden sıralamaya dayanır.

Reranker recall'ı mı yoksa precision'ı mı iyileştirir?

Reranker temelde precision'ı ve sıralama kalitesini iyileştirir, recall'ı değil. Recall, doğru parçanın aday listesine hiç girip girmediğiyle ilgilidir ve bu ilk-aşama retrieval'ın işidir; reranker aday listesinde olmayan bir parçayı yaratamaz. Reranker'ın yaptığı, zaten listede olan doğru parçayı en üste çıkarmak ve alakasızları geriye atmaktır. Bu yüzden reranker eklemeden önce ilk-aşama getirmenin recall'ı yeterli olmalıdır; recall düşükse önce hybrid search, daha iyi embedding veya daha geniş aday sayısı gibi recall'ı artıran adımlara bakmak gerekir. Reranker, iyi bir recall'ın üzerine kurulan bir katmandır.

Reranker'ı nasıl benchmark ederim?

Reranker'ı benchmark etmenin sağlıklı yolu, kendi verinizden türetilmiş bir altın küme kurmaktır: her test sorusu için hangi belge parçalarının doğru cevabı içerdiği işaretlenir. Sonra iki hat kurulur — biri reranker'sız, biri reranker'lı — ve aynı sorularla çalıştırılır. Retrieval katmanında recall, nDCG ve MRR gibi metrikler; uçtan uca katmanda ise yanıt doğruluğu ve bağlılık ölçülür. Ayrıca gecikme ve maliyet farkı kaydedilir. Kararı bu üç eksenin toplamı belirler: reranker retrieval kalitesini ve yanıt doğruluğunu ne kadar artırıyor, karşılığında ne kadar gecikme ve maliyet ekliyor? Bu ölçümler illüstratiftir; gerçek sayılar yalnızca sizin verinizle ortaya çıkar.

Reranker gecikmeyi ne kadar artırır?

Bu tamamen aday sayısına, reranker modelinin boyutuna ve nerede çalıştığına bağlıdır; tek bir evrensel sayı yoktur. Genel ilke şudur: cross-encoder her aday için ayrı bir çıkarım yaptığından, 100 adayı yeniden sıralamak 20 adayı yeniden sıralamaktan kabaca beş kat daha pahalıdır. Gecikmeyi yönetmenin yolları arasında aday sayısını makul tutmak, daha küçük veya damıtılmış bir reranker modeli seçmek, popüler sorgular için önbellek kullanmak ve reranker'ı yalnızca belirsiz sorgularda seçici olarak tetiklemek yer alır. Gecikme bütçeniz katıysa, reranker'ı eklemeden önce onun getirdiği kalite kazancının bu gecikmeye değip değmediğini benchmark ile doğrulamalısınız.

Reranker yerine hybrid search yeterli olur mu?

Bazı senaryolarda evet. Hybrid search, anlamsal (dense) ve anahtar kelime (sparse) aramayı birleştirerek ilk-aşama recall'ını ve retrieval kalitesini belirgin biçimde artırır; bu, doğru parçanın aday listesine girme olasılığını yükseltir. Eğer sorununuz doğru parça hiç getirilemiyor ise, çözüm reranker değil hybrid search olabilir. Ama sorununuz doğru parça getiriliyor ama sıralaması kötü ise, hybrid search tek başına yetmez ve reranker devreye girer. İkisi rakip değil tamamlayıcıdır: olgun bir hat çoğu zaman hybrid search ile geniş ve isabetli bir aday kümesi getirir, sonra reranker ile bu kümeyi keskinleştirir.

Reranker halüsinasyonu azaltır mı?

Dolaylı olarak azaltmaya yardımcı olabilir ama tek başına bir halüsinasyon çözümü değildir. Reranker, modele giden bağlamın sinyal-gürültü oranını yükseltir; alakasız parçalar geriye atıldığında, model yanlış bir parçaya dayanıp uydurma bir cevap üretme olasılığını düşürür. Ayrıca daha az ama daha nitelikli parça göndererek bağlam içinde kaybolma etkisini azaltır. Ancak reranker, doğru parça hiç getirilmediyse veya prompt katmanı modeli bağlama sadık kalmaya zorlamıyorsa halüsinasyonu önleyemez. Halüsinasyon azaltma; iyi retrieval, reranker, sağlam bir sistem promptu ve bağlılık ölçümünün birlikte çalıştığı bir disiplindir.

Reranker türleri nelerdir?

Pratikte birkaç ana yaklaşım vardır. En yaygını cross-encoder reranker'lardır: soru ve belgeyi birlikte değerlendirip tek bir alaka puanı üretirler; isabetli ama görece yavaştırlar. İkinci bir aile, geç etkileşimli (late-interaction) çok-vektörlü modellerdir; token düzeyinde eşleşme yaparak isabet ile hız arasında bir denge kurarlar. Üçüncü ve giderek yaygınlaşan yaklaşım, bir büyük dil modelini reranker olarak kullanmaktır (LLM-as-reranker): model, adayları alaka düzeyine göre sıralamaya veya puanlamaya yönlendirilir; esnektir ama maliyetli ve yavaş olabilir. Doğru seçim, isabet, gecikme ve maliyet ödünleşiminize göre yapılır ve yine benchmark ile doğrulanmalıdır.

Reranker'ı üretim mimarisinde nereye koymalıyım?

Reranker, ilk-aşama retrieval ile prompt kurma adımının arasına konumlanır. Akış şöyledir: kullanıcı sorusu gelir, ilk-aşama retrieval (dense, sparse veya hybrid search) geniş bir aday kümesi getirir (örneğin ilk 50-100 parça), reranker bu adayları yeniden sıralar ve en alakalı birkaçını seçer (örneğin ilk 3-8 parça), bu seçilen parçalar prompt'a yerleştirilir ve dil modeli yanıtı üretir. Bu iki aşamalı tasarım — geniş ve hızlı ilk-aşama, ardından dar ve isabetli yeniden sıralama — reranker'ın maliyetini yalnızca küçük aday kümesiyle sınırlar. Gözlemlenebilirlik için her adayın reranker puanı loglanmalı; böylece bir yanıt yanlış olduğunda hatanın retrieval'da mı yoksa yeniden sıralamada mı olduğu görülebilir.

KVKK ve Türkçe bağlamında reranker seçerken nelere dikkat etmeliyim?

İki boyut öne çıkar. Birincisi dil kalitesi: reranker modelinin Türkçeyi iyi anlaması gerekir; yalnızca İngilizce için eğitilmiş bir model, Türkçe soru-belge çiftlerinde alakayı zayıf puanlayabilir, bu yüzden çok dilli bir reranker tercih edilmeli ve Türkçe altın küme ile benchmark edilmelidir. İkincisi veri egemenliği: reranker bir API üzerinden çalışıyorsa soru ve belge içeriği dışarı çıkar; kişisel veya gizli veri söz konusuysa bu, KVKK açısından değerlendirilmelidir. Kendi altyapınızda barındırılan açık kaynak bir reranker, veriyi kurum içinde tutmayı sağlar ama operasyon yükü getirir. Bu bir hukuki tavsiye değildir; kurumunuzun hukuk ve uyum birimiyle birlikte değerlendirmelisiniz.

Reranker ile fine-tuning arasında nasıl seçim yaparım?

İkisi farklı problemleri çözer ve genellikle rakip değildir. Reranker, retrieval kalitesini artırır — doğru parçaların modele daha iyi sıralanmış biçimde ulaşmasını sağlar. Fine-tuning ise modelin davranışını, tonunu veya bir alandaki üslubunu değiştirir. Sorun "model doğru bağlamı alıyor ama yanlış biçimde yanıtlıyor" ise fine-tuning; sorun "modele giden bağlam gürültülü, doğru parça gömülüyor" ise reranker uygundur. Retrieval sorununu fine-tuning ile çözmeye çalışmak pahalı ve yanlış hedeflidir. RAG ve fine-tuning arasındaki genel seçimi RAG mi fine-tuning mi yazısında ele alıyoruz.

Kısaca, reranker gerçekten gerekli mi sorusunun cevabı: bazen kesinlikle evet, bazen hayır — ve hangisinin doğru olduğunu ancak kendi verinizle ölçerek bilirsiniz. Reranker, ilk-aşama retrieval'ın getirdiği adayları soruyla gerçek alaka düzeyine göre yeniden sıralayan, recall'ı değil precision'ı iyileştiren bir cross-encoder katmanıdır. Doğru parça aday listesine girip üste çıkamadığında, benzer belge çok olduğunda ve yanlış yanıtın maliyeti yüksek olduğunda belirgin değer katar; ilk-aşama zaten isabetliyse, gecikme bütçesi darsa veya asıl sorun düşük recall ya da kötü chunking ise gereksiz hatta zararlı olabilir.

En önemli mesaj şudur: reranker bir varsayılan değil, bir mühendislik kararıdır. Onu "herkes kullanıyor" diye körlemesine eklemek de, "karmaşık" diye peşinen reddetmek de yanlıştır. Doğru yaklaşım, hattı bir bütün olarak düşünmek (chunking, embedding, hybrid search, reranker), alternatifleri tartmak ve nihai kararı kendi verinizle kurulan bir benchmark ile — recall, nDCG ve uçtan uca yanıt doğruluğu açısından — vermektir. Temel kavramlar için reranker nedir, RAG nedir ve embedding nedir yazılarına bakabilir; kurumunuza özel bir RAG hattı ve retrieval kalitesi kurmak için yapay zeka danışmanlığı ile başlayabilir, ekibinizin yetkinliğini geliştirmek için kurumsal eğitim seçeneklerine göz atabilir ve kavramları derinleştirmek için öğrenme merkezini kullanabilirsiniz.