Berapa ukuran chunk terbaik untuk RAG?

Tidak ada jawaban universal, tetapi titik awal yang baik adalah 400 hingga 512 token dengan overlap 10 hingga 20%. Kemudian sesuaikan dengan jenis kueri Anda: 128 hingga 256 token untuk pencarian fakta yang presisi, dan 512 hingga 1024 token untuk kueri analitik atau peringkasan. Bandingkan beberapa ukuran terhadap pertanyaan Anda sendiri alih-alih mempercayai satu default saja.

Berapa banyak overlap yang sebaiknya dimiliki chunk?

Sepuluh hingga dua puluh persen dari ukuran chunk — sekitar 50 hingga 100 token pada chunk 500 token. Overlap mencegah makna terpotong di batas; terlalu sedikit memecah konteks di titik pembagian, dan terlalu banyak menggembungkan indeks serta memicu retrieval yang nyaris duplikat. NVIDIA menemukan sekitar 15% optimal pada dokumen keuangan.

Apakah semantic chunking lebih baik daripada fixed-size?

Tidak secara konsisten. Semantic chunking mengelompokkan kalimat berdasarkan topik, yang terdengar lebih baik, tetapi benchmark menunjukkan keunggulannya atas recursive atau fixed-size chunking tidak konsisten dan sering tidak sepadan dengan biaya komputasi embedding tambahan. Fixed dan recursive chunking tetap menjadi baseline yang kuat dan murah — mulailah dari sana dan beralih ke semantic hanya jika evaluasi Anda menunjukkan peningkatan yang nyata.

Apa itu late chunking dan kapan sebaiknya digunakan?

Late chunking meng-embed seluruh dokumen terlebih dahulu dengan model embedding long-context, lalu mem-pool embedding token ke dalam chunk — sehingga vektor setiap chunk membawa konteks dari seluruh dokumen, bukan hanya teksnya sendiri. Gunakan untuk dokumen panjang dengan dependensi jarak jauh, ketika sebuah bagian baru masuk akal jika ada konteks sebelumnya.

Apakah contextual retrieval benar-benar meningkatkan akurasi?

Ya, secara terukur. Anthropic melaporkan bahwa menambahkan catatan konteks hasil LLM ke setiap chunk menurunkan kegagalan retrieval top-20 sebesar 35% dengan contextual embedding, 49% bila dikombinasikan dengan contextual BM25, dan 67% saat reranking ditambahkan — dengan biaya sekitar $1,02 per juta token dokumen menggunakan prompt caching. Paling sepadan untuk korpus berisiko tinggi yang melewatkan satu bagian saja sudah mahal.

Apa itu parent-document (small-to-big) retrieval?

Ini memisahkan cara Anda mencocokkan dari apa yang Anda kembalikan. Anda mengindeks chunk anak yang kecil untuk pencocokan presisi, tetapi ketika satu chunk cocok, Anda menyerahkan bagian induk yang lebih besar ke model agar ia memiliki konteks di sekitarnya. Dengan begitu Anda mendapatkan recall dari chunk kecil sekaligus koherensi dari chunk besar tanpa mengorbankan keduanya.

Strategi chunking mana yang sebaiknya saya mulai?

Recursive chunking sekitar 500 token dengan overlap 15%. Ia menghormati batas alami, murah, dan menjadi baseline yang kuat untuk sebagian besar konten. Tambahkan structure-aware splitting untuk PDF dan manual, parent-document retrieval ketika jawaban memerlukan lebih banyak konteks, dan contextual retrieval hanya bila taruhannya sepadan dengan biaya tambahan.

← Resources

By Priya Shah — Senior Engineer, RAG + Knowledge · 2026-05-22 · TUTORIAL

Strategi Chunking untuk RAG: Ukuran, Overlap, dan Apa yang Benar-Benar Bekerja

Chunking sudah menentukan batas atas kualitas RAG bahkan sebelum retrieval dijalankan. Panduan ini membandingkan enam strategi yang mendominasi praktik, memberikan angka ukuran dan overlap yang konkret, serta menjelaskan strategi mana yang cocok untuk jenis kueri mana.

Mengapa chunking menentukan kualitas RAG

Chunk adalah unit yang sebenarnya diambil oleh retriever Anda, sehingga batas chunk menentukan batas atas seluruh proses di hilirnya. Jika chunk terlalu kecil, setiap embedding tidak memiliki cukup sinyal untuk ditemukan secara andal; jika terlalu besar, sinyal dari bagian yang relevan ikut dirata-ratakan sehingga vektor menjadi encer dan tidak lagi cocok dengan kueri. Salah dalam chunking, tidak ada reranker atau model yang lebih besar yang bisa menyelamatkan recall — bagian yang tepat memang tidak pernah terambil. Itulah sebabnya chunking, bukan pemilihan model, biasanya menjadi hal pertama yang perlu di-tune.

