İyi bir dil modeli, iyi hazırlanmış bir prompt ve güçlü bir vektör veritabanı seçtiniz. Yine de RAG sisteminiz (Retrieval-Augmented Generation) beklediğiniz doğruluğa ulaşamıyor. Büyük ihtimalle sorun modelde ya da retrieval algoritmasında değil, gözden kaçırılan bir adımda gizlidir: chunking, yani belge parçalama stratejisi.

Chunking (metin parçalama), büyük belge, transkript veya teknik dokümanların yapay zeka sistemlerinin işleyebileceği daha küçük ve anlamlı birimlere bölünmesi sürecidir. Bu parçalar daha sonra vektör temsillerine (embedding) dönüştürülerek bir sorguyla eşleştirilir. Yanlış parçalama, modele bağlamından kopuk bilgi parçaları sunar; bu da doğruluğu doğrudan düşürür.

İçindekiler

• Chunking Neden Bu Kadar Kritik Bir Adım?
• RAG Pipeline'ında Chunking Nerede Devreye Girer?
• Sabit Boyutlu Parçalama (Fixed-Size Chunking) Nasıl Çalışır?
• Özyinelemeli Parçalama (Recursive Chunking) Neden Tercih Edilen Başlangıç Noktasıdır?
• Anlamsal Parçalama (Semantic Chunking) Ne Zaman Gerçekten Fark Yaratır?
• Belge Yapısına Dayalı Parçalama Stratejileri Nelerdir?
• 2026 Benchmark Verileri Ne Söylüyor?
• Doğru Chunking Stratejisini Nasıl Seçersiniz?
• TL;DR
• Sonuç

Chunking Neden Bu Kadar Kritik Bir Adım?

Kısa cevap: Çünkü modelin ne kadar iyi yanıt vereceği, büyük ölçüde ona sunulan parçanın ne kadar tutarlı ve anlamlı olduğuna bağlıdır.

Büyük dil modelleri (LLM) sonsuz uzunlukta metin işleyemez. Her modelin bir bağlam penceresi (context window) sınırı vardır ve bu sınır dahilinde ne sunduğunuz, modelin çıktısının kalitesini belirler. Doğru parçalamanın yokluğunda iki kritik hata ortaya çıkar: çok küçük parçalar bağlamı kaybettirir, çok büyük parçalar ise alaka düzeyini seyreltir.

Vectara'nın NAACL 2025'te yayımlanan araştırması bu denklemi somutlaştırıyor: 25 farklı parçalama konfigürasyonu ve 48 gömme modeli üzerinde yapılan ölçümler, chunking konfigürasyonunun retrieval kalitesini gömme modeli seçimi kadar ya da daha fazla etkilediğini ortaya koyuyor. Bu bulgu, pek çok geliştirici ekibinin en çok zaman harcadığı bileşene (model ve embedding seçimi) değil, başlangıç aşamasına yatırım yapması gerektiğini gösteriyor.

Kötü bir parçalama stratejisinin zincirleme etkileri vardır. Kavramlar arasındaki kritik ilişkiler koparılır, retrieval adımı ilgisiz ya da eksik parçalar getirir ve model bu yetersiz bağlamla çalışarak hatalı veya yanıltıcı yanıtlar üretir. Sorun büyük dil modelinin yetersizliğinden değil, ona sunulan hammaddenin kalitesizliğinden kaynaklanır.

RAG Pipeline'ında Chunking Nerede Devreye Girer?

Chunking, RAG boru hattında belge ön işleme (preprocessing) aşamasından hemen sonra, vektör temsili oluşturma (embedding generation) adımından hemen önce yer alır.

Süreç şu şekilde ilerler: Ham belgeler sisteme alınır ve ön işleme adımından geçer. Ardından chunking stratejisi devreye girer ve belgeyi tanımlı kurallara göre parçalara böler. Her parça bağımsız olarak bir vektör gösterimine dönüştürülür ve bu vektörler bir vektör veritabanında depolanır. Kullanıcı sorgu yaptığında, sorgu da vektöre dönüştürülür ve en yakın parçalar belirlenir. Bu parçalar modele bağlam olarak sunulur ve model yanıtını oluşturur.

