RAG Nedir? AI Search’te Retrieval ve Generation Nasıl Birleşir?

RAG, bir dil modelinin cevap üretirken dış kaynaklardan getirilen bilgileri kullanmasını sağlayan yaklaşımdır. Açılımı Retrieval-Augmented Generation’dır; Türkçede bilgi erişimiyle desteklenen üretim olarak açıklanabilir. Sistem önce soruyla ilgili kanıtları bulur, bunları modelin kullanabileceği bağlama yerleştirir ve bu bağlamdan yararlanarak yanıt oluşturur.^[1]

Buradaki kritik ayrım şudur: Retrieval bilgiyi bulur; generation cevabı üretir. Birinin başarılı olması, diğerinin de başarılı olduğunu göstermez.

Doğru kullanım kılavuzu bulunabilir ama yanlış modelin özellikleri cevaplanabilir. Kaynak güncel olabilir ama önemli bir istisna modele aktarılmayabilir. Yanıtta kaynak bağlantısı bulunabilir ama bağlantı, yanındaki iddiayı desteklemeyebilir.

Information Retrieval yazısında bilgi ihtiyacına uygun sonuçların bulunmasını ele almıştım. RAG, bunun üzerine başka bir görev ekler: Bulunan bilgiyi kullanarak kullanıcıya yeni bir cevap hazırlamak. Bu yazıda iki görevin nasıl birleştiğini ve neden ayrı denetlenmesi gerektiğini açıklıyorum.

RAG neden yalnızca bir chatbot özelliği değildir?

RAG bir arayüzün değil, bilgi akışının adıdır. Sohbet kutusuyla sunulabileceği gibi ürün karşılaştırması, doküman asistanı veya arama sonuçlarının özetlenmesi içinde de kullanılabilir. Öte yandan her chatbot dış kaynak taramaz; bazıları yalnızca konuşma bağlamı ve modelin eğitiminde öğrendikleriyle yanıt verir.

Lewis ve çalışma arkadaşlarının 2020 tarihli RAG makalesi, üretici modelin parametrelerindeki bilgiyi dış bir bilgi indeksiyle birleştiren bir mimariyi araştırır. Çalışmadaki Wikipedia tabanlı yoğun vektör indeksi, bugünkü her RAG uygulamasının aynen kullanmak zorunda olduğu bir şablon değildir.^[2]

Pratikte RAG’ı tanımlayan ilişki şudur: Dışarıdan getirilen bilgi, yanıtın üretilmesine girdi olur. Sistemin hangi arama yöntemini, modeli veya veri deposunu kullandığı ayrıca belirlenir.

Retrieval, augmentation ve generation ne yapar?

Üç kavramı ayrı düşünmek, sorunun nerede başladığını bulmayı kolaylaştırır. Aşağıdaki tablo bir ürün sorusu üzerinden görevleri ayırır; belirli bir platformun iç mimarisini temsil etmez.

Aşama	Temel soru	Örnek çıktı
Retrieval	Bu ihtiyacı cevaplamak için hangi kayıtlar gerekli?	Ürünün uyumluluk belgesi, paket içeriği ve stok kaydı.
Augmentation	Hangi bilgiler, hangi kapsam ve kaynak kimliğiyle modele aktarılmalı?	Model kodları, uyumluluk koşulları, güncelleme zamanı ve kaynak referanslarını içeren bağlam.
Generation	Bu kanıtlarla kullanıcıya ne söylenebilir?	Doğrulanmış uyumluluğu açıklayan, belirsiz kalan noktaları ayıran yanıt.

Arama sonuçlarını listelemek tek başına generation değildir. Modelin akıcı cevap yazması da retrieval yapıldığı anlamına gelmez. RAG bu görevleri bir araya getirir; aralarındaki sınırları ortadan kaldırmaz.

RAG nasıl çalışır? Hazırlık ve cevaplama aşamaları

1. Bilgiyi erişilebilir hale getirmek

