RAG'de Hibrit Arama: BM25 + Vektör + Yeniden Sıralama ile Doğruluğu Yükseltmek

TL;DR — RAG (retrieval-augmented generation) sistemlerinde en sık gördüğüm sorun, tek bir arama yöntemine güvenmek. Saf vektör araması anlamı yakalar ama tam terim eşleşmesinde tökezler; BM25 anahtar kelimeyi bulur ama eş anlamlıyı kaçırır. Çözüm hibrit arama: BM25 (seyrek) ile vektör (yoğun) aramayı Reciprocal Rank Fusion (RRF) ile birleştirip üstüne bir cross-encoder yeniden sıralayıcı (reranker) koymak. Rakamlar net: WANDS e-ticaret kıyaslamasında ayarlı hibrit 0.7497 NDCG (BM25 tek başına 0.6983, saf vektör 0.6953); hibrit + Cohere Rerank saf-dense'e göre Recall@5'te %39 iyileşme sağlıyor. Bu yazıda mimariyi, RRF'nin nasıl çalıştığını, reranker'ın maliyet/gecikme dengesini, Türkçe için pratik ipuçlarını ve KVKK'lı kurum içi dağıtımı anlatıyorum. Hibrit aramayı her RAG projesi için "minimum uygulanabilir taban" olarak öneriyorum.

Kurumlarda RAG projelerine danışırken en çok karşılaştığım hayal kırıklığı şu cümleyle başlıyor: "Vektör veritabanı kurduk, embedding aldık, ama sistem hâlâ yanlış belgeleri getiriyor." Bunu o kadar çok duydum ki artık daha soru sorulmadan cevabı biliyorum. Sorun neredeyse her zaman, tek bir getirme (retrieval) yöntemine körü körüne güvenmekten kaynaklanıyor.

Meseleyi anlamak için iki farklı arama felsefesini ayırmamız lazım.

Seyrek (sparse) arama — BM25. Klasik anahtar kelime araması. Bir belgede aradığınız terimin tam olarak geçip geçmediğine, ne sıklıkta geçtiğine ve o terimin koleksiyonda ne kadar nadir olduğuna bakar. Ürün kodları, hukuki madde numaraları, özel isimler, kısaltmalar, hata kodları gibi tam eşleşme gerektiren durumlarda müthiş çalışır. "ABC-1234 model numarası" ararken BM25 tam isabet yapar. Ama "dizüstü bilgisayar" ile "laptop" arasındaki anlam köprüsünü kuramaz; kelime birebir geçmiyorsa göremez.

Yoğun (dense) arama — vektör embedding. Metni anlamsal bir uzaya gömer ve anlam benzerliğine bakar. "Otomobil sigortası nasıl yaptırılır" sorgusu, içinde bu kelimeler geçmese bile "araç poliçesi başvuru süreci" başlıklı bir belgeyi bulabilir. Eş anlamlılar, parafraz, kavramsal yakınlık burada güçlü. Ama tam terim eşleşmesinde, özellikle nadir özel terimlerde ve kodlarda zayıf kalır; embedding "yakın ama yanlış" bir şeye kayabilir.

"

BM25 kelimeyi bilir, vektör anlamı bilir. Gerçek dünya sorguları ise ikisini de aynı anda ister.

İşte hibrit aramanın tüm mantığı bu tek cümlede: iki yöntemin zayıflıkları birbirini tamamlıyor. BM25'in gözden kaçırdığı anlamsal eşleşmeyi vektör yakalıyor; vektörün kaçırdığı tam terimi BM25 yakalıyor. İkisini birleştirdiğinizde, tek başına hiçbirinin ulaşamadığı bir doğruluğa çıkıyorsunuz.

Ben rakama inanan bir insanım, "hissettim ki daha iyi" cümlesine değil. Neyse ki hibrit aramanın faydası ölçülmüş durumda.

WANDS adı verilen e-ticaret arama kıyaslamasında sonuçlar çok öğretici. NDCG (sıralama kalitesini ölçen metrik) değerlerine bakalım:

Yöntem	NDCG
Saf vektör (dense)	0.6953
Tek başına BM25	0.6983
Ayarlı hibrit (BM25 + vektör)	0.7497

