RAG neden yanlış cevap verir? Hataların çoğu modelde değil, getirmede
Ship AI Engineer ekibi · Yayımlandı: 2026-08-31
Şirket içi belgeler hakkında soru cevaplayan bir sistem yayına alınıyor. İlk hafta bir çalışan, iade süresini soruyor ve sistem kendinden emin bir şekilde "30 gün" diyor. Politika 14 gün. Ekip ilk iş olarak prompt'u değiştiriyor, sonra daha güçlü bir modele geçiyor. İki gün sonra aynı hata başka bir soruda tekrar ediyor.
Sonunda biri, o soru için modele hangi belge parçalarının gönderildiğine bakıyor. Getirilen parçaların hiçbirinde iade politikası yok; model, elinde cevap olmadan en makul görünen sayıyı söylemiş. Sorun hiçbir zaman modelde değildi.
RAG nedir?
Modelin cevabını, eğitim verisine değil sizin belgelerinize dayandırma yöntemidir.
Retrieval-Augmented Generation iki adımdan oluşur: önce soruyla ilgili belge parçaları bulunur (getirme), sonra bu parçalar soruyla birlikte modele verilir ve model cevabı onlara dayanarak üretir (üretme). Böylece model, eğitildiği tarihten sonra yazılmış ya da hiç görmediği belgeler hakkında da cevap verebilir. Getirmenin nasıl çalıştığını embedding'ler üzerine yazımızda anlattık.
RAG sistemi neden yanlış cevap verir?
Çoğu zaman modele cevabı taşıyan parça hiç gönderilmediği için.
Yanlış cevabın üç olası kaynağı vardır: doğru parça hiç getirilmemiştir, doğru parça getirilmiş ama yanlış parçaların arasında kaybolmuştur ya da doğru parça getirilmiş ve model onu yanlış okumuştur. Pratikte ilk ikisi üçüncüsünden çok daha sık görülür. Bu yüzden prompt'u değiştirmek ya da modeli büyütmek, bir RAG hatasına verilebilecek en pahalı ve en az işe yarayan ilk tepkidir.
Hatanın getirmede mi üretimde mi olduğunu nasıl anlarsınız?
Cevaba bakmadan önce, o soru için modele gönderilen parçalara bakarak.
Her istekte getirilen parçaları kaydedin. Yanlış bir cevapla karşılaştığınızda ilk soru şudur: cevabı taşıyan bilgi bu parçalarda var mı? Yoksa sorun getirmededir: belgelerin nasıl parçalandığına, sorunun nasıl aradığına ve arama türüne bakın. Varsa sorun üretimdedir: prompt'a, parçaların sırasına ve modelin talimatlara uyup uymadığına bakın. Bu iki durumu ayırmadan yapılan her düzeltme, şansa bağlıdır.
Ölçümde de aynı ayrım geçerlidir. İki ayrı sayı tutun: doğru parçanın ilk birkaç sonuç arasında getirilme oranı ve cevabın getirilen parçalara sadık kalma oranı. Birinin iyileşip diğerinin bozulduğunu ancak böyle görürsünüz.
Model belgede olmayan bir şeyi neden söyler?
Çünkü görevi bir cevap üretmektir ve cevap yoksa en olası görünen cevabı üretir.
Dil modeli doğruyu değil olası olanı üretir. Getirilen parçalarda cevap olmadığında, model genel bilgisinden ya da parçalardaki benzer bir bilgiden makul bir cevap kurar. Bunu sınırlamanın yolları bellidir: modele açıkça "yalnızca verilen belgelere dayanarak cevap ver, cevap yoksa bunu söyle" demek, gerçekten "bilmiyorum" diyebileceği bir çıkış tanımlamak ve cevabı göndermeden önce, iddialarının parçalarda geçip geçmediğini kontrol etmek. Belgede cevabı olmayan bir soruya "bu belgelerde bilgi yok" diyebilen bir sistem, her soruya bir cevap veren bir sistemden çok daha güvenilirdir.
Kaynak göstermek neden önemlidir?
Çünkü cevabı doğrulanabilir yapar; hem kullanıcı hem de siz için.
Her cevabın altında hangi belgenin hangi parçasına dayandığını göstermek, kullanıcıya cevabı kendisinin kontrol etme imkânı verir. Sizin için de bir ölçüm aracıdır: gösterilen kaynak cevabı gerçekten destekliyor mu, bunu otomatik olarak kontrol edebilirsiniz. Kaynak gösteremeyen bir cevap, kullanıcıya ulaşmadan önce şüpheyle karşılanmalıdır.
Kaç parça getirilmeli?
Cevabı içerecek kadar az, ama olabildiğince az.
Daha fazla parça göndermek ilk bakışta güvenli görünür: doğru parça bir yerlerde mutlaka olur. Ama her parça token tutar, yani maliyet ve gecikme demektir. Ayrıca modeller çok uzun bir girdinin ortasına gömülmüş bilgiye, başındaki ve sonundaki bilgiye göre daha az dikkat eder. Yirmi parça göndermek, doğru parçayı on yedinci sıraya gömüp modelin gözden kaçırmasına yol açabilir. Daha iyi yol, getirmenin kalitesini artırıp daha az ama daha doğru parça göndermektir.
Bir RAG sistemi nasıl değerlendirilmeli?
Kullanıcıların gerçekten sorduğu biçimde sorulmuş sorularla ve cevabı belgelerde olmayan sorular da dahil.
En sık yapılan hata, test sorularını belgeleri yazan kişinin yazmasıdır. Bu kişi soruları belgelerdeki kelimelerle sorar ve arama mükemmel çalışıyormuş gibi görünür. Gerçek kullanıcılar ise kendi kelimeleriyle sorar. İyi bir test kümesi gerçek kullanım kayıtlarından alınmış soruları, eş anlamlı ifadeleri ve belgede cevabı bulunmayan soruları içerir. Sonuncusu, sistemin uydurup uydurmadığını gösteren tek testtir. Gerçek bir RAG sisteminin nasıl bozulduğunu arıza vakalarında adım adım izleyebilirsiniz.
Kaynaklar
- Lewis ve ark. (2020): Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks: RAG yaklaşımını tanıtan makale. (eklenme: 2026-08)
- Gao ve ark. (2023): Enabling Large Language Models to Generate Text with Citations: modellerin kaynak göstererek cevap vermesi ve bunun nasıl ölçüldüğü. (eklenme: 2026-08)
- Anthropic: Reducing hallucinations: modelin "bilmiyorum" diyebilmesi ve cevabı kaynağa bağlaması için teknikler. (eklenme: 2026-08)
- LangChain: text splitters: belgeleri parçalamanın farklı yolları. (eklenme: 2026-08)
Okumaya devam et
2026-10-06
AI engineer olarak takip etmeye değer kaynaklar: neyi, ne zaman okumalı?
Bu alanda her gün yeni bir yazı, yeni bir model, yeni bir araç çıkıyor ve hepsini takip etmeye çalışmak, hiçbirini öğrenmemenin en hızlı yolu. Gerçekten işe yarayan bir avuç kaynak ve her birini öğrenmenin hangi aşamasında okumanın anlamlı olduğu.
2026-10-05
Yapay zeka çağında mühendis olmak: kod ucuzladı, yapı ucuzlamadı
Kod yazmak hiç bu kadar hızlı olmamıştı. Ama hızlı üretilen kod, altındaki yapı neyse onu büyütür. Neden mühendislik bugün daha az değil daha çok gerekiyor ve neyde derinleşmek gerekiyor.
2026-10-02
Bir AI uygulamasını yayına almak: maliyet tavanı, önbellek, izleme ve model değişikliği
Sıradan bir web uygulamasında her istek aşağı yukarı aynı maliyettedir. Dil modeli içeren bir uygulamada değildir. Yayına alırken maliyeti sınırlamak, önbelleği güvenle kullanmak, doğru şeyleri izlemek ve sağlayıcı bir modeli emekliye ayırdığında hazırlıklı olmak.
2026-09-30
AI engineer portföyü: işe alımda işe yarayan bir proje neye benzer?
Bir sohbet botu demosu artık kimseyi etkilemiyor. Bir AI projesini inandırıcı yapan altı işaret, her biri farklı bir beceriyi gösteren beş proje fikri ve projeyi iki dakikada okutan bir README.
2026-09-27
Prompt injection ve kötüye kullanım: bir AI uygulamasında sunucu neden tek doğruluk kaynağıdır?
Bir dil modeli içeren uygulama, sıradan bir web uygulamasının bütün güvenlik sorunlarını taşır ve yenilerini ekler. Prompt injection'ın neden tamamen önlenemediği, zararın nasıl sınırlandığı, uç noktanın korunması ve modelin çıktısına neden güvenilmediği.
2026-09-23
Bir LLM uygulaması için ilk test kümenizi kurmak: değerlendirme (eval) rehberi
Prompt'u değiştirdiniz ve cevaplar daha iyi görünüyor. Gerçekten mi? İlk test kümesini kurmak, taban çizgisi almak, ortalamanın gizlediğini görmek, bir modelin başka bir modeli puanlamasının sınırları ve yayındaki sistemi izlemek.
2026-09-19
Fine-tuning ne zaman yapılır, ne zaman zaman kaybıdır?
Bir modeli kendi verinizle eğitmek çekici bir fikir. Çoğu zaman yanlış araç. Fine-tuning'in neyi öğrettiği ve neyi öğretmediği, prompt ve RAG ile karşılaştırması, veri kalitesi, sızıntı, LoRA ve açık modellerde lisans.
2026-09-14
AI engineer kursu seçerken sorulacak 7 soru
Bir yapay zeka mühendisliği eğitimine para ve aylar vermeden önce sorulması gereken yedi soru. Her birinin kısa cevabı ve satın almadan önce müfredatta kontrol edebileceğiniz somut işaret.
2026-09-09
Görsel ve ses girdili yapay zeka: testte görünmeyen maliyetler ve hatalar
Bir fotoğrafı ya da ses kaydını modele vermek, metin göndermekle aynı şey değil. İstek boyutu, okunamayan görseller, sessizlikte uydurulan cümleler, saniyeler süren üretim ve her turda yeniden ödenen bir görsel.
2026-09-04
Agent'a ne zaman ihtiyacınız yoktur? Araç kullanan bir sistemi güvenle kurmak ve durdurmak
"Agent" bugün en çok istenen ve en kolay yanlış kurulan şey. Sabit bir iş akışıyla agent arasındaki fark, araç tanımlarının neden kritik olduğu, döngüyü durdurmanın yolları ve geri alınamayan işlemleri korumak.
2026-08-26
Yapay zeka mühendisi nasıl olunur? Model eğitmeden, ürün kurarak bir yol haritası
Arama sonuçlarındaki yol haritalarının çoğu başka bir mesleği tarif ediyor. Bugün işe alınan AI engineer'ın gerçekten ne bildiği, hangi sırayla öğrenildiği ve her aşamanın neyle "bitti" sayıldığı.
2026-08-21
Vektör veritabanına gerçekten ne zaman ihtiyacınız var? Embedding'ler üzerine pratik bir rehber
Anlamsal arama kurmaya karar verenlerin ilk adımı genellikle bir vektör veritabanı seçmek oluyor. Çoğu zaman erken bir adım. Embedding'in ne olduğu, benzerlik puanının neyi söylemediği ve veritabanına geçmenin gerçek sebepleri.
2026-08-17
Prompt'u kod gibi yönetmek: sürüm, şablon, şema ve test
Sohbet penceresinde işe yarayan prompt, bir uygulamanın içinde sessizce bozulur. Prompt'u depoda tutmak, kullanıcı girdisini talimattan ayırmak, cevabı şemayla doğrulamak ve bir değişikliği ölçerek yayına almak.
2026-08-12
LLM API'leri ilk gerçek trafikte neden bozulur? Hız sınırı, yeniden deneme ve zaman aşımı
Geliştirirken hiç görmediğiniz üç hata, ilk yoğun saatte aynı anda gelir. 429 ile 5xx'i ayırmak, doğru yeniden deneme, zaman aşımı ve sağlayıcı çöktüğünde ürünün ayakta kalması.
2026-08-07
AI engineer olmak için matematik gerekli mi?
İnsanları daha başlamadan durduran altı sorunun dürüst cevabı: matematik, diploma, makine öğrenmesi, Python, donanım ve para. Önce kısa cevap, sonra gerekçe.
2026-08-07
AI engineer, makine öğrenmesi mühendisi değildir
"Yapay zeka mühendisi nasıl olunur" diye arayın; ilk sayfa size lineer cebir, CNN ve eğitim döngüsü öğretir. O başka bir meslek. İşin gerçekte ne olduğu ve neyi atlayabileceğiniz.