İndeks kullanan bir uygulamada kaynaklar önce işlenir: Metin çıkarılır, gerekiyorsa bölümlere ayrılır, aranabilir temsiller oluşturulur ve kayıtlar kaynak bilgileriyle saklanır. Bir indeks yalnızca vektörlerden oluşmak zorunda değildir; metin, kimlik ve filtreleme alanları da taşıyabilir.^[3]

Örneğin bir katalog asistanı için şu alanları birlikte saklamayı tercih ederim:

• Belgenin ve ilgili ürünün kimliği.
• Bölüm başlığı ve bölümün bağlı olduğu ana belge.
• İçeriğin geçerli olduğu model veya ürün ailesi.
• Kaynağın güncelleme zamanı ve sürümü.
• Orijinal kayda dönmeyi sağlayan adres veya referans.

Bunlar yalnızca yönetim bilgileri değildir. “Bu açıklama hangi ürüne ait?” ve “Bu kayıt hâlâ geçerli mi?” sorularını cevaplamaya yarar. Eski bir kullanım kılavuzu ile güncel ürün kaydı aynı metin havuzunda birbirinin yerine geçmemelidir.

2. Soru geldiğinde kanıtları toplamak

Kullanıcının sorusu ve gerekiyorsa konuşma bağlamı, hangi bilginin aranacağını belirler. Uygulama ilgili kayıtları getirir; isteğe bağlı yeniden sıralama ve seçimden sonra modele aktarılacak bağlamı hazırlar. Model bu girdiyi kullanarak cevabı üretir.^[1]

Bu, her sistemin tek arama yaptığı anlamına gelmez. “Bu ürün uyumlu mu, paketinde ne var ve şu anda alınabilir mi?” sorusunda üç farklı bilgi ihtiyacı bulunur. Benim tasarım tercihim, böyle bir sorunun tamamlandığını ancak gerekli üç kanıt türü de kontrol edildiğinde kabul etmektir.

Son aşamada yalnızca metnin oluşmasına bakılmaz: Yanıt doğru üründen mi söz ediyor, iddialar kaynaklarla eşleşiyor mu, cevaplanamayan bölüm açıkça belirtilmiş mi?

RAG için vektör veritabanı şart mı?

Hayır. Retrieval, vektör aramasından daha geniştir. Anahtar kelime temelli arama, yoğun vektör araması ve bunları birleştiren hibrit yöntemler kullanılabilir. Microsoft’un retrieval rehberi de metin ve vektör aramasını farklı ihtiyaçlara hizmet eden seçenekler olarak ele alır.^[4]

Embedding, içeriğin sayısal temsilidir. Vektör benzerliği, belirli bir temsil uzayındaki yakınlığı gösterir; belgenin doğru, güncel veya kullanıcının ürününe ait olduğunu tek başına doğrulamaz.

Kurgusal M-18 ve M-18X modellerini düşünelim. İkisinin açıklamaları benzer olabilir. Fakat kullanıcının elindeki ürün M-18 ise diğer modelin uyumluluk kaydını getirmek, konu bakımından yakın ama karar bakımından yanlış sonuç üretebilir. Burada tam model kimliğiyle arama veya filtreleme önemli olabilir.

Bu yüzden seçim “keyword search eski, vector search yeni” şeklinde yapılmaz. Sorulması gereken soru, gerçek kullanıcı sorgularında gerekli kanıtı hangi yöntemin daha güvenilir bulduğudur.

Chunking neden yalnızca metni bölmek değildir?

Chunk, sistemin erişim için kullandığı içerik parçasıdır. Bölme sırasında anlamı taşıyan bağlam kaybolabilir. Anthropic’in Contextual Retrieval çalışması da parçaların bağlı oldukları belgeden koparıldığında belirsizleşebilmesini ele alır ve bu bağlamı korumaya yönelik bir yöntem sunar.^[5]

