Di artikel 3.3, tiga jalur utama sudah dipetakan — dan RAG disebut sebagai jalur yang dipakai sebagian besar kasus bisnis. Di artikel 3.4, grounding dengan sitasi muncul sebagai pertahanan pertama terhadap halusinasi. Kini saatnya membangun jalur itu dari nol: RAG sendiri, dengan dokumen sendiri, di infrastruktur sendiri.

Setiap checkpoint memberi tahu siapa yang seharusnya mengerjakannya: kapan non-teknis cukup, kapan developer masuk, dan kapan tim produksi wajib dilibatkan. Berhenti di checkpoint mana pun adalah keputusan yang sah.

Konsep RAG (Rekap Satu Menit)

RAG adalah prosedur kerja tiga langkah: sebelum menjawab, AI mengambil (retrieve) potongan dokumen yang relevan dari arsip, menempelkannya (augment) ke dalam prompt, lalu menjawab (generate) berdasarkan tempelan itu. Model tidak menghafal dokumen; ia mencarinya setiap kali dibutuhkan.

Dua hal dari artikel 3.2 yang relevan di sini: chunking (cara memecah dokumen menjadi potongan kecil) dan context window (batas kapasitas model). RAG ada justru karena seluruh arsip tidak mungkin ditempel ke context window — maka yang ditempel hanya potongan yang paling relevan. Dan seperti dibahas di artikel 3.4, jawaban yang menempel pada sumber adalah pertahanan pertama terhadap halusinasi: jawaban tanpa sitasi = halusinasi yang terlihat meyakinkan.

🟢 Level 0 & Checkpoint 1: RAG yang Bisa Ditanya

Level 0 — nol instalasi

Sebelum menyentuh apa pun, konsep RAG bisa dicoba langsung di fitur "Projects/Knowledge" milik kotak chat (ChatGPT Projects, Claude Projects, NotebookLM): upload PDF, ajukan pertanyaan, selesai. Ini pintu masuk paling ramah — dan bagi kebutuhan personal, berhenti di sini adalah keputusan yang sah.

Setup lingkungan (untuk jalur berikutnya)

• Install Ollama (ollama.com/download) — tool untuk menjalankan model AI lokal.
• Unduh model: ollama pull qwen2.5:7b (atau llama3.2:3b untuk eksperimen cepat).
• Unduh embedding model: ollama pull nomic-embed-text (mengubah teks menjadi vektor numerik).

Jalur A — No-Code: n8n + Ollama (30 menit)

Prasyarat: bisa klik mouse, punya qVM atau laptop dengan Docker.

1. Buka http://localhost:5678, buat akun.
2. Pastikan Ollama di host yang sama bisa diakses dari container n8n (network bridge).
3. Buat workflow RAG: Trigger → Read Binary File → Extract PDF Text → HTTP Request ke Ollama /api/embeddings → simpan ke ChromaDB; saat ada pertanyaan: embedding → cari top-3 → tempel ke prompt → kirim ke Ollama /api/generate.
4. Test: upload PDF kebijakan perusahaan, tanya "berapa batas refund?", lihat jawaban dengan sitasi.

Jalur B — Kode: Python + LangChain + ChromaDB (1 jam)

Prasyarat: bisa membaca kode Python dasar, Python 3.10+.

Inisialisasi vector store:

Load & chunk dokumen:

Query & jawaban bersitasi:

🟡 Checkpoint 2: RAG untuk Tim

Bagian ini untuk yang ingin naik dari eksperimen ke penggunaan rutin 5–10 orang. Bila hanya butuh RAG untuk diri sendiri, Checkpoint 1 sudah cukup.

Deep dive chunking: tiga teknik kunci

Chunking berjalan di sisi ingestion — sebagai perintah di kode atau field pengaturan di dashboard platform RAG. Embedding bekerja paling baik pada teks pendek dan fokus; satu dokumen 50 halaman menghasilkan embedding "rata-rata" yang kabur.

Teknik 1: Struktur-Aware Chunking — untuk dokumen dengan heading/markdown.

