Sebagian besar tutorial RAG berakhir di tahap demo. Anda melakukan chunking berdasarkan jumlah token, memasukkan semuanya ke dalam vector database, dan selesai. Itu berhasil jika pengguna bertanya "Apa kebijakan pengembalian?" ke dalam FAQ yang rapi. Namun, hal itu akan berantakan saat seseorang menempelkan setengah isi kontrak dan bertanya tentang klausul ketiga, atau saat seorang pengembang mengetikkan kode kesalahan yang tidak umum ke dalam pencarian dokumentasi Anda.

Jendela token yang tetap (fixed token windows) memotong perjanjian hukum di tengah kalimat. Chunk yang besar mengubur referensi API di bawah paragraf yang penuh kebisingan (noise). Yang terburuk, pengambilan (retrieval) yang lambat membuat pengguna membatalkan kueri bahkan sebelum model mulai menghasilkan jawaban. Kami mempelajari ini dengan cara yang sulit. Ketika kami mengubah lapisan pengambilan kami dari sekadar harapan menjadi pengukuran, kami memangkas latensi sebesar empat puluh persen dan mendorong recall hingga sembilan puluh lima persen. Inilah perubahan tepatnya.

Smart Chunking

Berhentilah menganggap ukuran chunk sebagai angka ajaib. Jendela 512 token tidak masuk akal untuk dokumen hukum di mana satu klausul mencakup beberapa paragraf, dan hal yang sama tidak berguna untuk dokumentasi API di mana tanda tangan fungsi (function signature) dan deskripsi dua barisnya harus tetap bersama. Kami beralih ke pemisahan yang sadar struktur (structure-aware splitting).

Untuk teks hukum, recursive chunking menghormati hierarki dokumen. Klausul tetap utuh. Untuk dokumentasi API, kami menggunakan function-aware splitting yang menjaga tanda tangan, parameter, dan contoh tetap bersama sebagai unit atomik. Tiket dukungan dan data percakapan membutuhkan batasan semantik, memisahkan di mana topik berubah, bukan pada jumlah karakter yang sembarang. Hasilnya adalah setiap chunk membawa konteks yang cukup untuk berguna tetapi tidak terlalu banyak sehingga mengencerkan sinyal. Model embedding Anda memiliki anggaran atensi yang terbatas. Gunakanlah dengan bijak.

Hybrid Retrieval

Pencarian vektor unggul dalam menemukan konten yang secara konseptual serupa. Tanyakan tentang kueri basis data yang lambat, dan ia akan memunculkan panduan penyetelan performa. Namun, tanyakan "Error 0x80070057" dan pencarian semantik akan melenceng ke wilayah yang tidak terkait karena dense embeddings tidak menangani kecocokan eksak dengan baik. Di sisi lain, BM25 sangat akurat dalam menangani string eksak dan istilah langka, namun ia tidak tahu bahwa "latensi" dan "waktu respons lambat" memiliki arti yang sama.

Kami menjalankan keduanya secara paralel dan menggabungkannya dengan Reciprocal Rank Fusion. RRF itu sederhana dan efektif. Ia mengambil daftar peringkat dari setiap metode dan memberi skor pada dokumen berdasarkan posisinya, memberikan kesempatan yang adil bagi kandidat kuat dari sistem mana pun. Setelah penggabungan (fusion), kami menjalankan cross-encoder reranker pada hasil gabungan dan hanya mengembalikan lima teratas. Reranker tersebut menambah sekitar lima puluh milidetik latensi tetapi meningkatkan recall kami sebesar lima belas persen. Pertukaran (trade-off) tersebut terbayar berkali-kali lipat dalam kualitas generasi.

Query Expansion

Pengguna sangat buruk dalam membuat kueri. Mereka menyingkat, salah mengeja, atau memasukkan tiga pertanyaan ke dalam satu ocehan panjang. Jika Anda mencari persis seperti apa yang mereka ketik, Anda akan melewatkan dokumen yang sebenarnya mereka butuhkan.

