Pencarian Hybrid: BM25 vs Vektor (dan Kenapa Kamu Butuh Keduanya)

Pencarian Hybrid: BM25 vs Vektor (dan Kenapa Kamu Butuh Keduanya)

Seorang agen support mengetik "SKU-4471" ke chatbot RAG kamu. Empat hasil muncul. Semuanya salah dengan penuh percaya diri. Model embedding umum tidak punya alasan untuk menempatkan string persis itu di dekat dirinya sendiri di ruang vektor. Satu mode kegagalan itulah alasan pencarian hybrid ada, dan itulah kenapa tim terus menanyakan satu pertanyaan spesifik: bagaimana sebenarnya menggabungkan BM25 dan pencarian vektor tanpa harus menjaga tombol tuning selamanya?

Kalau kamu sedang mengevaluasi tooling RAG secara lebih luas, rangkuman tool RAG terbaik kami membahas stack di sekitarnya.

Poin Penting

• BM25 menemukan kecocokan kata kunci persis (SKU, kode error); pencarian vektor menemukan teks yang mirip secara konsep, bukan string yang identik.
• Pencarian hybrid menggabungkan keduanya, biasanya lewat Reciprocal Rank Fusion (RRF), dan mengalahkan keduanya secara tunggal pada beban kerja query campuran.
• Di benchmark WANDS, RRF polos mencetak 0,7068 NDCG (vs 0,6983 milik BM25); tuning mendorongnya ke 0,7497, kenaikan 7,4%.
• Postgres/pgvector bisa menjalankan pencarian hybrid secara native lewat ts_rank + pgvector, tanpa database vektor khusus.

Apa Itu Pencarian Hybrid? (BM25 + Vektor, Digabungkan)

Pencarian hybrid menjalankan BM25 dan pencarian vektor sebagai dua lintasan retrieval terpisah untuk query yang sama, lalu menggabungkan dua daftar hasil berperingkat menjadi satu output menggunakan algoritma fusi, paling sering Reciprocal Rank Fusion. Ini bukan metode retrieval ketiga; ini lapisan orkestrasi di atas dua metode yang sudah ada.

Perbedaan itu penting karena sebagian besar traffic pencarian seputar topik ini menyamakan BM25 dan pencarian vektor seolah-olah keduanya sama. Kenyataannya tidak. BM25 adalah fungsi scoring berbasis kata kunci yang sparse, dengan akar di information retrieval tahun 1970-an. Pencarian vektor adalah pencarian kemiripan berbasis embedding yang dense, yang baru praktis dalam skala besar satu dekade terakhir. Pencarian hybrid memperlakukan keduanya sebagai input yang saling melengkapi, bukan teknik yang bersaing, dan memfusikan output mereka alih-alih memilih pemenang di awal.

BM25 vs Vektor vs Hybrid: Perbandingan Cepat

Di benchmark e-commerce WANDS, BM25 saja mencetak 0,6983 NDCG dan pencarian vektor saja mencetak 0,6953 (hampir seri). Fusi RRF polos, tanpa tuning per korpus, mencapai 0,7068, kenaikan tipis 1,2% dibanding BM25 saja. Benchmark Doug Turnbull juga menguji varian yang sudah di-tuning, yang menambahkan boost nama produk di atas RRF, dan versi itu mencapai 0,7497, kenaikan 7,4%. Perlu jujur soal angka mana yang kamu kutip: RRF saja memberimu keunggulan kecil yang nyata sejak awal; angka 7,4% yang lebih besar membutuhkan tuning spesifik-domain tambahan yang kebanyakan tim lewati di hari pertama. Baik BM25 maupun pencarian vektor tidak ada yang dominan sendirian; keduanya menutup mode kegagalan yang berbeda, dan memfusikan keduanya menutup dua celah sekaligus.

Mekanika BM25: Bagaimana Pencarian Kata Kunci Memberi Skor Relevansi

