Yapay Zekâda RAG Chunking: Belgeleri Doğru Parçalara Bölme Rehberi

Yapay zekâ ile dokümanlara soru sorduran bir uygulama geliştirirken model seçimi kadar önemli bir konu daha vardır: bilgi kaynağını modele nasıl sunduğunuz. RAG (Retrieval-Augmented Generation) sistemlerinde belgeleri küçük parçalara ayırma işlemine RAG chunking denir. Parçalar çok büyükse arama sonucu gürültülü olur; çok küçükse cümleler bağlamını kaybeder.

Bu rehberde PDF, Markdown, web sayfası ve şirket dokümanlarını yapay zekâ için daha aranabilir hâle getiren chunking yaklaşımını adım adım ele alacağım. Hedef, herkes için geçerli tek bir sayı bulmak değil; kendi veri setiniz için ölçülebilir bir başlangıç noktası kurmaktır.

RAG chunking nedir?

RAG mimarisinde model, her soruda bütün doküman arşivini okumak yerine önce ilgili içerik parçalarını bulur. Bu parçalar embedding adı verilen sayısal temsillere dönüştürülür ve bir vektör veritabanında aranabilir hâle gelir. Kullanıcı soru sorduğunda sistem benzer parçaları getirir; dil modeli de yanıtını bu bağlamı kullanarak üretir.

1. Kaynağı yükle: PDF, Markdown, HTML, DOCX veya veritabanı kaydını al.
2. Temizle ve böl: Başlık, paragraf, tablo ve kod sınırlarını mümkün olduğunca koru.
3. Embedding üret: Her parçayı anlamını temsil eden vektöre dönüştür.
4. Arama yap: Kullanıcı sorusuna en yakın parçaları getir.
5. Yanıt üret: Modeli yalnızca ilgili bağlamla besle ve kaynak göster.

Buradaki kritik nokta, embedding modelinin veya vektör veritabanının tek başına kaliteyi garanti etmemesidir. Yanlış yerden kesilmiş bir içerik, doğru modele gönderilse bile eksik veya yanıltıcı bir bağlam oluşturur.

Parça sınırları neden yanıt kalitesini etkiler?

Bir kullanım kılavuzunda “iade süresi 14 gündür” cümlesini düşünün. Bu cümle, hemen önceki “kampanya ürünleri hariç” ifadesinden ayrılırsa sistem kullanıcıya eksik bilgi verebilir. Aynı metni çevresindeki beş sayfalık içerikle birlikte tek parçaya koyarsanız bu kez arama sonucu gereğinden fazla bilgi taşır.

İyi bir chunk şu üç özelliği mümkün olduğunca birlikte taşır:

• Anlam bütünlüğü: Cümle, maddesi olduğu kuraldan kopmaz.
• Aranabilirlik: Kullanıcının sorusuyla eşleşecek kadar belirgin bir konu içerir.
• Bağlam: Başlık, bölüm veya ürün gibi kimlik bilgileri korunur.

Bu nedenle chunking yalnızca metni her 500 karakterde bir kesmek değildir. Veri kaynağının yapısını ve soruların nasıl sorulacağını birlikte düşünmek gerekir.

Chunking stratejileri: hangisi ne zaman kullanılır?

Yöntem	Nasıl çalışır?	Uygun olduğu yer
Sabit uzunluk	Metni karakter veya token sınırına göre keser.	Hızlı prototip, düzenli ve basit metinler
Recursive / hiyerarşik	Önce paragrafı, sonra satırı ve cümleyi korumaya çalışır.	Genel amaçlı doküman arama
Yapısal	Markdown başlığı, HTML etiketi, fonksiyon veya JSON nesnesini sınır kabul eder.	Teknik doküman, web sayfası, kod ve JSON
Anlamsal	Konu değişimini veya embedding benzerliğini kullanarak böler.	Uzun, düzensiz ve konu geçişleri belirgin metinler

İlk denemede genellikle yapıyı koruyan recursive bir splitter iyi bir başlangıçtır. Resmî LangChain text splitter dokümantasyonu da farklı stratejilerin avantajlarını ayırır ve çoğu kullanım için yapıyı koruyan yaklaşımın denenmesini önerir. Bu bir kural değil, ölçülebilir bir başlangıç hipotezidir.

Chunk boyutu ve overlap için başlangıç değerleri

Chunk boyutunu karakter sayısıyla değil, mümkünse token sayısıyla düşünmek daha sağlıklıdır. Çünkü dil modellerinin bağlam sınırı token üzerinden ölçülür ve farklı dillerde aynı karakter sayısı farklı miktarda anlam taşıyabilir.

İçerik türü	Başlangıç aralığı	Not
SSS ve kısa yardım metni	150–300 token	Tek sorunun cevabını mümkün olduğunca birlikte tut.
Genel açıklama ve politika	300–600 token	Başlık ve ilgili paragrafı koru.
Teknik dokümantasyon	400–800 token	Başlık yolunu metadata olarak ekle.
Kod ve yapılandırma	Fonksiyon veya nesne sınırı	Kod bloklarını ortadan bölme.

Overlap, ardışık parçaların ortak taşıdığı küçük alandır. Başlangıçta chunk boyutunun yaklaşık yüzde 10–15’i kadar overlap denenebilir. Ancak overlap arttıkça aynı cümleleri defalarca indekslersiniz; bu da depolama maliyetini ve arama gürültüsünü yükseltebilir. En doğru değer, test sorularınızda ölçülen sonuçla belirlenir.

Adım adım daha iyi RAG chunking tasarlama

1. Kaynağı normalize edin

Chunking işleminden önce PDF başlıklarını, sayfa alt bilgilerini, menü tekrarlarını ve OCR hatalarını temizleyin. Her sayfanın sonunda tekrar eden “Gizli bilgi” veya web sitesinin menüsü ayrı bir chunk olarak kalırsa, arama sonuçlarında işe yaramayan içerik öne çıkabilir.

Temizleme adımını geri döndürülebilir yapın. Ham dosyayı saklayın; normalize edilmiş metni ve hangi dönüşümlerin uygulandığını ayrıca kaydedin. Böylece yanlış bir yanıt gördüğünüzde sorunun kaynakta mı, chunking’de mi, embedding’de mi olduğunu ayırabilirsiniz.

2. Önce belge yapısını koruyun

Markdown veya HTML belgesini düz metne çevirip rastgele kesmek yerine başlıkları ve bölüm yollarını koruyun. Örneğin bir parçada sadece “Önbellek” yazması yerine metadata içinde Geliştirme > Performans > Önbellek bilgisi bulunabilir. Bu bilgi hem arama sonuçlarını açıklanabilir kılar hem de modelin parçanın bağlamını anlamasına yardımcı olur.

Tablolar için her satırı tek başına anlamsız hâle getirmeyin. Tablo başlığını, sütun adlarını ve ilgili açıklamayı satırla birlikte taşıyın. Gerekirse tabloyu doğal dil cümlelerine dönüştürüp ayrı bir indeksleme formatı oluşturun.

3. Sert token sınırını ikinci aşamada uygulayın

Önce paragraf, bölüm veya fonksiyon gibi anlamlı birimleri koruyun. Bu birimler çok büyüdüğünde onları daha küçük parçalara ayırın. Böylece “tam 500 token” hedefi uğruna cümlenin ortasından kesme ihtimalini azaltırsınız.

4. Metadata’yı chunk’ın ayrılmaz parçası sayın

Her parça için en az şu alanları düşünün:

• document_id ve kaynak dosyanın sürümü,
• section_path veya başlık hiyerarşisi,
• sayfa, bölüm veya paragraf konumu,
• kaynak URL’si ve güncellenme tarihi,
• erişim kapsamı veya tenant bilgisi.

Metadata yalnızca filtreleme için değildir. Kullanıcıya kaynak göstermek, eski sürümün yanıt üretmesini önlemek ve aynı başlıktaki içerikleri ayırmak için de kullanılır. Özellikle çok müşterili uygulamalarda erişim kapsamını metadata filtresi olarak uygulamadan arama yapmayın.

5. Aynı sorularla farklı ayarları karşılaştırın

Chunk boyutunu değiştirip “cevaplar daha iyi gibi” demek yerine küçük bir test seti oluşturun. Gerçek kullanıcı sorularından veya uzmanların yazdığı örneklerden 20–50 soru seçin. Her sorunun beklenen kaynak bölümü belli olsun. Sonra farklı chunking ayarlarını aynı embedding ve retriever ile karşılaştırın.

Basit metrikler yeterlidir:

• Hit@k: Beklenen kaynak ilk k sonuç içinde bulunuyor mu?
• Kaynak yeterliliği: Getirilen parçalar soruyu cevaplamak için gerekli bilgiyi içeriyor mu?
• Gereksiz bağlam: İlk sonuçlar aynı cümleleri tekrar ediyor mu?
• Yanıt doğruluğu: Model, kaynakta olmayan bir iddia ekliyor mu?
• Gecikme ve maliyet: Kalite artışı ek token ve sorgu maliyetine değiyor mu?

Python ile basit bir başlangıç örneği

Aşağıdaki örnek, yapıyı koruyan bir splitter ile başlangıç deneyi kurar. Değerler evrensel doğru değildir; kendi test setinizle değiştirin.

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=700,
    chunk_overlap=80,
    separators=["\n\n", "\n", ". ", " ", ""]
)

chunks = splitter.create_documents(
    [document_text],
    metadatas=[{
        "document_id": "urun-kilavuzu-v3",
        "section_path": "Kurulum > Sorun Giderme",
        "source_version": "3.0"
    }]
)

for index, chunk in enumerate(chunks):
    print(index, len(chunk.page_content), chunk.metadata)

Üretim ortamında sadece page_content alanını indekslemek yerine metadata filtrelerini, belge sürümünü ve erişim yetkisini de akışa dahil edin. LangChain’in retrieval mimarisi dokümantasyonu da yükleyici, splitter, embedding, vector store ve retriever bileşenlerinin ayrı değerlendirilebileceğini gösterir.

Sık yapılan RAG chunking hataları

• Her dosyada aynı boyutu kullanmak: SSS, kod, sözleşme ve teknik kılavuz aynı parçalama stratejisini gerektirmez.
• Başlıkları düşürmek: Parça doğru cümleyi içerir ama hangi bölümden geldiği anlaşılmaz.
• Aşırı overlap kullanmak: Sonuç listesi benzer kopyalarla dolar ve farklı kaynaklar görünmez.
• PDF’yi görsel gibi ele almak: Tablo, sütun ve dipnot sırası bozulduğunda metin araması yanıltır.
• Güncel olmayan sürümleri indekslemek: Eski ve yeni politika aynı anda getirilebilir.
• Sadece üretim yanıtını ölçmek: Sorun retrieval aşamasındaysa promptu değiştirerek gerçek nedeni gizlersiniz.
• Erişim kontrolünü geç uygulamak: Kullanıcı görmemesi gereken parçayı model bağlamına almadan önce filtreleyin.

Uygulama öncesi kontrol listesi

• Belge başlıkları, tabloları ve kod blokları korunuyor mu?
• Chunk sınırı cümleyi veya kuralı anlamsız biçimde bölüyor mu?
• Boyut token olarak ölçülüyor mu?
• Overlap oranı test edilerek mi seçildi?
• Her chunk’ın kaynak ve sürüm metadata’sı var mı?
• 20–50 soruluk sabit bir değerlendirme seti oluşturuldu mu?
• Hit@k, kaynak yeterliliği, gecikme ve maliyet kaydediliyor mu?
• Eski sürüm ve yetkisiz belge aramadan filtreleniyor mu?
• Model, kaynakta olmayan bilgi üretirse kullanıcıya belirsizliği gösterebiliyor mu?

Sonuç

Yapay zekâda RAG chunking, belgeyi küçültme işlemi değil; bilgiyi aranabilir anlam birimlerine dönüştürme tasarımıdır. İyi bir başlangıç için önce kaynağın yapısını koruyun, sonra token sınırı ve overlap ile kontrollü biçimde küçültün. Metadata’yı baştan ekleyin ve her değişikliği aynı soru setiyle ölçün.

En iyi chunk boyutu, başka bir projenin ayarını kopyalayarak bulunmaz. Kendi kullanıcı sorularınız, belge türünüz ve maliyet sınırınız için küçük deneyler yaparak bulunur. Bu yaklaşım, model değiştirmeden de RAG yanıtlarının isabetini ve açıklanabilirliğini artırabilir.

Sık sorulan sorular

RAG chunking için ideal chunk boyutu nedir?

Tek bir ideal değer yoktur. Kısa SSS metinleri daha küçük, teknik dokümanlar daha geniş parçalarla başlayabilir. 300–600 token aralığı genel metin için test edilebilir bir başlangıçtır; sonuçları hit@k ve yanıt doğruluğuyla karşılaştırın.

Overlap her zaman gerekli midir?

Hayır. Başlık ve paragraf sınırlarını iyi koruyan dokümanlarda düşük overlap yeterli olabilir. Cümleler bölüm sınırlarında kopuyorsa yüzde 10–15 civarı bir başlangıç değeri denenebilir.

PDF dosyaları nasıl bölünmelidir?

Önce metin, tablo, başlık ve sayfa düzeninin doğru çıkarıldığını kontrol edin. Sütunlu veya taranmış PDF’lerde OCR ve düzen analizi yapılmadan chunking uygulamak, doğru görünen ama yanlış sıralanmış parçalar üretebilir.

Chunking değiştiğinde embedding’leri yeniden üretmek gerekir mi?

Evet. Parçaların sınırı veya içeriği değiştiğinde embedding temsili de değişir. Yeni indeks ile eski indeksi karıştırmamak için veri seti sürümü veya indeks kimliği kullanın.

İleri okuma

Yaklaşımın teknik ayrıntıları için LangChain text splitters ve LangChain retrieval dokümantasyonuna göz atabilirsiniz.