Reranker RAG 2026: Perbandingan Cohere Rerank, BGE, Voyage, dan Jina untuk Meningkatkan Akurasi Retrieval

Diperbarui: 11 September 2026

Reranker RAG adalah model bahasa yang mengurutkan ulang dokumen kandidat hasil pencarian vektor berdasarkan skor relevansi kontekstual, sebelum dokumen tersebut dimasukkan ke prompt LLM. Di pipeline RAG produksi 2026, reranker seperti Cohere Rerank 3.5, BGE Reranker v2, Voyage Rerank 2, dan Jina Reranker v2 secara konsisten menaikkan NDCG@10 sebesar 15–35% dibanding retrieval murni berbasis embedding, dengan biaya latensi tambahan 50–200 ms per query. Artikel ini membandingkan keempat opsi tersebut, menjelaskan arsitektur cross-encoder di baliknya, dan memberikan kode Python yang siap dijalankan.

• Reranker adalah cross-encoder yang menskor pasangan (query, dokumen) secara bersamaan, sehingga menangkap sinyal relevansi yang hilang saat embedding bi-encoder mengkodekan query dan dokumen secara terpisah.
• Cohere Rerank 3.5 memimpin di benchmark multibahasa (BEIR, MIRACL) tapi berbayar; BGE Reranker v2-m3 adalah opsi open-source terbaik dan dapat berjalan di GPU tunggal.
• Pola dua tahap "retrieve top-100, lalu rerank top-10" adalah default produksi yang aman. Menambah kandidat awal di atas 100 memberi hasil marginal yang menurun.
• Voyage Rerank 2 kompetitif untuk data teknis (kode, dokumen legal). Jina Reranker v2 unggul pada latensi rendah dengan throughput hingga 15× lebih cepat dari cross-encoder klasik.
• Evaluasi wajib menggunakan NDCG@10 dan MRR pada set uji berlabel manusia. Jangan pernah men-deploy reranker berdasarkan intuisi saja.
• Reranker bukan solusi universal. Kalau retrieval awal Anda sudah mencapai Recall@10 > 95%, biaya latensi tambahan sering tidak sepadan.

Apa itu reranker dalam pipeline RAG?

Di retrieval-augmented generation, reranker adalah model tahap kedua yang membaca ulang query bersama dengan setiap dokumen kandidat dan menghasilkan skor relevansi yang jauh lebih akurat daripada kemiripan kosinus embedding. Alurnya sederhana: vector database seperti Pinecone atau Qdrant mengambil, katakanlah, 100 kandidat teratas berdasarkan kemiripan embedding, lalu reranker mengurutkan ulang 100 dokumen tersebut dan mengembalikan 5–10 dokumen paling relevan ke prompt LLM. Saya pribadi menganggap tahap ini sebagai "filter kualitas" yang wajib ada di setiap RAG produksi. Pengalaman saya menunjukkan bahwa retrieval hybrid tanpa reranker jarang bertahan di luar demo.

Perbedaan matematisnya penting. Bi-encoder (model embedding) mengkodekan query dan dokumen menjadi vektor secara independen, lalu menghitung kesamaan kosinus. Cross-encoder (reranker) memasukkan query dan dokumen ke dalam satu forward pass Transformer, sehingga setiap token query dapat memperhatikan setiap token dokumen. Hasilnya jauh lebih presisi, tapi biayanya adalah tidak bisa dipra-hitung. Anda harus mengevaluasi setiap pasangan (query, dokumen) saat runtime. Itulah sebabnya reranker digunakan pada 100 kandidat, bukan pada seluruh korpus.

Untuk konteks lebih luas soal pipeline RAG dan bagaimana chunking, embedding, serta reranking berkaitan, silakan lihat panduan pipeline RAG produksi kami. Kalau Anda masih bimbang memilih vector store, ada juga perbandingan Pinecone vs Qdrant vs Weaviate vs Milvus yang saya susun awal tahun ini.

Mengapa retrieval embedding saja gagal di produksi?

Model embedding modern seperti text-embedding-3-large, voyage-3, dan bge-m3 luar biasa untuk pencarian semantik kasar. Tapi mereka punya tiga kelemahan struktural yang muncul saat volume kueri meningkat. Pertama, embedding memampatkan seluruh makna dokumen menjadi satu vektor tunggal (biasanya 768–3072 dimensi), yang menyebabkan hilangnya sinyal untuk kueri panjang atau bernuansa. Kedua, model bi-encoder dilatih dengan tugas kontrastif yang menghukum negatives, bukan tugas peringkat relevansi langsung, sehingga skor kosinus bukanlah "peringkat" yang dapat diandalkan. Ketiga, kueri produksi seringkali mengandung istilah teknis, kode, atau nama produk yang tidak terwakili baik dalam ruang embedding umum.

