Apa Itu Retrieval-Augmented Generation (RAG)? Cara Kerja, Manfaat, dan Contohnya

Large Language Model atau LLM dapat menghasilkan jawaban yang terlihat meyakinkan. Namun, model tidak selalu mempunyai informasi terbaru, memahami data internal organisasi, atau menunjukkan sumber yang mendukung jawabannya.

Ketika informasi yang dibutuhkan tidak tersedia dalam data pelatihan, model berisiko menggunakan pengetahuan lama atau menghasilkan detail yang tidak didukung sumber. Kondisi tersebut merupakan salah satu bentuk halusinasi AI atau hallucination.

Retrieval-Augmented Generation atau RAG menjadi salah satu pendekatan untuk mengatasi keterbatasan tersebut. RAG menghubungkan LLM dengan sumber eksternal, seperti dokumen, database, basis pengetahuan, indeks pencarian, atau API. Sebelum menjawab, sistem mencari informasi yang relevan dan memberikannya sebagai konteks kepada model.

Meskipun demikian, RAG tidak otomatis membuat setiap jawaban menjadi benar. Kualitasnya tetap bergantung pada sumber data, strategi pencarian, penyusunan konteks, prompt, keamanan, dan evaluasi sistem.

Apa Itu Retrieval-Augmented Generation?

Retrieval-Augmented Generation perlu dipahami sebagai sebuah pola arsitektur, bukan sebagai satu model atau produk tertentu. Sistem ini menambahkan proses pencarian informasi sebelum LLM menghasilkan jawaban.

Retrieval-Augmented Generation atau RAG adalah metode yang membuat Large Language Model mencari informasi dari sumber eksternal sebelum menghasilkan jawaban. Informasi tersebut dapat berasal dari dokumen, database, basis pengetahuan, indeks pencarian, atau API yang terhubung dengan aplikasi.

Secara teknis, RAG menggabungkan proses retrieval atau pengambilan informasi dengan generation atau pembuatan jawaban oleh model bahasa. Istilah tersebut diperkenalkan secara luas melalui paper Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks yang diterbitkan oleh Patrick Lewis dan rekan-rekannya pada 2020.

Penelitian tersebut menggabungkan pengetahuan yang tersimpan di dalam parameter model dengan memori eksternal berupa indeks dokumen yang dapat dicari. Konsep ini memungkinkan model menggunakan informasi di luar data pelatihannya ketika menyelesaikan tugas yang membutuhkan pengetahuan faktual.

Pada LLM biasa, pengguna mengirim pertanyaan dan model langsung menghasilkan jawaban berdasarkan pola yang dipelajari selama pelatihan. Kemampuan ini merupakan bagian dari bidang Natural Language Processing atau pemrosesan bahasa alami.

Pada RAG, terdapat tahap tambahan. Sistem mencari dokumen yang berkaitan dengan pertanyaan, memilih bagian yang paling relevan, lalu memasukkannya ke dalam prompt sebelum meminta model menjawab.

Secara sederhana, alurnya adalah:

Pertanyaan pengguna → pencarian informasi → pemilihan konteks → LLM → jawaban

RAG tidak menyimpan seluruh dokumen secara permanen di dalam parameter model. Informasi biasanya dimasukkan melalui context window ketika diperlukan. Karena itu, basis pengetahuan dapat diperbarui tanpa harus melatih ulang LLM setiap kali terdapat perubahan informasi.

AWS menjelaskan RAG sebagai teknik untuk melengkapi LLM dengan data eksternal agar model mendapatkan konteks yang dibutuhkan untuk menghasilkan respons sesuai kebutuhan aplikasi.

Mengapa RAG Dibutuhkan?

Kemampuan model dalam menghasilkan bahasa tidak selalu sebanding dengan ketepatan fakta yang disampaikan. Dalam penggunaan nyata, aplikasi AI sering membutuhkan informasi yang bersifat privat, spesifik, atau terus berubah.

RAG menyediakan mekanisme agar informasi tersebut dapat diambil dari sumber yang ditentukan ketika pengguna mengajukan pertanyaan.

1. Mengakses Informasi di Luar Data Pelatihan

