Kebanyakan pasukan membina sistem capaian pertama mereka dengan cara yang sama: memotong setiap dokumen kepada cebisan 512 token yang tetap, menghantarnya

Kebanyakan pasukan membina sistem capaian pertama mereka dengan cara yang sama: memotong setiap dokumen kepada keratan 512-token yang tetap, memasukkannya ke dalam pangkalan data vektor, dan berharap model embedding melakukan kerja berat tersebut. Harapan itu mungkin memadai untuk sesi demo, tetapi ia tidak akan bertahan apabila berhadapan dengan pengguna sebenar.

Dalam persekitaran produksi, kontrak undang-undang akan gagal apabila anda memisahkan klausa liabiliti daripada pengecualiannya. Dokumentasi API menjadi tidak berguna apabila contoh kod terpisah daripada tandatangan fungsinya. Bebenang sokongan pelanggan menjadi hingar apabila anda mencabut satu aduan sahaja daripada sejarah perbualannya. Masalahnya jarang sekali terletak pada model bahasa yang berada di penghujung aliran kerja tersebut. Masalahnya adalah apa yang anda berikan kepadanya.

Kami mempelajari perkara ini melalui pengalaman yang sukar. Lapisan capaian awal kami kelihatan standard tetapi berkelakuan tidak konsisten. Jadi, kami membinanya semula berdasarkan satu idea mudah: anggap capaian sebagai infrastruktur terukur, bukan magis. Inilah perubahan yang dilakukan, dan bagaimana kami meningkatkan recall kepada 95 peratus sambil mengurangkan latensi persentil ke-95 daripada 850 ms kepada 320 ms.

Perangkap Keratan Tetap

Bilangan token yang seragam mudah untuk dikod dan mudah untuk dijelaskan. Kemudahan itu menyembunyikan satu kebenaran asas: dokumen mempunyai struktur. Apabila anda mengabaikan struktur tersebut, anda memusnahkan isyarat.

Bayangkan sebuah perjanjian perkhidmatan induk sebanyak sepuluh halaman. Keratan 512-token yang tetap akan terhenti di tengah-tengah obligasi, memisahkan klausa daripada jadual had yang mengehadkannya. Langkah capaian kemudiannya hanya mengembalikan separuh daripada pemikiran tersebut. Penjana pula akan berhalusinasi untuk melengkapkan selebihnya. Dalam dokumentasi API, keratan yang terlalu besar akan mencairkan embedding dengan header boilerplate, sehingga menimbus kaedah khusus yang diperlukan oleh pembangun. Dalam tiket sokongan, tetingkap tetap melayan perbualan sebagai "beg ayat", membuang interaksi berbalas-balas yang mendedahkan apa sebenarnya yang gagal.

Kami berhenti menganggap saiz keratan sebagai hiperparameter yang hanya diteka. Kami mula menganggapnya sebagai satu latihan pemetaan antara jenis dokumen dan senibina maklumat di dalamnya.

Sesuaikan Teknik Chunking Anda dengan Data

Penyelesaiannya bukanlah satu saiz keratan yang sempurna. Penyelesaiannya adalah tiga strategi berbeza yang dilaraskan mengikut tiga bentuk data yang berbeza.

Dokumen undang-undang kini melalui pembahagian rekursif. Algoritma tersebut terlebih dahulu mencari sempadan semula jadi yang terbesar—seksyen, kemudian subseksyen, kemudian klausa bernombor—dan hanya beralih kepada pembahagian yang lebih kecil apabila perlu. Ini memastikan klausa penamatan kekal bersama syarat kelangsungan ia. Langkah capaian akan melihat unit logik yang lengkap, yang secara drastik mengurangkan kecenderungan model untuk mencipta pengecualian yang hilang.

Dokumentasi API dan kod menggunakan chunking peka-struktur. Header Markdown, pagar kod (code fences), dan jadual parameter diproses sebagai unit atomik. Kami tidak membahagikan di dalam blok kod. Kami mengekalkan docstring bersebelahan dengan tandatangannya. Hasilnya, pertanyaan untuk kaedah kelas tertentu akan mendapatkan konteks penuh yang diperlukan oleh pembangun: penerangan, parameter bertipe, dan contoh yang berfungsi.

