recursive-char (varsayılan). Önce paragraf kırılımlarında, sonra satır kırılımlarında, sonra cümle sınırlarında ( . ), sonra boşluklarda bölmeye çalışır. Her parça chunk boyut bütçesine kadar açgözlüce paketlenir. Hiçbir şey sığmadığında sadece sert karakter bölmesine geri döner. LangChain, LlamaIndex ve çoğu üretim RAG yığınında varsayılan; neredeyse her düzyazı korpus için makul bir başlangıç noktası. sentence . Cümle sınırlarında böler, asla cümle içinde değil — bütçeden kısa bile olsa cümle bütün kalır. Chunk'lar kanıt olarak alıntılanacaksa (QA, citations) recursive-char'dan daha iyi, çünkü hiçbir chunk düşünce ortasında bitmez. Cümle uzunlukları değiştiği için chunk boyutları daha değişkendir. paragraph . Her paragrafı birim olarak ele alır. Yan yana iki kısa paragraf birlikte paketlenebilir, ama uzun olan asla bölünmez. Her paragrafın tutarlı bir düşünce olduğu dokümantasyon, KB makaleleri ve iyi formatlanmış uzun form için yararlı. semantic . paragraph'ın üstüne başlık tespiti ekler: # , ## ile başlayan veya kısa tamamen büyük harfli satırlar yeni-bölüm kırılımı olarak ele alınır. Bölüm sınırlarının görsel paragraf aralığından daha önemli olduğu teknik dokümantasyon için iyi.

Bir sezgisel yöntem. İngilizce-benzeri metin için karakter / 3.8 ve CJK için karakter başına 1 token kullanıyoruz. Düzyazı için ±5-10% iyi, kod ağırlıklı veya yapılandırılmış metin için daha kötü. Neden gerçek tokenizer değil? tiktoken ~1 MB WASM, sadece chunk boyutlandırma için göndermek aşırı ağır. Downstream modelin chunk'larda sert token limiti varsa (bazılarında var, örn. cohere/embed-v3 512'de sınırlı), güvenlik marjıyla inşa et veya pipeline'ında gerçek tokenizer çalıştır. Boyutlandırma için bu yeterli. Her chunk'ın tam token sayısı RAG kalitesi için çok önemli değil — embedding modeli zaten aşırı boyutlu girdileri keser. Önemli olan tutarlılık: chunking ve downstream prompt bütçelemesi için aynı sezgisel.

JSON veya CSV gibi yapılandırılmış veriyi metin chunker ile chunklama. Chunk sınırları kayıt ortasına düşer ve embedding'ler anlamsız olur. Önce kayıt sınırlarında böl, ya da araca özgü RAG yaklaşımı kullan. Kodu düzyazı chunker ile chunklama. Kod retrieval'ı için fonksiyon sınırları önemlidir, karakter sayıları değil. Bunun için tree-sitter tabanlı chunker'lar var. Whitespace ve BOM. Yapıştırılan metin token tahminlerini bozan gizli whitespace taşıyabilir. Önemliyse yapıştırmadan önce trim ve normalize et. Gizlilik. Her şey tarayıcıda çalışır. Buraya yapıştırılan dokümanlar sayfadan asla çıkmaz; bunu yerel bir script kullanır gibi gizli veya PII içeren materyaller için kullanabilirsin.

RAG Metin Chunker

Metni RAG / embedding hazırlığı için token boyutunda chunk'lara böl. Birden fazla strateji: recursive char, sentence-aware, semantic boundaries. Yapılandırılabilir overlap. Hepsi tarayıcıda.

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

Bu ne işe yarar?

Retrieval-Augmented Generation (RAG) ve embedding tabanlı arama, ikisi de bir korpusu chunk'lara bölmeye dayanır: tek tek embed edilip vector DB'de saklanan küçük parçalar. Bölme herhangi bir AI mekanizmasından önce olur, ama retrieval'ının kalitesi çoğu insanın farkettiğinden sessizce daha fazla buna bağlı. Çok küçük chunk'lar bağlamı kaybeder; çok büyükler relevansı seyreltir; cümle ortasından kesilenler kötü retrieve edilir çünkü embedding garip bir semantik noktada konuşlanır. Bu araç bir pipeline'a karar vermeden önce chunk boyutu, overlap ve stratejiyi deneyebileceğin hızlı bir tarayıcı içi playground.