LLM dilatih menggunakan kumpulan data pada periode tertentu. Model tidak otomatis mengetahui dokumen baru, perubahan kebijakan, pembaruan produk, atau informasi yang dibuat setelah proses pelatihan selesai.

Melalui RAG, aplikasi dapat mengambil data dari sumber yang diperbarui. Sebagai contoh, chatbot dapat mencari dokumentasi terbaru sebelum menjelaskan prosedur penggunaan produk.

Ketika terdapat perubahan, tim cukup memperbarui dokumen dan indeks. Parameter utama LLM tidak harus diubah hanya untuk memperbarui satu fakta.

2. Menggunakan Data Internal

Model publik tidak otomatis memiliki akses ke SOP, dokumentasi proyek, tiket layanan pelanggan, kontrak, kebijakan perusahaan, atau panduan operasional internal.

RAG memungkinkan organisasi menghubungkan LLM dengan sumber tersebut. Aplikasi kemudian dapat menjawab berdasarkan informasi yang memang tersedia dan diizinkan untuk diakses.

Namun, proses retrieval tetap harus mengikuti hak akses pengguna. Dokumen keuangan, data pelanggan, atau informasi rahasia tidak boleh muncul hanya karena secara semantik berkaitan dengan pertanyaan.

3. Menyediakan Sumber yang Dapat Diperiksa

Jawaban LLM biasa tidak selalu menunjukkan asal informasi. Pada RAG, setiap potongan data dapat disimpan bersama metadata, seperti:

• Nama dokumen.
• Judul bagian.
• Nomor halaman.
• Versi.
• Tanggal berlaku.
• Pemilik dokumen.
• Sumber asli.
• Tingkat akses.

Metadata memungkinkan aplikasi menampilkan rujukan agar pengguna dapat memeriksa sumber jawaban.

Meskipun demikian, keberadaan kutipan tidak otomatis membuktikan bahwa seluruh jawaban benar. Dokumen yang ditampilkan harus benar-benar mendukung klaim yang dibuat model, bukan sekadar membahas topik serupa.

Bagaimana Cara Kerja RAG?

Cara kerja RAG dapat dibagi menjadi dua proses besar. Pertama, sistem menyiapkan sumber pengetahuan agar dapat dicari. Kedua, sistem mengambil informasi ketika pengguna mengirim pertanyaan.

Kesalahan pada tahap persiapan data dapat memengaruhi seluruh proses berikutnya. Karena itu, kualitas RAG tidak hanya ditentukan oleh model bahasa yang digunakan.

1. Mengumpulkan dan Memproses Data

Sumber data dapat berupa website, PDF, dokumen kantor, wiki internal, database, object storage, tiket dukungan, dokumentasi teknis, atau API.

Dokumen perlu melalui proses parsing dan pembersihan agar teks, heading, tabel, metadata, serta struktur lainnya dapat diproses secara konsisten.

Informasi duplikat, kedaluwarsa, atau saling bertentangan dapat membuat sistem mengambil konteks yang salah. Oleh sebab itu, setiap jenis informasi sebaiknya memiliki sumber kebenaran yang jelas.

Dokumentasi resmi dapat digunakan untuk prosedur. Sementara itu, data transaksional yang sering berubah, seperti stok, saldo, harga, dan status layanan, sebaiknya diambil langsung dari database atau API resmi.

2. Membagi Dokumen Menjadi Chunk

Dokumen panjang biasanya dibagi menjadi potongan lebih kecil yang disebut chunk. Tujuannya agar sistem tidak perlu mengirim seluruh dokumen kepada LLM ketika hanya satu bagian yang relevan.

Chunk yang terlalu kecil dapat kehilangan konteks. Sebaliknya, chunk yang terlalu besar dapat membawa banyak informasi tidak relevan, memenuhi context window, dan menambah penggunaan token.

Tidak ada satu ukuran chunk yang selalu cocok untuk semua jenis data. Strateginya dapat disesuaikan berdasarkan:

• Jumlah karakter atau token.
• Kalimat dan paragraf.
• Heading dan subheading.
• Struktur halaman.
• Jenis dokumen.
• Batas topik atau makna.

Dokumentasi produk dapat dibagi berdasarkan heading. Sementara itu, kontrak mungkin perlu dibagi berdasarkan pasal agar ketentuan utama dan pengecualiannya tidak terpisah.

