Belgelerin Chunk Edilme Süreci: LLM Tabanlı Sistemlerde Neden ve Nasıl?
08.06.2025 10:42
Giriş
LLM tabanlı sistemlerde (özellikle RAG mimarisinde) belgelerin doğrudan büyük dil modellerine verilmesi çoğu zaman etkili sonuç vermez. Bunun en temel nedeni, modellerin sınırlı bağlam (context window) kapasitesine sahip olmasıdır. Bu nedenle, belgeleri anlamlı parçalara (chunk) bölmek, hem doğruluğu hem de verimliliği doğrudan etkiler.
Chunk Nedir?
Chunk, bir belgeden elde edilen paragraflar, cümle grupları veya madde bütünlükleri gibi alt bölümlerden oluşur. Amaç, LLM modeline verilecek bilginin hem anlam bütünlüğünü koruması hem de token sınırına uygun olmasıdır.
Neden Chunk Ediyoruz?
- 🔹 Context Limiti: LLM’ler genellikle 4k ila 128k token ile sınırlıdır. Tüm belgeyi vermek imkansızdır.
- 🔹 Sorgu Eşlemesi: Chunk'lar semantik olarak vektörleştirilip arama yapılacağı için küçük ve anlamlı bölümler daha isabetli sonuçlar verir.
- 🔹 Performans: Küçük parçalarla yapılan retrieval işlemleri, daha hızlı ve daha doğru cevaplar üretir.
Chunking Stratejileri
1. Sabit Uzunlukta Bölme (Fixed-length)
Belge her 500–1000 karakterde bir bölünür. En basit yöntemdir.
🧪 Örnek:
def chunk_text(text, chunk_size=1000):
return [text[i:i+chunk_size] for i in range(0, len(text), chunk_size)]
🟡 Avantaj: Hızlı ve uygulanması kolay
🔴 Dezavantaj: Cümle ortasında kesme, anlam kopukluğu riski
2. Cümle ve Paragraf Bazlı Bölme
Belgeler önce nltk
veya spaCy
gibi NLP araçlarıyla cümle/paragraf olarak ayrılır.
Ardından 3–5 cümlelik gruplar bir chunk oluşturur.
🟢 Avantaj: Anlamsal bütünlük korunur
🔴 Dezavantaj: Token sayısı kontrolü gerekir
3. Madde Bazlı Bölme (Yönetmelik İçin En Uygun)
Mevzuat belgelerinde en iyi sonuç, madde numaralarıyla yapılan bölmelerdir.
Örnek Regex:
import re
chunks = re.split(r'\nMadde\s+\d+[-–]?', text)
Bu yöntem, hem semantik bütünlük sağlar hem de kullanıcıların “Madde 5’te ne yazıyor?” gibi sorularına doğrudan cevap verir.
Chunking + Metadata = Güçlü Retrieval
Her chunk'a metadata eklersen, vektör aramada filtreleme yaparak alakasız bölümleri elemiş olursun. Örnek metadata yapısı:
{
"text": "Madde 12 - Serbest tüketici limiti...",
"kaynak": "Elektrik Piyasası Tüketici Hizmetleri Yönetmeliği",
"kategori": "Tüketici Hakları",
"yil": 2022
}
Sorgu Örneği:
index.query(query="serbest tüketici limiti", filters={"kaynak": "EPTHY"})
Dikkat Edilmesi Gerekenler
- ⚠️ Chunk’lar ne çok kısa ne çok uzun olmalıdır (ideal: 200–500 token)
- ⚠️ Overlap (çakışma) gerekebilir → bir cümle hem önceki hem sonraki chunk’a girebilir
- ⚠️ Metadata'lar chunk ile birlikte vektörleştirilmez ama sorguda filtrelemede kullanılır
Sonuç
Belgelerin chunk edilmesi, RAG mimarilerinin temel yapı taşlarından biridir. Doğru chunking stratejisi; bilgiye hızlı, anlamlı ve doğru erişimin anahtarıdır. Özellikle mevzuat gibi yapısal ve uzun dokümanlarda, madde bazlı bölme + metadata destekli retrieval kombinasyonu en verimli sonuçları verir.
🔗 Devamı Gelecek
Bu yazıda chunking sürecine odaklandık. Bir sonraki blog yazısında ise bu chunk’ların vektör veri tabanına nasıl eklendiğini ve sorgularla nasıl ilişkilendirildiğini anlatacağım.