Pentingnya Chunking Strategy dalam RAG

Chunking strategy dalam RAG adalah proses memecah dokumen panjang menjadi potongan-potongan kecil sebelum diubah jadi embedding dan disimpan di vector database. Topik ini juga jadi salah satu materi inti di kelas “Pengembangan Generative AI berbasis LLM” pada Dicoding Bootcamp Batch 15, jadi kalau kamu ingin mendalaminya sampai level produksi, program itu bisa jadi jalur belajar yang pas.

Strategi chunking menentukan seberapa akurat sistem Retrieval-Augmented Generation (RAG) menemukan konteks yang relevan saat menjawab pertanyaan pengguna. Artikel ini membahas kenapa chunking krusial, trade-off ukuran chunk, teknik-teknik populer, implementasi dengan LangChain, hingga cara mengevaluasinya.

Artikel ini cocok dibaca oleh praktisi ML dan backend engineer yang sedang membangun sistem RAG, maupun pemula yang baru mengenal konsep chunking dan ingin memahami dasarnya sebelum masuk ke optimasi lanjutan.

💻 Mulai Belajar Pemrograman

Belajar pemrograman di Dicoding Academy dan mulai perjalanan Anda sebagai developer profesional.

Daftar Sekarang

Apa Itu Chunking dan Kenapa RAG Butuh Itu?

Seperti disebutkan di awal, chunk hasil pemecahan dokumen disimpan sebagai embedding di vector database. Sistem RAG bekerja dengan mengambil potongan teks relevan dari basis pengetahuan itu, lalu menyisipkannya ke prompt sebelum dikirim ke large language model (LLM). Karena model embedding dan LLM punya batas panjang input, dokumen panjang seperti PDF ratusan halaman tidak bisa diproses utuh. Di sinilah chunking berperan, memecah dokumen menjadi unit-unit kecil yang bisa di-embed dan dicari secara efisien.

Ukuran dan cara pemotongan chunk memengaruhi langsung kualitas embedding yang dihasilkan. Chunk yang memuat satu ide utuh akan menghasilkan vektor representasi yang padat makna, sehingga saat query pengguna dicocokkan lewat cosine similarity, hasil retrieval lebih relevan. Sebaliknya, chunk yang memotong kalimat di tengah konteks akan menghasilkan embedding yang ambigu dan menurunkan retrieval quality.

Chunking juga menentukan efisiensi biaya. Setiap chunk yang diambil saat retrieval akan masuk ke context window LLM, dan context window dihitung berdasarkan jumlah token. Strategi chunking yang buruk membuat sistem mengambil terlalu banyak chunk tidak relevan hanya untuk menutupi informasi yang terpotong, ini yang akan kamu evaluasi lebih detail pada bagian trade-off ukuran chunk.

Trade-off Ukuran Chunk: Terlalu Kecil vs. Terlalu Besar

Menentukan chunk_size bukan angka sembarangan, ada trade-off nyata antara granularitas dan konteks. Chunk yang terlalu kecil (misalnya di bawah 128 token) cenderung kehilangan konteks sekitar. Sebuah kalimat seperti “Metode ini meningkatkan akurasi sebesar 15%” jadi tidak bermakna tanpa tahu “metode ini” merujuk ke apa.

Sebaliknya, chunk yang terlalu besar (misalnya di atas 1000 token) membawa terlalu banyak informasi campur aduk dalam satu vektor embedding. Ini menyebabkan noise, sinyal makna utama tertimbun oleh informasi pendukung yang tidak relevan dengan query. Chunk besar juga memboroskan token saat masuk ke context window LLM, karena hanya sebagian kecil isinya yang benar-benar relevan dengan pertanyaan pengguna.

Sebagai gambaran umum, banyak implementasi RAG produksi memakai chunk_size di rentang 256 sampai 512 token dengan chunk_overlap 10-20% dari ukuran chunk. Namun, angka ini bukan patokan mutlak, karakteristik dokumen (artikel berita vs dokumentasi teknis vs transkrip percakapan) menentukan rentang optimalnya. Mari kita lihat teknik-teknik konkret untuk menentukan potongan chunk yang tepat.

Teknik-Teknik Chunking Strategy

Ada beberapa pendekatan chunking yang umum dipakai, masing-masing punya karakteristik dan kasus penggunaan berbeda.

Fixed-size chunking: memotong teks per N karakter atau token secara mekanis, misalnya chunk_size=500 karakter. Paling sederhana dan cepat, tapi rawan memotong kalimat atau paragraf di tengah.
Recursive character splitting: memotong teks secara hierarkis, mencoba split di pemisah alami dulu (paragraf, lalu kalimat, lalu kata) sebelum jatuh ke potongan paksa. Parameter umum chunk_size=500, chunk_overlap=50.
Semantic chunking: menggunakan model embedding untuk mendeteksi pergeseran topik antar kalimat, lalu memotong chunk di titik pergeseran makna tersebut, bukan di titik jumlah karakter tetap.
Sliding window: membuat chunk yang saling tumpang tindih dengan window bergeser, misalnya window 300 token bergeser tiap 150 token, sehingga informasi di batas chunk tetap punya konteks di chunk sebelah.

