Kebanyakan pasukan kejuruteraan menghadapi masalah yang sama dengan retrieval-augmented generation. Mereka mengikut panduan tutorial: membahagikan dokumen kepada cebisan (chunks) tetap sebanyak lima ratus dua belas atau seribu dua puluh empat token, menghantarnya melalui satu model embedding, dan memanggil pangkalan data vektor dengan carian top-k yang mudah. Dalam slaid pembentangan, ini kelihatan mantap. Namun dalam persekitaran produksi, ia gagal.
Cebisan tetap tidak mempedulikan kandungan. Ia akan membahagikan kontrak undang-undang di tengah-tengah ayat tanpa ragu-ragu, menyebabkan klausa liabiliti tergantung pada dua bahagian teks yang tidak berkaitan. Ia akan memasukkan keseluruhan huraian titik hujung (endpoint) API ke dalam satu cebisan yang terlalu besar sehingga parameter khusus yang ditanya oleh pengguna tenggelam dalam gangguan (noise). Dan apabila proses pencarian (retrieval) menjadi perlahan, setiap milisaat kependaman (latency) akan menjejaskan pengalaman pengguna secara langsung. Kami mempelajari perkara ini melalui pengalaman yang sukar. Kemudian, kami merombak semula lapisan pencarian kami dan membinanya semula. Kadar recall kami pada tahap sepuluh melonjak daripada tujuh puluh lapan peratus kepada sembilan puluh lima peratus. Kependaman tidak meningkat. Malah, ia menurun secara drastik.
Masalah dengan RAG Salin-Tampal
Timbunan (stack) RAG standard telah menjadi seolah-olah tetapan lalai. Cebisan kecil, satu model embedding, carian vektor, selesai. Pendekatan itu berjaya dalam sesi demo kerana demo menggunakan soalan yang jelas dan dokumen yang kemas. Data produksi tidak pernah kemas.
Dokumen undang-undang mempunyai struktur hierarki. Seksyen mengandungi subseksyen. Subseksyen mengandungi klausa. Jika anda memotongnya dengan pengira token yang kasar, anda akan memusnahkan hubungan yang diperlukan oleh model untuk membuat penaakulan. Dokumentasi API juga mempunyai struktur, tetapi ia berbeza. Tandatangan fungsi (function signature), parameternya, nilai pulangan, dan contoh penggunaan membentuk satu unit logik. Jika anda memaksanya ke dalam tetingkap token yang tetap, anda sama ada akan memotong contoh tersebut atau memenuhkan cebisan dengan fungsi yang tidak berkaitan. Tiket sokongan adalah tidak teratur, bersifat perbualan, dan penuh dengan peralihan topik yang mendadak. Wiki pula luas dan mempunyai rujukan silang. Satu strategi pembahagian (chunking) tidak dapat memenuhi semua keperluan ini, namun pasukan kejuruteraan sering melaksanakan pendekatan yang sama. Kami berhenti berpura-pura bahawa ia boleh dilakukan.
Pembahagian Strategik: Padankan Kaedah dengan Bahan
Kami beralih kepada pembahagian sedar-kandungan (content-aware chunking). Untuk dokumen undang-undang, kami menggunakan pembahagian rekursif yang menghormati hierarki dokumen. Ia mengekalkan klausa secara utuh dan memelihara hubungan induk-anak antara seksyen. Untuk dokumentasi API, kami membina pembahagian sedar-fungsi (function-aware chunking) yang menganggap setiap fungsi atau titik hujung sebagai sempadan. Jika huraian parameter terlalu panjang, cebisan tersebut akan berkembang di sekitar fungsi itu, bukan berdasarkan had token. Untuk tiket sokongan, kami menggunakan pembahagian semantik (semantic chunking) yang mengesan sempadan topik semula jadi. Apabila pelanggan tiba-tiba beralih daripada aduan pengebilan kepada pepijat teknikal, pembahagian berlaku pada peralihan tersebut. Untuk wiki dan pangkalan pengetahuan tidak berstruktur, kami menggunakan pembahagian ejen (agentic chunking) di mana LLM ringan menilai teks dan memutuskan di mana sempadan yang bermakna harus diletakkan. Ini lebih lambat untuk disediakan berbanding pembahagian aksara, tetapi inilah perbezaan antara pencarian yang berfungsi dan pencarian yang sekadar meneka.
Pencarian Hibrid: Mengapa Carian Vektor Sahaja Tidak Mencukupi
Carian vektor memahami makna, tetapi ia boleh terlepas padanan tepat. Jika pengguna menampal kod ralat seperti ERR_CONNECTION_RESET_0x5F3, keserupaan semantik mungkin meletakkannya di bawah perenggan yang hanya membincangkan ralat rangkaian secara umum. Sebaliknya, BM25 mencari rentetan tepat tetapi terlepas perkaitan konsep. Anda memerlukan kedua-duanya.
Kami menjalankan carian vektor dan BM25 secara selari. Kemudian, kami menggabungkan keputusan tersebut dengan Reciprocal Rank Fusion, atau RRF, yang menormalkan skor daripada dua ruang carian yang berbeza tanpa memaksanya ke dalam skala yang sama. Selepas penggabungan, kami menghantar calon teratas melalui penyusun semula (reranker) cross-encoder. Ini menambah sedikit kependaman, tetapi peningkatan dalam ketepatan adalah ketara. Reranker tersebut membaca pertanyaan dan setiap calon secara bersama serta menetapkan skor relevansi yang jauh lebih tepat daripada keserupaan kosinus (cosine similarity) daripada embedding asal. Dalam praktiknya, kombinasi ini menangkap kod ralat tepat yang terlepas oleh carian vektor tulen, sambil tetap memaparkan langkah penyelesaian masalah yang berkaitan secara konsep yang akan diabaikan oleh carian kata kunci.
Pengembangan Pertanyaan: Memperbaiki Input Pengguna Sebelum Ia Mencapai Indeks
Pengguna tidak menulis pertanyaan carian yang sempurna. Mereka bertanya soalan pelbagai langkah (multi-hop) seperti "mengapa pelancaran (deploy) terakhir saya gagal dan bagaimana saya mahu membatalkannya (roll it back)", yang memerlukan pencarian dua badan pengetahuan yang berbeza dan menghubungkannya. Atau mereka bertanya soalan kabur yang sukar dipetakan ke dalam indeks.
We transform queries before searching. A multi-hop question gets broken into sub-questions. A vague intent gets expanded into multiple specific search queries. We found that expanding one user query into five distinct search queries can move recall from seventy-eight percent to ninety-six percent. This is not about prompting the LLM harder. It is about giving the retrieval system more shots at finding the right context. Each generated query captures a different angle or terminology, and the merged results paint a complete picture.
Bayesian Optimization: Stop Guessing
Once you have multiple chunking strategies, hybrid retrieval, and query expansion, you face a new problem. There are too many knobs. Chunk size, overlap percentage, vector weight versus BM25 weight, reranking thresholds, and top-k values all interact in nonlinear ways. Manual tuning becomes a guessing game.
We stopped guessing. We treat the