Reranking: Cara Developer Indonesia Menaikkan Akurasi RAG Tanpa Memperbesar Context Window

TL;DR: Reranking adalah tahap pasca-retrieval yang menyusun ulang kandidat dokumen pakai model lebih cermat (cross-encoder). Praktiknya menaikkan presisi top-3 sebesar 10-30% di sistem RAG produksi tanpa harus memperbesar context window. Trade-offnya tambahan latensi 100-500 ms per query.

Banyak tim Indonesia yang sudah punya RAG masih mengeluh jawaban LLM "hampir benar" tapi sering meleset. Penyebabnya jarang model. Lebih sering, retrieval mengirim 5 dokumen yang mirip secara vektor tapi tidak menjawab pertanyaan inti.

Dalam beberapa proyek terakhir, saya melihat pola yang sama berulang. Tim memperbesar context window, mengganti embedding model, atau menambah dokumen di vector database. Hasilnya marginal. Yang sebenarnya kurang adalah lapisan reranker.

Kenapa Retrieval Saja Tidak Cukup

Vector database bekerja dengan menghitung kemiripan kosinus antara query embedding dan dokumen embedding. Cepat, tapi kasar. Dua dokumen bisa punya skor mirip karena sama-sama menyebut "harga produk", padahal satu menjelaskan harga retail dan satunya harga grosir.

Reranker membaca query dan dokumen secara berdampingan dalam satu model (cross-encoder). Skornya lebih akurat karena model bisa menangkap konteks pertanyaan, bukan hanya kata kunci. Trade-offnya kecepatan: cross-encoder lebih lambat dibanding bi-encoder, jadi tidak praktis untuk menyaring jutaan dokumen sekaligus.

Arsitektur Dua Tahap yang Lazim

Arsitektur ini disebut retrieve-then-rerank. Top-k retrieval melebar (50-100 dokumen) supaya kandidat tepat tidak hilang. Reranker lalu mempersempit ke 3-5 dokumen yang benar-benar relevan sebelum dikirim ke LLM.

Studi Kasus: Atmo (LMS)

Saat membangun fitur Q&A internal di Atmo, kami pakai pgvector untuk retrieval modul pelatihan. Awalnya, jawaban LLM sering mencampur konteks dari modul berbeda karena top-5 hasil retrieval semuanya menyebut istilah yang sama. Setelah memasang Cohere Rerank di tengah pipeline, presisi top-3 naik dan jawaban LLM jadi lebih konsisten dengan modul yang ditanyakan.

Yang penting dicatat: kami tidak mengganti embedding model atau menambah data. Hanya menambah lapisan reranker. Itu bukti bahwa banyak masalah akurasi RAG sebenarnya masalah ranking, bukan retrieval.

Kapan Reranking Tidak Diperlukan

Reranking bukan obat segala penyakit. Skip kalau:

• Korpus kecil di bawah 1.000 dokumen, query sederhana, dan top-3 retrieval sudah konsisten benar.
• Aplikasi butuh latensi sub-200 ms (misal autocomplete real-time).
• Budget API ketat dan trade-off akurasinya tidak signifikan.

Sebaliknya, reranking memberi dampak besar saat dokumen panjang, query ambigu, atau bahasa campuran (ID dan EN). Dokumentasi Cohere Rerank menyebut peningkatan NDCG di banyak benchmark mendekati 20% dibanding hybrid search saja.

Trade-off yang Harus Dipertimbangkan

Tambahan latensi 100-500 ms terdengar kecil, tapi bertambah saat digabung dengan latensi LLM. Untuk produk berbahasa Indonesia yang melayani pengguna mobile dengan koneksi lambat, total waktu tunggu di atas 5 detik menurunkan engagement. Strategi mitigasi: streaming response dari LLM sambil reranker bekerja di background untuk follow-up query, atau cache hasil reranker untuk query yang sering muncul lewat LLM cache.

Pertanyaan Umum

Berapa biaya tambahan reranking di skala produksi?

Cohere Rerank per April 2026 dibandrol sekitar 1 USD per 1.000 search request. Untuk produk dengan 10.000 query per hari, biaya bulanan sekitar 300 USD. Bandingkan dengan biaya retraining embedding atau memperbesar model LLM yang biasanya jauh lebih mahal.

Apakah bisa pakai LLM sebagai reranker?

Bisa, tapi mahal dan lambat. Cross-encoder khusus reranker dirancang lebih efisien dibanding LLM general-purpose. Pakai LLM sebagai reranker hanya untuk korpus kecil dengan query kompleks.

Bagaimana cara mengukur dampak reranking?

Pakai NDCG@k atau MRR (mean reciprocal rank) di evaluation set yang sudah di-label manusia. Minimal 50-100 query dengan ground truth, lalu bandingkan skor sebelum dan sesudah reranking. Lihat juga dokumentasi Pinecone tentang evaluasi RAG.

Reranking Bukan Tambalan, Tapi Lapisan

Banyak tim memperlakukan reranking seperti tambalan saat retrieval bermasalah. Lebih akurat: reranking adalah lapisan terpisah dengan tugas berbeda dari retrieval. Retrieval mengejar recall, reranking mengejar precision. Keduanya saling melengkapi, bukan menggantikan. Tim yang membangun LLM grounding serius perlu menganggap reranker sebagai komponen pertama, bukan terakhir, dalam siklus optimasi RAG.