RAG'de Chunk Stratejisi: Boyut, Overlap ve Bölme Kararları Nasıl Verilir?

Retrieval-Augmented Generation (RAG) projelerinde en çok tartışılan konu model seçimi olur, ama cevap kalitesinin tavanını genellikle çok daha sıradan bir karar belirler: dokümanları hangi parçalara böldüğünüz. Modeli büyütmek, yanlış parçalanmış bir bilgi tabanını kurtarmaz — çünkü model, arama katmanının önüne koyduğu metinden fazlasını göremez.

Bu yazı chunk boyutu, overlap oranı, bölme yöntemi ve metadata kararlarını üretim gözüyle ele alıyor: hangi kararın neyi etkilediği, nasıl ölçüleceği ve Türkçe içerikte nelerin değiştiği.

Chunk nedir ve neden retrieval kalitesinin tavanını belirler?

Chunk, bir dokümanın vektör veritabanına ayrı bir kayıt olarak yazılan en küçük parçasıdır. Arama katmanı doküman değil chunk döndürür; dil modeli de yalnızca dönen chunk'ları görür. Bu yüzden bir bilginin cevaplanabilir olması için tek bir chunk'ın içinde bütün olarak bulunması gerekir. Cevap iki chunk'a bölünmüşse ve arama yalnızca birini getirdiyse, model eksik bilgiyle cevap üretir — üstelik eksik olduğunu bilmeden.

Buradaki asıl risk sessiz olmasıdır. Yanlış chunk'lama hata vermez, sadece cevapları biraz daha kötü yapar. Bu yüzden chunk stratejisi, ölçülmediği sürece fark edilmeyen bir kalite kaybı kaynağıdır.

Chunk boyutu ne olmalı?

Genel amaçlı doküman erişimi için pratikte iyi çalışan aralık 200-500 token'dır; başlangıç değeri olarak 300 token makul bir varsayılandır. Küçük chunk'lar (100-200 token) daha keskin eşleşme verir çünkü vektör tek bir konuyu temsil eder, ama cevap için gereken bağlam sıklıkla dışarıda kalır. Büyük chunk'lar (800+ token) bağlamı korur ama vektörü bulanıklaştırır: içinde beş farklı konu geçen bir metnin embedding'i hiçbirine tam olarak yakın olmaz.

Boyutu karakter değil token cinsinden ölçün ve embedding modelinizin girdi sınırını kontrol edin. Sınırın üzerindeki metin sessizce kesilir; chunk'ınızın son paragrafı vektöre hiç girmemiş olabilir. Ayrıca üretilen chunk'ların token dağılımını bir histogramla bakın — ortalama iyi görünürken uç değerlerin sınırı aştığı durum yaygındır.

Overlap ne kadar olmalı?

Overlap, ardışık chunk'ların paylaştığı metin miktarıdır ve sınırda kalan cümlelerin kaybolmasını önler. Yaygın pratik chunk boyutunun %10-20'si kadar overlap kullanmaktır: 300 token'lık chunk için 30-60 token. Amaç, bir cümlenin ortasından bölünen bilginin en az bir chunk'ta bütün halde bulunmasını garanti etmektir.

Overlap'i büyütmek cazip gelir ama bedeli vardır: %50 overlap, indeks boyutunu ve embedding maliyetini yaklaşık iki katına çıkarır, arama sonuçlarında da neredeyse aynı olan chunk'ların üst üste dönmesine yol açar. Bu, top-k sonucunun yarısını tek bir bilgiye harcamak demektir. Overlap'i bir sigorta olarak düşünün, strateji olarak değil.

Sabit boyut mu, yapısal sınır mı, semantik bölme mi?

Üç yaklaşım vardır ve seçim doküman tipine bağlıdır. Sabit boyutlu bölme metni belirli token sayısında keser; uygulaması en kolay olanıdır ve yapısı olmayan düz metinlerde makul çalışır. Yapısal bölme başlıkları, paragrafları ve liste sınırlarını kullanır; Markdown, HTML, teknik doküman ve mevzuat gibi hiyerarşisi belli içeriklerde açık ara en iyi maliyet/fayda oranını verir. Semantik bölme ardışık cümlelerin embedding'leri arasındaki mesafeye bakıp konu değiştiği noktada böler; en pahalısıdır ve yalnızca yapısı olmayan uzun anlatı metinlerinde farkını gösterir.

