RAG 2020: Cara Mengasih Model Bahasa Sumber Jawaban

Model bahasa tidak menyimpan ensiklopedia di kepalanya. Ia menyimpan pola — pola mana kata yang biasanya mengikuti kata lain. Itu membuatnya pandai berbicara, tapi tidak membuatnya pintar fakta. Pertanyaan "siapa presiden Indonesia pada 1967" dijawab dengan cara yang sama seperti menulis puisi: menebak kata berikutnya yang paling mungkin.

Retrieval-Augmented Generation, atau RAG, mengatasi itu dengan cara yang jujur. Alih-alih memaksa model menghafal semua fakta, RAG mengizinkan model mencarinya dulu. Kata "retrieval" berarti mengambil kembali. Sumbernya bisa berupa dokumen, database, atau seluruh situs web. Model menerima potongan yang relevan, membacanya, lalu menjawab.

2020: Makalah yang Mengubah Cara Model Dipakai

Pada 2020, Patrick Lewis dan timnya di Facebook AI menerbitkan makalah "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks". Ide di dalamnya sederhana: pisahkan antara pengetahuan yang ada di dalam model (parametric knowledge) dan pengetahuan yang ada di luar (non-parametric knowledge).

Parametric knowledge adalah apa yang sudah dipelajari model selama pelatihan. Ia tersimpan di dalam bobot jaringan. Non-parametric knowledge adalah dokumen yang bisa diakses kapan saja, diperbarui kapan saja, tanpa perlu melatih ulang model. RAG menggabungkan keduanya.

Makalah itu juga memperkenalkan dua varian: RAG-Sequence dan RAG-Token. RAG-Sequence mengambil satu dokumen dan menghasilkan seluruh jawaban. RAG-Token mengambil beberapa dokumen dan menghasilkan jawaban token demi token, dengan bobot yang berbeda untuk tiap dokumen.

Chunking: Memotong Jadi Potongan

Langkah pertama RAG adalah memotong dokumen menjadi potongan yang lebih kecil, atau "chunks". Dokumen yang terlalu panjang tidak bisa dipakai langsung. Model embedding punya batas token, dan potongan yang terlalu besar menurunkan kualitas pencarian.

Sebuah artikel 3.000 kata mungkin dipotong jadi 15 potongan masing-masing 200 kata. Ukuran potongan yang umum dipakai adalah antara 200 dan 500 token. Terlalu kecil, potongan kehilangan konteks. Terlalu besar, pencarian menjadi kurang tepat.

Embedding: Mengubah Teks Jadi Angka

Setiap potongan dikonversi menjadi vektor — daftar angka yang merepresentasikan maknanya. Model embedding dilatih supaya teks yang mirip maknanya punya vektor yang mirip jaraknya. "Presiden Soeharto" dan "pemimpin Indonesia 1967" akan punya vektor yang dekat, meskipun katanya berbeda.

Vektor ini disimpan di vector database, tempat yang dioptimalkan untuk mencari vektor yang paling dekat dengan vektor pertanyaan. Pencarian ini bukan pencarian kata kunci biasa. Ia mencari makna, bukan huruf.

Retrieval dan Reranking: Mencari yang Paling Relevan

Ketika pertanyaan masuk, pertanyaan itu juga diubah jadi vektor. Vector database mencari potongan yang vektornya paling dekat. Biasanya diambil lima sampai sepuluh potongan teratas.

Tapi sepuluh potongan teratas tidak selalu yang paling berguna. Kadang potongan yang relevan berada di urutan kedelapan karena vektornya sedikit lebih jauh. Itulah sebabnya banyak sistem RAG menambah tahap reranking — model kedua yang menilai ulang mana potongan yang benar-benar menjawab pertanyaan.

Analisis: RAG Mengurangi Halusinasi, Tidak Menghapusnya

Keunggulan utama RAG adalah model punya sumber yang bisa diperiksa. Kalau pertanyaan tentang fakta tertentu, model bisa mengutip potongan yang relevan. Kalau potongan itu tidak ada, model bisa menjawab "saya tidak menemukan informasi itu".

