RAG Dijelaskan dari Awal

Setiap kali saya mengobrol dengan developer lain yang baru mulai mengintegrasikan LLM ke aplikasinya, hampir selalu muncul pertanyaan yang sama: kenapa jawaban model kadang ngawur padahal modelnya sudah state of the art? Jawabannya hampir selalu sama juga — modelnya tidak salah, dia cuma tidak tahu. LLM dilatih pada data sampai titik waktu tertentu, dan dia tidak tahu apa-apa soal data internal organisasi Anda, dokumen yang baru diunggah kemarin, atau fakta yang berubah setelah masa training-nya selesai. Di sinilah retrieval-augmented generation (RAG) masuk, dan menurut saya ini salah satu konsep paling penting yang wajib dipahami siapa pun yang membangun produk berbasis AI hari ini.

Kenapa LLM butuh konteks eksternal

Bayangkan LLM sebagai seseorang yang sangat pintar, sudah membaca jutaan buku, tapi terkunci di ruangan tanpa akses internet dan tanpa tahu apa yang terjadi setelah hari terakhir dia membaca. Kalau Anda tanya soal konsep umum, dia jago. Tapi kalau Anda tanya "berapa stok obat X di gudang kita minggu ini?" atau "apa isi SOP terbaru rumah sakit kami soal triase?", dia tidak punya cara untuk tahu — kecuali dia mulai menebak, alias berhalusinasi.

Masalah ini punya dua sumber. Pertama, pengetahuan model itu statis — dibekukan sejak masa training, jadi apa pun yang terjadi setelahnya tidak dia ketahui. Kedua, pengetahuan model itu umum — dia dilatih dari data publik berskala besar, bukan dokumen internal, database, atau catatan spesifik milik organisasi Anda. Fine-tuning bisa menjawab sebagian masalah kedua, tapi itu mahal, lambat untuk di-refresh, dan tetap tidak menyelesaikan masalah pertama karena data baru terus bertambah setiap hari.

RAG mengambil pendekatan yang jauh lebih praktis: daripada memaksa semua pengetahuan masuk ke dalam bobot model, kita beri model itu akses untuk "membaca" sumber data eksternal secara real-time, tepat sebelum dia menjawab. Model tetap sama, tapi konteks yang dia terima di setiap pertanyaan menjadi dinamis dan relevan.

Bagaimana mekanismenya bekerja

Alurnya, secara prinsip, sederhana. Ada tiga langkah inti yang selalu berulang:

  1. Index — dokumen sumber (SOP, artikel, catatan medis anonim, dokumentasi API, dll) dipecah jadi potongan-potongan kecil (chunk), lalu masing-masing diubah jadi representasi vektor lewat model embedding. Vektor ini disimpan di vector database.
  2. Retrieve — saat ada pertanyaan masuk, pertanyaan itu juga diubah jadi vektor dengan model embedding yang sama, lalu dicari potongan dokumen mana yang paling mirip secara makna (bukan sekadar cocok kata kunci).
  3. Augment & generate — potongan-potongan yang paling relevan itu disisipkan ke dalam prompt yang dikirim ke LLM, bersama pertanyaan aslinya. Model lalu menjawab berdasarkan konteks yang baru saja diberikan, bukan cuma mengandalkan ingatannya sendiri.

Ilustrasi sederhana potongan prompt yang dikirim ke model biasanya kurang lebih seperti ini:

Konteks:
- [potongan dokumen 1 yang relevan]
- [potongan dokumen 2 yang relevan]

Pertanyaan: {pertanyaan pengguna}

Jawab hanya berdasarkan konteks di atas. Jika konteks tidak cukup, katakan tidak tahu.

Instruksi terakhir itu penting — tanpa itu, model tetap punya kecenderungan mengarang jika konteks yang diberikan kurang lengkap. Bagian "retrieve" ini yang sering diremehkan orang yang baru belajar RAG: kualitas jawaban akhir sangat bergantung pada seberapa bagus proses pencarian menemukan potongan yang benar-benar relevan, bukan cuma mirip secara permukaan. Ukuran chunk yang terlalu besar bikin konteks boros dan kurang presisi, terlalu kecil bikin makna terpotong dan kehilangan konteks di sekitarnya — di sinilah biasanya eksperimen paling banyak dilakukan.

Kapan RAG cocok dipakai, dan kapan tidak

RAG paling masuk akal ketika data sumbernya berubah-ubah atau spesifik ke domain/organisasi, dan Anda butuh jawaban yang bisa ditelusuri sumbernya. Contoh umum: asisten yang menjawab berdasarkan dokumentasi internal, pencarian semantik di basis pengetahuan medis, atau chatbot yang menjawab dari kebijakan perusahaan yang sering diperbarui. Keunggulan lain yang jarang disebut: karena pengetahuan disimpan di luar model, Anda bisa memperbarui, menghapus, atau mengoreksi satu dokumen kapan saja tanpa perlu melatih ulang apa pun — cukup update index-nya.

Tapi RAG bukan solusi ajaib untuk semua masalah. Kalau kebutuhan Anda cuma soal gaya bahasa, format keluaran, atau perilaku model secara konsisten (misalnya selalu menjawab dalam format tertentu), itu ranahnya prompt engineering atau fine-tuning, bukan retrieval. RAG juga menambah kompleksitas operasional — ada vector database yang perlu dirawat, proses indexing yang perlu dijadwalkan ulang tiap kali dokumen sumber berubah, dan latensi tambahan karena ada langkah pencarian sebelum model mulai menjawab. Untuk kasus yang datanya kecil dan jarang berubah, kadang menaruh semuanya langsung di prompt (tanpa retrieval sama sekali) justru lebih sederhana dan cukup.

Satu hal lagi yang sering saya tekankan ke tim: RAG mengurangi halusinasi, tapi tidak menghilangkannya sepenuhnya. Model tetap bisa salah menafsirkan konteks yang diberikan, atau retrieval-nya bisa saja mengambil potongan yang kurang tepat. Evaluasi terhadap kualitas retrieval dan kualitas jawaban akhir tetap perlu dilakukan terus-menerus, bukan sekali di awal lalu dianggap selesai.

Takeaway

Inti dari RAG sebenarnya sederhana: jangan paksa semua pengetahuan masuk ke dalam model, cukup beri model akses untuk mencari dan membaca sumber yang tepat sebelum dia menjawab. Kalau Anda sedang membangun sesuatu yang butuh jawaban akurat dari data yang spesifik dan sering berubah, RAG biasanya jadi titik awal yang jauh lebih murah dan lebih terkontrol dibanding fine-tuning. Mulai dari yang paling sederhana — index dokumen, retrieval berbasis kemiripan makna, lalu sisipkan ke prompt — baru optimalkan bagian retrieval-nya begitu Anda mulai melihat pola pertanyaan yang tidak terjawab dengan baik.