Microsoft Azure Architecture Center menyarankan agar chunk idealnya mewakili satu gagasan atau konsep yang relevan secara semantik. Strategi tersebut tetap perlu diuji menggunakan dokumen dan pertanyaan yang mewakili penggunaan nyata.

3. Membuat Embedding

Setiap chunk dapat diubah menjadi embedding, yaitu representasi numerik dari teks. Pertanyaan pengguna juga dapat diubah menjadi embedding agar sistem membandingkan kedekatan makna antara pertanyaan dan dokumen.

Embedding membantu sistem menemukan informasi yang relevan meskipun kata yang digunakan tidak sama persis.

Sebagai contoh, pertanyaan “mengapa pengguna tidak dapat masuk?” dapat dianggap berkaitan dengan dokumen yang menggunakan istilah “masalah autentikasi akun”, meskipun susunan katanya berbeda.

Embedding kemudian dapat disimpan dalam vector database. Namun, teks asli dan metadata tetap perlu dipertahankan agar hasil pencarian dapat dibaca, difilter, dan ditelusuri kembali.

4. Menyimpan Data dalam Indeks

Embedding, teks chunk, dan metadata disimpan dalam indeks pencarian atau vector database. Indeks tersebut dioptimalkan agar sistem dapat menemukan informasi yang relevan dengan cepat.

Implementasinya dapat menggunakan database khusus vektor, mesin pencari, layanan pencarian terkelola, atau PostgreSQL dengan ekstensi yang mendukung penyimpanan dan pencarian vektor.

Pilihan teknologi bergantung pada:

• Jumlah dokumen.
• Volume embedding.
• Kebutuhan pemfilteran.
• Target latensi.
• Pola pembaruan data.
• Kemampuan operasional tim.
• Kebutuhan pemisahan akses.

Ketika aplikasi RAG mulai membutuhkan backend, API, database vektor, cache, dan proses ingestion yang dapat dikonfigurasi secara mandiri, kamu dapat mempertimbangkan Cloud VPS DomaiNesia.

Akses root memberikan fleksibilitas untuk mengatur software dan lingkungan server sesuai arsitektur aplikasi. Model generatif dan embedding tetap dapat diakses melalui API apabila tim belum memerlukan inferensi mandiri.

Pendekatan ini memungkinkan tim memisahkan komponen aplikasi dari layanan LLM. Cloud VPS dapat digunakan untuk menjalankan backend, pipeline ingestion, database, cache, serta monitoring sesuai kapasitas server yang dipilih. Pembahasan lebih lanjut mengenai penggunaannya dapat ditemukan pada artikel Cloud VPS untuk mendukung AI dan machine learning.

Cloud VPS Turbo DomaiNesia saat ini menyediakan akses root, pilihan kapasitas yang dapat disesuaikan, penyimpanan SSD, serta infrastruktur berbasis AMD EPYC Genoa. Kebutuhan resource tetap perlu dihitung berdasarkan beban aplikasi, jumlah data, dan komponen yang dijalankan.

5. Mengambil Informasi yang Relevan

Ketika pengguna mengirim pertanyaan, retriever mencari sejumlah chunk yang dianggap paling relevan.

Pencarian dapat menggunakan beberapa metode:

• Keyword search untuk mencocokkan kata atau frasa.
• Vector search untuk mencari kedekatan makna.
• Hybrid search untuk menggabungkan pencarian teks dan vektor.
• Metadata filtering untuk membatasi hasil berdasarkan atribut tertentu.

Keyword search berguna untuk kode produk, nomor versi, nama paket, atau pesan error. Vector search lebih berguna ketika pertanyaan dan dokumen menggunakan susunan kata berbeda tetapi memiliki makna serupa.

Sebagai contoh, kueri “error koneksi database 1045” akan terbantu oleh keyword search karena memiliki kode khusus. Sementara itu, pertanyaan “mengapa aplikasi tidak dapat terhubung ke basis data?” lebih cocok dibantu pencarian semantik.

6. Melakukan Pemeringkatan Ulang dan Pemfilteran

Hasil pencarian awal belum tentu memiliki urutan terbaik. Sistem dapat menggunakan reranker untuk menilai kembali hasil dan menempatkan chunk yang paling mungkin menjawab pertanyaan di posisi atas.