BM25 memberi skor dokumen berdasarkan frekuensi istilah, dibobot terhadap seberapa langka istilah itu di seluruh korpus, lalu dinormalisasi untuk panjang dokumen. Robertson dan Zaragoza merumuskan formalisasi ini dalam paper 2009 mereka "The Probabilistic Relevance Framework: BM25 and Beyond". Ini penyempurnaan dari TF-IDF, bukan penggantinya.

Dua parameter mengendalikan sebagian besar perilaku BM25. k1 (biasanya 1,2-2,0) mengendalikan saturasi frekuensi istilah: ini membatasi seberapa banyak pengulangan kata mendongkrak skor, jadi dokumen yang menyebut "invoice" 40 kali tidak otomatis mengungguli dokumen yang menyebutnya 4 kali dalam bagian yang lebih padat dan lebih relevan. b (default 0,75) mengendalikan normalisasi panjang dokumen: ini menentukan seberapa keras BM25 menghukum dokumen panjang yang secara alami mengandung lebih banyak kecocokan istilah.

Salah mengatur b adalah kesalahan tuning yang nyata dan umum. Dokumen teknis pendek (log error, judul produk) butuh b lebih rendah karena variansi panjangnya kecil; konten panjang (halaman dokumentasi, artikel) biasanya butuh b mendekati default. Kelemahan inti BM25 adalah ketidakcocokan kosakata: jika pengguna bertanya "how do I get my money back" dan dokumen hanya menulis "refund policy," BM25 menemukan nol token bersama dan tidak mengembalikan apa pun yang berguna.

Mekanika Pencarian Vektor Dense (dan Di Mana Ia Rusak)

Pencarian vektor memetakan teks ke embedding berdimensi tetap menggunakan model, lalu menemukan vektor terdekat lewat cosine similarity atau dot product, biasanya dipercepat oleh indeks approximate nearest-neighbor. HNSW adalah algoritma dominan di Weaviate, Qdrant, dan Milvus, menukar sedikit recall dengan peningkatan kecepatan besar dalam skala.

Inilah yang memperbaiki masalah ketidakcocokan kosakata BM25: "get my money back" dan "refund policy" mendarat berdekatan di ruang embedding meski nol token bersama, karena model menangkap makna, bukan bentuk permukaan. Memilih model yang tepat sangat penting di sini. Lihat panduan kami tentang memilih model embedding yang tepat, dan rincian kami tentang cara kami membandingkan embedding Voyage, OpenAI, dan Cohere jika kamu sedang menimbang pilihan.

Tapi retrieval dense punya titik buta sendiri, dan itu cerminan dari titik buta BM25. Ketika kami membangun sistem RAG untuk klien, kegagalan kecocokan persis yang paling sering kami temui bukan sesuatu yang eksotis. Itu adalah agen support yang meminta nomor pesanan atau SKU tertentu, dan indeks vektor dengan percaya diri mengembalikan sesuatu yang mirip secara semantik tapi salah. Model embedding umum tidak punya alasan untuk menempatkan "SKU-4471" atau "ERR_CONN_RST" dekat dirinya sendiri di ruang vektor dibanding token yang terkait tapi salah, karena string seperti itu jarang muncul sebagai konsep yang berbeda dan terisolasi di data pelatihan. BigData Boutique mendokumentasikan pola kegagalan persis ini dengan contoh SKU dan kode error mereka sendiri. Ini fenomena yang sudah mapan dan dikuatkan secara independen di berbagai deployment RAG, bukan keanehan satu kali.

Cara Menggabungkan BM25 dan Pencarian Vektor: RRF vs Fusi Berbobot Alpha

