Kazanimlar:
- Chunk boyutu, overlap ve semantic chunking tradeoff'larını sayısal olarak değerlendirmek
- Farklı doküman türleri için (PDF, tablo, kod, sohbet kaydı) uygun chunking stratejisi seçmek
- Her chunk'a metadata ekleyerek retrieval kalitesini ve filtrelemeyi güçlendirmek
RAG'de en çok gözden kaçan ama sonucu en çok belirleyen aşama budur: dokümanı nasıl parçaladığınız. Buna chunking (parçalama) denir. Aynı dokümanı aynı modele verseniz bile, kötü chunking yüzünden retrieval yanlış parça getirir ve model harika bir cevabı asla üretemez. Bu ünitede parçalama stratejilerini, doküman türüne göre nasıl uyarlanacağını ve her parçaya nasıl anlamlı metadata ekleneceğini işliyoruz.
Neden Parçalıyoruz?
Üç sebep var. Birincisi, embedding modelleri belli bir uzunluğa kadar metni anlamlı bir vektöre çevirir; 40 sayfalık bir bölümün tamamı tek vektöre sığdırılırsa anlam "bulanıklaşır". İkincisi, modele bağlam olarak sadece ihtiyaç duyulan kısmı vermek isteriz; tüm dokümanı vermek pahalı ve dikkat dağıtıcıdır. Üçüncüsü, retrieval'ın hassas olması için arama biriminin küçük ve odaklı olması gerekir.
Yani chunk (parça), retrieval'ın en küçük birimidir. Ne çok büyük ne çok küçük olmalı — tam kararında.
Chunk Boyutu ve Overlap Dengesi
İki ana ayar var: chunk boyutu (bir parçada kaç token/kelime olacağı) ve overlap (örtüşme; komşu parçaların paylaştığı kısım).
Çok küçük parçalar (ör. 100 token): odaklıdır ama bağlamdan kopuktur. "14 gündür" der ama neyin 14 gün olduğu bir önceki cümlede kalmıştır. Çok büyük parçalar (ör. 2000 token): bağlamı korur ama içinde birçok konu karışır; embedding bulanır ve alakasız konular birlikte gelir.
Overlap ise sınır sorununu çözer. Bir cümle tam iki parçanın sınırına denk gelirse, örtüşme olmadan ikiye bölünüp anlamı kaybolur. 50-100 tokenlık örtüşme, sınıra denk gelen bilginin en az bir parçada bütün kalmasını sağlar.
Chunk boyutu
Avantaj
Dezavantaj
Uygun içerik
Küçük (100-250 token)
Yüksek hassasiyet, odaklı
Bağlam kopabilir
SSS, kısa maddeler, tanımlar
Orta (300-600 token)
Denge; çoğu senaryo
—
Prosedürler, politika metinleri
Büyük (800-1500 token)
Bağlam bütünlüğü
Bulanık embedding
Anlatı, uzun açıklamalar
İpucu: Nereden başlayacağınızı bilmiyorsanız 400-500 token chunk ve 50-80 token overlap ile başlayın; sonra kendi verinizle ölçüp ayarlayın. "Doğru" boyut evrensel değildir, içeriğe bağlıdır.
Chunking Stratejileri
Sabit boyut (fixed-size): Metni her N token'da bir keser. Basit ve hızlıdır ama cümlenin ortasından bölebilir.
Ayraç-tabanlı (recursive/separator): Önce paragraf, sonra cümle sınırlarına göre böler; anlam bütünlüğünü daha iyi korur. Çoğu üretim sistemi bununla başlar.
Semantik (semantic chunking): Cümlelerin embedding'lerine bakıp konu değişiminin olduğu yerden böler. En kaliteli ama en pahalı yöntemdir; büyük hacimde işlem maliyeti artar.
Yapıya duyarlı (structure-aware): Başlıklar, bölümler, tablolar gibi belge yapısını kullanır. Örneğin bir Markdown dokümanını başlıklarına göre bölmek, her parçanın kendi başlığını taşımasını sağlar.
Doküman Türüne Göre Uyarlama
Her doküman aynı değildir. Türe göre strateji değişir:
- PDF/politika metni: Ayraç-tabanlı, orta boyut. Sayfa üstü/altı tekrarlarını (header/footer) temizleyin.
- Tablolar: Satırı bağlamdan koparmayın; her satırı başlık bilgisiyle birlikte tutun ("Ürün: X, Fiyat: Y, Stok: Z"). Ham tabloyu düz metne çevirmek çoğu zaman şarttır.
- Kod: Fonksiyon/sınıf sınırlarına göre bölün; bir fonksiyonu ortadan kesmeyin.
- Sohbet/ticket kaydı: Mesaj veya konuşma turu bazında bölün; kim ne dedi bilgisini koruyun.
# Ayraç-tabanlı chunking (kavramsal)parcalar = bol( metin, hedef_boyut=450, # token overlap=70, # token ayraclar=["\n\n", "\n", ". ", " "] # önce paragraf, en son kelime)
Her Parçaya Metadata Ekleyin
Chunking sadece "böl" değildir; her parçayı zenginleştirmektir. Parçaya iliştireceğiniz her etiket, ileride filtreleme ve kaynak gösterimi için altın değerindedir.
# Zenginleştirilmiş chunk (kavramsal){ "metin": "Yıllık ücretli izin, 1-5 yıl kıdemde 14 gündür...", "metadata": { "kaynak": "ik_el_kitabi_v7.pdf", "bolum": "5.2 Yıllık İzin", "sayfa": 23, "tarih": "2025-06", "departman": "IK", "gizlilik": "ic" }}
Bir güçlü teknik de başlık ekleme (contextual header): her parçanın başına ait olduğu bölüm başlığını yazmak. Böylece "14 gündür" gibi kopuk bir parça bile "Yıllık İzin — 14 gündür" olarak hem daha iyi embed edilir hem de daha anlamlı gelir.
Zayıf Chunking / Güçlü Chunking
Zayıf (kör sabit kesim, metadata yok):
Metni her 1000 karakterde bir kes. Sadece metni sakla.# Sonuç: tablolar ortadan bölünür, "14 gündür" bağlamsız kalır,# hangi dokümandan geldiği bilinmez, filtre yapılamaz.
Güçlü (yapıya duyarlı + başlık + metadata):
Belgeyi başlıklarına göre böl; her parçaya bölüm başlığını ekle;kaynak, sayfa, tarih ve gizlilik metadata'sını iliştir; tablosatırlarını başlıklarıyla birlikte düz metne çevir.# Sonuç: odaklı, bağlamlı, filtrelenebilir, kaynağı gösterilebilir.
Üç Mini Vaka
Vaka 1 — Tablo felaketi. Bir finans ekibi 200 sayfalık fiyat listesini kör sabit kesimle böldü; tablo satırları rastgele bölündü. "X ürününün fiyatı ne?" sorusuna model yanlış satırı okuyup yanlış fiyat verdi (12 vakadan 9'u hatalı). Tablo satırlarını "Ürün: … | Fiyat: … | Birim: …" formatında düz metne çevirince hata 12'de 0'a indi.
Vaka 2 — Aşırı büyük chunk. Bir wiki'de her sayfa tek chunk (bazıları 3.000 token) yapılmış. Bir sayfada hem "izin" hem "mesai" hem "bordro" olduğu için embedding bulanmış; izin sorusuna mesai bölümü de gelmiş. Sayfaları başlık bazında orta boyuta bölünce recall@5 %64'ten %91'e çıkmış.
Vaka 3 — Overlap olmadan kesik cümle. Bir hukuk ekibinde 250 token sabit kesim, overlap yok. Kritik bir tanım tam iki parçanın sınırına düşmüş ve ikiye bölünmüş; ne biri ne diğeri tam cevabı içeriyor. 60 token overlap eklenince aynı tanım bir parçada bütün kalmış ve doğru cevap dönmüş.
Sık yapılan hatalar
- Kör sabit kesim: Cümle ve tabloları ortadan böler; anlam kaybolur.
- Overlap'ı sıfır bırakmak: Sınıra denk gelen bilgi bölünüp kaybolur.
- Metadata eklememek: Filtreleme ve kaynak gösterimi imkânsızlaşır.
- Tabloları ham bırakmak: Model tablo yapısını çözemez; satırları düz metne çevirin.
- Tek strateji dayatmak: PDF, kod ve tablo aynı yöntemle bölünmez; türe uyarlayın.
Dikkat: Chunking'i bir kez ayarlayıp unutmayın. Yeni doküman türleri geldikçe (yeni bir sistemden ticket'lar, taranmış PDF'ler) retrieval kalitesini yeniden ölçün. Kötü giren veri, kötü çıkan cevaptır ("garbage in, garbage out").
Özetle
- Chunk, retrieval'ın en küçük birimidir; ne çok büyük ne çok küçük — içeriğe göre kararında olmalı.
- Chunk boyutu odak-bağlam dengesini; overlap ise sınır kaybını yönetir.
- Ayraç-tabanlı ve yapıya duyarlı chunking çoğu üretim sisteminin başlangıç noktasıdır; semantik chunking kaliteli ama pahalıdır.
- Tablo, kod ve sohbet gibi türler kendi stratejilerini gerektirir; tabloları düz metne çevirin.
- Her parçaya kaynak/tarih/bölüm/gizlilik metadata'sı ve bölüm başlığı ekleyin; bu filtreleme ve citation'ın temelidir.
Uygulama görevi
Seçtiğiniz dokümandan bir bölümü üç farklı şekilde parçalayın: (1) 200 token'lık küçük parçalar, (2) 500 token orta parçalar (70 token overlap), (3) tek büyük parça. Her strateji için aynı 3 soruyu sorup hangi parçanın getirileceğini elle işaretleyin ve hangi stratejinin bu doküman için en iyi çalıştığını gerekçesiyle yazın. Ardından her parçaya en az dört metadata alanı ve bir "bölüm başlığı" ekleyin. Eğer dokümanda tablo varsa, bir tablo satırını "alan: değer" formatında düz metne dönüştürün.
Kontrol listesi
- [ ] Chunk'ın retrieval'ın en küçük birimi olduğunu ve boyutun odak-bağlam dengesi olduğunu anlatabiliyorum.
- [ ] Overlap'ın neden sınır kaybını önlediğini biliyorum.
- [ ] Ayraç-tabanlı, semantik ve yapıya duyarlı chunking'i ayırt edebiliyorum.
- [ ] Tablo, kod ve sohbet için stratejiyi uyarlayabiliyorum.
- [ ] Her parçaya metadata ve bölüm başlığı ekleyerek retrieval'ı güçlendiriyorum.