Kebanyakan tutorial RAG berakhir tepat pada saat fasa produksi bermula. Anda membahagikan dokumen anda kepada cebisan (chunk) 512-token, menghantarnya melalui satu model embedding, dan memanggil pangkalan data vektor dengan pengambilan top-k yang mudah. Dalam satu demo, ini kelihatan meyakinkan. Tanya bot tentang polisi cuti syarikat anda dan ia akan mengembalikan satu perenggan yang koheren. Semua orang mengangguk. Malangnya, demo menipu.

Produksi mendedahkan setiap jalan pintas. Cebisan tetap memotong kontrak undang-undang di tengah-tengah klausa indemnifikasi. Dokumentasi API bertukar menjadi hingar yang bertindih sehingga menenggelamkan isyarat yang anda sebenarnya perlukan. Latensi meningkat sehingga pengguna meninggalkan pertanyaan sebelum jawapan tiba. Kami menghadapi tembok ini dan terpaksa membina semula. Lapisan pengambilan kami telah berevolusi daripada "carian semantik dan berharap" kepada saluran paip (pipeline) yang terukur dan berinstrumen. Hasilnya ialah 95% recall dan pengurangan 40% dalam latensi. Inilah apa yang sebenarnya berkesan.

Padankan Strategi Chunking dengan Dokumen

Tetapan lalai 512-token kekal kerana ia mudah, bukan kerana ia betul. Dokumen yang berbeza membawa makna dengan cara yang berbeza, dan strategi chunking anda harus mencerminkannya.

Untuk kontrak undang-undang, gunakan chunking rekursif yang menghormati sempadan struktur. Bahasa undang-undang adalah bersarang. Satu klausa bergantung pada seksyen di atasnya, dan potongan tetap di tengah ayat akan memusnahkan logik sesuatu kewajipan. Chunking rekursif cuba melakukan pembahagian pada pemisah semula jadi terlebih dahulu—perenggan, kemudian ayat—sebelum mengenakan had token. Ini memastikan klausa indemnifikasi atau liabiliti kekal utuh.

Untuk dokumentasi API, gunakan chunking yang peka terhadap fungsi (function-aware chunking). Pembangun tidak mencari perenggan rawak; mereka mencari titik akhir (endpoints), parameter, dan tandatangan ralat. Satu cebisan harus mengandungi tandatangan fungsi yang lengkap, huraiannya, dan skema pulangan sebagai satu unit logik. Jika anda membahagikan blok tersebut kepada dua, sistem pengambilan akan mengembalikan separuh konteks dan model penjanaan akan berhalusinasi untuk selebihnya.

Untuk tiket sokongan, bergantung pada chunking semantik yang mengikut giliran perbualan. Bebenang sokongan adalah linear dan berulang. Seorang pelanggan mengulang masalah, ejen meminta log, pelanggan melampirkannya. Setiap giliran adalah unit semantiknya sendiri. Chunking mengikut giliran mengekalkan siapa yang berkata apa dan bila, yang mana sangat penting apabila pengguna bertanya, "Apakah yang dicadangkan oleh ejen pada hari Selasa?"

Untuk wiki dalaman, cuba chunking ejen (agentic chunking). Berikan satu seksyen kepada LLM dan minta ia memutuskan di mana satu topik berakhir dan topik lain bermula. Ini menelan kos lebih tinggi semasa masa pengambilan (ingest), tetapi wiki selalunya tidak teratur. Halaman mengandungi kemas kini yang tidak berkaitan daripada pasukan yang berbeza, dan sempadan yang ditentukan oleh manusia jarang membantu. Membiarkan model melukis sempadan berdasarkan peralihan topik mengurangkan hingar secara drastik.

Menjalankan pelbagai strategi dalam satu saluran paip memerlukan pelabelan dokumen mengikut jenis semasa pengambilan (ingest). Disiplin skema yang kecil itu akan membuahkan hasil dengan segera.

Gabungkan Kaedah Carian, Jangan Pilih Satu Sahaja

Carian vektor memahami niat, tetapi ia sering gagal pada padanan tepat. Minta kod ralat ERR_CONNECTION_REFUSED atau SKU yang khusus, dan embedding padat sering mengembalikan hasil yang serupa secara konsep tetapi salah secara fakta. BM25, kaedah pengambilan jarang kata kunci (keyword sparse retrieval) klasik, mengendalikan rentetan tepat dengan sangat baik tetapi terlepas nuansa semantik. Anda memerlukan kedua-duanya.

Gunakan pengambilan hibrid. Jalankan carian vektor dan BM25 secara selari. Kemudian gabungkan kedua-duanya dengan Reciprocal Rank Fusion (RRF). RRF memberi ganjaran kepada dokumen yang dipersetujui oleh kedua-dua kaedah sebagai relevan, sambil tetap memaparkan calon yang kuat daripada mana-mana pendekatan. Matematiknya mudah dan hasilnya stabil: tiada satu kaedah pengambilan tunggal yang mendominasi kedudukan akhir.

Selepas gabungan (fusion), tambahkan penyusun semula (reranker) cross-encoder. Peringkat pertama — carian vektor ditambah pengambilan jarang — adalah pantas dan luas. Cross-encoder kemudian memberikan skor kepada setiap pasangan pertanyaan-dokumen dengan perhatian penuh, bermakna ia benar-benar membaca calon tersebut berbanding soalan asal. Ya, ini menambah latensi. Dalam kes kami, kira-kira lima puluh hingga seratus milisaat. Tetapi peningkatan dalam ketepatan (precision) adalah cukup ketara sehingga pertukaran itu jelas berbaloi. Anda tidak boleh mengabaikan perkara ini jika anda mementingkan recall.