Örneğin “Bu model yalnızca A serisiyle uyumludur” cümlesi tek başına saklanırsa “bu model”in hangisi olduğu kaybolabilir. Bir tablonun hücresi alınırken sütun başlığının atılması ise bir değerin voltaj mı, ağırlık mı olduğunu belirsizleştirebilir.

Bu nedenle parça boyutunu yalnızca kelime sayısıyla değerlendirmem. Şunları da kontrol ederim:

• Özne ve model kimliği parçada anlaşılabiliyor mu?
• Koşul, istisna ve olumsuzluk ifadeleri korunmuş mu?
• Tablonun başlıkları ve ölçü birimleri birlikte taşınıyor mu?
• Gerekirse komşu bölüm veya ana belgeye dönülebiliyor mu?

En küçük parça her zaman en iyi parça değildir. Hedef, metni küçültmekten önce cevap için gerekli anlam birimini korumaktır.

Retrieval sonucu ile modele verilen bağlam aynı mı?

Her zaman değil. İlk aramada bulunan adaylar yeniden sıralanabilir, tekrar eden sonuçlar elenebilir ve yalnızca bir bölümü modele gönderilebilir. Reranking, aday sonuçları yeniden değerlendiren aşamadır; yarar sağladığı durumlarda ek işlem süresiyle birlikte düşünülmelidir.^[4]

Burada önemli bir teşhis sınırı vardır: Doğru belge adaylar arasında hiç bulunmadıysa, yalnızca mevcut adayları yeniden sıralamak onu ortaya çıkarmaz. Ek arama veya farklı bir kaynak gerekebilir.

Bu nedenle iki ayrı kayıt isterim: Arama katmanı neleri buldu ve üretici modele gerçekte ne gönderildi? “Belgeyi bulduk” demek, gerekli cümlenin son bağlamda korunduğunu kanıtlamaz.

Daha fazla bağlam her zaman daha iyi mi?

2023 tarihli Lost in the Middle araştırması, test ettiği modeller ve görevlerde ilgili bilginin uzun bağlam içindeki konumunun performansı etkileyebildiğini gösterdi. Bu bulgu bütün güncel modeller için değişmez bir kural değildir; ancak bağlama bilgi eklemekle modelin o bilgiyi doğru kullanmasının aynı şey olmadığını gösteren bir araştırma örneğidir.^[6]

Pratik çıkarımım şu: Değerlendirmeyi yalnızca “gerekli belge gönderildi mi?” düzeyinde bırakmamak gerekir. Gereksiz tekrar, çelişkili sürümler ve kaybolan koşullar da test edilmelidir.

RAG modelin bilgisini günceller mi?

Bir sorguda dış bilgi getirmek, normalde modelin ağırlıklarını o bilgiyle yeniden eğitmek anlamına gelmez. Bilgi, o yanıtı hazırlarken kullanılacak girdiye eklenir. Sonraki sorgularda aynı bilgiye erişilebilmesi, uygulamanın kaynak ve indeks yönetimine bağlıdır.

Ancak buradan “RAG sistemlerinde eğitim olmaz” sonucu çıkarılmamalıdır. İlk RAG çalışması zaten eğitilen bileşenler içeren bir yaklaşım sunar. Bir uygulama da retrieval veya generation bileşenini ayrıca fine-tune edebilir.^[2]

Yaklaşım	Temel müdahale	Tek başına çözmediği sorun
RAG	Yanıt sırasında ilgili dış bilgiyi getirip kullanıma sunmak.	Kaynağın yanlış veya eski olması.
Fine-tuning	Eğitimle model ağırlıklarını belirli görev veya davranışlara uyarlamak.	Her değişen stok kaydını anında öğrenmek.
Prompt tasarımı	Talimatları, örnekleri ve yanıt koşullarını düzenlemek.	Modele hiç sunulmayan ürün kaydını doğrulamak.
Uzun bağlam	Bir istekte daha fazla içeriğin kullanılabilmesine alan açmak.	Gerekli kanıtın seçileceğini ve doğru yorumlanacağını garanti etmek.