Dikkat edin: saf vektör ve tek başına BM25 neredeyse başa baş. Yani "vektör her zaman daha iyidir" efsanesi burada çöküyor. Asıl sıçrama, ikisini birleştirince geliyor: ayarlı hibrit, tek yöntemlere göre yaklaşık %7.4'lük bir iyileşme sağlıyor. Bu, arama gibi bir alanda küçümsenecek bir fark değil.

Daha zorlu bir senaryoya, metin ve tabloların iç içe geçtiği finansal belgelere bakalım. Burada iki aşamalı hibrit getirme + nöral yeniden sıralama kombinasyonu Recall@5 = 0.816 değerine ulaşıyor. Yani ilgili belgelerin büyük çoğunluğu ilk beş sonuç içinde yakalanıyor; bu, LLM'e verilen bağlamın kalitesi açısından kritik.

Ama beni en çok etkileyen rakam reranker'ın kattığı değer. Hibrit aramaya bir Cohere Rerank katmanı eklendiğinde:

• Saf-dense aramaya kıyasla Recall@5'te %39 iyileşme,
• Hibrit RRF'ye kıyasla ise ek %17.4 iyileşme.

Bunu bir kez daha vurgulayayım: reranker eklemek, saf vektörle başladığınız noktaya göre neredeyse recall'unuzu bir buçuk katına çıkarıyor. Bir de RRF'nin tek başına, skor normalizasyonu bile olmadan yaklaşık %91 recall@10 verdiğini ekleyeyim. Yani füzyon adımı zaten çok ucuza ciddi bir kazanç sağlıyor.

Ben hibrit RAG'i her zaman üç net aşamada anlatırım. Kafanızda bu üç kutuyu netleştirirseniz, geri kalan her şey yerine oturur.

Aşama 1 — Getirme (Retrieval). Sorgu aynı anda iki motora gider: BM25 ve dense vektör araması. Her biri kendi mantığıyla, diyelim ki en iyi 50-100 belgeyi döndürür. Bu aşamada amaç yüksek recall; yani ilgili hiçbir belgeyi kaçırmamak. Kesinlik (precision) henüz önceliğimiz değil, çünkü sonraki aşamalar bunu düzeltecek. Geniş bir ağ atıyoruz.

Aşama 2 — Füzyon (Fusion / RRF). İki listeyi tek bir sıralamada birleştiririz. Burada Reciprocal Rank Fusion (RRF) devreye girer; birazdan formülünü açacağım. RRF'nin güzelliği, iki motorun skorlarını aynı ölçeğe getirmeye (normalizasyon) uğraşmadan, sadece sıralama (rank) bilgisini kullanmasıdır. BM25 skoru ile kosinüs benzerliği skorunu doğrudan toplamak elmayla armutu toplamaktır; RRF bu sorunu zarifçe atlar.

Aşama 3 — Yeniden Sıralama (Reranking). Füzyondan çıkan, diyelim ki en iyi 50 belgeyi bir cross-encoder reranker'a veririz. Bu model, sorgu ile her belgeyi birlikte (çift olarak) değerlendirir ve gerçek alaka skorunu üretir. Sonra bu skorla yeniden sıralayıp en iyi 5-10 belgeye kırparız (prune) ve sadece bunları LLM'in bağlam penceresine koyarız. Bu son kırpma, hem doğruluğu artırır hem de token maliyetini düşürür.

Bu mimariyi bir tabloyla özetleyeyim:

Aşama	Amaç	Öncelik	Tipik çıktı
1. Getirme (BM25 + dense)	Aday havuzu oluştur	Yüksek recall	50-100 belge
2. Füzyon (RRF)	İki listeyi birleştir	Sıra tutarlılığı	Tek sıralı liste
3. Yeniden sıralama	Gerçek alakayı ölç	Yüksek precision	En iyi 5-10 belge

Reciprocal Rank Fusion kulağa akademik geliyor ama aslında bir satırlık bir fikir. Her belge için, o belgenin her arama listesindeki sırasına bakarız ve şu katkıyı toplarız:

skor(belge) = toplam ( 1 / (k + rank) )

Buradaki "rank" belgenin ilgili listedeki sıra numarası (1, 2, 3...), "k" ise bir yumuşatma sabiti; pratikte genellikle 60 kullanılır. Bir belge kaç listede varsa, her listeden bu katkıyı alır ve toplam skoru oluşur.