Tapi RAG bukan jaminan. Ada tiga cara RAG tetap bisa gagal. Pertama, dokumennya tidak ada atau tidak relevan. Kedua, ada dokumen yang relevan tapi tidak masuk ke potongan yang diambil. Ketiga, model membaca dokumen dengan salah, atau mengabaikannya sama sekali.

Yang ketiga adalah yang paling umum terjadi dan paling berbahaya. Model menerima dokumen yang berisi jawaban, tapi jawaban itu terkubur di tengah paragraf panjang. Model membaca sekilas, melewatkannya, dan menjawab dari pengetahuan parametriknya sendiri. Pengguna melihat jawaban yakin yang terdengar masuk akal, dan tidak punya cara untuk tahu bahwa jawaban itu tidak berpijak pada dokumen sama sekali.

Itulah sebabnya reranking penting. Tahap reranking yang baik tidak hanya menilai relevansi. Ia memeriksa apakah potongan benar-benar berisi informasi yang bisa menjawab pertanyaan. Sebuah potongan yang menyebut topik tapi tidak menjawab pertanyaan lebih buruk dari tidak berguna — ia memberi model izin untuk berlagak tahu.

Dua kegagalan pertama adalah masalah teknis. Keduanya bisa diperbaiki dengan chunking yang lebih baik, embedding yang lebih baik, dan reranking yang lebih baik. Kegagalan ketiga adalah masalah model. Ia membaik dengan model yang lebih besar dan pelatihan yang lebih baik, tapi tidak pernah hilang sepenuhnya. Itulah batas jujur dari RAG.

Kenapa RAG Lebih Murah dari Fine-Tuning

Fine-tuning melatih ulang model dengan data baru. Itu mahal, butuh GPU berjam-jam, dan setiap kali data berubah, proses harus diulang. RAG tidak menyentuh model sama sekali. Datanya tinggal di vector database, dan diperbarui kapan saja.

Perbandingannya seperti ini: fine-tuning adalah melatih karyawan baru, RAG adalah memberi karyawan buku panduan. Kalau buku panduannya berubah, tinggal ganti bukunya. Tidak perlu melatih ulang karyawannya.

Untuk tim kecil di Indonesia, perbedaan ini signifikan. Satu server dengan 16 GB RAM bisa menjalankan vector database untuk jutaan dokumen. GPU untuk fine-tuning model besar harganya bisa ratusan juta rupiah.

Batas yang Jujur

RAG bukan solusi ajaib. Ia menambah latensi karena ada tahap pencarian tambahan. Ia menambah biaya karena vector database butuh penyimpanan dan memori. Dan ia tidak menjamin model tidak mengarang — ia hanya memberinya kesempatan untuk tidak mengarang.

Pertanyaan yang paling sering muncul adalah: kalau model sudah besar, apakah RAG masih perlu? Jawabannya: ya. Karena ukuran model tidak menentukan apakah model tahu fakta terbaru. Model yang dilatih sampai 2024 tidak tahu apa yang terjadi pada 2026, seberapa pun besar ukurannya.

RAG 2020, sejak awal, adalah pengakuan bahwa model bahasa itu bukan ensiklopedia. Ia adalah penerjemah yang sangat pintar. Ia butuh sumber, dan RAG adalah cara memberikannya.

Contoh Nyata: RAG di Indonesia

Bayangkan sebuah perusahaan di Jakarta punya 500 halaman dokumen internal — kontrak, prosedur, dan laporan. Karyawan baru sering bertanya tentang prosedur tertentu. Tanpa RAG, mereka harus membaca semua dokumen atau bertanya ke senior.

Dengan RAG, dokumen-dokumen itu diubah jadi vektor dan disimpan. Ketika karyawan bertanya "bagaimana prosedur reimburse perjalanan dinas?", sistem mencari potongan yang relevan, memasukkannya ke konteks, dan model menjawab dengan mengutip dokumen itu.

