RAG Projeleri Neden Başarısız Olur? Veri Hazırlığı, Evaluation ve Prompt Katmanındaki Kritik Hatalar

RAG projeleri çoğu zaman umut verici başlar. İlk demo etkileyicidir. Kullanıcı bir soru sorar, sistem birkaç saniye içinde kurumsal bilgiye dayalı gibi görünen bir cevap üretir, hatta kaynak da gösterebilir. Bu aşamada organizasyon içinde güçlü bir heyecan oluşur. Ancak üretim ortamına geçildiğinde tablo hızla değişebilir. Aynı sistem farklı kullanıcı sorgularında tutarsız çalışmaya başlar, bazı sorularda eski veya alakasız doküman getirir, bazen eksik bilgiyle fazla özgüvenli cevap verir, bazen de doğru bilgi tabanda olduğu halde ona ulaşamaz.

Bu kırılma noktası çok kritiktir. Çünkü birçok ekip bu durumda yanlış teşhis koyar ve problemi model seçimine indirger. Oysa RAG projelerinde başarısızlığın kök nedeni çoğu zaman model değildir. Asıl sorun; veri hazırlığı zayıflığı, retrieval kalitesinin sistematik ölçülmemesi ve prompt katmanının kontrolsüz tasarlanması gibi yapısal eksikliklerdir.

Başka bir ifadeyle, RAG projeleri çoğu zaman “LLM yeterince güçlü değil” diye değil; modele doğru bilgi doğru biçimde verilemediği, getirilen bilginin kalitesi ölçülmediği ve modelin bu bilgiyle nasıl davranacağı net tanımlanmadığı için başarısız olur.

Bu yazıda, RAG projelerinin neden başarısız olduğunu üç temel eksende inceleyeceğim: veri hazırlığı, evaluation ve prompt katmanı. Ancak bunları izole başlıklar gibi değil; aynı kalite zincirinin birbirine bağlı halkaları olarak ele alacağım. Çünkü üretimde güvenilir RAG sistemleri kurmanın yolu, yalnızca retrieval eklemekten değil; bu zincirin her halkasını disiplinli biçimde tasarlamaktan geçer.

Birçok RAG projesi ilk aşamada sınırlı örnekler üzerinde test edilir. Doküman seti küçük, sorgular kontrollü, kullanıcı niyeti net ve sistem davranışı yakından gözlemlenebilir durumdadır. Bu ortamda retrieval hataları daha az görünür. Çünkü proje çoğu zaman en iyi örnekler üzerinden sunulur.

Üretimde ise durum değişir:

• Kullanıcılar çok daha belirsiz ve gürültülü sorular sorar.
• Bilgi tabanı büyür ve heterojenleşir.
• Eski sürüm ve yeni sürüm dokümanlar birlikte dolaşabilir.
• Rol bazlı erişim ve güvenlik gereksinimleri devreye girer.
• Edge-case’ler artar.
• Modelin yanlış cevap verdiği alanlar daha görünür hale gelir.

Yani PoC ile production arasındaki kırılma, çoğu zaman modelin bozulmasından değil; sistemin gerçek dünya karmaşıklığına hazırlıksız olmasından kaynaklanır.

"

Kritik gerçek: RAG projeleri çoğu zaman retrieval ekledikleri için değil, retrieval’ı üretim seviyesinde yönetemedikleri için başarısız olur.

RAG projelerinde tekrar tekrar gördüğümüz başarısızlık desenleri üç ana katmanda toplanır:

1. Veri hazırlığı katmanı: Yanlış veya zayıf bilgi tabanı oluşturulması
2. Evaluation katmanı: Kalitenin sistematik olarak ölçülmemesi
3. Prompt katmanı: Modele yanlış davranış kuralları verilmesi veya grounding disiplininin eksik kurulması

