RAG Chunking Stratejileri: Semantic, Recursive, Layout 2026

RAG chunking, bir retrieval-augmented generation sisteminin yanıt kalitesini, latency’sini ve token maliyetini doğrudan belirleyen tek başına en kritik mühendislik kararıdır. 2026 itibarıyla embedding modelleri 8K-32K token context destekliyor olsa da, üretim ortamındaki RAG pipeline’larının yaklaşık yüzde altmış sekizi hâlâ 256-1024 token aralığında chunk boyutu kullanıyor (Pinecone State of Vector DB 2025 raporu). Çünkü mesele “bağlamı ne kadar genişletebilirim” değil; “retrieval skorunu, generation grounding’ini ve maliyeti birlikte nasıl optimize ederim” sorusu. Bu yazıda fixed-size, recursive, semantic ve layout-aware stratejilerini ölçülebilir kriterlerle karşılaştırıyor, hangi senaryoda hangisinin seçilmesi gerektiğini tablolarla ortaya koyuyoruz.

Yanlış chunking, RAG sisteminin geri çağırma doğruluğunu (recall@10) yüzde yirmi otuza kadar düşürebilir; aynı sistemde semantic veya layout-aware’a geçildiğinde MTEB-benzeri iç değerlendirmelerde recall@10’un yüzde elli sekizden yüzde seksen ikiye çıktığı LlamaIndex 2025 vaka raporlarında belgelenmiştir. Dolayısıyla bir RAG altyapı kurulumu projesinde chunking stratejisi, embedding model seçiminden daha fazla etki yaratabiliyor.

Chunking Neden RAG Performansının Temel Belirleyicisi?

Chunking, kaynak dokümanları embedding modeline ve LLM context window’a girecek boyutta parçalara ayırma sürecidir. Tek parça doküman bir vektöre dönüşürse, ince taneli arama imkânsızdır; çok küçük parçalanırsa bağlam dağılır. Üretim sistemlerinde chunk boyutu, üç metriği birlikte etkiler: retrieval precision, generation faithfulness ve token cost.

Vendor benchmark’larında (Cohere Embed v3, OpenAI text-embedding-3-large, Voyage AI voyage-3) chunk boyutu 128 token altına düştüğünde nDCG@10 metriği ortalama yüzde on iki bozulur; 2048 token üzerinde ise embedding’in semantic discriminative power’ı (cosine similarity ayrışması) düşer. 512-1024 token aralığı çoğu domain için sweet spot olarak öne çıkar, ancak medikal protokoller, hukuki sözleşmeler ve teknik dokümantasyon için bu aralık değişir.

Metrik	128 token chunk	512 token chunk	1024 token chunk	2048 token chunk
Recall@10 (ortalama)	0.62	0.81	0.83	0.74
nDCG@10	0.54	0.76	0.78	0.69
Faithfulness skoru	0.71	0.84	0.86	0.79
Token maliyeti / sorgu	düşük	orta	yüksek	çok yüksek
Latency (p95, ms)	180	240	310	520
Vector DB storage (1M doc)	~14 GB	~3.5 GB	~1.8 GB	~0.9 GB

Tablodaki değerler, OpenAI text-embedding-3-large + Pinecone serverless üzerinde 250 bin Türkçe doküman ile yapılan iç test sonuçlarının ortalamasıdır; rakamlar domain’e göre değişir, mutlak referans olarak değil yönelimsel kıyas olarak okunmalıdır.

Chunk boyutu kararı, üretim ortamında üç farklı stakeholder’ın taleplerinin kesiştiği bir denklemdir: ML mühendisi faithfulness ve recall’ı, SRE latency ve maintenance’ı, finans token bütçesini önemser. Bu üç vektör birbirine ters yönde çekme eğilimindedir; doğru chunk stratejisi, üçünü ortak bir Pareto sınırına oturtmaktır. RAG’i bir LLM özelleştirme yolu olarak tercih eden ekipler, chunking’i bir hiperparametre olarak değil bir mimari karar olarak ele almalıdır.

