RAG Nedir? Retrieval Augmented Generation Rehberi 2026

RAG nedir? Retrieval-Augmented Generation, modelin yanıt üretirken harici bir kaynaktan getirilen ilgili bilgileri bağlam olarak kullanmasıdır. Getirim vektör araması, anahtar kelime araması veya bunların birleşimiyle yapılabilir; ayrı bir vektör veritabanı zorunlu değildir. Bilginin güncelliği indeksin güncellenmesine bağlıdır ve getirilen kaynaklar doğru yanıt garantisi vermez. Bu rehberde metin tabanlı bir RAG akışını inceliyoruz.

RAG Nedir, Yapay Zeka Neden Buna İhtiyaç Duyar?

Büyük dil modelleri (LLM), eğitildikleri veri kümesinin “dondurulmuş” bir anlık görüntüsü üzerinde çalışır. Bu durum iki temel soruna yol açar: model, eğitim tarihinden sonra gerçekleşen olaylar hakkında bilgi sahibi değildir ve kurum içi, özel veya güncel belgeler hakkında hiçbir fikri yoktur. Bu iki soruna verilen en yaygın teknik cevap RAG mimarisidir.

Büyük Dil Modellerinin Sınırları

Bir LLM’e “şirketimizin 2026 ikinci çeyrek satış politikası nedir” diye sorduğunuzda, model bu bilgiyi eğitim verisinde görmediği için ya “bilmiyorum” der ya da -daha kötüsü- gerçekçi görünen ama uydurma bir cevap üretir. Bu duruma sektörde “halüsinasyon” deniyor ve kurumsal yapay zeka projelerinin en büyük güven problemlerinden biri.

RAG’in Çözdüğü Problem

RAG, modelin kendi ağırlıklarını yeniden eğitmek yerine, sorgu anında ilgili belgeleri dışarıdan “ödünç alarak” bağlama ekler. Böylece model, gerçekten elinde olan bir kaynağa dayanarak cevap verir ve genellikle kullandığı kaynağı da referans gösterebilir. Bu yaklaşım, özellikle sık güncellenen bilgi tabanları (dokümantasyon, mevzuat, ürün katalogları, destek kayıtları) için fine-tuning’e kıyasla çok daha pratik bir çözüm sunar.

RAG Nasıl Çalışır? Mimarinin Üç Aşaması

RAG nasıl çalışır sorusunu üç aşamalı bir boru hattı (pipeline) olarak düşünebilirsiniz: getirim, zenginleştirme ve üretim.

Retrieval (Getirim) Aşaması

Kullanıcının sorgusu önce bir embedding modeliyle sayısal bir vektöre dönüştürülür. Bu vektör, önceden indekslenmiş belge parçalarının (chunk) vektörleriyle karşılaştırılır ve anlamsal olarak en yakın olan parçalar bulunur. Bu işlem genellikle kosinüs benzerliği (cosine similarity) veya benzer bir mesafe metriği ile yapılır.

Augmentation (Zenginleştirme) Aşaması

Bulunan belge parçaları, kullanıcının orijinal sorusuyla birlikte modele gönderilecek istemin içine yerleştirilir. Bu adımda genellikle “aşağıdaki bağlamı kullanarak soruyu yanıtla” tarzında bir sistem talimatı da eklenir.

Generation (Üretim) Aşaması

Zenginleştirilmiş istem, büyük dil modeline gönderilir ve model, hem kendi genel dil yeteneğini hem de sağlanan bağlamı kullanarak nihai yanıtı üretir. İyi tasarlanmış bir RAG sisteminde model, yanıtını hangi belgeye dayandırdığını da (kaynak/alıntı olarak) döndürebilir.

Gelişmiş RAG Teknikleri: Hybrid Search ve Re-ranking

Temel RAG mimarisi tek başına vektör benzerliğine dayanır, ancak üretim ortamındaki birçok sistem bunu tek başına yeterli bulmaz. 2026 itibarıyla olgunlaşmış RAG uygulamalarında yaygın olarak görülen iki teknik öne çıkıyor: hibrit arama (hybrid search) ve yeniden sıralama (re-ranking).

