RAG Nedir? Retrieval Augmented Generation Nasıl Çalışır?

RAG nedir? RAG (Retrieval Augmented Generation, Türkçesiyle “getirim ile zenginleştirilmiş üretim”), bir büyük dil modelinin cevap üretmeden önce harici bir bilgi kaynağından ilgili belgeleri arayıp bu belgeleri istemine (prompt) ekleyerek daha doğru ve güncel yanıtlar vermesini sağlayan bir mimari yaklaşımdır. Model, yalnızca eğitim verisinde ezberlediği bilgiye güvenmek yerine, soruya özel olarak getirilen gerçek dokümanlara dayanarak cevap üretir.

Bu yaklaşımın popülerleşmesinin arkasında somut bir problem var: büyük dil modelleri belirli bir tarihte eğitimi donduruluyor, şirket içi verilere erişemiyor ve zaman zaman yapay zeka halüsinasyonu denen, kulağa inandırıcı gelen ama yanlış bilgiler üretebiliyor. RAG, modele “bildiklerini kullan” demek yerine “önce bak, sonra cevapla” diyen bir mimari kurarak bu sorunları azaltmayı hedefliyor.

RAG Nedir, Neden Ortaya Çıktı?

RAG kavramı ilk olarak 2020 yılında Facebook AI Research (bugünkü Meta AI) tarafından yayımlanan bir araştırma makalesiyle akademik literatüre girdi. Ancak kavramın asıl patlaması, 2023-2024 döneminde şirketlerin kendi iç dokümanlarını, destek kayıtlarını ve ürün kataloglarını yapay zeka sohbet botlarına entegre etme ihtiyacıyla oldu. 2026 itibarıyla RAG, kurumsal yapay zeka projelerinin büyük çoğunluğunda varsayılan mimari yaklaşımlardan biri haline geldi.

Sorunun özü şu: bir dil modeline “şirketimizin 2026 iade politikası nedir?” diye sorduğunuzda, model bu bilgiyi eğitim verisinde görmemiş olabilir. İki çözüm var: modeli bu veriyle yeniden eğitmek (fine-tuning) ya da modele soru sorulduğu anda ilgili belgeyi bulup sunmak (RAG). Pratikte RAG, güncelleme hızı ve maliyet açısından çoğu senaryoda daha uygulanabilir çıkıyor.

RAG ile Basit Prompt Mühendisliği Arasındaki Fark

Bazı ekipler “ben zaten dokümanı prompt’a yapıştırıyorum, bu da RAG değil mi?” diye soruyor. Kısmen doğru, ama eksik. RAG’ı asıl güçlü kılan, binlerce hatta milyonlarca doküman arasından sorguya en alakalı parçaları otomatik olarak bulabilmesi. Elle kopyala-yapıştır yaklaşımı birkaç sayfalık dokümanda işe yarar; kurumsal ölçekte on binlerce sayfalık bir bilgi tabanında ise otomatik getirim mekanizması olmadan bu iş yürümez.

RAG Nasıl Çalışır? Adım Adım Mimari

Bir RAG sisteminin işleyişi beş temel aşamaya ayrılabilir. Her aşamada yapılan teknik tercihler, sistemin doğruluğunu ve maliyetini doğrudan etkiliyor.

1. Doküman Parçalama (Chunking)

Ham dokümanlar (PDF, HTML, Word, veritabanı kayıtları) önce anlamlı parçalara bölünür. Parça boyutu genellikle 300-800 token arasında tutulur; çok küçük parçalar bağlamı kaybettirir, çok büyük parçalar ise getirimin hassasiyetini düşürür. Pratikte parçalar arasında yüzde 10-20 oranında örtüşme (overlap) bırakmak, bir cümlenin iki parça arasında bölünüp anlamını kaybetmesini engeller.

2. Embedding Oluşturma

Her doküman parçası, bir embedding modeli aracılığıyla sayısal bir vektöre dönüştürülür. Bu vektör, metnin anlamsal içeriğini yüzlerce veya binlerce boyutlu bir uzayda temsil eder. Benzer anlama sahip iki metin, bu uzayda birbirine yakın konumlanır.

3. Vektör Veritabanında Saklama

Üretilen vektörler, hızlı benzerlik araması yapabilen bir vektör veritabanında saklanır. Bu veritabanları, milyonlarca vektör arasında milisaniyeler içinde “en yakın komşu” araması yapabilecek şekilde optimize edilmiştir.

4. Retrieval (Getirme) Aşaması