Enam strategi yang mendominasi praktik

Praktik saat ini mengelompok menjadi enam pendekatan:

Fixed-size: rentang token/karakter yang sama besar dengan overlap. Paling tua, paling murah, dapat direproduksi — dan ternyata baseline yang sangat kuat.
Recursive: pisahkan berdasarkan prioritas separator (paragraf → baris → kalimat) agar tetap di bawah batas ukuran sambil menghormati batas alami. Default yang direkomendasikan.
Semantic: kelompokkan kalimat berdasarkan kemiripan embedding sehingga setiap chunk berisi satu topik. Keunggulannya dibanding recursive tidak konsisten dan menuntut komputasi embedding tambahan.
Structure-aware: pisahkan mengikuti struktur dokumen (heading, bagian, halaman, Markdown). Paling baik untuk PDF, manual, dan dokumen keuangan.
Late chunking: embed dulu seluruh dokumen dengan model long-context, lalu pool embedding token ke dalam chunk — sehingga setiap chunk membawa konteks global.
Contextual retrieval: tambahkan blurb konteks hasil LLM di depan setiap chunk sebelum pengindeksan.

Mulailah dengan recursive; beralih ke yang lain ketika jenis dokumen atau kueri Anda menuntutnya.

Ukuran chunk dan overlap: angka konkret

Tidak ada ukuran terbaik yang berlaku universal, tetapi ada titik awal yang baik. Mulailah di kisaran 400–512 token dengan overlap 10–20% (kira-kira 50–100 token pada chunk 500 token). Lalu sesuaikan ukuran dengan jenis kueri: chunk kecil (128–256 token) lebih cocok untuk pencarian fakta dan kata kunci yang presisi, sedangkan chunk lebih besar (512–1024 token) lebih cocok untuk kueri analitik dan peringkasan yang mengutamakan alur naratif.

Overlap mencegah makna terpotong di batas — terlalu sedikit memecah konteks, terlalu banyak menggembungkan indeks dan menduplikasi retrieval. Benchmark NVIDIA menemukan overlap sekitar 15% optimal pada dokumen keuangan, dan chunking tingkat halaman memberikan akurasi tertinggi dan paling konsisten di seluruh korpus campuran, dengan kueri faktoid memuncak pada 256–512 token dan kueri analitik pada 1024+.

Lanjutan: contextual retrieval dan late chunking

Dua teknik yang lebih baru menyerang masalah yang sama — sebuah chunk yang berbunyi "revenue increased 15%" tidak berguna jika Anda tidak tahu perusahaan atau kuartal mana yang dimaksud.

Contextual Retrieval dari Anthropic menambahkan catatan konteks 50–100 token hasil LLM di depan setiap chunk sebelum embedding maupun pengindeksan BM25. Diukur terhadap tingkat kegagalan top-20 baseline sebesar 5,7%, contextual embedding menurunkan kegagalan 35%, penambahan contextual BM25 menurunkannya 49%, dan penambahan reranking menurunkannya 67% — dengan biaya sekitar $1,02 per juta token dokumen menggunakan prompt caching.

Late chunking dari Jina membalik pipeline: embed dokumen utuh dengan model long-context (hingga ~8.192 token), lalu pool embedding token yang sudah terkontekstualisasi ke dalam chunk, sehingga embedding setiap chunk sudah membawa konteks lintas-chunk. Gunakan untuk dokumen panjang dengan dependensi jarak jauh.

Retrieval dokumen induk dan metadata

Dua penyempurnaan ini hampir selalu memberi hasil. Parent-document ("small-to-big") retrieval memisahkan granularitas retrieval dari proses generasi: indeks chunk anak yang kecil (≈100–500 token) untuk pencocokan presisi, tetapi kembalikan bagian induk yang lebih besar (≈500–2.000 token) ke model agar ia memiliki konteks di sekitarnya. Lalu pengayaan metadata — melampirkan sumber, heading bagian, nomor halaman, dan timestamp pada setiap chunk — meningkatkan filtering, memungkinkan sitasi, dan menaikkan presisi retrieval secara independen dari ukuran chunk.

Memilih — dan men-tune — di osFoundry