Bu ayrım bir seçim reçetesi değildir. Aynı sistem, fine-tune edilmiş bir modeli retrieval ve iyi tasarlanmış talimatlarla birlikte kullanabilir. Önemli olan hangi müdahalenin hangi eksikliği gidermesinin beklendiğidir.

RAG halüsinasyonu ortadan kaldırır mı?

Hayır. Dış kanıt kullanılması hataları azaltmaya yardımcı olabilir; fakat eksik veya ilgisiz kanıtla da yanlış yanıt üretilebilir.^[1] Üstelik iki ayrı doğruluk sorusu vardır:

• Kaynağa sadakat: Yanıt, verilen kanıttan çıkarılabilecek şeyleri mi söylüyor?
• Gerçek doğruluk: Kullanılan kanıt ve ulaşılan sonuç gerçekte doğru mu?

Dün alınmış stok kaydını doğru özetleyen bir yanıt, bugün için yanlış olabilir. Burada model kaynağı çarpıtmamıştır; fakat eski veri, güncel gerçek gibi sunulmuştur. “Grounded” olması, cevabın her koşulda doğru olduğu anlamına gelmez.

Bu ayrımdan çıkardığım tasarım kuralı şu: Kanıt yetersiz olduğunda sistemin seçenekleri yalnızca cevap vermek ve hata yapmak olmamalı. Ek soru sormak, başka kaynak aramak veya doğrulanamayan kısmı açıkça ayırmak da geçerli sonuçlardır.

Kaynak göstermek ile iddiayı desteklemek aynı şey mi?

Bir yanıtın altında bağlantı bulunması, yanıtın bütün iddialarını doğrulamaz. ALCE çalışması da üretici sistemleri yalnızca akıcılık açısından değil, doğruluk ve citation kalitesi açısından değerlendirmeyi ele alır.^[7]

Ben kaynak kontrolünü üç soruyla yaparım:

1. Bağlantı veya belge referansı gerçekten mevcut mu?
2. Kaynak, hemen yanında sunulan iddiayı destekliyor mu?
3. Yanıttaki diğer doğrulanabilir iddialar da yeterli kaynak desteğine sahip mi?

Bir uyumluluk kılavuzu, ürünün mevcut stok durumunu kanıtlamaz. Stok kaydı da kullanıcının bataryasının uyumlu olduğunu göstermez. Aynı üründen söz etmeleri, bu kaynakları birbirinin yerine kullanılabilir hale getirmez.

Dolayısıyla citation kontrolü, yanıtın sonuna birkaç bağlantı eklemekten ibaret olmamalıdır. Kontrol edilen ilişki, iddia ile onu destekleyen kanıt arasındadır.

AI Search, RAG ve query fan-out nasıl ilişkilidir?

Google’ın güncel resmi rehberi, Search’teki üretken AI özelliklerinin temel arama sıralama sistemlerinden ve Search indeksinden yararlandığını; RAG ile ilgili sayfalardaki bilgilerin yanıt üretiminde kullanıldığını açıklar. Aynı rehber, query fan-out’u kullanıcı sorusunu desteklemek için üretilen ilişkili ek sorgular olarak tanımlar.^[8]

İki kavram aynı işi adlandırmaz. RAG, erişilen bilginin üretime bağlanmasıdır. Query fan-out ise daha kapsamlı kanıt toplamak için kullanılabilecek bir arama yaklaşımıdır. RAG uygulamasının mutlaka fan-out yapması gerekmez.

Bu açıklamayı bütün AI ürünlerinin aynı sistemi kullandığı iddiasına dönüştürmemek gerekir. Her soruda arama yapılıp yapılmadığı, hangi kaynakların seçildiği ve kaç aşama çalıştığı ürüne ve uygulamaya göre değişebilir. Kamuya açık bir rehber, gizli sistem ayrıntılarını bildiğimiz anlamına gelmez.

AI Search rehberinde arama deneyiminin daha geniş yapısını ele alıyorum. RAG burada, kanıt bulma ile yanıt üretme arasındaki bağlantıyı açıklayan parçadır.

