5.1 Konsep RAG

Tujuan bab

Setelah bab ini kamu bisa:

• Menjelaskan kelima tahap pipeline RAG dan apa yang terjadi di masing-masing
• Membedakan tahap ingest dan tahap query, serta tahu kapan masing-masing berjalan
• Menjelaskan apa itu embedding dengan bahasa sendiri
• Memutuskan kapan RAG tepat dipakai dan kapan tool biasa lebih baik
• Menyebutkan tiga cara RAG bisa gagal meski kodenya benar

Prasyarat

• 3.3 Semantic Recall

Kenapa tidak dikirim saja semuanya?

Pertanyaan wajar sebelum membahas RAG: kalau model butuh tahu isi dokumen, kenapa tidak kirim saja seluruh dokumennya ke dalam konteks?

Tiga alasan.

Muat tidaknya. Basis pengetahuanmu mungkin ratusan halaman. Jendela konteks model, sebesar apa pun, punya batas.

Biaya. Kamu membayar per token, di setiap panggilan. Mengirim seluruh manual produk untuk menjawab satu pertanyaan tentang garansi adalah pemborosan yang berlipat.

Ketepatan. Ini yang paling sering diabaikan, dan justru paling penting. Model yang diberi lima puluh halaman untuk menemukan satu paragraf relevan akan lebih sering keliru daripada model yang diberi tiga paragraf yang tepat. Konteks yang lebih banyak tidak selalu berarti jawaban yang lebih baik.

RAG menjawab ketiganya dengan satu ide: jangan kirim semuanya, kirim yang relevan saja.

Anatomi pipeline

RAG punya dua tahap yang berjalan pada waktu berbeda, dan memisahkan keduanya dalam pikiranmu akan sangat membantu.

Tahap ingest berjalan di luar percakapan — saat kamu pertama kali memuat dokumen, dan setiap kali dokumen berubah. Ini pekerjaan batch.

Tahap query berjalan setiap kali ada pertanyaan, dan harus cepat.

Kesalahan umum di awal adalah mencampur keduanya — memproses dokumen setiap kali pertanyaan datang. Itu lambat dan mahal tanpa manfaat apa pun.

Lima tahap, satu per satu

1. Dokumen

Titik awalnya bisa berupa teks biasa, HTML, Markdown, atau JSON. Mastra menyediakan MDocument sebagai pembungkus yang menyeragamkan keempatnya.

2. Chunking

Dokumen dipotong menjadi bagian-bagian kecil. Kenapa? Karena yang diambil saat query adalah potongan, bukan dokumen utuh — dan potongan yang terlalu besar membawa terlalu banyak hal tak relevan, sementara yang terlalu kecil kehilangan konteks.

Ini keputusan desain yang paling berpengaruh pada mutu RAG, dan dibahas tuntas di 5.2.

3. Embedding

Tiap potongan diubah menjadi embedding — deretan angka yang mewakili maknanya.

Cara memikirkannya: bayangkan setiap potongan teks diberi koordinat dalam ruang berdimensi banyak, di mana teks yang maknanya berdekatan mendapat koordinat yang berdekatan pula. "Kebijakan pengembalian barang" dan "prosedur retur produk" akan mendarat berdekatan meskipun tidak berbagi satu kata pun.

Itulah kenapa pencarian berbasis embedding menemukan hal yang tidak ditemukan pencarian kata kunci.

4. Penyimpanan

Embedding disimpan di vector store — basis data yang dioptimalkan untuk menjawab pertanyaan "mana yang koordinatnya paling dekat dengan ini?".

Mastra mendukung banyak pilihan: libSQL untuk lokal, dan untuk produksi ada pgvector, MongoDB, Pinecone, Qdrant, OracleDB, dan lainnya.

5. Retrieval

Saat pertanyaan datang, ia melalui proses yang sama: diubah jadi embedding, lalu dipakai mencari potongan dengan koordinat terdekat. Potongan yang ditemukan disisipkan ke konteks model, dan model menjawab dari situ.

