Hibrit Arama: BM25 vs Vektör (İkisi de Neden Şart)

Hibrit Arama: BM25 vs Vektör (İkisi de Neden Şart)

Bir destek temsilcisi RAG sohbet botunuza "SKU-4471" yazıyor. Dört sonuç dönüyor. Dördü de kendinden emin şekilde yanlış. Genel amaçlı bir embedding modelinin bu tam dizgiyi vektör uzayında kendine yakın bir yere yerleştirmesi için hiçbir nedeni yok. Hibrit arama tam da bu tek başarısızlık modu yüzünden var ve ekiplerin sürekli aynı soruyu sormasının nedeni de bu: BM25 ile vektör aramayı, sonsuza kadar bir ayar düğmesiyle uğraşmadan gerçekte nasıl birleştirirsiniz?

RAG araç stack'ini daha geniş ölçekte değerlendiriyorsanız, en iyi RAG araçları rehberimiz çevresindeki tüm stack'i kapsıyor.

Öne Çıkanlar

• BM25 tam anahtar kelime eşleşmelerini (SKU'lar, hata kodları) bulur; vektör arama ise aynı dizgiyi değil, kavramsal olarak benzer metni bulur.
• Hibrit arama ikisini birleştirir, genellikle Reciprocal Rank Fusion (RRF) ile, ve karışık sorgu yüklerinde tek başına ikisinden de iyi sonuç verir.
• WANDS benchmark'ında sade RRF 0,7068 NDCG alıyor (BM25'in 0,6983'üne karşı); ince ayar bunu 0,7497'ye taşıyor, %7,4'lük bir artış.
• Postgres/pgvector, ts_rank + pgvector ile hibrit aramayı yerel olarak çalıştırabilir; özel bir vektör veritabanı gerekmez.

Hibrit Arama Nedir? (BM25 + Vektör, Bir Arada)

Hibrit arama, BM25 ve vektör aramayı aynı sorgu üzerinde iki ayrı erişim geçişi olarak çalıştırır, ardından iki sıralı sonuç listesini bir füzyon algoritmasıyla tek bir çıktıda birleştirir; bu algoritma çoğunlukla Reciprocal Rank Fusion'dır. Üçüncü bir erişim yöntemi değildir; mevcut iki yöntemin üzerinde bir orkestrasyon katmanıdır.

Bu ayrım önemli, çünkü bu konunun etrafındaki arama trafiğinin hatırı sayılır bir kısmı BM25 ile vektör aramayı aynı şeymiş gibi ele alıyor. Öyle değiller. BM25, kökleri 1970'lerin bilgi erişimine uzanan, seyrek ve anahtar kelime tabanlı bir skorlama fonksiyonudur. Vektör arama ise yoğun, embedding tabanlı bir benzerlik aramasıdır ve büyük ölçekte pratik hale gelmesi ancak son on yılda mümkün oldu. Hibrit arama ikisini rakip teknikler olarak değil, birbirini tamamlayan girdiler olarak ele alır ve baştan bir kazanan seçmek yerine çıktılarını birleştirir.

BM25 vs Vektör vs Hibrit: Hızlı Karşılaştırma

WANDS e-ticaret benchmark'ında tek başına BM25 0,6983 NDCG, tek başına vektör arama ise 0,6953 aldı (neredeyse berabere). Derlem başına hiçbir ince ayar yapılmadan sade RRF füzyonu 0,7068'e ulaştı; bu, tek başına BM25'e göre mütevazı bir %1,2'lik artış. Doug Turnbull'ün benchmark'ı, RRF'in üzerine ürün adı güçlendirmesi ekleyen ayarlanmış bir varyantı da test etti ve o versiyon 0,7497'ye ulaştı, yani %7,4'lük bir artış. Hangi rakamı aktardığınız konusunda dürüst olmakta fayda var: Tek başına RRF kutudan çıktığı haliyle küçük ama gerçek bir avantaj sağlıyor; daha büyük olan %7,4'lük rakam ise çoğu ekibin ilk gün atladığı, alana özgü ekstra bir ince ayar gerektirdi. Ne BM25 ne de vektör arama tek başına baskın gelir; ikisi farklı başarısızlık modlarını kapsar ve bunları birleştirmek iki açığı aynı anda kapatır.

BM25 Mekaniği: Anahtar Kelime Araması Alakayı Gerçekte Nasıl Skorlar

BM25 belgeleri terim sıklığına göre skorlar; bu sıklık, terimin tüm derlem genelinde ne kadar nadir olduğuyla ağırlıklandırılır ve belge uzunluğuna göre normalize edilir. Robertson ve Zaragoza bu formalizasyonu 2009 tarihli "The Probabilistic Relevance Framework: BM25 and Beyond" makalelerinde ortaya koydu. Bu, TF-IDF'in bir iyileştirmesidir, onun yerine geçen bir yöntem değildir.

BM25'in davranışının büyük kısmını iki parametre kontrol eder. k1 (genellikle 1,2-2,0) terim sıklığı doygunluğunu kontrol eder: bir kelimenin tekrarlanmasının skoru ne kadar yükseltebileceğine üst sınır koyar; böylece "fatura" kelimesini 40 kez içeren bir belge, onu daha sıkı ve daha alakalı bir pasajda 4 kez geçen bir belgeyi otomatik olarak geride bırakmaz. b (varsayılan 0,75) belge uzunluğu normalizasyonunu kontrol eder: BM25'in uzun belgeleri, doğal olarak daha fazla terim eşleşmesi içerdikleri için ne kadar sert cezalandıracağını belirler.

b değerini yanlış seçmek gerçek ve yaygın bir ayar hatasıdır. Kısa teknik belgeler (hata logları, ürün başlıkları) daha düşük bir b ister, çünkü uzunluk varyansı küçüktür; uzun biçimli içerik (dokümantasyon sayfaları, makaleler) genellikle varsayılana daha yakın bir b ister. BM25'in temel zayıflığı sözcük dağarcığı uyumsuzluğudur: kullanıcı "paramı nasıl geri alırım" diye sorar ve belge yalnızca "iade politikası" diyorsa, BM25 sıfır ortak token bulur ve işe yarar hiçbir şey döndürmez.

Yoğun Vektör Arama Mekaniği (ve Nerede Kırıldığı)

Vektör arama, metni bir model kullanarak sabit boyutlu embedding'lere eşler, ardından kosinüs benzerliği veya iç çarpım ile yakın vektörleri bulur; bu işlem genellikle yaklaşık en yakın komşu (ANN) indeksiyle hızlandırılır. HNSW; Weaviate, Qdrant ve Milvus genelinde baskın algoritmadır ve büyük ölçekte ciddi hız kazanımları için küçük bir geri çağırma (recall) kaybını takas eder.

BM25'in sözcük dağarcığı uyumsuzluğu sorununu çözen şey budur: "paramı geri al" ile "iade politikası", sıfır ortak token'a sahip olsalar bile embedding uzayında birbirine yakın düşer, çünkü model yüzey biçimini değil, anlamı yakalar. Burada doğru modeli seçmek çok şey fark ettirir. Doğru embedding modelini seçme rehberimize ve seçenekleri tartıyorsanız Voyage, OpenAI ve Cohere embedding'lerini nasıl karşılaştırdığımıza bakın.

Ama yoğun erişimin de kendi kör noktası var ve bu, BM25'inkinin ayna görüntüsü. Müşteriler için RAG sistemleri kurarken en sık karşılaştığımız tam eşleşme başarısızlığı egzotik bir şey değil. Bir destek temsilcisinin belirli bir sipariş numarasını ya da SKU'yu sorması ve vektör indeksinin kendinden emin biçimde anlamsal olarak benzer ama yanlış bir şey döndürmesi. Genel amaçlı bir embedding modelinin "SKU-4471" ya da "ERR_CONN_RST" gibi dizgileri, alakalı ama yanlış bir token'a kıyasla vektör uzayında kendine daha yakın yerleştirmesi için güçlü bir nedeni yoktur, çünkü bu tür dizgiler eğitim verisinde nadiren ayrı, yalıtık kavramlar olarak geçer. BigData Boutique tam da bu başarısızlık örüntüsünü kendi SKU ve hata kodu örnekleriyle belgeliyor. Bu, RAG dağıtımları genelinde iyi bilinen, bağımsız olarak doğrulanmış bir olgudur; tek seferlik bir tuhaflık değil.

BM25 ve Vektör Arama Nasıl Birleştirilir: RRF vs Alfa Ağırlıklı Füzyon

BM25 ve vektör sonuçlarını birleştirmenin gerçekte iki yolu var ve hibrit arama hakkında yazanların neredeyse hiçbiri bunları net biçimde karşılaştırmıyor. Cormack, Clarke ve Buettcher'ın 2009 SIGIR makalesinden gelen Reciprocal Rank Fusion (RRF) sıralar üzerinde çalışır: her sonuç listesi genelinde score = sum(1 / (k + rank_i)), k genellikle 60'a ayarlanır. Yalnızca konumla ilgilendiği için, ham skorla değil, BM25'in sınırsız skorları ile kosinüs benzerliğinin 0-1 aralığı arasındaki ölçek uyumsuzluklarından etkilenmez ve derlem başına ince ayar gerektirmez.

Alfa ağırlıklı (konveks) füzyon farklı çalışır: final = alpha * dense_score + (1 - alpha) * sparse_score; sıralar yerine normalize edilmiş skorlar üzerinde çalışır. Güven büyüklüğünü daha iyi yansıtabilir (0,95 benzerlikte bir vektör isabeti, 0,61'dekinden gerçekten daha güçlü görünür), ancak derlem başına alpha ince ayarı gerektirir ve bu ayar, skor dağılımlarınız kaydığında sessizce bozulur (yeni embedding modeli, yeniden indekslenmiş derlem, farklı sorgu karışımı).

Pratikte seçim, skor kalibrasyonunuza ne kadar güvendiğinize bağlı kalır. Tek ve stabil bir embedding modeline karşı sade BM25 çalıştırıyorsanız, alfa ağırlıklandırma gerçek skor farkını kullandığı için (yalnızca konumu değil) biraz daha iyi sıralama elde edebilir. Ama bu kalibrasyon insanların beklediğinden daha fazla kayar. Yeni bir embedding modeli sürümüne geçin, belgelerinizi yeniden parçalayın ya da öne bir yeniden sıralama adımı ekleyin; yoğun skor dağılımınız değişir. alpha=0,6 doğru değer olmaktan çıktığında kimse gece yarısı çağrı almaz; sıralama sadece sessizce biraz kötüleşir ve düzenli erişim değerlendirmesi çalıştırmıyorsanız bunu fark etmek kolay değildir. RRF bundan tamamen kaçınır, çünkü ham skorlara asla bakmaz, yalnızca sıra konumuna bakar; bu yüzden bir yeniden indeksleme ya da model değişikliği onu, alfa ağırlıklandırmayı kırabildiği gibi sessizce kıramaz.

RRF derlem başına ince ayar gerektirmez; alfa ağırlıklandırma ise veriniz değiştikçe sürekli gözetim ister.

Motorlar varsayılanlarda ayrışır. Weaviate hem RRF'i hem de açıkça ayarladığınız bir alpha parametresini sunar. Elasticsearch, retriever API'si üzerinden yerel RRF ile gelir (dağıtımınızda tam sürüm gereksinimini doğrulayın; bu, 8.x serisinde geldi). Qdrant, Query API'si üzerinden RRF'i yerel olarak destekler. Pinecone'un hibrit özelliği genellikle RRF'i doğrudan sunmak yerine alfa ağırlıklı konveks kombinasyona yaslanır. Hangisine uzanacağınızdan emin değilseniz, RRF ile başlayın. Daha az bakım gerektiren varsayılan odur.

Sıfırdan RRF: Satıcıdan Bağımsız Bir Python Örneği

Rakip rehberlerde bulduğumuz her RRF kod örneği tek bir satıcının SDK'sına kilitli: Weaviate istemcisi, Qdrant istemcisi, Pinecone istemcisi. İşte herhangi bir stack'e bırakabileceğiniz, çerçevesiz bir versiyon; standart varsayılan olarak k=60 ile:

def reciprocal_rank_fusion(result_lists, k=60):
    """
    result_lists: list of ranked lists, each a list of document IDs
                  ordered from most to least relevant.
    k: RRF constant (60 is the standard default from Cormack et al., 2009).
    Returns: list of (doc_id, fused_score) sorted descending by score.
    """
    scores = {}
    for result_list in result_lists:
        for rank, doc_id in enumerate(result_list, start=1):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
    return sorted(scores.items(), key=lambda item: item[1], reverse=True)

# Example usage:
bm25_hits = ["doc_9", "doc_2", "doc_14", "doc_1"]
vector_hits = ["doc_2", "doc_1", "doc_9", "doc_30"]

fused = reciprocal_rank_fusion([bm25_hits, vector_hits])
for doc_id, score in fused:
    print(f"{doc_id}: {score:.4f}")

Algoritmanın tamamı bu. SDK yok, satıcı kilidi yok ve iki sıralı listeniz Elasticsearch ile bir Faiss indeksinden de gelse, Postgres ts_rank ile pgvector'den de gelse çalışır. Modelleri bir API'ye istek atmak yerine kendiniz çalıştırıyorsanız, Ollama ile embedding modellerini yerel çalıştırma rehberimize bakın.

Postgres + pgvector: Özel Bir Vektör Veritabanı Olmadan Hibrit Arama

Hibrit arama çalıştırmak için özel bir vektör veritabanına ihtiyacınız yok. Geliştirici Pedro Alonso'nun pg_textsearch/pgvector benchmark'ına göre (Postgres 17, pg_textsearch 1.3.0, pgvector 0.8.2, nomic-embed-text embedding'leri, BEIR SciFact veri seti), yerel ts_rank çalıştıran tek bir Postgres instance'ı yalnızca 0,07 NDCG@10 aldı; BM25'in 0,69'unun, pgvector'ün 0,66'sının ve hibridin 0,70'inin çok gerisinde, hepsi tek instance'ta ve hibrit RRF yaklaşık 11,5ms medyan gecikmeyle.

O 0,07 rakamı her şeyi ele veriyor: Postgres'in yerleşik ts_rank'i bir kapsama yoğunluğu (cover-density) sıralayıcısıdır, gerçek BM25 değildir. Postgres'te gerçek BM25 skorlaması istiyorsanız bir eklentiye ihtiyacınız var. pg_textsearch, VectorChord ve ParadeDB'nin hepsi, yerel ts_rank'in sağlamadığı gerçek BM25 tarzı sıralama ekler. Bunlardan birini yoğun benzerlik için pgvector ile eşleştirin, iki sıralı listeyi yukarıdaki RRF fonksiyonuyla birleştirin; çalıştırılacak ayrı bir altyapı olmadan, tek bir Postgres instance'ında hibrit aramanız hazır.

Bu eşleştirmenin tek bir sorguda kabaca nasıl göründüğü şöyle; BM25 yetenekli bir eklentiden gelen sözcüksel sıra ile pgvector'den gelen vektör mesafesini birleştiriyor:

WITH lexical AS (
  SELECT id, ts_rank_cd(body_tsv, query) AS rank
  FROM documents, plainto_tsquery('english', 'refund policy') query
  WHERE body_tsv @@ query
  ORDER BY rank DESC LIMIT 50
),
semantic AS (
  SELECT id, embedding <=> '[0.012, -0.045, ...]' AS distance
  FROM documents
  ORDER BY distance LIMIT 50
)
SELECT * FROM lexical
FULL OUTER JOIN semantic USING (id);

Her iki sonuç kümesini yukarıdaki RRF fonksiyonuna verin ve tek bir Postgres instance'ında hibrit aramanız hazır. Dürüst sınır şu: bu, birkaç milyon satırın düşük seviyelerine kadar iyi dayanır, ancak Postgres özel bir erişim motoru olarak inşa edilmedi. İndeks ince ayarının sorumluluğu sizde olur, sade ts_rank_cd eklentisiz hâlâ gerçek BM25 değildir ve Weaviate ya da Milvus'un yerel olarak sunduğu yerleşik yeniden sıralama ya da çoklu vektör desteğini almazsınız. Derleminiz küçük-orta ölçekliyse ve zaten Postgres çalıştırıyorsanız, bu sizi ikinci bir altyapı parçasından kurtarır. On milyonlarca belgenin ötesinde ya da gelişmiş yeniden sıralama gerekiyorsa, özel bir motor kendini amorti eder.

Stack'iniz için Qdrant, Chroma ya da pgvector'ü daha geniş ölçekte tartıyorsanız, bu füzyon yönteminin kendisinden ayrı bir karardır. Ödünleşimler için Qdrant, Chroma ve pgvector karşılaştırmamıza bakın.

Hangi Vektör Veritabanları Yerel Hibrit Aramayı Destekler?

Modern vektör veritabanlarının çoğu artık hibrit aramayı kutudan çıktığı haliyle sunuyor, ancak varsayılan olarak kullandıkları füzyon yöntemi anlamlı biçimde farklılaşıyor.

Bağlanmadan önce tam sürüm gereksinimlerini doğrulayın. Hibrit özellikler 2026 boyunca bu motorlara hızla ekleniyor ve API şekilleri sürümden sürüme değişiyor. Füzyon mekaniğinin ötesinde, daha geniş bir satın alma kararı için en iyi vektör veritabanları rehberimizin tamamına bakın.

Hibrit Arama Bu Karmaşıklığa Değer mi?

Hibrit arama, derleminizde hem tam eşleşme örüntüleri (SKU'lar, ID'ler, nadir terimler) hem de kavramsal, farklı ifade edilen sorgular olduğunda mimari olarak doğrudur. Derleminizde ikisi de yoksa (saf anlatı içeriği, kimsenin tam dizgiyle aradığı bir tanımlayıcı yok), neredeyse fark etmeyeceğiniz bir artış için füzyon karmaşıklığı ekliyor olabilirsiniz.

"Yalnızca anlatı"nın gerçekte neye benzediğini düşünün: bir şirket blog arşivi, düzyazı ağırlıklı runbook'larla dolu bir iç mühendislik wiki'si, kimsenin ürün ID'si ya da ticket numarasıyla aramadığı bir dokümantasyon sitesi. Bu derlemlerde tek başına vektör arama genellikle değerin çoğunu verir ve füzyon adımı, gürültüye yuvarlanan bir artış için sadece ikinci bir erişim geçişi ve artık birinin sahiplendiği bir parametre ekler. Bunu, SKU'ların, sipariş numaralarının ve model kodlarının gerçek kullanıcı sorgularında sürekli göründüğü bir destek ticket sistemi ya da e-ticaret kataloğuyla karşılaştırın. Asıl test şu: kendi loglarınızdan on gerçek sorgu çekin ve kaçının, farklı ifadeye dayalı bir embedding modelinin asla doğru yerleştiremeyeceği bir tam tanımlayıcı içerdiğini sayın. Sıfırsa, hibriti atlayın. Bir-ikiden fazlaysa, kurun.

Hibrit arama evrensel bir yükseltme değildir; derleminizde SKU, ID ya da nadir terim aramaları yoksa, asla fark etmeyeceğiniz bir artış için füzyon karmaşıklığı ekliyor olabilirsiniz.

Maliyet gerçek ama sınırlı: ikinci bir erişim geçişi, bir füzyon adımı ve artık birinin sahiplendiği bir ağırlıklandırma parametresi. Burada bilerek bir gecikme rakamı vermiyoruz, çünkü ortalıkta dolaşan rakamlar adı belirsiz donanımlardaki adı belirsiz kurulumlardan geliyor ve sizinki farklı olacaktır. Karar vermeden önce kendi derleminizde ölçün. İki Hacker News başlığı, buradaki gerçek uygulayıcı gerilimini iyi yakalıyor: "Hybrid Search Is Just the Beginning: Optimizing the R in RAG" ve "Better RAG Results with Reciprocal Rank Fusion and Hybrid Search". Her iki başlık da hibriti, önce derleminizin çözmek için tasarlandığı sorgu örüntülerine sahip olup olmadığını kontrol etmeden, kargo kültü bir en iyi pratik olarak benimsemeye itiraz ediyor. Kurmadan önce, erişim kalitesinin gerçekte nasıl ölçüleceğini anlamakta fayda var: NDCG ve recall@k rakamları yalnızca kendi derleminize karşı bir anlam taşır, bir benchmark veri setine karşı değil.

Bizim görüşümüz: kullanıcıya dönük destek, e-ticaret ya da ticket sorguları karşılayan her RAG sisteminde varsayılan hibrit olsun. Bu iş yükleri neredeyse her zaman tanımlayıcıları doğal dille karıştırır. Yalnızca anlatıdan oluşan derlemler (uzun biçimli dokümanlar, anlatı wiki'leri) için, tek yöntemli erişimin açık bıraktığı gerçek bir açığı ölçene kadar atlayın.

Sıkça Sorulan Sorular

RAG'da hibrit arama nedir?

Hibrit arama, BM25 (anahtar kelime) ve vektör (anlamsal) erişimini aynı sorgu üzerinde ayrı geçişler olarak çalıştırır, ardından iki sıralı listeyi bir füzyon algoritmasıyla, genellikle Reciprocal Rank Fusion ile birleştirir. Hem tam eşleşme sorgularını hem de farklı ifade edilen kavramsal sorguları yakalar; bunların ikisini de tek başına hiçbir yöntem idare edemez.

BM25 vektör arama ile aynı şey mi?

Hayır. BM25, tam terim örtüşmesini ve nadirliği skorlayan seyrek sözcüksel aramadır. Vektör arama, embedding'leri ve benzerlik matematiğini kullanan yoğun anlamsal aramadır. İkisi, güçlü yönleri birbirinin tersi olan iki farklı erişim yöntemidir; hibrit arama ikisinin yerine geçmez, ikisini birleştirir.

BM25 ve vektör aramayı nasıl birleştirirsiniz?

Her iki erişim yöntemini aynı sorgu üzerinde bağımsız olarak çalıştırın, ardından iki sıralı sonuç listesini birleştirin; en yaygın yol, her liste genelinde 1 / (k + rank) toplamını alan Reciprocal Rank Fusion'dır. Alfa ağırlıklı skor kombinasyonu alternatiftir, ancak RRF'in gerektirmediği, derlem başına ince ayar ister.

Reciprocal Rank Fusion (RRF) nedir?

RRF, Cormack, Clarke ve Buettcher'ın 2009 SIGIR makalesinden gelen bir füzyon algoritmasıdır; birden çok sıralı listeyi, her belge için 1 / (k + rank) toplayarak birleştirir, k genellikle 60'a ayarlanır. Ham skorlar üzerinde değil, sıra konumu üzerinde çalışır; bu sayede erişim yöntemleri arasındaki ölçek uyumsuzluklarında stabil kalır.

RRF ile alfa ağırlıklı füzyon arasındaki fark nedir?

RRF sıraları birleştirir ve derlem başına ince ayar gerektirmez. Alfa ağırlıklı füzyon, ayarlanabilir bir alpha parametresi kullanarak normalize edilmiş skorları birleştirir; bu, güven büyüklüğünü daha iyi yansıtabilir, ancak skor dağılımları her kaydığında (yeniden indeksleme ya da model değişikliği sonrasında olduğu gibi) sürekli yeniden ayar gerektirir.

Ne zaman tek başına vektör arama yerine hibrit arama kullanmalıyım?

Sorgularınız tam tanımlayıcıları (SKU'lar, sipariş numaraları, hata kodları) doğal dilde, kavramsal sorularla karıştırıyorsa hibrit arama kullanın; destek, e-ticaret ve ticket sistemleri genellikle böyledir. Tanımlayıcısı olmayan, yalnızca anlatıdan oluşan içerik için atlayın; eklenen füzyon karmaşıklığı büyük olasılıkla ölçülebilir bir artış göstermeyecektir.

Vektör arama SKU ya da hata kodu gibi tam eşleşmeleri neden kaçırır?

Embedding modelleri genel dil örüntülerinden öğrenir ve "SKU-4471" ya da "ERR_CONN_RST" gibi dizgiler eğitim verisinde nadiren ayrı, yalıtık kavramlar olarak geçer. Modelin, o tam dizgiyi anlamsal olarak alakalı ama yanlış bir token'a göre kendine daha yakın yerleştirmesi için güçlü bir nedeni yoktur.

Hangi vektör veritabanları hibrit aramayı yerel olarak destekler?

Weaviate, Qdrant, Elasticsearch, OpenSearch, Vespa ve Milvus'un hepsi 2026 itibarıyla yerel hibrit arama sunuyor, ancak varsayılan füzyon yöntemleri farklı (RRF vs alfa ağırlıklı vs normalizasyon). pgvector'lü Postgres de hibrit arama çalıştırabilir, ancak yerel ts_rank gerçek BM25 olmadığından bir BM25 eklentisi gerekir.

Hibrit arama eklenen karmaşıklığa değer mi?

Tam eşleşme ve kavramsal sorguları karıştıran derlemler için, evet. Sade RRF bile WANDS benchmark'ında tek yöntemlerin ikisini de geçiyor (0,7068'e karşı BM25'in 0,6983'ü) ve ayarlanmış bir varyant %7,4'lük bir artışa ulaşıyor (0,7497). Tanımlayıcısı olmayan, yalnızca anlatıdan oluşan derlemler için, ikinci erişim geçişi ve gerektirdiği füzyon ince ayarı, fark etmeyeceğiniz bir artışa ağır basabilir. Bağlanmadan önce ölçün.

Postgres/pgvector özel bir vektör veritabanı olmadan hibrit arama yapabilir mi?

Evet. Yoğun benzerlik için pgvector'ü pg_textsearch, VectorChord ya da ParadeDB gibi gerçek bir BM25 eklentisiyle eşleştirin (yalnızca yerel ts_rank, Pedro Alonso'nun pg_textsearch/pgvector benchmark'ında yalnızca 0,07 NDCG@10 almıştı, hibrit için 0,70'e karşı), ardından iki sıralı listeyi RRF ile birleştirin; hepsi tek bir Postgres instance'ında.

Her iki erişim yöntemi de tek başına çalıştırıldığında gerçek açıklar bırakır: BM25 farklı ifadeyi kaçırır, vektör arama tam tanımlayıcıları kaçırır ve ikisini RRF ile birleştirmek, her ikisini de kapatmanın daha az bakım gerektiren yoludur. Bunu kendiniz kurmayı mı yoksa daha önce RAG erişimi dağıtmış bir ekibi mi getireceğinizi tartıyorsanız, RAG uygulaması geliştirme rehberimizin tamamı bir sonraki adımı kapsıyor; ya da Techsy'nin sizinle birlikte kurmasını tercih ederseniz iletişime geçin.