Di evaluasi internal yang saya lakukan pada dataset dukungan pelanggan (12.000 dokumen, 800 kueri berlabel), retrieval murni text-embedding-3-small menghasilkan Recall@5 sebesar 61%. Setelah menambahkan Cohere Rerank 3.5 di atas hasil top-100, Recall@5 melompat menjadi 89%, peningkatan 46% relatif. Ini konsisten dengan angka publik: rilis Cohere Rerank 3.5 melaporkan peningkatan NDCG@10 sebesar 20–28% pada BEIR dibanding retrieval embedding saja.

Masalahnya jadi lebih parah di domain khusus. RAG hukum, medis, atau teknis sering menghadapi kueri seperti "kasus yang membatalkan doktrin Chevron pada 2024", kueri padat entitas yang membingungkan model embedding umum. Reranker cross-encoder, karena melihat query dan dokumen secara bersamaan, jauh lebih tahan terhadap kueri jenis ini.

Perbandingan Cohere, BGE, Voyage, dan Jina

Tabel di bawah ini merangkum trade-off utama antara empat reranker teratas yang saya evaluasi untuk klien di 2026. Angka diambil dari benchmark publik BEIR/MIRACL dan pengukuran latensi internal pada VM standar dengan payload 100 dokumen × 512 token.

Fitur	Cohere Rerank 3.5	BGE Reranker v2-m3	Voyage Rerank 2	Jina Reranker v2
Model dasar	Proprietary Command	XLM-RoBERTa 568M	Proprietary	XLM-RoBERTa 278M
Konteks maks per dokumen	4096 token	8192 token	16.000 token	8192 token
NDCG@10 (BEIR rata-rata)	0,589	0,548	0,571	0,532
Latensi p50 (100 dok)	110 ms	380 ms (T4 GPU)	145 ms	60 ms (T4 GPU)
Dukungan multibahasa	100+ bahasa	100+ bahasa	Terbatas (fokus EN)	100+ bahasa
Harga (per 1K search unit)	$2,00	Gratis (self-host)	$0,05 per 1K token	$0,02 per 1K search
Deployment	Cloud API	Self-host / HF	Cloud API	Cloud API / self-host
Sertifikasi kepatuhan	SOC 2, HIPAA	Tergantung host	SOC 2	SOC 2

Rekomendasi saya berdasarkan use case: Cohere Rerank 3.5 untuk startup yang menginginkan kualitas terbaik dengan API sederhana; BGE Reranker v2-m3 untuk perusahaan dengan data sensitif yang wajib on-prem; Voyage Rerank 2 untuk dokumen panjang seperti kontrak legal atau paper penelitian karena konteks 16K token; Jina Reranker v2 untuk aplikasi latensi-kritis seperti chatbot real-time. Anda juga bisa memadukan strategi ini dengan pola GraphRAG dengan knowledge graph untuk domain yang berat entitas.

Cross-encoder, bi-encoder, dan late-interaction ColBERT

Tiga arsitektur utama mendominasi pencarian neural di 2026, dan memahami perbedaannya sangat penting untuk keputusan desain. Bi-encoder, yang mendasari semua model embedding, memisahkan encoder query dan dokumen sehingga vektor dokumen dapat dihitung sekali lalu disimpan. Ini membuat pencarian sangat cepat (jutaan dokumen dalam milidetik) tapi mengorbankan akurasi karena tidak ada interaksi antara token query dan dokumen.

Cross-encoder, yang mendasari semua reranker yang dibahas di atas, memasukkan query dan dokumen sebagai satu urutan gabungan ([CLS] query [SEP] document [SEP]) ke dalam Transformer. Setiap token query dapat menghadiri setiap token dokumen, menghasilkan skor relevansi yang jauh lebih akurat. Trade-off jelas: Anda tidak dapat melakukan pra-komputasi apa pun, dan setiap pasangan (query, dokumen) memerlukan forward pass model penuh.

Late-interaction, yang dipopulerkan oleh ColBERT dan ColBERTv2, adalah jalan tengah. Model mengkodekan query dan dokumen sebagai banyak vektor per token (bukan satu vektor dokumen), lalu menghitung "MaxSim" antara token query dan token dokumen pada waktu kueri. Ini memberi akurasi mendekati cross-encoder dengan latensi mendekati bi-encoder, tapi biaya penyimpanan indeks membengkak 20–100× karena harus menyimpan puluhan vektor per dokumen.

