RAG Sistemlerinde Doğru Chunk Boyutu Nasıl Seçilir?

Büyük dil modellerinin kurumsal verilerle buluştuğu noktada RAG Sistemlerinde Doğru Chunk Boyutu Nasıl Seçilir? sorusu, sistemin bilgi geri çağırma doğruluğunu, yanıt kalitesini ve operasyonel maliyetlerini belirleyen temel mimari karardır. Metinlerin vektör veri tabanına işlenmeden önce hangi uzunlukta parçalara ayrılacağı; embedding modelinin semantik temsil gücünden LLM bağlam penceresi sınırlarına, gecikme süresinden API faturalandırmasına kadar tüm boru hattını doğrudan etkiler. Bu teknik rehber; işletmelerin, yapay zeka mühendislerinin ve teknik karar vericilerin veri tiplerine uygun chunk boyutunu ve overlap oranını matematiksel ve operasyonel kriterlerle nasıl belirleyeceğini kapsamlı biçimde açıklamaktadır.

RAG Sistemlerinde Chunk Boyutunun Belirlenmesi Neden Stratejik Bir Karardır?

Geri Çağırma ile Zenginleştirilmiş Üretim (Retrieval-Augmented Generation - RAG) mimarilerinde "chunking" (metin parçalama), ham dokümanların vektör veri tabanlarına indekslenmeden önce mantıksal ve yönetilebilir metin bloklarına bölünmesi işlemidir. Bu işlem ilk bakışta basit bir metin bölme adımı gibi görünse de, tüm retrieval (geri çağırma) ve generation (üretim) döngüsünün omurgasını oluşturur. Bir metin parçasının boyutu, o parçanın taşıdığı anlamsal bilginin embedding vektörü tarafından ne kadar net yakalanacağını doğrudan belirler. Yanlış yapılandırılmış bir parçalama stratejisi, en gelişmiş LLM (Large Language Model) ve en yüksek boyutlu embedding modelleri kullanılsa dahi sistemin yanlış veya ilgisiz yanıtlar üretmesine yol açar.

Chunk boyutu kararı; bilgi geri çağırma doğruluğu (retrieval accuracy), sistem gecikmesi (latency), bağlam penceresi (context window) optimizasyonu ve toplam sahip olma maliyeti (TCO) arasında çok değişkenli bir optimizasyon problemidir. Bir dokümanı çok küçük parçalara (örneğin 64 veya 128 token) ayırdığınızda, metnin bağlamını ve cümleler arası nedensellik ilişkilerini parçalamış olursunuz. Buna karşılık metni gereğinden büyük bloklar (örneğin 1500 veya 2048 token) halinde böldüğünüzde, embedding vektörü metnin genel temasını yakalasa da spesifik olguları, rakamsal verileri ve mikro detayları seyreltir; bu durum "semantik gürültü" (semantic noise) oluşmasına neden olur.

Kurumsal karar vericiler açısından bu optimizasyonun doğrudan finansal yansımaları mevcuttur. Her retrieval çağrısında büyük dil modeline beslenen gereksiz token hacmi, her bir API çağrısının girdi maliyetini katlar. OpenAI GPT-4o, Anthropic Claude 3.5 Sonnet veya Google Gemini 1.5 Pro gibi önde gelen modellerde milyon girdi tokenı başına ücretlendirme yapıldığından, bağlama eklenen her gürültülü chunk doğrudan operasyonel bütçeyi tüketir. Ayrıca, gereksiz büyük bağlamlar modellerin "lost in the middle" (ortada kaybolma) fenomeni yaşamasına yol açarak sistemin doğru veriye odaklanmasını zorlaştırır.