Pratikte doğru başlangıç yapısal bölmedir: dokümanın kendi başlık hiyerarşisini kullanın, ortaya çıkan parçalar hedef token aralığından büyükse onları sabit boyutla ikinci kez bölün. Semantik bölmeye ancak ölçüm yapısal bölmenin yetmediğini gösterdiğinde geçin — çoğu projede o noktaya hiç gelinmez.

Tablolar, kod blokları ve listeler nasıl bölünmeli?

Bölünmemeliler. Bir tablo başlık satırından koparıldığında geri kalan satırlar anlamsızlaşır: sütunun neyi ifade ettiğini söyleyen bilgi başka bir chunk'ta kalır. Aynısı kod blokları için de geçerlidir; ortasından bölünen bir fonksiyon ne çalıştırılabilir ne de açıklanabilir. Bu yapıları atomik birim olarak işleyin, token sınırını aşsalar bile.

Tablo hedef boyutu gerçekten aşıyorsa satır gruplarına bölün ve başlık satırını her parçaya yeniden ekleyin. Uzun kod dosyalarında fonksiyon veya sınıf sınırından bölün, satır sayısından değil. Genel kural: bölme sınırı, içeriğin kendi anlam sınırıyla çakışmalı.

Chunk'a hangi metadata eklenmeli?

En az şunlar: kaynak doküman kimliği, doküman içindeki başlık hiyerarşisi, bölüm veya sayfa numarası ve içeriğin tarihi. Başlık hiyerarşisini chunk metninin başına da yazın — "Ürün > Fiyatlandırma > Kurumsal Plan" gibi bir önek, embedding'e chunk'ın nerede geçtiğini öğretir ve tek başına okunduğunda anlamsız kalan parçaları bağlama oturtur.

Metadata'nın ikinci işlevi filtrelemedir: tarihe göre eskiyen içeriği elemek, kullanıcının yetkisi olmayan kaynakları aramanın dışında tutmak, belirli bir ürüne ait dokümanlarla sınırlamak. Üçüncüsü atıftır — kullanıcıya cevabın hangi dokümanın hangi bölümünden geldiğini gösteremiyorsanız, sistemin doğruluğu denetlenemez.

Küçük ara, büyük ver (small-to-big) yaklaşımı ne zaman doğru?

Bu yaklaşımda arama küçük chunk'lar üzerinde yapılır, ama modele o chunk'ın içinde bulunduğu daha büyük parça (üst paragraf, bölüm veya doküman) verilir. Böylece aramanın keskinliği ile cevabın bağlamı arasındaki ödünleşim ortadan kalkar: küçük vektör isabetli eşleşme sağlar, büyük metin cevabı yazmaya yeter.

Bedeli karmaşıklıktır — her chunk'ın ebeveynini tutan bir eşleme ve prompt'a giren token miktarında artış. Cevapların "doğru dokümanı buldu ama eksik anlattı" şeklinde başarısız olduğu sistemlerde bu yaklaşım en yüksek getiriyi veren tek değişikliktir. Cevaplar zaten yanlış dokümana gidiyorsa sorun chunk boyutunda değil, arama katmanındadır.

Chunk stratejisi nasıl ölçülür?

Ölçüm için 50-100 soruluk bir altın set hazırlayın: her soru için doğru cevabın hangi doküman ve hangi bölümde olduğunu elle işaretleyin. Sonra yalnızca arama katmanını değerlendirin — doğru parça ilk k sonuç içinde geliyor mu (recall@k), kaçıncı sırada geliyor (MRR). Bu ölçümü dil modeli olmadan yapın; modelin cevabı üzerinden değerlendirirseniz retrieval hatasıyla üretim hatasını birbirinden ayıramazsınız.

Altın set hazırlamak zaman alır ve tam da bu yüzden çoğu ekip atlar. Atlandığında chunk boyutu tartışması bir görüş meselesine döner; hazırlandığında ise iki saatlik bir deneyle karara bağlanır. Aynı seti daha sonra embedding modeli değiştirirken de kullanırsınız, yani maliyeti bir kere ödenir.

Türkçe içerikte chunk'lamada ne değişir?

İki şey değişir. Birincisi tokenizasyon: yaygın BPE tokenizer'lar İngilizce üzerinde eğitildiği için Türkçe kelimeleri daha fazla parçaya böler. Aynı karakter sayısındaki Türkçe metin, İngilizceye göre belirgin şekilde daha fazla token üretir. Karakter sayısına göre ayarlanmış bir chunk boyutu Türkçede beklediğinizden büyük çıkar ve sessizce embedding sınırını aşabilir — bu yüzden boyutu her zaman gerçek tokenizer ile ölçün.