Bu zincirdeki her adım, bir öncekinin kalitesine bağımlıdır. Parçalama adımındaki bir hata, sonraki tüm adımların performansını olumsuz etkiler. Yani retrieval kalitesini embedding modelini değiştirerek iyileştirmeye çalışmak, öncelikle parçalama stratejisini optimize etmeden etkili olmayabilir.

Sabit Boyutlu Parçalama (Fixed-Size Chunking) Nasıl Çalışır?

Sabit boyutlu parçalama (fixed-size chunking), belgeyi belirli bir token veya karakter sayısına ulaşıldığında bölen en temel yaklaşımdır.

Uygulaması hızlı ve deterministiktir: Her parça aynı büyüklükte olur ve hesaplama maliyeti minimumdur. Ancak bu yaklaşımın temel zayıflığı, belgenin anlamsal yapısını dikkate almamasıdır. Bir cümle ya da paragraf ortasında bölme gerçekleşebilir; bu da her iki taraftaki parçanın bağlam kaybetmesine neden olur.

Bu sorunu hafifletmek için örtüşme (chunk overlap) mekanizması kullanılır. Komşu parçalar arasında belirli bir token miktarı paylaşılır, böylece bir parçanın sonundaki bilgi bir sonraki parçanın başında da bulunur. Pratikte doğrulanan başlangıç parametreleri şu şekildedir: 256 ile 512 token aralığı çoğu kullanım için en verimli nokta olarak kabul edilirken, önerilen örtüşme oranı yüzde on ile yüzde yirmi arasında, yani 512 tokenlik bir parça için 50 ile 100 token arasındadır.

Sabit boyutlu parçalama, yapısı öngörülemeyen ya da tutarsız biçimlendirilmiş belgelerde makul bir başlangıç noktası sunsa da yapısal tutarlılığı olan belgeler için daha iyi alternatifler mevcuttur.

‍

Özyinelemeli Parçalama (Recursive Chunking) Neden Tercih Edilen Başlangıç Noktasıdır?

Özyinelemeli parçalama (recursive chunking), belgeyi önce büyük yapısal birimlerden başlayarak, ardından giderek küçülen birimlere inerek bölen bir yaklaşımdır. LangChain'deki RecursiveCharacterTextSplitter bu stratejinin en yaygın uygulamasıdır.

Önce çift satır sonu ile paragraflar ayrılır. Parçalar hâlâ hedef boyutu aşıyorsa tek satır sonuna göre bölme uygulanır. Gerekliyse cümle veya kelime düzeyine inilir. Bu hiyerarşik yaklaşım, belgenin doğal akışını mümkün olduğunca korur.

Üretim ortamlarında genel RAG uygulamaları için benchmark ile doğrulanmış başlangıç noktası, yüzde on ile yüzde yirmi örtüşmeyle 400 ile 512 token arasında RecursiveCharacterTextSplitter kullanımıdır. Hesaplama maliyeti düşük, uygulama hızı yüksek ve çoğu belge türüyle uyumludur. Bu nedenle RAG geliştirmenin ilk aşamalarında benchmark alınması gereken temel strateji olarak öne çıkmaktadır.

Anlamsal Parçalama (Semantic Chunking) Ne Zaman Gerçekten Fark Yaratır?

Anlamsal parçalama (semantic chunking), belgeyi karakter ya da token sayısına göre değil, anlam değişimlerine göre böler.

Süreç birkaç adımda işler: Önce metin cümlelere ayrılır. Her cümle için bir vektör temsili oluşturulur. Ardından komşu cümlelerin vektörleri arasındaki benzerlik ölçülür; benzerlik belirgin şekilde düştüğünde o nokta bir parça sınırı olarak belirlenir. Sonuçta her parça kendi içinde anlamsal olarak tutarlı, tek bir fikir veya konuyu kapsayan bir birime dönüşür.