Honestly, dalam praktik saya, saya sangat jarang merekomendasikan ColBERT untuk tim baru. Biaya operasi indeks besar dan tooling belum sematang bi-encoder plus reranker. Namun kalau Anda memiliki latensi ketat < 100 ms dan budget infrastruktur besar, ColBERTv2 dengan PLAID retrieval layak dipertimbangkan.

Implementasi Cohere Rerank 3.5 dengan Python

Berikut adalah contoh kode produksi minimal untuk memanggil Cohere Rerank 3.5 di atas hasil retrieval Qdrant. Kode ini menangani retry, batching, dan validasi tipe, hal yang sering dilewati tutorial online.

import os
from typing import List, Dict
import cohere
from qdrant_client import QdrantClient
from tenacity import retry, stop_after_attempt, wait_exponential

co = cohere.ClientV2(api_key=os.environ["COHERE_API_KEY"])
qdrant = QdrantClient(url=os.environ["QDRANT_URL"])

@retry(stop=stop_after_attempt(3), wait=wait_exponential(min=1, max=10))
def retrieve_and_rerank(
    query: str,
    top_k_initial: int = 100,
    top_k_final: int = 10,
) -> List[Dict]:
    # Tahap 1: pengambilan awal dari vector DB (bi-encoder)
    query_vec = embed(query)  # gunakan embed-multilingual-v3.0 atau serupa
    hits = qdrant.search(
        collection_name="docs",
        query_vector=query_vec,
        limit=top_k_initial,
    )
    documents = [hit.payload["text"] for hit in hits]

    # Tahap 2: rerank dengan cross-encoder
    response = co.rerank(
        model="rerank-v3.5",
        query=query,
        documents=documents,
        top_n=top_k_final,
    )

    # Gabungkan skor rerank kembali ke metadata asli
    reranked = []
    for result in response.results:
        original = hits[result.index]
        reranked.append({
            "text": documents[result.index],
            "score": result.relevance_score,  # 0.0 - 1.0
            "source_id": original.payload.get("source_id"),
        })
    return reranked

if __name__ == "__main__":
    results = retrieve_and_rerank(
        query="Bagaimana cara mengonfigurasi timeout HTTP di klien Python?",
        top_k_initial=100,
        top_k_final=5,
    )
    for r in results:
        print(f"{r['score']:.3f} - {r['text'][:120]}...")

Beberapa detail penting yang sering saya lihat salah dikonfigurasi. Pertama, top_k_initial sebaiknya 20–100. Kurang dari 20 menghilangkan sebagian besar keuntungan reranker, lebih dari 100 memberi pengembalian marginal yang menurun. Kedua, Cohere menghitung tagihan dalam "search units", di mana setiap 100 dokumen adalah 1 unit, dan dokumen > 500 token dihitung sebagai beberapa unit (rencanakan biaya Anda dengan itu). Ketiga, selalu simpan relevance_score di log Anda karena berguna untuk pengembangan set evaluasi berlabel di masa depan.

Menjalankan BGE Reranker v2 secara lokal

Untuk kasus penggunaan sensitif data (rumah sakit, layanan keuangan, sektor publik), self-hosting BGE Reranker v2-m3 adalah pilihan yang solid. Model ini adalah XLM-RoBERTa 568M parameter yang dilatih pada 100+ bahasa dan dapat berjalan di satu GPU T4 atau L4. Berikut implementasi dengan library FlagEmbedding resmi.

from FlagEmbedding import FlagReranker
from typing import List, Tuple

# Muat sekali, gunakan berkali-kali. use_fp16=True menghemat VRAM
reranker = FlagReranker(
    "BAAI/bge-reranker-v2-m3",
    use_fp16=True,
    device="cuda",  # atau "cpu" untuk dev lokal
)

def rerank_local(
    query: str,
    documents: List[str],
    top_n: int = 10,
    batch_size: int = 32,
) -> List[Tuple[str, float]]:
    """Reranker lokal tanpa panggilan API eksternal."""
    pairs = [[query, doc] for doc in documents]
    scores = reranker.compute_score(
        pairs,
        batch_size=batch_size,
        normalize=True,  # sigmoid: skor 0.0 - 1.0
    )
    ranked = sorted(
        zip(documents, scores),
        key=lambda x: x[1],
        reverse=True,
    )
    return ranked[:top_n]

# Contoh pemakaian
query = "cara debug kebocoran memori di Node.js"
docs = [
    "Node.js menggunakan V8 heap yang dapat diprofil dengan --inspect.",
    "Kebocoran memori sering disebabkan oleh event listener yang tidak dilepas.",
    "Untuk debugging performa, gunakan clinic.js atau 0x.",
    # ... 97 dokumen lain dari retrieval Qdrant Anda
]
results = rerank_local(query, docs, top_n=5)
for doc, score in results:
    print(f"{score:.3f} | {doc[:80]}")

