Skip to main content

Apa itu RAG (Retrieval-Augmented Generation)

Catatan: Dokumen ini adalah terjemahan otomatis dari versi asli bahasa Inggris.

Apa itu RAG (Retrieval-Augmented Generation)

Bayangkan seorang siswa mengikuti ujian open-book. Alih-alih menjawab setiap pertanyaan hanya dari ingatan, siswa itu membolak-balik buku teks, menemukan halaman yang paling relevan, membacanya, lalu menulis jawaban yang menggabungkan pengetahuan yang diingat dengan fakta yang baru dicari. Retrieval-Augmented Generation (RAG) bekerja dengan cara yang sama untuk large language model. Model tidak semata-mata mengandalkan apa yang dihafalnya selama pelatihan — ia lebih dulu mencari di basis pengetahuan eksternal, mengambil dokumen yang paling relevan, dan memakainya sebagai konteks tambahan saat menghasilkan respons.

Teknik ini penting karena bahkan LLM yang paling kuat pun memiliki tanggal batas pengetahuan, bisa "berhalusinasi" (menghasilkan pernyataan yang terdengar masuk akal tetapi keliru), dan mungkin kekurangan pengetahuan domain khusus. RAG mengatasi ketiga kelemahan itu sekaligus dengan memberi model akses ke sumber yang mutakhir, spesifik domain, dan dapat diverifikasi setiap kali ia menjawab pertanyaan.

Singkatnya: RAG adalah pola arsitektur yang menggabungkan sistem retrieval dengan LLM. Ia bukan jenis model tersendiri — ia adalah cara bekerja dengan pengetahuan dan konteks eksternal.

Cara kerjanya

Pipeline RAG mengikuti urutan lima langkah yang jelas. Memahami setiap langkah membantu Anda menilai apakah proyek yang mengklaim RAG memiliki lapisan retrieval yang benar-benar berfungsi atau sekadar membungkus panggilan LLM standar.

Langkah 1 — Kueri pengguna

Prosesnya dimulai ketika pengguna mengirimkan pertanyaan, perintah, atau prompt. Kueri ini adalah titik awal untuk semua yang menyusul. Misalnya, pengguna mungkin bertanya: "Apa saja proposal tata kelola besar di Ethereum dalam sebulan terakhir?" Sistem tidak mencoba menjawab dari ingatan LLM semata — ia memperlakukan kueri itu sebagai instruksi pencarian.

Langkah 2 — Embedding kueri

Kueri teks mentah dikonversi menjadi representasi numerik yang disebut embedding — vektor angka yang menangkap makna semantik kueri. Langkah ini memakai model embedding khusus (seperti text-embedding-ada-002 dari OpenAI atau alternatif open-source seperti E5 atau BGE). Vektor yang dihasilkan memungkinkan sistem melakukan pencarian semantik — menemukan dokumen berdasarkan makna, bukan kecocokan kata kunci yang persis.

Langkah 3 — Retrieval dari basis pengetahuan

Embedding kueri dibandingkan terhadap basis data vektor (juga disebut vector store) yang menyimpan embedding dokumen, bagian teks, atau potongan data yang telah dihitung sebelumnya. Basis data mengembalikan top-k item yang paling mirip secara semantik. Basis data vektor yang umum meliputi Pinecone, Weaviate, Qdrant, Milvus, dan Chroma.

Kualitas retrieval bergantung pada beberapa faktor:

  • Strategi chunking — bagaimana dokumen asli dipecah menjadi bagian-bagian lebih kecil. Chunk yang terlalu besar mengencerkan relevansi; chunk yang terlalu kecil kehilangan konteks. Menemukan ukuran chunk yang tepat adalah salah satu keputusan rekayasa paling berdampak dalam pipeline RAG.
  • Model embedding — seberapa akurat makna ditangkap dalam vektor. Model embedding yang lemah menghasilkan retrieval yang lemah, apa pun basis datanya.
  • Peringkat relevansi — apakah pencarian mengembalikan hasil yang benar-benar relevan atau hanya mirip di permukaan. Sebagian sistem menambahkan langkah re-ranking yang memakai cross-encoder untuk menskor ulang hasil awal.

