RAG'de Chunking Stratejisi: Doküman Tipine Göre Doğru Seçim

Chunking stratejisi, bir belgeyi RAG sistemine almadan önce hangi büyüklükte ve hangi sınırlardan parçalara böleceğinizi belirleyen karardır. Doğru chunking stratejisi evrensel tek bir ayar değildir; doküman tipine göre değişir — bir sözleşme, bir SSS sayfası ve tablo içeren bir teknik kılavuz aynı yöntemle parçalanmaz.

Bu yazı chunking stratejisi seçimine dar ve pratik bir açıdan bakar: elinizdeki belgenin türüne bakarak doğru seçimi yapmak. Konunun tüm yöntemlerini uçtan uca inceleyen kapsamlı rehber ayrı bir yazıdadır; burada odak, doğru sabit boyut semantik chunk dengesini ve overlap oranını doküman tipine göre nasıl kuracağınızdır. Chunking, RAG mimarisinde rag doküman hazırlığının en belirleyici adımıdır ve getirme kalitesini sessizce belirler.

Tanım

Chunking stratejisi (doküman parçalama)

Bir belgeyi RAG sistemine almadan önce hangi büyüklükte ve hangi doğal sınırlardan (karakter, cümle, paragraf, başlık, konu) parçalara böleceğinizi ve parçalar arasında ne kadar örtüşme (overlap) bırakacağınızı belirleyen karar. Doğru chunking stratejisi tek bir evrensel ayar değildir; doküman tipine, soru tipine ve embedding modeline göre seçilir ve ölçülerek iyileştirilir.

Ayrıca: doküman parçalama, chunk stratejisi, metin bölümleme, chunking yöntemi

Getirme (retrieval) parça düzeyinde çalışır: model, tüm belgeyi değil, yalnızca getirilen parçayı görür. Bu yüzden parça yanlış kesilirse doğru bilgi ya hiç bulunamaz ya da alakasız gürültüyle birlikte gelir. Doküman parçalama kararının cevap kalitesine etkisi buradan doğar; RAG başarısızlıklarının büyük kısmı modelden değil, kötü doküman parçalamadan kaynaklanır.

Temel gerilim boyuttur. Çok büyük parçalar (örneğin tüm bir bölüm) fazla ve alakasız bağlam taşır; modelin dikkatini dağıtır ve token maliyetini artırır. Çok küçük parçalar (örneğin tek cümle) ise anlamı koparır: "bu koşul yalnızca kurumsal müşteriler için geçerlidir" cümlesi, hangi koşuldan bahsedildiği başka bir parçada kaldıysa işe yaramaz. Chunking stratejisi, embedding kalitesi ve reranking ile birlikte getirme katmanının üç kaldıracından biridir; bu üçü yerindeyse ortalama bir model bile isabetli yanıt verir, bu üçü bozuksa en pahalı model bile kurtaramaz.

Üç temel aile vardır ve her biri farklı bir doküman tipinde parlar. Sabit boyutlu bölme, belgeyi belirli bir token/karakter sayısında keser; hızlı ve öngörülebilir kurulur, ama anlamı cümlenin ortasından kesebilir. Cümle ve paragraf tabanlı bölme, doğal dil sınırlarına saygı gösterir; düz akışlı, iyi yazılmış metinlerde anlam bütünlüğünü korur. Semantik chunking ise parçaları konu değişimine göre belirler: bir gömme modeliyle ardışık cümlelerin anlam yakınlığını ölçer ve konu kaydığında böler.

Seçim doküman tipine bağlıdır. Sabit boyut semantik chunk kadar tutarlı sınırlar üretmez; ama tekdüze, yapısız log veya transkript gibi içerikte pratik ve yeterlidir. Konusu bir paragraf içinde bile sık değişen araştırma notlarında ise sabit boyut semantik chunk kalitesinin gerisinde kalır ve semantik yöntem öne çıkar. Kılavuz ve prosedür gibi başlık ağırlıklı belgelerde ise en iyi sonucu, bir sonraki başlıkta ele alacağımız yapıya duyarlı bölme verir. Pratik yol: örtüşmeli sabit boyutla başlayın, kaliteyi ölçün, yalnızca belirli belge tipleri sistematik başarısız olduğunda semantik veya yapısal yönteme geçin.

