Kebanyakan tutorial RAG berakhir di peringkat notebook. Mereka memuatkan beberapa PDF yang kemas, membahagikan teks setiap seribu aksara, memasukkan fragmen tersebut ke dalam pangkalan data vektor, dan menganggapnya sebagai satu seni bina. Pada petang Jumaat, demo tersebut berjalan dengan sempurna. Namun dalam persekitaran produksi, saluran (pipeline) yang sama secara senyap berubah menjadi liabiliti.
Kekangan sebenar dalam sistem pencarian semula (retrieval) jarang sekali terletak pada model atau prompt. Ia terletak pada ingestion. Saluran RAG hanya boleh mendapatkan apa yang telah diberikan kepadanya, dan jika input tersebut bising, lapuk, atau tidak lengkap, model akan memberikan jawapan tidak masuk akal dengan penuh yakin. Apabila pengguna mengadu bahawa bot tersebut berhalusinasi, kesalahannya sering kali terletak jauh di peringkat awal dalam saluran data yang tidak dipantau dengan teliti oleh sesiapa pun.
Perangkap Papan Putih
Rajah seni bina membuatkan proses ingestion kelihatan seperti satu anak panah tunggal berlabel “Documents → Vector DB.” Hakikatnya jauh lebih rumit. Sistem sumber berubah tanpa pemberitahuan. Susun atur HTML direka semula. URL dialihkan ke halaman pendaratan generik. Rangka kerja JavaScript menukar kandungan selepas respons HTTP awal. Menganggap ingestion sebagai tugas penyediaan sekali sahaja adalah kesilapan pertama. Ia adalah masalah kejuruteraan data yang berterusan yang memerlukan ketelitian yang sama seperti mana-mana saluran ETL.
Mengapa Kegagalan RAG Biasanya Berpunca daripada Kegagalan Input
Bayangkan situasi ini: seorang pengguna bertanya kepada pembantu dalaman anda tentang polisi pemulangan wang semasa. Model tersebut mengambil cebisan (chunk) teratas daripada stor vektor dan menyatakan tempoh 30 hari. Polisi sebenar telah berubah kepada 60 hari pada suku tahun lepas. LLM tersebut tidak mencipta jawapan yang salah. Ia hanya mempercayai input yang buruk. Lapisan retrieval telah memberikan halaman lama, dan kerana embedding tersebut kelihatan cukup dekat dari segi semantik, model menganggapnya sebagai kebenaran asas (ground truth).
Corak ini berulang secara berterusan. Pasukan menghabiskan berjam-jam melaraskan temperature dan top-k sedangkan korpus mereka penuh dengan bahagian kaki (footer) navigasi, siaran akhbar pendua, dan cebisan yang membahagikan jadual kepada dua. Sebelum anda mengoptimumkan penjanaan (generation), audit dahulu apa yang dibenarkan untuk diketahui oleh sistem anda.
Tujuh Perangkap yang Merosakkan Ingestion
1. Larian Pertama Adalah Penipuan
Tanda semak hijau pada proses 'crawl' awal anda hampir tidak bermakna. Data produksi sentiasa berubah. Halaman dokumentasi disusun semula, pautan kekal (permalink) blog rosak, dan peta laman (sitemap) menggugurkan bahagian secara senyap. Jika anda hanya mengesahkan bahawa saluran tersebut selesai tanpa ralat, anda sebenarnya sedang terbang membuta tuli. Anda perlu mengesahkan output tersebut. Pastikan dokumen yang diharapkan ada, strukturnya masih boleh dibaca, dan jumlah keseluruhan teks tidak merosot kerana sesuatu sumber memutuskan untuk membahagikan keputusan mengikut halaman (paginate) secara berbeza.
2. Crawling Bukanlah Ingestion
Mengambil HTML adalah bahagian yang mudah. Proses 'crawl' mentah menangkap segalanya: sepanduk kuki, bar sisi "Artikel Berkaitan", blok iklan, dan notis hak cipta di bahagian kaki. Jika anda membahagikan HTML mentah tersebut secara melulu, setiap cebisan teks akan membawa bersama fragmen menu navigasi. Apabila pengguna bertanya tentang had kadar API, retriever mungkin memaparkan cebisan yang 40 peratusnya adalah pautan bar sisi. Pengekstrakan yang bersih adalah penting. Anda perlu mengenal pasti kawasan kandungan utama, membuang kandungan boilerplate, dan mengeluarkan elemen yang berulang di setiap halaman. Jika tidak, anda bukan sedang membina pangkalan pengetahuan, tetapi anda sedang membina enjin carian untuk elemen luaran (chrome) laman web.
3. Chunking Merosakkan Makna
Pembahagian saiz tetap (fixed-size chunking) adalah tetapan lalai dalam hampir setiap panduan pantas, dan ia sangat berbahaya. Jika anda membahagikan dokumen semata-mata berdasarkan jumlah aksara, anda akan memotong jadual tepat di tengah, memisahkan langkah 4 dan 5 dalam prosedur bernombor, dan menyebabkan titik peluru (bullet points) terasing daripada tajuknya. Satu cebisan yang hanya mengandungi separuh bahagian daripada jadual harga adalah tidak berguna dari segi semantik. Chunking yang peka struktur menghormati format asal. Analisis hierarki tajuk. Kekalkan jadual secara utuh jika boleh. Bahagikan pada sempadan perenggan di bawah H2 atau H3 yang sama. Kekalkan senarai di dalam satu cebisan jika ia cukup pendek. Matlamatnya bukan blok bersaiz seragam, tetapi unit makna yang koheren.
4. Masalah Kesegaran Data
A static snapshot of an internal wiki is simple mode. Continuously ingesting from the live web is hard. You need to know when a page was last gathered, whether it has changed since then, and how long the information remains valid. Stale data does not always mean a visibly old date. Sometimes a page updates its text but keeps the same URL, so your system never notices without content hashing. Build clear refresh rules based on source volatility. A financial data feed might need hourly checks. A company about page might need quarterly checks. Record timestamps and set time-to-live boundaries, especially if your domain involves regulated or safety-critical guidance where old facts can cause real harm.
5. Duplicate Pollution
Websites are full of repetition. The same product description appears on the category page, the product page, and a promotional landing page. The same press release lives under /news/, /press/, and /blog/. Vector search does not deduplicate automatically. If ten nearly identical chunks sit in your database, they can crowd out diverse, relevant results in your top-k retrieval. You need canonical tracking or content deduplication before embedding. If two chunks say the same thing, keep the authoritative source and drop the copies. Your retriever has limited slots. Do not let them go to waste.
6. Missing Metadata
A vector database without metadata is just a dense text search engine with no memory of context. Smart retrieval depends on filtering and ranking signals that raw embeddings cannot provide. Store the source URL, the capture date, the document category, and the version number. If you ingest API documentation, versioning is essential. Without it, a query might blend v1 and v2 specs into the same answer. If you ingest HR policies, tagging by region or department lets you filter results before they ever reach the model. Metadata turns a text dump into a curated knowledge system.
7. JavaScript Gaps
Modern sites do not ship their content in the first HTML payload. They send a skeleton and hydrate it with JavaScript calls. A basic HTTP request might see nothing but a loading spinner and a layout shell. If your pipeline cannot execute JavaScript, you will ingest blank pages or partial fragments and never realize anything is wrong. Using a headless browser solves the rendering problem but introduces new ones: heavier memory use, slower throughput, and bot detection walls. Choose your trade-offs deliberately, but do not pretend a simple curl equivalent is enough for every source.
A Practical Ingestion Checklist
If you are building or reviewing a RAG feed, start here:
- Validate source coverage and pagination. A sitemap might list only the first ten articles in a category. Crawl deep and verify that paginated or dynamically loaded content is actually captured.
- Remove boilerplate before chunking. Strip navigation, ads, footers, and repeated legal disclaimers. If a phrase appears on every page, it is noise.
- Use structure-aware chunking. Respect headings, bullet lists, and tables. Split on semantic boundaries, not character counts.
- Attach rich metadata. Include URL, capture date, content category, and version. Make these fields filterable in your retrieval queries.
- Set refresh frequencies based on data volatility. High-change sources need frequent re-crawls. Static archives do not.
- Monitor the corpus, not just the job status. A pipeline can exit with code zero while producing garbage. Audit samples of stored chunks regularly for drift and quality.
- Define rules for versioning and deletions. When a source page is removed, delete its chunks. When it updates, overwrite or version them. Orphaned data is a silent killer.
The Hard Truth About Embeddings
No embedding model, no matter how advanced, can repair a missing document. It cannot guess that a page was updated last week if your feed still holds last year's copy. It cannot infer the context of a table row that got separated from its header by a bad chunk boundary. Embeddings compress meaning, but they do not create meaning where the ingestion layer failed to preserve it.
Retrieval quality starts at the ingestion layer. That layer decides whether your RAG system is a useful tool or just a confident liar with a vector database behind it.
The Real Takeaway
Berhenti mengukur kesihatan pengambilan data hanya dengan papan pemuka pipeline sahaja. Status tugasan yang berjaya dan log yang bersih tidak menjamin korpus yang bersih. Buka pangkalan data dan baca cebisan data sebenar yang akan diambil oleh pengguna anda. Jika teks tersebut penuh dengan notis hak cipta, jadual yang terputus, dan halaman polisi yang lapuk, masalah anda bukanlah LLM tersebut. Baiki suapan data terlebih dahulu. Segala-galanya yang lain hanyalah penalaan di atas sampah.