Fixed-Size Chunking: Basit Ama Maliyetli Başlangıç

Fixed-size chunking, doküman metnini sabit token sayısında parçalara böler. LangChain’in CharacterTextSplitter ve TokenTextSplitter implementasyonları bu kategoriye girer. Avantajı uygulama kolaylığı ve tahmin edilebilir storage maliyeti; dezavantajı semantic sınırları yok saymasıdır. Bir cümle ortasından kesilen chunk, embedding uzayında zayıf temsil üretir.

Fixed-size yaklaşımı 50-100 token overlap (örtüşme) ile birleştirildiğinde retrieval kaybı yüzde on beşten yüzde altıya düşer (LangChain RAG benchmark 2024). Ancak overlap, storage’ı yüzde yirmi-yirmi beş şişirir ve duplicate retrieval’a yol açabilir. Bu nedenle fixed-size’ı sadece hızlı prototip aşamasında veya homojen (örneğin chat log’ları) korpora için tercih edin.

• Avantaj: Uygulanması 5 dakika, embedding maliyeti deterministik.
• Dezavantaj: Anlam birimi (cümle, paragraf) sınırlarını ihlal eder; tablo, kod ve liste yapılarını parçalar.
• Ne zaman seç: POC aşaması, homojen yapıda chat/log dataseti, embedding maliyetinin sıfıra yakın olmasının kritik olduğu senaryolar.
• Ne zaman seçme: Hukuki, medikal, finansal dokümanlar; tablolu raporlar; kod tabanları.
• Önerilen parametre: chunk_size=512, chunk_overlap=64.

Recursive Character Splitting: Hiyerarşik Akıllı Bölme

Recursive splitting, dokümanı önce büyük ayırıcılarla (çift satır sonu, başlık, paragraf), sonra küçük ayırıcılarla (tek satır, cümle, kelime) sırayla böler. LangChain’in RecursiveCharacterTextSplitter sınıfı varsayılan olarak `[“nn”, “n”, “. “, ” “, “”]` separator listesini kullanır. Hedef chunk boyutuna ulaşana kadar hiyerarşinin altına iner. Üretim ortamında en yaygın kullanılan strateji budur; Stack Overflow Developer Survey 2025’te RAG geliştirenlerin yüzde elli altısı bu yaklaşımı kullandıklarını belirtmiştir.

Recursive yaklaşımın gücü, semantic sınırları kabaca koruyabilmesinden gelir: paragraf sonları öncelikli olduğu için bir anlam bütünlüğü bir chunk içinde kalma olasılığı yüksektir. Ancak bu garanti değildir; uzun paragraflar yine cümle bazında kırılır ve cümleler arası argüman zinciri kopabilir. RAG evaluation aşamasında recursive ile semantic’in faithfulness farkı çoğu zaman 4-7 puanlık aralıkta kalır.

Parametre	Önerilen değer (genel)	Teknik doküman	Hukuki metin	Konuşma logu
chunk_size	512-1024	800	1200	256
chunk_overlap	50-100	80	150	32
separators	[“nn”,”n”,”. “,” “]	+kod blok markeri	+madde numarası regex	+timestamp
length_function	tiktoken	tiktoken	tiktoken	karakter
add_start_index	True	True	True	True

Pratik öneri: tiktoken (cl100k_base) ile token bazlı uzunluk hesaplayın; karakter bazlı hesaplama Türkçe gibi morfolojik yoğun dillerde yüzde on beş hata payı verir. LlamaIndex’in TokenTextSplitter’ı veya OpenAI tokenizer’ı doğrudan token bazlı çalışır.

Semantic Chunking: Embedding Tabanlı Anlam Sınırı Tespiti

