Reranking di RAG Brand Indonesia: Cara Naikkan Akurasi Asisten AI Tanpa Ganti Model di 2026

TL;DR: Reranker adalah lapisan kedua di pipeline Retrieval-Augmented Generation yang menyusun ulang kandidat dokumen sebelum dikirim ke LLM. Dalam beberapa proyek RAG yang saya bantu, menambah reranker yang tepat menurunkan jawaban tidak relevan dalam kisaran 20-40% tanpa perlu mengganti model utama. Brand Indonesia yang ingin chatbot AI dipakai tim, bukan diabaikan, sebaiknya memperlakukan reranker sebagai bagian dari arsitektur sejak awal.

Banyak tim Indonesia mulai membangun asisten AI internal pada akhir 2024 dan awal 2025. Hampir semua memakai pola Retrieval-Augmented Generation: ambil dokumen relevan dari knowledge base, suntikkan ke prompt LLM, lalu kirim ke pengguna. Setelah enam sampai dua belas bulan beroperasi, keluhan yang sering muncul mirip: jawaban terdengar percaya diri tapi melenceng dari pertanyaan, atau dokumen yang dirujuk tidak benar-benar menjawab maksud penanya.

Akar masalahnya jarang ada di model utama. Lebih sering ada di tahap retrieval, terutama ketika pipeline hanya mengandalkan satu langkah pencarian vektor tanpa memilah ulang kandidat yang dikembalikan.

Masalah Retrieval Satu Tahap

Saat tim merancang RAG dengan cara paling sederhana, mereka menyimpan dokumen di vector database, mengonversi pertanyaan jadi embedding, lalu mengambil 5 sampai 10 dokumen paling mirip secara cosine similarity. Dokumen ini langsung dimasukkan ke prompt LLM. Pola ini cepat dan murah, tapi punya kelemahan utama: kemiripan vektor bukan jaminan relevansi.

Pertanyaan "Berapa biaya pengembalian produk yang rusak?" mungkin memunculkan dokumen tentang prosedur retur, dokumen tentang biaya pengiriman, dan dokumen tentang produk yang sudah dihentikan. Ketiganya mirip secara semantik dengan pertanyaan, tapi hanya satu yang benar-benar menjawabnya. Tanpa lapisan kedua untuk menyaring, LLM bisa menyatukan ketiganya jadi jawaban yang terdengar masuk akal namun tidak akurat.

Apa yang Reranker Lakukan

Reranker adalah model kecil khusus yang membaca pertanyaan dan setiap kandidat dokumen secara berpasangan, lalu memberi skor relevansi yang lebih halus. Arsitekturnya biasanya cross-encoder, yang lebih lambat dibanding bi-encoder embedding tapi jauh lebih akurat untuk menilai pasangan pertanyaan-jawaban.

Pipeline lengkapnya jadi seperti ini: pertanyaan masuk, retriever vektor mengambil 50 sampai 200 kandidat awal, reranker menilai dan menyusun ulang, hasil 5 sampai 10 teratas dikirim ke LLM. Pola ini disebut two-stage retrieval dan sudah jadi praktik standar di sistem pencarian modern.

Kapan Reranker Memberi Dampak Paling Besar

Praktik standar di industri menunjukkan reranker memberi nilai paling besar saat basis dokumen tumbuh dan pertanyaan jadi lebih beragam. Tim yang baru mulai dengan beberapa ratus dokumen sebaiknya memprioritaskan kualitas chunking dulu, baru menambah reranker setelah skala bertambah.

Studi Kasus dari Proyek

Saat membantu sebuah tim e-commerce membangun asisten AI untuk customer support internal, basis dokumen mereka ada sekitar 12.000 entri kebijakan, FAQ, dan log percakapan masa lalu. Versi pertama tanpa reranker menghasilkan jawaban yang dilaporkan tim CS sebagai "kurang nyambung" di sekitar tiga dari sepuluh kasus. Setelah menambahkan reranker open-source ringan dan menurunkan jumlah kandidat awal dari 100 menjadi 50, rasio jawaban yang dipakai langsung tanpa edit naik dalam kisaran yang membuat tim merasa nyaman mengandalkannya untuk pertanyaan rutin.

Yang menarik, kami tidak mengganti LLM utama sama sekali. Bagian yang berubah hanya pipeline di antara database dan model. Biaya inferensi memang naik sedikit karena ada langkah ekstra, tapi nilai dari kualitas jawaban yang lebih tinggi jauh melampaui selisih biaya itu.

Kerangka Memilih Reranker

Untuk tim Indonesia yang ingin mulai, saya biasanya menyarankan kerangka tiga pertanyaan ini sebelum memilih model.

Pertama, seberapa beragam pertanyaan pengguna. Kalau pertanyaan datang dari banyak departemen dengan istilah yang berbeda, reranker yang dilatih multibahasa atau multidomain akan lebih cocok dibanding reranker spesifik domain tunggal.

Kedua, latency yang dapat diterima. Reranker cross-encoder menambah ratusan milidetik ke total waktu respons. Kalau aplikasi butuh respon di bawah satu detik, pilih reranker yang lebih kecil atau pertimbangkan pendekatan hybrid.

Ketiga, anggaran inferensi. Reranker open-source seperti yang ada di Cohere, Voyage, atau model terbuka di Hugging Face memberi banyak pilihan trade-off antara biaya dan kualitas.

Pertanyaan Umum

Apakah reranker selalu membuat sistem lebih lambat?

Iya, ada penalti latency. Tapi karena reranker hanya memproses 50-200 kandidat, bukan seluruh basis dokumen, dampaknya bisa ditekan dengan memilih model yang efisien dan menjalankan reranker di GPU yang sama dengan retriever.

Apakah saya bisa pakai LLM utama sebagai reranker?

Bisa secara teknis, tapi mahal dan lambat. Reranker khusus jauh lebih efisien karena tugasnya sempit dan modelnya lebih kecil.

Apakah hybrid search mengganti kebutuhan reranker?

Tidak. Hybrid search menggabungkan retrieval vektor dan keyword di tahap pertama. Reranker tetap di tahap kedua, dan biasanya hybrid search plus reranker memberi hasil terbaik.

Bagaimana mengukur dampak reranker?

Bandingkan rasio jawaban yang dipakai pengguna tanpa edit, recall@k pada dataset evaluasi yang Anda buat sendiri, dan skor kepuasan pengguna lewat feedback eksplisit. Lihat juga Agent Confidence Score untuk metrik komplementer.

Apakah ini berlaku untuk content publik di website juga?

Iya. Reranker membantu pencarian internal di situs e-commerce, dokumentasi, atau katalog produk. Pola arsitekturnya sama meski use case-nya berbeda dari chatbot internal.

Penutup

Reranker bukan komponen ajaib yang menyelesaikan semua masalah RAG. Tapi untuk brand Indonesia yang sudah punya basis dokumen lumayan besar dan masih kecewa dengan kualitas jawaban asisten AI, lapisan ini sering jadi pintu masuk paling efisien untuk perbaikan tanpa membongkar arsitektur. Kuncinya, pasang sejak desain awal kalau Anda tahu basis dokumen akan tumbuh, atau retrofit secepatnya begitu skala mulai terasa. Bacaan lanjutan praktis ada di dokumentasi Cohere Rerank dan riset BEIR benchmark untuk evaluasi.