Teknik 2: Semantic Chunking — untuk dokumen panjang dengan topik beragam; memecah di titik perubahan topik.

Teknik 3: Contextual Retrieval (Anthropic, 2024) — setiap chunk ditempel 1–2 kalimat konteks dokumen sebelum embedding. Anthropic melaporkan penurunan kegagalan retrieval sekitar 35%.

Reranking: agar dokumen relevan muncul di top-3

Retrieval awal sering mengambil 10–20 dokumen, tapi yang benar-benar relevan mungkin di posisi 7. Reranking mengurutkan ulang dengan model yang lebih akurat.

(Catatan: reranker Cohere berbayar via API; alternatif open-source: bge-reranker-v2-m3 via Ollama.)

Grounding dengan sitasi

Hardening dasar

Autentikasi (API key/OAuth), rate-limit (mis. 10 query/menit per user), dan logging (catat setiap query, dokumen yang diambil, dan jawaban — untuk audit dan debugging).

🔴 Checkpoint 3: RAG Production-Ready

Evaluasi terukur dengan RAGAS

Bagaimana tahu RAG bagus? Jangan tebak — ukur. RAGAS adalah framework standar industri dengan empat metrik utama:

Iterasi berdasarkan angka, bukan intuisi. Context recall rendah → perbaiki chunking. Faithfulness rendah → perbaiki prompt atau tambah reranking.

Custom test set: 50–100 pertanyaan nyata

Jangan pakai pertanyaan buatan — kumpulkan log query paling sering, mintakan jawaban benar + dokumen sumbernya ke domain expert:

Observability: Langfuse atau Phoenix

Di produksi, perlu terlihat apa yang terjadi — trace setiap query, score dari feedback user, dashboard metrik agregat (latency, cost, accuracy).

Eskalasi infrastruktur: ChromaDB → Qdrant

ChromaDB bagus untuk eksperimen dan skala kecil. Untuk jutaan dokumen, Qdrant lebih cocok: performance optimized untuk large-scale vector search, filtering, payload indexing, dan distributed mode.

Disaster recovery, backup, & security

Vector DB adalah database produksi — perlakukan sama: backup snapshot harian, replication primary-replica, test restore berkala. Untuk data sensitif: enkripsi at-rest, audit trail semua query & user, dan role-based access (admin, user, read-only).

Siapa Mengerjakan Apa: Matriks Peran

Sinyal wajib melibatkan tim teknis — bila salah satu benar, berhenti di jalur mandiri:

• Pengguna melebihi 10 orang atau lintas tim.
• Data mencakup data pribadi/sensitif (konteks UU PDP).
• Butuh integrasi ke sistem internal (CRM/ERP/SSO).
• Ada kebutuhan audit/kepatuhan (ISO 27001/SOC2).
• Volume menuju ribuan query per hari.
• Butuh DR, SLA, atau ketersediaan 24/7.

Long-Context & Agentic RAG: Apakah RAG Masih Relevan?

Long-context tidak menggantikan RAG. Model dengan context window jutaan token mengubah ekonomi RAG, bukan menggugurkannya. Grounding tetap dibutuhkan: dokumen bisa berubah (RAG memperbarui indeks, context window tidak), biaya menempel seluruh arsip di setiap query tidak masuk akal, dan sitasi tetap hanya lahir dari retrieval. "RAG is dead" adalah judul yang bagus; arsitektur nyata tetap memakai retrieval.

Agentic RAG adalah perluasan, bukan pengganti. Pada agen, retrieval menjadi satu tool di antara banyak tool. Prinsip dari artikel 3.4 berlaku penuh: konten eksternal yang masuk ke agen adalah permukaan serangan — guardrails di depan dan approval manusia untuk aksi berakibat tetap wajib.

Dan fenomena RAG-as-a-feature (Projects, NotebookLM, platform no-code) justru menegaskan: retrieval menjadi fitur standar karena ia menyelesaikan masalah yang tidak diselesaikan prompt engineering — menjadikan dokumen sendiri sebagai sumber kebenaran.

Infrastruktur di Balik RAG

RAG butuh infrastruktur — dan pilihannya tergantung checkpoint mana yang dicapai:

• Checkpoint 1 (eksperimen): qVM cukup — VPS NVMe dengan provisioning instan; jalankan Ollama + ChromaDB + n8n di satu server.
• Checkpoint 2 (tim kecil): tetap di qVM dengan spek lebih besar; atau pertimbangkan qMetal bila vector DB tumbuh ke jutaan dokumen.
• Checkpoint 3 (produksi): qMetal adalah eskalasi alami — bare metal dengan NVMe dedicated IOPS hingga 200.000, latensi konsisten. Pemilik GPU sendiri mendapat rumah di qRack. Dan bila tidak ada tim yang menjaga, qManaged menjadikan tim engineer Sequel sebagai perpanjangan tim IT — monitoring 24/7, patching, backup terverifikasi.

Self-hosting RAG bukan hanya soal kendali — tapi juga soal kedaulatan data: dokumen perusahaan tidak perlu mampir ke server pihak ketiga.

Perlindungan Data & Kepatuhan

Data yang di-index masuk ke vector DB — perlakukan sama seperti database produksi: backup rutin, akses terbatas, enkripsi at-rest. Dalam spektrum lima level dari artikel 3.3, RAG self-hosted berada di Level 4–5 — jalur yang tepat untuk data sensitif.

Glosarium

FAQ

Berapa lama waktu membangun RAG sendiri?

Checkpoint 1: 30 menit (no-code) atau 1 jam (kode). Checkpoint 2: 3–5 jam implementasi plus 1 minggu tuning. Checkpoint 3: 1–2 minggu untuk implementasi penuh.

Apakah RAG bisa dibangun tanpa coding?

Bisa. Level 0 (Projects/NotebookLM) cukup upload dokumen; jalur n8n + Ollama + ChromaDB bisa dirakit siapa pun yang bisa klik mouse dalam 30 menit.

Bagaimana mengukur kualitas RAG?

Gunakan RAGAS dengan empat metrik (recall ≥0.8, precision ≥0.7, faithfulness ≥0.85, relevancy ≥0.8), dilengkapi custom test set berisi 50–100 pertanyaan nyata dari pengguna.

Kapan harus melibatkan tim teknis?

Saat pengguna melebihi 10 orang, data sensitif, butuh integrasi internal, kebutuhan audit, volume ribuan query/hari, atau kebutuhan DR/SLA — lihat matriks peran di atas.

Apakah model long-context membuat RAG tidak perlu?

Tidak. Grounding, kesegaran dokumen, biaya, dan sitasi tetap membutuhkan retrieval. Long-context mengubah ekonomi RAG, bukan menggugurkannya.

Langkah Evaluasi Awal

• Mulai dari Level 0 — upload satu dokumen penting ke Projects/NotebookLM dan rasakan perbedaan jawaban bersitasi.
• Buat test set dini — kumpulkan 20 pertanyaan nyata sejak hari pertama; ia menjadi kompas evaluasi di semua checkpoint.
• Tetapkan batas peran — putuskan di awal checkpoint mana yang akan dituju dan siapa yang terlibat, sebelum kebutuhan mendikte terburu-buru.

Pertanyaan Reflektif untuk Evaluasi Internal

Untuk Tim Bisnis/Manajemen:

Dokumen mana yang paling sering ditanyakan berulang — dan apakah jawaban AI atasnya kelak dilengkapi sitasi yang bisa diverifikasi manusia?

Untuk Tim IT/Engineering:

Bila vector DB diperlakukan seperti database produksi — backup, akses terbatas, enkripsi — apakah seluruh perlakuan itu sudah berjalan, atau masih "nanti saja"?

Daftar Pustaka

• Lewis, P., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. · arxiv.org
• Anthropic. (2024). Introducing Contextual Retrieval. · anthropic.com
• Es, S., et al. (2024). RAGAS: Automated Evaluation of Retrieval Augmented Generation. · arxiv.org
• LangChain Documentation. Retrieval-Augmented Generation. · python.langchain.com
• Ollama Documentation. Running Models Locally. · ollama.com
• Langfuse Documentation. LLM Observability. · langfuse.com