Doğru Dosya Geliyor Ama Cevap Neden Hâlâ Yanlış? RAG Sistemlerinde Chunking, Evidence Selection ve Grounding Rehberi

Kurumsal soru-cevap sistemlerinde en kafa karıştırıcı başarısızlıklardan biri şudur: Sistem sorguya cevap verirken gerçekten doğru dokümanı bulur; hatta log’lara bakıldığında ilgili dosya retrieval sonuçları içinde görünür. Buna rağmen üretilen cevap eksik, yanlış, aşırı genel veya bazen tamamen yanıltıcı olabilir. Bu durum ekiplerde çoğu zaman şu refleksi doğurur: “Model zayıf, daha büyük model kullanalım.” Oysa pratikte sorun çoğu zaman modelin genel kapasitesinden değil, retrieval zincirinin dosya seviyesinden evidence seviyesine geçerken kırılmasından kaynaklanır.

Buradaki temel yanılgı şudur: doğru dosyanın gelmesi ile doğru cevabın üretilmesi aynı şey değildir. Bir doküman birçok başlık, alt başlık, tablo, madde, dipnot, istisna ve versiyon bilgisi içerebilir. Kullanıcının sorduğu cevap o dokümanın yalnızca tek bir bölümünde, hatta bazen tek bir paragrafında veya iki farklı bölümün birlikte yorumlanmasında saklı olabilir. Eğer retrieval sistemi yalnızca “ilgili dosya” düzeyinde başarı gösteriyor ama cevabı taşıyan gerçek pasajı öne çıkaramıyorsa, dosya doğru olsa bile cevap yanlış kalabilir. Bu nedenle kurumsal RAG mimarisinde asıl kalite problemi çoğu zaman document retrieval değil, evidence selection problemidir.

Üstelik bu problem tek bir kökten beslenmez. Cevabı taşıyan metin chunking sırasında bölünmüş olabilir. Sabit boyutlu chunk’lar başlık ve paragraf bütünlüğünü bozmuş olabilir. Doğru bölüm top-k içine girmiş ama çok gürültülü başka parçalar arasında kaybolmuş olabilir. Reranker en güçlü kanıtı seçememiş olabilir. Context assembly katmanı, en destekleyici parçaları değil sadece ilk benzer parçaları modele göndermiş olabilir. Son adımda ise model retrieved bağlama sadık kalmak yerine kendi genel bilgisini veya istatistiksel tahminini araya katmış olabilir. Kullanıcı tarafında görünen tek sonuç ise basittir: “Doğru belge var ama cevap yine de yanlış.”

Bu yazıda bu problemin mimarisini uçtan uca ele alacağım. Önce neden doğru dosya seviyesinde başarı ile doğru answer grounding’in farklı şeyler olduğunu açıklayacağım. Ardından chunking, retrieval granularity, reranking, context assembly, prompt tasarımı ve model davranışı gibi katmanları ayrı ayrı inceleyeceğim. Sonrasında failure taxonomy, evaluation yaklaşımı, golden dataset tasarımı, production sinyalleri ve iyileştirme yol haritası sunacağım. Amaç, bu problemi “LLM bazen saçmalıyor” seviyesinde bırakmak değil; kurumsal RAG kalitesinin hangi halkada koptuğunu sistematik biçimde görünür kılmaktır.

RAG sistemlerinde retrieval çoğu zaman iki farklı doğruluk seviyesinde düşünülmelidir: document-level relevance ve evidence-level relevance. Document-level relevance, sistemin doğru dosya veya doğru belge ailesini bulduğunu gösterir. Evidence-level relevance ise cevabı gerçekten taşıyan bölüm, paragraf, madde veya pasajın retrieval zincirine doğru biçimde girdiğini gösterir. Bu ayrım kritik önemdedir; çünkü kullanıcı soruları çoğu zaman belge düzeyinde değil, pasaj düzeyinde yanıtlanır.

