Mengapa Jawapan yang Yakin Boleh Menjadi Lebih Buruk Daripada Tiada Jawapan
Anda selesai membina chatbot dalaman. Anda memasukkan setiap polisi HR, spesifikasi kejuruteraan, dan dokumen orientasi yang dimiliki syarikat anda. Seorang pekerja baharu bertanya tentang had perbelanjaan perjalanan untuk makan malam pelanggan. Bot tersebut menjawab dengan serta-merta. Ia kedengaran sangat yakin. Had yang dinyatakan adalah $75 seorang.
Polisi sebenar menyatakan $50. Bot tersebut telah mereka-reka jawapan itu. Ia tidak pernah membuka fail anda. Ia hanya meneka, berdasarkan corak yang terpendam dalam data latihannya dari bertahun-tahun yang lalu. Inilah realiti pahit menjalankan model bahasa besar (LLM) mentah terhadap dokumen peribadi. Ia tidak mempunyai akses kepada pengetahuan dalaman anda. Apabila fakta yang diperlukan berada di luar pemberat latihannya, ia akan mereka-reka fakta dan bukannya mengaku tidak tahu. Dalam fasa produksi, perkara ini bukan lagi sesuatu yang melucukan, sebaliknya ia mula menjadi liabiliti.
Retrieval-Augmented Generation, atau RAG, dibina khusus untuk menyelesaikan masalah ini. Daripada meminta model untuk mengingati segalanya, anda membenarkannya untuk mencari maklumat.
Daripada Meneka kepada Membaca
Bayangkan LLM mentah sebagai seorang rakan sekerja yang bijak dengan memori fotografik, tetapi dia telah meninggalkan syarikat anda sebelum anda menyertainya. Mereka boleh menulis prosa yang fasih, menaakul melalui teka-teki logik, dan menjelaskan konsep dalam istilah yang mudah. Namun, jika anda bertanya tentang perubahan API suku tahun lepas, mereka hanya akan mereka-reka sesuatu yang kedengaran munasabah. Mereka tidak mempunyai pilihan lain.
RAG memberikan rakan sekerja tersebut akses kepada kabinet fail. Apabila pengguna bertanya soalan, sistem tidak melontarkan soalan itu secara melulu kepada model. Ia terlebih dahulu mendapatkan dokumen yang relevan, memasukkannya ke dalam prompt sebagai konteks, dan hanya selepas itu meminta model untuk membaca dan menjawab. Model tersebut beralih daripada sekadar mengingat fakta kepada memahami fakta yang secara literal berada di hadapannya.
Aliran ini terbahagi dengan jelas kepada dua bahagian: kerja asas luar talian (offline) dan respons dalam talian (online).
Fasa 1: Fasa Persediaan (Luar Talian)
Jauh sebelum sesiapa menaip soalan, anda mesti menukarkan koleksi dokumen anda yang berselerak menjadi pangkalan pengetahuan yang boleh dicari. Kerja asas ini menentukan sama ada sistem RAG anda akan berkembang maju atau gagal secara senyap.
Document loaders adalah titik permulaan anda. Penyambung (connectors) ini menarik teks mentah daripada PDF, ruang kerja Notion, folder SharePoint, halaman web, dan wiki dalaman. Di sinilah realiti mula terasa. Sebuah loader mungkin mengekstrak teks yang bersih daripada dokumen Word, tetapi gagal memproses PDF imbasan yang sebenarnya hanyalah imej tanpa lapisan teks terbenam. Loader tersebut mengembalikan string kosong, pangkalan data anda tidak menyimpan apa-apa, dan pengguna anda kemudiannya mendapat respons "Saya tidak tahu" tanpa sebarang amaran. Sentiasa sahkan apa yang sebenarnya diekstrak oleh loader anda. Lakukan semakan rawak pada beberapa dokumen daripada setiap sumber sebelum anda mempercayai saluran (pipeline) tersebut.
Seterusnya ialah text splitting, juga dikenali sebagai chunking. Anda tidak boleh memasukkan polisi keselamatan sebanyak lapan puluh halaman ke dalam satu prompt sekaligus; anda akan melampaui had konteks dan menenggelamkan isyarat dalam bunyi bising (noise). Sebaliknya, anda memotong dokumen kepada bahagian-bahagian kecil (chunks). Triknya adalah memilih saiz yang betul. Chunk yang terlalu kecil, seperti satu ayat tunggal, sering kali menghilangkan konteks kritikal. Satu chunk yang berbunyi "Semua permintaan mesti diluluskan oleh pengurus" terlupa menyatakan bahawa peraturan ini hanya terpakai untuk perjalanan antarabangsa. Chunk yang terlalu besar, seperti bab penuh, mencairkan embedding dan mengelirukan pencarian (retrieval) kerana ia merangkumi lima belas topik berbeza sekaligus. Dalam praktiknya, banyak pasukan bermula dengan chunk antara 300 hingga 500 token, dengan pertindihan (overlap) sebanyak 50 token supaya ayat yang merentasi sempadan tidak terputus atau rosak. Laraskan ini berdasarkan kandungan anda. Dokumentasi API boleh menerima chunk yang lebih kecil. Kontrak undang-undang sering memerlukan chunk yang lebih besar untuk mengekalkan logik bersyarat.
Setelah dipecahkan kepada chunk, setiap bahagian ditukarkan kepada embedding. Ini bermakna menjalankan teks melalui model yang menghasilkan senarai nombor, iaitu vektor, yang mewakili makna semantik chunk tersebut. Idea yang serupa akan berada berdekatan antara satu sama lain dalam ruang matematik ini. "polisi padanan 401k" dan "peraturan caruman persaraan" akan berada lebih dekat berbanding "polisi padanan 401k" dan "penyediaan pencetak pejabat." Vektor-vektor ini disimpan dalam vector database, seperti Pinecone, Weaviate, atau alternatif sumber terbuka seperti Chroma. Vector store bukan sekadar tempat pembuangan. Ia adalah indeks yang dioptimumkan untuk carian jiran terdekat anggaran (approximate nearest-neighbor search), membolehkan anda mencari chunk yang paling relevan dalam masa milisaat walaupun merentasi berjuta-juta dokumen.
Fasa 2: Laluan Langsung (Dalam Talian)
When a user finally asks, "What is our travel reimbursement policy for client dinners?", the live pipeline kicks in.
The