Ini bukan contoh hipotetis. Banyak perusahaan di Indonesia sudah memakai RAG untuk dukungan pelanggan, pencarian dokumen internal, dan asisten virtual. Teknologinya matang, harganya terjangkau, dan hasilnya terukur.

Tabel Perbandingan: RAG vs Fine-Tuning

Tabel ini menunjukkan bahwa RAG dan fine-tuning bukan pilihan yang saling menggantikan. Keduanya bisa dipakai bersama. RAG untuk fakta, fine-tuning untuk gaya. Banyak sistem produksi memakai keduanya sekaligus.

Implementasi Praktis: dari Nol ke Sistem yang Jalan

Membangun sistem RAG dari nol tidak serumit yang dibayangkan. Komponen-komponennya sudah tersedia sebagai perangkat lunak bebas. Langkah pertama adalah memilih vector database. Pilihan yang umum termasuk Chroma, Qdrant, dan FAISS. Ketiganya bisa dijalankan di satu server tanpa GPU.

Langkah kedua adalah memilih model embedding. Untuk bahasa Indonesia, model multilingual seperti multilingual-e5-base bekerja cukup baik. Untuk hasil yang lebih baik, model yang dilatih khusus untuk bahasa Indonesia bisa dipakai. Ukuran model embedding umumnya kecil, di bawah 1 GB.

Langkah ketiga adalah membuat pipeline. Dokumen masuk, dipotong jadi chunks, diubah jadi vektor, disimpan. Ketika pertanyaan masuk, cari vektor terdekat, ambil potongan, masukkan ke konteks, dan model menjawab. Pipeline ini bisa dibangun dengan Python murni dalam beberapa ratus baris kode.

Tantangan sebenarnya bukan pada tekniknya, tapi pada datanya. Dokumen yang berantakan menghasilkan vektor yang berantakan. Dokumen yang tidak terstruktur sulit dipotong dengan benar. Itulah sebabnya persiapan data sering memakan waktu lebih lama daripada membangun sistemnya.

Masa Depan RAG

RAG terus berkembang. Versi yang lebih baru menambahkan kemampuan untuk mencari di beberapa sumber sekaligus, menggabungkan hasil dari vector database dan pencarian kata kunci biasa, dan bahkan meminta model untuk mencari lagi kalau hasil pertama tidak memuaskan.

Ada juga pendekatan yang disebut "agentic RAG", di mana model tidak hanya mengambil dokumen, tapi juga memutuskan apa yang harus dicari, bagaimana mencarinya, dan apakah hasilnya cukup. Ini membawa RAG lebih dekat ke cara manusia mencari informasi: mencoba, mengevaluasi, mencoba lagi.

Yang tidak berubah adalah ide intinya. Model bahasa tetap bukan ensiklopedia. Ia tetap butuh sumber. Dan RAG tetap cara paling praktis untuk memberikannya.

Kenapa Ini Penting untuk Pengguna di Indonesia

Bagi pengguna API di Indonesia, RAG bisa mengurangi biaya secara signifikan. Daripada mengirim dokumen panjang setiap kali bertanya, sistem RAG mengirim hanya potongan yang relevan. Itu berarti lebih sedikit token yang diproses, dan tagihan yang lebih rendah.

Bagi pengembang di Indonesia, RAG membuka kemungkinan untuk membangun aplikasi AI yang terhubung ke data lokal — dokumen perusahaan, peraturan pemerintah, atau konten edukasi — tanpa harus melatih model dari nol. Itu bukan kemewahan lagi, tapi kebutuhan praktis.

Dan bagi yang baru mulai, ada pelajaran paling sederhana: jangan bangun sistem RAG kalau datanya belum siap. Persiapan data adalah bagian yang paling memakan waktu, paling membosankan, dan paling menentukan keberhasilan. Tekniknya bisa dipelajari dalam seminggu. Datanya bisa butuh berbulan-bulan.