Panduan keputusan singkat: recursive adalah default yang aman; structure-aware atau tingkat halaman untuk dokumen terstruktur; semantic untuk prosa yang padat topik; late chunking untuk dokumen panjang dengan embedder long-context; contextual retrieval untuk korpus berisiko tinggi yang kehilangan konteksnya mahal; parent-document saat Anda butuh presisi sekaligus konteks.

osFoundry memperlakukan semua ini sebagai konfigurasi, bukan kode. Auto-chunking hadir dengan default recursive yang masuk akal, dan pipeline RAG kustom memungkinkan Anda men-tune ukuran, overlap, dan strategi per knowledge base, dengan reranking dan parent-document retrieval sebagai toggle stage pipeline. Karena stage-nya dapat dikonfigurasi, Anda bisa meng-A/B-kan setelan chunking terhadap distribusi kueri Anda sendiri — faktoid versus analitik — sambil menjaga sisa stack tetap tidak berubah, dan inilah persisnya alur kerja parameter yang dapat di-tune seperti yang direkomendasikan penelitian.

Frequently asked questions

Berapa ukuran chunk terbaik untuk RAG?: Tidak ada jawaban universal, tetapi titik awal yang baik adalah 400 hingga 512 token dengan overlap 10 hingga 20%. Kemudian sesuaikan dengan jenis kueri Anda: 128 hingga 256 token untuk pencarian fakta yang presisi, dan 512 hingga 1024 token untuk kueri analitik atau peringkasan. Bandingkan beberapa ukuran terhadap pertanyaan Anda sendiri alih-alih mempercayai satu default saja.
Berapa banyak overlap yang sebaiknya dimiliki chunk?: Sepuluh hingga dua puluh persen dari ukuran chunk — sekitar 50 hingga 100 token pada chunk 500 token. Overlap mencegah makna terpotong di batas; terlalu sedikit memecah konteks di titik pembagian, dan terlalu banyak menggembungkan indeks serta memicu retrieval yang nyaris duplikat. NVIDIA menemukan sekitar 15% optimal pada dokumen keuangan.
Apakah semantic chunking lebih baik daripada fixed-size?: Tidak secara konsisten. Semantic chunking mengelompokkan kalimat berdasarkan topik, yang terdengar lebih baik, tetapi benchmark menunjukkan keunggulannya atas recursive atau fixed-size chunking tidak konsisten dan sering tidak sepadan dengan biaya komputasi embedding tambahan. Fixed dan recursive chunking tetap menjadi baseline yang kuat dan murah — mulailah dari sana dan beralih ke semantic hanya jika evaluasi Anda menunjukkan peningkatan yang nyata.
Apa itu late chunking dan kapan sebaiknya digunakan?: Late chunking meng-embed seluruh dokumen terlebih dahulu dengan model embedding long-context, lalu mem-pool embedding token ke dalam chunk — sehingga vektor setiap chunk membawa konteks dari seluruh dokumen, bukan hanya teksnya sendiri. Gunakan untuk dokumen panjang dengan dependensi jarak jauh, ketika sebuah bagian baru masuk akal jika ada konteks sebelumnya.
Apakah contextual retrieval benar-benar meningkatkan akurasi?: Ya, secara terukur. Anthropic melaporkan bahwa menambahkan catatan konteks hasil LLM ke setiap chunk menurunkan kegagalan retrieval top-20 sebesar 35% dengan contextual embedding, 49% bila dikombinasikan dengan contextual BM25, dan 67% saat reranking ditambahkan — dengan biaya sekitar $1,02 per juta token dokumen menggunakan prompt caching. Paling sepadan untuk korpus berisiko tinggi yang melewatkan satu bagian saja sudah mahal.
Apa itu parent-document (small-to-big) retrieval?: Ini memisahkan cara Anda mencocokkan dari apa yang Anda kembalikan. Anda mengindeks chunk anak yang kecil untuk pencocokan presisi, tetapi ketika satu chunk cocok, Anda menyerahkan bagian induk yang lebih besar ke model agar ia memiliki konteks di sekitarnya. Dengan begitu Anda mendapatkan recall dari chunk kecil sekaligus koherensi dari chunk besar tanpa mengorbankan keduanya.
Strategi chunking mana yang sebaiknya saya mulai?: Recursive chunking sekitar 500 token dengan overlap 15%. Ia menghormati batas alami, murah, dan menjadi baseline yang kuat untuk sebagian besar konten. Tambahkan structure-aware splitting untuk PDF dan manual, parent-document retrieval ketika jawaban memerlukan lebih banyak konteks, dan contextual retrieval hanya bila taruhannya sepadan dengan biaya tambahan.