Imagine you hire a consultant who is genuinely brilliant — reads everything, knows all the frameworks, explains concepts clearly. But when you ask about your company's specific SOPs, your pricing structure, or details of a contract you just signed — dia hanya boleh reka jawapan based on what she thinks is logical.
That is an LLM without RAG.
Models like Claude or GPT-4 are trained on vast but general data. They know how to do many things well. But they don't know about your 3,000-SKU product catalogue, the refund policy you updated last month, or the outstanding issue customer XYZ raised in Q3 last year.
If you force the model to answer questions about those specifics without providing the actual information, ia akan buat apa yang LLM memang direka untuk buat: generate the most probable text based on its training patterns. That text will look confident and well-structured. And there is a real chance it is wrong.
In a business context, a wrong answer that sounds convincing is more dangerous than an answer that clearly says it doesn't know.
Apa itu RAG dan kenapa ia penting?
RAG — Retrieval-Augmented Generation — is an architecture where the agent, before generating an answer, first retrieves relevant information from your knowledge base. That retrieved information becomes additional context for the LLM to generate an answer grounded in real data.
The fundamental difference: without RAG, the agent relies entirely on what is in its training data and the current context window. With RAG, the agent can access and reason about knowledge you curate — and it knows where the information came from.
Kenapa "retrieval" dan bukan sekadar "paste semua document dalam prompt"?
Context window LLM ada limit — dan besar pun ia mahal dari segi token cost. Kalau product catalogue korang ada 3,000 item, korang tak boleh paste semua dalam setiap query. RAG solve ini dengan retrieve hanya bahagian yang relevan dengan soalan spesifik yang ditanya — cekap dan tepat sasaran.
Macam mana RAG pipeline sebenarnya kerja
RAG ada dua fasa yang berlaku pada masa berbeza: indexing yang berlaku sekali (atau secara berkala bila data update), dan retrieval yang berlaku setiap kali ada query.
Fasa 1 — Indexing: Proses knowledge korang
Fasa 2 — Retrieval: Jawab query dengan context sebenar
Jenis-jenis RAG dan bila guna mana satu
Bukan semua RAG implementation sama. Ada spectrum dari simple ke complex, dan pilihan yang betul bergantung pada use case korang — bukan pada mana satu yang nampak paling canggih.
| Jenis RAG | Cara kerja | Sesuai untuk | Tradeoff |
|---|---|---|---|
| Basic RAG | Embed → retrieve → generate. Straightforward pipeline. | FAQ systems, product info lookup, internal KB search | Boleh miss context kalau query ambiguous atau knowledge tersebar dalam banyak chunks |
| Hybrid RAG | Combine semantic search (vector) dengan keyword search (BM25). Kedua-dua hasil di-merge dan reranked. | Cases di mana exact term penting — nombor model, kod produk, nama undang-undang | Lebih complex, perlu tuning dua sistem retrieval |
| Agentic RAG | Agent decide bila dan macam mana nak retrieve — boleh buat multiple retrieval calls, reformulate query, atau combine dari multiple knowledge bases. | Complex multi-step reasoning, cross-domain queries, procurement intelligence | Latency lebih tinggi, lebih mahal dari segi token, perlu careful design |
| GraphRAG | Knowledge disimpan sebagai graph — entities dan relationships — bukan hanya teks chunks. | Cases di mana relationships antara entities penting (contoh: siapa connected dengan siapa dalam procurement network) | Complex ingestion pipeline, niche use case |
Untuk kebanyakan Malaysian SME yang baru mula, Basic RAG adalah tempat yang betul untuk start. Solve 80% of use cases dengan complexity yang manageable. Hybrid RAG bila korang ada keperluan untuk exact match yang kritikal. Agentic RAG bila workflow korang genuinely require multi-step reasoning across sources.
Contoh aplikasi untuk Malaysian SME
Syarikat Perundangan / Firma Guaman
Knowledge base: semua precedent cases, contract templates, legislative updates, client engagement letters. Agent boleh retrieve relevant precedents bila lawyer draft contract baru, flag clauses yang mungkin ada conflict dengan perundangan semasa, atau answer soalan tentang engagement terms tanpa perlu scroll manual.
Tanpa RAG: agent akan cuba jawab soalan perundangan dari general knowledge — dangerous, sebab law Malaysia ada nuances spesifik yang LLM general mungkin tak accurate.
Distributor / Syarikat Trading
Knowledge base: product catalogue dengan specs penuh, pricing tiers by customer segment, stock levels dari ERP (sync secara berkala), warranty terms, supplier lead times. Sales agent boleh answer detailed product queries, compare specs antara items, dan quote dengan pricing yang betul — tanpa kena call warehouse atau check spreadsheet manually.
Klinik / Healthcare Provider
Knowledge base: clinical protocols, medication formulary, patient FAQ, appointment policies, PDPA compliance procedures. Agent handle patient queries dengan grounded dalam protocol sebenar klinik — bukan general medical advice yang mungkin tak accurate untuk konteks Malaysian healthcare system.
Macam mana IRIS guna RAG: Dalam sistem procurement kami, setiap tender pursuit ada associated knowledge base — dokumen tender, specification sheets, historical bid data untuk tender serupa, contact intelligence untuk officer yang listed. Bila Aisyah (bid writing specialist) nak draft proposal, dia retrieve relevant precedents dari tender yang lepas yang kami menang dalam kategori yang sama. Bila Faridah (compliance) review dokumen, dia query regulatory knowledge base untuk flag requirements yang specific to tender tu. Retrieval yang targeted, bukan dump semua benda dalam satu context.
Kenapa RAG gagal — dan macam mana elak
RAG bukan silver bullet. Ada beberapa failure modes yang kami dah encounter dalam production dan nampak orang lain pun encounter:
1. Garbage in, garbage out
Ini yang paling common. Kalau knowledge base korang ada dokumen yang outdated, contradictory, atau poorly structured — RAG akan retrieve dan present maklumat yang salah dengan confidence yang sama tingginya macam kalau ia betul. Agent tak distinguish antara "ini dokumen lama" dan "ini dokumen terkini" kecuali korang explicitly handle metadata dan versioning.
Fix: Establish governance untuk knowledge base sebelum build RAG atas dia. Siapa yang bertanggungjawab update? Apa process untuk retire outdated documents? Metadata macam last_updated dan source_authority wajib ada.
2. Chunking strategy yang salah
Split document di tempat yang salah dan korang akan retrieve chunks yang tak ada cukup context untuk berguna. Bayangkan retrieve satu chunk yang cuma ada "...seperti yang dinyatakan dalam jadual di atas, kadar adalah..." tanpa ada jadual atau angka sebenar dalam chunk tu.
Fix: Experiment dengan chunk size dan overlap. Untuk dokumen yang ada struktur (contract clauses, product specs), consider structural chunking — split ikut section headers, bukan ikut token count semata.
3. Retrieval precision yang rendah
Agent retrieve chunks yang semantically dekat tapi bukan yang paling relevant untuk context sebenar. Ini produce jawapan yang technically grounded tapi menjawab soalan yang sedikit berbeza dari apa yang ditanya.
Fix: Evaluate retrieval quality secara berasingan dari generation quality. Test dengan real queries dari domain korang. Hybrid RAG (tambah keyword matching) sering improve precision untuk domain-specific terminology.
4. Missing knowledge
Agent retrieve dengan baik, tapi jawapan yang diperlukan memang tak ada dalam knowledge base. Tanpa explicit handling, ada LLM yang akan "fill the gap" dengan hallucination.
Fix: Instruction yang jelas dalam system prompt: kalau retrieved context tak contain maklumat yang cukup untuk jawab soalan, agent mesti acknowledge tu secara explicit — bukan reka. "Berdasarkan maklumat yang saya ada, saya tak jumpa detail tentang X. Korang boleh semak dengan [specific person/system]."
Apa yang perlu ada sebelum korang build RAG
Soalan yang betul untuk tanya sebelum invest dalam RAG implementation:
- Knowledge base korang ada ke? Bukan semua SME ada documentation yang cukup. Kalau knowledge syarikat korang mostly dalam kepala orang, dalam WhatsApp threads, atau dalam spreadsheets yang tak terstruktur — step pertama adalah knowledge capture, bukan RAG build.
- Siapa yang akan maintain ia? RAG bukan set-and-forget. Bila product pricing berubah, bila policy update, bila prosedur baru implemented — knowledge base perlu update. Kalau tak ada process untuk ini, system korang akan degrade over time.
- Apa sensitivity level data korang? Kalau knowledge base korang contain customer PII, financial data, atau confidential business information — ada infrastructure dan access control considerations yang perlu di-address sebelum data tu masuk dalam vector database. Artikel 3.4 akan cover ini dalam konteks PDPA Malaysia.
- Korang boleh evaluate quality? Macam mana korang tahu kalau RAG system korang perform dengan baik? Perlu ada evaluation set — soalan yang korang tahu jawapan betulnya — untuk measure retrieval precision dan generation accuracy secara sistematik.
Kalau jawapan korang untuk soalan 1 dan 2 solid, korang dah separuh jalan. RAG implementation yang baik adalah 20% engineering dan 80% data hygiene.
Takeaway
RAG adalah komponen kritikal untuk AI agent yang korang boleh trust dalam context business sebenar. Tanpa ia, agent korang adalah pandai tapi buta — capable secara general, clueless tentang specifics yang matter untuk operasi harian korang.
Tapi RAG bukan magic. Ia amplify kualiti knowledge base yang korang bagi ia. Invest dalam data dulu, architecture kemudian.
Artikel seterusnya dalam series ni akan cover Human-in-the-Loop — macam mana design agent systems yang ada oversight yang betul, approval gates di tempat yang tepat, dan escalation paths yang jelas supaya korang tak fully surrender control kepada automation yang belum proven.