Langkah 4 — Injeksi konteks

Dokumen yang diambil digabungkan dengan kueri asli pengguna menjadi satu prompt (kadang disebut "augmented prompt") yang dikirim ke LLM. Prompt itu biasanya menginstruksikan model untuk menjawab pertanyaan memakai konteks yang disediakan dan untuk menyatakan ketika konteksnya tidak memuat informasi yang cukup.

Langkah 5 — Generasi LLM dan output

LLM membaca augmented prompt dan menghasilkan respons yang berpijak baik pada pengetahuan pralatihnya maupun bukti yang diambil. Sistem RAG yang dirancang baik juga dapat menyertakan lapisan sitasi yang menautkan bagian-bagian jawaban kembali ke dokumen sumber tertentu, memberi pengguna cara untuk memverifikasi klaim.

Tahap Input Output Komponen kunci
Kueri Teks pengguna Kueri mentah Antarmuka pengguna
Embedding Kueri mentah Vektor kueri Model embedding
Retrieval Vektor kueri Dokumen relevan Basis data vektor
Injeksi konteks Kueri + dokumen Augmented prompt Templat prompt
Generasi Augmented prompt Jawaban akhir LLM

Mengapa RAG penting

RAG mengatasi tiga keterbatasan LLM mandiri yang sudah dikenal luas:

  • Halusinasi. LLM dapat menghasilkan jawaban yang percaya diri tetapi keliru. RAG menguranginya dengan memijakkan respons pada dokumen nyata. Ketika model dapat merujuk bagian teks tertentu, risiko fabrikasi turun signifikan.
  • Pengetahuan usang. Model pralatih memiliki tanggal batas pengetahuan. RAG memungkinkan akses ke data segar yang terus diperbarui — basis data eksternal dapat disegarkan harian atau bahkan real-time.
  • Spesifisitas domain. Men-fine-tune LLM untuk domain sempit itu mahal dan memakan waktu. RAG memungkinkan model serba guna bekerja dengan basis pengetahuan terspesialisasi tanpa pelatihan ulang, membuatnya lebih cepat dan lebih murah untuk men-deploy aplikasi spesifik domain.

RAG vs fine-tuning

Baik RAG maupun fine-tuning bertujuan meningkatkan kinerja LLM pada tugas tertentu, tetapi keduanya bekerja dengan cara yang berbeda secara fundamental.

Aspek RAG Fine-tuning
Kapan pengetahuan ditambahkan Saat inferensi (setiap kueri) Saat pelatihan (sekali, lalu statis)
Biaya pembaruan Rendah — perbarui basis pengetahuan Tinggi — latih ulang atau fine-tune ulang model
Kesegaran pengetahuan Bisa nyaris real-time Beku pada batas waktu pelatihan
Butuh infrastruktur pelatihan Tidak Ya (GPU, dataset, pipeline pelatihan)
Paling cocok untuk Mengingat fakta, tanya-jawab dokumentasi Gaya, nada, format, optimasi tugas sempit
Auditabilitas Tinggi — sumber yang diambil dapat dicatat Rendah — pengetahuan tertanam dalam bobot

Dalam praktiknya, banyak sistem produksi menggabungkan keduanya: model yang di-fine-tune memberikan nada dan perilaku tugas yang tepat, sementara RAG memasok pijakan faktual yang mutakhir.

Pola RAG tingkat lanjut

