Sebagian besar tim engineering menemui hambatan yang sama dengan retrieval-augmented generation. Mereka mengikuti panduan tutorial standar: memotong dokumen menjadi chunk tetap berukuran lima ratus dua belas atau seribu dua puluh empat token, memasukkannya melalui satu model embedding, dan memanggil database vektor dengan pencarian top-k yang sederhana. Di dalam slide presentasi, ini terlihat solid. Namun di produksi, semuanya berantakan.
Chunk tetap tidak memedulikan konten. Mereka akan dengan senang hati memotong kontrak hukum di tengah kalimat, membiarkan klausul kewajiban menggantung di dua bagian teks yang tidak terkait. Mereka akan memasukkan seluruh deskripsi endpoint API ke dalam satu chunk yang membengkak sehingga sangat besar hingga parameter spesifik yang ditanyakan pengguna tenggelam dalam noise. Dan ketika retrieval lambat, setiap milidetik latensi berdampak langsung pada pengalaman pengguna. Kami mempelajari ini dengan cara yang sulit. Kemudian kami merombak total lapisan retrieval kami dan membangunnya kembali. Recall kami pada k=10 melonjak dari tujuh puluh delapan persen menjadi sembilan puluh lima persen. Latensi tidak meningkat. Latensi justru turun drastis.
Masalah dengan RAG Copy-Paste
Stack RAG standar telah menjadi semacam pengaturan default. Chunk kecil, satu model embedding, pencarian vektor, selesai. Pendekatan tersebut berhasil dalam demo karena demo menggunakan pertanyaan yang bersih dan dokumen yang rapi. Data produksi tidak pernah rapi.
Dokumen hukum memiliki struktur hierarkis. Bagian berisi sub-bagian. Sub-bagian berisi klausul. Memotongnya dengan penghitung token yang kasar akan menghancurkan hubungan yang justru dibutuhkan model untuk melakukan penalaran. Dokumentasi API juga memiliki struktur, tetapi berbeda. Tanda tangan fungsi (function signature), parameternya, nilai kembaliannya, dan contoh penggunaannya membentuk satu unit logis. Memaksanya ke dalam jendela token tetap akan membuat Anda memotong contoh tersebut atau mengisi chunk dengan fungsi yang tidak terkait. Tiket dukungan bersifat berantakan, percakapan, dan penuh dengan perubahan topik yang tiba-tiba. Wiki bersifat luas dan saling merujuk. Satu strategi chunking tidak dapat melayani semua ini, namun tim secara rutin menerapkan hal yang persis seperti itu. Kami berhenti berpura-pura bahwa itu bisa dilakukan.
Chunking Strategis: Sesuaikan Metode dengan Materi
Kami beralih ke content-aware chunking. Untuk dokumen hukum, kami menggunakan recursive chunking yang menghormati hierarki dokumen. Ini menjaga klausul tetap utuh dan mempertahankan hubungan parent-child antar bagian. Untuk dokumentasi API, kami membangun function-aware chunking yang memperlakukan setiap fungsi atau endpoint sebagai batas. Jika deskripsi parameter terlalu panjang, chunk akan meluas di sekitar fungsi tersebut, bukan di sekitar batas token. Untuk tiket dukungan, kami menggunakan semantic chunking yang mendeteksi batas topik secara alami. Ketika pelanggan tiba-tiba beralih dari keluhan penagihan ke bug teknis, pemisahan terjadi pada titik transisi tersebut. Untuk wiki dan basis pengetahuan yang tidak terstruktur, kami menggunakan agentic chunking di mana LLM ringan mengevaluasi teks dan memutuskan di mana batas yang bermakna harus diletakkan. Ini lebih lambat untuk disiapkan daripada pemisahan karakter (character split), tetapi inilah perbedaan antara retrieval yang berfungsi dan retrieval yang hanya menebak-nebak.
Retrieval Hibrida: Mengapa Pencarian Vektor Saja Tidak Cukup
Pencarian vektor memahami makna, tetapi bisa melewatkan kecocokan eksak. Jika pengguna menempelkan kode kesalahan seperti ERR_CONNECTION_RESET_0x5F3, kemiripan semantik mungkin menempatkannya di bawah paragraf yang hanya membahas kesalahan jaringan secara umum. Di sisi lain, BM25 menemukan string eksak tetapi melewatkan keterkaitan konseptual. Anda membutuhkan keduanya.
Kami menjalankan pencarian vektor dan BM25 secara paralel. Kemudian kami menggabungkan hasilnya dengan Reciprocal Rank Fusion, atau RRF, yang menormalisasi skor dari dua ruang pencarian yang berbeda tanpa memaksanya ke dalam skala yang sama. Setelah penggabungan (fusion), kami mengirimkan kandidat teratas melalui reranker cross-encoder. Ini menambah sedikit latensi, tetapi peningkatan presisinya sangat signifikan. Reranker membaca kueri dan setiap kandidat secara bersamaan dan menetapkan skor relevansi yang jauh lebih akurat daripada kemiripan kosinus (cosine similarity) dari embedding awal. Dalam praktiknya, kombinasi ini menangkap kode kesalahan eksak yang terlewatkan oleh pencarian vektor murni, sambil tetap menampilkan langkah-langkah pemecahan masalah yang terkait secara konseptual yang akan diabaikan oleh pencarian kata kunci.
Ekspansi Kueri: Memperbaiki Input Pengguna Sebelum Mencapai Indeks
Pengguna tidak menulis kueri pencarian yang sempurna. Mereka mengajukan pertanyaan multi-hop seperti "mengapa deployment terakhir saya gagal dan bagaimana cara melakukan rollback", yang memerlukan pencarian dua badan pengetahuan terpisah dan menghubungkannya. Atau mereka mengajukan pertanyaan samar yang pemetaannya buruk terhadap indeks.
Kami mentransformasi kueri sebelum melakukan pencarian. Pertanyaan multi-hop dipecah menjadi sub-pertanyaan. Niat yang samar diperluas menjadi beberapa kueri pencarian yang spesifik. Kami menemukan bahwa memperluas satu kueri pengguna menjadi lima kueri pencarian yang berbeda dapat meningkatkan recall dari tujuh puluh delapan persen menjadi sembilan puluh enam persen. Ini bukan tentang memberikan prompt yang lebih keras kepada LLM. Ini tentang memberikan lebih banyak kesempatan kepada sistem retrieval untuk menemukan konteks yang tepat. Setiap kueri yang dihasilkan menangkap sudut pandang atau terminologi yang berbeda, dan hasil yang digabungkan memberikan gambaran yang lengkap.
Optimasi Bayesian: Berhenti Menebak-nebak
Setelah Anda memiliki berbagai strategi chunking, hybrid retrieval, dan ekspansi kueri, Anda akan menghadapi masalah baru. Ada terlalu banyak parameter yang harus diatur. Ukuran chunk, persentase overlap, bobot vektor versus bobot BM25, ambang batas reranking, dan nilai top-k semuanya berinteraksi secara nonlinear. Penyetelan manual menjadi sebuah permainan tebak-tebakan.
Kami berhenti menebak-nebak. Kami memperlakukan