RAG vs Context Window Jutaan Token: Kapan Butuh Pipeline, Kapan Cukup Lempar Semua Dokumen?

Dulu jawabannya gampang: model hanya kuat membaca beberapa halaman, jadi kalau mau AI menjawab dari dokumen banyak, kamu wajib membangun pipeline RAG — sistem yang memotong dokumen, menyimpannya di database vektor, lalu mengambil potongan relevan untuk tiap pertanyaan. Sekarang model berkonteks ratusan ribu hingga jutaan token mengubah hitungannya: untuk banyak kasus, kamu bisa melempar seluruh dokumen mentah-mentah ke model dan selesai.

Lalu apakah RAG sudah mati? Belum — tapi wilayah kekuasaannya menyempit. Pertanyaan yang tepat bukan 'mana yang lebih canggih', melainkan 'untuk kasus saya, mana yang lebih sederhana dan lebih murah'. Mari kita bedah.

Kapan konteks panjang saja sudah cukup

Kalau total dokumenmu muat di context window dan pertanyaannya tidak terlalu sering, lempar saja semuanya. Menelaah satu kontrak panjang, membandingkan beberapa peraturan, merangkum laporan tahunan — untuk pekerjaan begini, membangun pipeline RAG itu seperti membangun gudang untuk menyimpan tiga kardus. Konteks panjang juga unggul saat jawabannya butuh pemahaman lintas-dokumen yang utuh: model melihat semuanya sekaligus, bukan potongan-potongan yang diambil sistem pencari.

Pola pemakaian saya sehari-hari sebagai ASN justru hampir semuanya kategori ini: dokumen kerja datang per kasus, ditelaah, selesai. Tidak ada alasan merawat database vektor untuk itu.

Kapan RAG tetap tak tergantikan

Pertama, skala: kalau korpusmu ribuan dokumen — arsip peraturan satu instansi, basis pengetahuan layanan pelanggan, dokumentasi produk bertahun-tahun — tidak ada context window yang muat, dan RAG kembali jadi satu-satunya jalan. Kedua, frekuensi: chatbot yang menjawab ratusan pertanyaan sehari dari basis pengetahuan yang sama akan jauh lebih hemat mengambil potongan kecil yang relevan ketimbang membayar pembacaan seluruh korpus berulang-ulang.

Di sinilah implikasi biaya yang sering dilupakan: kamu membayar per token yang dibaca model, dan membaca dokumen raksasa untuk tiap pertanyaan kecil itu seperti menyewa truk kontainer untuk antar satu paket. Fitur prompt caching memang memangkas biaya pembacaan berulang secara signifikan, tapi tidak menghilangkan logika dasarnya. Untuk dompet Indonesia — apalagi UMKM yang menimbang tiap rupiah tagihan API — selisihnya terasa.

Rumus praktis saya: mulai dari yang paling sederhana, yaitu lempar dokumen ke model berkonteks panjang. Baru bangun RAG kalau (a) dokumen tidak muat, (b) volume pertanyaan tinggi dan tagihan mulai sakit, atau (c) korpus terus bertambah dan butuh diperbarui tanpa menyentuh ulang semuanya. RAG itu jawaban untuk masalah skala — jangan mengadopsi masalah skala sebelum kamu memilikinya.