Belajar AI - Vector Databases & Retrieval (RAG)

#Pendahuluan

Setelah di episode 12 kalian memahami kapan fine-tuning diperlukan (dan kapan tidak), episode ini membangun pola arsitektur yang paling banyak dipakai untuk aplikasi LLM produksi: Retrieval-Augmented Generation (RAG). RAG menjawab kelemahan terbesar LLM — hallucination dan pengetahuan yang kedaluwarsa — dengan cara yang elegan: memberi model sumber sebelum ia menjawab.

Mengapa episode ini penting? Karena hampir setiap chatbot yang "tahu dokumen internal kalian" — manual produk, kebijakan HR, katalog — dibangun di atas RAG. Memahami RAG berarti memahami cara memberi LLM pengetahuan yang tidak ada di training-nya, tanpa perlu fine-tuning.

#Masalah yang Dipecahkan RAG

LLM dilatih pada satu titik waktu: ia tidak tahu dokumen yang dibuat kemarin, dan ia bisa mengarang fakta yang tidak pernah ada (hallucination). Solusi naifnya: masukkan semua dokumen ke prompt. Masalahnya: context window terbatas (episode 7) dan biaya token membengkak.

RAG memecah masalahnya: jangan masukkan semua dokumen — masukkan hanya bagian yang relevan dengan pertanyaan. Alurnya:

#Tiga Pilar RAG

#1. Chunking: Memecah Dokumen

Dokumen panjang tidak bisa di-embedding sekaligus (batas panjang dan presisi). Chunking memecahnya menjadi potongan yang bermakna:

• Fixed-size chunks: potong per N token. Sederhana, tapi bisa memotong kalimat di tengah.
• Recursive / semantic chunking: pecah berdasarkan paragraf atau batas makna (misal heading). Lebih bagus untuk kualitas retrieval.
• Chunk overlap: sisakan sedikit tumpang tindih antar chunk agar konteks tidak terpotong di sambungan.

from langchain_text_splitters import RecursiveCharacterTextSplitter
 
splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50,
)
chunks = splitter.split_text(document)
print(f"Terpecah menjadi {len(chunks)} chunk")

#2. Embeddings: Menjadi Vektor

Setiap chunk diubah menjadi embedding — vektor angka yang menangkap makna semantik (konsep yang kita kenal di episode 6). Model embedding umum di 2026: text-embedding-3-small (OpenAI), Cohere Embed, dan model open-weight seperti sentence-transformers/bge.

from sentence_transformers import SentenceTransformer
 
model = SentenceTransformer("sentence-transformers/all-MiniLM-L6-v2")
vectors = model.encode(chunks)
print(vectors.shape)  # (jumlah_chunk, 384)

#3. Vector Database: Mencari Cepat

Vector DB menyimpan embeddings dan menjawab "mana vektor yang paling mirip dengan vektor ini?" — biasanya dengan cosine similarity atau inner product. Yang populer:

#Praktik: Pipeline Dokumen → QA

#Indexing: Dokumen Masuk ke Vector DB

import chromadb
from sentence_transformers import SentenceTransformer
 
client = chromadb.PersistentClient(path="./chroma_db")
collection = client.get_or_create_collection("docs")
 
model = SentenceTransformer("sentence-transformers/all-MiniLM-L6-v2")
 
collection.add(
    ids=[f"chunk-{i}" for i in range(len(chunks))],
    embeddings=model.encode(chunks).tolist(),
    documents=chunks,
)

#Retrieval + Generation: Menjawab dengan Konteks

def ask(question: str) -> str:
    # 1. Embedding pertanyaan
    q_vec = model.encode([question]).tolist()
 
    # 2. Cari chunk paling relevan
    results = collection.query(
        query_embeddings=q_vec,
        n_results=3,
    )
    context = "\n\n".join(results["documents"][0])
 
    # 3. LLM menjawab dengan konteks
    prompt = (
        "Jawab berdasarkan konteks berikut. Jika konteks tidak memuat "
        "jawaban, katakan tidak tahu.\n\n"
        f"KONTEKS:\n{context}\n\nPERTANYAAN: {question}"
    )
    return llm_generate(prompt)

llm_generate adalah panggilan ke API LLM — kita bangun versi lengkapnya dengan streaming dan structured output di episode 14.

#Chunk Size, Top-K, dan Kualitas Retrieval

Tiga tombol yang paling memengaruhi kualitas RAG:

• Chunk size: terlalu kecil → konteks terpotong; terlalu besar → noise. Mulai dari 300-800 token, ukur.
• Top-K: jumlah chunk yang diambil (3-5 umumnya). Terlalu banyak → model bingung.
• Jenis similarity: cosine similarity adalah default yang paling aman.

Kualitas retrieval diukur dengan metrik episode 8: context recall (apakah konteks yang diambil memuat informasi yang dibutuhkan) dan context precision (apakah konteks yang diambil relevan). Evaluasi ini adalah fondasi MLOps LLM di episode 18.

#Common Pitfalls

• Chunking tanpa overlap: jawaban terputus di sambungan chunk.
• Embedding model tidak konsisten: chunking dan query harus pakai model embedding yang sama — kalau beda, hasil pencarian rusak.
• Mengabaikan metadata: simpan sumber chunk (nama dokumen, halaman) — penting untuk citation dan filtering.
• Tanpa evaluasi retrieval: RAG yang tidak diukur hanyalah tebakan; ukur context recall/precision.
• Menempatkan data sensitif tanpa akses control: semua user bisa membaca semua dokumen.

#Penutup

Inti yang harus dibawa pulang:

• RAG = retrieve dulu, jawab kemudian: memberi LLM sumber relevan mengurangi hallucination dan biaya.
• Pipeline: chunking → embeddings → vector DB → similarity search → LLM.
• Pilihan vector DB: ChromaDB (mudah) sampai Pinecone (managed skala besar).
• Kualitas retrieval = chunk size + top-K + konsistensi model embedding + evaluasi metrik.

Di episode 14 selanjutnya kita masuk ke integrasi: AI Applications & Integration (API) — memakai OpenAI-compatible API, structured output JSON, function/tool calling, dan membangun chatbot/copilot sederhana dengan streaming untuk aplikasi web, mobile, dan backend. Sampai jumpa di episode 14!