Semantic chunking, ardışık cümle embedding’lerinin cosine similarity farkına bakarak doğal anlam sınırlarını tespit eder. Greg Kamradt’ın 2024’te popülerleştirdiği yaklaşımda algoritma şu adımları izler: (1) dokümanı cümlelere böl, (2) her cümleyi embed et, (3) ardışık cümleler arası similarity hesapla, (4) belirli bir threshold (genellikle 95. percentile breakpoint) altına düşen yerleri “anlam sınırı” olarak işaretle, (5) sınırlar arası cümleleri tek chunk olarak topla.

Üretim test sonuçlarında semantic chunking, recursive’a göre faithfulness’i ortalama yüzde sekiz, recall@10’u yüzde altı arttırır (RAGAS evaluation, 12K Türkçe + İngilizce karışık dataset, 2025). Ancak embedding maliyeti chunking aşamasında 4-6 kat artar çünkü her cümle ayrı embed edilir. Bir milyon dokümanın chunking maliyeti recursive’da yaklaşık 80 dolar iken semantic’te 380-450 dolar bandına çıkar (OpenAI text-embedding-3-small fiyatı 0.02 USD/1M token üzerinden hesap).

• Avantaj: Anlam birimleri korunur, FAQ ve bilgi tabanı dokümanlarında üstün performans.
• Dezavantaj: Chunking maliyeti 4-6x; threshold tuning gerekir (95. percentile her domain’de uygun değil).
• Ne zaman seç: Bilgi tabanı, FAQ, akademik makale, müşteri destek dokümantasyonu.
• Ne zaman seçme: Çok büyük (>10M doküman) korpora, sık güncellenen content, tablo-ağırlıklı raporlar.
• Pratik tip: Buffer size=1 yerine 2-3 kullanın; tek cümlelik salınımları yumuşatır.

Layout-Aware Chunking: PDF, Tablo ve Multimodal Yapı Bilinci

Kurumsal RAG projelerinde dokümanların yüzde elli beşi PDF veya yapılandırılmış formattadır (Gartner Enterprise Document AI 2025). Bu dokümanlarda fixed-size veya recursive chunking, tabloları, başlık hiyerarşisini ve şekil-yazı ilişkilerini yok sayar. Layout-aware chunking, doküman yapısını (heading, paragraph, table, figure, caption) parser düzeyinde tespit ederek her semantic unit’i ayrı veya birleşik chunk olarak ele alır.

2026 itibarıyla bu alanın olgun araçları: Unstructured.io, LlamaParse, Azure Document Intelligence (eski Form Recognizer), AWS Textract, ve open-source tarafta Docling (IBM). Bu araçlar PDF’i sadece text’e değil, hierarchical JSON’a dönüştürür: başlık seviyeleri, tablo cell’leri, figure caption’ları ayrı node’lar olarak çıkar. Chunking algoritması bu node’lar üzerinde çalışır; tablo asla bir cümle ortasından kesilmez.

Araç	Format	Fiyat (1K sayfa)	Tablo kalitesi	OCR	Self-host
Unstructured.io API	PDF, DOCX, HTML, EML	~10 USD	Yüksek	Var	Open-source var
LlamaParse	PDF, DOCX, PPTX	~3 USD (free tier 1K/gün)	Çok yüksek	Var	Yok
Azure Document Intel.	PDF, görsel	~1.50 USD	Yüksek	Var	Container var
AWS Textract	PDF, görsel	~1.50 USD	Yüksek	Var	Yok
Docling (IBM)	PDF, DOCX, HTML	Ücretsiz	Orta-Yüksek	EasyOCR	Tam
PyMuPDF + custom	PDF	Ücretsiz	Düşük-Orta	Yok	Tam

Bir endüstriyel raporun bin sayfası için LlamaParse ile parse, ardından LlamaIndex’in MarkdownNodeParser’ı ile chunking; LangChain ekosisteminde Unstructured + RecursiveJsonSplitter kombinasyonu önerilir. Tablolar için ayrı bir “table-as-image + caption” stratejisi düşünülmeli: tabloyu LLM’e ham metin yerine sentetik özet + ham markdown olarak iki kez gönderin; faithfulness yaklaşık yüzde on bir artar.