Hibrit Arama Neden Gerekli?

Saf vektör araması, anlamsal olarak yakın ama anahtar kelime açısından tam eşleşmeyen sonuçları bazen kaçırabilir; örneğin bir ürün kodu veya hata numarası gibi tam eşleşme gerektiren aramalarda vektör benzerliği tek başına yetersiz kalabilir. Hibrit arama, klasik anahtar kelime tabanlı arama (BM25 gibi bir algoritma) ile vektör aramasını birleştirerek her iki yaklaşımın güçlü yönlerini bir araya getirir. Weaviate ve Qdrant gibi modern vektör veritabanları bu hibrit arama modunu yerleşik olarak destekliyor.

Re-ranking Katmanı

Yeniden sıralama, ilk aramadan gelen adayları sorguyla birlikte puanlayabilir. Aday ve sonuç sayısı bir ayardır; 20–50 aday ile 3–5 sonuç ancak deneme başlangıcıdır. Kalite kazanımı ve ek gecikmeyi aynı test kümesinde ölçün.

Sorgu Yeniden Yazımı (Query Rewriting)

Kullanıcıların yazdığı sorgular çoğu zaman belirsiz veya eksik bağlam içerir. Sorgu yeniden yazımı adımında, kullanıcı sorgusu getirim işleminden önce bir dil modeli tarafından daha açık ve arama dostu bir forma dönüştürülür. Örneğin “geçen ayki fatura” gibi göreli bir ifade, konuşma geçmişinden faydalanılarak somut bir tarih aralığına çevrilebilir. Bu teknik özellikle çok turlu (multi-turn) sohbet arayüzlerinde getirim kalitesini belirgin şekilde artırır.

RAG Mimarisinin Temel Bileşenleri

Pratikte bir RAG sistemi kurarken karar vermeniz gereken iki temel bileşen var: embedding modeli ve vektör veritabanı.

Embedding Modelleri Nasıl Seçilir?

Embedding modeli metni vektöre çevirir. text-embedding-3-small ve text-embedding-3-large için varsayılan boyutlar sırasıyla 1.536 ve 3.072’dir; boyut azaltma destekleri de bulunur. Modeli gerçek Türkçe sorgularla değerlendirin. API bedelini güncel fiyat sayfasından kontrol edin; kendi sunucunuzda açık kaynak model çalıştırmak da işlemci, bellek ve bakım maliyeti taşır.

Türkçe içerik ağırlıklı projelerde ekstra bir kontrol noktası daha var: seçilen embedding modelinin çok dilli (multilingual) desteğinin gerçekten Türkçe morfolojik yapıyı iyi işleyip işlemediği. Bazı embedding modelleri İngilizce metinlerde çok başarılıyken, eklerin yoğun kullanıldığı Türkçe gibi dillerde anlamsal yakınlığı daha zayıf yakalayabiliyor. Bu nedenle Türkçe ağırlıklı bir proje için model seçimi yapılırken, gerçek sorgu-belge çiftleri üzerinde küçük bir pilot test çalıştırmak, sadece genel bir kıyaslama tablosuna (benchmark) güvenmekten daha güvenilir sonuç veriyor.

Vektör Veritabanı Seçenekleri

Vektör veritabanı, embedding’lerin depolandığı ve hızlı benzerlik aramasının yapıldığı katmandır. Aşağıdaki tablo, yaygın kullanılan dört seçeneği karşılaştırıyor.

İndeksleme maliyetini sayfa sayısı yerine ölçülen token sayısı üzerinden hesaplayın: token sayısı × birim embedding fiyatı. Yeniden indeksleme, veritabanı barındırma, sorgu embedding’i, yeniden sıralama ve yanıt üreten model çağrıları da toplam bedele dahildir.

Zaten bir PostgreSQL veritabanı kullanıyorsanız ve vektör sayınız birkaç milyonu geçmiyorsa, yeni bir sistem öğrenmek yerine MCP tabanlı araç entegrasyonlarıyla da uyumlu çalışan pgvector eklentisiyle başlamak pratik bir tercih olabilir.