Baiki Pertanyaan Sebelum Anda Membaiki Indeks

Pengguna tidak menulis pertanyaan untuk enjin carian anda. Mereka menulisnya untuk manusia. "Ia tidak berfungsi" adalah pertanyaan sokongan yang biasa. Huraian ciri yang samar adalah carian wiki dalaman yang biasa. Jika anda mencari indeks dengan input mentah tersebut, anda akan mendapat hasil yang sampah.

Transformasikan pertanyaan sebelum ia sampai ke pengambil (retriever).

Gunakan query expansion untuk menjana pelbagai versi soalan pengguna. Jika seseorang menaip “server down,” sistem anda juga harus mencari “service unavailable,” “502 error,” dan “connection timeout.” Meliputi variasi niat ini telah meningkatkan recall kami daripada 78% kepada 96%. Ia adalah satu langkah tunggal, dan kosnya hampir sifar berbanding hasil yang diperoleh.

Gunakan query decomposition untuk soalan yang kompleks. Apabila pengguna bertanya sesuatu seperti “Bagaimanakah saya hendak berpindah daripada API pengebilan legasi kepada yang baharu dan apakah perubahan drastik yang menjejaskan akaun perusahaan?,” pecahkannya kepada sub-soalan. Satu sub-soalan menyasarkan langkah migrasi. Satu lagi menyasarkan perubahan drastik khusus untuk perusahaan. Setiap satu menyasarkan bahagian indeks yang berbeza. Model bahasa hiliran mensintesis jawapan akhir daripada cebisan (chunks) yang diperoleh dengan baik, bukannya meneka merentasi tetingkap konteks yang bising.

Berhenti Meneka Hiperparameter

Sebaik sahaja anda mempunyai pelbagai strategi chunking, perolehan hibrid, dan transformasi kueri, anda akan menghadapi masalah kombinatorial. Saiz chunk, pertindihan (overlap), pemberat gabungan, kedalaman reranker, dan jumlah pengembangan semuanya saling berinteraksi. Mengubah satu secara berasingan akan merosakkan yang lain. Carian grid (grid search) merentasi ruang ini adalah membazir dan perlahan.

Gunakan pengoptimuman Bayesian sebagai ganti. Anggap ini seperti tugas penalaan pembelajaran mesin. Takrifkan objektif anda dengan jelas: maksimumkan recall sambil mengekalkan kependaman (latency) di bawah had tertentu. Bina satu golden dataset — beberapa ratus soalan representatif di mana anda tahu dengan tepat cebisan mana yang patut diperoleh. Kemudian, biarkan carian Bayesian meneroka ruang konfigurasi secara cekap. Ia membina model kebarangkalian tentang apa yang berkesan dan kemudian menguji kawasan yang paling menjanjikan.

Setiap konfigurasi calon mesti melepasi golden dataset sebelum ia sampai ke peringkat staging. Jika saiz chunk baharu menurunkan recall atau reranker yang lebih berat menyebabkan anda melebihi bajet kependaman, pengoptimuman akan mengesannya secara automatik. Ini menghapuskan unsur pendapat dalam perbincangan. Anda berhenti berdebat sama ada 256 atau 512 token adalah “lebih baik” dan mula membaca hasil yang nyata.

Hasilnya

Perubahan saluran paip (pipeline) ini memberikan kesan kumulatif tepat seperti yang kami harapkan.

  • Recall@10 meningkat daripada 78% kepada 95%.
  • Kependaman P95 menurun daripada 850 ms kepada 320 ms.
  • Kadar halusinasi jatuh daripada 12% kepada 3%.
  • Kos setiap kueri menurun sebanyak 38%, sebahagian besarnya kerana perolehan yang lebih baik membolehkan kami menggunakan model penjanaan yang lebih kecil dan token prompt yang lebih sedikit.

Pengurangan kependaman mengejutkan sesetengah ahli pasukan. Menambah reranker dan query expansion kedengaran seperti ia akan melambatkan proses. Namun, kerana kualiti perolehan bertambah baik, model penjanaan memerlukan kurang prompting, kurang spekulasi, dan kurang percubaan semula. Perolehan yang baik menjadikan segala-galanya di hiliran lebih murah.

Anggap Perolehan Seperti Infrastruktur

Perolehan bukanlah sebuah notebook yang anda jalankan sekali dan kemudian lupakan. Ia adalah infrastruktur, dan ia harus diuruskan seperti kod. Versikan strategi chunking anda. Apabila pasukan undang-undang mengeluarkan templat kontrak baharu, uji pembahagi rekursif (recursive splitter) anda sebelum ia sampai ke pengeluaran (production). Kekalkan golden dataset anda sebagai dokumen yang sentiasa dikemas kini, bukan sekadar fail CSV statik dari suku tahun lepas. Automatikkan penilaian anda dalam CI supaya sebarang pull request yang mengubah model embedding atau pemberat gabungan akan menerima komen dengan angka recall dan kependaman sebelum manusia menyemaknya.

Pengguna anda tidak akan pernah bertanya model embedding mana yang anda gunakan. Mereka tidak akan peduli tentang heuristik chunking atau seni bina reranker anda. Mereka hanya peduli jika jawapannya betul, jika ia sampai dengan cepat, dan jika mereka boleh mempercayainya. Bina saluran paip yang membina kepercayaan tersebut, ukurnya dengan jujur, dan berhenti menganggap perolehan sebagai perkara sampingan.

Sumber: Optimizing RAG At Scale
Sertai perbincangan: GyaanSetu AI Community