Neden bu kadar iyi çalışıyor? Birkaç sebebi var:

• Skor normalizasyonu gerektirmez. BM25 skorları 0 ile 30 arasında, kosinüs benzerliği 0 ile 1 arasında olabilir; bunları toplamak anlamsız. RRF ham skoru değil, sadece sırayı kullandığı için bu sorun ortadan kalkar.
• Üst sıralara ağırlık verir. k=60 iken 1. sıradaki belge 1/61, 2. sıradaki 1/62 katkı alır; fark üstlerde daha belirgin. Yani her iki motorun da üst sıraya koyduğu belge doğal olarak öne çıkar.
• Dayanıklıdır. Bir motor tuhaf bir skor üretse bile, sistem çökmez; RRF aykırı skorlara karşı bağışıklıdır.

k sabitini büyütürseniz sıralar arası fark azalır (daha demokratik), küçültürseniz üst sıralar daha baskın olur. 60 iyi bir başlangıç; ama kendi verinizle deneyip ayarlamanızı öneririm. Bu "ayarlı hibrit" ile "ham hibrit" arasındaki farkın bir kısmı tam da buradan gelir.

Cross-encoder reranker, mimarinin en çok değer katan ama aynı zamanda en çok düşündürmesi gereken parçası. Neden bu kadar iyi? Çünkü çalışma prensibi temelden farklı.

Vektör araması "bi-encoder" mantığıyla çalışır: sorgu ve belge ayrı ayrı vektöre çevrilir, sonra karşılaştırılır. Hızlıdır çünkü belge vektörleri önceden hesaplanabilir. Ama sorgu ile belge birbirini "görmeden" kodlandığı için ince nüanslar kaybolur. Cross-encoder ise sorgu ve belgeyi birlikte, aynı anda modele verir; kelime kelime etkileşimi görür. Bu yüzden çok daha isabetli, ama çok daha yavaş; her sorgu-belge çifti için ayrı bir model çalışması gerekir.

İşte denge tam burada. Cross-encoder'ı tüm koleksiyona uygulayamazsınız; milyonlarca belgeyi tek tek skorlamak hem imkansız hem gereksiz. Bu yüzden onu sadece füzyondan çıkan küçük aday havuzuna (50 belge gibi) uygularsınız. Böylece hem cross-encoder'ın isabetini alırsınız hem de gecikmeyi (latency) kontrol altında tutarsınız.

Pratik önerilerim şunlar:

• Aday havuzunu makul tutun. 100 yerine 50 belgeye rerank uygulamak, gecikmeyi neredeyse yarıya indirirken doğruluğu genelde çok az düşürür. Kendi verinizle bu tatlı noktayı bulun.
• Bütçe/gecikme kritikse seçici olun. Her sorguya reranker şart değil; basit sorgularda RRF sonucu yeterli olabilir. Ama unutmayın, reranker'ın kattığı %17.4'lük iyileşme çoğu kurumsal senaryoda bu maliyete fazlasıyla değer.
• Yönetilen servis mi, açık kaynak mı? Cohere Rerank gibi yönetilen servisler hızlı başlamanızı sağlar; ama veri kurum dışına çıkacağı için KVKK açısından değerlendirmeniz gerekir. Açık kaynak cross-encoder'ları kendi sunucunuzda çalıştırmak, veri egemenliği isteyen kurumlar için daha güvenli.

Her projeye üç aşamayı birden dayatmam. Ölçekli düşünmek lazım. Ama şunu net söyleyeyim: hibrit aramayı, neredeyse her RAG dağıtımı için "minimum uygulanabilir taban" olarak görüyorum. Saf vektörle başlayıp sonra "neden çalışmıyor" diye dövünmektense, baştan BM25'i de eklemek çok daha akıllıca.

Hibrit + reranker'ın özellikle şart olduğu durumlar:

• Terminoloji yoğun alanlar: Hukuk, tıp, finans, mühendislik. Buralarda özel terimler, kod ve madde numaraları BM25'i vazgeçilmez kılar.
• Karışık içerik: Metin + tablo + kod içeren belgeler. Finansal belge örneğindeki 0.816 Recall@5 tam da bu tür karmaşıklıkta elde edildi.
• Yüksek doğruluk gereken senaryolar: Yanlış belgenin ciddi sonuç doğurduğu müşteri desteği, uyum, tıbbi bilgi gibi alanlar.