Metadata filtering kemudian dapat membatasi hasil berdasarkan:

• Bahasa.
• Jenis produk.
• Versi dokumentasi.
• Tanggal berlaku.
• Departemen.
• Kategori.
• Identitas pengguna.
• Hak akses.

Tahap ini membantu mencegah dokumentasi lama bercampur dengan dokumen aktif. Pemfilteran juga mengurangi kemungkinan data dari departemen atau pengguna lain ikut masuk ke dalam konteks.

7. Menambahkan Konteks ke Prompt

Chunk terpilih digabungkan dengan pertanyaan pengguna dan instruksi sistem. Prompt dapat meminta model untuk:

• Menjawab hanya berdasarkan konteks.
• Tidak menambahkan fakta di luar sumber.
• Menyatakan ketika informasi tidak ditemukan.
• Menyertakan sumber pada klaim penting.
• Memisahkan fakta dan kesimpulan.
• Mengabaikan instruksi yang ditemukan di dalam dokumen.

LLM kemudian menyusun jawaban dalam bahasa yang lebih mudah dipahami. Retriever bertugas menemukan bukti, sedangkan model bahasa bertugas merangkum, menjelaskan, atau memformat informasi.

Komponen Utama Sistem RAG

RAG tidak hanya terdiri dari LLM dan vector database. Sistem produksi memerlukan beberapa komponen yang saling terhubung, mulai dari pengolahan dokumen hingga pemantauan jawaban.

Perubahan pada salah satu komponen, seperti embedding model atau strategi chunking, dapat memengaruhi kualitas keseluruhan sistem.

1. Sumber Pengetahuan

Sumber pengetahuan menentukan fakta yang tersedia bagi aplikasi. Setiap dokumen idealnya memiliki pemilik, versi, tanggal berlaku, dan prosedur pembaruan.

2. Pipeline Ingestion

Pipeline ingestion mengambil data, membersihkannya, membagi dokumen, membuat embedding, menambahkan metadata, serta memperbarui indeks.

Proses ini dapat dijalankan kembali ketika sumber berubah. Sistem juga perlu menangani dokumen yang dihapus atau tidak lagi berlaku.

3. Retriever dan Indeks Pencarian

Retriever menerima kueri dan mencari konteks yang relevan. Indeks pencarian menyediakan mekanisme pencarian, pemeringkatan, pemfilteran, dan penyimpanan metadata.

4. Orchestrator

Orchestrator mengatur alur dari pertanyaan hingga jawaban. Komponen ini dapat menangani penulisan ulang kueri, pemanggilan retriever, pemilihan konteks, penyusunan prompt, pemanggilan LLM, dan pencatatan hasil.

5. Large Language Model

LLM membaca konteks dan menghasilkan respons. Model yang lebih besar tidak selalu memperbaiki hasil apabila dokumen yang diambil salah.

Apabila ingin bereksperimen dengan model yang dijalankan sendiri, kamu dapat mempelajari cara menjalankan LLM menggunakan Ollama dan Open WebUI. Periksa kebutuhan RAM, CPU, GPU, dan penyimpanan setiap model sebelum melakukan deployment.

6. Guardrail dan Observability

Guardrail merupakan mekanisme pembatas untuk mengendalikan input, konteks, dan output. Sementara itu, observability membantu tim mencatat:

• Pertanyaan pengguna.
• Dokumen yang ditemukan.
• Waktu respons.
• Penggunaan token.
• Error.
• Biaya.
• Feedback pengguna.
• Versi prompt dan model.

Data tersebut diperlukan untuk menemukan apakah masalah berasal dari retrieval, sumber data, atau model generatif.

Manfaat Menggunakan RAG

RAG memberikan manfaat paling besar ketika aplikasi harus menjawab berdasarkan informasi yang dapat berubah atau bersifat khusus. Namun, manfaat tersebut bergantung pada kualitas sumber dan proses pengelolaannya.

Dokumen yang tidak terawat tetap dapat menghasilkan jawaban yang salah meskipun sistem retrieval bekerja sesuai konfigurasi.

1. Memperbarui Pengetahuan dengan Lebih Praktis