Ada dua cara nyata untuk memfusikan hasil BM25 dan vektor, dan hampir tidak ada yang menulis tentang pencarian hybrid membandingkan keduanya dengan jelas. Reciprocal Rank Fusion (RRF), dari paper SIGIR 2009 Cormack, Clarke, dan Buettcher, bekerja pada peringkat: score = sum(1 / (k + rank_i)) di setiap daftar hasil, dengan k biasanya disetel 60. Karena hanya peduli posisi, bukan skor mentah, RRF menangani ketidakcocokan skala antara skor BM25 yang tak terbatas dan rentang 0-hingga-1 cosine similarity tanpa masalah, dan tidak butuh tuning per korpus.

Fusi berbobot alpha (konveks) bekerja berbeda: final = alpha * dense_score + (1 - alpha) * sparse_score, beroperasi pada skor ternormalisasi, bukan peringkat. Ia bisa lebih baik mencerminkan besaran keyakinan (trefer vektor di kemiripan 0,95 benar-benar terlihat lebih kuat daripada yang 0,61), tapi butuh tuning alpha per korpus, dan tuning itu rusak secara diam-diam ketika distribusi skor kamu bergeser (model embedding baru, korpus yang di-reindex, bauran query yang berbeda).

Dalam praktik, pilihannya bergantung pada seberapa besar kamu percaya kalibrasi skor kamu. Menjalankan BM25 vanilla terhadap satu model embedding yang stabil, pembobotan alpha bisa meraih peringkat sedikit lebih baik karena memakai jarak skor aktual, bukan cuma posisi. Tapi kalibrasi itu bergeser lebih sering dari dugaan orang. Ganti ke versi model embedding baru, chunk ulang dokumen kamu, atau tambahkan lintasan reranking di hulu, dan distribusi skor dense kamu bergeser. Tidak ada yang di-page ketika alpha=0.6 berhenti menjadi nilai yang benar; peringkatnya hanya diam-diam menjadi sedikit lebih buruk, dan mudah terlewat kecuali kamu menjalankan eval retrieval secara rutin. RRF menghindari ini sepenuhnya karena tidak pernah melihat skor mentah, hanya posisi peringkat, jadi reindex atau penggantian model tidak bisa merusaknya secara diam-diam seperti halnya pada pembobotan alpha.

RRF tidak butuh tuning per korpus; pembobotan alpha butuh penjagaan konstan seiring data kamu berubah.

Engine terbelah soal default. Weaviate mengekspos RRF dan parameter alpha yang kamu setel secara eksplisit. Elasticsearch menghadirkan RRF native lewat API retriever (konfirmasi gating versi persis di deployment kamu; ini mendarat di lini 8.x). Qdrant mendukung RRF secara native lewat Query API. Fitur hybrid Pinecone biasanya bersandar pada kombinasi konveks berbobot alpha alih-alih mengekspos RRF secara langsung. Kalau kamu tidak yakin harus memilih yang mana, mulai dengan RRF. Itu default yang lebih rendah perawatannya.

RRF dari Nol: Contoh Python yang Netral dari Vendor

Setiap sampel kode RRF yang kami temukan di panduan pesaing terkunci ke SDK satu vendor: klien Weaviate, klien Qdrant, klien Pinecone. Ini versi tanpa framework yang bisa kamu masukkan ke stack mana pun, dengan k=60 sebagai default standar:

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}")

Itulah seluruh algoritmanya. Tanpa SDK, tanpa vendor lock-in, dan bekerja entah dua daftar berperingkat kamu datang dari Elasticsearch dan indeks Faiss, atau dari Postgres ts_rank dan pgvector. Kalau kamu menjalankan model sendiri alih-alih memanggil API, lihat menjalankan model embedding secara lokal dengan Ollama.

Postgres + pgvector: Pencarian Hybrid Tanpa Database Vektor Khusus

Kamu tidak butuh database vektor khusus untuk menjalankan pencarian hybrid. Menurut benchmark pg_textsearch/pgvector oleh developer Pedro Alonso (Postgres 17, pg_textsearch 1.3.0, pgvector 0.8.2, embedding nomic-embed-text, dataset BEIR SciFact), satu instance Postgres yang menjalankan ts_rank native hanya mencetak 0,07 NDCG@10, jauh di belakang 0,69 milik BM25, 0,66 milik pgvector, dan 0,70 milik hybrid, semuanya dalam satu instance, dengan RRF hybrid mendarat di sekitar median 11,5 ms.