Hırdavat örneği: Aynı yanlış cevap, üç farklı arıza

Aşağıdaki model kodları ve kayıtlar tamamen kurgusaldır. Örnek, gerçek bir ürün önerisi veya proje sonucu değildir.

Kullanıcı şöyle soruyor: “Elimde A-18 batarya var. M-18 gövdeyle kullanabilir miyim? Ürün bataryalı mı geliyor, şu anda stokta mı?”

Bu soruyu tek bir ürün açıklamasıyla geçiştirmem. Önce hangi iddianın hangi kayıtla doğrulanacağını ayırırım:

İhtiyaç	Örnekteki kayıt	Çıkarılabilecek sonuç
Batarya uyumluluğu	Geçerli uyumluluk belgesi, M-18 ile A-18’i eşleştiriyor; B-18’i hariç tutuyor.	Bu kayıt kapsamında A-18 uyumludur. Bütün bataryalara genellenemez.
Paket içeriği	Seçili ürünün paket kaydında yalnızca gövde bulunuyor.	Bu satış paketinde batarya yoktur. Başka paketler için aynı sonuç çıkarılamaz.
Güncel stok	Envanter sorgusu başarısız; yalnızca önceki güne ait bir kopya var.	Mevcut stok doğrulanamıyor. Eski kayıt güncel stok kanıtı değildir.

Bu koşullarda uygun bir yanıt; uyumluluk belgesinin A-18’i doğruladığını, seçili paketin batarya içermediğini ve anlık stok bilgisinin teyit edilemediğini ayrı ayrı belirtmelidir. Son cümlenin belirsiz olması, ilk iki bilginin de atılması gerektiği anlamına gelmez.

Şimdi sistemin “Evet, tüm bataryalar uyumlu; batarya dahil ve stokta” dediğini varsayalım. Yalnızca yanıtı görmek, arızanın nerede olduğunu söylemez:

• Retrieval hatası: M-18 yerine benzer isimli başka ürünün set kaydı bulunmuş olabilir.
• Bağlam aktarımı hatası: Doğru kayıttaki istisna, paket kapsamı veya zaman bilgisi modele gönderilmemiş olabilir.
• Generation hatası: Gerekli ayrımlar modele gönderildiği halde cevapta yanlış birleştirilmiş olabilir.

Üçüncü sorunu çözmek için retrieval ayarlarını değiştirmek zorunda olmayabiliriz. Birinci sorunda da yalnızca “daha dikkatli cevap ver” talimatını güçlendirmek yeterli olmayabilir. Müdahale, kaybolan kanıtın bulunduğu aşamaya yönelmelidir.

RAG internete bağlanmak veya her şeyi indekslemek mi demek?

İkisi de zorunlu değildir. Bilgi kaynağı açık web olabileceği gibi kapalı bir doküman koleksiyonu da olabilir. Örneğimizde teknik belgeler aranabilir bir indeksten, anlık stok ise yetkili bir veri sorgusundan alınabilir.

Burada ölçüt, getirilen bilginin cevap üretiminde kanıt olarak kullanılmasıdır. Her API çağrısı RAG değildir: Stok bilgisini getirip yanıtı desteklemekle sipariş oluşturmak farklı görevlerdir. RAG’ın varlığı, sisteme işlem yapma yetkisi vermez.

Kaynak erişimi neden bir güvenlik meselesidir?

Bir belgenin soruyla ilgili olması, kullanıcının o belgeyi görmeye yetkili olduğu anlamına gelmez. OWASP, erişim kontrollerinin retrieval sırasında uygulanmasını ve belgeden türetilen parçalarda da korunmasını önerir. Yetkisiz içeriği modele verip gizlemesini beklemek yeterli bir erişim kontrolü değildir.^[9]