+-----------------------------------------------------------------------------------+
|                           RAG PİPELINE CHUNKING AKIŞI                             |
+-----------------------------------------------------------------------------------+
| [Ham Kurumsal Doküman] (PDF, DOCX, HTML, SQL)                                     |
|        │                                                                          |
|        ▼                                                                          |
| [Metin Temizleme & Ayrıştırma] (Yapısal formatlama, metadata çıkarma)            |
|        │                                                                          |
|        ▼                                                                          |
| [Chunking & Overlap Motoru] ───► Belirlenen Token Boyutu (C) & Örtüşme Payı (O)   |
|        │                                                                          |
|        ▼                                                                          |
| [Embedding Modeli] (Dense Vector Üretimi: 768 / 1536 / 3072 Boyut)               |
|        │                                                                          |
|        ▼                                                                          |
| [Vektör Veri Tabanı] (Pinecone, Qdrant, Milvus, pgvector - HNSW/IVF İndeksleme)   |
|        │                                                                          |
|        ▼ (Kullanıcı Sorgusu Geldiğinde)                                           |
| [K-NN Semantik Arama + Re-ranking] ──► LLM Bağlam Penceresine Enjeksiyon         |
+-----------------------------------------------------------------------------------+

Teknik açıdan bakıldığında, doğru chunk boyutu dokümanın doğal semantik sınırlarına sadık kalmalıdır. Paragraf geçişleri, maddeleme işaretleri, alt başlıklar ve tablo sınırları göz ardı edilerek salt karakter veya rastgele kelime sayısına göre yapılan sabit parçalamalar, cümle ortasında anlam kırılmalarına yol açar. Bu durum vektör uzayında cosine similarity (kosinüs benzerliği) veya dot product (nokta çarpım) metriklerinin yanıltıcı sonuçlar vermesine neden olur. Başarılı bir RAG mimarisi, veri kaynağının tipolojisini anlayan ve bunu LLM'in anlama kapasitesiyle eşleştiren bir chunking yaklaşımını şart koşar.

Chunk Boyutunun RAG Performansına Etkileri ve Teknik Risk Analizi

Chunk boyutunu yapılandırırken karşılaşılan temel mühendislik ikilemi, hassasiyet (precision) ile bağlam kapsamı (recall) arasındaki dengedir. Bilgi geri çağırma sistemlerinde bir sorguya karşılık gelen en alakalı doküman parçalarının getirilmesi hedeflenir. Ancak getirilen parçanın tek başına taşıdığı anlam ile parçanın ait olduğu geniş metin bloğu arasındaki ilişki doğru ayarlanmazsa, sistem ya eksik bilgi nedeniyle yetersiz çıkarım yapar ya da aşırı bilgi nedeniyle doğru cevabı ayırt edemez.

Aşağıdaki denklem, RAG sisteminde bir doküman havuzunun ($D$) parçalanması sonucunda oluşan chunk kümesini ($C$) ve her bir chunk'ın embedding vektörüne dönüştürülmesini temsil eder:

Burada $d$ embedding modelinin vektör boyutunu (örneğin OpenAI text-embedding-3-small için 1536, text-embedding-3-large için 3072, BGE-Large için 1024) ifade eder. Vektör boyutu sabitken, chunk boyutu ($|c_i|$) büyüdükçe tek bir vektöre sıkıştırılmaya çalışılan semantik bilgi yoğunluğu artar. Bu durum bilgi sıkıştırma kaybına (information compression loss) yol açar.

Küçük Chunk Boyutları (128 - 256 Token): Yüksek Hassasiyet, Düşük Bağlam

Küçük chunk yapılandırmaları, metnin çok dar aralıklarla (genellikle 1 ila 3 cümle) bölünmesini ifade eder. Bu yaklaşımın en belirgin avantajı, vektör veri tabanında yapılan benzerlik aramasının son derece yüksek hassasiyetle (high precision) sonuç vermesidir. Embedding modeli, 128 tokenlık bir metin parçasının temsil ettiği ana fikri son derece net bir vektöre dönüştürebilir. Kullanıcı çok spesifik bir soru sorduğunda (örneğin "X ürününün garanti süresi kaç aydır?"), doğrudan ilgili cümleyi içeren chunk en yüksek benzerlik skoruyla getirilir.