Angka 0,07 itu adalah petunjuknya: ts_rank bawaan Postgres adalah ranker cover-density, bukan BM25 sungguhan. Kalau kamu mau scoring BM25 sungguhan di Postgres, kamu butuh ekstensi. pg_textsearch, VectorChord, dan ParadeDB semuanya menambahkan peringkat gaya BM25 yang proper, yang tidak disediakan ts_rank native. Pasangkan salah satunya dengan pgvector untuk kemiripan dense, fusikan dua daftar berperingkat dengan fungsi RRF di atas, dan kamu punya pencarian hybrid dalam satu instance Postgres tanpa infrastruktur terpisah untuk dijalankan.

Kira-kira beginilah pasangan itu dalam satu query, menggabungkan peringkat leksikal dari ekstensi berkemampuan BM25 dengan jarak vektor dari pgvector:

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);

Masukkan kedua set hasil ke fungsi RRF di atas dan kamu punya pencarian hybrid dalam satu instance Postgres. Batas jujurnya: ini bertahan dengan baik hingga jutaan baris rendah, tapi Postgres tidak dibangun sebagai engine retrieval khusus. Kamu menanggung tuning indeks sendiri, ts_rank_cd polos tetap bukan BM25 sungguhan tanpa ekstensi, dan kamu tidak mendapat reranking bawaan atau dukungan multi-vektor yang dihadirkan Weaviate atau Milvus secara native. Jika korpus kamu kecil hingga menengah dan kamu sudah menjalankan Postgres, ini menghemat satu potong infrastruktur kedua. Lewat puluhan juta dokumen, atau jika kamu butuh reranking lanjutan, engine khusus sepadan dengan biayanya.

Kalau kamu sedang menimbang Qdrant, Chroma, atau pgvector untuk stack kamu secara lebih luas, itu keputusan terpisah dari metode fusi itu sendiri. Lihat perbandingan Qdrant, Chroma, dan pgvector kami untuk tradeoff-nya.

Database Vektor Mana yang Mendukung Pencarian Hybrid Native?

Sebagian besar database vektor modern kini menghadirkan pencarian hybrid sejak awal, tapi metode fusi default mereka berbeda secara berarti.

Verifikasi gating versi persis sebelum kamu berkomitmen. Fitur hybrid mendarat cepat di berbagai engine ini sepanjang 2026, dan bentuk API bergeser dari rilis ke rilis. Untuk keputusan pembelian yang lebih luas di luar mekanika fusi, lihat rangkuman lengkap database vektor terbaik kami.

Apakah Pencarian Hybrid Sepadan dengan Kompleksitasnya?

Pencarian hybrid benar secara arsitektur ketika korpus kamu punya kedua pola: pola kecocokan persis (SKU, ID, istilah langka) dan query konseptual yang diparafrase. Jika korpus kamu tidak punya keduanya (konten naratif murni, tanpa identifier yang dicari orang lewat string literal), kamu mungkin menambahkan kompleksitas fusi untuk kenaikan yang nyaris tidak terasa.

Bayangkan seperti apa "naratif saja" yang sebenarnya: arsip blog perusahaan, wiki engineering internal yang penuh runbook berat prosa, situs dokumentasi yang tidak ada orang cari berdasarkan ID produk atau nomor tiket. Di korpus seperti itu, pencarian vektor saja biasanya memberimu sebagian besar nilainya, dan langkah fusi hanya menambah lintasan retrieval kedua dan parameter yang kini harus dimiliki seseorang, untuk kenaikan yang dibulatkan menjadi noise. Bandingkan dengan sistem tiket support atau katalog e-commerce, di mana SKU, nomor pesanan, dan kode model muncul di query pengguna nyata terus-menerus. Itulah ujian sebenarnya: tarik sepuluh query nyata dari log kamu sendiri dan hitung berapa banyak yang mengandung identifier persis yang tidak akan pernah ditempatkan dengan benar oleh model embedding berbasis parafrase. Nol, lewati hybrid. Lebih dari satu atau dua, bangun.