Sekarang kami mengubah setiap kueri sebelum mencapai indeks. Pertama, kami menghasilkan beberapa versi kalimat ulang dari pertanyaan asli untuk mencakup sinonim dan pengungkapan alternatif. Kedua, kami menguraikan pertanyaan kompleks menjadi sub-pertanyaan yang lebih kecil. Kueri seperti "Mengapa pengembalian dana gagal untuk pelanggan internasional dan bagaimana cara memperbaikinya?" menjadi dua pencarian berbeda: satu tentang kegagalan pengembalian dana internasional dan satu tentang langkah-langkah perbaikan. Ekspansi kueri (query expansion) saja telah meningkatkan recall kami dari tujuh puluh delapan persen menjadi sembilan puluh empat persen. Pelajarannya sederhana: jangan percaya pada draf pertama pengguna. Bantulah mereka.

Berhenti Menebak, Mulai Mencari

Ukuran chunk, persentase overlap, batas top-k, dan kedalaman reranker berinteraksi dengan cara yang mustahil untuk disetel secara manual. Kami menghabiskan terlalu banyak waktu memperdebatkan apakah 256 token lebih baik daripada 512, sambil mengabaikan pengaturan overlap yang sebenarnya merusak koherensi.

Kami mengganti intuisi dengan optimasi Bayesian. Alih-alih grid search, yang membuang-buang daya komputasi pada wilayah yang jelas-jelas buruk, metode Bayesian membangun model probabilitas tentang apa yang berhasil dan secara aktif mencari Pareto frontier yang memaksimalkan recall sambil meminimalkan latensi. Untuk stack kami, itu berarti menemukan kombinasi spesifik dari ukuran chunk, overlap, dan top-k yang memberi kami recall sembilan puluh lima persen tanpa melampaui anggaran latensi kami. Kasus penggunaan yang berbeda mendarat pada titik yang berbeda di sepanjang frontier tersebut. Chatbot yang berhadapan dengan pelanggan memprioritaskan kecepatan. Riset hukum internal memprioritaskan recall. Optimasi otomatis memungkinkan kami melayani keduanya tanpa perlu menyalin-tempel file konfigurasi secara manual.

Hasilnya

Angka-angka ini menunjukkan dengan jelas. Recall@10 kami meningkat dari tujuh puluh delapan persen menjadi sembilan puluh lima persen. Latensi p95 turun dari 850 milidetik menjadi 320 milidetik. Dan karena model akhirnya menerima konteks yang relevan alih-alih noise, tingkat halusinasi turun dari dua belas persen menjadi tiga persen. Retrieval yang lebih baik tidak hanya membuat jawaban lebih cepat. Ia membuatnya menjadi akurat.

Apa yang Harus Dilakukan Selanjutnya

Jika Anda sedang membangun kembali lapisan retrieval Anda, mulailah dari sini:

  • Lakukan chunking berdasarkan struktur dokumen, bukan jumlah token. Sesuaikan strategi pemisahan Anda dengan bentuk data Anda.
  • Gunakan hybrid retrieval. Gabungkan vector search dan BM25, gabungkan dengan Reciprocal Rank Fusion, dan lakukan rerank sebelum Anda melakukan generasi.
  • Perluas kueri untuk cakupan yang lebih baik. Lakukan rephrase dan dekomposisi sebelum pencarian dijalankan.
  • Bangun golden dataset untuk pengujian. Anda tidak dapat mengoptimalkan apa yang tidak Anda ukur.
  • Optimalkan parameter dengan alat otomatis. Bayesian search akan menemukan pengaturan yang lebih baik daripada sekadar intuisi Anda.

Retrieval bukanlah file konfigurasi yang Anda atur sekali lalu dilupakan. Ini adalah infrastruktur, dan infrastruktur layak mendapatkan ketelitian yang sama dengan kode produksi: pengujian, pengukuran, dan optimasi berkelanjutan. Perlakukan seperti itu, dan sistem RAG Anda tidak lagi sekadar demo, melainkan mulai menjadi sebuah produk.

Komunitas belajar opsional: GyaanSetu AI