RAG, Fine-Tuning ve Uzun Bağlam Penceresi Karşılaştırması

RAG, tek yapay zeka özelleştirme yöntemi değil. Aşağıdaki tablo üç yaygın yaklaşımı karşılaştırıyor.

Pratikte birçok üretim sistemi bu üç yaklaşımı birlikte kullanır: temel davranış ve ton için hafif bir fine-tuning, güncel/özel bilgi için RAG, kısa bağlamlı ek notlar için de context window’un kendisi. Modelin muhakeme adımlarını nasıl kurduğunu daha iyi anlamak isteyenler chain of thought rehberimize göz atabilir.

Basit Bir RAG Sistemi Nasıl Kurulur?

Aşağıdaki adımlar, küçük ölçekli bir doküman tabanı (örneğin bir şirketin destek dokümantasyonu) için basit bir RAG sistemi kurmanın genel akışını gösteriyor.

1. Belgelerinizi 300-800 token uzunluğunda parçalara (chunk) bölün; çok küçük parçalar bağlamı zayıflatır, çok büyük parçalar ise alakasız bilgi getirme riskini artırır. Parçalar arasında yaklaşık yüzde 10-15 oranında örtüşme (overlap) bırakmak, bir cümlenin ortasından bölünüp anlamının kaybolmasını önler.
2. Her parça için bir embedding modeliyle vektör oluşturun ve parçayla birlikte kaynak dosya adı, bölüm başlığı ve son güncelleme tarihi gibi metadata bilgilerini de saklayın; bu metadata daha sonra hem kaynak gösterimi hem de filtreleme için kullanılır.
3. Vektörleri seçtiğiniz vektör veritabanına, orijinal metin ve kaynak bilgisiyle birlikte kaydedin. Büyük veri kümelerinde bu işlemi toplu (batch) olarak yapmak API çağrı sayısını ve maliyeti azaltır.
4. Kullanıcı sorgusu geldiğinde aynı embedding modeliyle sorguyu vektöre çevirin ve veritabanında en yakın 3-5 parçayı arayın; gerekiyorsa bu adımda kullanıcının erişim yetkisine göre metadata filtrelemesi de uygulayın.
5. Getirilen parçaları sistem talimatıyla birleştirip modele gönderin ve yanıtı kaynaklarıyla birlikte kullanıcıya sunun; kaynak gösterimi, kullanıcıların yanıtı doğrulamasını kolaylaştırır ve güveni artırır.

Aşağıdaki Python örneği, belge parçalarını embedding’e çevirip bir vektör veritabanına kaydetme adımını basitleştirilmiş biçimde gösteriyor:

from openai import OpenAI
client = OpenAI()

def embed_chunks(chunks: list[str]):
    response = client.embeddings.create(
        model="text-embedding-3-small",
        input=chunks
    )
    return [item.embedding for item in response.data]

chunks = [
    "Ürün iade süresi teslimattan itibaren 14 gündür.",
    "Kurumsal müşteriler için destek hattı 09:00-18:00 arası aktiftir.",
]
vectors = embed_chunks(chunks)
print(f"{len(vectors)} parça embedding'e çevrildi, boyut: {len(vectors[0])}")

Kayıtlı vektörler üzerinde arama yaparken, pgvector kullanıyorsanız aşağıdakine benzer bir SQL sorgusu en yakın belgeleri getirir:

SELECT content, source_url
FROM documents
ORDER BY embedding <=> $1::vector
LIMIT 5;

<=> kosinüs mesafesidir. Bu SQL şablonunda $1, uygulama tarafından bağlanan, kayıtlardaki embedding ile aynı boyuttaki sorgu vektörüdür; parametresiz şekilde doğrudan çalıştırılmaz. Küçük mesafe anlamsal yakınlıktır, belgenin doğruluğunun kanıtı değildir.

RAG Sistemlerinde Performans Nasıl Ölçülür?

