Bagaimana Ukuran Chunk, Embeddings, dan Pencarian Hybrid Menentukan Keberhasilan atau Kegagalan Produksi RAG

Tim yang memindahkan Retrieval-Augmented Generation (RAG) dari demo ke layanan produksi akan menghadapi sejumlah keputusan yang membedakan asisten yang berguna dari asisten yang berisik (noisy). Lima pilihan desain—chunking, model embedding, vector store, hybrid search, dan evaluasi—mengontrol presisi, recall, dan latensi yang dialami pengguna nyata.

Mengapa transisi dari prototipe ke produksi itu penting

Sebagian besar tutorial menjalankan pipeline RAG hanya dalam beberapa lusin baris kode, lalu berhenti sebelum mencapai ketelitian engineering yang dibutuhkan untuk trafik langsung (live traffic).

1. Strategi chunking – gerbang kualitas pertama

Ukuran chunk sangatlah penting. Chunk yang besar menenggelamkan sinyal dengan teks yang tidak relevan; chunk yang terlalu kecil menghilangkan konteks di sekitarnya yang dibutuhkan model untuk menghasilkan jawaban yang koheren. Pembagian ukuran tetap (fixed-size splitting) mengabaikan struktur alami dari materi sumber.

Aturan praktis

• Bagi berdasarkan batasan logis: header dalam dokumen, pemisah paragraf dalam artikel, definisi fungsi dalam kode.
• Jaga agar chunk cukup kecil untuk pengambilan (retrieval) yang presisi, tetapi tetap pertahankan bagian induk (parent section) yang lebih besar untuk langkah generasi LLM. Pola “parent-child” ini memungkinkan retriever menampilkan cuplikan yang tepat sementara generator melihat konteks yang cukup agar tetap faktual.

2. Model embedding – bagaimana kemiripan dinilai

Model embedding mengubah teks menjadi vektor yang dibandingkan oleh mesin pencari kemiripan (similarity search engine). Model tujuan umum (general-purpose) yang kuat seperti text-embedding-3-large milik OpenAI memberikan baseline yang solid untuk sebagian besar domain. Jika korpus berada dalam bidang yang sangat terspesialisasi—pendapat hukum, rekam medis, spesifikasi teknis—uji model khusus domain (domain-specific), tetapi hanya setelah Anda mengukur peningkatan nyata pada data Anda sendiri.

Kapan harus beralih

• Beralihlah hanya jika Anda melihat peningkatan terukur dalam skor relevansi yang penting bagi aplikasi Anda (misalnya, presisi konteks yang lebih tinggi).

3. Database vektor – menskalakan penyimpanan

Pilih vector store yang sesuai dengan infrastruktur Anda saat ini dan jumlah vektor yang diharapkan.

• pgvector berjalan di dalam PostgreSQL dan dapat menangani hingga sekitar satu juta vektor dengan nyaman. Ini ideal bagi tim yang sudah mengoperasikan database relasional dan membutuhkan solusi dengan pemeliharaan rendah.
• Qdrant unggul dalam rentang 1 Juta–100 Juta, memberikan throughput yang lebih tinggi dan latensi yang lebih rendah untuk korpus yang lebih besar.
• Pinecone menyediakan layanan cloud yang dikelola sepenuhnya, menghilangkan beban operasional dari self-hosting.

4. Hybrid search dan reranking – menyeimbangkan makna dan ketepatan

Pencarian vektor murni unggul dalam kemiripan semantik tetapi dapat melewatkan kecocokan kata kunci (keyword) tepat yang diharapkan pengguna. Hybrid search menambahkan lapisan indeks kata kunci BM25 tradisional di atas indeks vektor, lalu menggabungkan kedua daftar hasil tersebut. Reciprocal Rank Fusion (RRF) memberikan skor pada setiap kandidat berdasarkan peringkatnya di kedua daftar dan menggabungkannya, sehingga meningkatkan item yang muncul di peringkat tinggi pada salah satu daftar.

Reranking menambahkan filter presisi terakhir. Setelah pengambilan hybrid, masukkan N kandidat teratas (biasanya 50) ke cross-encoder—sebuah model yang memberikan skor pada pasangan query-dokumen secara bersamaan. Skor cross-encoder menggantikan angka kemiripan asli, memungkinkan Anda memilih chunk yang paling relevan sebelum meneruskannya ke LLM. Langkah tambahan ini sering kali menghasilkan lonjakan kualitas jawaban yang nyata, terutama untuk korpus yang panjang atau berisik (noisy).

5. Evaluasi dan abstensi – mengukur apa yang penting

Anda tidak dapat meningkatkan sistem yang tidak Anda ukur. Kerangka kerja RAGAS mengusulkan empat metrik yang secara bersama-sama menangkap kesehatan pipeline RAG:

• Context Precision – proporsi chunk yang diambil yang benar-benar berisi jawaban.
• Context Recall – proporsi dari semua chunk relevan yang berhasil diambil.
• Faithfulness – sejauh mana jawaban yang dihasilkan tetap berada dalam konteks yang diambil, guna menghindari halusinasi.
• Answer Relevance – seberapa baik jawaban akhir memenuhi query asli.

Pantau metrik ini pada set pengujian berkelanjutan (rolling test set) yang mencerminkan trafik produksi.

Perlindungan terakhir yang sering diabaikan adalah abstensi. Alih-alih memaksa model untuk menjawab dengan tingkat kepercayaan (confidence) yang rendah, tetapkan ambang batas (threshold) pada skor faithfulness atau relevance yang memicu respons “Saya tidak tahu”. Pengguna lebih menyukai pengakuan ketidakpastian yang jelas daripada jawaban yang terdengar percaya diri tetapi salah, dan mekanisme fallback ini mengurangi biaya dukungan (support costs) di hilir.

Anggaplah masing-masing dari kelima area ini sebagai titik keputusan, bukan sekadar konfigurasi "set-and-forget", dan Anda dapat memindahkan RAG dari demo yang mencolok menjadi layanan produksi yang andal. Hasilnya: sistem yang menjawab dengan cepat, tetap pada topik, dan tahu kapan harus tetap diam.