Data sokongan dan perbualan menggunakan chunking semantik. Daripada mengira token, kami mencari peralihan topik atau niat. Jika pelanggan menerangkan pepijat dalam mesej ketiga dan menampal stack trace dalam mesej ketujuh, kami melakukan chunking berdasarkan makna, bukan berdasarkan indeks mesej. Lapisan capaian kemudian mengembalikan keseluruhan aliran masalah dan bukannya satu ayat yang terasing.

Mengapa Carian Vektor Sahaja Gagal

Walaupun keratan itu sempurna, ia tetap akan gagal dalam carian vektor tulen. Embedding padat sangat cemerlang dalam menangkap makna dan sinonim, tetapi ia terkenal dengan sifatnya yang kabur terhadap rentetan (string) yang tepat. Jika seorang jurutera mencari kod ralat tepat ERR_CONNECTION_REFUSED, keserupaan vektor mungkin mengembalikan belasan jiran konseptual dan terlepas padanan tepat yang tersembunyi pada kedudukan ke-14.

Carian kata kunci dengan BM25 pula mempunyai masalah yang bertentangan. Ia menemui token yang tepat tetapi terlepas niat semantik. Seorang pengguna yang bertanya "mengapa pangkalan data saya tergendala" tidak akan sepadan dengan dokumen yang menyatakan "penyelesaian masalah masa tamat sambungan."

Kami kini menjalankan kedua-duanya. Keputusan vektor dan kata kunci dimasukkan ke dalam Reciprocal Rank Fusion, yang menggabungkan kedua-dua senarai kedudukan tanpa memerlukan skor terkalibrasi. Senarai yang digabungkan itu kemudiannya dihantar melalui reranker cross-encoder. Reranker adalah lebih lambat daripada capaian awal, tetapi ia jauh lebih tepat kerana ia menilai kaitan pertanyaan-dokumen secara langsung dan bukannya melalui embedding yang dimampatkan. Aliran kerja hibrid itu sahaja telah meningkatkan recall kami sebanyak 15 peratus.

Memperbaiki Pertanyaan yang Lemah Sebelum Ia Mencapai Indeks

Pengguna tidak menulis pertanyaan carian yang ideal. Mereka menampal baris log yang terpotong. Mereka menaip "ia rosak." Mereka menggunakan jargon yang tidak pernah digunakan dalam dokumentasi anda. Jika anda mempercayai pertanyaan mentah, anda sebenarnya mempercayai hingar.

Kami kini mengembangkan setiap pertanyaan yang masuk kepada tiga hingga lima variasi sebelum menghantarnya ke lapisan pengambilan (retrieval layer). Satu variasi mungkin merupakan parafrasa langsung. Satu lagi mungkin merupakan tajuk dokumen ideal yang hipotetikal. Variasi ketiga membuang pengisi perbualan (conversational filler) dan mengasingkan kata kunci teknikal. Setiap varian akan melalui proses embedding dan dicari. Kami kemudian menghapuskan duplikasi (deduplicate) dan menggabungkan kumpulan calon tersebut.

Ini tidak percuma. Panggilan embedding tambahan itu memerlukan kos dan menambah beberapa milisaat. Namun kesannya terhadap recall adalah dramatik: kami meningkat daripada 78 peratus kepada 96 peratus dengan mengembangkan pertanyaan sebelum pengambilan. Kerana pengambilan yang lebih baik mengecilkan tetingkap penjanaan (generation window) dan memberikan konteks yang betul kepada model, kami akhirnya menjimatkan kos di peringkat hiliran (downstream). Langkah pengambilan yang sedikit lebih mahal adalah lebih murah daripada langkah penjanaan yang panjang dan berhalusinasi.

Berhenti Meneka. Mula Mencari.

Sebaik sahaja kami menetapkan chunking, pengambilan hibrid, dan pengembangan pertanyaan yang betul, kami masih menghadapi kekacauan kombinatorial. Saiz chunk, pertindihan chunk (chunk overlap), kedalaman pengambilan top-k, had reranker, dan pemberat gabungan (fusion weights) semuanya saling berinteraksi. Carian grid manual akan mengambil masa berminggu-minggu dan masih meninggalkan kami dengan nilai maksimum tempatan (local maximum).