Bir RAG sistemi kurduktan sonra “çalışıyor mu” sorusunu sübjektif izlenimlere bırakmamak gerekir. Sistemin kalitesini ölçmek için genellikle iki ayrı katman değerlendirilir: getirim (retrieval) kalitesi ve üretim (generation) kalitesi.

Getirim Kalitesi Metrikleri

Getirim tarafında en çok kullanılan ölçütler precision@k (getirilen ilk k belgenin ne kadarının gerçekten alakalı olduğu) ve recall@k (gerçekten alakalı belgelerin ne kadarının ilk k sonuç arasında yer aldığı). Bu metrikleri hesaplayabilmek için önceden hazırlanmış bir “soru-doğru belge” test kümesine ihtiyaç var; bu küme genellikle proje ekibi tarafından elle veya yarı otomatik olarak oluşturuluyor.

Üretim Kalitesi Metrikleri

Üretim tarafında ise yanıtın bağlama sadakati (faithfulness) ve soruyla alaka düzeyi (answer relevancy) değerlendiriliyor. RAGAS gibi açık kaynak değerlendirme çerçeveleri, bu metrikleri otomatik olarak hesaplamak için bir başka dil modelini “hakem” olarak kullanıyor. Küçük ölçekli projelerde bu otomasyona hemen yatırım yapmak şart değil; haftalık olarak 20-30 örnek sorguyu elle gözden geçirmek bile erken aşamada büyük sorunları yakalamak için yeterli olabiliyor.

Gerçek Dünyadan RAG Kullanım Örnekleri

RAG mimarisi farklı sektörlerde farklı problemleri çözmek için kullanılıyor. Aşağıda sık karşılaşılan kullanım senaryoları özetleniyor.

• Kurumsal destek botları: Ürün dokümantasyonu, SSS ve geçmiş destek talepleri üzerinde arama yaparak müşteri temsilcilerine veya son kullanıcılara anlık, kaynağa dayalı yanıtlar sunar.
• Hukuki ve mevzuat araştırması: Değişen kanun ve yönetmelik metinleri üzerinde arama yaparak avukatların ilgili maddeleri hızla bulmasına yardımcı olur; nihai kararın hâlâ bir uzman tarafından doğrulanması gerekir.
• Yazılım dokümantasyon asistanları: API referansları ve teknik dokümantasyon üzerinde arama yaparak geliştiricilere kod örnekleriyle birlikte yanıt sunar.
• E-ticaret ürün asistanları: Ürün kataloğu ve kullanıcı yorumları üzerinde arama yaparak “bu özelliklere sahip bir ürün var mı” tarzı sorulara yanıt üretir.
• İç bilgi yönetimi (kurumsal hafıza): Şirket içi wiki, toplantı notları ve proje dokümanları üzerinde arama yaparak yeni çalışanların bilgiye erişimini hızlandırır.

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

RAG sistemleri kurarken tekrar eden birkaç hata kalıbı var:

1. Chunk boyutunun yanlış seçilmesi: Çok küçük parçalar bağlamı koparır, çok büyük parçalar ise arama hassasiyetini düşürür. Çözüm: 300-800 token aralığında başlayıp gerçek sorgu sonuçlarına göre ayarlamak.
2. Kaynak güncellemelerinin yeniden indekslenmemesi: Belgeler güncellendiğinde eski embedding’ler veritabanında kalırsa model eski bilgiye dayanır. Çözüm: içerik güncellemelerini otomatik yeniden indeksleme sürecine bağlamak (n8n gibi bir otomasyon aracıyla tetiklenebilir).
3. Getirilen belge sayısının çok az veya çok fazla olması: Çok az belge yetersiz bağlam, çok fazla belge ise gereksiz token maliyeti ve “gürültü” yaratır. Çözüm: 3-5 parça ile başlayıp yanıt kalitesini test ederek ayarlamak.
4. Embedding modeli ile arama modelinin uyumsuz olması: Sorgu ve belgeler farklı embedding modelleriyle oluşturulursa benzerlik skorları anlamsız hale gelir. Çözüm: tüm pipeline boyunca aynı embedding modelini kullanmak.
5. Güvenlik ve erişim kontrolünün göz ardı edilmesi: Farklı yetki seviyelerindeki kullanıcıların aynı vektör indeksinden hassas belgelere erişebilmesi ciddi bir veri sızıntısı riski oluşturur. Çözüm: vektör veritabanında da rol tabanlı filtreleme uygulamak.

RAG Ne Zaman Tercih Edilmeli, Ne Zaman Edilmemeli?

RAG; sık güncellenen bilgi tabanlarına dayalı destek botları, kurum içi arama asistanları, dokümantasyon chatbot’ları ve hukuki/teknik referans sorgulama sistemleri için genellikle uygun bir seçim. Buna karşılık, modelin sadece belirli bir yazım tonunu veya çıktı formatını öğrenmesi gerekiyorsa (örneğin markaya özgü bir üslup), bu ihtiyaç RAG yerine fine-tuning ile daha verimli çözülebilir. Çok küçük ve nadiren değişen bir bilgi kümesi söz konusuysa (örneğin birkaç sayfalık statik bir SSS), bazen basit bir uzun context window yaklaşımı, ayrı bir vektör veritabanı kurmaktan daha az karmaşık olabilir.

Özetle: veri hacmi büyüyorsa, veri sık değişiyorsa ve kaynak gösterme ihtiyacı varsa RAG öne çıkan seçenek oluyor; veri küçük ve sabitse basit yaklaşımlar yeterli olabiliyor.

Ekip büyüklüğü ve teknik olgunluk da karar sürecinde göz önünde bulundurulmalı. Tek kişilik bir geliştirici ekibi veya küçük bir işletme için hazır bir yönetilen vektör veritabanı (Pinecone veya Weaviate Cloud gibi) ile hızlı bir başlangıç yapmak, altyapı bakımıyla uğraşmadan projeyi hayata geçirmenin en pratik yolu olabilir. Buna karşılık kendi altyapısını yönetme deneyimi olan ve maliyet kontrolünü öncelik haline getiren orta-büyük ölçekli ekipler için pgvector veya kendi sunucusunda barındırılan Qdrant, uzun vadede daha esnek ve öngörülebilir bir maliyet yapısı sunabilir.

Sonuç

RAG nedir sorusuna kısaca yanıt vermek gerekirse: bir dil modelinin dış kaynaklardan gerçek zamanlı bilgi çekerek daha doğru ve güncel yanıtlar üretmesini sağlayan bir mimari. Doğru embedding modeli ve vektör veritabanı seçimi, iyi tasarlanmış bir chunk stratejisi ve düzenli yeniden indeksleme süreciyle RAG, kurumsal yapay zeka uygulamalarında halüsinasyon riskini azaltan pratik ve nispeten düşük maliyetli bir çözüm sunuyor.

Sık Sorulan Sorular

RAG nedir, kısaca nasıl tanımlanır?

RAG, harici kaynaktan ilgili bilgileri getirip modelin yanıt bağlamına ekleyen bir yaklaşımdır. Vektör veritabanı uygulama seçeneklerinden biridir.

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

Hayır. pgvector gibi ücretsiz açık kaynak eklentiler veya Qdrant’ın küçük ölçekli ücretsiz katmanı, küçük ve orta ölçekli projeler için yeterli olabilir.

RAG ile fine-tuning aynı anda kullanılabilir mi?

Evet, birçok üretim sistemi temel davranış için hafif bir fine-tuning, güncel bilgi için ise RAG’i birlikte kullanır.

Chunk boyutu ne kadar olmalı?

Genel bir başlangıç noktası 300-800 token aralığıdır; kesin değer, belge türüne ve sorgu tarzına göre test edilerek belirlenmelidir.

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

Hayır, RAG halüsinasyon riskini azaltır ancak modelin getirilen bağlamı yanlış yorumlaması hâlâ mümkündür; bu yüzden kaynak gösterimi ve doğrulama adımları önemlidir.

Kaynaklar

• RAG araştırma makalesi
• OpenAI embedding rehberi
• pgvector belgeleri