Bununla birlikte, küçük chunk boyutları ciddi bir "bağlamsal körlük" (contextual blindness) riski taşır. Metnin genelindeki koşul cümleleri, istisnalar veya bir önceki paragrafta tanımlanan zamirler (örneğin "Bu şirket...", "Bahsi geçen düzenleme...") parçalandığı için chunk bağımsız bir anlam ifade edemeyebilir. LLM'e sadece bu izole parça iletildiğinde, model metnin arkasındaki koşulu göremez ve hatalı genellemeler yapabilir. Ayrıca, kapsamlı bir cevabın oluşturulması için birden fazla küçük chunk'ın getirilmesi ($Top\text{-}K$ değerinin artırılması) gerekir; bu da vektör aramasında getirme karmaşıklığını yükseltir ve birbirini tekrar eden parçaların bağlamı doldurmasına yol açabilir.

Büyük Chunk Boyutları (1024 Token ve Üzeri): Geniş Bağlam, Yüksek Gürültü

Büyük chunk stratejisi, genellikle birden fazla paragrafı, uzun alt bölümleri veya bütünsel metin bloklarını kapsayan 1024 ila 2048 tokenlık parçaları içerir. Bu yöntemin temel avantajı, metnin mantıksal akışını, argüman bütünlüğünü ve arka plan bilgilerini tek bir parça içinde eksiksiz koruyabilmesidir. LLM, üretilecek yanıt için ihtiyaç duyduğu tüm yan bilgileri aynı bağlam bloğu içinde bulur; böylece cümleler arası bağlantı kopukluklarından kaynaklanan anlama hataları minimuma iner.

Büyük chunk boyutlarının teknik riski ise "semantik seyreltme" ve "vektör gürültüsü"dür. 1500 tokenlık bir metin içerisinde 10 farklı konu veya alt olgu işleniyor olabilir. Bir embedding modeli bu metni tek bir vektöre indirgediğinde, metnin genel ağırlık merkezini temsil eden bir vektör üretir. Kullanıcı metnin kıyısında köşesinde geçen spesifik bir detay hakkında soru sorduğunda, chunk'ın genel vektörü bu spesifik sorguyla düşük benzerlik skoru üretebilir ve arama motoru bu parçayı ilk sıralarda getiremeyebilir ($False\text{ }Negative$ oranı artar). Ayrıca, LLM'e aktarılan büyük metin blokları içinde doğru bilgi yer alsa bile, modelin bağlam içindeki gereksiz ayrıntılara takılarak asıl sorudan sapması (distraction) ve üretim gecikmesinin (time-to-first-token) artması kaçınılmaz hale gelir.

Orta Segment Chunk Boyutları (512 Token): Denge Noktası ve Sınırları

Endüstriyel RAG uygulamalarında en yaygın varsayılan başlangıç noktası 400 ila 512 token aralığıdır. Bu aralık, yaklaşık 300-400 kelimelik bir metin hacmine karşılık gelir ve tipik bir kurumsal dokümanda 2-3 tutarlı paragrafı kapsar. 512 tokenlık bir parça, hem embedding modelinin spesifik kavramları kaybetmeden yakalamasına olanak tanır hem de LLM'e yeterli düzeyde yerel bağlam sağlar.

Ancak 512 token sihirli bir formül değildir. Veri tabanınız çok kısa ve birbirinden bağımsız müşteri mesajlarından oluşuyorsa 512 token gereksiz dolgu yaratır; buna karşılık çok sayfalı hukuki sözleşmelerde bir maddenin tüm fıkralarını ve atıflarını 512 tokene sığdırmak madde bütünlüğünü bozabilir. Dolayısıyla orta segment, optimize edilmemiş bir genel kabulden ziyade, üzerine senaryo bazlı ince ayar yapılması gereken bir referans noktası olarak değerlendirilmelidir.

Doğru Chunk Boyutunu Belirleme Metodolojisi: Adım Adım Yol Haritası

Chunk boyutunu rastgele tahminlerle belirlemek yerine, verinin morfolojisinden model parametrelerine kadar uzanan analitik bir metodoloji izlenmelidir. Bu süreç, deneme-yanılma maliyetlerini düşürürken üretim ortamında istikrarlı bir performans elde edilmesini sağlar.

Adım 1: Veri Kaynağının Yapısını ve Semantik Bütünlüğünü Analiz Edin

İlk aşama, RAG sistemine beslenecek dokümanların iç yapısını ve bilgi yoğunluğunu sınıflandırmaktır. Ham veriler yapılandırılmamış (unstructured), yarı yapılandırılmış (semi-structured) veya yapılandırılmış (structured) formatlarda olabilir. Her format farklı bir parçalama stratejisi gerektirir:

• Düzyazı ve Anlatı Metinleri: Paragrafların mantıksal bir sıra izlediği kurumsal raporlar veya makalelerde, parçalama sınırları doğrudan paragraf sonlarına (\n\n) veya cümle bitişlerine (. , ? , !) hizalanmalıdır. RecursiveCharacterTextSplitter gibi yinelemeli ayırıcılar bu senaryoda önce çift satır başlarını, yetmezse tek satır başlarını, ardından boşlukları referans alarak semantik kırılmayı engeller.

• Yarı Yapılandırılmış Dokümanlar (Markdown, HTML, PDF): Başlık hiyerarşisinin (#, ##, <h3>) bulunduğu dokümanlarda MarkdownHeaderTextSplitter kullanılmalıdır. Bu yaklaşım, dokümanı doğrudan H2 ve H3 başlıklarına göre ayırarak, chunk boyutunun doğal konu sınırlarıyla örtüşmesini sağlar. Başlık bilgisi chunk'ın metadata alanına eklenerek embedding kalitesi artırılır.

• Tablolar ve Sayısal Veriler: Tablo satırlarını ortadan bölen standart karakter ayırıcılar sayısal verilerin anlamını tamamen yok eder. Tablolar ya JSON/Markdown tablo formatında tek bir chunk olarak korunmalı ya da her satır bağımsız bir metin cümlesine dönüştürülerek (table linearizing) parçalanmalıdır.

Adım 2: Embedding Modeli ve LLM Bağlam Penceresi Uyumunu Kontrol Edin

Kullanılan embedding modelinin mimari sınırları, izin verilen maksimum chunk boyutunu doğrudan sınırlar. Örneğin, popüler açık kaynaklı modellerden all-MiniLM-L6-v2 maksimum 256 token desteklerken, BAAI/bge-large-en-v1.5 512 token, OpenAI text-embedding-3-large ve Cohere embed-v3 ise 8192 tokena kadar giriş kabul edebilir.

Ancak bir embedding modelinin 8192 token desteklemesi, 8192 tokenlık chunklar oluşturmanız gerektiği anlamına gelmez. Vektör uzayında yapılan deneysel çalışmalar, chunk boyutu 512-1024 tokenı aştığında cosine similarity ayrıştırma gücünün logaritmik olarak zayıfladığını göstermektedir. Embedding modeli ile LLM bağlam penceresi arasındaki ilişki şu formülle yönetilmelidir:

Burada $K$, vektör veri tabanından çağrılan chunk adedini ($Top\text{-}K$) temsil eder. Eğer bağlam bütçeniz kısıtlı bir model kullanıyorsanız (örneğin 8k context window), 1000 tokenlık 5 chunk getirmek bağlam penceresinin %60'ından fazlasını doldurur ve modelin akıl yürütme alanını daraltır.

Adım 3: Overlap (Örtüşme Oranı) Stratejisini Matematiksel Olarak Kurgulayın

Overlap (örtüşme payı), birbirini takip eden iki chunk arasındaki paylaşılan metin miktarını ifade eder. Overlap kullanılmadığında ($O = 0$), kritik bir tanım veya sayısal veri tam iki parçanın kesişim noktasına denk gelirse ikiye bölünür ve her iki parçada da anlamsız hale gelir.

Endüstri standardı örtüşme oranı, chunk boyutunun %10'u ile %20'si arasındadır:

Örneğin, 500 tokenlık bir chunk boyutu seçildiyse, örtüşme payı 50 ila 100 token olarak ayarlanmalıdır. Bu pay, cümlelerin yarım kalmasını önlerken vektör veri tabanında aşırı veri tekrarı (redundancy) ve gereksiz depolama maliyeti oluşmasını engeller. Örtüşme oranı %25'in üzerine çıkarıldığında benzer içerikli vektörlerin sayısı artar; bu da arama motorunun aynı bilginin farklı varyasyonlarını getirerek $Top\text{-}K$ çeşitliliğini tüketmesine yol açar.

Chunk 1: [ Token 0 ────────────────────── Token 500 ]
                              │◄── Overlap: 75 Token ──►│
Chunk 2:                     [ Token 425 ────────────────────── Token 925 ]
                                                           │◄── Overlap: 75 Token ──►│
Chunk 3:                                                  [ Token 850 ────────────────────── Token 1350 ]

Adım 4: Gecikme Süresi, Token Tüketimi ve API Maliyet Simülasyonu Yapın

Operasyonel fizibilite için sistemin ölçeklenme maliyetleri önceden modellenmelidir. Chunk boyutu büyüdükçe ve $Top\text{-}K$ arttıkça LLM'e iletilen toplam girdi token hacmi katlanır.

Aşağıdaki simülasyon tablosu, günlük 10.000 sorgu alan bir kurumsal RAG asistanının farklı chunk mimarilerindeki yaklaşık aylık girdi token maliyetlerini ve gecikme projeksiyonlarını göstermektedir (Maliyet hesaplaması ortalama $2.50 / Milyon girdi tokenı üzerinden modellenmiştir):

Bu simülasyon, chunk boyutu ve $Top\text{-}K$ parametrelerinin bütçeyi nasıl 8 kata kadar değiştirebileceğini ortaya koymaktadır. Karar vericiler, hedeflenen doğruluk artışının getirdiği ek maliyet ve gecikme marjını iş hedefleri doğrultusunda tartmalıdır.

Farklı İş Senaryolarına Göre İdeal Chunk ve Overlap Değerleri

Her sektörün ve kurumsal departmanın ürettiği verinin mantıksal derinliği farklıdır. Tek tip bir chunking kuralını tüm işletme verilerine uygulamak kaçınılmaz olarak retrieval başarısızlıklarına yol açar. Aşağıda yaygın kurumsal senaryolar için test edilmiş konfigürasyonlar detaylandırılmıştır.

Yapılandırılmış ve Hukuki Belgeler (Sözleşmeler, Mevzuat)

Hukuki metinler, katı hiyerarşik maddeler, çapraz atıflar ve istisnalar içerir. Bir sözleşmedeki "Madde 12.3: Yukarıdaki yükümlülükler Madde 4'te belirtilen mücbir sebepler halinde askıya alınır" ifadesi tek başına parçalanırsa, model mücbir sebebin ne olduğunu bilemez.

• Önerilen Chunk Boyutu: 700 - 1000 Token

• Önerilen Overlap: 100 - 150 Token (%15)

• Strateji: Doküman madde ve fıkra hiyerarşisine (MarkdownHeaderTextSplitter veya özel Regex ayırıcılar) göre bölünmeli; üst madde başlığı chunk metadata'sına gömülmelidir.

Teknik Dokümantasyon, API Referansları ve Kod Tabanları

Teknik dokümantasyonlar, fonksiyon tanımları, parametre listeleri ve kod blokları barındırır. Kod bloklarının ortadan ikiye bölünmesi syntax hatasına ve anlamsız fonksiyon parçalarına neden olur.

• Önerilen Chunk Boyutu: 400 - 600 Token

• Önerilen Overlap: 50 - 80 Token (%12)

• Strateji: Language bazlı özel splitters (Python, JavaScript, Go veya Markdown AST ayrıştırıcıları) kullanılmalı; her bir fonksiyon veya sınıf tanımı tek bir parça olarak korunmalıdır.

Akademik Makaleler, Kitaplar ve Uzun Formlu Raporlar

Bu kaynaklar, geniş kapsamlı sentez, literatür taraması ve çok adımlı hipotez akışları barındırır. Bilgi tek bir cümlede değil, tüm bölüm boyunca inşa edilir.

• Önerilen Chunk Boyutu: 800 - 1200 Token

• Önerilen Overlap: 120 - 200 Token (%15 - %20)

• Strateji: Hiyerarşik indeksleme (Small-to-Big Retrieval) tercih edilmelidir. İndeksleme 200 tokenlık küçük parçalarla yapılırken, LLM'e iletilen içerik o küçük parçanın ait olduğu 1000 tokenlık ana paragraf (parent chunk) olmalıdır.

Kurumsal AI Güvenliği: Veri Gizliliği, Halüsinasyon Riski ve Uyum

Chunk boyutu seçimi yalnızca teknik bir performans parametresi değil, aynı zamanda kurumsal veri güvenliği, mevzuata uyum ve risk yönetimi konusudur. Metinlerin parçalanması ve vektör veri tabanlarında saklanması sürecinde kişisel verilerin korunması ve erişim denetimlerinin kurgulanması yasal bir zorunluluktur.

Hassas Verilerin Korunması ve KVKK/GDPR Uyumlu Parçalama

6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) ve Avrupa Genel Veri Koruma Tüzüğü (GDPR), kişisel verilerin işlenmesinde veri minimizasyonu ilkesini şart koşar. Ham dokümanlar parçalama motoruna girmeden önce otomatik PII (Personally Identifiable Information - Kişisel Olarak Tanımlanabilir Bilgi) maskeleme katmanından geçirilmelidir. T.C. Kimlik Numaraları, kredi kartı bilgileri, telefon numaraları ve sağlık verileri ayrıştırılmalı veya sentetik verilerle anonimleştirilmelidir.