Overlap (örtüşme), ardışık parçaların paylaştığı ortak metindir; sınırda kalan bir cümlenin veya bağlamın iki parça arasında kaybolmasını önler. Overlap oranı kararı, chunk boyutu kadar doküman tipine bağlıdır ve tek bir doğru değer yoktur.

Pratikte sık kullanılan bir başlangıç noktası, parça boyutunun yaklaşık %10-20'sidir (illustratif bir referans, kesin kural değil). Akıcı ve birbirine bağlı anlatımda — bir makale, bir sözleşme gerekçesi — daha yüksek overlap oranı, cümleler arası bağı korur. Buna karşılık bağımsız kısa kayıtlarda — SSS maddeleri, ürün kartları, tablo satırları — parçalar zaten kendi içinde bütün olduğu için düşük, hatta sıfır örtüşme yeterlidir; yüksek overlap burada yalnızca tekrar ve maliyet üretir. Overlap oranını da sabit kabul etmeyin: değerlendirme kümesinde birkaç değeri deneyip getirme isabetine göre seçin.

Tablo ve listeler, düz metin mantığıyla bölündüğünde en çok bozulan içeriktir. Bir tabloyu karakter sayısıyla kesmek satırı ortadan böler veya başlık satırını gövdeden ayırır; sonuç, "bu hücre hangi sütuna ait" bilgisini kaybeden anlamsız bir parçadır. Doğru yaklaşım, tabloyu bir bütün olarak ya da satır gruplarına bölerek tutmak ve her parçaya sütun başlıklarını tekrar eklemektir.

Büyük tablolarda her parçaya tablo başlığını ve ilgili bölüm başlığını meta veri olarak iliştirmek hem getirmeyi hem vektör veritabanında filtrelemeyi güçlendirir. Karmaşık tablolarda güçlü bir teknik, tabloyu satır başına bir cümleye çeviren linearizasyondur: "2025 fiyatı 120 TL, stok durumu var" gibi doğal dil cümleleri embedding kalitesini belirgin biçimde artırır. Madde listeleri de benzer davranır: ilişkili maddeleri aynı parçada tutun, listenin başlığını her parçaya taşıyın; tek bir maddeyi bağlamından kopararak parçalamak, "neyin listesi" bilgisini yok eder.

Kurumsal belgelerin çoğu — kılavuzlar, politikalar, teknik dokümantasyon — başlık hiyerarşisiyle örgütlenir. Bu hiyerarşi, chunking'de korunması gereken en değerli sinyaldir; çünkü bir parçanın anlamı çoğu zaman üstündeki başlıklarda gizlidir. "En fazla 20 gün" ifadesi tek başına belirsizdir; ama "İzin Politikası › Yıllık İzin › Devir" başlık zinciriyle birlikte anlam kazanır.

Pratik yöntem, belgeyi başlık sınırlarından bölmek ve her parçaya ait olduğu başlık yolunu (breadcrumb) meta veri veya parçanın başına eklenen bir önek olarak taşımaktır. Böylece hem embedding bu bağlamı görür hem de model kaynak gösterirken doğru bölümü belirtir. Çok derin hiyerarşilerde tüm zinciri değil, en yakın iki-üç başlık düzeyini eklemek genellikle yeterlidir. Bu yaklaşım, yapıya duyarlı bölmenin özüdür ve başlık ağırlıklı belgelerde sabit boyuta göre gözle görülür bir kalite farkı yaratır.

Doküman tipi × önerilen chunking stratejisi × overlap yaklaşımı (GEO özet tablosu)