Örneğin bir şirket politikasına dair “uzaktan çalışma için yönetici onayı hangi koşullarda zorunludur?” sorusu sorulduğunda sistem doğru İnsan Kaynakları politikasını getirebilir. Ancak bu politikanın içindeki uzaktan çalışma maddesini değil, genel yan haklar kısmını veya işe giriş sürecini retrieve ederse belge doğru ama evidence yanlış olur. Sonuçta model, doğru doküman içindeymiş gibi görünen ama aslında cevabı taşımayan context’ten cevap üretmeye zorlanır.

"

Kritik gerçek: Kurumsal RAG sistemlerinde en sık kalite yanılsaması, doğru dosya düzeyindeki başarıyı doğru evidence düzeyindeki başarıyla karıştırmaktır.

Birçok ekip retrieval başarısını, “ilgili dosya geldi mi?” sorusuyla ölçer. Bu faydalı ama eksik bir metriktir. Çünkü kullanıcıya değer üreten şey dosyanın kendisi değil, dosya içindeki doğru pasajın modele zamanında ve doğru öncelikte verilmesidir. Özellikle aşağıdaki belge türlerinde passage retrieval kalitesi document retrieval’dan çok daha önemlidir:

• Politika ve prosedür dokümanları
• Sözleşmeler ve hukuki metinler
• Teknik kılavuzlar ve SOP’ler
• Wiki ve bilgi bankası sayfaları
• Sık istisna ve dipnot içeren iç dokümanlar
• Tablo ve madde listesi yoğun içerikler

Bu belge tiplerinde aynı dosya içinde birbirinden tamamen farklı kavramsal bölgeler bulunur. Dolayısıyla sistemin doğru belgeyi bulması yalnızca ilk eşiği geçtiğini gösterir; asıl kalite, cevabı taşıyan granüler bilgi birimini seçebilmesinde ortaya çıkar.

Doğru dosya geliyor ama cevap yanlışsa, ilk bakılması gereken sorun çoğu zaman şudur: Cevabı taşıyan gerçek pasaj top-k içinde var mı? Birçok sistemde dosya retrieval başarılıdır ama passage retrieval zayıftır. Bunun birkaç tipik nedeni vardır:

• Chunking sınırları yanlış çizilmiştir
• Başlık ve alt başlık ilişkisi korunmamıştır
• Cevap iki farklı chunk’a bölünmüştür
• Benzer kelimeler taşıyan ama asıl cevabı içermeyen başka bölümler üst sıralara çıkmıştır
• Retrieval depth çok düşüktür

Bu durumda model, doğru dosyanın gölgesinde yanlış evidence ile cevap üretir. Kullanıcı belgeyi görünce “ama bu dosyada cevap vardı” der; sistem ise o cevabı modelin görebileceği şekilde çıkaramamıştır.

Chunking, retrieval zincirinin görünmeyen ama belirleyici kararlarından biridir. Eğer belge sabit boyutlu parçalara bölündüyse ve başlık-paragraf bütünlüğü korunmadıysa, anlamlı bilgi akışları parçalanabilir. Özellikle kurumsal belgelerde şu yapı çok sık görülür: başlık bir chunk’ta, açıklama başka chunk’ta, istisna üçüncü chunk’ta kalır. Sistem bu parçaları ayrı ayrı indekslediğinde, sorgu yalnızca bir kısmını yakalar ve model eksik evidence ile konuşur.

Chunking Kaynaklı Tipik Hata Türleri

• Boundary split: Kritik cümle iki chunk arasında bölünür
• Header loss: Alt başlığın anlamı gövde metinden kopar
• Exception separation: Ana kural ve istisna farklı parçalara düşer
• Table fragmentation: Tablo satırları veya alanlar anlamsız şekilde parçalanır
• Noise bundling: Çok büyük chunk içinde gereksiz bağlam birikir

Bu nedenle doğru dosya retrieval başarısını görmek, chunking’in kaliteli olduğu anlamına gelmez. Asıl soru, dosyanın retrieval için doğru temsil edilip edilmediğidir.

