
Teknik not
Yapay Zekâda RAG Reranking: Arama Sonuçlarını İyileştirme Rehberi

Bir RAG uygulamasında doğru cevabı üretmenin ilk şartı, modele doğru bağlamı vermektir. Ancak vektör aramasıyla bulunan ilk sonuçlar her zaman en yararlı parçalar olmayabilir. Benzer kelimeler içeren bir belge üst sıralara çıkarken, soruya doğrudan cevap veren başka bir parça geride kalabilir. RAG reranking, ilk aramadan gelen aday parçaları ikinci bir değerlendirmeden geçirip sorguya en alakalı olanları öne çıkarır.

Bu rehberde RAG reranking nedir, embedding aramasından farkı nasıl anlaşılır, aday belge sayısı ve top-k nasıl seçilir, kalite nasıl ölçülür sorularını adım adım ele alacağım. Konu; destek botu, kurum içi arama, teknik dokümantasyon ve Türkçe soru-cevap sistemleri geliştiren ekipler için özellikle değerlidir.
RAG reranking nedir?
RAG reranking, bir arama sisteminin döndürdüğü aday belgeleri veya metin parçalarını kullanıcı sorgusuna göre yeniden sıralama işlemidir. İlk aşamada hızlı bir lexical, vector veya hybrid search yapılır. İkinci aşamada reranker, sorgu ile her aday parçayı birlikte değerlendirir ve alaka derecesine göre yeni bir sıralama üretir. Son olarak yalnızca en güçlü parçalar cevap üretmesi için LLM’e gönderilir.
Bu nedenle reranking, arama sisteminin yerine geçen tek başına bir yöntem değildir. Daha çok iki aşamalı retrieval mimarisinin kalite filtresidir. İlk arama geniş bir aday havuzu oluşturur; reranker bu havuzdaki parçalar arasından soruya gerçekten hizmet edenleri seçmeye çalışır.
Embedding araması ile reranking arasındaki fark
| Aşama | Amaç | Öne çıkan özellik |
|---|---|---|
| İlk arama | Geniş aday havuzu bulmak | Hızlı, yüksek hacimli, vector veya keyword tabanlı |
| Reranking | Adayları sorguya göre hassas sıralamak | Daha derin alaka değerlendirmesi, daha yüksek işlem maliyeti |
| Bağlam seçimi | LLM’e gidecek parçaları belirlemek | Token bütçesi ve cevap kalitesi arasında denge |
Embedding araması, sorgu ile belgeyi vektör uzayında karşılaştırarak hızlı benzerlik bulur. Reranker ise çoğu kullanımda sorgunun ve belgenin birlikte okunmasına dayalı daha ayrıntılı bir alaka değerlendirmesi yapar. Bu iki yöntemi art arda kullanmak, geniş aramanın hızını ve ikinci aşamanın seçiciliğini aynı akışta birleştirir.
RAG reranking pipeline’ı nasıl çalışır?
1. Kullanıcı sorgusunu normalize edin
Yazım hatalarını düzeltmek, gereksiz oturum bilgisini ayırmak ve gerekiyorsa konuşma geçmişinden bağımsız bir arama sorgusu üretmek ilk adımdır. Kullanıcının “Peki bunun iade süresi ne?” gibi kısa bir takip sorusu varsa, arama için önceki mesajlarla anlamlı bir sorgu oluşturun. Bu işlemi cevabın kendisiyle karıştırmayın; amaç yalnızca retrieval sorgusunu iyileştirmektir.
2. Geniş aday havuzu getirin
İlk aramada yalnızca cevapta kullanacağınız kadar parça istemek yerine daha geniş bir aday kümesi alın. Örneğin 3 parça yerine 20 aday getirip bunları reranker’a göndermek, ikinci aşamaya seçim yapacak alan bırakır. İdeal sayı sabit değildir; corpus büyüklüğü, sorgu tipi, gecikme hedefi ve reranker limitleriyle birlikte test edilmelidir.
3. Aday parçaları zengin metadata ile taşıyın
Her parçanın metninin yanında belge başlığı, bölüm adı, ürün veya sürüm bilgisi, yayın tarihi ve erişim etiketi gibi metadata bulunabilir. Reranker’a yalnızca anlamsız bir metin kırıntısı göndermek yerine başlık ve bölüm bağlamını kontrollü biçimde eklemek alaka kararını kolaylaştırabilir. Ancak aynı bilgiyi her parçada tekrar ederek token maliyetini gereksiz büyütmeyin.
4. Reranker ile yeniden sıralayın
Reranker girdisi genellikle bir sorgu ve aday belgeler listesinden oluşur. Her aday için alaka skoru veya sıralama sonucu döner. Sonuçları skor azalan şekilde sıralayın ve uygulamanızın bağlam bütçesine sığan en iyi parçaları seçin. Sağlayıcıya göre alan adları ve model seçenekleri değişebilir; bu yüzden kullandığınız servisin güncel API sözleşmesini takip edin.
5. Eşik ve top-k kuralını uygulayın
En yüksek skorlu parçaları almak her zaman yeterli değildir. Çok düşük skorlu adaylar soruyla ilgisiz olabilir. Bu nedenle sabit bir top-k değerine ek olarak bir alaka eşiği deneyebilirsiniz. Eşik değerlerini farklı reranker modelleri arasında doğrudan taşımayın; skorların anlamı ve dağılımı modele göre değişebilir. Kararı gerçek test setinde gözlemleyin.
6. Seçilen bağlamı LLM’e gönderin
Reranking sonucundan kalan parçaları kaynak bilgisiyle birlikte cevap promptuna ekleyin. Prompt, modelden yalnızca verilen bağlama dayanmasını, kaynak yetersizse bunu açıkça belirtmesini ve parçalar arasındaki çelişkiyi işaretlemesini istemelidir. Reranker doğru parçayı seçse bile LLM’in bağlamı yanlış yorumlamasını tamamen engellemez.
Sağlayıcıdan bağımsız örnek akış
Aşağıdaki JSON, RAG reranking mantığını gösteren basitleştirilmiş bir şablondur. Gerçek API’de alan adlarını kullandığınız arama ve rerank servisinin formatına göre değiştirin:
{
"query": "Kullanılmamış ürün kaç gün içinde iade edilebilir?",
"candidates": [
{
"id": "doc-17-chunk-3",
"title": "İade Politikası",
"text": "Kullanılmamış ürünler teslimattan sonra 14 gün içinde iade edilebilir."
},
{
"id": "doc-42-chunk-8",
"title": "Kargo Takip",
"text": "Kargo durumunuzu sipariş numarasıyla takip edebilirsiniz."
}
],
"top_n": 1
}
Üretim akışında iki sonucu ayrı ayrı kaydedin: ilk aramanın sırası ve reranking sonrası sıra. Böylece bir parçanın ilk aşamada kaçıncı geldiğini, reranker’ın onu nereye taşıdığını ve son cevapta kullanılıp kullanılmadığını inceleyebilirsiniz.
Reranking ile hybrid search birlikte kullanılabilir mi?
Evet. Keyword search; ürün kodu, hata mesajı, sürüm numarası ve özel isimlerde güçlü olabilir. Vector search ise anlam bakımından benzer ifadeleri yakalamaya yardımcı olur. Hybrid search bu iki aday listesini birleştirir. Reranker ise birleşik havuzdaki parçaları aynı sorguya göre yeniden sıralayabilir.
Bu akışta dikkat edilmesi gereken nokta, aynı belgenin iki farklı arama yöntemiyle gelmesi ve aday havuzunu gereksiz doldurmasıdır. Belge kimliğine göre tekilleştirme yapın, farklı retrieval skorlarını doğrudan karşılaştırmak yerine reranker’ın ortak skorlamasını kullanın ve hangi kaynak türünün daha çok katkı sağladığını ölçün.
Türkçe ve çok dilli aramalarda nelere dikkat edilmeli?
Türkçe sorgular eklemeli yapı, yazım farklılıkları, ürün adları ve İngilizce teknik terimler içerebilir. Reranker seçerken desteklenen dilleri ve Türkçe test sonuçlarını kontrol edin. Sadece model açıklamasında “multilingual” yazması, sizin alanınızdaki özel terimlerde doğru sıralama yapacağı anlamına gelmez.
Test setinizde aynı niyeti farklı biçimlerde ifade eden sorular bulundurun: “iade süresi nedir?”, “ürünü geri göndermek için kaç günüm var?” ve “14 gün kuralı hangi ürünlerde geçerli?” gibi örnekler, yalnızca kelime eşleşmesine dayalı sistemlerin zayıf noktalarını gösterir. Yanlış yazılmış marka adları ve kodlar için keyword aramayı da koruyun.
RAG reranking kalitesi nasıl ölçülür?
Reranker’ı yalnızca son cevabın iyi görünüp görünmediğine göre değerlendirmeyin. Önce retrieval katmanını, sonra cevap katmanını ayrı ölçün. Küçük bir test setinde her soru için doğru belge veya doğru chunk kimliğini işaretleyebilirsiniz.
- Recall@k: Doğru parça ilk k sonuç içinde bulunuyor mu?
- MRR: Doğru parçanın sıralamadaki konumu ne kadar yukarıda?
- nDCG: Birden fazla alakalı parçanın sırası ne kadar kaliteli?
- Kaynağa bağlılık: LLM cevabı seçilen parçalarla destekleniyor mu?
- Cevap alaka düzeyi: Sonuç kullanıcı sorusunu gerçekten karşılıyor mu?
- Gecikme ve maliyet: İkinci aşamanın kalite kazanımı işlem yükünü hak ediyor mu?
Değerlendirme için aynı sorguları reranking kapalı ve açık şekilde çalıştırın. RAG kalitesini ölçmek için LLM evals rehberindeki test seti, rubric ve regresyon yaklaşımını retrieval metrikleriyle birleştirebilirsiniz.
RAG reranking’de sık yapılan hatalar
- Aday havuzunu çok dar tutmak: Doğru parça ilk aramada gelmiyorsa reranker onu sonradan üretemez.
- Belgeyi gereğinden fazla büyütmek: Uzun ve dağınık adaylar alaka kararını zorlaştırabilir; chunk kalitesini de iyileştirin.
- Skorları evrensel kabul etmek: Eşik değerleri modelden modele taşınmamalıdır.
- Kaynak metadata’sını yok saymak: Sürüm veya erişim bilgisi olmadan benzer ama yanlış belge seçilebilir.
- Sadece tek bir soru türüyle test etmek: Takip soruları, özel isimler, tarih filtreleri ve konu dışı istekleri ayrı dilimler halinde ölçün.
- Her sorguda reranking kullanmak: Çok kısa veya tek sonuçlu aramalarda ek maliyet kaliteye katkı sağlamayabilir.
- Reranker’ı güvenlik filtresi sanmak: Alaka sıralaması, prompt injection veya yetki kontrolünün yerine geçmez.
Ne zaman reranking kullanmalısınız?
İlk arama sonuçları sık sık birbirine benziyor ama doğru parçayı üst sıralara taşımakta zorlanıyorsa reranking güçlü bir adaydır. Özellikle aynı kelimeleri kullanan farklı ürün belgeleri, çok bölümlü teknik dokümanlar, uzun kurum içi wiki’ler ve Türkçe-İngilizce karışık içerikler için test etmeye değer.
Öte yandan çok küçük bir bilgi tabanında, tek bir filtreyle doğru belge bulunuyorsa ikinci aşama gereksiz gecikme ekleyebilir. Kararı varsayımla değil, aynı test setindeki Recall@k, cevap kalitesi, p95 gecikme ve maliyet karşılaştırmasıyla verin.
Uygulama kontrol listesi
- İlk retrieval katmanı yeterince geniş bir aday havuzu getiriyor mu?
- Aday parçalar başlık ve gerekli metadata ile birlikte mi taşınıyor?
- Reranker sorgu ile belgeyi birlikte değerlendiriyor mu?
- top-k ve alaka eşiği gerçek test setinde kalibre edildi mi?
- Keyword, vector veya hybrid aramanın katkısı ayrı ölçülüyor mu?
- Reranking açık ve kapalı akışın retrieval ve cevap metrikleri karşılaştırıldı mı?
- Türkçe, takip sorusu, sürüm numarası ve konu dışı istekler test edildi mi?
- Reranking katmanı güvenlik ve yetki kontrollerinden ayrı tutuluyor mu?
Sonuç
RAG reranking, ilk aramanın hızını korurken LLM’e giden bağlamın alaka kalitesini artırmayı hedefleyen ikinci aşama bir retrieval tekniğidir. En iyi sonuç; geniş ama yönetilebilir bir aday havuzu, kaliteli chunk’lar, doğru metadata, uygun top-k ve ölçülebilir eval testlerinin birlikte tasarlanmasıyla alınır.
Başlangıç için mevcut RAG akışınızın ilk 20 sonucunu kaydedin, doğru parçanın sırasını ölçün ve aynı havuzu bir reranker ile yeniden değerlendirin. Ardından yalnızca cevap kalitesini değil, Recall@k, p95 gecikme, token kullanımı ve maliyeti de karşılaştırın. Böylece reranking kararını sezgiyle değil, uygulamanızın gerçek verisiyle verebilirsiniz.
Kaynaklar: Cohere Rerank dokümantasyonu ve Reranking uygulama rehberi