Bu üç katman birbirini doğrudan etkiler. Örneğin veri kötü ise retrieval kötü olur. Retrieval kötü ise evaluation yanlış sinyaller üretir. Prompt kötü ise retrieval iyi olsa bile nihai cevap güvenilir olmaz. Bu yüzden kök neden analizi katmanlar arası düşünülmelidir.

RAG sistemleri bilgiye dayanır. Bu yüzden sistemin bilgi tabanı zayıfsa, geri kalan tüm mimari katmanlar sınırlı değer üretir. Kurumsal ortamlarda veri hazırlığı çoğu zaman “dokümanları topla ve indexle” düzeyinde görülür. Oysa asıl kalite problemi tam da burada başlar.

Hata 1: Yanlış Kaynakları Sisteme Dahil Etmek

Her kurumsal doküman retrieval için uygun değildir. Taslak politikalar, eski SOP’ler, onaysız eğitim notları, kişisel klasörlerde tutulan ara versiyonlar veya artık geçerli olmayan süreç belgeleri bilgi tabanına dahil edildiğinde sistem semantik olarak ilgili ama kurumsal olarak yanlış içerikleri getirmeye başlar.

Bu durumda model teknik olarak “ilgili” bir cevap veriyor gibi görünür; ancak cevap iş açısından yanlıştır. Bu, RAG sistemlerinde güven kaybının en yıkıcı kaynaklarından biridir.

Hata 2: Parsing Kalitesini İkinci Plana Atmak

Özellikle PDF yoğun yapılarda parsing kalitesi retrieval kalitesinin gizli belirleyicisidir. Tablo bozulmaları, dipnotların ana metne karışması, çok sütunlu yapının tek akışta birleşmesi, madde numaralarının kaybolması ve footer/header kirliliği sistemin yanlış metin parçalarını indexlemesine neden olur.

Bu tür hatalar çoğu zaman retrieval aşamasında fark edilmez; çünkü kullanıcı yalnızca kötü sonucu görür. Oysa kök neden daha yukarıdaki belge işleme katmanındadır.

Hata 3: Tek Tip Chunking ile Tüm Belgeleri Yönetmeye Çalışmak

Politika dokümanları, SOP’ler, wiki sayfaları ve teknik destek içerikleri aynı şekilde chunk’lanmamalıdır. Sabit uzunluklu, yapısal sınırları dikkate almayan chunking; istisnaları, madde bütünlüklerini, süreç sıralarını ve bağlam ilişkilerini bozar.

Bunun sonucunda:

• İstisna başka chunk’ta kalır
• SOP adımı bağlamından kopar
• Tablo değeri metinden ayrılır
• Kapsam ve koşul farklı parçalara dağılır

RAG kalitesinin düşmesi çoğu zaman retrieval skorlarından önce chunking mimarisine bakmayı gerektirir.

Hata 4: Metadata Katmanını Zayıf Kurmak

Kurumsal retrieval yalnızca semantik yakınlık üzerinden çalışamaz. Belgenin sürümü, geçerlilik tarihi, ülke/lokasyon, departman, rol bazlı erişim seviyesi ve onay durumu çoğu zaman retrieval doğruluğu için zorunludur. Metadata zayıf olduğunda sistem en benzer ama yanlış sürüm dokümanı getirir.

Hata 5: Güncellik ve Sürüm Yönetimini Görmezden Gelmek

Birçok kurumda aynı politikanın, aynı prosedürün veya aynı ürün kılavuzunun birden fazla sürümü dolaşımda olur. Eğer bilgi tabanında bu sürümler ayrıştırılmıyorsa, retrieval kalite problemi kaçınılmazdır. Kullanıcıya kaynaklı cevap veriliyor gibi görünse de kaynak güncel değilse sistem fiilen yanlış yönlendiriyordur.

RAG projelerinin en kritik ama en sık ihmal edilen katmanı evaluation’dır. Birçok ekip sistemi kurar, birkaç örnek sorguda iyi sonuç görünce kaliteyi doğrulanmış sayar. Oysa retrieval tabanlı sistemlerde kalite, hissedilerek değil; katman katman ölçülerek yönetilmelidir.

