recursive-char (default). Coba pecah di paragraph dulu, lalu line break, lalu batas kalimat ( . ), lalu spasi. Setiap potongan dipack secara greedy sampai budget ukuran. Hanya fallback ke pemotongan keras karakter kalau nggak ada lainnya yang muat. Default di LangChain, LlamaIndex, dan kebanyakan stack RAG produksi; titik awal masuk akal untuk hampir semua corpus prosa. sentence . Pecah di batas kalimat dan nggak pernah di dalam kalimat — bahkan kalau lebih pendek dari budget, tetap utuh. Lebih bagus dari recursive-char saat chunk akan dikutip sebagai bukti (QA, citations) karena nggak ada chunk yang berakhir di tengah pikiran. Ukuran chunk lebih bervariasi, karena panjang kalimat juga. paragraph . Perlakukan setiap paragraf sebagai unit. Dua paragraf pendek berdampingan bisa dipack bersama, tapi yang panjang nggak pernah dipecah. Berguna untuk dokumentasi, artikel KB, dan long-form terformat baik di mana setiap paragraf adalah pikiran koheren. semantic . Tambahkan deteksi heading di atas paragraph: baris mulai dengan # , ## dll., atau baris pendek all-caps, diperlakukan sebagai batas bagian baru. Bagus untuk dokumentasi teknis di mana batas seksi lebih penting daripada spasi paragraf visual.

Ini heuristik. chars / 3.8 untuk teks Inggris-ish dan 1 token per karakter untuk CJK. ±5-10% untuk prosa, lebih buruk untuk teks code-heavy atau terstruktur. Kenapa nggak tokenizer asli? tiktoken ~1 MB WASM, terlalu berat hanya untuk chunk-sizing. Kalau model downstream-mu punya batas token keras pada chunk (beberapa punya, mis. cohere/embed-v3 dibatasi 512), build dengan margin keamanan atau jalankan tokenizer asli di pipeline-mu. Untuk sizing ini cukup. Hitungan token persis per chunk nggak penting banget untuk kualitas RAG — model embedding truncate input yang kebesaran toh. Yang penting adalah konsistensi: heuristik sama untuk chunking dan untuk budgeting prompt downstream.

Jangan chunk data terstruktur (JSON, CSV) dengan text chunker. Batas chunk jatuh di tengah record dan embedding jadi nggak berarti. Pecah di batas record dulu, atau pakai pendekatan RAG spesifik tool. Jangan chunk kode dengan prose chunker. Untuk retrieval kode, batas fungsi yang penting, bukan hitungan karakter. Chunker berbasis tree-sitter ada untuk ini. Whitespace dan BOM. Teks yang ditempel bisa membawa whitespace tersembunyi yang membuyarkan estimasi token. Trim dan normalize sebelum tempel kalau penting. Privasi. Semua jalan di browser. Dokumen yang ditempel di sini tidak pernah keluar dari halaman; bisa pakai ini untuk materi rahasia atau berisi PII sama seperti pakai script lokal.

RAG Text Chunker

Pecah teks jadi chunk berukuran token untuk persiapan RAG / embeddings. Banyak strategi: recursive char, sentence-aware, semantic boundaries. Overlap bisa diatur. Semua di browser.

Paste your document

RAG (Retrieval-Augmented Generation) is a technique that pairs an LLM with an external knowledge base. Instead of relying only on the model's parametric memory, the system retrieves relevant passages at query time and concatenates them into the prompt.

The retrieval step depends on a vector store. Documents are split into chunks, each chunk gets an embedding vector, and those vectors are stored in a database that supports approximate nearest-neighbour search.

# Chunk size matters

Chunks that are too small lose context — a single sentence might not contain enough information to answer the question. Chunks that are too large dilute relevance — the embedding becomes an average of many unrelated topics, and retrieval gets noisy.

A common starting point is 500 tokens per chunk with 50 tokens of overlap. Overlap lets a chunk see a bit of context from its neighbours, which helps when a relevant span happens to fall across a chunk boundary.

# Strategy choice

Recursive character splitting is the most general: it tries paragraph breaks first, then line breaks, then sentence boundaries, then spaces. This is the default in most frameworks and works well for prose.

Sentence-aware splitting respects sentence boundaries and never breaks mid-sentence. It produces cleaner chunks for QA over articles and books, at the cost of more variable chunk sizes.

Paragraph chunking treats each paragraph as its own chunk (subject to the size limit). This is useful for structured documents like documentation or knowledge-base articles where each section is already a coherent unit.

Semantic chunking goes one step further: it tries to keep semantically related content together by respecting headings and topic boundaries, even when those don't align with paragraph breaks.