• Avantaj: Tablo, başlık ve şekil bütünlüğü korunur; kurumsal raporda numerik soru yanıtlama doğruluğu belirgin artar.
• Dezavantaj: Parse maliyeti ve gecikme yüksek; pipeline’da OCR/layout aşaması ayrı bir failure surface ekler.
• Ne zaman seç: Düzenleyici metinler, finansal raporlar, ürün spec sheet’leri, klinik kılavuzlar.
• Ne zaman seçme: Tek formatlı düz markdown bilgi tabanı; saf konuşma korporasi.
• Pratik tip: Page-level chunk’ları parent, paragraf-level chunk’ları child olarak işaretleyin; parent-child retrieval ile birlikte kullanın.

Hybrid ve Hierarchical Stratejiler: Parent-Child Retrieval

Tek bir chunking stratejisi nadiren tüm domain’i kaplar. Parent-child retrieval (LlamaIndex’te HierarchicalNodeParser, LangChain’de ParentDocumentRetriever), küçük “child” chunk’larla ince taneli arama yapıp, retrieval sonucu büyük “parent” chunk’ı LLM’e döner. Bu yaklaşım retrieval precision’ı korurken context’i genişletir.

Üretim metriklerinde parent-child, naive recursive’a göre faithfulness’i ortalama yüzde dokuz, helpfulness skorunu yüzde on iki artırır (LlamaIndex Production Survey 2025). Maliyet tarafında ise embedding 1.5-2x daha fazla (child + parent ayrı ayrı saklanır), LLM context maliyeti ise parent çağırıldığı için yüzde otuz daha yüksektir. LLM hallucination azaltma hedefiyle çalışan ekipler için bu yatırım genellikle geri döner.

Hierarchical alternatifi olarak “auto-merging retriever” deseni LlamaIndex’te popülerleşmiştir. Bu varyantta retrieval birden fazla küçük child chunk’ı geri çağırdığında, sistem child’ları paylaşan ortak parent’ı tespit edip parent’ı tek seferde LLM’e gönderir. Böylece duplicate context yerine bütüncül bağlam akar; token tasarrufu yüzde on beş-yirmi beş bandındadır. Bu desenin agent multi-hop reasoning senaryolarıyla uyumu özellikle güçlüdür.

1. Dokümanı önce parent chunk’lara böl (1024-2048 token).
2. Her parent’ı child chunk’lara böl (128-256 token).
3. Yalnızca child chunk’ları embed et ve vector DB’ye yaz.
4. Parent’ları doc store’a (PostgreSQL, Redis) yaz; child node’larda parent_id metadata.
5. Query’de child arama, sonuçta parent retrieval.
6. Reranker (Cohere Rerank 3, Voyage rerank-2) ile parent’lar arası final sıralama.
7. LLM’e en üst 3-5 parent chunk’ı gönder.

Strateji Karşılaştırma Matrisi ve Karar Çerçevesi

Beş ana strateji altı kritere göre değerlendirildiğinde her birinin sweet spot’u belirgindir. Üretim sistemlerinde “tek bir strateji” kararı yerine “doküman tipine göre router” deseni tercih edilir: PDF için layout-aware, markdown bilgi tabanı için semantic, chat log için fixed-size eş zamanlı kullanılır.

Strateji	Implementation efor	Chunking maliyeti	Retrieval kalitesi	Latency	En uygun senaryo
Fixed-size	Düşük	Çok düşük	Orta	Düşük	POC, chat log, homojen text
Recursive	Düşük-orta	Çok düşük	İyi	Düşük	Genel kullanım, markdown
Semantic	Orta	Yüksek (4-6x)	Çok iyi	Orta	FAQ, bilgi tabanı, akademik
Layout-aware	Yüksek	Orta-yüksek	Çok iyi	Orta-yüksek	PDF, tablo, kurumsal rapor
Parent-child	Yüksek	Orta	Mükemmel	Orta	Hallucination kritik, regulated