Birçok kurum ilk RAG sistemini sabit boyutlu chunking ile kurar; çünkü uygulaması basittir. Ancak bu yaklaşım özellikle prosedür, sözleşme, madde bazlı politika ve wiki tipi içeriklerde sessiz kalite problemi yaratabilir. Sabit chunk mantığı, belge yapısını ve semantik sınırları dikkate almadığı için sistemin şu tür hatalar üretmesine yol açar:

• Doğru bölüm görünürde vardır ama sorunun cevabı taşıyan cümle yoktur
• İlgili başlık gelir ama istisna maddesi eksik kalır
• Madde listesi retrieval’da doğal blok yerine rastgele dilimlenmiş biçimde görünür
• Citation gösterilse bile kullanıcıya mantıklı gelmeyen yarım pasajlar oluşur

Bu nedenle doğru dosya gelip cevabın yine de yanlış olması, çoğu zaman “belge bulundu ama belge doğru temsil edilmedi” problemidir.

Kurumsal belgelerde anlam çoğu zaman sadece cümlelerin içinde değil, yapının içinde saklıdır. “İstisnalar”, “Not”, “Yalnızca şu durumda”, “Hariç”, “Ek koşullar”, “Version 2.1 sonrası” gibi ifadeler yapısal bağlama bağlıdır. Eğer retrieval pipeline başlık, alt başlık, madde numarası, tablo başlığı ve bölüm kimliğini kaybediyorsa, model yanlış bağlamla doğruymuş gibi konuşabilir.

Örneğin “seyahat masrafları ne zaman onaysız ödenebilir?” sorusunda “Onay Süreci” başlığı ile “İstisnai Durumlar” başlığı farklı chunk’lara ayrıldığında sistem yalnızca ana kuralı görebilir ve istisnayı kaçırabilir. Sonuç yanlış ama ikna edici bir cevaptır.

İlk aşama dense retrieval çoğu zaman semantik olarak benzer adayları bulur; ancak bunlar arasında en iyi evidence’ı seçme işinde zayıf kalabilir. Özellikle aynı dosya içinde birbirine benzeyen ama işlevsel olarak farklı bölümler varsa, yalnızca embedding similarity ile doğru pasajı en üste taşımak zorlaşır. İşte burada reranker eksikliği görünür hale gelir.

Reranker Eksikliğinin Sonuçları

• Doğru pasaj top-k içinde kalır ama üst sıralara çıkamaz
• Benzer kelime taşıyan yanlış pasajlar modele önce gösterilir
• LLM, ilk gelen yarı-doğru parçaya fazla ağırlık verir
• Citation varmış gibi görünür ama destek kalitesi düşer

Yani doğru dosya retrieval başarısı, reranking zayıfsa kullanıcıya doğru evidence olarak yansımayabilir. Bu nedenle belge düzeyi retrieval ile passage düzeyi reranking birlikte düşünülmelidir.

Bazı sistemler maliyet veya hız kaygısıyla top-k değerini düşük tutar. Bu, ilk bakışta mantıklı olabilir; ama doğru dosya içinde cevabı taşıyan paragraf üst sıralara çıkamıyorsa, düşük retrieval depth sistematik kalite kaybı yaratır. Özellikle uzun belgelerde veya birbirine benzeyen bölüm kümelerinde şu sorun görülür:

• Top-3 içinde belge doğru görünür
• Asıl evidence top-8 veya top-12’dedir
• Sistem yalnızca ilk birkaç chunk’ı modele verir
• Model eksik veya yanlış kanıttan sonuç üretir

Bu nedenle retrieval depth optimizasyonu yalnızca hız ve maliyet konusu değil, grounded answer kalitesi konusudur.

Diyelim ki retrieval zinciri doğru pasajı buldu. Bu yine de yeterli olmayabilir. Çünkü sonrasında context assembly katmanı devreye girer: hangi parçalar, hangi sırayla, hangi formatta, hangi başlık bilgileriyle modele gönderilecek? Eğer bu katman zayıfsa, doğru evidence gelse bile şu problemler oluşabilir:

• Çok gürültülü ek parçalar asıl kanıtı gölgeler
• Başlık ve meta bilgi atılır, pasaj bağlamsız kalır
• Aynı cevabı destekleyen iki parça bir araya getirilmez
• İstisna maddesi ile ana kural aynı bağlam içinde sunulmaz
• Parçalar yanlış sırada modele verilir

Bu yüzden retrieval ve reranking kadar context assembly tasarımı da cevap kalitesinin merkezindedir. Özellikle kurumsal RAG sistemlerinde “hangi chunk’lar bulundu?” sorusu kadar “hangi chunk’lar modele nasıl servis edildi?” sorusu da önemlidir.

Bazen doğru dosya gelir, doğru pasaj da gelir; ama model yine de yanlış cevap üretir. Bu durumda problem retrieval sonrası generation katmanına kayar. Model, retrieved bağlamı tam yorumlayamamış, eksik evidence’dan fazla sonuç çıkarmış, belirsiz bir ifadeyi kesin cümleye dönüştürmüş veya kendi önbilgisini araya katmış olabilir. Bu, klasik bir grounding failure problemidir.

Grounding Failure Türleri

• Unsupported completion: Kaynakta olmayan bilgiyi ekleme
• Overstatement: Belirsiz bilgiyi kesin gibi sunma
• Partial evidence inflation: Kısmi kanıttan tam sonuç üretme
• Exception omission: İstisna veya sınırlayıcı koşulu görmezden gelme
• Synthesis error: İki doğru pasajı yanlış biçimde birleştirme

Burada belge ve passage retrieval doğru olabilir; fakat answer generation hâlâ zayıftır. Bu yüzden kurumsal RAG kalitesini yalnızca retrieval metriğiyle ölçmek yetersizdir.

Kurumsal sistemlerde sık görülen başka bir yanılsama da şudur: “Citation gösteriyorsak cevap grounded’dır.” Hayır. Citation varlığı, citation doğruluğu anlamına gelmez. Sistem doğru dosyadan yanlış paragrafı referanslayabilir, ilgili başlığı işaretleyip destekleyici satırı kaçırabilir veya tek citation ile çok daha geniş bir iddiayı desteklemeye çalışabilir. Bu durumda kullanıcı kaynak görüyor diye cevap güvenilir sanılır; oysa citation yalnızca dekoratif hale gelmiştir.

Citation Kalitesinde Bakılması Gereken Sorular

• Gösterilen pasaj gerçekten iddiayı destekliyor mu?
• Doğru bölüm mü işaretlendi, yoksa aynı dokümandan sadece yakın bir bölüm mü?
• Citation, cevabın tamamını mı yoksa yalnızca bir kısmını mı destekliyor?
• Kaynakta belirsizlik varken cevap kesin mi konuşuyor?

Doğru dosya geliyor ama cevap yine de yanlışsa, çoğu zaman citation katmanı da ayrıca incelenmelidir.

Bazı kullanıcı soruları doğrudan belge yapısıyla hizalı değildir. Kullanıcı doğal dilde, kısa, eksik veya kuruma özgü terim kullanmadan soru sorabilir. Belge ise farklı terminolojiyle yazılmış olabilir. Böyle durumlarda sistem doğru dosyayı genel benzerlik üzerinden bulur; fakat doğru paragrafı seçmekte zorlanır. Query rewriting veya decomposition katmanı yoksa, retrieval motoru sorunun asıl niyetini yeterince ayrıştıramaz.

Örnek Riskler

• Kullanıcı “evden çalışma onayı” der, belge “uzaktan çalışma yetkilendirmesi” yazar
• Kullanıcı kısa soru sorar, cevabı iki bölümün birlikte okunmasını gerektirir
• Kullanıcı belirsiz terim kullanır, sistem yanlış alt başlığa yönelir

Bu nedenle doğru dosya bulunsa bile query-document alignment zayıfsa, asıl evidence seçimi yine bozulabilir.