Neden Evaluation Bu Kadar Kritik?

Çünkü RAG sistemlerinde hata yalnızca son cevapta oluşmaz. Hata şu aşamalardan herhangi birinde olabilir:

• Doğru doküman hiç bulunmamıştır
• Doğru doküman bulunmuştur ama doğru bölüm seçilmemiştir
• Doğru bağlam gelmiştir ama model onu yanlış yorumlamıştır
• Prompt modeli yetersiz bağlama rağmen kesin cevap vermeye itmiştir

Bu nedenle yalnızca “cevap doğru mu?” sorusu yeterli değildir. Retrieval ve generation katmanlarını ayrıştıran bir evaluation gereklidir.

Hata 6: Sadece Son Cevaba Bakmak

Birçok ekip nihai cevabın akıcı ve makul görünmesini kalite göstergesi sayar. Ancak retrieval hatası, bazen akıcı cevap içinde gizlenir. Model yanlış chunk’tan da makul görünen bir cevap yazabilir. Bu yüzden yalnızca final output incelemesi, retrieval başarısızlıklarını maskeler.

Hata 7: Retrieval Kalitesini Ayrı Ölçmemek

RAG evaluation’da şu sorular ayrı ölçülmelidir:

• Doğru doküman bulundu mu?
• Doğru bölüm ilk sıralarda mı geldi?
• Getirilen bağlam yeterince temiz mi?
• Alakasız chunk’lar bağlamı kirletiyor mu?

Bu ölçüm yapılmadan sadece cevap kalitesine bakıldığında, retrieval sorunları model problemi gibi yorumlanır.

Hata 8: Benchmark Seti Olmadan İlerlemek

Kurumsal RAG sistemleri için use-case temelli benchmark setleri şarttır. Politika soruları, SOP adımları, exact-match sorgular, belirsiz doğal dil soruları, jargonlu sorular ve rol bazlı kısıt gerektiren sorgular ayrı ayrı değerlendirilmelidir. Tek tip örnek set ile tüm retrieval davranışı ölçülemez.

Hata 9: Değişiklik Sonrası Regresyon Testi Yapmamak

Chunk size değiştiğinde, embedding modeli değiştiğinde, top-k güncellendiğinde, hybrid search veya reranking eklendiğinde kalite her zaman artmaz. Bazen bir use-case iyileşirken başka bir use-case bozulur. Bu yüzden RAG sistemlerinde regresyon testi zorunludur.

Hata 10: İnsan Değerlendirmesini Hiç Kurmamak

Özellikle politika, uyum, sözleşme, teknik prosedür ve yüksek riskli bilgi alanlarında otomatik metrikler tek başına yeterli değildir. İnsan değerlendirmesi, özellikle groundedness, citation quality ve iş açısından doğruluk boyutlarında vazgeçilmezdir.

RAG sistemlerinde retrieval iyi çalışsa bile nihai kalite garanti değildir. Çünkü getirilen bilginin model tarafından nasıl kullanılacağı, prompt katmanının kalitesine bağlıdır. Birçok ekip retrieval’a çok odaklanır ama prompt’u “genel bir sistem mesajı” düzeyinde bırakır. Bu yaklaşım üretim ortamında ciddi sorunlar yaratır.

Prompt Katmanı Neden Bu Kadar Kritik?

Prompt katmanı, modeli şu konularda yönlendirir:

• Yalnızca verilen bağlama mı dayanacak?
• Bağlam yetersizse ne yapacak?
• Çelişkili içerik varsa bunu nasıl ifade edecek?
• Kaynak gösterecek mi?
• Yorum mu yapacak, yoksa sadece dokümandaki bilgiyle mi kalacak?

Bu sorular net değilse, retrieval iyi olsa bile model yanlış davranabilir.