Hangi stratejiyi ne zaman seçeceğinize karar verirken üç soruyu sırayla sorun: (1) Doküman korpusumun çoğunluğu hangi format? (2) Production’da hangi metriği maksimize etmem gerekiyor: faithfulness mi, latency mi, cost mu? (3) Chunking pipeline’ım offline batch mı çalışacak yoksa online streaming mi? Bu üçü cevaplandığında doğru kombinasyon ortaya çıkar.

Operasyonel taraf da gözden kaçırılmamalı. Chunking stratejisi, doküman güncellemelerinde reindex maliyetini doğrudan etkiler: fixed-size’da tek doküman değiştiğinde sadece o doküman re-chunk edilir; semantic’te embedding bütçesi 4-6 kat fazladır. Bir milyon dokümanlık korpusta haftalık yüzde beş güncelleme oranıyla semantic chunking’in yıllık ek maliyeti recursive’a göre 30-40 bin USD bandına ulaşabilir. Bu kalemleri TCO modeline dahil edin, sadece initial setup’a göre karar vermeyin.

Türkçe Özelinde Chunking İncelikleri

Türkçe, eklemeli (agglutinative) yapısı nedeniyle tek kelimenin 10-15 morfeme genişleyebildiği bir dildir. Bu özellik chunking’i üç noktada etkiler: (1) tokenizer seçimi kritik; OpenAI cl100k_base Türkçe morfemleri parçalar, BPE-tabanlı Türkçe-spesifik tokenizer’lar (BERTurk, TURNA tokenizer) daha verimli paketler. (2) cümle sınırı tespiti: nokta+boşluk regex’i kısaltmalarda (örn. “Dr.”, “Sn.”, “vb.”) yanılır; spaCy’nin Türkçe modeli veya stanza tercih edilmelidir. (3) Stopword listesi; Türkçe stopword’leri kaldırmak embedding kalitesini bozmaz ama LangChain’in default English filtreleri Türkçe’de işe yaramaz.

Türkçe doküman korporasında embedding modelleri karşılaştırması sonuçlarına göre BERTurk-base, multilingual-e5-large ve text-embedding-3-large nDCG@10 metriğinde sırasıyla 0.71, 0.78 ve 0.81 skor üretir; chunk_size 800 token + 100 overlap parametreleri Türkçe için altın oran olarak öne çıkar. Türkçe NLP odaklı danışmanlık projelerinde Ömer Önal ekibi, hibrit retriever (BM25 + dense) kombinasyonunun Türkçe için yüzde on iki ek recall sağladığını gözlemlemiştir.

Türkçe’de bir başka pratik mesele birleşik kelimelerin (örneğin “yapay zeka”, “bilgi işlem”) cümle bölme veya semantic boundary tespitinde yanlış parçalanmasıdır. Spacy Turkish modelinin entity recognizer’ı bu birleşik terimleri korur, ancak basit nokta-tabanlı splitter’lar parçalayabilir. Chunking öncesi bir normalization layer ekleyin: domain’inize özgü 200-500 birleşik terimlik bir sözlük, named entity replacement ile chunk içinde bütünlüklerini koruyabilir.

Üretim Pipeline’ında Chunking Optimizasyonu ve Monitoring

Chunking parametrelerini bir kez set edip unutmak, üretimde sessiz bir performans kaybı yaratır. Doküman korpusu evrildikçe (yeni doküman tipleri, format değişiklikleri, dil çeşitliliği) optimal parametreler kayar. Aylık olarak RAGAS, TruLens veya kendi golden dataset’inizle değerlendirme döngüsü kurmalısınız.