Dört strateji

recursive-char (varsayılan). Önce paragraf kırılımlarında, sonra satır kırılımlarında, sonra cümle sınırlarında (. ), sonra boşluklarda bölmeye çalışır. Her parça chunk boyut bütçesine kadar açgözlüce paketlenir. Hiçbir şey sığmadığında sadece sert karakter bölmesine geri döner. LangChain, LlamaIndex ve çoğu üretim RAG yığınında varsayılan; neredeyse her düzyazı korpus için makul bir başlangıç noktası.
sentence. Cümle sınırlarında böler, asla cümle içinde değil — bütçeden kısa bile olsa cümle bütün kalır. Chunk'lar kanıt olarak alıntılanacaksa (QA, citations) recursive-char'dan daha iyi, çünkü hiçbir chunk düşünce ortasında bitmez. Cümle uzunlukları değiştiği için chunk boyutları daha değişkendir.
paragraph. Her paragrafı birim olarak ele alır. Yan yana iki kısa paragraf birlikte paketlenebilir, ama uzun olan asla bölünmez. Her paragrafın tutarlı bir düşünce olduğu dokümantasyon, KB makaleleri ve iyi formatlanmış uzun form için yararlı.
semantic. paragraph'ın üstüne başlık tespiti ekler: #, ## ile başlayan veya kısa tamamen büyük harfli satırlar yeni-bölüm kırılımı olarak ele alınır. Bölüm sınırlarının görsel paragraf aralığından daha önemli olduğu teknik dokümantasyon için iyi.

Overlap — neden ve ne kadar

Neden. İlgili bir span tam olarak iki chunk arasındaki sınıra düşerse, her ikisi de kötü retrieve eder çünkü her biri sadece yarısına sahip. Overlap önceki chunk'un son N token'ını sonraki chunk'un önüne kopyalar, her ikisine de span'i yakalama şansı verir.
Ne kadar. Chunk boyutunun %10-20'si yaygın kural. 500-token chunk'lar için 50-100 token overlap. Varsayılan burada 50, pratikte iyi çalışır.
Ödünleşim. Daha fazla overlap = daha fazla toplam embedding (daha fazla depolama, daha fazla maliyet, daha yavaş index build, daha fazla retrieval adayı). Belirli bir nedenin yoksa %30'u aşma; retrieval'ı pek iyileştirmeden para harcarsın.

Token tahmini

Bir sezgisel yöntem. İngilizce-benzeri metin için karakter / 3.8 ve CJK için karakter başına 1 token kullanıyoruz. Düzyazı için ±5-10% iyi, kod ağırlıklı veya yapılandırılmış metin için daha kötü.
Neden gerçek tokenizer değil? tiktoken ~1 MB WASM, sadece chunk boyutlandırma için göndermek aşırı ağır. Downstream modelin chunk'larda sert token limiti varsa (bazılarında var, örn. cohere/embed-v3 512'de sınırlı), güvenlik marjıyla inşa et veya pipeline'ında gerçek tokenizer çalıştır.
Boyutlandırma için bu yeterli. Her chunk'ın tam token sayısı RAG kalitesi için çok önemli değil — embedding modeli zaten aşırı boyutlu girdileri keser. Önemli olan tutarlılık: chunking ve downstream prompt bütçelemesi için aynı sezgisel.

Yaygın tuzaklar

JSON veya CSV gibi yapılandırılmış veriyi metin chunker ile chunklama. Chunk sınırları kayıt ortasına düşer ve embedding'ler anlamsız olur. Önce kayıt sınırlarında böl, ya da araca özgü RAG yaklaşımı kullan.
Kodu düzyazı chunker ile chunklama. Kod retrieval'ı için fonksiyon sınırları önemlidir, karakter sayıları değil. Bunun için tree-sitter tabanlı chunker'lar var.
Whitespace ve BOM. Yapıştırılan metin token tahminlerini bozan gizli whitespace taşıyabilir. Önemliyse yapıştırmadan önce trim ve normalize et.
Gizlilik. Her şey tarayıcıda çalışır. Buraya yapıştırılan dokümanlar sayfadan asla çıkmaz; bunu yerel bir script kullanır gibi gizli veya PII içeren materyaller için kullanabilirsin.