Chunk boyutu bu noktada erişim kontrolü (Role-Based Access Control - RBAC) açısından kritik rol oynar. Eğer bir chunk çok büyük tutulursa (örneğin 2000 token), içinde hem genel şirket politikası hem de sadece yöneticilerin görmesi gereken bir maaş bütçesi tablosu yer alabilir. Bu chunk genel bir kullanıcı sorgusunda çağrıldığında, LLM tüm bloğu bağlama dahil edeceği için yetkisiz veri sızıntısı (data leakage) riski doğar. Küçük ve modüler chunklar oluşturmak, her bir parçaya detaylı erişim etiketi (metadata filtering: department: "finance", clearance: "level-3") atanmasına imkan tanır ve vektör aramasının doğrudan kullanıcı yetkisiyle filtrelenmesini sağlar.

Halüsinasyon Riskini Azaltma ve İnsan Denetimi (Human-in-the-Loop)

Yapay zeka modelleri, bağlam penceresinde açıkça belirtilmeyen veya parçalanma nedeniyle eksik kalan bilgileri tamamlama eğilimindedir; bu durum "halüsinasyon" (hallucination) olarak adlandırılır. Chunk boyutu çok küçük olduğunda model bilgi boşluklarını kendi parametrik hafızasındaki olasılıksal verilerle doldurur. Chunk boyutu çok büyük olduğunda ise model alakasız detaylar arasında kaybolarak yanlış bağlantılar kurabilir.