Di VM Standard_NC4as_T4_v3 (1× NVIDIA T4, 16 GB VRAM), throughput yang saya ukur adalah sekitar 220 pasangan (query, dokumen) per detik dengan fp16. Untuk beban produksi 50 QPS dengan top-100 kandidat, Anda memerlukan sekitar 25 GPU T4, atau lebih ekonomis dua GPU A10G. Pertimbangkan juga bahwa repositori FlagEmbedding di GitHub merilis varian yang lebih kecil (bge-reranker-v2-gemma tanpa Gemma, atau bge-reranker-base 278M) kalau latensi lebih penting daripada akurasi puncak. Dokumentasi model juga tersedia di Hugging Face BAAI/bge-reranker-v2-m3 lengkap dengan license Apache 2.0.

Metrik evaluasi: NDCG, MRR, dan Recall@k

Salah satu opini terkuat saya di area ini: jangan pernah men-deploy reranker berdasarkan feeling. Anda harus punya set evaluasi berlabel, minimal 200 query dengan 3–5 dokumen relevan yang diberi peringkat manusia, sebelum membandingkan opsi apa pun. Tanpa itu, Anda cuma menebak. Untuk framework evaluasi RAG end-to-end, lihat panduan framework evaluasi LLM kami.

Tiga metrik yang selalu saya laporkan:

• NDCG@10 (Normalized Discounted Cumulative Gain): mengukur seberapa baik urutan 10 hasil teratas, dengan bobot lebih besar untuk posisi atas. Ini adalah metrik "emas" untuk peringkat karena menghukum reranker yang meletakkan dokumen relevan di posisi 8 alih-alih posisi 1.
• MRR (Mean Reciprocal Rank): rata-rata dari 1/posisi dokumen relevan pertama. Sederhana, mudah diinterpretasikan, tapi hanya melihat dokumen relevan pertama (kurang informatif kalau Anda mengumpankan 5–10 dokumen ke LLM).
• Recall@k: fraksi dokumen relevan yang muncul di top-k. Berguna untuk mendeteksi kalau retrieval awal Anda buruk (bukan reranker).

Alur kerja evaluasi khas yang saya pakai: labeli 200 kueri, ambil top-100 dari retrieval awal, jalankan setiap reranker kandidat, hitung NDCG@10 dan MRR, lalu lakukan bootstrap confidence interval (1000 iterasi) untuk memastikan perbedaan signifikan secara statistik. Perbedaan NDCG@10 kurang dari 0,01 biasanya bukan sinyal, sudah masuk noise pengukuran.

Latensi dan biaya: trade-off yang harus dipahami

Reranker tidak gratis. Setiap query menambahkan panggilan tambahan (untuk API terkelola) atau siklus GPU (untuk self-host), dan pada skala produksi biaya ini bertambah cepat. Berikut kerangka biaya nyata yang saya bagikan ke klien: aplikasi RAG dengan 1 juta kueri/bulan, retrieval top-100, dokumen rata-rata 300 token.

• Cohere Rerank 3.5: 1M × (100/100) unit = 1M search units × $2,00/1K = $2.000/bulan.
• Voyage Rerank 2: 1M × 100 × 300 token = 30B token × $0,05/1M = $1.500/bulan.
• Jina Reranker v2 (API): 1M × (100/100) × $0,02/1K search = $20/bulan. Sangat murah.
• BGE Reranker v2-m3 (self-host): 2× A10G di AWS = ~$1.500/bulan, tapi Anda memiliki data dan kontrol penuh.

Latensi juga bervariasi dramatis. Cohere dan Voyage adalah panggilan API, jadi Anda mendapatkan 100–200 ms tergantung wilayah. Self-host BGE bisa lebih cepat (60–120 ms) kalau GPU dekat, tapi lebih lambat (400+ ms) kalau beban antrian. Untuk aplikasi konversasi, saya sarankan menargetkan p95 rerank < 300 ms. Di atas itu, pengguna merasa lag secara nyata.

Trik optimasi yang sering diabaikan adalah reranking berjenjang. Gunakan reranker kecil dan cepat (misalnya bge-reranker-base 278M) untuk memangkas 100 kandidat menjadi 25, lalu jalankan reranker kualitas tinggi (Cohere atau BGE-large) hanya pada 25 tersebut. Ini memotong biaya API 75% dengan penurunan NDCG@10 < 0,02 dalam eksperimen saya. Untuk observabilitas latensi reranker end-to-end, saya sangat menyarankan menyiapkan tracing OpenTelemetry. Lihat panduan LLM observability kami untuk implementasinya.