Bagian "Augmented" dalam Retrieval-Augmented Generation merujuk pada langkah penyisipan ini — konteks model diperkaya sebelum ia menjawab.

RAG atau tool biasa?

Keduanya memberi agent akses ke data di luar model, jadi wajar bingung memilih. Pembedanya bentuk pertanyaan.

Pakai tool kalau	Pakai RAG kalau
Data punya pengenal yang jelas	Jawaban tersebar di teks
Pertanyaannya presisi: "pesanan 4417"	Pertanyaannya konseptual: "bagaimana kebijakan kami soal…"
Sumbernya basis data atau API	Sumbernya dokumen, artikel, transkrip
Jawabannya harus mutakhir detik ini	Jawabannya berubah lambat
Datanya terstruktur	Datanya prosa

Perhatikan baris keempat. RAG punya jeda: dokumen yang berubah baru bisa ditemukan setelah diproses ulang. Untuk harga saham atau stok gudang, itu tidak dapat diterima — pakai tool.

Dan tentu saja keduanya bisa dipakai bersamaan dalam satu agent. Itu justru susunan yang lazim di aplikasi nyata.

Tiga cara RAG gagal meski kodenya benar

Ini yang membedakan RAG yang berguna dari RAG yang sekadar jalan. Ketiganya bukan bug — semuanya keputusan desain.

Potongan yang salah ukuran. Terlalu besar, dan setiap hasil pencarian membawa banyak teks tak relevan yang mengaburkan yang penting. Terlalu kecil, dan potongan kehilangan konteks — sebuah kalimat yang berbunyi "hal ini tidak berlaku untuk pelanggan korporat" tidak berguna kalau "hal ini" ada di potongan sebelumnya.

Potongan yang benar tidak pernah ditemukan. Bisa karena topK terlalu kecil, atau karena cara pengguna bertanya sangat berbeda dari cara dokumen menuliskannya.

Potongan ditemukan tapi diabaikan. Model menerima konteks yang tepat, tapi tetap menjawab dari pengetahuan umumnya. Biasanya karena instruksi tidak menegaskan bahwa jawaban harus bersumber dari konteks yang diberikan.

Yang ketiga paling berbahaya karena paling sulit terdeteksi — jawabannya terdengar masuk akal, dan kamu baru tahu salah saat ada yang mengeceknya.

Instruksi untuk agent berbasis RAG

Sertakan aturan eksplisit di instructions: jawab hanya dari konteks yang diberikan, dan kalau konteks tidak memuat jawabannya, katakan tidak tahu. Tanpa itu, model akan mengisi kekosongan dengan tebakan yang meyakinkan.

Gambaran kode yang akan kamu tulis

Sebagai peta untuk dua bab berikutnya, inilah bentuk keseluruhannya:

// 1. Buat dokumen
const doc = MDocument.fromText('Isi dokumenmu di sini...')

// 2. Potong jadi chunk
const chunks = await doc.chunk({ strategy: 'recursive', maxSize: 512, overlap: 50 })

// 3. Buat embedding untuk tiap chunk
const { embeddings } = await embedMany({
  values: chunks.map(chunk => chunk.text),
  model: new ModelRouterEmbeddingModel('openai/text-embedding-3-small'),
})

// 4. Simpan ke vector store
await vectorStore.upsert({ indexName: 'embeddings', vectors: embeddings })

// 5. Cari yang mirip
const results = await vectorStore.query({
  indexName: 'embeddings',
  queryVector,
  topK: 3,
})

Lima baris utama untuk lima tahap. Sisanya adalah keputusan tentang angka dan strategi — dan di situlah letak seluruh perbedaan mutu.

Kesalahan umum

Gejala: Setiap pertanyaan pengguna memakan waktu lama dan biaya besar, padahal dokumennya tidak berubah. Penyebab: Tahap ingest dijalankan bersama tahap query — dokumen dipotong dan di-embed ulang setiap kali ada pertanyaan. Perbaikan: Pisahkan keduanya. Ingest adalah pekerjaan batch yang dijalankan saat dokumen dimuat atau diperbarui; query hanya melakukan pencarian.