Halüsinasyon riskini minimize etmek ve kurumsal güvenilirliği garanti altına almak için şu mimari tedbirler uygulanmalıdır:

1. Katı Sistem Yönergeleri: LLM'e verilen talimatta, cevabın yalnızca sağlanan bağlamdaki chunklara dayandırılması, bağlamda açıkça yer almayan hiçbir bilginin varsayılmaması ve emin olunmadığında "Sağlanan dokümanlarda bu bilgi yer almamaktadır" yanıtının verilmesi kurala bağlanmalıdır.

2. Atıf ve Kaynak Gösterme (Citations): Modelin ürettiği her cümlenin, hangi chunk ID'sinden ve hangi doküman sayfasından alındığı metadata üzerinden kullanıcı arayüzünde doğrulanabilir şekilde referanslanmalıdır.

3. İnsan Denetimi (Human-in-the-Loop): Finansal, hukuki veya kritik operasyonel kararlara temel oluşturan RAG çıktılarında sistemin yanıtı doğrudan nihai işlem olarak uygulanmamalı; teknik uzman veya yetkili personel onay mekanizmasından geçirilmelidir.

RAG Sistemlerinde Performans Ölçümü ve Sürekli Optimizasyon Döngüsü

Chunk boyutunun başarısı statik bir varsayımla değil, somut metriklerle ve sürekli testlerle doğrulanmalıdır. Üretim ortamına alınan bir RAG boru hattı, değişen veri hacimleri ve yeni kullanıcı sorgu desenleri karşısında düzenli olarak değerlendirilmelidir.

Geri Çağırma Doğruluğu (Retrieval Accuracy) Metrikleri

