# Chunking Stratejileri: RAG'de Belge Bölümleme En İyi Uygulamaları > Source: https://sukruyusufkaya.com/blog/chunking-stratejileri > Updated: 2026-07-15T04:57:59.557Z > Type: blog > Category: yapay-zeka **TLDR:** Chunking stratejileri nelerdir? RAG'de belge bölümleme için chunk boyutu, overlap, semantik chunking ve yapıya duyarlı yöntemlerin en iyi uygulamaları rehberi. Chunking stratejileri nelerdir ve RAG'de belge bölümleme neden bu kadar belirleyicidir? Chunking (belge bölümleme), bir RAG sisteminde belgeleri embedding'lenip vektör veritabanında aranacak parçalara (chunk) ayırma işlemidir; ve bu parçaların boyutu, sınırı ve örtüşmesi, doğru bilginin bulunup bulunamayacağını doğrudan belirler. Kısacası chunking, RAG kalitesinin görünmeyen ama en belirleyici temelidir. Sezgiye aykırı bir gerçekle başlayalım: bir RAG sisteminde yanıt kalitesi çoğu zaman modelden değil, belgelerin nasıl bölündüğünden gelir. Çünkü getirme (retrieval) bütün belge üzerinde değil, chunk düzeyinde çalışır; sistem her zaman bir parça getirir, belgenin tamamını değil. Parça yanlış kesilmişse, en pahalı model bile doğru cevabı üretemez. Bu rehberde chunking neden RAG'in kalbindedir, chunk boyutu ve overlap kararı nasıl verilir, hangi chunking stratejileri vardır (sabit boyut, cümle/paragraf, özyinelemeli, belge yapısına duyarlı, semantik chunking), metadata ve bağlam nasıl korunur, tablo/kod/PDF gibi zor içerikler nasıl bölünür, chunk kalitesi nasıl ölçülür, embedding ile ilişkisi nedir, Türkçe metinde nelere dikkat edilir, doğru strateji nasıl seçilir ve yaygın hatalar nelerdir sorularını bir AI mühendisi ve danışman titizliğiyle ele alıyoruz. RAG kavramının temeline hâkim değilseniz önce RAG nedir, uçtan uca kurulum için RAG mimarisi nasıl kurulur yazılarını okumanız faydalı olur. ## Chunking Neden RAG'de Belge Bölümlemenin Kalbidir? Chunking'in neden bu kadar önemli olduğunu anlamak için, bir RAG sisteminde bilginin nasıl aktığını hatırlamak gerekir. Belgeleriniz parçalara bölünür, her parça bir embedding vektörüne çevrilir ve bir vektör veritabanına yazılır. Kullanıcı soru sorduğunda, sistem sorunun vektörüne anlamca en yakın parçaları bulur ve yalnızca bu parçaları modele bağlam olarak verir. Yani model, yalnızca kendisine getirilen chunk kadar iyi cevap verebilir. Bu mekanizmayı ayrıntısıyla embedding nedir ve vektör veritabanı nedir yazılarında ele alıyoruz. Bu akışın kritik sonucu şudur: chunking, modelin göreceği bilginin sınırını çizer. Bir parça çok geniş kesilmişse, doğru cümlenin yanına alakasız içerik gelir ve model gürültüyle boğulur; çok dar kesilmişse, kritik bağlam başka bir parçada kalır ve doğru cevap eksik olur. Getirme parça düzeyinde çalıştığı için, belge bölümleme kararı doğrudan yanıt kalitesine yansır. Bu yüzden deneyimli ekipler arasında yaygın bir gözlem vardır: RAG başarısızlıklarının büyük kısmı modelden değil, kötü chunking'den kaynaklanır. Bir benzetme yardımcı olur. Bir kütüphaneyi düşünün: kitapları rastgele elli sayfalık tomarlar halinde yırtıp raflara koysanız, bir okuyucu belirli bir konuyu aradığında ya konunun ortasından başlayan yarım bir tomar bulur ya da aradığı cümle iki tomara bölünmüş olur. Oysa kitapları bölüm ve alt başlık sınırlarından ayırıp her tomarın üstüne hangi kitaptan ve hangi bölümden olduğunu yazsanız, arama çok daha isabetli olur. Chunking tam olarak bu "anlamlı yerden bölme ve etiketleme" işidir; ve bir RAG sisteminin arama kalitesi doğrudan bu işin kalitesine bağlıdır. Chunking'in sessiz gücü, tam da görünmez olmasından gelir. Kullanıcı yalnızca nihai yanıtı görür; belgelerin nasıl bölündüğünü göremez. Bu yüzden ekipler dikkatlerini görünür katmana — modele ve prompta — yoğunlaştırır, oysa kalite büyük ölçüde görünmez katmandan, yani chunking ve getirmeden gelir. Bu rehberin temel tezi şudur: chunking'i bir teknik detay değil, RAG tasarımının merkezi bir kararı olarak ele almak, güvenilir bir sistemin ön koşuludur. Chunking kavramının genel çerçevesi için chunking nedir yazısına da bakabilirsiniz; bu rehber ise üretim odaklı stratejilere ve en iyi uygulamalara odaklanıyor. Yaygın bir yanılgı, chunking'i "belgeyi parçalara böl" gibi mekanik bir ön işlem adımı olarak görmektir. Gerçekte chunking, sisteminizin hangi soruları iyi yanıtlayabileceğini önceden belirleyen stratejik bir karardır. Bir parçanın sınırı, o bilginin bulunabilirliğini doğrudan etkiler. Bu yüzden chunking, veri hazırlığından hemen sonra, embedding modeli seçilmeden önce bilinçle tasarlanmalıdır. ## Chunk Boyutu ve Overlap Kararı Nasıl Verilir? Her chunking stratejisinin merkezinde iki hiperparametre vardır: chunk boyutu ve overlap (örtüşme). Bu iki karar, diğer tüm strateji tercihlerinden önce anlaşılmalıdır çünkü hangi yöntemi seçerseniz seçin, sonunda "parça ne kadar büyük olmalı" ve "komşu parçalar ne kadar örtüşmeli" sorularını yanıtlarsınız. Chunk boyutunun temel gerilimi şudur: çok büyük parçalar fazla ve alakasız bağlam taşır. Bir parça bütün bir bölümü kapsıyorsa, kullanıcının sorusuyla ilgili tek bir cümlenin yanında sayfalarca ilgisiz metin gelir; bu hem modelin dikkatini dağıtır hem token maliyetini artırır hem de getirme isabetini düşürür çünkü parçanın embedding'i çok sayıda konuyu ortalayarak bulanıklaşır. Çok küçük parçalar ise ters soruna yol açar: tek bir cümle veya birkaç kelime, anlamı taşımaya yetmez. "Bu koşul yalnızca kurumsal müşteriler için geçerlidir" cümlesi, hangi koşuldan bahsedildiği önceki parçada kaldıysa tek başına işe yaramaz. Doğru chunk boyutu, bu iki uç arasında, tek bir tipik soruya kendi kendine yeten bir yanıt taşıyacak büyüklüktür. Peki doğru chunk boyutu kaçtır? Dürüst cevap: evrensel bir sayı yoktur. Doğru boyut belge türüne, soru desenine ve embedding modeline bağlıdır. Pratik bir başlangıç noktası, birkaç yüz token'lık orta boy parçalardır; illüstratif olarak 300-500 token aralığı yaygın bir başlangıçtır, ancak bunu kendi verinizle ölçmeniz şarttır. Kısa ve olgusal sorular (bir tarih, bir tanım, bir sayı) daha küçük ve odaklı parçalardan; kavramsal ve çok cümleli bağlam gerektiren sorular daha büyük parçalardan fayda görür. Token kavramının ne olduğunu ve boyut ölçümünü token nedir yazısında ele alıyoruz. Overlap ise ikinci kritik karardır. Overlap, ardışık chunk'ların bir miktar ortak metin paylaşmasıdır; amacı, bir cümlenin veya fikrin tam parça sınırında ikiye bölünüp bağlamının kopmasını önlemektir. Örtüşme olmadan, kritik bir cümle iki parçanın tam ortasına düşerse, her iki parça da o cümleyi eksik taşır ve getirme onu kaçırabilir. Pratik bir aralık, chunk boyutunun yaklaşık yüzde 10-20'si kadar örtüşmedir; yine illüstratif bir değerdir ve kendi içeriğinizle ölçülmelidir. Çok az overlap sınır bağlamını kaybetme riski taşır; çok fazla overlap ise gereksiz tekrar, artan depolama ve aynı bilginin birden çok parçadan gelmesi (mükerrer getirme) sonucu doğurur. Chunk boyutu ile overlap arasında ayrıca bir etkileşim vardır ve bu sık gözden kaçar. Küçük chunk boyutu seçtiğinizde, sınıra denk gelen bir cümlenin bağlamını kaybetme riski görece artar çünkü toplam sınır sayısı fazladır; bu durumda oransal olarak biraz daha yüksek overlap mantıklı olabilir. Büyük chunk boyutu seçtiğinizde ise sınır sayısı azalır ve her parça zaten geniş bir bağlam taşıdığı için daha düşük overlap yeterli kalır. Yani bu iki hiperparametre bağımsız değil, birbirine bağlı iki kadran gibidir; birini değiştirdiğinizde diğerini yeniden düşünmek gerekir. Bu bağımlılık, neden "tek doğru sayı" aramanın yanıltıcı olduğunu bir kez daha gösterir. Kritik olan nokta şudur: chunk boyutu ve overlap birer dogma değil, evaluation ile ayarlanacak hiperparametrelerdir. En doğru değerleri, birkaç seçeneği aynı altın soru kümesiyle test edip getirme metriklerini karşılaştırarak bulursunuz. Bir sonraki bölümlerde ele alacağımız daha akıllı stratejiler (yapıya duyarlı, semantik), sınırları anlamlı yerlerden geçirdikleri için bu iki hiperparametreyi kısmen otomatikleştirir; ama temel gerilim her zaman aynı kalır. ## Chunking Stratejileri Nelerdir? Strateji Strateji İnceleme Şimdi rehberin kalbine geliyoruz: başlıca chunking stratejileri ve her birinin ne zaman parladığı. Bu stratejiler bir olgunluk merdiveni gibi düşünülebilir; en basitinden en gelişmişine doğru ilerlerken hem kalite hem maliyet artar. Doğru seçim, en gelişmiş olanı değil, belgelerinize ve sorularınıza en uygun olanıdır. ### Sabit Boyutlu Chunking En basit ve en yaygın başlangıç stratejisi sabit boyutlu chunking'dir: belge, belirli bir karakter veya token sayısına göre eşit parçalara bölünür (genellikle bir miktar overlap ile). Gücü, basitliği ve öngörülebilirliğidir; kurulumu hızlıdır, her belgeye aynı şekilde uygulanır ve parça boyutları tahmin edilebilir kalır. Bu, bir prototipi hızla ayağa kaldırmak için makul bir başlangıçtır. Zayıflığı ise anlam sınırlarını görmezden gelmesidir. Sabit boyutlu chunking, bir cümlenin, paragrafın veya tablonun tam ortasından kesebilir çünkü tek kriteri karakter/token sayısıdır, içeriğin anlamı değil. Bu yüzden sabit boyutlu chunking, iyi bir taban çizgisi kurmak için uygundur ama üretim kalitesinde bir RAG sistemi için genellikle yetersiz kalır. Overlap eklemek bu zayıflığı hafifletir ama tamamen çözmez; sınırlar hâlâ anlamdan bağımsız yerlerden geçer. ### Cümle ve Paragraf Tabanlı Chunking Bir adım ileri strateji, belgeyi karakter sayısına göre değil, doğal dil birimlerine — cümlelere veya paragraflara — göre bölmektir. Cümle tabanlı chunking, metni cümle sınırlarından ayırır ve birkaç cümleyi bir chunk'ta gruplar; paragraf tabanlı chunking ise paragrafı doğal bir anlam birimi olarak alır. Bu yaklaşımlar, en azından bir cümleyi ortadan kesme sorununu ortadan kaldırır ve parçaların dilbilgisel olarak bütün kalmasını sağlar. Cümle ve paragraf tabanlı chunking, kısa ve orta uzunlukta, düzenli paragraflardan oluşan metinlerde (makaleler, açıklama metinleri, sıkça sorulan sorular) iyi çalışır. Zorluğu, paragraf uzunluklarının çok değişken olabilmesidir: bazı paragraflar tek cümlelik, bazıları bir sayfa uzunluğunda olabilir; bu da parça boyutlarının kontrolsüz dalgalanmasına yol açar. Bu yüzden pratikte cümle/paragraf sınırları, bir boyut hedefiyle birleştirilir — ki bu da bizi bir sonraki stratejiye, özyinelemeli chunking'e götürür. ### Özyinelemeli (Recursive) Chunking Özyinelemeli chunking, sabit boyutun öngörülebilirliğiyle doğal sınırların anlam bütünlüğünü birleştiren zarif bir stratejidir ve birçok RAG hattında pratik bir varsayılan başlangıç noktasıdır. Mantığı şudur: belge, bir sınırlayıcı hiyerarşisine göre kademeli olarak bölünür. Önce en büyük doğal sınırdan (örneğin bölümler) ayrılmaya çalışılır; ortaya çıkan bir parça hedeflenen chunk boyutundan hâlâ büyükse, bir sonraki daha küçük sınırlayıcıya inilir (paragraflar), sonra gerekirse cümlelere, en son çare olarak kelimelere. Bu kademeli yaklaşımın güzelliği, parçaları mümkün olduğunca anlamlı sınırlarda kesmesi ama boyut sınırını da aşmamasıdır. Bir paragraf hedef boyuta sığıyorsa bütün bırakılır; sığmıyorsa cümlelerden bölünür ama yine de anlamlı bir yerden. Özyinelemeli chunking, çoğu yapılandırılmış ve yarı yapılandırılmış belgede sabit boyuttan belirgin biçimde daha iyi sonuç verir ve kurulum karmaşıklığı görece düşüktür; bu yüzden "nereden başlamalıyım" diyen ekipler için sık önerilen ilk stratejidir. ### Belge Yapısına Duyarlı Chunking Belgeler nadiren biçimsiz metin yığınlarıdır; başlıklar, alt başlıklar, bölümler, listeler, tablolar ve hiyerarşik bir yapı taşırlar. Belge yapısına duyarlı chunking (structure-aware / document-aware chunking), bu yapıyı doğrudan kullanır: parçaları belgenin mantıksal birimlerine göre keser ve her parçaya ait olduğu başlık hiyerarşisini bağlam olarak taşır. Böylece "Ödeme Koşulları > İade" başlığı altındaki bir parça, hangi bölüme ait olduğunu bilir. Bu strateji, kurumsal dokümantasyon, teknik kılavuzlar, sözleşmeler ve iyi biçimlendirilmiş içerikte çoğu zaman en iyi sonucu verir çünkü anlamsal bütünlüğü korur ve başlık bağlamıyla zenginleştirir. Markdown, HTML veya yapılandırılmış PDF gibi formatlarda başlık işaretleri açıkça bulunduğu için yapıya duyarlı chunking uygulaması kolaylaşır. Zorluğu, yapısı bozuk veya hiç biçimlendirilmemiş belgelerde işe yaramamasıdır; böyle içerikte önce yapı çıkarımı gerekir, bu da ek bir işlem katmanıdır. ### Semantik Chunking En gelişmiş stratejilerden biri olan semantik chunking, sınırları belge yapısına değil, anlamın kendisine göre belirler. Yöntem şöyle çalışır: metin önce cümlelere bölünür, her cümlenin embedding'i hesaplanır ve ardışık cümleler arasındaki anlamsal benzerlik ölçülür. Benzerlik yüksek kaldığı sürece cümleler aynı parçada gruplanır; benzerlik belirgin biçimde düştüğünde — yani konu değiştiğinde — bir parça sınırı çizilir. Sonuç, her biri tek bir fikre odaklanan, anlamsal olarak tutarlı parçalardır. Semantik chunking, özellikle tutarsız yapıya sahip, başlık sınırları belirsiz veya tek belge içinde birçok konu barındıran metinlerde değer kazanır; çünkü yapıya duyarlı chunking'in dayandığı biçimsel işaretler burada güvenilmezdir, ama anlam hâlâ oradadır. Bedeli, indeksleme sırasında her cümle için ek embedding hesaplaması ve dolayısıyla daha yüksek hesaplama maliyeti ile daha yavaş indekslemedir. Bu yüzden semantik chunking, bir varsayılan değil, yapıya duyarlı chunking'in yetersiz kaldığı kanıtlandığında başvurulacak bir strateji olarak konumlanmalıdır. Anlamsal benzerliğin nasıl ölçüldüğünü semantik arama nedir yazısında ele alıyoruz. Bu beş strateji birbirinin rakibi değil, bir araç kutusudur. Olgun bir RAG sistemi, farklı belge tiplerine farklı stratejiler uygulayabilir: kurumsal kılavuzlara yapıya duyarlı, dağınık e-postalara semantik chunking, basit metin dosyalarına özyinelemeli. Doğru yaklaşım, tek bir strateji seçmek değil, belge portföyünüzü tanımak ve her tür için en uygun bölümlemeyi seçmektir. ## Metadata ve Bağlam Koruma Chunking'de Nasıl Yapılır? Chunking'in çoğu zaman ihmal edilen ama getirme kalitesini belirgin biçimde artıran boyutu, metadata ve bağlam korumadır. Bir parçayı belgeden koparıp tek başına vektör uzayına attığınızda, o parça bağlamının çoğunu kaybeder: hangi belgeden geldiğini, hangi bölümün altında olduğunu, ne zaman yazıldığını ve kimin yetkisinde olduğunu bilmez. İyi bir chunking stratejisi, bu bağlamı parçayla birlikte korur. Metadata zenginleştirmesi, her chunk'a yapılandırılmış bilgi eklemektir: belge başlığı, bölüm ve alt başlık, tarih, yazar, kaynak, dil, gizlilik seviyesi ve erişim yetkisi. Bu metadata üç işe birden yarar. Birincisi getirmeyi güçlendirir: sistem "yalnızca son bir yıla ait belgelerden getir" veya "yalnızca bu kullanıcının yetkili olduğu belgelerden getir" gibi filtreler uygulayabilir. İkincisi kaynak göstermeyi mümkün kılar: model, yanıtını hangi belgeye ve bölüme dayandırdığını gösterebilir. Üçüncüsü güvenliği ve KVKK uyumunu destekler; erişim kontrolü ve denetim için gerekli bilgi baştan parçayla birlikte taşınır. KVKK bağlamını KVKK nedir yazısında ele alıyoruz. Bağlam koruma ise metadatanın ötesine geçer. İzole bir chunk, çoğu zaman kendi içinde eksik bir bağlam taşır: "Bu oran %20'ye yükseltildi" cümlesi, hangi orandan bahsedildiği başlıkta kaldıysa anlamsızdır. Bu sorunu çözmek için birkaç güçlü teknik vardır. Birincisi, her parçaya belgedeki yerini açıklayan kısa bir bağlamsal başlık eklemektir (örneğin parçanın başına "Bu bölüm, 2026 fiyatlandırma politikasının iade koşullarını açıklar" gibi bir cümle). İkincisi, başlık hiyerarşisini parçaya gömmektir: parça, ait olduğu tüm üst başlıkları taşır. Üçüncüsü, "küçük getir, büyük besle" desenidir: küçük ve hassas parçalarla arama yapılır, ama modele o parçanın etrafındaki daha geniş pencere verilir. İyi bir chunk'ın altın kuralı şudur: tek başına okunduğunda bile anlamlı olmalıdır. Bir insan o parçayı belgeden koparıp okuduğunda "bu neyle ilgili?" diye soruyorsa, model de aynı belirsizlikle karşılaşır. Bağlamsal başlık, başlık hiyerarşisi ve metadata, bir parçaya kimliğini kazandırır. Bu küçük yatırım, getirme isabetini ve kaynak gösterme kalitesini birlikte yükselttiği için, chunking'in en yüksek getirili ince ayarlarından biridir. ## Tablo, Kod ve PDF Gibi Zor İçerikler Nasıl Bölünür? Chunking stratejilerinin çoğu, düz ve akıcı metin varsayımıyla tasarlanır. Ama gerçek kurumsal belgeler bu varsayımı sık sık bozar: tablolar, kod blokları, formlar, çok sütunlu düzenler ve taranmış PDF'ler, düz metin gibi bölündüğünde anlamını tamamen kaybeder. Zor içeriklerin chunking'i, üretim RAG sistemlerinin en çok tökezlediği alanlardan biridir ve özel işleme gerektirir. Tablolar özellikle sorunludur. Sabit boyutlu bir chunking, bir tabloyu satır ortasından keserse, kalan parça hangi sütunun hangi değere karşılık geldiğini kaybeder; "1.250" sayısı, hangi ürünün hangi ayın fiyatı olduğu başka bir parçada kaldıysa anlamsızdır. Tablolar için işe yarayan yaklaşımlar şunlardır: her satırın sütun başlıklarını taşıması (her chunk kendi içinde "Ürün: X, Ocak fiyatı: 1.250" gibi tam bir kayıt olur), tabloyu satır-nesne biçiminde metne çevirmek veya küçük tabloları bütün bir chunk olarak korumak. Genel ilke, tablonun anlamını taşıyan birimin satır olduğunu ve her satırın başlık bağlamıyla birlikte parçalanması gerektiğidir. Kod blokları da benzer bir zorluk taşır. Bir fonksiyonu veya sınıfı ortadan kesmek, kodu hem sözdizimsel hem anlamsal olarak bozar. Kod için doğru yaklaşım, mantıksal birimlere (fonksiyon, sınıf, mantıksal blok) göre bölmek ve her parçaya dosya yolunu, üst kapsamı ve gerekiyorsa içe aktarmaları metadata olarak eklemektir. Böylece izole bir fonksiyon parçası, hangi dosyada ve hangi sınıfın içinde olduğunu bilir. PDF'ler ise ayrı bir metin çıkarımı sorunu getirir. Bir PDF'den metni doğru çıkarmak zordur: çok sütunlu düzenler karışır, üstbilgi/altbilgiler metne sızar, tablolar bozulur ve taranmış (görüntü tabanlı) PDF'ler hiç metin içermez. Taranmış belgeler için optik karakter tanıma (OCR) gerekir; bu sürecin ne olduğunu OCR nedir yazısında ele alıyoruz. Kötü bir metin çıkarımı, en iyi chunking stratejisini bile boşa çıkarır çünkü chunking, önüne gelen bozuk metni sadakatle parçalar; çöp girerse çöp çıkar. Bu yüzden zor içeriklerde chunking'den önce gelen adım — yüksek kaliteli metin ve yapı çıkarımı — en az chunking kadar önemlidir. ## Chunking ve Embedding İlişkisi Nedir? Chunking ve embedding, RAG hattında ardışık iki adımdır ve birbirlerini derinden etkilerler. Her chunk bir embedding modeliyle vektöre çevrilir; bu yüzden chunking kararları, embedding'in kalitesini doğrudan belirler ve tersine, embedding modelinin özellikleri de chunk boyutu kararını sınırlar. Bu ilişkiyi anlamadan alınan chunking kararları çoğu zaman yanıltıcı olur. Birinci ilişki, chunk boyutu ile embedding kalitesi arasındadır. Bir embedding, kendisine verilen tüm metnin anlamını tek bir vektöre sıkıştırır. Parça çok uzunsa, embedding çok sayıda farklı konuyu ortalayarak bulanık ve ayırt ediciliği düşük bir vektör üretir; sonuç, hiçbir sorguya güçlü biçimde yakın olmayan "vasat" bir parçadır. Parça odaklı ve tek konuluysa, embedding o konuyu keskin biçimde temsil eder ve ilgili sorulara güçlü yakınlık gösterir. Bu yüzden "her parça tek bir fikre odaklansın" ilkesi, aslında embedding kalitesini yükseltmenin bir yoludur. İkinci ilişki, embedding modelinin bağlam sınırıdır. Her embedding modelinin işleyebileceği bir maksimum girdi uzunluğu vardır; chunk bu sınırı aşarsa, model metni sessizce kırpar ve parçanın bir kısmı embedding'e hiç yansımaz. Bu, fark edilmesi zor sinsi bir hatadır: parça veritabanında tam görünür ama vektörü yalnızca ilk bölümünü temsil eder. Bu yüzden chunk boyutu, seçtiğiniz embedding modelinin bağlam sınırıyla uyumlu olmalıdır. Bağlam sınırı kavramını context window nedir yazısında ele alıyoruz. Üçüncü ilişki, tutarlılıktır. Belgeleri bir embedding modeliyle, sorguları başka bir modelle gömmek — iki farklı vektör uzayı yarattığı için — getirmeyi anlamsız hale getirir. Aynı şekilde, embedding modelini değiştirdiğinizde tüm belgeleri yeni modelle yeniden vektörlemeniz, yani tüm chunk'ları yeniden işlemeniz gerekir. Bu, chunking ve embedding kararlarının birlikte, bir bütün olarak yönetilmesi gerektiğini gösterir. Embedding modeli seçiminin ayrıntısını embedding nedir ve modelin RAG içindeki rolünü LLM nedir yazısında bulabilirsiniz. Sık yapılan sinsi bir hata, embedding modelinin işleyebileceğinden daha uzun chunk'lar üretmektir. Model bu durumda hata vermez; metni sessizce kırpar ve parçanın sonu embedding'e hiç girmez. Sonuç, veritabanında tam görünen ama aslında yarım temsil edilen parçalardır. Chunk boyutunu belirlerken, seçtiğiniz embedding modelinin maksimum girdi uzunluğunu mutlaka kontrol edin ve güvenli bir marjla altında kalın. ## Türkçe Metinde Chunking'in Özel Zorlukları Nelerdir? Chunking literatürünün büyük kısmı İngilizce metinler üzerine kuruludur; oysa Türkçe içerikle çalışan bir RAG sistemi, dilin kendine özgü yapısı nedeniyle ek özen ister. Türkiye'de kurumsal yapay zeka çözümleri geliştiren ekipler için bu, göz ardı edilemeyecek bir boyuttur; özellikle Türkiye'nin üretken yapay zeka benimsemesinde dünyada öne çıktığı bir dönemde, Türkçe belgeler üzerinde çalışan RAG sistemlerinin kalitesi doğrudan iş değerine dönüşür. Birinci zorluk, Türkçenin sondan eklemeli (agglutinatif) yapısıdır. Tek bir kök, çok sayıda çekim ve yapım ekiyle uzayabilir: "ev", "evler", "evlerimizden", "evlerimizdekiler" gibi. Bu, iki pratik sonuç doğurur. Öncelikle token bazlı chunk boyutu ölçümü Türkçede farklı davranır; aynı anlam, İngilizceye kıyasla farklı sayıda token'a karşılık gelebilir çünkü tokenizer, Türkçe kelimeleri sık sık parçalara böler. Dolayısıyla İngilizce içerik için belirlenmiş bir chunk boyutu, Türkçe içeriğe olduğu gibi taşınamaz; boyut kararı Türkçe metinle yeniden ölçülmelidir. İkinci zorluk, cümle sınırı tespitidir. Cümle ve paragraf tabanlı chunking, cümle sınırlarını doğru bulmaya dayanır; Türkçede kısaltmalar (örneğin "vb.", "Dr.", "T.C."), ondalık sayılar ve özel noktalama, naif bir nokta-temelli bölücüyü yanıltabilir. Türkçeye uygun bir cümle bölücü kullanmak, chunk sınırlarının doğru yerden geçmesini sağlar. Üçüncü ve belki en kritik zorluk, embedding modelinin Türkçe kalitesidir: yalnızca İngilizce için eğitilmiş veya Türkçeyi zayıf temsil eden bir model, en iyi chunking stratejisini bile boşa çıkarır çünkü anlamsal yakınlık ölçümü Türkçe nüansları kaçırır. Türkçe ağırlıklı bir bilgi tabanı için, Türkçeyi güçlü temsil eden çok dilli bir embedding modeli seçmek, chunking stratejisi kadar belirleyicidir. Pratik sonuç şudur: Türkçe içerikle çalışırken chunking stratejinizi İngilizce varsayımlarla kopyalamayın. Chunk boyutunu Türkçe metinle ölçün, cümle bölücüyü Türkçeye uyarlayın ve embedding modelini Türkçe kalitesine göre seçin. Bu üç ayar, Türkçe bir RAG sisteminde getirme kalitesini belirgin biçimde etkiler ve çoğu zaman göz ardı edildiği için bir fark yaratma fırsatı sunar. ## Chunk Kalitesi Nasıl Değerlendirilir? Chunking kararlarını tahminle vermek, RAG projelerinin en yaygın hatalarından biridir. "Bu boyut daha iyi gibi" veya "overlap'i artırınca düzeldi sanki" tarzı öznel izlenimler, sistematik iyileştirmenin düşmanıdır. Chunk kalitesi doğrudan gözle değil, getirme metrikleriyle ölçülür; ve ölçmeden yapılan her chunking değişikliği bir tahmindir. Değerlendirmenin temeli bir altın soru kümesidir: her soru için doğru cevabı içeren belge parçalarının önceden işaretlendiği, temsili bir soru koleksiyonu. Bu küme olmadan chunking stratejilerini objektif karşılaştırmak imkânsızdır. İyi haber şudur: mükemmel ve büyük bir küme gerekmez; gerçek kullanıcı sorularından türetilmiş onlarca soru bile bir taban çizgisi kurmak için değerlidir. Bu kümeyi hazırlamak, bir RAG projesinin en yüksek getirili erken yatırımlarından biridir. Altın küme hazırsa, farklı chunking stratejileri ve boyutları bu kümeyle test edilir ve başlıca getirme metrikleri karşılaştırılır: recall (doğru parçaların ne kadarı aday listesine girdi), precision (getirilen parçaların ne kadarı gerçekten alakalı) ve sıralama kalitesi (MRR ve nDCG — doğru parça ne kadar üstte geldi). Chunking'e özgü ek göstergeler de vardır: bir chunk'ın tek başına bir soruyu yanıtlayabilme oranı (kendine yeterlilik), parça başına gereksiz bağlam miktarı ve bir sorunun cevabının kaç parçaya dağıldığı (parçalanma). Değerlendirme metriklerinin genel çerçevesini LLM değerlendirme nedir yazısında ele alıyoruz. Sağlıklı bir değerlendirme pratiği birkaç ilkeye dayanır. Önce bir taban çizgisi ölçün (örneğin özyinelemeli chunking, orta boyut, makul overlap). Sonra her değişikliği tek tek, aynı küme üzerinde test edin; aynı anda hem boyutu hem overlap'i hem stratejiyi değiştirmek, hangisinin etki ettiğini gizler. Zamanla altın kümeyi büyütün ve üretimden gelen başarısız sorularla zenginleştirin. Bu disiplin, chunking'i bir kez kurulup unutulan değil, ölçüldükçe iyileşen yaşayan bir parametreye dönüştürür. ## Hangi Chunking Stratejisini Seçmeliyim? Karar Rehberi Bunca strateji arasında hangisini seçeceğiniz, en sık sorulan sorudur. Cevap, "en gelişmiş olanı" değil, "belgelerinize ve sorularınıza en uygun olanı"dır. Doğru seçim, üç boyutu birlikte düşünmeyi gerektirir: belge tipiniz, soru deseniniz ve maliyet-kalite dengeniz. Belge tipiyle başlayın. İyi yapılandırılmış belgeler (kurumsal kılavuzlar, teknik dokümantasyon, sözleşmeler, Markdown/HTML içerik) için belge yapısına duyarlı veya özyinelemeli chunking çoğu zaman en iyi sonucu verir çünkü mevcut yapıyı doğrudan kullanır. Yapısız veya tutarsız biçimli, tek belge içinde çok konu barındıran metinler (uzun serbest metin raporlar, dağınık notlar) için semantik chunking daha uygundur. Hızlı bir prototip veya basit metin dosyaları için makul overlap'li sabit boyutlu ya da özyinelemeli chunking yeterli bir tabandır. Soru desenini göz önünde bulundurun. Kısa ve olgusal sorular (bir tanım, bir sayı, bir tarih) daha küçük ve odaklı chunk'lardan fayda görür. Kavramsal, çok cümleli bağlam gerektiren sorular daha büyük parçalardan; birden çok belgeyi birleştiren ilişkisel sorular ise farklı bir yaklaşımdan — belki bir bilgi grafiği tabanlı getirmeden — fayda görebilir; bu ileri yaklaşımı GraphRAG nedir yazısında ele alıyoruz. Chunking'ten sonra gelen ve getirme kalitesini yükselten reranking katmanını da unutmayın; reranker nedir yazısı bu adımı açıklar. Pratik yol haritası şudur: özyinelemeli veya yapıya duyarlı bir temelle başlayın, makul bir overlap ekleyin, her parçaya metadata iliştirin, bir altın soru kümesiyle taban çizgisini ölçün ve ancak belirli soru tipleri sistematik olarak başarısız olursa semantik chunking gibi daha maliyetli stratejilere geçin. Bu kademeli yaklaşım, erken karmaşıklığın tuzağından kaçınmanızı sağlar. Kurumunuza özel bir RAG sistemi tasarlarken chunking stratejisini uçtan uca kurgulamak için kurumsal RAG sistemleri çözümüne, genel yapay zeka danışmanlığı yaklaşımına ve ekip yetkinliği için kurumsal eğitim seçeneklerine bakabilirsiniz. Chunking'te "en iyi strateji hangisi?" sorusunun tek dürüst cevabı, "sizin verinizle ölçtüğünüzde en iyi metrikleri veren"dir. Bir ekip için semantik chunking mükemmel çalışırken, başka bir ekip için özyinelemeli chunking daha iyi sonuç verebilir; fark, belgelerin ve soruların doğasındadır. Bu yüzden strateji seçimini bir inanç meselesi değil, bir ölçüm meselesi olarak ele alın. ## Chunking'de Yaygın Hatalar Nelerdir? Deneyimli bir gözle bakıldığında, başarısız RAG sistemlerinin çoğu benzer chunking hatalarıyla bozulur. Bu hataların ortak kökü, chunking'i önemsiz bir ön işlem adımı sanıp hızla geçmektir. En sık görülenleri tanımak, onlardan kaçınmanın ilk adımıdır. - **Chunking'i düşünmeden sabit boyutta kesmek:** En yaygın hata, belgeleri anlamı hiç dikkate almadan gelişigüzel karakter sayısıyla bölmektir. Bu, cümleleri ve tabloları ortadan keser, bağlamı koparır ve getirmeyi baştan sakatlar. - **Overlap'i tamamen atlamak:** Örtüşme olmadan, sınıra denk gelen kritik cümleler kaybolur. Overlap küçük bir maliyettir ama sınır bağlamını korumanın en basit yoludur. - **Metadata eklememek:** Parçaları çıplak metin olarak indekslemek, "kim, ne zaman, hangi yetkiyle" sorularını cevapsız bırakır; hem kaynak göstermeyi hem erişim kontrolünü hem de tarih/yetki filtrelemesini imkânsızlaştırır. - **Zor içeriği düz metin gibi işlemek:** Tabloları, kodu ve formları düz metin varsayımıyla bölmek, bu içeriklerin anlamını yok eder. Yapılandırılmış içerik özel işleme gerektirir. - **Embedding sınırını aşan chunk üretmek:** Modelin işleyebileceğinden uzun parçalar sessizce kırpılır; parçanın sonu embedding'e hiç girmez ve bu fark edilmesi zor bir hatadır. - **Ölçmeden chunking değiştirmek:** "Daha iyi oldu gibi" hissiyle karar vermek, sistematik iyileştirmenin düşmanıdır. Altın küme ve metrikler olmadan her değişiklik bir tahmindir. - **Türkçeyi İngilizce varsayımlarıyla bölmek:** İngilizce için belirlenmiş boyutları ve cümle bölücüleri Türkçeye olduğu gibi taşımak, dile özgü nüansları kaçırır. - **Tek stratejiyi her belgeye uygulamak:** Kurumsal kılavuzla dağınık e-postayı aynı chunking'le işlemek, her ikisinde de suboptimal sonuç verir; belge portföyü farklı yaklaşımlar gerektirebilir. Bu hataların çoğu aynı yanılgıdan doğar: chunking, modelin gölgesinde kalan ve hızla geçilen bir adım sanılır. Oysa RAG kalitesinin görünmeyen temeli tam da buradadır. Bir RAG sistemi beklenenden kötü çalışıyorsa, ilk bakılacak yer çoğu zaman model değil, belgelerin nasıl bölündüğüdür. Chunking'i iyileştirmek, model değiştirmekten neredeyse her zaman daha yüksek getiri sağlar. ## Chunking Performansı Nasıl Ölçülür ve Kıyaslanır? Chunk kalitesini değerlendirmeyi ele aldık; şimdi bunu bir performans ve kıyaslama (benchmark) disiplinine dönüştürelim. Amaç, farklı chunking stratejilerini sayısal olarak karşılaştırıp kanıta dayalı bir seçim yapmaktır. Buradaki tüm sayısal örnekler illüstratiftir ve yalnızca yöntemi göstermek içindir; gerçek değerler yalnızca kendi verinizle ölçüldüğünde anlam taşır. Bir chunking kıyaslaması kurmak için önce sabit tutulacakları belirleyin: aynı belge kümesi, aynı embedding modeli, aynı altın soru kümesi ve aynı getirme ayarları. Sonra yalnızca chunking değişkenini oynatın — strateji, boyut ve overlap. Her yapılandırma için getirme metriklerini (recall, precision, MRR, nDCG) hesaplayın ve bir tabloda karşılaştırın. Bu kontrollü kıyaslama, "hangi chunking daha iyi" sorusunu bir tartışma olmaktan çıkarıp bir ölçüm sonucuna dönüştürür. Performans ölçümünün ikinci boyutu, kalite dışındaki maliyetlerdir. Semantik chunking daha iyi getirme verebilir ama indeksleme süresini ve hesaplama maliyetini artırır; daha büyük chunk'lar daha az parça üretir (daha ucuz depolama) ama sorgu başına daha fazla token tüketir (daha pahalı üretim). Sağlıklı bir kıyaslama, yalnızca getirme kalitesini değil, indeksleme maliyeti, depolama, sorgu gecikmesi ve token tüketimini de birlikte okur. En iyi chunking stratejisi, en yüksek recall'u veren değil, kabul edilebilir maliyette yeterince yüksek kaliteyi veren stratejidir. Üçüncü boyut, uçtan uca etkidir. Chunking, getirme metriklerini iyileştirse bile asıl önemli olan nihai yanıt kalitesidir. Bu yüzden chunking değişikliklerini, getirme metriklerinin yanında üretim (generation) metrikleriyle de doğrulamak gerekir: yanıt dayanaklılığı (getirilen parçaya sadakat), doğruluk ve eksiksizlik. Bazen getirme metriği iyileşse de yanıt kalitesi aynı kalır; çünkü darboğaz başka bir katmandadır. Bu bütünsel ölçüm yaklaşımını uçtan uca kurmak için RAG mimarisi nasıl kurulur yazısındaki evaluation bölümü tamamlayıcı bir çerçeve sunar. ## Chunking, Fine-tuning ve Getirme Katmanı Nasıl Konumlanır? Chunking'i tek başına değil, RAG hattının diğer kaldıraçlarıyla birlikte düşünmek gerekir; çünkü chunking'in çözebileceği ve çözemeyeceği sorunlar vardır. Yaygın bir yanılgı, her getirme sorununu chunking'i değiştirerek çözmeye çalışmaktır; oysa bazı sorunlar embedding, reranking veya model katmanına aittir. Chunking ile fine-tuning sık karıştırılan iki farklı kaldıraçtır. Chunking, bilginin nasıl bölünüp getirileceğini belirler; fine-tuning ise modelin davranışını, tonunu ve çıktı formatını değiştirir. Sorun "doğru bilgi getirilemiyor" ise çözüm chunking, embedding ve getirme katmanındadır; sorun "doğru bilgi getiriliyor ama model onu yanlış biçimde sunuyor" ise fine-tuning devreye girer. Bu iki kaldıracı karıştırmak, yanlış yere yatırım yapmaya yol açar. Fine-tuning'in ne olduğunu fine-tuning nedir yazısında ele alıyoruz. Chunking'in getirme katmanının diğer bileşenleriyle ilişkisi de nettir. İyi bir chunking, iyi bir embedding için ön koşuldur; iyi bir embedding, etkili bir getirme için; ve reranking, getirilen adayları temizleyerek chunking'in kaçırdığı ince ayarları kısmen telafi eder. Bu zincirde chunking en baştadır ve en zayıf halka tüm sistemin tavanını belirler. Bu yüzden bir RAG sistemini iyileştirirken sıralama önemlidir: önce chunking ve veri kalitesini sağlamlaştırın, sonra embedding ve getirme ayarlarına, en son model ve prompt katmanına geçin. Baştaki bir chunking sorununu ileri katmanlarda kapatmaya çalışmak, çoğu zaman pahalı ve yetersiz kalır. RAG iyileştirmesinde altın kural şudur: sorun büyük olasılıkla modelde değil, getirme katmanındadır ve getirme katmanının temeli chunking'dir. Yanıtlar tutarsız veya eksikse, en pahalı modele geçmeden önce belgelerin nasıl bölündüğüne bakın. Chunking'i iyileştirmek, model yükseltmekten hem daha ucuz hem çoğu zaman daha etkilidir; çünkü doğru parça getirilmiyorsa, hiçbir model onu telafi edemez. ## Bir Belgenin Chunking Yolculuğu: Somut Bir Örnek Chunking'in soyut ilkelerini somutlaştırmanın en iyi yolu, tek bir belgenin sistem içindeki yolculuğunu izlemektir. Varsayalım ki elimizde, bir kurumun 40 sayfalık İK yönetmeliği var ve bunu bir RAG asistanına eklemek istiyoruz. Bu belgenin chunking yolculuğu, buraya kadar anlattığımız kararların hepsini bir arada gösterir. Önce metin ve yapı çıkarımı yapılır. Yönetmelik bir PDF ise, metni çıkarırken başlık hiyerarşisini (Bölüm 1, 1.1, 1.2 gibi), tabloları (izin gün sayıları tablosu) ve listeleri korumaya özen gösteririz. Taranmış bir belgeyse önce OCR gerekir. Bu adım kötü yapılırsa, sonraki her şey zehirlenir; bu yüzden çıkarım kalitesini gözle kontrol ederiz. Ardından chunking stratejisini seçeriz: yönetmelik iyi yapılandırılmış olduğu için belge yapısına duyarlı veya özyinelemeli chunking uygundur. Her parçayı madde ve alt başlık sınırlarından keser, hedef boyutu aşan uzun maddeleri özyinelemeli olarak paragraf ve cümlelere böleriz. Bölme sırasında iki şeye dikkat ederiz. Birincisi overlap: ardışık parçalar arasında makul bir örtüşme bırakırız, böylece bir madde ile bir sonraki arasındaki bağ kopmaz. İkincisi metadata: her parçaya belge adını (İK Yönetmeliği), bölüm başlığını (örneğin "Yıllık İzin"), tarihi ve erişim yetkisini ekleriz; ayrıca izole parçaların anlamlı kalması için başlık hiyerarşisini parçaya gömeriz. İzin gün sayıları tablosunu düz metin gibi kesmeyiz; her satırı sütun başlıklarıyla birlikte, kendi içinde tam bir kayıt olacak şekilde işleriz. Son adımda her parça embedding modeliyle vektöre çevrilir ve metadatasıyla birlikte vektör veritabanına yazılır. Artık bir çalışan "Yıllık iznim devrediyor mu?" diye sorduğunda, sistem doğrudan "Yıllık İzin" bölümünden gelen, başlık bağlamını taşıyan, kendine yeterli bir parçayı getirir ve model kaynak göstererek yanıtlar. Bu yolculuğun her adımı — çıkarım, strateji seçimi, boyut, overlap, metadata, zor içerik işleme — nihai yanıtın kalitesini belirler. Ve dikkat edin: bu yolculukta "hangi model" sorusu hiç geçmedi; çünkü chunking doğru yapıldığında, ortalama bir model bile isabetli yanıt verir. ## Chunking'i Üretime Taşırken Nelere Dikkat Edilir? Bir chunking stratejisini bir prototipte çalıştırmak ile üretimde sürdürülebilir kılmak arasında fark vardır. Üretim, chunking'e birkaç ek boyut ekler: güncelleme, sürümleme, ölçek ve tutarlılık. Bu boyutlar göz ardı edildiğinde, başlangıçta iyi çalışan bir chunking zamanla sessizce bozulur. Birinci boyut güncelleme ve yeniden indekslemedir. Belgeler değişir, silinir ve eklenir. Bir belge güncellendiğinde, o belgenin tüm chunk'ları yeniden işlenmeli ve eski parçalar indeksten kaldırılmalıdır; aksi halde sistem, artık geçersiz bir sürüme dayanarak yanıt üretmeye devam eder. Artımlı indeksleme — yalnızca değişen belgeleri yeniden chunk'lamak — bu süreci ölçekte yönetilebilir kılar. İkinci boyut sürümlemedir: chunking mantığını (strateji, boyut, overlap) bir yapılandırma olarak sürümlemek gerekir, çünkü bu parametreleri değiştirdiğinizde tüm bilgi tabanını yeniden chunk'lamanız gerekebilir ve hangi indeksin hangi ayarla üretildiğini bilmek önemlidir. Üçüncü boyut ölçek ve maliyettir. Semantik chunking gibi maliyetli stratejiler küçük bir belge kümesinde sorun çıkarmaz ama yüz binlerce belgede indeksleme maliyeti ve süresi ciddi hale gelir. Ölçekte, chunking stratejisinin indeksleme maliyeti, sorgu maliyeti kadar önemli bir kalem olur. Dördüncü boyut tutarlılıktır: aynı belge tipine her zaman aynı chunking'in uygulanması, sistemin öngörülebilir davranmasını sağlar; farklı zamanlarda farklı ayarlarla indekslenmiş parçalar, tutarsız getirme sonuçları üretebilir. Bu operasyonel disiplinleri bir bütün olarak LLMOps nedir yazısında ele alıyoruz. Son bir uyarı, güvenlik ve gizlilik boyutudur. Chunking sırasında eklenen metadata (özellikle erişim yetkisi ve gizlilik seviyesi), üretimde erişim kontrolünün temelini oluşturur; bir parça yanlış yetki etiketiyle indekslenirse, yetkisiz bir kullanıcıya sızabilir. Bu yüzden chunking, yalnızca bir kalite değil, aynı zamanda bir güvenlik kararıdır ve KVKK açısından dikkatle tasarlanmalıdır. Kişisel veri içeren belgelerde, chunking aşamasında maskeleme veya anonimleştirme ihtiyacı da değerlendirilmelidir; bu, hukuki tavsiye değildir ve kurumunuzun hukuk/uyum birimiyle birlikte planlanmalıdır. ## Chunk Boyutunu Soru Tipine Göre Nasıl Ayarlarsınız? Chunk boyutu kararını sabit bir sayı olarak değil, sisteminizin yanıtlayacağı soru tiplerinin bir fonksiyonu olarak düşünmek, chunking'i çok daha isabetli kılar. Aynı belge koleksiyonu, farklı soru desenleri için farklı chunk boyutu gerektirebilir; ve deneyimli ekipler bu gerilimi tek bir boyuta zorlamak yerine bilinçli bir tasarımla çözer. Kısa, olgusal ve noktasal sorular (bir tarih, bir eşik değer, bir tanım, bir madde numarası) küçük ve odaklı parçalardan fayda görür. Küçük chunk boyutu, embedding'in tek bir olguyu keskin biçimde temsil etmesini sağlar ve getirme, gürültüsüz bir yanıt döndürür. Buna karşılık kavramsal, çok cümleli akıl yürütme gerektiren sorular (bir sürecin nasıl işlediği, bir politikanın gerekçesi, birbirine bağlı koşullar) daha büyük parçalardan fayda görür çünkü cevap tek bir cümlede değil, bir bağlam bütününde yatar. Küçük chunk boyutu bu tür sorularda bağlamı koparır ve model eksik bir tabloyla yanıt üretmeye zorlanır. Bu gerilimi çözmenin zarif bir yolu, ebeveyn-belge getirme (parent-document retrieval) desenidir. Burada arama küçük ve hassas chunk'lar üzerinden yapılır — çünkü küçük parçalar daha keskin eşleşir — ama modele o küçük parçanın ait olduğu daha büyük ebeveyn parça (veya bölüm) verilir. Böylece hem getirmenin isabeti (küçük chunk boyutu) hem de üretmenin bağlam zenginliği (büyük ebeveyn) elde edilir. Bir başka yaklaşım, aynı belgeyi birden çok chunk boyutunda indekslemek ve soru tipine göre hangi çözünürlüğün kullanılacağını yönlendirmektir; bu daha fazla depolama ister ama karışık soru koleksiyonlarında değerlidir. Chunk boyutu ikilemini çözmenin en pratik desenlerinden biri şudur: aramayı küçük parçalarla yap, modele büyük bağlamı ver. Küçük chunk boyutu getirme isabetini yükseltir; büyük ebeveyn parça ise modele eksiksiz bağlam sunar. Bu ayrım sayesinde "getirme için ideal boyut" ile "üretme için ideal boyut" arasındaki çelişkiyi tek bir sabit boyuta feda etmeden çözersiniz. Soru tipi belirsizse, bu desen çoğu zaman güvenli bir varsayılandır. Pratik sonuç şudur: chunk boyutunu belirlerken önce "bu sistem hangi soruları yanıtlayacak?" diye sorun. Soru koleksiyonunuz ağırlıklı olarak noktasal ise küçük boyuta, kavramsal ise büyük boyuta veya ebeveyn-belge desenine yönelin. Ve her zaman olduğu gibi, bu kararı bir altın soru kümesiyle doğrulayın; soru tipi analizi bir başlangıç hipotezi verir, ölçüm ise onu kanıtlar. ## Overlap Türleri ve İnce Ayarı Nasıl Yapılır? Overlap kavramını yüzeysel ele almak yaygındır — "biraz örtüşme bırak" denir ve geçilir. Oysa overlap'in birkaç türü ve ince ayar boyutu vardır ve bunları anlamak, sınır bağlamını gereksiz maliyet ödemeden korumanızı sağlar. Overlap, chunking'in en ucuz ama en çok ihmal edilen kalite kaldıraçlarından biridir. En yaygın tür, token veya karakter tabanlı overlap'tir: her chunk, bir öncekinin son N token'ını kendi başına tekrar taşır. Bu, sabit boyutlu chunking ile doğal bir eşleşmedir ve uygulaması basittir. İkinci tür, cümle tabanlı overlap'tir: örtüşme, keyfi bir token sayısı yerine tam cümle sınırlarından paylaşılır; böylece örtüşen bölüm her zaman dilbilgisel olarak bütün kalır. Üçüncü ve daha gelişmiş bir yaklaşım, kayan pencere (sliding window) mantığıdır: parçalar sabit bir adımla kaydırılarak üretilir ve her bilgi birden çok pencerede farklı komşularla birlikte görünür; bu, sınır bilgisinin hiçbir zaman tek bir parçada izole kalmamasını sağlar ama depolama ve mükerrer getirme maliyetini artırır. Overlap'in ince ayarı, seçtiğiniz chunking stratejisiyle yakından ilişkilidir. Sabit boyutlu chunking, sınırları anlamdan bağımsız yerlerden geçirdiği için daha yüksek overlap'e ihtiyaç duyar — çünkü kritik bir cümlenin sınıra denk gelme olasılığı yüksektir. Buna karşılık yapıya duyarlı veya semantik chunking, sınırları zaten anlamlı yerlerden (başlık, konu değişimi) geçirdiği için daha az overlap ile yetinebilir; hatta bazı durumlarda overlap'i tamamen kaldırmak bile makul olabilir. Bu, önemli bir tasarım içgörüsüdür: overlap ihtiyacı, chunking stratejisinin ne kadar "akıllı" olduğuyla ters orantılıdır. Overlap'i ayarlarken maliyet tarafını unutmayın. Her overlap birimi, aynı metnin birden çok parçada tekrarlanması demektir; bu, depolamayı artırır, indeksleme maliyetini yükseltir ve getirmede aynı bilginin birden çok kez dönmesine (mükerrerlik) yol açabilir. Sağlıklı yaklaşım, overlap'i sınır bağlamını korumaya yetecek en küçük değerde tutmaktır. Ve yine altın kural geçerlidir: doğru overlap değerini tahminle değil, farklı değerleri aynı altın soru kümesiyle test ederek bulun. ## Çok Dilli ve Karışık Formatlı Koleksiyonlarda Chunking Nasıl Yönetilir? Gerçek kurumsal bilgi tabanları nadiren tek dilli ve tek formatlıdır. Tipik bir koleksiyon; Türkçe ve İngilizce belgeleri, Word ve PDF dosyalarını, wiki sayfalarını, e-postaları, sunumları ve tabloları bir arada barındırır. Bu heterojenlik, chunking'e ek bir yönetim katmanı ekler; tek bir stratejiyi bütün koleksiyona körü körüne uygulamak, çeşitliliğin her köşesinde suboptimal sonuç verir. Çok dillilik, chunking'de iki ayrı karar gerektirir. Birincisi, cümle bölme ve boyut ölçümünün dile göre ayarlanmasıdır: Türkçe bir belge ile İngilizce bir belge, aynı chunk boyutu hedefinde farklı sayıda anlamsal birim taşıyabilir çünkü diller token'a farklı oranda bölünür. İkincisi, embedding modelinin tüm dilleri iyi temsil etmesidir; çok dilli bir koleksiyonda, diller arası anlamsal tutarlılık sağlayan bir embedding modeli seçmek, chunking stratejisi kadar belirleyicidir. Bazı ekipler, dile göre farklı chunking parametreleri (boyut, overlap) uygular ve bunu belgenin dil metadatasına bağlar; bu, göz ardı edilen ama etkili bir ince ayardır. Karışık format ise chunking'in format-farkında olmasını gerektirir. İyi biçimlendirilmiş bir Markdown dokümanı, yapıya duyarlı chunking için idealdir; taranmış bir PDF önce OCR ve yapı çıkarımı ister; bir e-posta zinciri, imza blokları ve alıntılanmış geçmiş nedeniyle özel temizlik gerektirir; bir sunum, slayt başına anlam birimiyle bölünmelidir. Sağlıklı bir mimari, gelen her belgeyi formatına göre doğru işleme hattına yönlendiren bir sınıflandırma katmanı kurar. Bu, "tek chunking her yere" yaklaşımının aksine, belge tipine göre uyarlanmış bir bölümleme sağlar ve heterojen koleksiyonlarda getirme kalitesini belirgin biçimde yükseltir. Karışık bir koleksiyonda en yaygın hata, tüm belgeleri aynı sabit chunking'le işlemektir. Bir kurumsal kılavuz ile bir e-posta zinciri, bir tablo ile serbest metin bir rapor, aynı bölümleme mantığıyla işlendiğinde her biri kendi optimal noktasından uzaklaşır. Belge tipine göre yönlendirme yapan bir sınıflandırma katmanı, bu heterojenliği bir soruna değil, bir tasarım fırsatına dönüştürür. Türkiye bağlamında bu boyut özellikle önemlidir çünkü birçok kurum hem Türkçe hem İngilizce belgelerle çalışır ve mevzuat, sözleşme, teknik dokümantasyon gibi çok farklı format ve dil profillerini bir arada tutar. Bu tür bir koleksiyonda chunking'i format ve dil farkındalığıyla tasarlamak, hem Türkçe hem İngilizce sorularda tutarlı bir getirme kalitesi sağlar ve KVKK açısından belge tipine göre farklı gizlilik işlemesini de kolaylaştırır. ## Chunking İçin Araç ve Kütüphaneler Nasıl Değerlendirilir? Chunking'i uygularken karşılaşacağınız bir karar, hangi araç ve kütüphaneleri kullanacağınızdır. Piyasada belge bölümleme için çok sayıda kütüphane, orkestrasyon çerçevesi ve hazır bileşen bulunur. Burada belirli ürün adları vermek yerine, doğru araç seçiminin ilkelerine odaklanmak daha kalıcı bir rehber sunar; çünkü araçlar hızla değişir, seçim ilkeleri kalıcıdır. Birinci ilke, esneklik ve kontrol dengesidir. Hazır chunking bileşenleri (birçok RAG çerçevesinin sunduğu metin bölücüler) hızlı başlangıç sağlar ve sabit boyutlu, özyinelemeli, cümle tabanlı gibi yaygın stratejileri kutudan çıktığı gibi sunar. Bu, bir prototipi hızla ayağa kaldırmak için idealdir. Ancak üretimde, belgelerinizin kendine özgü yapısı (örneğin kurumunuza özel başlık formatları, tablo düzenleri veya numaralandırma şemaları) genellikle özel chunking mantığı gerektirir. Olgun ekipler, prototipi hazır bir bileşenle kurar, sonra kritik belge tiplerinde bölümlemeyi daha fazla kontrol için kendileri yönetir. İkinci ilke, chunking'in hattın geri kalanıyla uyumudur. Seçtiğiniz araç, metadata iliştirme, format-farkında işleme (tablo, kod, PDF) ve seçtiğiniz embedding modeliyle sorunsuz çalışabilmelidir. Bir chunking aracının tek başına iyi olması yetmez; embedding, vektör veritabanı ve değerlendirme katmanlarıyla temiz bir arayüzden konuşabilmesi gerekir. Üçüncü ilke, değerlendirilebilirliktir: seçtiğiniz araç, farklı chunking ayarlarını hızla deneyip bir altın soru kümesiyle karşılaştırmanıza izin vermelidir. Ölçmeyi zorlaştıran bir araç, chunking'i tahmine mahkûm eder. Son bir değerlendirme boyutu, bağımsızlık ve taşınabilirliktir. Chunking mantığınızı belirli bir araca sıkıca bağlamak, ileride daha iyi bir seçeneğe geçmeyi zorlaştırır. Chunking'i, arkasındaki aracı değiştirebileceğiniz bir soyutlama katmanı olarak tasarlamak, hem tedarikçi kilidini önler hem de stratejinizi ölçüp iyileştirdikçe bileşenleri özgürce değiştirmenizi sağlar. Bu yaklaşım, chunking'i bir kez seçilip unutulan bir araç kararı değil, sürekli iyileştirilebilir bir sistem bileşeni olarak konumlandırır. Kurumunuzun bilgi tabanına özel bir chunking ve getirme hattı tasarlamak için yapay zeka danışmanlığı yaklaşımı ve ekip yetkinliğini geliştirmek için kurumsal eğitim seçenekleri bu ilkeleri uygulamaya taşımanıza yardımcı olur. ## Chunking'de İleri Teknikler Nelerdir? Temel stratejileri sağlam kurduktan sonra, chunking kalitesini bir adım öteye taşıyan birkaç ileri teknik vardır. Bu teknikler bir varsayılan değildir; temel bir chunking hattı ölçülüp sınırına ulaştığında, belirli sorunları çözmek için devreye alınır. Erken uygulamak, çoğu zaman çözdüğünden fazla karmaşıklık ekler. Birinci ileri teknik, bağlamsal zenginleştirmedir (contextual enrichment). Burada her chunk, kendi ham metnine ek olarak, belge içindeki yerini açıklayan model üretimi kısa bir bağlam cümlesiyle zenginleştirilir. Örneğin izole bir parçanın başına "Bu bölüm, 2026 tedarik sözleşmesinin fesih koşullarını açıklar" gibi bir cümle eklenir; bu cümle hem embedding'e girer hem de getirmede parçanın doğru bağlamda eşleşmesini sağlar. Bağlamsal zenginleştirme, izole parçaların "nereye ait olduğunu bilme" sorununu doğrudan çözer ve özellikle çapraz referans içeren belgelerde getirme isabetini yükseltir; bedeli, indeksleme sırasında ek model çağrısı ve maliyettir. İkinci ileri teknik, özet-tabanlı çok katmanlı indekslemedir. Burada büyük bir belge veya bölüm için önce kısa bir özet üretilir ve bu özet, ayrı bir chunk olarak indekslenir. Kavramsal veya "bu belge neyle ilgili" tarzı geniş sorular önce özet parçalarla eşleşir; sonra ilgili belgenin ayrıntılı parçalarına inilir. Bu, "önce genele, sonra ayrıntıya" mantığıyla çalışan bir hiyerarşik getirme sağlar ve büyük belge koleksiyonlarında hem isabeti hem hızı artırabilir. Üçüncü teknik, soru-farkında chunking veya çıkarımdır: bazı sistemler, her chunk için o parçanın yanıtlayabileceği olası soruları önceden üretip bunları da indeksler; böylece kullanıcı sorusu, doğrudan parça metnine değil, parçanın "yanıtlayabileceği sorulara" eşleşir ve semantik boşluk daralır. Bağlamsal zenginleştirme, özet-tabanlı indeksleme ve soru-farkında chunking güçlü tekniklerdir; ama her biri ek maliyet ve karmaşıklık getirir. Deneyim şunu gösterir: iyi bir yapıya duyarlı veya özyinelemeli chunking, makul overlap, doğru metadata ve güçlü bir embedding ile kurulmuş sade bir hat, sorunların büyük çoğunluğunu çözer. İleri teknikler, ancak bu sağlam temel ölçülüp belirli soru tiplerinde sınırına ulaştığında anlam kazanır. Karmaşıklığı baştan değil, kanıt biriktikçe ekleyin. Bu ileri teknikler, chunking'in artık statik bir "böl ve unut" adımı olmadığını, giderek modelin de katkıda bulunduğu akıllı bir katmana dönüştüğünü gösterir. Yine de altın kural değişmez: her ileri tekniğin katkısı bir altın soru kümesiyle ölçülmeli ve yalnızca kanıtlanmış olanlar üretime alınmalıdır. Bu tekniklerin bazıları, getirmeden sonra gelen yeniden sıralama (reranking) ve ilişkisel getirme (GraphRAG) gibi katmanlarla birleşerek daha bütünsel bir RAG kalitesi üretir; bu ileri yaklaşımları reranker nedir ve GraphRAG nedir yazılarında ele alıyoruz. ## Sıkça Sorulan Sorular ### Chunking nedir ve RAG'de neden bu kadar önemlidir? Chunking (belge bölümleme), bir RAG sisteminde belgeleri embedding'lenip vektör veritabanında aranacak parçalara (chunk) ayırma işlemidir. Önemlidir çünkü getirme (retrieval) bütün belge üzerinde değil, bu parçalar üzerinde çalışır; sistem her zaman parça getirir, belge değil. Parça yanlış kesilmişse, doğru bilgi ya hiç bulunamaz ya da alakasız gürültüyle birlikte gelir. Bu yüzden chunking, RAG kalitesini sessizce belirleyen en kritik adımlardan biridir ve pratikte RAG başarısızlıklarının büyük kısmı modelden değil, kötü chunking'den kaynaklanır. ### En iyi chunk boyutu kaç token olmalıdır? Evrensel bir doğru chunk boyutu yoktur; doğru boyut belge türüne, soru desenine ve embedding modeline bağlıdır. Pratik bir başlangıç noktası, birkaç yüz token'lık orta boy parçalardır (örneğin illüstratif olarak 300-500 token aralığı, kendi verinizle ölçmeniz şartıyla). Kısa ve olgusal sorular daha küçük, odaklı parçalardan; kavramsal ve bağlam gerektiren sorular daha büyük parçalardan fayda görür. Doğru chunk boyutunu bulmanın tek güvenilir yolu birkaç seçeneği aynı altın soru kümesiyle test edip getirme metriklerini karşılaştırmaktır; boyut bir dogma değil, ölçülerek ayarlanan bir hiperparametredir. ### Overlap (örtüşme) ne kadar olmalı ve neden gereklidir? Overlap, ardışık chunk'ların bir miktar ortak metin paylaşmasıdır ve bir cümlenin veya fikrin tam parça sınırında ikiye bölünüp bağlamının kopmasını engeller. Pratik bir aralık, parça boyutunun yaklaşık yüzde 10-20'si kadar örtüşmedir (illüstratif; kendi içeriğinizle ölçün). Çok az örtüşme sınır bağlamını kaybetme riski taşır; çok fazla örtüşme ise gereksiz tekrar, artan depolama ve mükerrer getirme sonucu doğurur. Yapıya duyarlı veya semantik chunking kullanıldığında, sınırlar zaten anlamlı yerlerden geçtiği için daha az overlap yeterli olabilir. ### Semantik chunking ne zaman tercih edilmelidir? Semantik chunking, parça sınırlarını sabit boyuta veya belge yapısına göre değil, anlamın kendisine göre belirler: ardışık cümlelerin embedding'leri karşılaştırılır ve konu değişiminin yaşandığı noktalarda parça sınırı çizilir. Bu strateji özellikle tutarsız yapıya sahip, başlık/paragraf sınırları belirsiz veya tek belge içinde çok konu barındıran içeriklerde değer kazanır çünkü her parçanın tek bir fikre odaklanmasını sağlar. Bedeli, indeksleme sırasında ek embedding hesaplaması ve dolayısıyla daha yüksek maliyettir; bu yüzden semantik chunking, yapıya duyarlı chunking'in yetersiz kaldığı kanıtlandığında tercih edilmelidir. ### Özyinelemeli (recursive) chunking nasıl çalışır? Özyinelemeli chunking, belgeyi bir sınırlayıcı hiyerarşisine göre kademeli olarak böler: önce en büyük doğal sınırlardan (bölümler, sonra paragraflar) ayırmayı dener; ortaya çıkan bir parça hedeflenen chunk boyutundan hâlâ büyükse, bir sonraki daha küçük sınırlayıcıya (cümleler, sonra kelimeler) iner ve bölmeyi tekrarlar. Böylece parçalar mümkün olduğunca anlamlı sınırlarda kesilir ama boyut sınırı da aşılmaz. Bu yaklaşım, sabit boyutun basitliğiyle yapıya duyarlılığın anlam bütünlüğünü birleştirdiği için birçok RAG hattında pratik bir varsayılan başlangıç stratejisidir. ### Tablolar ve kod blokları nasıl chunk'lanmalıdır? Tablolar ve kod blokları düz metin gibi bölünemez; sabit boyutlu chunking bir tabloyu satır ortasından veya bir fonksiyonu blok ortasından keserse anlam tamamen kaybolur. Tablolar için her satırın başlık bağlamını taşıması (örneğin her chunk'a sütun başlıklarını eklemek) veya tabloyu satır-nesne biçiminde metne çevirmek işe yarar. Kod için mantıksal birimlere (fonksiyon, sınıf, blok) göre bölmek ve her parçaya dosya yolu ile üst kapsamı metadata olarak eklemek gerekir. Genel ilke: yapılandırılmış içerik, yapısını koruyan özel bir chunking mantığıyla işlenmeli, asla ham karakter sayısıyla kesilmemelidir. ### Türkçe metinlerde chunking'de nelere dikkat edilmeli? Türkçe, sondan eklemeli bir dildir; tek bir kök çok sayıda çekim ekiyle uzayabilir ve cümle yapısı İngilizceden farklıdır. Bu, iki pratik sonuç doğurur. Birincisi, token bazlı chunk boyutu ölçümü Türkçede farklı sonuç verebilir çünkü aynı anlam farklı sayıda token'a karşılık gelebilir; boyut kararı Türkçe içerikle ölçülmelidir. İkincisi, cümle sınırı tespiti (noktalama, kısaltmalar) Türkçeye uygun yapılmalı, embedding modeli ise Türkçeyi iyi temsil eden çok dilli bir model olmalıdır. Zayıf bir Türkçe embedding'i, en iyi chunking stratejisini bile boşa çıkarır. ### Chunk kalitesi nasıl ölçülür? Chunk kalitesi doğrudan gözle değil, getirme metrikleriyle ölçülür. Bir altın soru kümesi hazırlanır: her soru için doğru cevabı içeren belge parçaları önceden işaretlenir. Sonra farklı chunking stratejileri ve boyutları bu kümeyle test edilir ve recall (doğru parça aday listesine girdi mi), precision (getirilen parçaların ne kadarı alakalı) ve sıralama kalitesi (MRR, nDCG) karşılaştırılır. Ek göstergeler: bir chunk'ın tek bir soruyu kendi kendine yanıtlayabilme oranı ve parça başına gereksiz bağlam miktarı. Ölçüm olmadan chunking kararları tahmine dayanır; en iyi uygulama, her değişikliği bu altın kümeyle doğrulamaktır. ### Chunking stratejimi nasıl seçmeliyim? Belge türünüzle başlayın. İyi yapılandırılmış belgeler (kılavuzlar, dokümantasyon, sözleşmeler) için belge yapısına duyarlı veya özyinelemeli chunking; yapısız veya çok konulu metinler için semantik chunking; hızlı ve basit bir taban için makul overlap'li sabit boyutlu chunking uygundur. Pratik yol haritası şudur: özyinelemeli/yapıya duyarlı bir temelle başlayın, makul bir overlap ekleyin, her parçaya metadata iliştirin, bir altın soru kümesiyle taban çizgisini ölçün ve ancak belirli soru tipleri sistematik olarak başarısız olursa semantik chunking gibi daha maliyetli stratejilere geçin. Erken karmaşıklık, çoğu zaman çözdüğünden fazla sorun yaratır. ## Özetle: Chunking Stratejileri ve Belge Bölümlemede En İyi Uygulamalar Özetle chunking stratejileri sorusunun cevabı şudur: RAG'de belge bölümleme, üç kararın bilinçli dengesidir — chunk boyutu, overlap ve sınır mantığı. Getirme parça düzeyinde çalıştığı için, bu kararlar doğrudan yanıt kalitesini belirler; ve RAG başarısızlıklarının büyük kısmı modelden değil, kötü chunking'den kaynaklanır. Başlıca stratejiler — sabit boyutlu, cümle/paragraf tabanlı, özyinelemeli, belge yapısına duyarlı ve semantik chunking — bir olgunluk merdivenidir; doğru seçim en gelişmiş olan değil, belgelerinize ve sorularınıza en uygun olandır. Chunking'i doğru kurmanın işletme değeri de somuttur. Getirme isabetini yükselten iyi bir belge bölümleme, aynı anda birkaç şeyi birden iyileştirir: kullanıcı daha az yanlış yanıtla karşılaşır ve sisteme güveni artar; model daha az ama daha nitelikli bağlam aldığı için token maliyeti düşer; ve doğru kaynak gösterildiği için yanıtlar denetlenebilir hale gelir. Yani chunking, yalnızca teknik bir kalite meselesi değil, aynı zamanda maliyet, güven ve uyum boyutlarına dokunan bir iş kararıdır. Bu yüzden bir RAG projesinde chunking'e ayrılan zaman, çoğu zaman en yüksek getirili yatırımdır ve model yükseltmekten önce gelmelidir. En önemli mesaj şudur: chunking'i bir teknik ön işlem değil, RAG tasarımının merkezi bir kararı olarak ele alın. Yapıya duyarlı veya özyinelemeli bir temelle başlayın, makul bir overlap ekleyin, her parçaya metadata iliştirin, zor içerikleri (tablo, kod, PDF) yapısını koruyarak işleyin, Türkçe metinde dile özgü nüanslara özen gösterin ve doğru boyutu tahminle değil bir altın soru kümesiyle ölçerek bulun. Chunking'i ölçen ve iyileştiren ekipler, güvenilir RAG sistemleri kurar; onu hafife alanlar ise en pahalı modelle bile başarısız olur. Temel kavramlar için RAG nedir, embedding nedir ve vektör veritabanı nedir yazılarına bakabilir; kurumunuza özel bir RAG mimarisi ve chunking stratejisi kurmak için yapay zeka danışmanlığı ile başlayabilir, ekip yetkinliği için kurumsal eğitim seçeneklerini inceleyebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz.