RAG İçin Doküman Chunking Nasıl Yapılır?

RAG sistemlerinde doküman chunking, metinlerin karakter, kelime veya semantik bazlı küçük parçalara bölünerek vektör veri tabanlarına işlenmesi sürecidir.

RAG (Retrieval-Augmented Generation) mimarilerinde bilgi getirme doğruluğu, büyük dil modellerinin (LLM) başarısını doğrudan belirler. Dokümanların ham formatta doğrudan vektörleştirilmesi, bağlam kaybına, alakasız bilgi getirilmesine ve yüksek işletme maliyetlerine yol açar. Bu rehberde, kurumsal sistemlerde RAG İçin Doküman Chunking Nasıl Yapılır? sorusunun teknik yanıtlarını, kullanılan algoritmaları, token optimizasyonunu, güvenlik katmanlarını ve geri çağırma (retrieval) kalitesini artıran kanıtlanmış yöntemleri detaylı olarak inceliyoruz.

RAG Sistemlerinde Chunking Nedir ve Neden Kritik Önem Taşır?

Doküman chunking, yapılandırılmış veya yapılandırılmamış büyük metin yığınlarının, anlamsal bütünlüğü korunarak belirli token veya karakter sınırları dahilinde yönetilebilir alt birimlere ayrılması işlemidir. LLM modelleri doğrudan milyonlarca kelimelik ham veri havuzlarına sorgu atamaz; bunun yerine dokümanlar küçük parçalara (chunks) bölünür, bir embedding modeli aracılığıyla yüksek boyutlu sayısal vektörlere dönüştürülür ve Pinecone, Weaviate, Qdrant veya Milvus gibi vektör veri tabanlarında indekslenir.

Parçalama sürecinin temel amacı, kullanıcının yönelttiği sorgu ile vektör uzayında en yüksek kosinüs benzerliğine (cosine similarity) sahip en alakalı metin bloğunu bulup getirmektir. Çok büyük parçalar modelin dikkat mekanizmasını (attention mechanism) seyrelterek gürültüye yol açarken, gereğinden küçük parçalar cümlenin ana bağlamını yitirmesine neden olur. Bu denge, kurumsal RAG boru hatlarının (pipeline) operasyonel verimliliğini doğrudan tayin eder.

Veri Hazırlama Sürecinde Chunking’in Rolü ve Tanımı

Veri ön işleme aşamasında chunking, ham metin temizliği ile embedding üretimi arasında köprü görevi görür. PDF, DOCX, HTML veya Markdown formatındaki kaynak dosyalar ayrıştırıldıktan (parsing) sonra, standart bir metin akışı elde edilir. Chunking algoritması, bu metin akışını önceden tanımlanmış kurallara göre dilimler.

Ayrıştırma adımında metadata etiketleme kritik bir rol oynar. Her bir parçaya dokümanın başlığı, oluşturulma tarihi, sayfa numarası ve erişim yetki düzeyi gibi üst veriler eklenir. Bu sayede vektör araması esnasında hibrit filtreleme yapılabilir ve sadece yetkili kullanıcının erişebileceği parçalar LLM'in bağlam penceresine iletilir.

Bağlam Koruma ve Halüsinasyon Riski Arasındaki Doğrudan İlişki

LLM'lerin doğru bilgi üretemeyip gerçeğe aykırı ifadeler üretmesi durumu olan halüsinasyon (hallucination), doğrudan yetersiz veya parçalanmış bağlam aktarımından kaynaklanır. Cümle ortasından rastgele kesilmiş bir doküman parçası, sebep-sonuç ilişkisini ortadan kaldırır.

Model, eksik kalan mantık zincirini tamamlamak için kendi parametrik hafızasındaki olasılıksal tamamlama mekanizmasını devreye sokar. Bu durum, finansal rapor analizlerinde veya yasal uyum denetimlerinde kabul edilemez operasyonel riskler doğurur. Doğru uygulanan bir chunking stratejisi, bilginin kaynak metindeki semantik sınırlarını koruyarak modele yalnızca doğrulanabilir ve eksiksiz bilgi parçalarını sunar.