Hata 11: Modele “Bilmiyorsan Bilmiyorum De” Dememek

RAG sistemlerinde en kritik davranış kurallarından biri, yetersiz bağlam durumunda uydurmamaktır. Ancak prompt katmanında bu net olarak tanımlanmazsa model akıcı ve özgüvenli bir şekilde eksik bilgiyi tamamlamaya çalışabilir. Bu, özellikle kurumsal politika ve prosedür sistemlerinde ciddi risktir.

Hata 12: Kaynaklı Cevap Davranışını Tasarlamamak

Kurum içi güven için kaynak gösterimi merkezi önemdedir. Ancak prompt katmanında bunun nasıl yapılacağı tanımlanmazsa model ya hiç kaynak vermez ya da zayıf ve belirsiz atıflar üretir. Kaynaklı cevap davranışı sistematik tasarlanmalıdır.

Hata 13: Çelişkili Bağlamı Yönetememek

Bazen retrieval katmanı farklı sürüm veya farklı ekipten çelişkili içerik getirebilir. Prompt modeli bu durumda tek bir cevabı kesinmiş gibi vermeye itiyorsa sistem risk üretir. İyi prompt tasarımı, çelişkiyi tespit edip bunu kullanıcıya yansıtacak davranış kuralları içermelidir.

Hata 14: Her Soru Tipi İçin Aynı Prompt Kalıbını Kullanmak

Politika açıklama, SOP yönlendirme, özetleme, karşılaştırma, madde bulma ve karar destek senaryoları aynı prompt davranışını gerektirmez. Tek tip prompt kalıbı üretim kalitesini düşürür. Soru tipine göre görevsel prompt stratejileri oluşturulmalıdır.

RAG projelerinde başarısızlık genellikle tek bir noktada oluşmaz. Daha sık gördüğümüz tablo şudur:

• Veri hazırlığı zayıftır, bu yüzden retrieval aday seti zayıftır.
• Evaluation eksiktir, bu yüzden retrieval zayıflığı zamanında fark edilmez.
• Prompt katmanı yetersizdir, bu yüzden model eksik bağlamla bile özgüvenli cevap verir.

Bu birleşim özellikle tehlikelidir. Çünkü sistem kullanıcıya sadece yanlış bilgi vermez; aynı zamanda bu yanlış bilgiyi güvenilir gibi sunar. Kurumsal güven kaybı tam da burada başlar.

Aşağıdaki sinyaller, RAG sisteminizin üretimde sorun yaşadığını erken gösterebilir:

• Aynı soru tiplerinde tutarsız cevaplar
• Kullanıcıların “kaynak doğru ama cevap eksik” demesi
• Doğru bilginin tabanda olmasına rağmen yanlış cevap üretilmesi
• Eski sürüm veya yanlış ülke/lokasyon dokümanlarının görünmesi
• İnsanların sistemi kullanıp sonrasında tekrar manuel arama yapması
• Belirli query tiplerinde düşük task success
• Belirsiz sorularda aşırı özgüvenli cevaplar

1. Bilgi tabanını teknik değil yönetsel problem olarak ele al

Hangi dokümanın sisteme gireceği, kim tarafından sahiplenileceği, nasıl güncel tutulacağı baştan tanımlanmalıdır.

2. Retrieval kalite ölçümünü cevap kalitesinden ayır

Doğru doküman bulundu mu, doğru bölüm mü geldi, bağlam ne kadar temiz; bunları ayrı ölç.

3. Prompt’u retrieval sonrası davranış katmanı olarak tasarla

Modelin bağlamla ne yapacağını net kurallarla tanımla.

4. Her belge türü için aynı stratejiyi kullanma

Politika, SOP, wiki ve PDF aynı retrieval ve prompt kalıbıyla yönetilmemelidir.

5. “Demo iyi çalıştı” ile “production iyi çalışıyor” arasındaki farkı baştan kabul et