Pipeline lima langkah dasar yang dijelaskan di atas kadang disebut naive RAG. Seiring teknik ini semakin matang, para insinyur mengembangkan varian yang lebih canggih:

  • RAG multi-langkah (iteratif). Alih-alih mengambil sekali, sistem mengambil, menghasilkan jawaban antara, mengidentifikasi celah pengetahuan, mengambil lagi dengan kueri yang diperhalus, dan mengulanginya sampai jawabannya cukup lengkap. Pendekatan ini menangani pertanyaan kompleks yang tidak bisa dijawab dari satu putaran retrieval.
  • Agentic RAG. Langkah retrieval dibungkus di dalam kerangka agen AI. Agen memutuskan kapan mengambil, basis pengetahuan mana yang dikueri, apakah kueri perlu dirumuskan ulang, dan kapan konteksnya sudah cukup untuk menghasilkan jawaban akhir. Pola ini mengaburkan batas antara RAG dan agen otonom.
  • Pencarian hibrida. Menggabungkan pencarian semantik berbasis vektor dengan pencarian kata kunci tradisional (BM25) dalam langkah retrieval yang sama. Pencarian hibrida menangkap kecocokan berbasis makna sekaligus berbasis istilah, meningkatkan recall untuk kueri yang memuat istilah teknis spesifik atau nama diri.
  • Graph RAG. Alih-alih potongan dokumen datar, basis pengetahuan distrukturkan sebagai knowledge graph — entitas dan relasi. Retrieval mengikuti sisi-sisi graf alih-alih (atau selain) kemiripan vektor, memungkinkan penalaran multi-hop atas data terstruktur. Pola-pola ini penting untuk evaluasi: proyek yang menjelaskan pipeline graph-RAG dengan retrieval iteratif membuat klaim yang lebih spesifik (dan lebih sulit dipalsukan) daripada yang sekadar bilang "kami memakai RAG."

Contoh nyata RAG

RAG bukan konsep teoretis — ia menenagai sebagian produk AI yang paling luas dipakai saat ini.

  • Bing Chat (Microsoft Copilot). Saat Anda mengajukan pertanyaan ke Bing Chat, ia mencari di web, mengambil halaman yang relevan, dan memakai halaman-halaman itu sebagai konteks untuk jawaban LLM. Sitasi sebaris yang Anda lihat pada respons adalah hasil langsung dari langkah retrieval.
  • Perplexity. Perplexity dibangun di atas arsitektur RAG: setiap kueri pengguna memicu pencarian web, hasilnya diumpankan ke LLM, dan jawabannya menyertakan rujukan sumber bernomor. Pengguna dapat mengklik untuk memverifikasi setiap klaim.
  • Asisten pengetahuan korporat. Perusahaan memakai sistem RAG internal agar karyawan dapat mengkueri kebijakan HR, dokumentasi rekayasa, atau kontrak hukum dengan bahasa alami. Lapisan retrieval mencari di penyimpanan dokumen internal perusahaan, bukan di web terbuka. Contoh-contoh ini menunjukkan RAG adalah teknologi arus utama. Ketika proyek AI kripto berkata "kami memakai RAG," pertanyaannya bukan apakah RAG adalah teknologi nyata, melainkan apakah implementasi spesifik proyek itu solid: data apa yang diambil, bagaimana diindeks, dan apakah kualitas retrieval-nya pernah diukur.

Mengapa RAG muncul di proyek AI kripto

Banyak proyek AI kripto memakai RAG atau mengklaim memakainya dalam arsitektur mereka. Kasus penggunaan yang umum meliputi:

  • Asisten dokumentasi — mengambil dokumen protokol, whitepaper, atau proposal tata kelola untuk menjawab pertanyaan pengguna tentang aturan atau parameter protokol.
  • Perangkat inteligensi kripto — menarik data pasar real-time, peristiwa on-chain, atau artikel berita untuk menghasilkan ringkasan analisis atau peringatan.
  • Basis pengetahuan untuk agen — membangun repositori terstruktur yang dapat dikueri agen AI sebelum bertindak, memastikan keputusan diinformasikan oleh data terbaru.
  • Pemijakan data on-chain — menghubungkan lapisan retrieval ke pengindeks blockchain sehingga LLM dapat menjawab pertanyaan tentang saldo dompet, riwayat transaksi, atau status smart contract dengan informasi terkini alih-alih snapshot masa pelatihan.

