Retrieval-Augmented Generation (RAG) adalah salah satu pola arsitektur paling praktis untuk membuat LLM menjawab berdasarkan data spesifik Anda — dokumentasi internal, basis pengetahuan produk, atau data perusahaan — tanpa perlu fine-tuning model. Artikel ini adalah panduan pilar: memahami konsep inti, komponen arsitektur, dan implementasi dasar sebelum masuk ke teknik optimasi yang lebih lanjut.

Mengapa RAG, Bukan Fine-tuning?

Pertanyaan paling umum: “kenapa tidak fine-tune saja modelnya dengan data kita?” Ada tiga alasan RAG lebih sering jadi pilihan default:

  • Data selalu berubah — RAG mengambil data terbaru saat query, sementara fine-tuning “membekukan” pengetahuan pada satu titik waktu.
  • Biaya dan kompleksitas lebih rendah — fine-tuning butuh infrastruktur training dan dataset berkualitas dalam jumlah besar; RAG cukup dengan pipeline retrieval yang baik.
  • Transparansi sumber jawaban — RAG bisa menunjukkan dokumen sumber yang dipakai untuk menjawab, penting untuk auditabilitas di konteks bisnis.

Fine-tuning tetap relevan untuk kasus lain (mengubah gaya/format output, atau menanamkan pola perilaku spesifik) — tapi untuk kebutuhan “jawab berdasarkan data kami”, RAG adalah titik awal yang tepat.

Komponen Inti Arsitektur RAG

Dokumen sumber → Chunking → Embedding → Vector Database
                                              ↓
Pertanyaan pengguna → Embedding → Similarity Search → Konteks relevan
                                              ↓
                              Konteks + Pertanyaan → LLM → Jawaban
  1. Chunking — memecah dokumen panjang menjadi potongan kecil (biasanya 200-800 token) agar retrieval lebih presisi. Ukuran chunk yang terlalu besar membuat retrieval kurang relevan; terlalu kecil membuat konteks terpotong.
  2. Embedding model — mengubah teks menjadi vektor numerik yang merepresentasikan makna semantik.
  3. Vector database — menyimpan embedding dan melakukan pencarian kemiripan (similarity search) dengan cepat pada skala besar.
  4. Retriever — komponen yang mengambil top-K chunk paling relevan berdasarkan query pengguna.
  5. Prompt assembly — menggabungkan konteks yang diambil dengan pertanyaan asli menjadi satu prompt untuk LLM.

Implementasi Dasar (Contoh Konsep dengan LangChain)

Contoh berikut menunjukkan alur inti secara konseptual — sesuaikan nama library/API dengan versi yang Anda pakai:

from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma
from langchain.chains import RetrievalQA
from langchain.llms import OpenAI

# 1. Pecah dokumen jadi chunk
splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = splitter.split_documents(dokumen_sumber)

# 2. Buat embedding dan simpan ke vector database
embeddings = OpenAIEmbeddings()
vectordb = Chroma.from_documents(chunks, embeddings)

# 3. Bangun retriever
retriever = vectordb.as_retriever(search_kwargs={"k": 4})

# 4. Rangkai retriever dengan LLM
qa_chain = RetrievalQA.from_chain_type(
    llm=OpenAI(temperature=0),
    retriever=retriever,
)

jawaban = qa_chain.run("Bagaimana kebijakan cuti tahunan di perusahaan?")
print(jawaban)

Empat langkah ini adalah kerangka minimal. Dalam praktik produksi, setiap langkah punya ruang optimasi signifikan.

Kesalahan Umum yang Menurunkan Kualitas RAG

  • Chunking tanpa mempertimbangkan struktur dokumen — memotong tabel atau daftar di tengah membuat konteks kehilangan makna.
  • Top-K terlalu kecil atau terlalu besar — terlalu kecil berisiko melewatkan informasi relevan; terlalu besar membuat prompt penuh noise dan menaikkan biaya token.
  • Tidak ada evaluasi retrieval terpisah dari evaluasi jawaban akhir — kalau jawaban salah, Anda perlu tahu apakah masalahnya di retrieval (dokumen relevan tidak ditemukan) atau di generation (LLM salah menafsirkan konteks yang benar).
  • Mengabaikan pembaruan data — vector database perlu strategi re-indexing saat dokumen sumber berubah, bukan hanya di-build sekali di awal.

Kapan RAG Sederhana Tidak Cukup

Untuk kasus yang lebih kompleks — pertanyaan yang butuh menggabungkan informasi dari banyak dokumen, atau butuh penalaran multi-langkah — pola RAG dasar (single retrieval pass) sering tidak memadai. Di sinilah teknik lanjutan seperti re-ranking, query rewriting, dan agentic RAG (retrieval bertahap dengan keputusan dinamis) menjadi relevan.

Checklist Sebelum ke Produksi

  1. Sudah diuji dengan pertanyaan yang jawabannya tidak ada di data sumber — apakah sistem mengaku tidak tahu, atau berhalusinasi?
  2. Ada mekanisme menampilkan sumber dokumen di jawaban akhir.
  3. Ada strategi update/re-index saat dokumen sumber berubah.
  4. Ada evaluasi kualitas retrieval secara terpisah dari kualitas jawaban akhir.
  5. Ada batas biaya token yang dipantau, terutama saat top-K atau ukuran chunk membesar.

Artikel ini adalah bagian dari seri Tutorial & Implementasi Teknis di Nalar Digital. Teknik lanjutan seperti re-ranking dan agentic RAG akan dibahas di artikel-artikel berikutnya.