RAG (Retrieval-Augmented Generation) sisteminde model yanlış cevap verdiğinde suç genelde promptta ya da modelde aranır; oysa sorunun kaynağı çoğu zaman çok daha basit bir yerdedir: retrieval katmanı modele hiç doğru parçayı getirmemiştir. Chunking stratejin, hibrit arama kurulumun ve reranking adımın — üçü birlikte RAG chunking reranking kalitesini belirler ve her biri ayrı bir hata modunu kapatır. Bu yazıda chunking yaklaşımlarından iki-aşamalı reranking'e, retrieval'i recall@k ve MRR ile ölçmeye kadar üretimde çalışan bir kalite mühendisliği döngüsünü adım adım kuruyoruz.
💡 Pro Tip: Yeni bir RAG projesine başlarken chunking'i düzeltmeden reranker eklemeye çalışma — kötü chunk'ları ne kadar iyi sıralarsan sırala, içinde cevap olmayan bir parçadan doğru yanıt çıkmaz.
İçindekiler
- Kötü cevabın kaynağı genelde retrieval
- Chunking stratejileri: sabit, cümle, başlık-bilinçli
- Overlap ve metadata: neyi saklamalı
- Hibrit arama (BM25 + vektör) ne zaman kazanır
- Reranking: iki aşamalı retrieval maliyeti
- Retrieval'i ölçmek: recall@k, MRR, cevap doğruluğu
- Üretimde iyileştirme döngüsü
- SSS
- RAG'de en iyi chunk boyutu nedir?
- Reranker gerçekten gerekli mi, ne kadar kazandırır?
- Retrieval kalitesi nasıl ölçülür (recall@k, MRR)?
- Hibrit arama ne zaman saf vektör aramasını yener?
- Chunk overlap için sabit bir yüzde önerir misin?
- Chunking'i mi önce düzeltmeliyim, hibrit aramayı mı önce kurmalıyım?
- Güncelleme (Eylül 2026)
- Sonuç
- Kaynaklar
Kötü cevabın kaynağı genelde retrieval
Tipik bir RAG akışı üç adımdan oluşur: sorguyu embed et, en yakın k parçayı getir, (varsa) yeniden sırala, sonra bağlamı modele ver. Zincirin en kırılgan halkası genelde ortadaki adımdır. Anthropic'in contextual retrieval çalışmasında ölçülen bir baseline'da, sağlam bir embedding modeliyle bile top-20 retrieval'in ilgili parçayı kaçırma oranı %5,7 çıkmış — yani her 100 sorgudan yaklaşık 6'sında model, doğru cevabı üretebileceği parçayı hiç görmeden yanıt vermek zorunda kalıyor.
Bu yüzden bir RAG yanıtı yanlış geldiğinde ilk kontrol noktası prompt değil, o sorgu için gerçekten neyin getirildiğidir: retrieval loglarına bakmadan prompt'u kurcalamak, çoğu zaman semptomu değil belirtiyi tedavi etmek olur. Ben genelde önce "getirilen top-k chunk'lar arasında cevap fiilen var mıydı?" sorusunu yanıtlarım; yoksa mesele chunking/arama tarafındadır, varsa mesele modelin bağlamı kullanma biçimindedir.
Bu ikisini ayırt etmeden yapılan optimizasyon çoğunlukla yanlış yere gider: prompt'u uzatmak, sistem talimatını sertleştirmek ya da modeli değiştirmek, altta yatan retrieval boşluğunu kapatmaz — yalnızca hatanın nasıl göründüğünü değiştirir. Bu yazının geri kalanı, retrieval'i üç ayrı bileşene (chunking, arama, reranking) bölüp her birini kendi başına ölçülebilir hale getirmeye odaklanıyor; böylece bir iyileştirme denendiğinde hangi bileşenin gerçekten işe yaradığını rakamla görebilirsin, tahminle değil.
Chunking stratejileri: sabit, cümle, başlık-bilinçli
Pinecone'un chunking rehberi, üretimde kullanılan yaklaşımları birkaç ana başlıkta topluyor:
- Sabit boyutlu (fixed-size) chunking: Karakter veya token sayısına göre böler; rehberin varsayılan önerisi budur — basit, öngörülebilir, hızlı kurulur.
- Cümle bazlı chunking: Doğal cümle sınırlarında böler; anlam bütünlüğünü fixed-size'a göre daha iyi korur, ama chunk boyutları düzensizleşir.
- Başlık/yapı-bilinçli (header-aware) chunking: Markdown/HTML başlık hiyerarşisini veya doküman yapısını izler; teknik dokümantasyon ve makale gibi başlıklı içerikte parça sınırlarının yazarın kendi anlam sınırlarıyla örtüşmesini sağlar.
- Semantik chunking: Ardışık cümleler arasındaki embedding benzerliğindeki düşüşe göre sınır belirler; konuşma konusu değiştiğinde böler.
- Contextual chunking: Anthropic'in 2024'te tanıttığı yaklaşımla her chunk'ın başına, o chunk'ı doğru yorumlamak için gereken kısa bir bağlam cümlesi (hangi doküman, hangi bölüm) ekler.
- Chunk-expansion: Getirme sırasında bir chunk seçildiğinde komşu chunk'ları da bağlama ekler, sınırda kesilen cümleleri tamamlar.
Kod tabanı ya da SSS gibi kısa/yapılandırılmış içerikte fixed-size çoğu zaman yeterlidir; uzun, başlıklı dokümantasyonda header-aware chunking, chunk sınırlarının yazarın anlam sınırlarıyla örtüşmesini sağlar ve anlamsal olarak daha tutarlı parçalar üretir. RAG'in temellerini (embedding, vektör arama, benzerlik skorları) daha önce RAG temelleri: embedding ve vektör arama yazısında işlemiştim; bu yazı doğrudan onun devamı sayılabilir.
Overlap ve metadata: neyi saklamalı
Chunk overlap'in amacı, bir cümlenin ya da fikrin iki parçanın sınırına denk gelip yarım kalmasını önlemektir. Tek bir ideal overlap oranı yok: overlap arttıkça sınırda bağlam kaybı azalır ama depolanan/indekslenen veri miktarı ve embedding maliyeti de artar; doğru değer doküman tipine ve chunk boyutuna göre değişir, bu yüzden aşağıda anlatacağım recall@k ölçümüyle deneysel olarak belirlenir.
Metadata tarafında sakladığın alanlar retrieval'den çok üretim kalitesini etkiler: doküman başlığı, bölüm/başlık yolu, kaynak URL, sayfa/versiyon numarası ve indeksleme zamanı gibi alanlar hem modelin kaynak göstermesini hem de filtreli aramayı (örneğin "yalnız şu ürünün dokümantasyonu içinde ara") mümkün kılar. Bu alanları şemalı ve tutarlı tutmak — LLM çıktısında yaptığın gibi — retrieval katmanında da işe yarar; yapılandırılmış şema disiplinini LLM'de yapılandırılmış çıktı ve JSON Schema yazısında detaylandırmıştım. Metadata şemasını en başta netleştirmek, sonradan tüm indeksi yeniden oluşturmaktan çok daha ucuzdur.
Hibrit arama (BM25 + vektör) ne zaman kazanır
Saf vektör arama, anlamca yakın ama farklı kelimelerle yazılmış metinleri bulmakta güçlüdür; ama bir hata kodu, ürün SKU'su ya da nadir bir özel isim gibi tam eşleşme gerektiren sorgularda zayıflayabilir, çünkü embedding uzayında "yakınlık" her zaman "aynı token" anlamına gelmez. Anthropic'in ölçümü bunu somutlaştırıyor: yalnız contextual embeddings kullanan pipeline'da top-20 retrieval başarısızlık oranı baseline'a göre %35 azalarak %3,7'ye inerken, buna contextual BM25 (lexical/hibrit arama) eklendiğinde azalma %49'a çıkıp oran %2,9'a düşüyor. Yani hibrit arama, saf semantik aramanın üstüne lexical eşleşmeyi eklediğinde ek ve ölçülebilir bir kazanç sağlıyor.
Vektör tarafında OpenAI'ın embedding modelleri (text-embedding-3-small: 1536 boyut, MTEB ortalaması %62,3; text-embedding-3-large: 3072 boyut, %64,6; ikisi de kosinüs benzerliğiyle kullanılıyor ve 8192 token girdi limitine sahip) güçlü bir semantik temel verir, ama yukarıdaki veri de gösteriyor ki bu temeli lexical bir katmanla (BM25 gibi) tamamlamak, saf vektör aramaya göre ek doğruluk kazandırıyor. Bu 8192 token limiti, chunk boyutunu seçerken bağlam penceresi maliyetiyle de ilişkilendirmen gereken bir sınır — bu dengeyi LLM'de token, bağlam penceresi ve maliyet temelleri yazısında ayrıca işlemiştim:
python
1def hybrid_score(vector_score: float, bm25_score: float, alpha: float = 0.7) -> float:2 # alpha: vektor skoruna verilen agirlik, (1-alpha): BM25'e3 return alpha * vector_score + (1 - alpha) * bm25_score4 5# ornek: vektor 0.82, BM25 0.416score = hybrid_score(0.82, 0.41, alpha=0.7)7print(round(score, 3)) # 0.7*0.82 + 0.3*0.41 = 0.574 + 0.123 = 0.697Pratikte alpha değerini sabit tutmak yerine sorgu tipine göre (kısa/kod-benzeri sorgularda BM25 ağırlığını artırarak) ayarlamak daha iyi sonuç verir — ben genelde teknik dokümantasyon RAG'lerinde alpha'yı 0.6-0.7 aralığında başlatıp ölçüme göre kalibre etmeyi tercih ederim.
Reranking: iki aşamalı retrieval maliyeti
Anthropic'in pipeline'ı iki aşamalıdır: önce geniş bir aday havuzu (top-150) getirilir, sonra bir reranker bu havuzu daralta daralta nihai top-20'ye indirir. Bu ikinci aşamayı pipeline'a eklemek, baseline'a göre toplam başarısızlık oranını %67 azaltıp %1,9'a indiriyor — yalnız contextual embeddings + BM25 hibritinin sağladığı %2,9'un da altına iniliyor. Yani reranking, hibrit aramanın üstüne konduğunda hâlâ ölçülebilir bir kazanç sağlıyor.
Bunun bir bedeli var: reranker, ilk aşamadan gelen yüz onlarca adayı tek tek (ya da grup grup) puanlamak zorunda, bu da ekstra bir model çağrısı ve gecikme demek. Contextual chunking'in kendisi de bedelsiz değil — her chunk için bağlam cümlesi ürettirmek, prompt caching kullanıldığında milyon token başına 1,02 dolara mal oluyor (bu rakam rerank'ın değil, contextualization adımının maliyeti; ikisini birbirine karıştırmamak gerekir).
Gerçek zamanlı, düşük gecikmeli bir sohbet arayüzünde iki aşamalı retrieval + rerank her zaman mantıklı olmayabilir; reranking adımı ekstra bir model çağrısı kadar gecikme ekler ve bu, kullanıcı yanıtı beklerken fark edilir hâle gelebilir. Ama toplu (batch) işlenen ya da doğruluğun gecikmeden daha kritik olduğu kullanım senaryolarında (hukuki/tıbbi doküman sorgulama, iç bilgi tabanı gibi) bu maliyet genelde kendini amorti eder, çünkü yanlış bir cevabın maliyeti, reranking'in eklediği gecikmeden çok daha yüksektir.
Retrieval'i ölçmek: recall@k, MRR, cevap doğruluğu
Retrieval kalitesini "iyi görünüyor" demeden ölçmenin iki temel metriği var:
- Recall@k: İlgili (ground-truth) parçanın, getirilen ilk k sonuç içinde bulunma oranı. k arttıkça recall artar ama bağlam penceresi de şişer ve modelin ilgisiz içerikle dikkati dağılabilir.
- MRR (Mean Reciprocal Rank): İlk ilgili sonucun kaçıncı sırada geldiğinin tersinin ortalaması; sonuç 1. sırada ise 1, 3. sırada ise 1/3 katkı verir — sıralamanın kalitesini recall'dan daha hassas yakalar.
İkisini birlikte hesaplarken genelde önce recall@k'ya bakarım, çünkü basit bir evet/hayır sorusuna cevap verir: parça ilk k içinde var mı yok mu.
python
1def recall_at_k(hits: list[bool]) -> float:2 # hits[i] = True ise o sorgu icin ilgili parca ilk k sonuc icinde bulundu3 return sum(hits) / len(hits)4 5# 4 sorgu, top-5 icinde ilgili parca bulundu mu6hits = [True, True, False, True]7print(round(recall_at_k(hits), 3)) # 3/4 = 0.75Recall@k tek başına yeterli değil çünkü ilgili parçanın 1. sırada mı yoksa 5. sırada mı geldiğini ayırt etmez; sıralama kalitesini görmek için MRR'a bakmak gerekir:
python
1def mrr(ranks: list[int]) -> float:2 # her sorgu icin ilk ilgili sonucun sirasi (1-indeksli)3 reciprocal = [1 / r for r in ranks]4 return sum(reciprocal) / len(reciprocal)5 6# 3 sorgu: ilk ilgili sonuc sirasiyla 1., 3. ve 2. sirada bulundu7print(round(mrr([1, 3, 2]), 3)) # (1 + 0.333... + 0.5) / 3 = 0.611Bu iki metrik retrieval'in "doğru parçayı getirdi mi" sorusuna cevap verir ama "model o parçayı doğru kullandı mı" sorusuna cevap vermez — bunun için ayrı bir cevap-doğruluğu değerlendirmesi (golden dataset + insan ya da LLM-as-judge) gerekir; bu ayrımı ve golden dataset kurma pratiğini LLM uygulamalarında eval: golden dataset ve LLM-as-judge yazısında ele almıştım. Üretimde ikisini birlikte izlemek gerekir: recall@k düşükse sorun retrieval'de, recall@k yüksek ama cevap yanlışsa sorun promptlama ya da modelin bağlamı kullanma biçimindedir.
Üretimde iyileştirme döngüsü
Retrieval kalitesi tek seferlik bir ayar değil, sürekli bir döngüdür: her sorgu ve getirilen chunk'lar loglanır, düzenli aralıklarla golden set üzerinde recall@k ve MRR yeniden hesaplanır, düşüş görülen sorgu kümeleri incelenir (chunk boyutu mu küçük, hibrit ağırlık mı yanlış, yoksa doküman hiç indekslenmemiş mi), ilgili parametre değiştirilir, yeniden indekslenir ve ölçüm tekrarlanır.
bash
1# basit bir offline degerlendirme dongusu (pseudocode)2# run-tag: CHUNKRUN013for query in golden_set.jsonl; do4 retrieved=$(rag_retrieve --query "$query" --top-k 20)5 echo "$retrieved" | eval_recall_mrr --ground-truth golden_set.jsonl >> metrics.log6done7# metrics.log trend asagi giderse chunk/hibrit/rerank parametrelerini gozden gecirGolden set'i tek seferlik hazırlayıp bir kenara bırakmak da hata olur: kullanıcıların gerçekten sorduğu ama sistemin zayıf kaldığı sorgular üretim loglarından düzenli olarak golden set'e eklenmeli, çünkü kullanıcı davranışı ve doküman içeriği zamanla değişiyor. Bir chunk boyutu ya da hibrit ağırlık değişikliğini üretime almadan önce, bu değişikliği yalnızca golden set üzerinde değil, en azından son birkaç haftanın gerçek sorgu örnekleminde de test etmek, laboratuvar koşullarında iyi görünen bir ayarın üretimde beklenmedik biçimde kötüleşmesini önler.
Bu döngüyü tek seferlik bir manuel kontrol değil, ajan-tabanlı sistemlerde otomatikleştirmek de mümkün: retrieval'i tek seferlik bir çağrı değil, modelin kendi kararıyla tekrar sorgu attığı bir araç (tool) olarak modellemek, örneğin MCP (Model Context Protocol) ile AI entegrasyonu yazısında anlattığım gibi, modelin "bu sonuçlar yetersiz, farklı bir sorguyla tekrar dene" demesine izin verir; bu da özellikle çok adımlı, karmaşık sorularda tek-atışlık retrieval'e göre daha dayanıklı bir davranış ortaya çıkarır.
ALTIN İPUCU
Bu yazının en değerli bilgisi
Bu ipucu, yazının en önemli çıkarımını içeriyor.
Easter Egg
Gizli bir bilgi buldun!
Bu bölümde gizli bir bilgi var. Keşfetmek ister misin?
Okuyucu Ödülü
RAG kalite mühendisliğine yeni başlıyorsan aşağıdaki checklist, chunking'den ölçüme kadar hangi sırayla ilerlemen gerektiğini özetliyor; her maddeyi tek tek uygulayıp bir sonrakine geçmeden önce recall@k'da gördüğün değişikliği not et.
SSS
RAG'de en iyi chunk boyutu nedir?
Tek bir "en iyi" boyut yok; Pinecone'un rehberi bile varsayılan olarak sabit boyutlu chunking'i önerirken, yapılandırılmış dokümanlarda Markdown başlık hiyerarşisini izlemenin anlamsal olarak daha tutarlı parçalar ürettiğini belirtiyor. Doğru yaklaşım, birkaç chunk boyutunu kendi golden set'inde recall@k ile karşılaştırmaktır.
Reranker gerçekten gerekli mi, ne kadar kazandırır?
Anthropic'in ölçümünde contextual embeddings + BM25 hibriti top-20 başarısızlık oranını baseline'a göre zaten %49 azaltıyor (%2,9); reranker eklemek bunu %67 azalmaya (%1,9) taşıyor. Yani gerekli değil ama ölçülebilir bir ek kazanç sağlıyor — asıl soru bu kazancın ek gecikmeye değip değmediği.
Retrieval kalitesi nasıl ölçülür (recall@k, MRR)?
Recall@k, ilgili parçanın ilk k sonuç içinde olma oranını; MRR ise ilk ilgili sonucun sırasının tersinin ortalamasını verir. İkisi de bir golden set (sorgu + doğru kaynak eşleşmesi) gerektirir ve düzenli aralıklarla yeniden hesaplanmalıdır.
Hibrit arama ne zaman saf vektör aramasını yener?
Sorguda tam eşleşmesi gereken bir terim (hata kodu, ürün adı, nadir isim) olduğunda hibrit arama saf vektör aramayı geride bırakır; Anthropic'in verisinde contextual BM25 eklemek, yalnız embeddings kullanmaya göre başarısızlık oranını ek olarak azaltıyor.
Chunk overlap için sabit bir yüzde önerir misin?
Hayır — sabit bir sayı vermek yerine golden set üzerinde birkaç değeri deneyip recall@k'ya bakmanı öneririm; doğru değer doküman tipine göre değişir.
Chunking'i mi önce düzeltmeliyim, hibrit aramayı mı önce kurmalıyım?
İkisi birbirini engellemiyor ama sıra önemli: chunk sınırları doküman yapısına uymuyorsa hibrit arama da, reranker de bozuk parçaları düzeltemez, çünkü bulunacak doğru içerik zaten yarım kesilmiş olabilir. Bu yüzden önce doküman tipine uygun chunking'i (header-aware ya da fixed-size) oturt, ardından hibrit aramayı ekle, en son da gerekiyorsa reranking'i devreye al — yani sıralama chunking, sonra hibrit arama, en son reranking.
Güncelleme (Eylül 2026)
Bu yazı Mart 2026'daki araç ve mimarilerle yazıldı; Eylül 2026 itibarıyla alan iki eksende ilerledi. Birincisi, chunking'i büyük ölçüde embedding modeline devreden yaklaşımlar: Voyage AI'ın 29 Haziran 2026'da duyurduğu voyage-context-4, dokümanı tek geçişte tam bağlamıyla encode ederek "chunking'den endişelenmeyi bırakın" pozisyonu alıyor ve kendi ölçümlerinde chunk-seviyesinde voyage-context-3'e göre +%2,08 kazanç bildiriyor; LongEmbed değerlendirmesinde ise aynı dokümanları tek vektör olarak gömmek yerine contextualized chunk embedding kullanmak +%7,11 kazandırıyor (blog.voyageai.com, 29 Haz 2026). İkincisi, reranker'ların küçülüp hızlanması: jina-reranker-v3.5 (03 Ağu 2026), 0,6 milyar parametreyle önceki sürüme göre BEIR'de 62,10'dan 63,20'ye çıkarken uzun dokümanlarda ortalama gecikmeyi 1,56 kat düşürdüğünü, ama çok dilli ve yapılandırılmış IR görevlerinde kendinden yaklaşık 7 kat büyük Qwen3-Reranker-4B'nin gerisinde kaldığını raporluyor (jina.ai) — yani "küçük ve hızlı her zaman kazanır" değil, göreve göre değişir.
Akademik tarafta 24 Eylül 2026'da yayımlanan ChunkRank çalışması (arXiv:2609.29828) dikkat çekici bir olumsuz bulgu paylaşıyor: üç QA veri setinde (NaturalQuestions, TriviaQA, HotpotQA) cevap seçiminde (retrieval reranking'de değil) içerik-tabanlı sıralayıcıların, modelin ilk boş-olmayan cevabı almasından güvenilir biçimde daha iyi olmadığını gösteriyor. Ayrıca Microsoft, Azure AI Search'te Nisan 2026'da "knowledge base" adı altında GA'ya çıkardığı yapıya Ağustos 2026'da eklediği otomatik retrievalReasoningEffort ayarıyla (önizleme), hafif bir ilk retrieval geçişinden yetersiz kaldığında LLM tabanlı sorgu planlamasına (en fazla medium efor) yükselen adaptif bir akış getirdi; reranking'i tamamen atlama ise aynı ayki ayrı bir özellik olan per-source resultsProcessing: none ayarıyla (önizleme) geliyor (learn.microsoft.com/azure/search/whats-new). Vektör veritabanı seçimi bu yazının kapsamı dışında; o karşılaştırmayı Pinecone, Weaviate, Qdrant vektör veritabanı karşılaştırması yazısında bulabilirsin.
Sonuç
RAG chunking reranking kalitesi, tek bir "sihirli" ayar değil, doküman yapına uygun chunking, tam-eşleşme gerektiren sorguları yakalayan hibrit arama ve yalnızca gerektiğinde eklenen reranking'in birlikte çalıştığı bir sistemdir. Temellerini RAG temelleri: embedding ve vektör arama yazısında, metadata şemasını LLM'de yapılandırılmış çıktı ve JSON Schema yazısında, ölçüm disiplinini LLM uygulamalarında eval: golden dataset ve LLM-as-judge yazısında, üretim döngüsünü otomatikleştirmeyi MCP ile AI entegrasyonu yazısında derinleştirebilirsin. Kurduğun sistemi tek bir "iyi görünüyor" hissiyle değil, kendi golden set'in üzerinde recall@k ve MRR ile düzenli ölçerek ilerlet.
Kaynaklar
- Pinecone — Chunking Strategies — fixed-size, cümle-bazlı, başlık-bilinçli, semantik, contextual ve chunk-expansion chunking yaklaşımlarının rehberi.
- Anthropic Engineering — Contextual Retrieval — baseline top-20 başarısızlık oranı, contextual embeddings/BM25/rerank katkıları ve iki-aşamalı retrieve→rerank pipeline'ı.
- OpenAI — Embeddings guide — text-embedding-3-small/large boyutları, MTEB skorları ve token limiti.
- Voyage AI — voyage-context-4 duyurusu — dokümanı tam bağlamıyla encode eden embedding modeli.
- Jina AI — jina-reranker-v3.5 — küçük/hızlı reranker'ın BEIR ve çok dilli arama karşılaştırması.
- arXiv — ChunkRank (2609.29828) — cevap seçiminde içerik-tabanlı sıralayıcıların ilk boş-olmayan cevaba üstünlüğünü sorgulayan çalışma.
- Microsoft Learn — Azure AI Search what's new — knowledge base GA ve adaptif retrieval reasoning effort.