Kullanıcı bir soru sorduğunda, sorunun kendisi de aynı embedding modeliyle bir vektöre dönüştürülür. Sistem, bu vektöre en yakın (anlamsal olarak en alakalı) doküman parçalarını vektör veritabanından çeker. Genellikle en alakalı 3 ila 10 parça seçilir.

5. Generation (Üretim) Aşaması

Getirilen parçalar, kullanıcının sorusuyla birlikte dil modeline bir istem (prompt) içinde sunulur. Model, artık kendi ezberine değil, önüne konan gerçek belgelere dayanarak cevap üretir. Bu aşamada modelin ne kadar bağlam işleyebileceği de önemli; konuyla ilgili daha fazla teknik detay için context window nedir yazımıza bakabilirsiniz.

Basit Bir RAG Pipeline’ı Kod Örneğiyle

Aşağıdaki Python örneği embedding ve en benzer parçanın seçimini gösterir; yanıt üretimi içermez. Veriler varsayımsal bir mağaza örneğidir. API anahtarını OPENAI_API_KEY ortam değişkeninde tutun; istekler ücretli olabilir. Üretim adımı için aşağıdaki ayrı API şablonuna bakın.

import openai
import numpy as np

# 1) Doküman parçalarını embedding'e çevir
def embed(text):
    response = openai.embeddings.create(
        model="text-embedding-3-small",
        input=text
    )
    return np.array(response.data[0].embedding)

chunks = [
    "İade süreci sipariş tarihinden itibaren 30 gün içinde başlatılabilir.",
    "Kargo ücreti, hatalı ürün iadelerinde şirket tarafından karşılanır.",
    "Dijital indirmeler örnek mağazanın Hesabım bölümünde listelenir."
]
chunk_vectors = [embed(c) for c in chunks]

# 2) Kullanıcı sorusunu embedding'e çevir
query = "Dijital indirmeyi nerede bulabilirim?"
query_vector = embed(query)

# 3) Kosinüs benzerliğiyle en alakalı parçayı bul
def cosine_similarity(a, b):
    return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))

scores = [cosine_similarity(query_vector, v) for v in chunk_vectors]
best_chunk = chunks[int(np.argmax(scores))]
print("En alakalı bilgi:", best_chunk)

Gerçek bir sistemde üçüncü adımdaki döngüsel karşılaştırma yerine, milyonlarca vektörü verimli şekilde tarayabilen bir vektör veritabanı kullanılır. Küçük ölçekli projeler için bu döngüsel yaklaşım bile işe yarayabilir; ancak binlerce dokümanı aştığınızda performans ciddi şekilde düşer.

Gelişmiş RAG Teknikleri: Yeniden Sıralama ve Hibrit Arama

Temel RAG mimarisi birçok senaryoda yeterli olsa da, doğruluk gereksinimi yüksek projelerde birkaç ek teknik devreye giriyor. Bu tekniklerin ortak amacı, modele sunulan bağlamın kalitesini artırmak; çünkü RAG’ın nihai doğruluğu, büyük ölçüde getirilen belgelerin ne kadar alakalı olduğuna bağlı.

Yeniden Sıralama (Re-ranking)

İlk aşamada vektör benzerliğiyle 20-50 aday parça getirilir, ardından bu adaylar daha güçlü ama daha yavaş çalışan bir “cross-encoder” modeliyle yeniden sıralanır. Bu iki aşamalı yaklaşım, hızlı ama kaba bir ilk filtreleme ile yavaş ama hassas bir ikinci filtrelemeyi birleştirerek hem hız hem doğruluk kazandırır. Cohere Rerank ve açık kaynak BGE-reranker gibi modeller bu amaçla yaygın kullanılıyor.

Hibrit Arama (Hybrid Search)

Salt vektör (anlamsal) arama, ürün kodu, hata kodu veya özel isim gibi tam eşleşme gerektiren sorgularda zayıf kalabilir. Hibrit arama, klasik anahtar kelime araması (BM25 gibi) ile vektör aramasını birleştirerek her iki yaklaşımın güçlü yanlarından faydalanır. Weaviate ve Qdrant gibi araçlar bu hibrit modu doğrudan destekliyor.

Çok Adımlı Getirim (Multi-Hop Retrieval)

Bazı sorular tek bir belgeyle cevaplanamaz; birden fazla belgeden gelen bilginin birleştirilmesi gerekir. Çok adımlı getirim yaklaşımında sistem, ilk getirilen belgelerden yola çıkarak ek sorgular üretir ve ikinci bir getirim turu yapar. Bu yöntem, karmaşık araştırma sorularında doğruluğu artırır ama gecikmeyi ve maliyeti de yükseltir; bu yüzden her sorguya değil, gerektiğinde devreye sokulmalıdır.