Tim dapat memperbarui dokumen dan indeks tanpa selalu melakukan fine-tuning. Pendekatan ini cocok untuk kebijakan, dokumentasi, spesifikasi produk, dan informasi operasional.

2. Mengurangi Jawaban Tanpa Dasar

Konteks eksternal memberikan bukti yang lebih spesifik kepada model. Paper awal RAG melaporkan bahwa pendekatan retrieval menghasilkan respons yang lebih faktual dan spesifik dibandingkan baseline parametrik pada tugas yang diuji. Hasil tersebut tidak dapat digeneralisasi sebagai jaminan untuk semua implementasi.

RAG tetap dapat menghasilkan jawaban tanpa dasar apabila dokumen yang ditemukan tidak relevan atau model menambahkan informasi di luar konteks.

3. Mendukung Data Domain Khusus

RAG dapat digunakan untuk bidang yang memiliki istilah dan dokumen khusus, seperti teknologi, pendidikan, hukum, layanan pelanggan, dan operasional internal.

LLM umum dapat digunakan untuk memahami bahasa, sedangkan fakta khusus tetap diperoleh dari sumber yang dipilih organisasi.

4. Mempermudah Audit Jawaban

Metadata dan kutipan membantu pengguna menelusuri asal informasi. Fitur ini berguna ketika jawaban perlu diperiksa oleh staf sebelum digunakan untuk mengambil keputusan.

Keterbatasan RAG

RAG sering dianggap sebagai solusi cepat untuk membuat chatbot berbasis dokumen. Padahal, retrieval menambahkan beberapa sumber kegagalan baru.

Sistem tetap perlu diuji secara menyeluruh meskipun menggunakan model yang memiliki kemampuan generatif tinggi.

1. Dokumen yang Diambil Tidak Relevan

Jika retriever menemukan chunk yang salah, LLM menerima dasar jawaban yang salah. Mengirim terlalu banyak dokumen juga dapat menambah noise dan mengurangi fokus konteks.

2. Sumber Kedaluwarsa atau Bertentangan

Basis pengetahuan tanpa manajemen versi dapat memuat beberapa aturan berbeda. Tanpa metadata dan pemfilteran, sistem mungkin memilih kebijakan yang sudah tidak berlaku.

3. Chunk Kehilangan Hubungan Penting

Ketentuan utama dan pengecualiannya dapat terpisah ke chunk berbeda. Akibatnya, jawaban terlihat benar tetapi tidak lengkap.

Masalah tersebut perlu dipertimbangkan ketika menentukan ukuran chunk, overlap, dan metode pengambilan dokumen induk.

4. Latensi dan Biaya Bertambah

RAG menambahkan proses embedding kueri, pencarian, pemeringkatan ulang, serta pemanggilan LLM. Setiap tahap dapat menambah waktu respons dan biaya.

Sistem yang lebih kompleks juga dapat memecah pertanyaan menjadi beberapa subkueri dan melakukan pencarian berulang.

5. Memiliki Risiko Keamanan

Dokumen eksternal dapat memuat indirect prompt injection, yaitu instruksi berbahaya yang ikut dibaca oleh model ketika dokumen masuk ke dalam konteks.

OWASP menegaskan bahwa RAG dan fine-tuning tidak sepenuhnya menghilangkan risiko prompt injection. Pengelola perlu membatasi hak akses, memisahkan konten tidak tepercaya, memfilter input dan output, serta meminta persetujuan manusia untuk tindakan berisiko.

RAG vs Fine-Tuning

RAG dan fine-tuning sama-sama dapat digunakan untuk menyesuaikan aplikasi AI. Namun, keduanya menyelesaikan masalah yang berbeda.

RAG lebih cocok untuk memberikan fakta atau dokumen ketika model menjawab. Fine-tuning lebih cocok untuk mengubah perilaku, gaya bahasa, format output, atau kemampuan model dalam menjalankan tugas tertentu.

Perbandingan tersebut tidak berarti salah satu pendekatan selalu lebih mudah atau murah. Kompleksitas bergantung pada skala data, model, frekuensi pembaruan, kebutuhan evaluasi, serta kemampuan operasional tim.

Berbeda dengan RAG, fine-tuning melibatkan pelatihan model AI menggunakan dataset tambahan untuk menyesuaikan parameter atau perilaku model.