Vektör arama performansını ölçmek için literatürde kabul görmüş üç temel metrik kullanılır:

• Hit Rate@K: Kullanıcı sorusunun doğru cevabını içeren doküman parçasının, sistem tarafından getirilen ilk $K$ adet chunk içinde yer alma oranıdır. Örneğin, 100 test sorgusunun 85'inde doğru parça ilk 5 chunk içinde geliyorsa $Hit\text{ }Rate@5 = 0.85$'tir.

• Mean Reciprocal Rank (MRR): Doğru bilgi parçasının getirilen sonuç listesinde kaçıncı sırada olduğunu ölçer. Eğer doğru parça 1. sıradaysa skor $1$, 2. sıradaysa $1/2 = 0.5$, 3. sıradaysa $1/3 = 0.33$'tür. MRR, sistemin en alakalı cevabı en tepeye çıkarma yeteneğini gösterir:

• Normalized Discounted Cumulative Gain (NDCG@K): Çoklu alakalı chunk durumunda sıralamanın doğruluğunu ve alaka düzeyinin derecesini ağırlıklı olarak hesaplar.

Chunk boyutu optimize edilirken en az 50-100 adet soru ve doğrulanmış cevap çiftinden oluşan bir "Altın Test Kümesi" (Golden Evaluation Dataset) oluşturulmalı; Ragas veya TruLens gibi değerlendirme çatıları kullanılarak farklı chunk boyutlarının Hit Rate ve MRR skorları karşılaştırılmalıdır.

+-----------------------------------------------------------------------------------+
|                        RAG EVALUATION (DEĞERLENDİRME) DÖNGÜSÜ                     |
+-----------------------------------------------------------------------------------+
| [Test Soru Kümesi (Golden Dataset)] ──► [Chunking Konfigürasyonu: 256 / 512 / 1024]
|                                                   │
|                                                   ▼
|                                      [Vektör Arama (Top-K = 5)]
|                                                   │
|                 ┌─────────────────────────────────┴─────────────────────────────────┐
|                 ▼                                                                   ▼
|       [Retrieval Metrikleri]                                              [Üretim Metrikleri]
|    - Hit Rate @ K (Başarı Oranı)                                       - Faithfulness (Sadakat)
|    - MRR (Sıralama Başarısı)                                           - Answer Relevance (Alaka)
|    - NDCG (Kümülatif Kazanç)                                           - Context Precision (Hassasiyet)
|                 │                                                                   │
|                 └─────────────────────────────────┬─────────────────────────────────┘
|                                                   ▼
|                                   [Reranker Entegrasyonu (Cohere/BGE)]
|                                                   │
|                                                   ▼
|                                   [Nihai Parametre Seçimi & Yayına Alma]
+-----------------------------------------------------------------------------------+

LLM Yanıt Kalitesi ve Semantik Re-ranking Entegrasyonu

Retrieval aşamasında getirilen chunklar doğrudan LLM'e verilmek zorunda değildir. Modern RAG mimarilerinde en başarılı yaklaşım, iki aşamalı getirme (Two-Stage Retrieval) stratejisidir:

1. Aşama 1 (Bi-Encoder Retrieval): Vektör veri tabanından daha küçük chunk boyutları (örneğin 256-400 token) ile geniş bir aday havuzu ($Top\text{-}20$ veya $Top\text{-}30$) hızlı ve düşük maliyetle çekilir.

2. Aşama 2 (Cross-Encoder Re-ranking): Çekilen 30 parça, Cohere Rerank 3 veya BGE-Reranker gibi özel bir yeniden sıralama modelinden geçirilir. Re-ranker, kullanıcı sorgusu ile metin parçası arasındaki anlamsal ilişkiyi çok daha derin analiz ederek en alakalı ilk 3-5 parçayı ($Top\text{-}K = 5$) seçer ve LLM bağlamına iletir.

Bu strateji, chunk boyutu seçimindeki hassasiyet-kapsam ikilemini büyük ölçüde çözer. İlk aşamada küçük chunkların yüksek hassasiyetinden faydalanılırken, ikinci aşamada gürültülü parçalar elenerek LLM'e yalnızca en yüksek semantik değere sahip bağlam sunulur.