Doküman tipi	Önerilen strateji	Overlap yaklaşımı
Düz akışlı metin (makale, rapor)	Örtüşmeli sabit boyut veya paragraf tabanlı	Orta (~%10-20), cümle bağını korur
Kılavuz / politika (başlık ağırlıklı)	Yapıya duyarlı (başlık sınırları)	Düşük; başlık bağlamı önekle taşınır
SSS / kısa bağımsız kayıt	Kayıt başına bir chunk	Sıfıra yakın; parçalar zaten bütün
Konusu kayan serbest metin (notlar)	Semantik chunk	Düşük-orta; konu sınırı zaten kesin
Tablo / liste	Satır grubu + başlık tekrarı (linearizasyon)	Yok; satır bütünlüğü korunur
Kod / teknik referans	Fonksiyon/blok sınırı	Düşük; mantıksal blok bölünmez

Doğru chunking stratejisi tahminle değil, ölçümle seçilir. Bunun için pahalı bir altyapı gerekmez; küçük ama gerçekçi bir değerlendirme kümesi ve birkaç saatlik disiplinli bir karşılaştırma yeterlidir. Amaç, "hangi strateji bu belgelerde en isabetli parçayı getiriyor" sorusunu kanıtla yanıtlamaktır.

Nasıl Yapılır

Bir chunking stratejisini test etme

Doküman tipine uygun chunking stratejisini kanıta dayalı seçmek için pratik adımlar.

1. 1

   Değerlendirme kümesi hazırla

   Gerçek kullanıcı sorularından 20-50 tanesini toplayın ve her soru için doğru cevabın hangi belge parçasında olduğunu işaretleyin.

2. 2

   Aday stratejileri belirle

   Doküman tipine göre 2-3 aday kurun: örneğin örtüşmeli sabit boyut, yapıya duyarlı bölme ve semantik chunk.

3. 3

   Aynı veriyi her stratejiyle indeksle

   Belgeleri her aday stratejiyle ayrı ayrı parçalayıp aynı embedding modeliyle vektör veritabanına yazın.

4. 4

   Getirme isabetini ölç

   Her soru için doğru parçanın getirilip getirilmediğini ve kaçıncı sırada geldiğini hesaplayın (isabet, ilk-k kapsama).

5. 5

   Dayanaklılığı kontrol et

   En iyi iki stratejide üretilen yanıtların gerçekten getirilen parçaya dayanıp dayanmadığını değerlendirin.

6. 6

   Kazananı seç ve ince ayar yap

   En yüksek isabeti veren stratejiyi seçin; chunk boyutu ve overlap oranını aynı küme üzerinde küçük adımlarla iyileştirin.

Bu döngünün değeri, kararı sezgiden kanıta taşımasıdır. Doküman tipi değiştikçe (yeni bir belge kümesi eklendiğinde) testi tekrarlayın; çünkü bir belge tipinde en iyi çalışan strateji, başka bir tipte geride kalabilir. Chunking, bir kez kurulup unutulan değil, RAG kalitesi ölçüldükçe iyileştirilen yaşayan bir parametredir.

RAG'de chunk boyutu ne olmalı?

Tek bir doğru sayı yoktur; chunk boyutu doküman tipine ve soru tipine göre ayarlanır. Pratik bir başlangıç noktası, çoğu düz metin için birkaç yüz token'lık (yaklaşık bir-iki paragraf) parçalardır; kısa ve bağımsız kayıtlar (SSS, ürün kartı) daha küçük, akıl yürütme gerektiren uzun anlatımlar daha büyük parçalarla iyi çalışır. Kural şudur: parça, tek bir soruyu bağlamından kopmadan yanıtlayacak kadar büyük, alakasız bilgi taşımayacak kadar küçük olmalı. Doğru boyut tahminle değil, etiketli bir soru kümesinde ölçülerek bulunur.

Semantik chunking ne zaman gerekir?