PoC ve gerçek dünya kalite sinyalleri farklıdır. Mimariyi buna göre kur.

• Kaynaklar onaylı ve güncel mi?
• Parsing kalitesi belge türüne göre doğrulandı mı?
• Chunking stratejisi belge tipine göre farklılaşıyor mu?
• Metadata alanları retrieval doğruluğunu destekliyor mu?
• Retrieval relevance ve context precision ölçülüyor mu?
• Benchmark seti use-case bazlı mı?
• Regresyon testi yapılıyor mu?
• Prompt, yetersiz bağlam durumunu güvenli yönetiyor mu?
• Kaynaklı cevap davranışı net mi?
• Çelişkili bağlamı ele alma kuralı tanımlı mı?

İlk 30 Gün: Kök Nedenleri Görünür Kıl

• Başarısız örnekleri kategori bazlı incele
• Veri, retrieval ve prompt kaynaklı hataları ayrıştır
• Bilgi tabanı hijyenini kontrol et
• İlk benchmark soru setini oluştur

31-60 Gün: Katman Bazlı Kaliteyi Güçlendir

• Parsing ve chunking stratejilerini belge türüne göre yeniden tasarla
• Retrieval relevance ve context precision metriklerini devreye al
• Prompt davranışını görev bazlı netleştir
• Kaynaklı cevap ve “bilmiyorum” kurallarını standartlaştır

61-90 Gün: Production Disiplinine Geç

• Regresyon testlerini release sürecine bağla
• Observability ile retrieval trace görünürlüğü kur
• İnsan değerlendirmesini kritik use-case’lerde resmileştir
• İlk referans RAG kalite standardını kurum standardı haline getir

RAG projelerinin başarısız olması çoğu zaman modelin yetersiz olmasından değil; sistemin veri hazırlığı, evaluation ve prompt katmanlarında yeterince olgun tasarlanmamasından kaynaklanır. Kurumsal üretim ortamında retrieval kalitesi, bilgi tabanı hijyeni ve cevap davranışı birlikte yönetilmediğinde, en güçlü LLM bile düşük güvenli bir sistemin parçası haline gelir.

Bu nedenle RAG’i yalnızca “retrieval eklenmiş LLM” olarak görmek eksiktir. Gerçekte RAG; bilgi kalitesi, retrieval doğruluğu, ölçüm disiplini ve davranış kontrolünün birleştiği bir sistem mühendisliği problemidir. Uzun vadede başarılı olan projeler, en popüler modeli kullananlar değil; bu kalite zincirini en disiplinli biçimde kuran projelerdir.

RAG projelerinde en yaygın başarısızlık nedeni nedir?

En yaygın neden, düşük kaliteli veya kontrolsüz bilgi tabanıdır. Eski sürüm, onaysız veya yanlış parse edilmiş dokümanlar retrieval kalitesini doğrudan bozar.

Evaluation olmadan demo iyi görünüyorsa sistem yine de riskli midir?

Evet. Demo başarısı, gerçek dünya kalitesini garanti etmez. Evaluation olmadan retrieval ve generation hataları gizli kalabilir.

Prompt iyi yazılırsa retrieval hataları telafi edilir mi?

Hayır. Prompt davranışı iyileştirebilir ama yanlış veya eksik bağlamı doğru bilgiye çeviremez. Retrieval kalitesi temeldir.

Bu sorunlar sadece büyük kurumlarda mı görülür?

Hayır. Küçük ekiplerde de görülür. Ancak bilgi hacmi, belge çeşitliliği ve kullanıcı sayısı arttıkça etkileri çok daha görünür hale gelir.

Başarısız RAG projesi kurtarılabilir mi?

Evet. Kök neden doğru analiz edilirse veri hijyeni, evaluation disiplini ve prompt davranışı yeniden tasarlanarak kalite önemli ölçüde yükseltilebilir.