Kelemahan Pencarian Semantik Murni pada Sistem RAG
Banyak sistem retrieval augmented generation atau RAG perusahaan gagal bukan saat model bahasa menjawab, melainkan jauh sebelumnya: saat dokumen dibaca, dipotong, diindeks, lalu dicari kembali. Setelah tahap penulisan indeks diperbaiki lewat parsing sadar tata letak, struktur judul, tabel, nomor halaman, nama berkas, serta breadcrumb heading, masalah berikutnya muncul di jalur baca. Indeks bisa rapi, potongan dokumen bisa bermakna, metadata bisa lengkap, tetapi kueri pertama tetap dapat mengembalikan konteks yang salah. Di sinilah hybrid search menjadi penting. Pencarian semantik murni, pola bawaan banyak tutorial RAG, biasanya hanya menanamkan pertanyaan menjadi vektor, mencari tetangga terdekat, lalu mengambil top k. Pola ini tampak cukup dalam purwarupa, sampai pengguna mencari sesuatu seperti “WH-1000XM5”. Sistem dapat mengembalikan berbagai potongan tentang headphone nirkabel, tetapi bukan potongan yang menyebut model itu secara spesifik. Kegagalan ini bukan urusan prompt. Ini sifat embedding. Model embedding menangkap makna umum, bukan identitas string buram seperti nomor model, kode galat, nomor suku cadang, rujukan klausul kontrak, atau nama proyek internal.
Karakteristik Pencarian Leksikal dan Tantangan Penggabungan Skor
Pencarian leksikal memiliki profil sebaliknya. Ia menemukan token persis seperti WH-1000XM5 dengan cepat karena bekerja berdasarkan kecocokan kata serta statistik istilah. Namun ia lemah saat pengguna bertanya “berapa lama baterainya bertahan” sementara dokumen hanya menulis “waktu pemutaran”. Tidak ada token bersama, maka pencarian leksikal bisa gagal. Karena itu, tidak ada satu retriever yang unggul mutlak. Keduanya gagal pada hal berbeda. Hybrid search menjalankan keduanya, tetapi tantangan sesungguhnya bukan menjalankan dua pencarian; tantangannya menyatukan hasilnya. Menjumlahkan skor mentah tidak memadai karena skor kosinus dari pencarian vektor berskala terbatas, sedangkan skor leksikal seperti ts_rank_cd atau BM25 tidak berbatas tetap, dipengaruhi frekuensi istilah, kedekatan kemunculan, panjang dokumen, serta statistik korpus. Normalisasi min-max pun menipu: daftar leksikal yang seluruhnya lemah tetap akan memberi skor 1,0 kepada kandidat terbaiknya, seolah-olah itu kecocokan sempurna. Sinyal yang ingin diselamatkan justru hilang.
Penyatuan Peringkat Menggunakan Reciprocal Rank Fusion
Solusi yang dipakai ialah Reciprocal Rank Fusion atau RRF, metode yang diperkenalkan Cormack, Clarke, dan Büttcher pada SIGIR 2009. RRF membuang skor asli, lalu memakai posisi peringkat. Rumusnya menjumlahkan 1/(k + rank) untuk setiap daftar, dengan konstanta lazim 60. Efek konstanta ini membuat kurva di peringkat atas relatif datar. Peringkat pertama dan kedua tidak terpaut jauh; yang lebih penting ialah kesepakatan antarretriever. Potongan yang berada di peringkat kedua pada pencarian vektor dan leksikal bisa mengalahkan potongan yang hanya menjadi peringkat pertama di salah satu retriever. Konsensus menang atas keyakinan tunggal. Implementasi dilakukan dalam satu perjalanan ke database. PostgreSQL menjalankan pencarian kata kunci, pencarian vektor, pemberian ROW_NUMBER sebagai rank, penggabungan FULL OUTER JOIN, lalu menghitung skor RRF. Keputusan FULL OUTER JOIN krusial karena INNER JOIN akan membuang kandidat yang hanya ditemukan salah satu retriever, padahal kasus itulah alasan hybrid search dipakai: SKU yang hanya cocok secara leksikal, atau parafrasa yang hanya tertangkap secara semantik.
Ada keputusan teknis lain yang menentukan kualitas. Kueri leksikal dibangun di database, bukan di Python, agar tokenisasi, stemming, serta stopword sama dengan indeks yang disimpan. Istilah digabung memakai OR, bukan AND, karena lengan leksikal bertugas memperluas recall; presisi akan diproses di tahap berikutnya. Payload besar seperti konten teks tidak dibawa sejak awal, melainkan diambil setelah kandidat digabung, agar operasi peringkat tetap sempit. Parameter pool juga dipisahkan dari k yang diminta pengguna. Pool mengatur kedalaman kandidat yang dicari dan difusikan, sedangkan k mengatur jumlah akhir yang dikembalikan. Jika keduanya disamakan, reranker akan kelaparan kandidat. Hasil hybrid search bersifat mekanis: kueri identifier kini menemukan string persis, kueri parafrasa tetap bekerja, kandidat dari satu lengan tidak hilang, skala skor tidak perlu dikalibrasi ulang saat korpus tumbuh, dan seluruh proses terjadi dalam satu round trip. Namun RRF tetap bukan skor relevansi. Skor maksimum dua retriever hanya sekitar 0,0328, angka yang menunjukkan posisi dalam daftar, bukan apakah potongan benar-benar menjawab pertanyaan.
Peran Cross-Encoder Reranker dalam Memastikan Relevansi Jawaban
Karena itu, sistem menambahkan reranker. Hybrid search memperbaiki kumpulan kandidat, tetapi tidak memastikan jawaban terbaik. Retriever menghitung kueri dan dokumen secara terpisah: embedding dibandingkan di ruang vektor, leksikal dihitung lewat statistik istilah. Cross-encoder reranker memproses pertanyaan dan dokumen bersama dalam satu forward pass, sehingga dapat menilai apakah dokumen ini menjawab pertanyaan ini. Biayanya lebih mahal, maka ia dijalankan terakhir, pada sekitar 50 kandidat, bukan seluruh korpus. Dalam sistem ini, tahap tersebut memakai Amazon Bedrock amazon.rerank-v1:0 melalui endpoint bedrock-agent-runtime. Manfaatnya nyata: relevanceScore menjadi satu-satunya angka dalam pipeline yang benar-benar mengukur relevansi jawaban. Ambang batas pun menjadi bermakna. Sistem dapat mengembalikan lebih sedikit dari k hasil, bahkan nol, jika memang tidak ada potongan yang layak. Dalam konteks kepatuhan atau dukungan pelanggan, kemampuan mengatakan “tidak ada dasar jawaban” sering lebih berharga daripada memaksa tiga konteks lemah masuk ke prompt.
Kombinasi ini juga menyediakan jalur degradasi. Jika reranker gagal atau terkena throttling, sistem dapat kembali ke urutan RRF dan memotong sampai k, sembari menandai bahwa skor relevansi tidak tersedia. Tanpa hybrid search, kueri exact identifier gagal diam-diam dan menghasilkan konteks yang tampak masuk akal tetapi salah. Tanpa reranker, sistem tidak punya sinyal relevansi, semua pertanyaan selalu mendapat k hasil, dan model terdorong menjawab dari konteks yang mungkin tidak menjawab apa pun. Keduanya menyelesaikan separuh masalah yang berbeda. Retrieval menentukan apa yang tersedia untuk dijawab. Reranking menentukan apa yang layak dipakai untuk menjawab. Tahap berikutnya membawa rancangan ini dari laptop ke AWS: S3 sebagai penyimpanan dokumen, Amazon OpenSearch Service sebagai indeks vektor serta leksikal, dan ingestion berbasis peristiwa saat berkas masuk ke bucket. Di sana, logika FULL OUTER JOIN serta aritmetika 1/(60+rank) berpindah menjadi deklarasi search pipeline, karena OpenSearch sudah menyediakan RRF melalui score-ranker-processor dengan rank_constant bawaan 60.