Birçok ekip bu tip sorunu tek cümleyle tarif eder: “RAG bazen yanlış cevap veriyor.” Bu ifade mühendislik açısından yetersizdir. Çünkü çözüm üretebilmek için hatanın hangi katmanda oluştuğunu bilmek gerekir. Güçlü bir failure taxonomy burada merkezi rol oynar.

Örnek Failure Taxonomy

• Document hit, passage miss: Doğru dosya var, doğru pasaj yok
• Passage low rank: Doğru pasaj var ama üst sıralara çıkamıyor
• Context noise overload: Doğru evidence gelse de gürültü çok fazla
• Grounding failure: Model evidence’a sadık kalmıyor
• Citation mismatch: Cevap başka, kaynak başka şeyi destekliyor
• Exception omission: İstisna maddesi retrieval veya generation’da kayboluyor
• Structure loss: Başlık veya bölüm bağlamı kayboluyor

Bu sınıflandırma olmadan ekipler yanlış katmanı optimize eder. Örneğin sorun chunking iken daha büyük model almak ya da sorun reranking iken embedding değiştirmek sınırlı fayda üretir.

“Doğru dosya ama yanlış cevap” probleminde evaluation çok katmanlı kurulmalıdır. Sadece final answer doğruluğuna bakmak yeterli değildir. En az şu katmanlar ayrı ölçülmelidir:

• Document-level retrieval accuracy
• Passage-level evidence recall
• Reranked top-n evidence quality
• Answer faithfulness
• Citation support quality
• Exception / nuance preservation

Özellikle source-level ground truth ve passage-level annotation içeren golden dataset’ler burada çok değerlidir. Çünkü sadece referans cevap tutmak, doğru dosya ile doğru pasaj arasındaki farkı görünmez bırakır.

Bu problem sınıfını doğru ölçmek için golden dataset’te yalnızca soru ve beklenen cevap değil, şu alanlar da bulunmalıdır:

• Doğru doküman kimliği
• Doğru pasaj veya evidence span
• Gerekliyse ikinci destekleyici pasaj
• İstisna / koşul bilgisi
• Beklenen citation davranışı
• Görev tipi ve zorluk seviyesi

Bu yapı sayesinde ekipler şu ayrımı net görebilir: sistem belgeyi buluyor ama pasajı kaçırıyor mu, yoksa pasajı bulup cevabı yanlış mı kuruyor?

Canlı trafikte bu problemin tekrar edip etmediğini anlamak için sadece kullanıcı memnuniyeti yetmez. Özellikle şu sinyaller çok değerlidir:

• Doğru dosya / yanlış cevap vakalarının oranı
• Top-k içinde doğru pasaj görülme oranı
• Reranker sonrası top-3 evidence kalitesi
• Unsupported claim incidents
• Citation inspect davranışı
• Escalation to human oranı
• No-answer yerine hatalı answer verilme oranı
• Section-level retrieval başarısı

Bu ölçümler olmadan problem sadece kullanıcı şikâyeti şeklinde görünür. Ölçümlerle birlikte ise sistematik kalite iyileştirmesine dönüşür.

1. Chunking’i Semantik ve Yapısal Hale Getir

Başlık, alt başlık, madde listesi ve tablo sınırlarını koruyan chunking stratejileri kullan.

2. Passage-Level Benchmark Kur

Sadece dosya bazlı değil, cevap taşıyan pasaj bazlı truth tut.

3. Reranker Ekle veya Güçlendir

İlk aşamada gelen adaylar içinden en destekleyici evidence’ı öne çıkar.

4. Retrieval Depth’i Kontrollü Artır

Doğru pasajın top-k içinde kalıp kalmadığını veriyle test et.

5. Context Assembly’yi İyileştir

Yalnızca benzer chunk’ları değil, tamamlayıcı ve istisna taşıyan chunk’ları birlikte sun.

6. Grounding Prompt’larını Sertleştir

Modeli evidence dışına taşmama, belirsizlikte açıkça “yetersiz bilgi” deme ve istisnaları koruma yönünde yönlendir.

7. Citation Quality Kontrolü Ekle

Gösterilen kaynağın claim’i gerçekten destekleyip desteklemediğini ölç.