Nilai AI component yang tipikal di kartu proyek DecAIHub yang melibatkan pola RAG meliputi: "3D AI agents (RAG/memory/LLM catalog)", "AI summaries + crypto intelligence terminal", dan "AgentData (real-time data streams for AI agents)".

RAG bukan model

Miskonsepsi yang umum adalah memperlakukan RAG sebagai jenis model AI. Bukan. RAG adalah pola arsitektur — cara menggabungkan sistem retrieval dengan LLM. Model di dalam pipeline RAG bisa GPT, DeepSeek, Mistral, atau LLM lain mana pun. Komponen retrieval-nya bisa berupa basis data vektor, API pencarian, atau knowledge graph terstruktur.

Mengatakan "kami memakai RAG" memberi tahu Anda bagaimana sistemnya diorganisasi. Ia tidak memberi tahu model mana yang dipakai, apakah modelnya proprietary, atau seberapa baik kualitas retrieval-nya. Dua proyek bisa sama-sama mengklaim RAG dengan tingkat kecanggihan yang jauh berbeda — satu dengan basis pengetahuan terkurasi cermat dan embedding kustom, satunya lagi dengan prototipe rakitan tergesa yang jarang mengembalikan dokumen relevan.

Apa yang tidak dibuktikan oleh RAG

  • Memakai RAG tidak membuktikan LLM di baliknya proprietary atau di-fine-tune. Proyek bisa saja memanggil API pihak ketiga.
  • Membangun pipeline RAG tidak membuktikan kualitas retrieval-nya tinggi. Kualitas bergantung pada basis pengetahuan, strategi chunking, model embedding, dan relevansi pencarian.
  • Memiliki arsitektur RAG tidak membuktikan jawabannya akurat. Retrieval yang buruk dapat memasok konteks yang tidak relevan, dan LLM tetap bisa berhalusinasi.
  • Menyebut RAG di landing page tidak membuktikan sistemnya benar-benar melakukan retrieval. Tanpa bukti Tier-1 — kode, diagram arsitektur, log demo — klaim itu tetap tak terverifikasi. Saat mengevaluasi proyek AI kripto yang mengklaim RAG, cari hal-hal spesifik: basis pengetahuan apa yang dicari, model embedding apa yang dipakai, bagaimana relevansi diukur, dan apakah ada metrik kualitas yang dipublikasikan.

Di mana ia muncul dalam kartu proyek DecAIHub

RAG biasanya dirujuk di field AI component — baik secara langsung maupun lewat deskripsi yang menyiratkan pipeline retrieval-plus-generation. Flag AI_1 memeriksa apakah komponen AI dideskripsikan dengan cukup spesifik. Sekadar menulis "RAG" tidak cukup; kartu harus menjelaskan apa yang diambil, dari mana, dan untuk tujuan apa.

Jangan bingung dengan

  • LLM — mesin generasi di dalam pipeline RAG. RAG menambahkan retrieval di atasnya.
  • Pelatihan — RAG adalah pola saat inferensi. Ia tidak melatih ulang model; ia mengaugmentasi prompt dengan konteks yang diambil.
  • Agen AI — agen dapat memakai RAG sebagai salah satu perkakasnya, tetapi RAG sendiri tidak membuat sistem menjadi agen.
  • Fine-tuning — fine-tuning menyesuaikan bobot model selama fase pelatihan. RAG menyuntikkan pengetahuan eksternal saat inferensi tanpa memodifikasi model.
  • Lapisan retrieval / pengetahuan — komponen retrieval adalah separuh dari RAG. RAG menambahkan langkah generasi di atas retrieval murni.