RAG Sisteminin Maliyeti Ne Kadar Tutar?

RAG maliyeti üç ana kalemden oluşur: embedding oluşturma, vektör veritabanı barındırma ve model çağrısı (generation). Küçük ölçekli bir proje için embedding maliyeti genellikle ihmal edilebilir düzeydedir; örneğin birkaç bin sayfalık bir doküman kümesini embedding’lemenin maliyeti çoğu sağlayıcıda birkaç dolar seviyesindedir. Asıl tekrarlayan maliyet, her kullanıcı sorgusunda yapılan model çağrısından (generation) kaynaklanır, çünkü bağlama eklenen belgeler istem uzunluğunu artırır ve bu da token başına ücretlendirmeyi doğrudan etkiler.

Vektör veritabanı tarafında ise tam yönetilen hizmetler (Pinecone gibi) kullanım hacmine göre aylık ücretlendirme yaparken, kendi sunucunuzda çalıştırdığınız açık kaynak seçenekler (Qdrant, Weaviate, pgvector) yalnızca sunucu maliyetini üstlenmenizi gerektirir. Bütçesi sınırlı projeler için mevcut bir PostgreSQL sunucusuna pgvector eklentisini kurmak, ayrı bir sistem işletme maliyetinden kaçınmanın pratik bir yolu.

RAG İçin Vektör Veritabanı Seçimi

Vektör veritabanı seçimi, projenin ölçeğine, bütçesine ve mevcut altyapınıza göre değişir. Aşağıdaki tablo, 2026 itibarıyla yaygın kullanılan seçenekleri karşılaştırıyor.

Küçük ve orta ölçekli projeler için pgvector, zaten bir PostgreSQL veritabanı işletiyorsanız pratik bir başlangıç noktası. Yüksek trafikli, milyonlarca dokümanlık kurumsal sistemlerde ise Pinecone veya Qdrant gibi özel olarak vektör araması için optimize edilmiş çözümler daha iyi performans sunuyor.

Getirilen belgeleri bir dil modeline gönderirken, API isteğinin yapısı genellikle şu şekle benzer:

curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4.1-mini",
    "messages": [
      {"role": "system", "content": "Sadece verilen bağlamdaki bilgileri kullanarak cevap ver."},
      {"role": "user", "content": "Bağlam: Dijital indirmeler örnek mağazanın Hesabım bölümünde listelenir.\n\nSoru: Dijital indirmeyi nerede bulabilirim?"}
    ]
  }'

Adım Adım: Kendi RAG Sisteminizi Nasıl Kurarsınız?

1. Kaynak dokümanları belirleyin. PDF, Word, HTML sayfası, veritabanı kaydı veya destek biletleri gibi hangi verinin sisteme dahil edileceğine karar verin.
2. Dokümanları temizleyin ve parçalayın. Gereksiz başlık/altbilgi metinlerini temizleyin, ardından 300-800 token aralığında, örtüşmeli parçalara bölün.
3. Embedding modelini seçin. OpenAI’nin text-embedding-3-small/large, Google’ın gemini-embedding veya açık kaynak alternatiflerinden (BGE, E5 gibi) birini test edin.
4. Vektör veritabanını kurun. Yukarıdaki tablodan projenizin ölçeğine uygun aracı seçip parçaları embedding’leriyle birlikte kaydedin.
5. Getirim mantığını test edin. Gerçek kullanıcı sorularıyla deneme yapıp doğru parçaların getirilip getirilmediğini manuel olarak kontrol edin.
6. Üretim istemini (prompt) yazın. Modele “yalnızca verilen bağlamı kullan, bilmiyorsan bilmediğini söyle” gibi net talimatlar verin.
7. Değerlendirme döngüsü kurun. Gerçek kullanıcı sorgularını ve model cevaplarını loglayıp düzenli olarak doğruluk kontrolü yapın.

RAG Sisteminin Başarısı Nasıl Ölçülür?

Bir RAG sistemi kurduktan sonra “çalışıyor mu?” sorusunu öznel izlenimlerle değil, ölçülebilir metriklerle cevaplamak gerekir. Sektörde yaygın kullanılan üç temel metrik grubu var.

Getirim Kalitesi (Retrieval Metrics)

Precision (kesinlik), getirilen parçaların ne kadarının gerçekten alakalı olduğunu; recall (duyarlılık) ise alakalı olması gereken parçaların ne kadarının gerçekten getirildiğini ölçer. Bu iki metriği hesaplamak için, önceden hazırlanmış bir soru-doğru cevap belge çiftinden oluşan bir test seti gerekir.