Doküman Chunking Yöntemleri Nelerdir? (Kullanım Senaryoları)

Metinlerin türüne, hiyerarşisine ve kullanım amacına göre farklı chunking algoritmaları tercih edilmelidir. Tek tip bir parçalama stratejisi, heterojen veri yapılarına sahip kurumsal sistemlerde beklenen doğruluğu sağlamaz.

1. Karakter Bazlı ve Sabit Boyutlu (Fixed-Size) Chunking

Sabit boyutlu parçalama, metni belirli bir karakter veya token sayısına ulaştığında doğrudan bölen en ilkel yöntemdir. Örneğin metin her 500 karakterde bir kesilir.

# Sabit boyutlu parça mantığı örneği
def fixed_size_chunk(text, chunk_size=500):
    return [text[i:i+chunk_size] for i in range(0, len(text), chunk_size)]

Bu yöntemin avantajı işlem hızının yüksek olması ve hesaplama maliyetinin düşüklüğüdür. Ancak kelimeleri, cümleleri veya mantıksal paragrafları ortadan ikiye bölme riski taşır. Sözlükler veya yapısal standart içeren log kayıtları haricinde karmaşık metinlerde kullanılması önerilmez.

2. Rekürsif (Yinelemeli) Karakter Chunking

LangChain ve LlamaIndex gibi modern orkestrasyon kütüphanelerinde standart olarak kullanılan RecursiveCharacterTextSplitter, metni belirli bir ayırıcı hiyerarşisine göre böler. Tipik ayırıcı listesi şöyledir:

1. Çift satır sonu (\n\n - Paragraf geçişleri)

2. Tek satır sonu (\n - Satır geçişleri)

3. Boşluk ( - Kelime sınırları)

4. Karakter düzeyi ("" - Son çare karakter bölme)

Algoritma öncelikle metni paragraflara ayırmayı dener. Eğer oluşan parça hedef token boyutundan büyükse, bir alt ayırıcıya (satır sonu veya boşluk) geçerek parçalama işlemini yineler. Böylece metnin doğal dil yapısı bozulmadan hedeflenen parça limitleri içinde kalınır.

3. Dokümana Duyarlı (Yapısal) Chunking (PDF, Markdown, JSON)

Dokümanların biçimsel hiyerarşisini dikkate alan yapısal chunking, özellikle teknik kılavuzlar ve yasal sözleşmeler için zorunludur.