Anlamsal parçalama, kural tabanlı bölme yerine anlam temelli segmentasyona geçişi temsil eder; her cümleyi vektör gösterimine dönüştürür, bu vektörler arasındaki benzerliği analiz eder ve konunun değiştiği noktaları anlamsal sınır olarak belirler.

Ancak anlamsal parçalamayı her zaman tercih etmek doğru değildir. Semantic chunking'in teorik olarak üstün görünmesine karşın, Vectara'nın araştırması gerçekçi veri setlerinde bunun her zaman ölçülebilir bir iyileşme sağlamadığını ortaya koyuyor; ayrıca hesaplama maliyeti anlamlı biçimde daha yüksek. Özellikle uzun bağlamlı belgeler içeren uygulamalarda anlamsal parçalama çok küçük parçalar üretebilir ve bu durum modele yetersiz bağlam sunulmasına neden olur.

En uygun kullanım senaryoları şunlardır: bilgi tabanları (knowledge bases), çeşitli konuları kapsayan teknik belgeler ve içeriğin anlam yoğunluğunun yüksek olduğu alanlara özgü RAG sistemleri.

Belge Yapısına Dayalı Parçalama Stratejileri Nelerdir?

Tüm belgeler düz metin değildir. Markdown, HTML, PDF veya kod dosyaları gibi yapısal unsurlar içeren belgelerde bu yapıyı göz önünde bulunduran parçalama yaklaşımları daha iyi sonuç verir.

Markdown tabanlı parçalama, başlık hiyerarşisine (H1, H2, H3) göre belgeyi doğal bölümlere ayırır. Her bölüm kendi içinde anlamsal bir bütünlük taşıdığından bu yaklaşım, teknik dokümantasyon ve bilgi tabanı içerikleri için oldukça etkilidir.

HTML tabanlı parçalama ise <section>, <article>, <p> gibi etiketlere göre belgeyi parçalar. Web içeriği işleyen RAG sistemleri için bu strateji belgenin görsel yapısını koruyan bir parçalama sağlar.

Kod tabanlı parçalama, kaynak kod dosyalarında fonksiyon veya sınıf sınırlarına göre bölme yapar. Bir RAG sisteminin kod dokümantasyonu veya kod tabanı üzerinde sorgu yapması gerektiğinde her parçanın bir fonksiyonun tamamını içermesi, retrieval kalitesini önemli ölçüde artırır.

Parent-document retrieval (üst belge erişimi) ise daha gelişmiş bir yaklaşımdır: küçük parçalar retrieval için kullanılırken, modele daha geniş bağlam sunmak amacıyla üst belgeye ya da daha büyük bir bölüme erişilir. Bu strateji, hem hassas retrieval hem de yeterli bağlam dengesi gereken durumlarda etkili sonuçlar vermektedir.

2026 Benchmark Verileri Ne Söylüyor?

2025 ve 2026 başında yayımlanan çeşitli değerlendirmeler, chunking stratejileri hakkında bazı yaygın ön kabulü sorgulayan bulgular içeriyor.

Vectara'nın NAACL 2025'te yayımlanan araştırması, 25 chunking konfigürasyonu ve 48 gömme modeli üzerinde yapılan testlerde sabit boyutlu parçalamanın gerçekçi belge kümelerinde anlamsal parçalamaya kıyasla tutarlı biçimde daha iyi performans gösterdiğini ortaya koymuştur.

Ayrıca Ocak 2026'da yapılan sistematik bir analiz, yanıt kalitesinin 2.500 token civarında belirgin biçimde düştüğünü gösteren bir "bağlam uçurumu" noktası tespit etmiştir.

Metadata zenginleştirmenin etkisi de kayda değer: Chunk'lara üst veri eklenmesi, retrieval mimarisinde herhangi bir değişiklik yapılmadan soru-cevap doğruluğunu yüzde 50-60 bandından yüzde 72-75 seviyesine çıkarmıştır.