Chunk size (tokens): 500

Overlap (tokens): 50

Strategy

Buat apa ini?

RAG (Retrieval-Augmented Generation) dan pencarian berbasis embedding sama-sama bergantung pada memecah corpus jadi chunk: potongan kecil yang masing-masing di-embed dan disimpan di vector DB. Pemecahan terjadi sebelum mesin AI mana pun jalan, tapi kualitas retrieval-mu diam-diam lebih bergantung padanya daripada yang dikira kebanyakan orang. Chunk terlalu kecil kehilangan konteks; terlalu besar mengencerkan relevansi; chunk yang dipotong di tengah kalimat me-retrieve buruk karena embedding mendarat di titik semantik aneh. Tool ini playground cepat di browser untuk bereksperimen dengan ukuran, overlap, dan strategi sebelum kamu fix pipeline.

Empat strategi

recursive-char (default). Coba pecah di paragraph dulu, lalu line break, lalu batas kalimat (. ), lalu spasi. Setiap potongan dipack secara greedy sampai budget ukuran. Hanya fallback ke pemotongan keras karakter kalau nggak ada lainnya yang muat. Default di LangChain, LlamaIndex, dan kebanyakan stack RAG produksi; titik awal masuk akal untuk hampir semua corpus prosa.
sentence. Pecah di batas kalimat dan nggak pernah di dalam kalimat — bahkan kalau lebih pendek dari budget, tetap utuh. Lebih bagus dari recursive-char saat chunk akan dikutip sebagai bukti (QA, citations) karena nggak ada chunk yang berakhir di tengah pikiran. Ukuran chunk lebih bervariasi, karena panjang kalimat juga.
paragraph. Perlakukan setiap paragraf sebagai unit. Dua paragraf pendek berdampingan bisa dipack bersama, tapi yang panjang nggak pernah dipecah. Berguna untuk dokumentasi, artikel KB, dan long-form terformat baik di mana setiap paragraf adalah pikiran koheren.
semantic. Tambahkan deteksi heading di atas paragraph: baris mulai dengan #, ## dll., atau baris pendek all-caps, diperlakukan sebagai batas bagian baru. Bagus untuk dokumentasi teknis di mana batas seksi lebih penting daripada spasi paragraf visual.

Overlap — kenapa dan seberapa

Kenapa. Kalau span relevan jatuh tepat di antara dua chunk, keduanya me-retrieve buruk karena masing-masing hanya punya separuh. Overlap salin N token terakhir chunk sebelumnya ke depan chunk berikutnya, memberi keduanya kesempatan menangkap span.
Seberapa. 10-20% dari ukuran chunk adalah aturan umum. Untuk chunk 500 token, 50-100 token overlap. Default di sini 50, jalan baik dalam praktik.
Trade-off. Lebih banyak overlap = lebih banyak total embedding (lebih banyak storage, lebih banyak biaya, build index lebih lambat, lebih banyak kandidat retrieval). Jangan lebih dari 30% tanpa alasan spesifik; buang uang tanpa banyak peningkatan.

Estimasi token

Ini heuristik. chars / 3.8 untuk teks Inggris-ish dan 1 token per karakter untuk CJK. ±5-10% untuk prosa, lebih buruk untuk teks code-heavy atau terstruktur.
Kenapa nggak tokenizer asli? tiktoken ~1 MB WASM, terlalu berat hanya untuk chunk-sizing. Kalau model downstream-mu punya batas token keras pada chunk (beberapa punya, mis. cohere/embed-v3 dibatasi 512), build dengan margin keamanan atau jalankan tokenizer asli di pipeline-mu.
Untuk sizing ini cukup. Hitungan token persis per chunk nggak penting banget untuk kualitas RAG — model embedding truncate input yang kebesaran toh. Yang penting adalah konsistensi: heuristik sama untuk chunking dan untuk budgeting prompt downstream.

Jebakan umum

Jangan chunk data terstruktur (JSON, CSV) dengan text chunker. Batas chunk jatuh di tengah record dan embedding jadi nggak berarti. Pecah di batas record dulu, atau pakai pendekatan RAG spesifik tool.
Jangan chunk kode dengan prose chunker. Untuk retrieval kode, batas fungsi yang penting, bukan hitungan karakter. Chunker berbasis tree-sitter ada untuk ini.
Whitespace dan BOM. Teks yang ditempel bisa membawa whitespace tersembunyi yang membuyarkan estimasi token. Trim dan normalize sebelum tempel kalau penting.
Privasi. Semua jalan di browser. Dokumen yang ditempel di sini tidak pernah keluar dari halaman; bisa pakai ini untuk materi rahasia atau berisi PII sama seperti pakai script lokal.