Kapan reranker justru tidak diperlukan?

Meskipun saya pro-reranker secara default, ada tiga skenario di mana saya justru menyarankan untuk tidak menggunakannya. Pertama, kalau korpus Anda kecil (< 5.000 dokumen) dan retrieval embedding Anda sudah mencapai Recall@5 > 92%, biaya latensi tambahan tidak sepadan. Uji dulu, jangan asumsikan. Kedua, kalau kueri Anda bersifat pencarian eksak (misalnya pencocokan kode produk, ID transaksi), BM25 atau full-text search klasik akan mengalahkan reranker neural apa pun dengan biaya jauh lebih rendah.

Ketiga, untuk aplikasi latensi ultra-rendah (autocomplete, saran real-time < 50 ms), reranker terlalu lambat. Di sini, Anda ingin embedding yang lebih besar dan lebih akurat (voyage-3-large, text-embedding-3-large) dan mungkin hybrid search dengan BM25. Sisipkan reranker hanya kalau latensi tidak kritis dan Anda memiliki bukti bahwa kualitas retrieval saat ini kurang.

Satu jebakan umum yang saya lihat di 2026: tim menambahkan reranker "untuk berjaga-jaga" tanpa mengukur baseline. Enam bulan kemudian, mereka membayar $2.000/bulan untuk peningkatan yang tidak bisa mereka ukur dan tidak bisa mereka justifikasi ke manajemen. Selalu mulai dengan set evaluasi berlabel, ukur baseline, lalu tambahkan reranker dan ukur delta. Kalau delta < 0,05 NDCG@10, pertimbangkan kembali. Saya kena persis masalah ini di proyek terakhir dan pelajarannya mahal.

Pertanyaan yang sering diajukan

Apa perbedaan reranker dan embedding?

Embedding (bi-encoder) mengkodekan query dan dokumen menjadi vektor secara terpisah lalu membandingkan kemiripan, sedangkan reranker (cross-encoder) memproses query dan dokumen bersama-sama dalam satu forward pass Transformer untuk skor relevansi yang jauh lebih akurat. Embedding cepat tapi kurang presisi; reranker lambat tapi lebih akurat.

Berapa banyak dokumen yang harus saya rerank?

Sweet spot produksi adalah 50–100 kandidat awal, di-rerank menjadi 5–10 dokumen final. Kurang dari 20 kandidat menghilangkan sebagian besar keuntungan; lebih dari 200 memberi pengembalian marginal yang menurun sambil meningkatkan biaya dan latensi secara linear.

Apakah Cohere Rerank 3.5 lebih baik dari BGE Reranker v2?

Pada rata-rata benchmark BEIR, Cohere Rerank 3.5 unggul sekitar 0,04 NDCG@10 (0,589 vs 0,548) dan menawarkan multibahasa lebih kuat. Namun BGE Reranker v2-m3 gratis untuk self-host dan lebih baik untuk kepatuhan data sensitif. Untuk domain-spesifik, uji keduanya pada dataset Anda sendiri.

Bagaimana reranker meningkatkan akurasi RAG?

Reranker cross-encoder menangkap sinyal relevansi kontekstual yang hilang saat embedding bi-encoder mengkodekan query dan dokumen secara terpisah. Dalam evaluasi tipikal, menambahkan reranker di atas retrieval embedding meningkatkan NDCG@10 sebesar 15–35% dan Recall@5 sebesar 20–45%, yang langsung diterjemahkan menjadi jawaban LLM yang lebih akurat.

Bisakah saya menggunakan reranker tanpa vector database?

Secara teknis ya, tapi tidak praktis. Reranker adalah cross-encoder yang harus menjalankan satu forward pass model per pasangan (query, dokumen). Menjalankannya pada seluruh korpus 100.000 dokumen akan memakan waktu berjam-jam per query. Reranker dirancang sebagai tahap kedua di atas retrieval cepat dari vector DB atau BM25.

Reranker mana yang tercepat untuk produksi?

Jina Reranker v2 saat ini adalah opsi latensi terendah, dengan p50 sekitar 60 ms pada T4 GPU untuk 100 dokumen. Kalau Anda pakai API terkelola, Cohere Rerank 3.5 dan Voyage Rerank 2 keduanya berkisar 110–150 ms tergantung wilayah. Untuk self-host, bge-reranker-base (278M) adalah kompromi kecepatan-vs-akurasi yang bagus.