Aynı şekilde kaynak içindeki metin, sistem talimatı olarak kabul edilmemelidir. RAG sistemleri, belgelerdeki yönlendirici içeriklerden kaynaklanan prompt injection ve bilgi havuzunun bozulması gibi riskler taşıyabilir. Kaynak doğrulama, izinler ve çıktı denetimi birlikte ele alınmalıdır.^[9]

Katalog örneğinde bunun karşılığı basittir: Kamuya açık ürün özellikleri ile yalnızca çalışanlara açık tedarikçi koşulları, aynı kullanıcıya sunulabilir kanıtlar değildir. Kaynak seçiminde uygunluk kadar erişim hakkı da belirleyicidir.

RAG kalitesi nasıl ölçülür?

Tek bir “RAG başarı puanı” sorunun hangi aşamada olduğunu saklayabilir. Ragas araştırması da ilgili bağlamın bulunması, modelin bu bağlama sadık kalması ve üretilen yanıtın kalitesi gibi boyutları ayrı ele alır.^[10]

Aşağıdaki çerçeve, bir RAG uygulamasını denetlemek için önerdiğim kontrol setidir. Hazır bir aracın tek başına bütün bu soruları cevaplayacağı varsayılmamalıdır.

Katman	Denetim sorusu	Örnek değerlendirme
Retrieval	Gerekli kanıtlar adaylar arasında mı?	Etiketlenmiş test sorularında ilgili kayıtların bulunma oranı.
Bağlam	Bulunan kanıtın gerekli koşulları modele ulaştı mı?	Model, paket kapsamı, istisna ve zaman bilgisinin korunması.
Kaynağa sadakat	Yanıtın iddiaları verilen kanıttan çıkarılabiliyor mu?	Desteklenmeyen genellemelerin kontrolü.
Doğruluk	Yanıt gerçek durumu doğru açıklıyor mu?	Geçerli kayıt veya uzman değerlendirmesiyle karşılaştırma.
Citation	Kaynaklar ilgili iddiaları destekliyor mu?	Desteklenen iddialar ve kaynak kapsamındaki boşluklar.
Belirsizlik yönetimi	Eksik kanıt halinde sınır doğru belirtiliyor mu?	Cevabı bulunmayan sorularda uydurma yerine açıklama veya ek soru.
Operasyon	Sistem kabul edilebilir sürede ve maliyetle çalışıyor mu?	Arama, yeniden sıralama ve üretim sürelerinin ayrı takibi.

Recall@k gibi bir retrieval metriği kullanılıyorsa, neyin sayıldığı açıklanmalıdır: Belge mi, parça mı, kayıt mı? Örneğin etiketlenmiş bir test sorusunda ilgili kabul edilen beş belgeden üçü ilk on sonuçtaysa, belge düzeyinde recall@10 değeri 3/5’tir. Bu, yanıtın yüzde 60 doğru olduğu anlamına gelmez.

Test kümesinde yalnızca kolay ve cevaplanabilir sorular bulunmamalıdır. Benzer model kodları, çelişkili sürümler, eksik kayıtlar, cevaplanamayacak sorular ve erişimi kısıtlı içerikler de denenmelidir. Ortalamalar kadar hangi soru türlerinde başarısız olunduğu da önemlidir.

Otomatik değerlendirmeler incelemeyi hızlandırabilir. Fakat başka bir modelin “doğru” demesi, bağımsız doğrulamanın yerine geçmez. Özellikle kullanıcı kararını etkileyen iddialarda insan kontrolüyle kalibre edilmiş bir test seti gerekir.

Bu ölçüm, SEO görünürlük ölçümüyle aynı mı?

Hayır. Kendi RAG sisteminizin aday kayıtlarını ve modele verdiği bağlamı görebiliyorsanız bileşen düzeyinde test yapabilirsiniz. Dış bir AI platformunun yanıtında sitenizi görmek, o platformun retrieval başarısını veya tüm kaynak seçim sürecini ölçtüğünüz anlamına gelmez.