Pertanyaan yang sering diajukan

Apa perbedaan antara RAG dan fine-tuning?

Fine-tuning mengubah bobot model secara permanen dengan melatihnya pada dataset terspesialisasi. Pengetahuan baru menjadi bagian dari model itu sendiri. RAG membiarkan model tak tersentuh dan sebagai gantinya memasok dokumen relevan pada saat kueri. Fine-tuning lebih baik untuk mengajari model gaya atau format tugas baru; RAG lebih baik untuk menjaga jawaban tetap berpijak pada fakta segar yang dapat diverifikasi. Banyak sistem produksi memakai keduanya — model yang di-fine-tune menangani nada dan format sementara RAG menyediakan pijakan faktual yang mutakhir.

Apakah RAG membuat LLM lebih akurat?

RAG dapat secara signifikan mengurangi halusinasi dengan memijakkan output model pada bukti yang diambil. Namun, akurasi bergantung pada kualitas retrieval. Jika sistem retrieval mengembalikan dokumen yang tidak relevan atau usang, LLM bisa menghasilkan jawaban yang salah dengan percaya diri — kini didukung bukti yang keliru. RAG menaikkan plafon akurasi tetapi tidak menjaminnya. Mengukur presisi dan recall retrieval sangat penting bagi setiap deployment RAG yang serius.

Apa itu basis data vektor?

Basis data vektor adalah penyimpanan data khusus yang dirancang untuk menyimpan dan mencari vektor numerik berdimensi tinggi (embedding). Ketika embedding kueri dikirimkan, basis data melakukan pencarian kemiripan — biasanya dengan algoritme seperti HNSW atau IVF — untuk menemukan vektor yang paling cocok. Ini memungkinkan pencarian semantik: menemukan dokumen berdasarkan makna, bukan kecocokan kata kunci yang persis. Basis data vektor yang populer meliputi Pinecone, Weaviate, Qdrant, Milvus, dan Chroma.

Bagaimana RAG dipakai di proyek AI kripto?

Proyek AI kripto memakai RAG untuk menghubungkan LLM dengan data spesifik blockchain: dokumentasi protokol, proposal tata kelola, riwayat transaksi on-chain, umpan harga real-time, dan kode sumber smart contract. Lapisan retrieval mencari di sumber-sumber terspesialisasi ini sehingga LLM dapat menjawab pertanyaan spesifik domain dengan data terkini alih-alih mengandalkan pengetahuan pelatihan yang usang. Kualitas sistem semacam itu sangat bervariasi — dari basis pengetahuan yang terindeks baik dan terkurasi hingga penyiapan minimal yang mengambil sedikit konteks berguna.

Bisakah RAG bekerja dengan data on-chain?

Ya. Lapisan retrieval dalam pipeline RAG dapat terhubung ke pengindeks blockchain, subgraph, atau API analitik on-chain. Ketika pengguna bertanya tentang saldo dompet, riwayat transaksi, atau status smart contract, sistem retrieval mengambil data on-chain yang relevan, dan LLM menghasilkan penjelasan yang mudah dibaca manusia. Tantangan utamanya adalah latensi (kueri blockchain bisa lambat), pemformatan data (data on-chain mentah harus diurai dan di-chunk untuk embedding), dan kesegaran (indeks harus diperbarui cukup sering agar mencerminkan status chain terkini).

Lihat juga

Referensi eksternal

  • Lewis, P. et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." arXiv, 2020. https://arxiv.org/abs/2005.11401
  • Gao, Y. et al. "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv, 2024. https://arxiv.org/abs/2312.10997
  • AWS. "What is RAG?" https://aws.amazon.com/what-is/retrieval-augmented-generation/
  • Pinecone. "Retrieval-Augmented Generation (RAG)." https://www.pinecone.io/learn/retrieval-augmented-generation/
  • Microsoft. "Retrieval-Augmented Generation (RAG) in Azure AI Search." https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview