Sebagian besar tim masih menyusun pipeline retrieval pertama mereka dengan cara yang sama. Mereka memilih batas token tetap, mungkin 512, membagi dokumen menjadi blok-blok seragam, dan memasukkan blok-blok tersebut ke dalam database vektor. Pada dataset kecil dengan pertanyaan sederhana, ini terlihat ajaib. Namun di tahap produksi, sistem ini berantakan.
Kontrak hukum hancur menjadi fragmen yang tidak bermakna ketika sebuah klausul terpotong di tengah kalimat. Dokumentasi API berubah menjadi kumpulan informasi yang kacau jika satu chunk menelan tiga fungsi yang tidak terkait. Tiket dukungan pelanggan kehilangan seluruh alur narasi tanpa adanya tumpang tindih (overlap) antar segmen. Hasilnya dapat diprediksi: latensi yang membengkak, recall yang lemah, dan jawaban yang memaksa generator untuk berhalusinasi.
Kami membongkar lapisan retrieval kami dan membangunnya kembali. Hasilnya adalah lonjakan recall dari 78 persen menjadi 95 persen, pemotongan latensi sebesar 62 persen, dan pipeline yang akhirnya berperilaku seperti infrastruktur nyata, bukan sekadar hasil eksperimen akhir pekan. Inilah yang benar-benar berhasil.
Smart Chunking: Struktur di Atas Token
Kesalahan pertama adalah berasumsi bahwa setiap dokumen menggunakan bahasa yang sama. Chunk berukuran 512 token masuk akal untuk prosa naratif dan hampir tidak masuk akal di tempat lain. Kami beralih ke strategi yang menghormati anatomi sumber dokumen.
Untuk dokumen hukum, kami menggunakan recursive chunking. Algoritma ini pertama-tama mencoba membagi berdasarkan batasan tingkat tinggi seperti bagian (section) dan pasal (article). Jika sebuah bagian masih terlalu panjang, algoritma akan mencari subbagian, lalu paragraf, kemudian kalimat. Hal ini menjaga struktur hierarki logis dari klausul-klausul tersebut. Perjanjian non-kompetisi tetap utuh. Definisi tidak bercampur dengan ketentuan ganti rugi (indemnity).
Dokumentasi API menuntut structure-aware chunking. Tanda tangan fungsi (function signature), tabel parameternya, dan contoh permintaannya (example request) harus berada dalam satu kesatuan. Membagi berdasarkan jumlah token tetap sering kali meninggalkan parameter di satu chunk dan contoh di chunk lainnya. Sebagai gantinya, kami melakukan chunking berdasarkan objek dokumen. Satu chunk berisi satu endpoint lengkap atau satu fungsi tunggal. Retriever kemudian dapat mengembalikan referensi mandiri yang benar-benar menjawab pertanyaan.
Tiket dukungan pelanggan secara alami cocok dengan semantic chunking. Alih-alih memotong pada batas token, kami mendeteksi di mana topik berubah. Sebuah tiket yang dimulai dengan keluhan login dan beralih ke pertanyaan penagihan akan terbagi menjadi dua bagian yang koheren. Setiap bagian membawa metadata yang dibutuhkannya, dan model tidak perlu lagi menebak masalah mana yang sebenarnya dipedulikan oleh pengguna.
Wiki internal jauh lebih berantakan. Mereka mencampur prosa, tabel, diagram, dan utas (thread) yang tertanam. Untuk ini, kami menggunakan agentic chunking. Model bahasa kecil membaca lebih dulu dan memutuskan di mana unit tematik yang lengkap berakhir. Ini memakan biaya sedikit lebih mahal pada saat proses ingestion, tetapi menghilangkan pekerjaan manual yang membosankan dalam menyesuaikan aturan untuk setiap format halaman baru.
Hybrid Retrieval: Lindungi Semua Sisi
Pencarian vektor sangat baik dalam menangkap makna yang samar (fuzzy meaning). Tanyakan tentang unggahan yang lambat, dan ia akan dengan senang hati mengembalikan paragraf tentang latensi dan bandwidth. Namun, ia terkenal karena sering mengacaukan kecocokan eksak. Jika seorang pengembang mencari kode kesalahan ERR_CONNECTION_REFUSED, dense embeddings sering kali menganggapnya sebagai noise generik.
BM25, algoritma kata kunci klasik, melakukan hal sebaliknya. Ia sangat akurat dalam menemukan string yang presisi dan istilah langka, namun ia melewatkan nuansa semantik. Sebuah kueri tentang penandatanganan perjanjian mungkin tidak akan pernah memunculkan konten yang ditandai dengan pelaksanaan kontrak.