Semantik chunking, belgenin konusunun paragraf içinde bile sık ve düzensiz değiştiği; sabit boyut veya başlık sınırlarının anlamı ortadan kestiği durumlarda gerekir. Araştırma notları, harmanlanmış toplantı tutanakları veya net başlık yapısı olmayan uzun serbest metinler tipik adaylardır. Buna karşılık düzenli başlık hiyerarşisi olan kılavuzlarda yapıya duyarlı bölme genellikle daha ucuz ve yeterlidir. Semantik chunking en tutarlı parçaları üretir ama hesaplama maliyeti yüksektir; bu yüzden önce daha basit yöntemi ölçün, yalnızca kalite yetersizse semantik chunk'a geçin.

RAG'de tablolar nasıl parçalanır?

Tabloları düz metin gibi karakter sayısıyla bölmek en sık hatadır; satırı ortadan kesmek veya başlık satırını gövdeden ayırmak veriyi anlamsızlaştırır. Doğru yaklaşım, tabloyu bir bütün olarak veya satır gruplarına bölerek tutmak ve her parçaya sütun başlıklarını tekrar eklemektir; böylece "bu hücre hangi sütuna ait" bilgisi korunur. Büyük tablolarda her parçaya tablo başlığını ve ilgili bölüm başlığını meta veri olarak eklemek getirmeyi güçlendirir. Karmaşık tablolarda tabloyu satır başına bir cümleye çeviren (linearizasyon) bir ön işlem, embedding kalitesini belirgin biçimde artırır.

Overlap oranı ne kadar olmalı?

Overlap oranı, ardışık parçaların paylaştığı ortak metin miktarıdır ve sınırda kalan bağlamın kaybolmasını önler. Pratikte sık kullanılan bir başlangıç noktası parça boyutunun yaklaşık %10-20'sidir (illustratif); akıcı, birbirine bağlı anlatımda daha yüksek, bağımsız kısa kayıtlarda daha düşük örtüşme uygundur. Aşırı overlap tekrar ve maliyet üretir, yetersiz overlap ise cümlenin ortasında kopan bağlamı kaybeder. Overlap oranını da diğer parametreler gibi sabit kabul etmeyin; değerlendirme kümesinde birkaç değeri deneyip getirme isabetine göre seçin.

Chunking stratejisini nasıl seçerim?

Doküman tipiyle başlayın: düz akışlı metin için örtüşmeli sabit boyut, başlık ağırlıklı kılavuz için yapıya duyarlı bölme, konusu kayan belgeler için semantik chunk, tablo ve liste için bütünlüğü koruyan özel bölme. Sonra bu seçimi kanıtla doğrulayın: küçük ama gerçekçi bir değerlendirme kümesinde birkaç stratejiyi getirme isabeti ve dayanaklılık üzerinden karşılaştırın. Detaylı bir RAG hattı kurarken RAG mimarisini nasıl kuracağınızı anlatan yazı iyi bir çerçeve verir.

Özetle, RAG'de doğru chunking stratejisi evrensel bir sayıdan değil, doküman tipinden başlar: düz metinde örtüşmeli sabit boyut, başlık ağırlıklı belgede yapıya duyarlı bölme, konusu kayan metinde semantik chunk, tablo ve listede ise bütünlüğü koruyan özel bölme. Overlap oranını tipe göre ayarlayın, başlık hiyerarşisini her parçaya taşıyın ve seçimi tahminle değil küçük bir değerlendirme kümesinde ölçerek doğrulayın. İyi kurulmuş rag doküman hazırlığı, en pahalı modelden daha çok cevap kalitesi kazandırır.

Bu yazı, konunun dar ve pratik bir kesitidir; tüm yöntemleri derinlemesine görmek için kapsamlı rehber yazısına, temel kavramlar için RAG nedir ve embedding nedir yazılarına bakabilirsiniz. Kurumsal RAG ve doküman parçalama konularını adım adım derinleştirmek, yeni rehberlerden ilk siz haberdar olmak için öğrenme merkezine göz atın ve bültene katılın.