Keduanya juga dapat digabungkan. Model yang telah di-fine-tune dapat digunakan untuk mengikuti format tertentu, sementara fakta tetap diperoleh melalui pipeline RAG.

Contoh Penggunaan RAG

RAG dapat diterapkan pada berbagai aplikasi selama sumber kebenarannya jelas. Sistem perlu mengetahui sumber mana yang harus digunakan untuk setiap jenis informasi.

Berikut beberapa contoh penggunaan yang umum.

1. Chatbot Layanan Pelanggan

Sistem mencari panduan produk, kebijakan, dan artikel bantuan sebelum menjawab pertanyaan pengguna.

2. Asisten Pengetahuan Internal

Karyawan dapat mencari SOP, dokumentasi proyek, kebijakan perusahaan, atau panduan operasional melalui antarmuka percakapan.

3. Pencarian Dokumentasi Teknis

Developer dapat bertanya tentang API, source code, konfigurasi, atau catatan versi tanpa mencari secara manual di banyak halaman.

4. Analisis Dokumen

RAG dapat membantu menemukan klausul, membandingkan isi dokumen, atau merangkum bagian tertentu dengan menyertakan rujukan.

Untuk data transaksional seperti harga, stok, saldo, dan status layanan, aplikasi sebaiknya mengambil data langsung dari database atau API resmi. Pencarian vektor terhadap dokumen lama tidak seharusnya menjadi sumber utama informasi yang berubah cepat.

Cara Mengevaluasi Sistem RAG

Kualitas RAG tidak dapat dinilai hanya dari kelancaran bahasa. Jawaban yang terdengar meyakinkan belum tentu didukung sumber yang tepat.

Evaluasi perlu memisahkan kemampuan sistem menemukan informasi dan kemampuan LLM menggunakan informasi tersebut.

1. Evaluasi Retrieval

Evaluasi retrieval menilai apakah sumber yang benar berhasil ditemukan dan ditempatkan pada posisi yang cukup tinggi.

Beberapa metrik yang dapat digunakan adalah:

• Precision.
• Recall.
• Hit rate.
• Mean Reciprocal Rank.
• NDCG.

Sebelum mengganti LLM, periksa terlebih dahulu apakah dokumen yang benar muncul dalam hasil pencarian. Model tidak dapat menggunakan informasi yang tidak pernah diberikan kepadanya.

2. Evaluasi Generation

Evaluasi generation menilai relevansi, kelengkapan, ketepatan, dan keterdukungan jawaban terhadap sumber atau groundedness.

Dataset pengujian sebaiknya berasal dari pertanyaan nyata pengguna dan mencakup:

• Pertanyaan dengan jawaban yang tersedia.
• Pertanyaan yang membutuhkan beberapa dokumen.
• Pertanyaan ambigu.
• Pertanyaan dengan istilah berbeda.
• Pertanyaan yang jawabannya tidak tersedia.
• Pertanyaan yang mengandung informasi salah.

Sistem yang baik harus mampu menyatakan bahwa informasi tidak ditemukan. Memaksakan jawaban ketika sumber tidak tersedia justru meningkatkan risiko halusinasi.

Kesimpulan

Retrieval-Augmented Generation adalah metode yang menghubungkan LLM dengan sumber informasi eksternal. Sistem mencari data relevan, memasukkannya sebagai konteks, kemudian meminta model menyusun jawaban.

RAG dapat membantu aplikasi menggunakan informasi terbaru, data internal, dan sumber yang dapat diperiksa. Namun, metode ini tidak otomatis menghilangkan halusinasi AI.

Kualitas akhirnya bergantung pada pengelolaan dokumen, chunking, embedding, retrieval, pemeringkatan ulang, prompt, keamanan, dan evaluasi.

Pembangunan RAG sebaiknya dimulai dari sumber data yang terbatas dan jelas. Pastikan retriever mampu menemukan bukti yang benar sebelum menambah model, agent, atau arsitektur yang lebih kompleks.

Infrastruktur kemudian dapat dikembangkan secara bertahap untuk menjalankan backend, pipeline ingestion, database vektor, cache, dan monitoring sesuai pertumbuhan kebutuhan aplikasi.