RAG — Retrieval Augmented Generation: Mengapa LLM Butuh Buku Referensi Sebelum Menjawab

Beberapa bulan lalu, aku sempat bangga punya AI Assistant lokal yang bisa menjawab pertanyaan sehari-hari. Tanya soal Nginx, ia jawab. Tanya soal Python, ia jawab. Tanya soal resep masakan, ia juga jawab. Tapi lama-kelamaan aku sadar ada satu masalah yang mengganggu: jawabannya terkadang terlalu umum, kadang ketinggalan tahun, atau bahkan membuat fakta yang sebenarnya tidak pernah aku berikan. LLM itu seperti teman yang sangat lancar berbicara, hafal banyak pola, tapi tidak selalu membawa buku referensi yang tepat. Di sinilah aku mulai belajar soal Retrieval Augmented Generation, atau yang sering disingkat RAG.

LLM Tanpa RAG: Seperti Teman yang Hapal Tapi Tidak Punya Catatan

Coba bayangkan kamu sedang ujian. Ada dua teman yang duduk di sebelahmu. Teman pertama sangat cerdas dan hapal banyak hal, tapi ia hanya mengandalkan ingatan. Teman kedua tidak seenak pertama, tapi ia punya buku catatan rapi yang berisi materi dari kelas, slide dosen, dan rangkuman pribadi. Saat pertanyaan ujian keluar, teman pertama bisa menjawab cepat, tapi kadang salah detail. Teman kedua menjawab lebih lambat sedikit, tapi lebih presisi karena ia mencocokkan pertanyaan dengan catatannya dulu.

LLM tanpa RAG itu seperti teman pertama. Ia dilatih dari miliaran teks di internet, jadi pengetahuannya luas tapi statis. Ia tidak tahu dokumen terbarumu, catatan pribadimu, atau konfigurasi servermu. RAG mengubahnya jadi teman kedua: sebelum menjawab, ia mencari dulu sumber yang relevan dari basis data pribadimu, lalu menjawab berdasarkan sumber itu.

Apa Itu RAG?

RAG adalah pola arsitektur AI yang menggabungkan dua hal: retrieval (pencarian informasi) dan generation (pembuatan teks). Secara sederhana, alurnya seperti ini:

1. Pengguna mengajukan pertanyaan.
2. Sistem mencari dokumen atau potongan teks yang paling relevan dari basis data yang sudah kita siapkan.
3. Dokumen relevan itu disisipkan ke dalam prompt LLM sebagai konteks.
4. LLM menjawab pertanyaan berdasarkan konteks tersebut.

Dengan cara ini, jawaban LLM tidak lagi hanya murni dari ingatannya sendiri. Ia sekarang punya "buku referensi" yang bisa dibuka sebelum berbicara.

Tiga Komponen Utama RAG

Implementasi RAG biasanya terdiri dari tiga komponen utama. Masing-masing punya peran yang berbeda, tapi saling menopang.

1. Dokumen Sumber

Ini bisa berupa file PDF, catatan Markdown, halaman dokumentasi, log server, atau bahkan artikel blog sendiri. Semakin berkualitas dan terstruktur dokumenmu, semakin baik hasil RAG. Sampah masuk, sampah keluar — pepatah itu berlaku juga di sini.

2. Vector Database

Vector database menyimpan representasi numerik dari teks, yang disebut embedding. Bayangkan setiap kalimat diubah menjadi sekumpulan angka yang menangkap maknanya. Saat pengguna bertanya, pertanyaan itu juga diubah jadi angka-angka serupa. Sistem lalu mencari dokumen yang angkanya paling dekat dengan pertanyaan. Contoh populer: ChromaDB, Qdrant, Milvus, dan Weaviate.

3. LLM sebagai Generator

Setelah dokumen relevan ditemukan, LLM-lah yang menyusun jawaban manusiawi. Kamu bisa pakai model lokal seperti Qwen atau Llama melalui Ollama, atau pakai API seperti Gemini dan OpenAI. Bagusnya, RAG membuat LLM kecil pun bisa jadi lebih berguna karena ia tidak perlu hafal segalanya — cukup pintar membaca konteks.

Implementasi Sederhana dengan Python dan ChromaDB

Untuk memahami RAG, aku lebih suka langsung lihat contoh kecil. Berikut ini adalah skrip Python sederhana yang membaca beberapa kalimat, menyimpannya ke ChromaDB, lalu menjawab pertanyaan berdasarkan data tersebut.

# install dulu: pip install chromadb sentence-transformers
import chromadb
from chromadb.utils.embedding_functions import SentenceTransformerEmbeddingFunction