Kami beralih kepada pengoptimuman Bayesian untuk meneroka ruang tersebut. Daripada menguji setiap kombinasi secara menyeluruh, algoritma carian mengekalkan kepercayaan tentang konfigurasi mana yang berkemungkinan memberikan prestasi baik dan secara progresif mengecil kepada kawasan yang menjanjikan.

Hasilnya bukanlah satu tetapan tunggal yang sempurna. Ia adalah sempadan Pareto (Pareto frontier) bagi pilihan yang ada. Di satu hujung, kami mempunyai konfigurasi ramping yang dioptimumkan untuk titik akhir (endpoint) sokongan API berkapasiti tinggi kami: inferens pantas, recall sederhana, dan kependaman (latency) serendah mungkin. Di hujung yang lain, kami mempunyai konfigurasi agresif untuk semakan undang-undang: pengambilan yang lebih mendalam, reranking yang lebih berat, dan pertindihan yang lebih ketat, menukar milisaat untuk ketelitian. Kerana sempadan tersebut adalah eksplisit, kami boleh memilih titik yang betul untuk produk tersebut daripada berpura-pura bahawa satu saiz sesuai untuk semua.

Bagaimana Rupa Angka Sebenar

Perubahan ini mengubah sistem daripada prototaip yang rapuh kepada saluran paip pengeluaran (production pipeline) yang terukur.

Recall pada sepuluh meningkat daripada 78 peratus kepada 95 peratus. Ini bermakna apabila jawapan yang betul wujud dalam korpus kami, kami menemuinya sembilan belas kali daripada dua puluh.

Kependaman pada persentil ke-95 jatuh daripada 850 ms kepada 320 ms. Timbunan hibrid (hybrid stack) kedengaran lebih berat di atas kertas, tetapi pengindeksan yang lebih pintar, reranker yang lebih kecil, dan keupayaan untuk menyediakan chunk yang agresif hanya apabila diperlukan menjadikan keseluruhan sistem lebih pantas.

Kadar halusinasi—yang dijejak oleh anotator manusia pada set data emas (golden dataset) yang diasingkan—jatuh daripada 12 peratus kepada 3 peratus. Apabila model menerima konteks yang lengkap dan relevan, ia berhenti mereka-reka fakta.

Kos bagi setiap pertanyaan jatuh daripada $0.008 kepada $0.005. Pengambilan yang lebih baik bermakna prom LLM yang lebih pendek dan lebih fokus serta kurang percubaan pemulihan. Perbelanjaan embedding tambahan untuk pengembangan pertanyaan adalah kecil berbanding penjimatan dalam penjanaan.

Bina Set Data Emas dan Layan Pengambilan Seperti Kod

Jika anda ingin mengambil satu pengajaran daripada ini, ia perlulah disiplin dalam pengukuran. Kami membina set data emas kecil yang mengandungi soalan sebenar dan lokasi jawapan yang telah disahkan. Sebelum sebarang perubahan sampai ke pengeluaran, ia akan diuji terhadap set data tersebut. Recall dan kependaman dipantau dalam masa nyata, bukan sekadar diperhatikan secara kasar dalam buku nota.

Pengambilan bukanlah sekadar demo penyelidikan. Ia adalah infrastruktur. Ia layak menerima ujian unit, penanda aras regresi, dan pengoptimuman automatik sama seperti bahagian lain dalam timbunan (stack) anda. Lakukan chunking mengikut struktur dokumen, bukan mengikut kepercayaan token yang tidak berasas. Gabungkan carian vektor dan carian kata kunci dengan reranker. Kembangkan pertanyaan yang sebenarnya ditulis oleh pengguna anda. Kemudian, biarkan algoritma carian melaraskan parameter (tune the knobs) dan bukannya menggunakan gerak hati anda.

Saluran paip yang kami huraikan ini bukan sekadar teori. Anda boleh membaca penulisan asal di sini, dan jika anda ingin membincangkan kejuruteraan pengambilan dengan komuniti yang mementingkan perkara ini, kumpulan GyaanSetu AI sentiasa terbuka.