İkincisi morfoloji: Türkçe sondan eklemeli bir dildir ve aynı kök çok sayıda yüzey biçimiyle görünür. Bu, anahtar kelime tabanlı aramayı (BM25 gibi) tek başına zayıflatır, çünkü "faturalandırma" ile "faturaların" farklı terimler gibi görünür. Vektör araması bu farkı büyük ölçüde soğurur; hibrit arama kuruyorsanız Türkçe için anahtar kelime tarafına kök bulma veya lemmatizasyon eklemeden ölçtüğünüz sonuç yanıltıcı olur.

Kaç chunk döndürmeli (top-k)?

Top-k, arama katmanının modele kaç chunk verdiğidir ve chunk boyutuyla birlikte düşünülmesi gerekir: 300 token'lık chunk'larla k=5 yaklaşık 1.500 token bağlam demektir, 800 token'lık chunk'larla aynı k dört binin üzerine çıkar. Küçük chunk kullanıyorsanız k'yı büyütmek, büyük chunk kullanıyorsanız küçültmek gerekir; ikisini ayrı ayrı ayarlamak yaygın bir hatadır.

k'yı büyütmek her zaman iyi değildir. Alakasız chunk'lar prompt'a girdikçe model dikkatini bölmek zorunda kalır ve cevap kalitesi belli bir noktadan sonra düşmeye başlar. Altın setle recall@k eğrisine bakın: recall'un düzleştiği nokta k için doğal üst sınırdır, ötesi maliyet ve gürültüden ibarettir.

Re-ranking chunk boyutu kararını değiştirir mi?

Evet, ve genellikle küçük chunk lehine değiştirir. Re-ranker, vektör aramasının döndürdüğü aday kümesini soru-chunk çiftlerini tek tek puanlayarak yeniden sıralar. Bu, geniş bir aday kümesini (k=50 gibi) ucuza toplayıp en iyi beşini hassas bir modelle seçmenizi mümkün kılar; küçük chunk'ların keskin eşleşme avantajı korunurken düşük recall dezavantajı büyük k ile telafi edilir.

Re-ranking gecikme ve maliyet ekler, bu yüzden her sistemde gerekli değildir. Kural olarak: doğru chunk ilk 50 sonuçta var ama ilk 5'te değilse re-ranker sorununuzu çözer. Doğru chunk ilk 50'de de yoksa sorun sıralamada değil, chunk'lama veya embedding modelindedir — re-ranker orada hiçbir şey kurtarmaz.

Hibrit arama chunk stratejisini nasıl etkiler?

Hibrit arama, vektör benzerliğini BM25 gibi anahtar kelime skoruyla birleştirir ve özellikle ürün kodu, hata mesajı, mevzuat maddesi gibi tam eşleşme gerektiren sorgularda vektör aramasının zayıf kaldığı yeri kapatır. Anahtar kelime tarafı chunk boyutuna vektör tarafından farklı tepki verir: BM25 uzun metinlerde terim yoğunluğunu düşürdüğü için çok büyük chunk'larda skorlar birbirine yaklaşır ve ayırt ediciliği azalır.

Pratikte bu, hibrit kurulumda orta boy chunk'ları (300-500 token) iki yöntem için de makul bir orta nokta yapar. Türkçe içerikte anahtar kelime tarafına kök bulma eklemeden ölçüm yapmayın; eksiz karşılaştırma BM25'i hak etmediği kadar zayıf gösterir ve sizi yanlış sonuca götürür.

En sık yapılan beş hata

Birincisi, chunk boyutunu ölçmeden seçmek ve bir daha dönüp bakmamak. İkincisi, overlap'i strateji sanıp yükseltmek; bu indeks maliyetini artırır ve top-k sonucunu birbirinin kopyası chunk'larla doldurur. Üçüncüsü, tabloları ve kod bloklarını sıradan metin gibi bölmek. Dördüncüsü, metadata'yı sonraya bırakmak — sonradan eklemek tüm indeksi yeniden üretmek demektir. Beşincisi, retrieval'i uçtan uca cevap kalitesiyle değerlendirmek ve hatanın arama katmanında mı üretimde mi olduğunu hiç ayırt edememek.

Bu beşinin ortak yanı, hiçbirinin hata olarak görünmemesidir. Sistem çalışır, cevap üretir, sadece olması gerekenden daha kötüdür — ve karşılaştırma noktası olmadığı için bu fark kimseye görünmez.