Üretim Kalitesi (Generation Metrics)

Faithfulness (sadakat), modelin cevabının yalnızca getirilen bağlama dayanıp dayanmadığını; answer relevancy ise cevabın kullanıcının sorduğu soruyla ne kadar örtüştüğünü ölçer. RAGAS gibi açık kaynak değerlendirme kütüphaneleri, bu metrikleri otomatik olarak hesaplamak için kullanılabilir.

Kullanıcı Geri Bildirimi

Otomatik metrikler her zaman gerçek kullanıcı memnuniyetini yansıtmayabilir. Bu yüzden üretim ortamında basit bir “bu cevap yardımcı oldu mu?” geri bildirim mekanizması eklemek, sistemi zaman içinde iyileştirmek için değerli bir veri kaynağı oluşturur. Düşük puan alan sorguları düzenli olarak inceleyip hangi aşamada (getirim mi, üretim mi) sorun yaşandığını tespit etmek, iyileştirme çalışmalarının en verimli başlangıç noktasıdır.

Sık Yapılan Hatalar ve Çözümleri

• Parça boyutunu çok büyük tutmak: Aşırı büyük parçalar getirimin isabetini düşürür. Çözüm: 300-800 token aralığında kalıp örtüşme ekleyin.
• Getirilen belge sayısını sabit ve düşük tutmak: Her soru için yalnızca 1 parça getirmek, karmaşık sorularda eksik bağlam bırakır. Çözüm: Soru karmaşıklığına göre 3-10 arası dinamik bir getirim sayısı kullanın.
• Modeli bağlamla sınırlamamak: Sistem istemine “sadece bağlamı kullan” talimatı eklenmezse model yine de eğitim verisinden halüsinasyon üretebilir. Çözüm: Açık ve sınırlayıcı bir sistem istemi yazın.
• Embedding modelini değiştirirken indeksleri karıştırmak: Sorgu ve belge embedding’leri aynı uyumlu model/yapılandırmadan gelmelidir. Yeni indeksi ayrı oluşturup test edin, sonra trafiği ona taşıyın; eski indeksi geri dönüş için kontrollü süre saklayın.
• Değerlendirmeyi hiç yapmamak: Sistemin “çalıştığını varsaymak” en yaygın hata. Çözüm: Gerçek kullanıcı sorularından oluşan küçük bir test seti oluşturup düzenli aralıklarla doğruluğu ölçün.

RAG mi, Fine-Tuning mi, Uzun Bağlam Penceresi mi?

RAG tek çözüm değil; duruma göre fine-tuning veya doğrudan uzun bağlam penceresine güvenmek de mantıklı olabilir. RAG, sık güncellenen ve büyük hacimli bilgi kaynakları için uygundur. Fine-tuning, modelin üslubunu veya davranış kalıbını değiştirmek istediğinizde daha etkilidir. Uzun bağlam penceresi ise doküman sayısı azsa ve her seferinde tüm belgeyi modele gönderebiliyorsanız basit bir alternatif olabilir; ancak maliyet ve gecikme açısından RAG genellikle daha verimli kalır.

Güvenlik ve Performans Notları

RAG sistemleri, harici veri kaynaklarını doğrudan modele bağladığı için birkaç ek güvenlik ve performans riski taşır. Bu riskleri göz ardı etmek, teknik olarak çalışan ama üretimde sorun çıkaran bir sisteme yol açabilir.

• Erişim kontrolü: Vektör veritabanınızda farklı kullanıcı gruplarına ait belgeler varsa, getirim aşamasında yetkilendirme kontrolü yapılmazsa bir kullanıcı başka bir kullanıcıya ait gizli belgelere erişebilir. Belge düzeyinde erişim etiketleri (metadata filtreleme) kullanılmalı.
• Prompt injection riski: Getirilen belgeler arasında kötü niyetli talimatlar içeren bir metin varsa, model bu talimatları kullanıcı talimatıymış gibi işleyebilir. Sistem isteminde net sınırlar çizmek ve harici içeriği “veri” olarak işaretlemek bu riski azaltır.
• Gecikme birikimi: Embedding çağrısı, vektör araması, yeniden sıralama ve model çağrısı art arda çalıştığında toplam gecikme saniyeleri bulabilir. Kritik uygulamalarda önbellekleme ve asenkron işlem sırası kullanılmalı.
• Veri tazeliği: Kaynak dokümanlar güncellendiğinde vektör veritabanının da güncellenmesi gerekir; otomatik bir yeniden indeksleme (re-indexing) süreci kurulmazsa sistem eski bilgiyle cevap vermeye devam eder.