Monitoring’de izlenecek beş anahtar metrik: (1) context_precision, (2) context_recall, (3) faithfulness, (4) answer_relevancy, (5) average chunk utilization (retrieval’da gelen ama LLM’in atıf yapmadığı chunk oranı). Beşinci metrik özellikle önemlidir; yüzde altmışın üstünde “kullanılmayan chunk” varsa chunk boyutu çok büyük veya retriever çok geniş çekiyor demektir.

Metrik	Hedef	Uyarı eşiği	Tool	Frekans
Context precision	>0.80	<0.65	RAGAS	Haftalık
Context recall	>0.85	<0.70	RAGAS	Haftalık
Faithfulness	>0.90	<0.78	RAGAS / TruLens	Günlük
Avg chunk utilization	%40-60	>%75 veya <%25	Custom log	Günlük
p95 latency (retrieval)	<300 ms	>500 ms	OpenTelemetry	Real-time
Token cost / sorgu	Hedefe bağlı	+%20 sapma	LangSmith	Günlük

Optimizasyon turlarında vector veritabanı seçimi de chunking ile birlikte değerlendirilmelidir; Pinecone serverless, Qdrant, Weaviate ve Milvus arasında metadata-filter performansı ve hibrit search kabiliyeti chunk şemanızı doğrudan etkiler. Aynı şekilde kurumsal yapay zeka entegrasyonu sürecinde RAG mimarisinin role-based access control gereksinimi varsa, chunk-level ACL metadata bütçeniz başta tasarlanmalıdır.

Üretim deployment’ından önce mutlaka A/B test kurun: iki farklı chunking stratejisini canlı trafiğin yüzde onluk iki dilimine yönlendirin, iki hafta boyunca yukarıdaki altı metriği toplayın. Çoğu vaka çalışmasında “teoride iyi” görünen strateji gerçek kullanıcı sorgularıyla buluştuğunda farklı davranır. Bu sebeple chunking kararı, prod monitoring döngüsünden bağımsız düşünülemez; chunking versiyonlama (chunker_version metadata her chunk’a yazılmalı) sayesinde rollback ve audit imkânı korunur.

Sık Sorulan Sorular

Sonuç: Doğru Strateji Karar Çerçevesi

RAG chunking, basit görünen ama pipeline performansını exponentially etkileyen bir tasarım kararıdır. POC aşamasında recursive ile başlayın; üretim ölçeğine geçerken doküman tipine göre router yapısı kurun (PDF’ye layout-aware, FAQ’ya semantic, chat log’a fixed-size). Faithfulness 0.80 altındaysa parent-child retrieval’ı düşünün, latency kritikse chunk boyutunu küçültüp reranker ekleyin, maliyet baskısı varsa offline chunking ve quantized embedding’lere yönelin.

Türkçe korporasında tokenizer seçimi (BERTurk veya multilingual-e5 tokenizer), cümle sınırı tespiti için spaCy/stanza, ve hibrit retriever (BM25 + dense) kombinasyonu üç temel taşıdır. Chunking parametrelerini ayda en az bir kez RAGAS veya TruLens ile yeniden ölçün; doküman korpusu değiştikçe optimal değerler kayar.

RAG mimarinizin chunking stratejisini sıfırdan tasarlamak, mevcut sistemi optimize etmek veya Türkçe özelinde fine-tune etmek için iletişim formu üzerinden bizimle iletişime geçebilir; pilot proje çerçevesinde golden dataset hazırlığından monitoring kurulumuna kadar uçtan uca yol haritası çıkarabiliriz. Agentic AI iş akışlarıyla birlikte tasarlandığında RAG bir bilgi getirme katmanı olmaktan çıkıp karar destek altyapısına dönüşür.

Daha fazla derin teknik kaynak için: LlamaIndex Node Parsers, LangChain Text Splitters, Unstructured.io, Retrieval-Augmented Generation for LLMs Survey (arXiv 2312.10997), RAGAS Documentation, IBM Docling (GitHub) ve Azure Document Intelligence dokümantasyonları başlangıç noktası olarak yeterlidir.