Bir sayfanın kaynak gösterilmesi, siteye ziyaret gelmesi ve kullanıcının işlem yapması da ayrı olaylardır. Sistemin cevap kalitesiyle sitenin ticari katkısını aynı puanda birleştirmek yerine, her biri için uygun veriyi toplamak gerekir.

RAG’ın SEO açısından anlamı ne?

SEO açısından çıkarımım, her paragrafı yapay zekâ için yeniden yazmak değil; sayfanın hangi soruya, hangi koşullarda ve hangi kanıtla cevap verdiğini netleştirmektir.

Katalog örneğinde bunun karşılığı; tam model kimliğini, uyumluluk kapsamını, paket içeriğini ve stok bilgisinin güncelliğini birbirinden ayırmaktır. Bir rehberde ise iddianın dayanağını ve istisnalarını anlaşılır biçimde sunmaktır. Bunlar önce insanın kararını kolaylaştıran içerik kararlarıdır.

Google, üretken arama için özel bir schema türü gerekmediğini, llms.txt dosyalarını Search görünürlüğünde kullanmadığını ve içeriği küçük parçalara bölme zorunluluğu bulunmadığını açıkça belirtir. Bu açıklamalar Google Search kapsamındadır; başka bir uygulamanın kendi veri alma gereksinimlerini tanımlamaz.^[8]

Dolayısıyla bir RAG uygulamasının indeksleme sırasında belgeyi parçalaması, yayıncının her parçayı ayrı URL yapması gerektiği anlamına gelmez. Teknik veri hazırlama kararı ile sitenin içerik mimarisi kararı farklıdır.

Bir RAG sistemine bakarken hangi sorular sorulmalı?

1. Hangi kullanıcı ihtiyacı için hangi kanıt türleri gerekiyor?
2. Kaynakların kimliği, güncelliği ve erişim izinleri korunuyor mu?
3. Gerekli kayıt ilk retrieval sonucunda bulunuyor mu?
4. Kaydın koşulları ve istisnaları son bağlama taşınıyor mu?
5. Üretilen iddialar gerçekten bu bağlamla destekleniyor mu?
6. Eksik veya çelişkili kanıt geldiğinde sistem ne yapıyor?
7. Bu davranışlar tekrar edilebilir bir test kümesiyle kontrol ediliyor mu?

Bu soruların değeri, bir teknoloji listesi çıkarmaktan çok yanlış cevabın nedenini ayırabilmeleridir. Yeni model, daha büyük indeks veya daha uzun bağlam ancak belirlenen sorunu çözdüğü ölçüde anlamlıdır.

RAG’ın temel ayrımı

Bilgiyi bulmak, onu doğru bağlamda sunmak ve ondan güvenilir bir cevap üretmek üç farklı iştir. RAG bu işleri birbirine bağlar; hiçbirini otomatik olarak kusursuz hale getirmez.

Information Retrieval açısından soru “İlgili kanıt bulunabildi mi?” iken, RAG ile buna “Bu kanıt cevabı gerçekten destekliyor mu?” sorusu eklenir. İyi bir değerlendirme ikisini de sorar; yalnızca akıcı son metne bakmaz.

Kaynaklar ve teknik referanslar

Kaynaklar 27 Ağustos 2026 tarihinde kontrol edildi. Araştırma bulguları, ilgili çalışmaların test ettiği sistemler ve koşullar kapsamında aktarılmıştır.

1. Microsoft Learn — Retrieval augmented generation (RAG) and indexes
2. Lewis ve diğerleri — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
3. Microsoft Learn — Vector index overview
4. Microsoft Architecture Center — RAG information-retrieval phase
5. Anthropic — Introducing Contextual Retrieval
6. Liu ve diğerleri — Lost in the Middle: How Language Models Use Long Contexts
7. Gao ve diğerleri — Enabling Large Language Models to Generate Text with Citations
8. Google Search Central — Optimizing your website for generative AI features on Google Search
9. OWASP Cheat Sheet Series — RAG Security
10. Es ve diğerleri — Ragas: Automated Evaluation of Retrieval Augmented Generation