Chunking & kualitas retrieval

RAG di materi sebelumnya berasumsi retrieval selalu menemukan chunk yang tepat. Kenyataannya, cara dokumen dipecah jadi chunk — dan cara pencariannya dilakukan — adalah bagian yang paling menentukan kualitas RAG di produksi.

Ukuran chunk: trade-off yang harus dipilih sengaja

Tidak ada ukuran ajaib yang cocok semua kasus — titik awal umum adalah beberapa ratus token per chunk, disesuaikan dengan struktur dokumenmu (per paragraf, per bagian dokumentasi, dsb.), lalu diuji & disetel berdasarkan hasil evaluasi (materi berikutnya).

def pecah_jadi_chunk(teks: str, ukuran: int = 500, overlap: int = 50) -> list[str]:
    kata = teks.split()
    chunks = []
    i = 0
    while i < len(kata):
        chunk = " ".join(kata[i:i + ukuran])
        chunks.append(chunk)
        i += ukuran - overlap  # mundur sedikit supaya ada tumpang tindih antar chunk
    return chunks

Masalah konteks yang hilang: contextual retrieval

Chunk yang diambil sendirian, terpisah dari dokumen aslinya, sering kehilangan konteks penting. Sebuah chunk berbunyi "Pendapatan perusahaan naik 20% tahun ini" tidak berguna kalau sistem tidak tahu ini kutipan dari laporan tahunan perusahaan mana, dan tahun berapa.

Teknik contextual retrieval (dari sumber materi ini) mengatasinya dengan menambahkan ringkasan konteks singkat ke setiap chunk sebelum di-embed — biasanya dibuat dengan meminta LLM merangkum "di mana posisi chunk ini dalam dokumen aslinya":

Chunk asli:
"Pendapatan naik 20% dibanding tahun sebelumnya, didorong oleh ekspansi pasar Asia Tenggara."

Chunk + konteks tambahan (sebelum di-embed):
"[Dari: Laporan Tahunan 2025, PT Contoh Jaya, bagian Ringkasan Keuangan]
Pendapatan naik 20% dibanding tahun sebelumnya, didorong oleh ekspansi pasar Asia Tenggara."

Hybrid search: semantik + kata kunci

Pencarian embedding murni bisa melewatkan kecocokan yang sebenarnya jelas secara literal — kode produk seperti "SKU-4521" atau istilah teknis yang jarang muncul di data latihan model embedding mungkin tidak punya representasi vektor yang tajam. Hybrid search menggabungkan skor dari pencarian semantik (embedding) dan pencarian kata kunci tradisional (mis. full-text search Postgres), lalu menggabungkan rankingnya.

Reranking: kasar dulu, presisi kemudian

Pola yang sering dipakai bersama hybrid search: ambil kandidat lebih banyak dari yang dibutuhkan di tahap retrieval awal (mis. 20 chunk), lalu pakai model reranker — biasanya lebih lambat tapi jauh lebih presisi — untuk menilai ulang kecocokan tiap kandidat dengan pertanyaan, dan ambil yang benar-benar terbaik (mis. top 3) untuk dikirim ke model generatif.

Retrieval awal (cepat, kasar):  20 kandidat teratas dari similarity search
                                        │
                                        ▼
Reranking (lambat, presisi):    urutkan ulang 20 kandidat itu berdasarkan relevansi sebenarnya
                                        │
                                        ▼
Kirim ke model:                  ambil 3 teratas hasil reranking