Bu bulgular birlikte değerlendirildiğinde pratik bir çerçeve ortaya çıkar: Anlamsal parçalamanın maliyetini üstlenmeden önce özyinelemeli parçalama ve metadata zenginleştirme kombinasyonunu test edin. Chunking konfigürasyonunun etkisi, seçilen gömme modelinden daha belirleyici olabilir.

Doğru Chunking Stratejisini Nasıl Seçersiniz?

Doğru strateji, kullanım senaryonuza, belge türünüze ve latency bütçenize göre değişir.

Hızlı prototipleme ve doğrulama aşamasındaysanız, özyinelemeli parçalama yüzde on ile yirmi örtüşmeyle birlikte 512 token hedefinde başlangıç için yeterlidir. Kurulum beş dakika sürer ve çoğu belge tipiyle uyumludur.

Yapısal belgelerde (teknik dokümantasyon, markdown, HTML) belgenin kendi hiyerarşisini kullanan yapı tabanlı stratejiyi tercih edin. Belgenin doğal bölümlerine saygı gösteren bu yaklaşım, retrieval kalitesini genellikle iyileştirir.

Semantik tutarlılığın kritik olduğu alanlarda ve yeterli hesaplama bütçesi varsa anlamsal parçalamayı değerlendirin; ancak mutlaka kendi veri kümenizle ölçün. Teorik üstünlük her zaman pratikte doğrulanmayabilir.

Metadata zenginleştirmeyi hiçbir stratejide atlamayın. Parçalara kaynak belgesi, bölüm başlığı, oluşturulma tarihi veya alan adı gibi meta bilgiler eklemek, sorgulama sırasında filtreleme yapabilmenizi sağlar ve doğruluğu kayda değer biçimde artırır.

Son olarak en önemli kural şudur: kendi veri kümenizde, kendi sorgu örüntülerinizle ölçün. Gömme modeli benchmark puanları alan spesifik performansı garanti etmez ve chunking stratejisi seçiminiz de aynı şekilde ampirik doğrulama gerektirir.

TL;DR

Chunking, RAG sistemlerinin en çok göz ardı edilen ama gömme modeli seçimi kadar etkili olan adımıdır. Özyinelemeli parçalama (recursive chunking), 512 token ve yüzde 10-20 örtüşmeyle benchmark ile doğrulanmış pratik başlangıç noktasıdır. Anlamsal parçalama teorik olarak üstün görünse de gerçek veri setlerinde her zaman tutarlı kazanım sağlamaz ve hesaplama maliyeti daha yüksektir. Metadata zenginleştirme ise mimariyi değiştirmeden doğruluğu anlamlı ölçüde artıran, kolayca ihmal edilen bir kazanımdır. Strateji seçimi önce kendi verinizle ölçüme, ardından optimizasyona dayanmalıdır.

Sonuç

RAG sistemleri, zincirleme kararların birikimli etkisiyle çalışır. Model seçimi, embedding kalitesi ve retrieval algoritması kadar chunking stratejisi de bu zincirin kritik bir halkasını oluşturur. Veri bilimi ekipleri çoğunlukla görünür bileşenlere yatırım yapar ve parçalama adımını varsayılan ayarlara terk eder. Oysa 2025-2026 araştırmaları, bu adımın retrieval kalitesini belirlemedeki ağırlığını açıkça ortaya koydu.

İyi bir chunking stratejisi sihirli bir formül değildir; belge türünüzü, sorgu örüntülerinizi ve sisteminizin önceliklerini anlayan bilinçli bir tasarım kararıdır. Bu kararı veriden hareketle almak, RAG sisteminizin performansını öngörülemeyen iyileştirmelerden daha sağlam temeller üzerine inşa eder.

RAG sisteminizin retrieval performansını değerlendirmek ve chunking stratejinizi optimize etmek ister misiniz? Ekibimizle teknik bir keşif görüşmesi ayarlayın.

‍

Kaynaklar

DataCamp, "Chunking Strategies for AI and RAG Applications

‍