# 1. Siapkan dokumen sumber
 documents = [
    "Nginx adalah web server yang populer dan ringan.",
    "Docker memungkinkan aplikasi berjalan dalam container yang terisolasi.",
    "RAG membantu LLM menjawab berdasarkan data pribadi pengguna.",
    "fail2ban melindungi server dari brute-force attack dengan memblokir IP."
]

# 2. Buat koleksi di ChromaDB
client = chromadb.Client()
ef = SentenceTransformerEmbeddingFunction(model_name="all-MiniLM-L6-v2")
collection = client.create_collection(name="catatan-server", embedding_function=ef)

# 3. Masukkan dokumen
collection.add(documents=documents, ids=["d1", "d2", "d3", "d4"])

# 4. Tanya dan ambil konteks relevan
query = "Cara melindungi server dari serangan password?"
results = collection.query(query_texts=[query], n_results=2)
context = "\n".join(results["documents"][0])

print("Konteks yang ditemukan:")
print(context)

Kalau skrip di atas dijalankan, ChromaDB akan mengembalikan dokumen yang paling relevan dengan pertanyaan. Dokumen tentang fail2ban dan Docker kemungkinan besar muncul, karena keduanya berkaitan dengan keamanan server. Hasil pencarian itu nantinya bisa disusun jadi prompt seperti ini untuk LLM:

Kamu adalah asisten teknis. Jawab pertanyaan berikut berdasarkan konteks di bawah.

Konteks:
- fail2ban melindungi server dari brute-force attack dengan memblokir IP.
- Docker memungkinkan aplikasi berjalan dalam container yang terisolasi.

Pertanyaan: Cara melindungi server dari serangan password?

LLM akan menjawab dengan lebih fokus, karena ia punya konteks yang spesifik. Ia tidak lagi menebak-menebak atau memberikan jawaban umum dari pengetahuan lamanya.

Kapan RAG Benar-Benar Dibutuhkan?

RAG bukan solusi untuk segala masalah. Ada situasi di mana RAG sangat berguna, dan ada situasi di mana ia malah membuat sistem jadi lebih rumit tanpa manfaat yang jelas.

RAG cocok dipakai ketika kamu punya data pribadi yang tidak bisa diberikan ke LLM secara langsung, seperti catatan server, dokumen internal, atau arsip blog. RAG juga berguna ketika kamu ingin jawaban LLM selalu mengacu pada sumber tertentu, misalnya dokumentasi resmi produk yang kamu kembangkan. Selain itu, RAG membantu mengurangi hallucination, yaitu kecenderungan LLM membuat jawaban yang terdengar meyakinkan tapi salah.

Namun RAG tidak terlalu dibutuhkan jika pertanyaan pengguna bersifat umum dan tidak membutuhkan data spesifik. Tanya soal sejarah dunia atau tips menulis, LLM tanpa RAG sudah cukup. Tanya soal konfigurasi server yang baru kamu ubah minggu lalu, baru RAG jadi penting.

Keterbatasan yang Perlu Diingat

RAG terdengar sempurna, tapi sebenarnya punya batasan. Pertama, kualitas jawaban sangat bergantung pada kualitas dokumen sumber. Kalau dokumennya berantakan, hasil pencarian juga akan berantakan. Kedua, RAG tidak selalu menemukan konteks yang paling tepat, terutama kalau pertanyaan diungkapkan dengan kata kunci yang berbeda dari isi dokumen. Ketiga, RAG menambah kompleksitas: kamu perlu memikirkan cara memotong dokumen, menyimpan embedding, mengupdate data, dan mengelola vector database.

Jadi RAG itu seperti membangun perpustakaan pribadi. Bukan cukup sekadar punya rak buku, tapi juga harus punya sistem katalog yang rapi, petugas yang tahu di mana letak bukunya, dan kebiasaan merapikan kembali setelah dipakai.

Kesimpulan

RAG membuka cara baru untuk memanfaatkan LLM: dari sekadar mesin yang hafal pola, menjadi asisten yang bisa membaca dan merujuk pada data kita sendiri. Bagi aku yang punya home server dan banyak catatan konfigurasi, RAG seperti memberikan AI Assistant itu sebuah buku referensi pribadi. Ia tidak perlu tahu segalanya, asalkan tahu di mana harus mencari.

Kalau kamu sudah punya LLM lokal atau asisten AI sendiri, mencoba RAG adalah langkah berikutnya yang cukup menyenangkan. Mulai dari dokumen kecil, satu koleksi, satu pertanyaan. Lama-lama, kamu akan punya perpustakaan digital yang bisa diajak ngobrol.