Setelah memproses lebih dari 5 juta dokumen di berbagai aplikasi hukum dan penelitian, para pengembang menemukan bahwa sistem RAG yang siap produksi membutuhkan lebih dari sekadar pencarian kesamaan vektor. Konsensus komunitas yang muncul dari diskusi terkini mengungkapkan bahwa implementasi yang berhasil bergantung pada tumpukan teknik yang canggih yang secara dramatis mengungguli pendekatan dasar.
Revolusi Reranking
Apa yang awalnya dimulai sebagai pencarian vektor sederhana telah berevolusi menjadi sistem pengambilan multi-tahap yang kompleks, dengan reranking muncul sebagai peningkatan yang paling berdampak. Para pengembang melaporkan bahwa menambahkan model reranker khusus—yang mengurutkan ulang hasil pencarian berdasarkan relevansi dengan kueri tertentu—dapat mengkompensasi banyak kelemahan lain dalam pengaturan RAG. Konfigurasi tipikalnya melibatkan pengumpanan 50 potongan kandidat ke dalam reranker dan menerima kembali 15 potongan yang paling relevan.
5 baris kode bernilai tertinggi yang akan Anda tambahkan. Peringkat potongan berubah banyak. Lebih dari yang Anda perkirakan.
Pendekatan ini terbukti jauh lebih efektif daripada hanya mengandalkan kesamaan kosinus antara embedding, karena reranker memahami relevansi kontekstual daripada hanya kesamaan semantik.
Apa yang Menggerakkan Jarum (Peringkat ROI)
- Query Generation - LLM membuat beberapa kueri semantik + kata kunci untuk pemrosesan paralel
- Reranking - Input 50 chunk → output 15 memberikan hasil optimal
- Chunking Strategy - Logika khusus memastikan unit logis tanpa pemisahan di tengah kalimat
- Metadata Injection - Menambahkan judul, penulis, dll. ke konteks LLM meningkatkan kualitas jawaban
- Query Routing - Mendeteksi pertanyaan non-RAG untuk penanganan alternatif
Melampaui Chunking Dasar
Sementara reranking memberikan kemenangan cepat, strategi chunking tetap menjadi elemen yang paling memakan waktu namun sangat penting. Sistem produksi membutuhkan logika chunking kustom yang memahami struktur dokumen, memastikan setiap potongan mewakili unit logis daripada pemisahan teks yang sewenang-wenang. Komunitas menekankan bahwa potongan tidak boleh terputus di tengah kalimat atau di tengah kata, dan masing-masing harus berfungsi sebagai unit informasi yang mandiri.
Banyak tim yang beralih dari pemisah teks sederhana, dengan beberapa menggunakan LLM untuk menghasilkan ringkasan dan ekstrak yang cerdas. Pendekatan pengambilan kontekstual Anthropic, yang menyertakan ringkasan dokumen lengkap di samping potongan, telah mendapatkan daya tarik untuk mempertahankan konteks yang lebih luas sambil tetap memungkinkan pengambilan yang tepat.
Pembuatan dan Ekspansi Kueri
Para pengembang menemukan bahwa kueri pengguna sering kali gagal menangkap konteks lengkap yang diperlukan untuk pengambilan yang efektif. Solusinya: menggunakan LLM untuk menghasilkan beberapa variasi semantik dan kata kunci dari kueri asli, kemudian memprosesnya secara paralel. Teknik ini, yang dikenal sebagai ekspansi kueri, secara signifikan meningkatkan cakupan pengambilan tanpa mengandalkan skor pencarian hibrida yang dihitung.
Salah satu implementasinya menghasilkan tiga varian kueri berbeda dalam satu panggilan LLM tunggal, memastikan keragaman daripada kesamaan. Hasil dari pencarian paralel kemudian digabungkan menggunakan fusi peringkat timbal balik, menciptakan sekumpulan dokumen kandidat yang kuat yang menangani kueri dari berbagai sudut.
Tumpukan Pengambilan Lengkap
Komunitas sebagian besar telah bergerak melampaui pola pikir penyimpanan vektor sebagai solusi yang mendominasi implementasi RAG awal. Sistem produksi sekarang biasanya menggabungkan:
- Pencarian hibrida yang menggabungkan vektor padat dan BM25 jarang untuk istilah teknis
- Injeksi metadata untuk memberikan petunjuk kontekstual kepada LLM
- Perutean kueri untuk menangani pertanyaan non-RAG melalui metode alternatif
- Beberapa model embedding dan strategi pengambilan
Seperti yang dicatat oleh seorang pengembang Microsoft, Sedemikian sedikit pengembang yang menyadari bahwa Anda membutuhkan lebih dari sekadar pencarian vektor, jadi saya masih menghabiskan banyak waktu dalam presentasi saya untuk menekankan tumpukan pengambilan LENGKAP untuk RAG. Azure AI Search dan solusi perusahaan lainnya sekarang membakar kemampuan ini langsung ke dalam platform mereka.
Komponen Production RAG Stack
| Komponen | Pilihan Awal | Pilihan Akhir | Insight Utama |
|---|---|---|---|
| Vector Database | Azure → Pinecone | Turbopuffer | Murah, pencarian kata kunci native |
| Reranker | None → Cohere 3.5 | Zerank | Kurang dikenal tapi efektif |
| Embedding | text-embedding-large-3 | Sama | Tidak menguji alternatif |
| Chunking | Unstructured.io | Custom | Kritis untuk performa |
| Query Processing | Single query | Multi-query generation | Pemrosesan paralel dengan reranking |
Pertanyaan Terbuka dan Arah Masa Depan
Terlepas dari kemajuan ini, beberapa tantangan masih belum terselesaikan. Biaya komputasi dari model reranker besar menimbulkan kekhawatiran skalabilitas, mendorong eksplorasi model khusus yang lebih kecil seperti Qwen3-reranker. Ada juga perdebatan yang sedang berlangsung tentang apakah akan menggunakan reranker khusus versus LLM tujuan umum untuk penilaian relevansi, dengan pertukaran antara biaya, kecepatan, dan akurasi.
Komunitas juga bereksperimen dengan pendekatan yang lebih canggih seperti merutekan kueri ke model embedding yang berbeda berdasarkan jenis konten, dan menggunakan beberapa reranker secara berurutan atau paralel. Beberapa pengembang melampaui RAG tradisional sepenuhnya menuju pencarian agentic yang menggunakan alat seperti grep dan pencarian sumber waktu nyata di samping pengambilan tradisional.
Evolusi terus berlanjut saat tim menyeimbangkan tuntutan yang bersaing dari akurasi, latensi, dan biaya di lingkungan produksi di mana pengguna mengharapkan pemahaman mendekati manusia dari sistem pengambilan dokumen mereka.
Referensi: Production RAG: what I learned from processing 5M+ documents