Fase 5 · RAG — Retrieval Augmented Generation

Apa itu RAG & pipeline dasarnya

Menyuruh model menjawab pertanyaan tentang kebijakan cuti perusahaanmu tidak akan berhasil — model tidak pernah melihat dokumen itu saat training. RAG menyelesaikan ini dengan mencari dulu, baru menjawab.

Sumber asli aws.amazon.com Resmi Rangkuman ~8 menit baca

Intisari

RAG (Retrieval Augmented Generation): sebelum model menjawab, sistem mencari potongan dokumen relevan dulu, lalu menyisipkannya ke prompt sebagai konteks tambahan.
Menyelesaikan dua batasan LLM sekaligus: knowledge cutoff (model tidak tahu data terbaru/internal) dan context window terbatas (tidak mungkin memasukkan seluruh basis pengetahuan ke setiap prompt).
Pipeline dasarnya empat langkah: ingest (pecah dokumen jadi potongan/chunk) → embed (ubah tiap chunk jadi vektor, Fase 4) → retrieve (cari chunk paling relevan dengan pertanyaan) → generate (model menjawab berdasarkan chunk yang ditemukan).
RAG berbeda dari fine-tuning: RAG menambah konteks saat request (murah, cepat diperbarui), fine-tuning mengubah bobot model itu sendiri (mahal, butuh retraining tiap kali data berubah).
Kualitas jawaban RAG dibatasi oleh kualitas retrieval — kalau chunk yang diambil tidak relevan, model akan menjawab berdasarkan konteks yang salah atau mengarang (dibahas lanjut di dua materi berikutnya).

Masalah yang dipecahkan RAG

Ingat dari Fase 0: model dilatih sekali, pada data sampai tanggal tertentu (knowledge cutoff), dan tidak tahu apa pun di luar itu — termasuk dokumen internal perusahaanmu yang jelas tidak pernah jadi bagian data latihan publik. Menempelkan seluruh basis pengetahuan ke setiap prompt juga tidak praktis: context window ada batasnya, dan mengirim jutaan token di setiap request akan sangat mahal & lambat (Fase 7).

RAG (Retrieval Augmented Generation) menjawab ini dengan pola sederhana: alih-alih menyuruh model "tahu semuanya", sistem mencari dulu potongan informasi yang relevan dengan pertanyaan saat itu, lalu menyisipkan hanya potongan itu ke prompt sebagai konteks.

Pipeline: empat langkah

┌─────────────┐   ┌──────────┐   ┌───────────┐   ┌──────────┐
│ 1. INGEST   │ → │ 2. EMBED │ → │ (disimpan │   │          │
│ pecah dok-  │   │ tiap     │   │  di vector│   │          │
│ umen jadi   │   │ chunk    │   │  database)│   │          │
│ chunk kecil │   │ jd vektor│   │           │   │          │
└─────────────┘   └──────────┘   └───────────┘   │          │
                                                    ▼          │
Saat pengguna bertanya:                    ┌───────────────┐  │
                                            │ 3. RETRIEVE   │  │
                                            │ cari chunk    │  │
                                            │ paling mirip  │  │
                                            │ dgn pertanyaan│  │
                                            └───────┬───────┘  │
                                                     ▼          │
                                            ┌───────────────┐  │
                                            │ 4. GENERATE   │  │
                                            │ model jawab   │◄─┘
                                            │ pakai chunk   │
                                            │ yg ditemukan  │
                                            └───────────────┘

Langkah 1-2 (ingest & embed) dilakukan sekali di awal (atau tiap kali dokumen berubah). Langkah 3-4 (retrieve & generate) terjadi setiap kali ada pertanyaan baru.

# Langkah 1-2: dilakukan sekali (atau tiap dokumen baru masuk)
def ingest_dokumen(path: str):
    teks = open(path).read()
    chunks = pecah_jadi_chunk(teks, ukuran=500)  # detail chunking di materi berikutnya
    for chunk in chunks:
        vektor = embed(chunk)  # dari Fase 4
        simpan_ke_db(chunk, vektor)

# Langkah 3-4: terjadi setiap ada pertanyaan
def jawab_dengan_rag(pertanyaan: str) -> str:
    vektor_pertanyaan = embed(pertanyaan)
    chunks_relevan = cari_dokumen_mirip(vektor_pertanyaan, k=3)  # dari Fase 4 (pgvector)

    konteks = "\n\n".join(c["isi"] for c in chunks_relevan)
    prompt = f"""Jawab pertanyaan HANYA berdasarkan konteks berikut. Kalau jawabannya tidak ada
di konteks, katakan tidak tahu — jangan mengarang.

<konteks>
{konteks}
</konteks>

Pertanyaan: {pertanyaan}"""

    return client.messages.create(
        model="claude-sonnet-4-5", max_tokens=1024,
        messages=[{"role": "user", "content": prompt}],
    ).content[0].text

Instruksi "jangan mengarang" di atas bukan jaminan mutlak — ia mengurangi kecenderungan halusinasi (Fase 0), bukan menghapusnya. Bagian terpenting dari kualitas RAG justru ada di langkah 3 (retrieve): kalau chunk yang diambil memang tidak relevan atau tidak lengkap, model tetap bisa menjawab meyakinkan berdasarkan informasi yang salah. Ini dibahas lanjut di materi kedua fase ini.

RAG vs fine-tuning

	RAG	Fine-tuning
Cara kerja	Menambah konteks di prompt saat request	Melatih ulang sebagian bobot model dengan data baru
Update data baru	Cepat — tinggal ingest dokumen baru	Lambat & mahal — butuh proses training ulang
Sumber jawaban bisa dilacak	Ya — tahu persis chunk mana yang dipakai	Tidak — pengetahuan "melebur" ke bobot model
Cocok untuk	Pengetahuan faktual yang sering berubah/spesifik (dokumen internal, knowledge base)	Mengubah gaya/format respons, atau menanamkan pola yang sangat konsisten

Untuk hampir semua kasus AI engineer sehari-hari, RAG adalah pilihan pertama — jauh lebih murah, lebih cepat diiterasi, dan hasilnya bisa dilacak sumbernya. Fine-tuning adalah alat khusus untuk kasus yang benar-benar butuh mengubah perilaku dasar model, bukan sekadar memberinya informasi baru.

Latihan: ambil 3 paragraf dokumen fiktif (mis. kebijakan cuti kantor karanganmu sendiri), jalankan pipeline ingest_dokumen lalu jawab_dengan_rag dengan pertanyaan yang jawabannya ADA di dokumen, dan satu pertanyaan yang jawabannya TIDAK ada. Periksa apakah model menjawab "tidak tahu" untuk yang kedua, bukan mengarang.

Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.