1. Retrieval Başarısını Dosya Düzeyinde Kutlama

Doğru dosyanın gelmesi önemli ama yetersizdir; gerçek kalite evidence düzeyinde ölçülmelidir.

2. “Model Zayıf” Diyerek Retrieval Sonrası Katmanları Görmezden Gelme

Sorun çoğu zaman model boyutundan önce chunking, reranking veya grounding katmanındadır.

3. Başlık ve Yapı Bilgisini Koru

Kurumsal dokümanlarda anlam, yalnızca metinde değil yapıda saklıdır.

4. Citation’ı Güven Sinyali Olarak Değil, Doğrulanması Gereken Delil Olarak Gör

Yanlış citation, bazen hiç citation olmamasından daha tehlikelidir.

5. Production Hatalarını Failure Taxonomy ile Veri Setine Geri Besle

Gerçek kırılma noktaları benchmark’a dönmedikçe sistem aynı hataları tekrar eder.

İlk 30 Gün: Sorunun Yerini Netleştir

• Doğru dosya / yanlış cevap örneklerini topla
• Her örneği document hit, passage miss, grounding failure gibi sınıflara ayır
• Passage-level benchmark seti oluşturmaya başla

31-60 Gün: Retrieval Sonrası Katmanları Güçlendir

• Chunking stratejisini gözden geçir
• Reranker ekle veya mevcut reranker’ı benchmark et
• Context assembly ve citation mapping mantığını iyileştir

61-90 Gün: Grounded Answer Kalitesini Kurumsal Standarda Dönüştür

• Answer faithfulness ve citation support metriklerini production dashboard’una taşı
• Failure taxonomy’yi düzenli kalite toplantılarının parçası yap
• Yüksek riskli use-case’ler için human review ve no-answer stratejisini netleştir

Bir şirket iç dokümanlardan çalışan bir soru-cevap sistemi kurduğunda ve doğru dosya gelmesine rağmen cevap yine de yanlış oluyorsa, bu durum genellikle modelin “bazen saçmalaması” değildir. Asıl mesele, dosya düzeyindeki başarının pasaj düzeyinde, context assembly katmanında ve answer grounding davranışında korunamamasıdır. Yani sistem ilk kapıyı geçer ama son metrelerde düşer. Bu düşüşün kaynağı da çoğu zaman chunking, evidence ranking, retrieval depth, yapısal bilgi kaybı, citation zayıflığı veya grounding failure’dır.

Uzun vadede güçlü kurumsal RAG ekipleri, yalnızca doğru belgeyi bulan sistemler kuran ekipler olmayacaktır. Asıl farkı yaratan ekipler; doğru belgeyi doğru pasajla eşleştiren, o pasajı doğru sırayla modele servis eden, modeli evidence’a sadık tutan ve kaliteyi document-level değil evidence-level ölçen ekipler olacaktır.

Doğru dosya geliyorsa retrieval başarılı sayılır mı?

Kısmen evet; ama yalnızca document-level başarı anlamına gelir. Cevabı taşıyan doğru pasaj retrieval’a girmiyorsa sistem yine başarısız olabilir.

Bu sorun model değiştirerek çözülür mü?

Bazen sınırlı fayda sağlar; ancak çoğu durumda asıl sorun chunking, reranking, context assembly veya grounding katmanındadır.

Reranker gerçekten fark yaratır mı?

Evet. Özellikle aynı dosya içindeki benzer ama farklı bölümler arasında en güçlü evidence’ı öne çıkarmada ciddi kalite farkı yaratabilir.

Citation varsa cevap grounded kabul edilir mi?

Hayır. Citation’ın gerçekten ilgili claim’i desteklemesi gerekir. Aksi halde sadece güven yanılsaması üretir.

En güçlü ilk adım nedir?

Genellikle doğru dosya / yanlış cevap örneklerini toplayıp bunları passage miss, grounding failure, citation mismatch gibi sınıflara ayırmak ve document-level değil passage-level benchmark kurmak en yüksek başlangıç etkisini yaratır.