Pencarian hybrid bukan peningkatan universal; jika korpus kamu tidak punya SKU, ID, atau pencarian istilah langka, kamu mungkin menambahkan kompleksitas fusi untuk kenaikan yang tidak akan pernah kamu sadari.

Biayanya nyata tapi terbatas: lintasan retrieval kedua, langkah fusi, dan parameter pembobotan yang kini harus dimiliki seseorang. Kami sengaja tidak mengutip angka latensi di sini, karena angka-angka yang beredar datang dari setup tanpa nama di hardware tanpa nama, dan milik kamu akan berbeda. Ukur di korpus kamu sendiri sebelum memutuskan. Dua thread Hacker News menangkap ketegangan praktis nyata di sini: "Hybrid Search Is Just the Beginning: Optimizing the R in RAG" dan "Better RAG Results with Reciprocal Rank Fusion and Hybrid Search". Kedua thread mendorong balik adopsi hybrid sebagai best practice cargo-cult tanpa memeriksa dulu apakah korpus kamu bahkan punya pola query yang dimaksud untuk dipecahkan. Sebelum membangunnya, layak dipahami cara benar-benar mengukur kualitas retrieval: angka NDCG dan recall@k hanya berarti terhadap korpus kamu sendiri, bukan dataset benchmark.

Pendapat kami: default ke hybrid untuk sistem RAG apa pun yang melayani query support, e-commerce, atau tiket yang menghadap pengguna. Beban kerja itu hampir selalu mencampurkan identifier dengan bahasa alami. Lewati untuk korpus naratif saja (dokumen panjang, wiki naratif) sampai kamu mengukur celah nyata yang dibiarkan terbuka oleh retrieval metode tunggal.

Tentang Penulis

Mert Batur adalah Co-Founder Techsy.io, tempat tim menghadirkan agen AI, sistem otomasi, dan pipeline voice/SDR untuk klien B2B. Ia menulis tentang stack tooling LLM yang benar-benar dipakai tim Techsy di produksi. Terhubung di LinkedIn.

Pertanyaan yang Sering Diajukan

Apa itu pencarian hybrid di RAG?

Pencarian hybrid menjalankan retrieval BM25 (kata kunci) dan vektor (semantik) sebagai lintasan terpisah untuk query yang sama, lalu menggabungkan dua daftar berperingkat dengan algoritma fusi, biasanya Reciprocal Rank Fusion. Ia menangkap kedua jenis: query kecocokan persis dan query konseptual yang diparafrase, yang tidak bisa ditangani metode mana pun sendirian.

Apakah BM25 sama dengan pencarian vektor?

Tidak. BM25 adalah pencarian leksikal sparse yang memberi skor pada tumpang tindih dan kelangkaan istilah persis. Pencarian vektor adalah pencarian semantik dense yang memakai embedding dan matematika kemiripan. Keduanya dua metode retrieval berbeda dengan kekuatan berlawanan; pencarian hybrid menggabungkan, bukan menggantikan salah satunya.

Bagaimana cara menggabungkan BM25 dan pencarian vektor?

Jalankan kedua metode retrieval secara independen untuk query yang sama, lalu fusikan dua daftar hasil berperingkat, paling sering dengan Reciprocal Rank Fusion, yang menjumlahkan 1 / (k + rank) di setiap daftar. Kombinasi skor berbobot alpha adalah alternatifnya, tapi butuh tuning per korpus yang tidak dibutuhkan RRF.

Apa itu Reciprocal Rank Fusion (RRF)?