Fixed-size cocok untuk prototyping cepat, recursive character splitting jadi default paling banyak dipakai karena seimbang antara kesederhanaan dan kualitas, sementara semantic chunking lebih cocok untuk dokumen dengan struktur topik kompleks seperti buku atau laporan riset. Selanjutnya, kita akan masuk ke praktik implementasinya.

Implementasi Chunking dengan LangChain

LangChain menyediakan text splitter siap pakai yang memudahkan implementasi chunking tanpa menulis logika parsing dari nol. Berikut contoh sederhana memakai RecursiveCharacterTextSplitter.

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(

chunk_size=500,

chunk_overlap=50,

separators=["\n\n", "\n", ". ", " ", ""]

)

chunks = splitter.split_text(dokumen_teks)

print(f"Jumlah chunk: {len(chunks)}")

Parameter chunk_size=500 menentukan panjang maksimum tiap chunk dalam karakter, sedangkan chunk_overlap=50 memastikan 50 karakter terakhir suatu chunk terulang di awal chunk berikutnya, menjaga kesinambungan konteks di batas potongan.

Untuk kasus yang butuh pemotongan berbasis makna, LangChain juga menyediakan SemanticChunker dari modul langchain_experimental.

from langchain_experimental.text_splitter import SemanticChunker

from langchain_openai import OpenAIEmbeddings

semantic_splitter = SemanticChunker(

embeddings=OpenAIEmbeddings(),

breakpoint_threshold_type="percentile",

breakpoint_threshold_amount=90

)

chunks = semantic_splitter.split_text(dokumen_teks)

breakpoint_threshold_amount=90 berarti splitter akan memotong chunk baru saat perbedaan makna antar kalimat berada di atas persentil ke-90, sehingga chunk hanya dipecah pada pergeseran topik yang signifikan. Setelah chunk terbentuk, langkah berikutnya adalah memastikan strategi yang dipilih benar-benar meningkatkan kualitas retrieval.

Cara Evaluasi Strategi Chunking untuk RAG

Menentukan strategi chunking terbaik tidak boleh hanya berdasarkan asumsi, kamu perlu mengukurnya dengan metrik retrieval yang konkret. Dua metrik yang umum dipakai sebagai proxy kualitas chunking adalah recall@k dan Mean Reciprocal Rank (MRR).

Recall@k mengukur seberapa sering dokumen relevan muncul di antara k hasil teratas, misalnya recall@5 menghitung persentase query yang jawabannya berhasil ditemukan dalam 5 chunk teratas. MRR mengukur seberapa cepat dokumen relevan muncul di urutan hasil, memberi skor lebih tinggi jika jawaban ada di posisi 1 dibandingkan dengan posisi 5.

Perlu dicatat, hasil recall@k dan MRR tidak murni mencerminkan kualitas chunking saja, metrik ini juga dipengaruhi oleh pilihan model embedding dan algoritma retriever yang dipakai. Karena itu, saat membandingkan strategi chunking, pastikan komponen lain (model embedding, jumlah k, dataset evaluasi) dibuat konstan agar perbandingan adil.

Tips praktis untuk membandingkan strategi, siapkan set pertanyaan uji beserta jawaban rujukan (ground truth), lalu jalankan retrieval dengan beberapa variasi chunk_size (misalnya 256, 512, 1024) dan chunk_overlap (misalnya 0%, 10%, 20%) secara terpisah. Bandingkan skor recall@5 dan MRR dari tiap kombinasi, lalu pilih konfigurasi dengan skor tertinggi yang juga efisien dari sisi biaya token. Dengan alur dari konsep dasar sampai evaluasi ini, kamu sudah punya gambaran lengkap untuk merancang chunking strategy sendiri.

Penutup

Intinya: chunking bukan sekadar memotong teks, ia menentukan seberapa relevan konteks yang diambil sistem RAG saat menjawab pertanyaan. Ukuran chunk yang terlalu kecil kehilangan konteks, terlalu besar membawa noise dan boros token. Teknik seperti recursive character splitting jadi pilihan seimbang untuk kebanyakan kasus, sementara semantic chunking cocok untuk dokumen kompleks.

Mulai dengan chunk_size=500 dan chunk_overlap=50 sebagai baseline, lalu ukur performanya lewat recall@k dan MRR sebelum melakukan tuning lebih lanjut. Terapkan ceklis praktis di atas pada proyek RAG kamu, dan lakukan eksperimen kecil untuk menemukan konfigurasi chunking paling pas dengan karakteristik dokumen kamu.