Gerçek Bir Kullanım Senaryosu

Orta ölçekli bir e-ticaret şirketini örnek alalım: müşteri hizmetleri ekibi günde yüzlerce benzer soruyla uğraşıyor (kargo süresi, iade koşulları, garanti kapsamı). Şirket, yardım merkezi makalelerini ve sık sorulan soru arşivini bir vektör veritabanına aktarıp bunun üzerine bir RAG destek botu kuruyor. Sonuç olarak, ekip zamanının büyük kısmını tekrarlayan sorulara değil, gerçekten karmaşık ve özel durum gerektiren taleplere ayırabiliyor. Bu senaryoda kritik nokta, botun “bilmiyorum, bir temsilciye yönlendireyim” diyebilmesi; yani sistem isteminde bağlam dışına çıkmaması gerektiğinin açıkça belirtilmesi.

Kime, Hangi Durumda RAG Uygun?

RAG; müşteri destek botları, iç bilgi bankası asistanları, hukuki veya teknik doküman arama sistemleri ve sık güncellenen ürün kataloglarına dayalı sohbet botları için uygun bir seçim. Buna karşılık, doküman sayısı çok azsa, veri neredeyse hiç değişmiyorsa veya modelin üslup/davranışını kökten değiştirmeniz gerekiyorsa RAG yerine daha basit bir prompt yaklaşımı ya da fine-tuning düşünülebilir. Karar verirken beklenen doğruluk artışını, kurulum ve bakım maliyetiyle karşılaştırmak faydalı olur. Küçük bir ekipseniz ve hızlı bir prototip istiyorsanız, Chroma veya pgvector ile bir hafta içinde çalışan bir ilk sürüm çıkarmak, doğru mimariye karar vermeden önce gerçek kullanıcı geri bildirimi toplamanın en pratik yolu.

Sık Sorulan Sorular

RAG nedir, kısaca nasıl özetlenir?

RAG, bir dil modelinin cevap üretmeden önce harici bir kaynaktan ilgili belgeleri getirip bu belgeleri istemine ekleyerek daha doğru ve güncel yanıtlar üretmesini sağlayan bir mimaridir.

RAG kurmak için mutlaka vektör veritabanı mı gerekir?

Hayır. RAG, anahtar kelime/BM25 araması, SQL sorgusu, vektör araması veya hibrit getirim kullanabilir. Vektör veritabanı seçiminde belge sayısına ek olarak sorgu yükü, gecikme hedefi, filtreleme ve mevcut altyapı değerlendirilir; tek bir belge sayısı sınırı bunu zorunlu kılmaz.

RAG, yapay zeka halüsinasyonunu tamamen ortadan kaldırır mı?

Hayır, halüsinasyon riskini azaltır ama tamamen ortadan kaldırmaz. Model yine de getirilen bağlamı yanlış yorumlayabilir; bu yüzden sistem isteminde net sınırlar koymak önemlidir.

RAG mi fine-tuning mi daha maliyetlidir?

Genellikle RAG kurulumu, fine-tuning’e göre daha düşük başlangıç maliyetiyle uygulanabilir ve veri güncellendiğinde yeniden eğitim gerektirmez; fine-tuning ise model davranışını kalıcı olarak değiştirmek istediğinizde daha uygundur.

Küçük bir WordPress veya işletme sitesi için RAG gerekli mi?

Çoğu küçük site için gerekli değildir; ancak sitenizde binlerce sayfalık bir bilgi tabanı, sık sorulan soru arşivi veya ürün kataloğu varsa, bir müşteri destek asistanı için RAG değerli bir yatırım olabilir.

Örnekleri Üretime Taşımadan Önce

300–800 token ve yüzde 10–20 örtüşme başlangıç denemeleridir; evrensel en iyi ayarlar değildir. En yakın parça her zaman ilgili değildir: düşük eşleşmede cevap üretmemeyi test edin. Kaynak kimliği, tarih ve sürümü saklayın; yanıttaki iddianın gösterilen kaynakta gerçekten bulunduğunu değerlendirin. Sistem istemi tek başına doğruluğu veya prompt injection korumasını garanti etmez. Yetki filtresini getirimden önce uygulayın ve belgelerdeki talimatları kullanıcı yetkisi saymayın. Loglarda müşteri sırlarını ve kişisel verileri gereksiz saklamayın.

Teknik kaynak: Lewis ve diğerleri — Retrieval-Augmented Generation, 2020.