Buna karşılık, küçük ve homojen bir bilgi tabanınız varsa, sorgular basitse ve gecikme çok kritikse, belki sadece hibrit (reranker'sız) yeterli olur. Mühendislikte her şey bir denge; ama gördüğüm kadarıyla insanların çoğu hibrite geç geçtiği için pişman oluyor, erken geçtiği için değil.

Şimdi çoğu İngilizce kaynakta bulamayacağınız kısma geliyoruz: Türkçe. Türkçe sondan eklemeli (agglutinative) bir dil ve bu, hem BM25 hem de embedding tarafını doğrudan etkiliyor.

BM25 tarafında tokenizasyon ve gövdeleme kritik. "Ev", "evler", "evimizde", "evlerimizden" kelimeleri İngilizce mantığıyla ayrı token sayılırsa, BM25 bunları birbiriyle eşleştiremez ve tam terim eşleşmesi avantajınızı kaybedersiniz. Türkçe için gövdeleme (stemming) veya en azından kök bulma (lemmatization) yapan bir analizör kullanmalısınız. Elasticsearch/OpenSearch gibi motorlarda Türkçe analizör ve zemberek benzeri araçlar burada işinizi görür. Bunu ihmal ederseniz, BM25'in tüm gücü Türkçe'de sönük kalır.

Embedding modeli seçimi. Sadece İngilizce üzerine eğitilmiş bir embedding modeli, Türkçe'de anlamı zayıf yakalar. Çok dilli (multilingual) veya Türkçe'ye özel eğitilmiş bir embedding modeli seçin. Küçük bir doğrulama seti üzerinde birkaç modeli karşılaştırmadan üretime almayın; benim tecrübem, model seçiminin Türkçe'de sonucu İngilizce'den çok daha fazla etkilediği yönünde.

Karakter normalizasyonu. Türkçe'ye özgü "ı/İ" ve "i/I" büyük-küçük harf dönüşümü, klasik bir tuzak. Yanlış yapılandırılmış bir küçük harfe çevirme (lowercasing) "İstanbul" ile "istanbul"u eşleştiremez. Türkçe'ye duyarlı normalizasyon kullanın, yoksa hem BM25 hem eşleşme sessizce bozulur.

Kısacası Türkçe'de hibrit arama daha da kritik: gövdeleme sorunları BM25'i zorlarken, iyi bir Türkçe embedding vektör tarafını taşır; ikisini birleştirince tek başına hiçbirinin veremeyeceği bir dayanıklılık elde edersiniz.

Kurum içi doküman RAG'i kurarken en sık atlanan konu güvenlik ve KVKK. Doğruluğu kovalarken kişisel veriyi sızdırmak, çözdüğünüz problemden çok daha büyük bir problem yaratır. Sahadan birkaç ilke.

Erişim kontrolü getirme aşamasına gömülmeli. RAG sisteminiz, sorguyu yapan kullanıcının görmeye yetkili olmadığı belgeleri getirmemeli. Yani BM25 ve vektör aramasına, kullanıcının erişim izinlerine göre bir filtre (metadata filtreleme) eklemelisiniz. Aksi halde bir çalışan, sorusunun cevabında başka bir departmanın gizli belgesinden bir alıntı görebilir. Erişim kontrolünü LLM'e bırakmayın; getirme katmanında uygulayın.

PII maskeleme. İndekslediğiniz belgelerde kişisel veri (TC kimlik, telefon, adres, sağlık bilgisi) varsa, KVKK açısından bunları maskelemeyi veya en azından amaç sınırlaması ve erişim kısıtıyla yönetmeyi düşünün. Reranker'ı yönetilen bir dış servise gönderirken, o servise giden metinde açık PII olup olmadığını kontrol edin; veri sınır dışına çıkıyorsa aydınlatma ve hukuki dayanak gerekir.

Kayıt ve izlenebilirlik. Hangi sorgunun hangi belgeleri getirdiğini loglamak hem hata ayıklama hem de KVKK hesap verebilirliği için değerli. Ama logların kendisi de kişisel veri içerebilir; saklama sürelerini ve erişimini tanımlayın.

Katman	Doğruluk kaygısı	KVKK kaygısı
Getirme	Yüksek recall	Erişim izni filtresi
Füzyon (RRF)	Sıra tutarlılığı	(nötr)
Yeniden sıralama	Yüksek precision	Dış servise PII gönderimi
Bağlam kırpma	Token verimliliği	Minimum veri ilkesi

Hibrit aramadan bahsederken çoğu insan doğrudan BM25 ve vektöre atlar; ama arama kalitesini belki de en çok etkileyen karar, belgelerinizi nasıl parçaladığınız (chunking) kararıdır. Ne getirebileceğiniz, önce nasıl indekslediğinizle sınırlıdır. Kötü bir chunking stratejisiyle en gelişmiş reranker bile sizi kurtaramaz.

Sık gördüğüm hata, belgeleri kör bir şekilde sabit uzunlukta (örneğin her 500 kelimede bir) kesmek. Bu, cümleleri ortasından bölebilir, bir tabloyu başlığından koparabilir, bir maddeyi bağlamından ayırabilir. Sonuçta hem vektör embedding'i bulanıklaşır hem de BM25 için anlamlı birim kaybolur.

Benim önerilerim şunlar:

• Yapıya saygılı bölme. Mümkünse belgeyi başlık, paragraf, madde gibi doğal sınırlardan bölün. Markdown veya HTML yapısı varsa bunu kullanın; bir başlık ve altındaki paragraf aynı parçada kalsın.
• Örtüşme (overlap) bırakın. Ardışık parçalar arasında küçük bir örtüşme (birkaç cümle), sınırda kalan bilginin kaybolmasını önler.
• Tablolar için özel muamele. Finansal veya teknik belgelerde tabloyu düz metne ezmeyin; tablonun bağlamını (hangi başlık altında, hangi dönem) koruyacak şekilde işleyin. Metin+tablo senaryosundaki yüksek recall rakamları, tam da bu özenle elde ediliyor.
• Parça boyutunu göreve göre ayarlayın. Kısa, kesin cevaplar için küçük parçalar; kavramsal, geniş sorular için daha büyük parçalar daha iyi çalışır. Tek bir sihirli sayı yok; kendi verinizle deneyin.

Chunking'i bir kez ciddiye alıp düzeltmek, çoğu zaman yeni bir model denemekten daha büyük kazanç sağlar. Bunu bir ön-koşul olarak görün.

Hibrit mimaride enerjinin çoğu getirme sonrasına (füzyon, rerank) harcanır; ama getirmeden önce de kazanılacak çok şey var. Kullanıcının yazdığı ham sorgu, çoğu zaman aramanın ihtiyaç duyduğu ideal biçimde değildir.

Birkaç pratik teknik:

• Sorgu genişletme (query expansion). Kullanıcının sorgusuna eş anlamlıları veya ilgili terimleri ekleyerek BM25'in yakalama alanını genişletebilirsiniz. Türkçe'de bu özellikle işe yarar, çünkü aynı kavramın Türkçe ve yabancı karşılığı (örneğin "bilgisayar" ve "PC") belgelerde karışık geçebilir.
• Sorgu yeniden yazma (query rewriting). Özellikle sohbet tabanlı RAG'de kullanıcı "peki ya fiyatı?" gibi bağlama bağlı bir soru sorar. Bu soruyu, önceki konuşmayı kullanarak kendi başına anlamlı bir sorguya dönüştürmek getirme kalitesini uçurur.
• Çok sorgulu getirme. Tek bir sorgudan birkaç varyant üretip her biriyle arama yapmak ve sonuçları birleştirmek, RRF ile doğal olarak uyumludur; zaten sıralamaları birleştiriyorsunuz.

Bu adımlar ucuz ama etkilidir. Getirme aşamasına giren sorgu ne kadar iyiyse, sonraki tüm aşamalar o kadar kolaylaşır. Çöp girerse çöp çıkar; bu, RAG için fazlasıyla geçerli.

Teoriyi anladıktan sonra en sık gelen soru şu: "Peki ben bunu neyle kurarım?" Somut bir başlangıç yığını önereyim, ama şunu baştan söyleyeyim: tek doğru yığın yok, önemli olan üç aşamayı destekleyen araçları seçmek.

• Getirme motoru. Elasticsearch veya OpenSearch, hem BM25 hem de vektör aramayı tek üründe sunduğu için hibrit için doğal bir başlangıç. Türkçe analizör desteği de olgun. Alternatif olarak, ayrı bir vektör veritabanı (Qdrant, Weaviate, Milvus gibi) ile ayrı bir metin arama motorunu birleştirebilirsiniz.
• Füzyon. RRF'yi çoğu modern arama motoru artık yerleşik olarak sunuyor; sunmuyorsa, birkaç satır kodla kendiniz yazabilirsiniz. Formül basit, hatırlayın.
• Reranker. Yönetilen bir servis (Cohere Rerank gibi) hızlı başlangıç için; veri egemenliği isteyen kurumlar için açık kaynak bir cross-encoder'ı kendi altyapınızda çalıştırmak. KVKK kaygınız varsa ikincisini ciddi değerlendirin.

Benim önerim, mükemmel mimariyi ilk günden kurmaya çalışmamak. Önce sadece BM25 ile bir taban kurun, ölçün. Sonra vektörü ekleyin, ölçün. Sonra RRF, sonra reranker. Her katmanın kattığı değeri kendi verinizde görün; böylece hem gereksiz karmaşıklıktan kaçınır hem de yatırımınızı gerekçelendirirsiniz.

Yıllar içinde aynı hataların tekrar tekrar yapıldığını gördüm. Sizi bunlardan kurtarmak için kısa bir kontrol listesi bırakıyorum:

• Skorları çıplak toplamak. BM25 skoru ile kosinüs benzerliğini doğrudan toplamayın; ölçekler farklı. RRF veya düzgün bir normalizasyon kullanın.
• Türkçe'de İngilizce tokenizasyon. Varsayılan analizörle Türkçe indekslemek, BM25'inizi sessizce sakatlar. Türkçe analizör ve gövdeleme şart.
• Reranker'ı her şeye uygulamak. Cross-encoder'ı tüm koleksiyona değil, sadece aday havuzuna uygulayın. Aksi halde gecikme patlar.
• Ölçmeden üretime geçmek. Altın set yoksa, iyileştirme yaptığınızı sadece hissedersiniz, kanıtlayamazsınız.
• Erişim kontrolünü LLM'e bırakmak. Yetki filtresini getirme katmanında uygulayın; "modele söyleriz göstermez" yaklaşımı KVKK açısından kabul edilemez.
• Chunking'i sonraya bırakmak. İndeksleme kararınız yanlışsa, sonraki hiçbir katman tam telafi edemez.

Bu listeyi her yeni RAG projesinde bir kez baştan okumanızı öneririm; çünkü bu hataların çoğu ucuza önlenebilirken, sonradan düzeltmek pahalıya patlar.

Doğruluk kadar önemli ama sürekli ihmal edilen bir konu var: gecikme bütçesi. Her mimari katman size doğruluk kazandırırken bir miktar süre de ekler. Kullanıcı bir sohbet arayüzünde cevabı iki saniyede beklerken, siz üç aşamalı bir boru hattını dört saniyeye yayamazsınız; yoksa en doğru cevap bile geç geldiği için kaybeder.

Ben her RAG projesinde baştan bir "gecikme bütçesi" çıkarırım. Toplam hedef süreyi belirler, sonra bunu aşamalara paylaştırırım: getirme, füzyon, yeniden sıralama ve LLM üretimi. Genelde en büyük iki kalem reranker ve LLM'in kendisidir. Reranker'ın aday havuzunu 100'den 50'ye düşürmek, çoğu zaman doğruluğu neredeyse hiç bozmadan gecikmede ciddi bir rahatlama sağlar; bu tam da ayar yapılacak yerdir.

Pratik bir denge tablosu:

Kurulum	Göreli doğruluk	Göreli gecikme	Ne zaman?
Sadece BM25	Taban	En düşük	Basit, terim odaklı sorgular
Sadece vektör	Taban	Düşük	Anlamsal, kısa bilgi tabanı
Hibrit (RRF)	Yüksek	Orta	Çoğu üretim senaryosu
Hibrit + reranker	En yüksek	Yüksek	Yüksek doğruluk gereken alanlar

Bu tabloyu kendi ölçümlerinizle doldurun; gerçek rakamlar sisteminize göre değişir. Ama karar mantığı hep aynı: doğruluk kazancı, eklenen gecikmeye değiyor mu? Kullanıcıyı bekletmeden verebileceğiniz en iyi cevabı hedefleyin.

Yöneticilerden gelen ilk itiraz genelde maliyet olur: "İki ayrı arama, bir de reranker; bu bize pahalıya patlamaz mı?" Gerçekçi konuşalım.

BM25 tarafı neredeyse bedava; zaten çoğu arama motorunda yerleşik ve hesaplama olarak ucuz. Vektör tarafı, embedding üretimi (bir kereye mahsus indeksleme maliyeti) ve vektör depolama gerektirir; bu, koleksiyon büyüklüğüyle ölçeklenir ama yönetilebilir. Asıl değişken maliyet reranker'da: eğer yönetilen bir servis kullanıyorsanız, her sorgudaki aday sayısı kadar çağrı ücreti ödersiniz.

Ama şu hesabı da yapın: yanlış belge getiren bir RAG'in maliyeti nedir? Yanlış cevap veren bir müşteri desteği botu, kaybedilen müşteri demektir. Uyum alanında yanlış bir alıntı, yasal risk demektir. Reranker'ın kattığı %17.4'lük recall iyileşmesi, bu bağlamda çoğu zaman kendini kolayca amorti eder. Benim yaklaşımım şu: reranker'ı bir gider değil, bir sigorta olarak görün. Ama körü körüne değil; aday havuzunu makul tutarak, gerektiğinde basit sorgularda atlayarak maliyeti akıllıca yönetin. Doğru ayarlanmış bir hibrit sistem, "her şeyi en pahalı şekilde yap" ile "hiç yapma" arasındaki tatlı noktadır.

Son olarak, en çok ihmal edilen ama en çok fark yaratan konu: ölçüm. "Sistem daha iyi gibi" cümlesiyle üretime çıkan RAG projelerinin çoğu, altı ay sonra neyin neden bozulduğunu anlayamıyor. Baştan bir değerlendirme disiplini kurun.

Somut önerim: küçük ama temsili bir "altın set" oluşturun; yani gerçek kullanıcı sorguları ve bunlara karşılık gelen doğru belgelerden oluşan bir doğrulama kümesi. Bu setle şu metrikleri düzenli ölçün:

• Recall@k: İlgili belgelerin ilk k sonuç içinde yakalanma oranı. RAG için belki en kritik metrik; çünkü LLM ancak getirilen belgeyi kullanabilir.
• NDCG: Sadece yakalamayı değil, sıralamanın kalitesini de ölçer. İyi belgenin üstte olması önemliyse buna bakın.
• Gecikme (latency): p50 ve p95 gecikmenizi izleyin. Reranker eklerken bu rakamların nasıl değiştiğini görmelisiniz.

Bu metrikleri her mimari değişikliğinde (sadece BM25, sadece vektör, hibrit, hibrit+reranker) yeniden ölçün. Böylece "hibrit gerçekten bize %X kazandırdı mı" sorusunu hissiyatla değil, veriyle yanıtlarsınız. Benim üretimde ilerleme tarzım hep bu: küçük bir altın setle başla, her değişikliği ölç, sadece sayı iyileşiyorsa tut. Hibrit arama ve reranking'in kağıt üstündeki faydası etkileyici; ama sizin verinizde ne kadar kazandırdığını sadece kendi ölçümünüz söyler. Bir sonraki RAG projenize başlarken ilk kuracağınız şey vektör veritabanı değil, bu değerlendirme döngüsü olsun.

Bir noktayı daha ekleyeyim: metrikleri sadece bir kez değil, düzenli aralıklarla ölçün. Bilgi tabanınıza yeni belgeler eklendikçe, kullanıcı soru kalıpları değiştikçe ve modelleri güncelledikçe, dünkü optimum bugün optimum olmayabilir. Ben canlı sistemlerde küçük bir altın seti otomatik bir testle her hafta çalıştırmayı öneriyorum; recall veya NDCG'de sessiz bir düşüş olduğunda, kullanıcı şikayet etmeden önce sizin haberiniz olsun. Ölçüm bir başlangıç ritüeli değil, sürekli bir alışkanlıktır; hibrit aramanın gerçek gücünü ancak bu disiplinle koruyabilirsiniz.