RRF adalah algoritma fusi dari paper SIGIR 2009 Cormack, Clarke, dan Buettcher yang menggabungkan beberapa daftar berperingkat dengan menjumlahkan 1 / (k + rank) untuk setiap dokumen, dengan k biasanya disetel 60. Ia bekerja pada posisi peringkat, bukan skor mentah, jadi tetap stabil melintasi ketidakcocokan skala antar metode retrieval.

Apa perbedaan antara RRF dan fusi berbobot alpha?

RRF menggabungkan peringkat dan tidak butuh tuning per korpus. Fusi berbobot alpha menggabungkan skor ternormalisasi memakai parameter alpha yang bisa disetel, yang bisa lebih baik mencerminkan besaran keyakinan tapi menuntut penyetelan ulang terus-menerus setiap kali distribusi skor bergeser, seperti setelah reindex atau penggantian model.

Kapan saya harus memakai pencarian hybrid alih-alih pencarian vektor saja?

Pakai pencarian hybrid ketika query kamu mencampurkan identifier persis (SKU, nomor pesanan, kode error) dengan pertanyaan konseptual bahasa alami; sistem support, e-commerce, dan tiket biasanya begitu. Lewati untuk konten naratif saja tanpa identifier, di mana kompleksitas fusi tambahan kemungkinan tidak akan menunjukkan kenaikan yang terukur.

Kenapa pencarian vektor melewatkan kecocokan persis seperti SKU atau kode error?

Model embedding belajar dari pola bahasa umum, dan string seperti "SKU-4471" atau "ERR_CONN_RST" jarang muncul sebagai konsep yang berbeda dan terisolasi di data pelatihan. Model tidak punya alasan kuat untuk menempatkan string persis itu lebih dekat ke dirinya sendiri daripada ke token yang terkait secara semantik tapi salah.

Database vektor mana yang mendukung pencarian hybrid secara native?

Weaviate, Qdrant, Elasticsearch, OpenSearch, Vespa, dan Milvus semuanya menghadirkan pencarian hybrid native per 2026, meski metode fusi default mereka berbeda (RRF vs berbobot alpha vs normalisasi). Postgres dengan pgvector juga bisa menjalankan pencarian hybrid, tapi butuh ekstensi BM25 karena ts_rank native bukan BM25 sungguhan.

Apakah pencarian hybrid sepadan dengan kompleksitas tambahan?

Untuk korpus yang mencampurkan query kecocokan persis dan konseptual, ya. RRF polos sudah mengalahkan kedua metode tunggal di benchmark WANDS (0,7068 vs 0,6983 milik BM25), dan varian yang di-tuning mencapai kenaikan 7,4% (0,7497). Untuk korpus naratif saja tanpa identifier, lintasan retrieval kedua dan tuning fusi yang dibutuhkannya mungkin melebihi kenaikan yang tidak akan kamu sadari. Ukur sebelum berkomitmen.

Bisakah Postgres/pgvector melakukan pencarian hybrid tanpa database vektor khusus?

Bisa. Pasangkan pgvector untuk kemiripan dense dengan ekstensi BM25 sungguhan seperti pg_textsearch, VectorChord, atau ParadeDB (ts_rank native saja hanya mencetak 0,07 NDCG@10 di benchmark pg_textsearch/pgvector Pedro Alonso, versus 0,70 untuk hybrid), lalu fusikan dua daftar berperingkat dengan RRF, semuanya di dalam satu instance Postgres.

Kedua metode retrieval meninggalkan celah nyata ketika dijalankan sendiri: BM25 melewatkan parafrase, pencarian vektor melewatkan identifier persis, dan memfusikan keduanya dengan RRF adalah cara yang lebih rendah perawatannya untuk menutup keduanya. Kalau kamu sedang menimbang membangun ini sendiri atau membawa tim yang sudah pernah menghadirkan retrieval RAG sebelumnya, panduan lengkap membangun aplikasi RAG kami membahas langkah berikutnya, atau hubungi kami jika kamu lebih suka Techsy membangunnya bersama kamu.