Gejala: Agent menjawab dengan percaya diri tapi isinya tidak sesuai dokumen, padahal potongan yang benar terbukti ditemukan. Penyebab: Instruksi agent tidak mewajibkan jawaban bersumber dari konteks, sehingga model mencampurnya dengan pengetahuan umum. Perbaikan: Tegaskan di instructions bahwa jawaban harus berdasar konteks yang diberikan, dan bahwa "tidak ada informasi soal itu" adalah jawaban yang sah.

Coba sendiri

Tantangan: Belum ada kode di bab ini. Latihannya adalah merancang, dan ini keterampilan yang menentukan apakah RAG-mu nanti berguna.

Ambil satu kumpulan dokumen nyata yang kamu punya — bisa dokumentasi internal, catatan kuliah, atau arsip artikel. Kalau tidak ada, pakai skenario ini: basis pengetahuan support sebuah layanan hosting, berisi 40 artikel bantuan sepanjang 1–3 halaman masing-masing.

Jawab enam pertanyaan berikut secara tertulis:

1. Berapa besar potongan yang masuk akal untuk dokumen ini, dan kenapa? Pikirkan: seberapa panjang satu gagasan utuh dalam dokumenmu?
2. Apakah potongan perlu tumpang tindih? Apa yang hilang kalau tidak?
3. Sebutkan tiga pertanyaan yang kemungkinan akan diajukan pengguna, dengan kata-kata yang mereka pakai sehari-hari — bukan istilah yang dipakai dokumenmu
4. Untuk tiap pertanyaan itu, tebak: apakah potongan yang benar akan ditemukan? Kalau ragu, kenapa?
5. Bagian mana dari kebutuhan ini yang sebenarnya lebih tepat memakai tool daripada RAG?
6. Kalau agent tidak menemukan jawaban, apa yang seharusnya ia katakan? Tulis kalimatnya.

Checklist penerimaan:

• [ ] Jawaban nomor 1 merujuk pada sifat dokumenmu, bukan angka yang kamu dengar dari orang lain
• [ ] Ketiga pertanyaan di nomor 3 memakai bahasa pengguna awam, dan minimal satu di antaranya tidak memakai istilah yang ada di dokumen
• [ ] Kamu menemukan setidaknya satu kebutuhan yang lebih tepat memakai tool
• [ ] Kalimat di nomor 6 sudah siap disalin ke instructions
• [ ] Kamu bisa menjelaskan perbedaan tahap ingest dan tahap query, beserta seberapa sering masing-masing berjalan

Petunjuk: Nomor 3 dan 4 adalah inti latihan ini. Kesenjangan antara cara pengguna bertanya dan cara dokumen ditulis adalah penyebab kegagalan RAG yang paling sering, dan paling mudah diramalkan sejak awal — asal kamu benar-benar menuliskan pertanyaannya alih-alih membayangkannya.

Ikhtisar

• RAG mengirim potongan yang relevan, bukan seluruh dokumen — menyelesaikan masalah muat, biaya, dan ketepatan sekaligus.
• Dua tahap yang berjalan pada waktu berbeda: ingest (batch, saat dokumen berubah) dan query (setiap pertanyaan). Jangan dicampur.
• Lima langkah: dokumen → chunking → embedding → penyimpanan → retrieval.
• Embedding memberi teks koordinat dalam ruang makna, sehingga teks yang bermakna serupa berdekatan meski tidak berbagi kata.
• Tool untuk data terstruktur dengan pengenal jelas; RAG untuk jawaban yang tersebar dalam prosa. Keduanya lazim dipakai bersamaan.
• Tiga kegagalan desain: potongan salah ukuran, potongan benar tidak ditemukan, dan potongan ditemukan tapi diabaikan model. Yang ketiga dicegah lewat instruksi yang tegas.

Lanjut ke mana

Sekarang bagian yang paling menentukan mutu RAG-mu — memotong dokumen dan mengubahnya menjadi vektor: 5.2 Chunking & Embedding.