• Markdown Splitter: Başlık etiketlerini (#, ##, ###) sınır kabul eder. Bir başlık altındaki tüm alt başlık ve paragraflar tek bir semantik bağlam olarak tutulur.

• HTML/XML Splitter: DOM ağacındaki <div>, <article>, <p> etiketlerine göre metni gruplar.

• JSON Splitter: Anahtar-değer eşleşmelerini ve iç içe geçmiş nesneleri ilişkilerini kaybetmeden dilimler.

• PDF Tablo Ayrıştırıcılar: Unstructured, PyMuPDF veya OCR tabanlı LayoutLM araçları kullanılarak tablolardaki satır-sütun ilişkisi Markdown tablosuna dönüştürülüp tek bir chunk olarak saklanır.

4. Semantik (Anlamsal) Chunking

Semantik chunking, sabit sınırlar yerine metnin anlamsal değişim noktalarını tespit ederek parçalama yapar. Metin önce cümlelere ayrılır, her cümlenin embedding vektörü çıkarılır ve ardışık cümleler arasındaki kosinüs benzerliği hesaplanır.

Benzerlik skorunun belirlenen eşik değerinin (threshold) altına düştüğü nokta, konunun değiştiğini gösterir ve yeni bir chunk başlangıcı kabul edilir. Hesaplama maliyeti yüksektir ancak yüksek doğruluk gerektiren kurumsal araştırma sistemlerinde en yüksek getirme başarısını sunar.

Chunk Size (Parça Boyutu) ve Chunk Overlap (Örtüşme Payı) Ayarı Nasıl Yapılır?

Chunk Size (parça boyutu), her bir metin parçasının içereceği maksimum token veya karakter miktarını ifade eder. Chunk Overlap (örtüşme payı) ise ardışık iki parça arasında paylaşılan ortak metin miktarını tanımlar. Bu iki parametrenin yanlış ayarlanması, RAG mimarisinin genel başarımını sekteye uğratan en yaygın yapılandırma hatasıdır.

LLM Token Sınırları ve Context Window Yönetimi

Büyük dil modellerinin girdi olarak kabul edebileceği bir bağlam penceresi (context window) sınırı vardır. Modern modeller (örneğin 128k veya 1M token kapasiteli sistemler) geniş bağlam sunsa da, "Needle In A Haystack" (Samandağında İğne Arama) testlerinin gösterdiği üzere, bağlam penceresi büyüdükçe modelin pencerenin ortasında yer alan bilgileri gözden kaçırma oranı artar.

Ayrıca embedding modellerinin (örneğin OpenAI text-embedding-3-small veya açık kaynak BGE-M3, E5-large) de katı token limitleri bulunur. Çoğu embedding modeli 512 veya 8192 token sınırına sahiptir. Parça boyutu seçilirken embedding modelinin etkin temsil gücü göz önüne alınmalıdır. 512 tokenlik bir embedding modeline 1000 tokenlik girdi verilirse, kalan metin sessizce kırpılır ve ciddi bilgi kaybı yaşanır.

Bilgi Kaybını Önlemede Örtüşme Payının (Overlap) Matematiksel Mantığı

Örtüşme payı, ardışık parçaların sınırlarında bulunan cümlelerin bağlamından kopmasını engeller. Eğer bir cümle parçalama sınırına denk gelirse, anlamı ikiye bölünür. Örtüşme payı sayesinde cümlenin tamamı hem $n$. parçada hem de $n+1$. parçada yer alarak semantik bütünlük korunur.

Örtüşme oranı genel bir kural olarak hedef parça boyutunun $\%10$ ile $\%20$'si arasında tutulmalıdır:

Örneğin $500$ tokenlik bir parça boyutu için $50$ ila $100$ tokenlik bir örtüşme payı ayrılmalıdır. Örtüşme payının $\%30$'un üzerine çıkarılması, vektör veri tabanında gereksiz veri tekrarına (redundancy), indeks boyutunun şişmesine ve API sorgu maliyetlerinin artmasına neden olur.

Doküman Akışı: [ -------- Parça 1 (1-500 Token) -------- ]
                                  [ --- Örtüşme (450-500) --- ]
                                  [ -------- Parça 2 (450-950 Token) -------- ]

Kurumsal Projelerde Chunking Stratejisi Belirlerken 4 Kritik Kriter

Kurumsal ölçekli yapay zeka projelerinde doküman parçalama yalnızca teknik bir kodlama tercihi değil; regülasyon, bütçe ve donanım kısıtlarını içeren kapsamlı bir mimari karardır.

1. Veri Tipi ve Doküman Formatı (Yapılandırılmış vs. Yapılandırılmamış)

Kurumsal bilgi havuzları homojen değildir. ERP sistemlerinden gelen tablolar, CRM sözleşmeleri, teknik şartnameler ve e-posta yazışmaları farklı veri yapılarına sahiptir.

• Yapılandırılmamış Veriler (Serbest Metinler): Blog yazıları, kılavuzlar ve şirket içi duyurular için rekürsif karakter parçalama yeterlidir.

• Yarı Yapılandırılmış Veriler (PDF & Tablolar): Çok sütunlu PDF belgeleri OCR işleminden geçirilirken okuma sırası bozulabilir. Bu belgelerde metin blokları yerine tablo hücreleri ve hiyerarşik başlıklar baz alınarak özel çıkarıcılar kullanılmalıdır.

2. Embedding Modeli Yetenekleri ve Sınırları

Kullanılan embedding modelinin vektör boyutu (dimensionality) ve eğitildiği dil havuzu doğrudan parça kalitesini etkiler. Çok dilli (multilingual) modeller, Türkçe gibi eklemeli dillerde tokenizasyon yaparken kelimeleri daha fazla alt birime (sub-word token) ayırabilir.

Örneğin, İngilizce 500 kelimelik bir metin ortalama 650 token tutarken, Türkçe 500 kelimelik bir metin 1000'in üzerinde token üretebilir. Bu nedenle parça boyutu karakter değil, kullanılan tokenizer (tiktoken, HuggingFace Tokenizers) bazında doğrulanmalıdır.

3. API Token Maliyetleri ve Performans Optimizasyonu

Vektör veri tabanına yazma maliyeti tek seferliktir; ancak getirme (retrieval) sırasında LLM'e iletilen her parça değişken API maliyeti yaratır. Kullanıcının her sorgusunda modele $Top\text{-}k = 5$ parça iletildiğinde:

• Her parça 1000 token ise: $5 \times 1000 = 5000$ girdi tokeni.

• Her parça 250 token ise: $5 \times 250 = 1250$ girdi tokeni.

Gereksiz büyük parçalar, her ay yüz binlerce sorgu alan kurumsal sistemlerde ciddi maliyet kalemleri oluşturur. Token tasarrufu sağlamak için parça boyutunu optimize etmek ve gerekirse getirme sonrasında bir Reranker (yeniden sıralayıcı) modeli (örneğin Cohere Rerank veya bge-reranker) çalıştırarak sadece en yüksek skora sahip 2-3 parçayı LLM'e iletmek gerekir.

4. Veri Gizliliği, KVKK ve Güvenlik Gereksinimleri

Chunking işlemi esnasında metin içinde yer alan TCKN, kredi kartı bilgisi, isim ve e-posta gibi Kişisel Verilerin Korunması Kanunu (KVKK) ve GDPR kapsamındaki hassas veriler ayrıştırılmalıdır.

Veriler vektörleştirilmeden önce bir PII (Personally Identifiable Information) maskeleme katmanından geçirilmelidir. Parçalara atanan metadata etiketlerinde rol bazlı erişim denetimi (RBAC) bilgileri yer almalıdır. Yetkisiz bir kullanıcının yaptığı aramada, ilgili parça vektör benzerlik skoru yüksek olsa dahi filtreleme aşamasında elenmelidir.

Chunking Performansı Nasıl Ölçülür ve Optimize Edilir?

Uygulanan chunking stratejisinin doğruluğu varsayımlarla değil, nesnel metriklerle ve geri çağırma testleriyle ölçülmelidir. RAG boru hattının zayıf halkası genellikle dil modelinin kendisi değil, yanlış seçilen parçalama parametreleridir.

Geri Çağırma (Retrieval) Doğruluğunu Test Etme Yöntemleri

Chunking başarısını izlemek için RAG Değerlendirme Çerçeveleri (Ragas, TruLens veya DeepEval) kullanılır. Bu araçlar şu temel metrikleri ölçer:

• Context Precision (Bağlam Hassasiyeti): Getirilen parçaların sorguyla ne kadar doğrudan ilişkili olduğunu ölçer. Düşükse parça boyutu çok büyük olabilir veya gürültü içeriyordur.

• Context Recall (Bağlam Kapsamı): Soruyu yanıtlamak için gereken tüm bilgilerin parçalar içinde eksiksiz yer alıp almadığını kontrol eder. Düşükse örtüşme payı yetersizdir veya parça boyutu fazla küçüktür.

• Faithfulness (Sadakat): Üretilen yanıtın yalnızca getirilen parçalara dayanıp dayanmadığını doğrular.

İnsan Denetimi (Human-in-the-Loop) ile Yanıt Kalitesi Kontrolü

Otomatik metriklerin yanı sıra alan uzmanlarının (domain experts) yer aldığı bir denetim mekanizması kurulmalıdır. Özellikle finans, sağlık ve hukuk gibi kritik sektörlerde modelin getirdiği kaynak parçalar ile ürettiği çıktı yan yana doğrulanmalıdır.

Kullanıcıların verdiği olumsuz geri bildirimler (örneğin "eksik yanıt", "yanlış veri") loglanmalı; bu sorguların getirdiği chunk'lar incelenerek parça sınırı, ayırıcı türü veya embedding modeli geriye dönük olarak optimize edilmelidir.