RAG Nedir? Retrieval-Augmented Generation ve Vektör Veritabanı Mimarisi

RAG (Retrieval-Augmented Generation), bir dil modelinin cevabı üretmeden önce kurumun kendi belgelerinden ilgili bilgiyi arayıp bulduğu ve bu bilgiyi bağlam olarak kullandığı yapay zeka mimarisidir. Model yalnızca eğitimde öğrendiklerine güvenmez; her soruda kaynağa gider, ilgili parçaları çeker ve cevabı bu parçaların üzerine kurar. Terim, Lewis ve arkadaşlarının 2020'de yayımlanan Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks makalesinden gelir; makale, önceden eğitilmiş bir üretici modeli, bir arama bileşeniyle erişilen dış bir metin dizinine bağlayan yaklaşımı tarif eder.

Pratikte bu şu demek: modelin eğitim verisinde hiç bulunmayan sözleşmeleriniz, ürün kataloğunuz, iç prosedürleriniz ve destek kayıtlarınız da cevaplanabilir hâle gelir; üstelik modeli yeniden eğitmeden.

RAG hangi sorunu çözüyor?

Büyük dil modelleri halka açık metinlerle eğitilir ve eğitim tamamlandığı anda modelin bilgisi sabitlenir. Kurumsal kullanımda bu, iki somut boşluk bırakır.

Modelin bilmediği kurum verisi. Bir dil modeli sizin fiyat listenizi, iade politikanızı, teknik şartnamenizi veya geçen hafta güncellenen prosedürünüzü bilmez. Bu bilgiler hiçbir zaman eğitim setine girmemiştir, girmemelidir de. "Bizim iade süremiz kaç gün?" diye sorduğunuzda elinde gerçek kaynak yoksa genel bir tahmin üretir.

Halüsinasyon. Dil modelleri metni, bir sonraki parçanın olasılığını hesaplayarak üretir. Bilmediği bir konuda susmak yerine, dilbilgisel olarak kusursuz ama içerik olarak uydurma bir cevap üretebilir. Destek hattında bunun bedeli müşteriye verilmiş yanlış bir taahhüttür.

RAG ikisini birden ele alır: soru geldiğinde önce arama yapılır, sonra üretim. Doğru kurgulanmış bir sistemde model, kaynakta karşılığı olmayan sorulara "bu bilgi belgelerimde yok" diyecek şekilde yönlendirilir. Kulağa mütevazı bir özellik gibi geliyor; ama kullanıcının sisteme güvenmesi büyük ölçüde buna bağlıdır.

RAG nasıl çalışır?

RAG'in işleyişi iki aşamaya ayrılır: belgelerin önceden hazırlandığı indeksleme ve kullanıcı sorusuyla tetiklenen sorgulama.

• İndeksleme: Belgeler parçalanır, vektöre çevrilir ve saklanır.
• Sorgulama: Soru vektöre çevrilir, ilgili parçalar bulunur ve cevap bu parçalarla üretilir.

Bu iki aşama dört adıma ayrılır. Emeğin büyük kısmı genellikle ilk adıma, belgelerin hazırlanıp parçalanmasına gider.

1. Parçalama (chunking)

Belgeler olduğu gibi modele verilemez; hem bağlam penceresi sınırlıdır hem de uzun metnin içinde ilgili cümle kaybolur. Bu yüzden dokümanlar anlamlı parçalara bölünür.

Parça boyutu için evrensel bir doğru yoktur. Parçayı fazla kısa tutarsanız cümlenin bağlamı kopar; fazla uzun tutarsanız arama, parçanın içindeki asıl cümleyi seyreltir. Yaygın yaklaşım, birkaç yüz token'lık parçalarla ve ardışık parçalar arasında küçük bir örtüşmeyle başlamak, sonra boyutu kendi sorularınızla ölçerek ayarlamaktır. Destek kayıtları gibi zaten kısa ve kendi içinde bütün metinlerde bölmeye gerek kalmaz; her kayıt tek parçadır.

İyi parçalama cümle ve başlık sınırlarını gözetir, her parçaya dosya adı, başlık, tarih ve bölüm numarası gibi kaynak bilgisini iliştirir. Tablolar, iç içe geçmiş maddeler ve taranmış PDF'ten dönüştürülen sayfalar burada başa bela olur. Sistemin en kırılgan noktası çoğu zaman burasıdır: tabloyu düzgün taşıyamayan bir dönüştürücü, uzun süre fark edilmeyen yanlış cevaplara yol açabilir. Çünkü cevap yanlış görünmez, sadece yanlıştır.

2. Gömme (embedding)

Her parça, bir gömme modeli aracılığıyla sayı dizisine, yani vektöre dönüştürülür. Bu vektör metnin anlamsal konumunu temsil eder; anlamca yakın iki metin vektör uzayında da birbirine yakın konumlanır. "Fatura iptali nasıl yapılır" ile "faturayı geri almak istiyorum" ifadeleri tek bir ortak kelime içermese bile birbirine yakın vektörlere sahiptir. Klasik anahtar kelime aramasının çözemediği sorun tam olarak budur.

Vektörün boyut sayısı model tercihine bağlıdır. OpenAI'ın gömme dokümantasyonuna göre text-embedding-3-small varsayılan olarak 1.536, text-embedding-3-large 3.072 boyut üretir; Google'ın metin gömme belgesine göre ise gemini-embedding-001 modeli varsayılan olarak 3.072, text-embedding-005 ve text-multilingual-embedding-002 modelleri 768 boyutlu vektör üretir. İki sağlayıcı da bu varsayılan boyutu bir parametreyle küçültmeye izin verir. Maliyet tarafında gömme, üretim çağrılarının yanında genellikle ucuz kalır. Asıl maliyet tekrar sayısından gelir: gömme modelini değiştirdiğiniz gün arşivin tamamını baştan gömmeniz gerekir, çünkü farklı modellerin ürettiği vektörler aynı uzayda değildir.

3. Vektör arama ve geri getirme

Geri getirme adımında kullanıcı sorusu, parçalarla aynı gömme modelinden geçirilerek vektöre çevrilir ve veri tabanındaki en yakın parçalar bulunur. Bağlama kaç parça konacağı sabit bir sayı değildir, ölçülerek belirlenir. Anthropic'in bağlamsal geri getirme üzerine yayımladığı çalışmada modele ilk 20 parçayı vermek, yalnızca ilk 5 ya da 10 parçayı vermekten daha iyi sonuç verdi. Öte yandan her ek parça maliyeti artırır ve alakasız metin modeli yanlış yöne çekebilir.

Olgun sistemlerde bu adım tek başına bırakılmaz. Anahtar kelime aramasıyla birleştirilen hibrit arama, departman, tarih aralığı ve dil gibi metadata filtreleri ve sonuçları yeniden puanlayan yeniden sıralama (reranking) modelleri devreye girer. Yaygın kurgu şöyledir: önce geniş bir aday kümesi çekilir, yeniden sıralama modeli bunları puanlar, en iyileri modele gider. Aynı çalışmada ilk aşamada 150 aday çekilmiş, yeniden sıralamayla bunların 20'si seçilmiştir; hibrit aramanın ve yeniden sıralamanın, tek başına vektör aramasından daha iyi sonuç verdiği de raporlanmıştır.

4. Bağlamla üretim

Üretim adımında, aramanın seçtiği parçalar kullanıcı sorusuyla birlikte dil modeline verilir. İstem (prompt) modele açık talimatlar verir: yalnızca verilen bağlamı kullan, bağlamda yoksa uydurma, kaynağı belirt.

Model cevabı üretir; iyi arayüzlerde her iddianın yanında hangi belgeden geldiği gösterilir. Kaynak gösterimi kozmetik sanılır, oysa kullanıcı cevabı kendi gözüyle doğrulayabildiği anda sistemi gerçekten kullanmaya başlar.

Vektör veritabanı nedir?

Vektör veritabanı, metinlerin gömme vektörlerini saklayan ve "bu vektöre en yakın olanları getir" sorgusunu hızlıca yanıtlayan bir depolama sistemidir. Klasik veritabanları tam eşleşme ve aralık sorgusuna göre tasarlanmıştır; burada aranan şey benzerliktir.

Milyonlarca vektörü her sorguda tek tek karşılaştırmak pratik olmadığından bu sistemler yaklaşık en yakın komşu (ANN) algoritmaları kullanır; HNSW ve IVF gibi indeks yapıları, doğruluktan bir miktar ödün vererek aramayı belirgin biçimde hızlandırır. Vektör veritabanları genellikle metadata da saklar ve arama sırasında bununla filtrelemeye izin verir; kurumsal senaryolarda yetki bazlı filtreleme için bu zorunlu bir özelliktir.

Büyüklük hissi vermek için doğrudan aritmetik: 1.536 boyutlu bir vektör, 4 baytlık kayan noktalı sayılarla 6.144 bayt, yani kabaca 6 KB yer kaplar; 100 bin parçalık bir arşiv yalnızca vektörler için 600 MB civarı yer demektir (indeks, metin ve metadata hariç). Pratikte üç yol var: özel amaçlı vektör veritabanları, mevcut veritabanınıza eklenen vektör uzantıları ve arama motorlarının vektör destekli sürümleri. Zaten PostgreSQL kullanan ve orta ölçekli bir bilgi tabanı olan kurumlarda en sade yol çoğu zaman ikincisidir: PostgreSQL için pgvector uzantısı hem HNSW hem IVFFlat indeksini mevcut veritabanınızın içine taşır, yani ayrı bir sistem işletmeden vektör aramasına geçersiniz.

RAG projelerinde zaman nereye gider?

RAG projelerinde kalite sorunu çoğu zaman model seçiminden değil, parçalama stratejisinden ve doküman kalitesinden kaynaklanır.

Ekipler hangi modelin daha iyi olduğunu tartışırken indeksin içinde aynı prosedürün birkaç farklı sürümü durabilir. Model değiştirmek bu sorunu çözmez; çelişen iki dokümandan birini arşivden çıkarmak ise o soruyu tek hamlede doğru cevaplanır hâle getirir.

Bir RAG projesinin takviminde en uzun kalem genellikle aynıdır: belgeleri toparlamak, sürüm karmaşasını çözmek, taranmış PDF'leri okunur hâle getirmek, hangi belgeye kimin erişebileceğini netleştirmek. Vektör veritabanını kurmak işin kısa kısmıdır; onu doğru veriyle doldurmak çok daha uzun sürer. Bu yüzden RAG'e başlamadan önce içerik yönetişimini konuşun.

RAG'in sınırları

RAG, bir arama probleminin üzerine kurulmuş bir üretim katmanıdır. Aramanın kalitesi düşükse cevabın kalitesi de düşer. En sık karşılaşılan beş sınır şunlar.

Kötü parçalama. Bir tablo ortasından bölünmüşse, bir maddenin koşulu bir parçada ve istisnası başka parçada kalmışsa, model eksik bilgiyle cevap üretir. Hata modelin uydurmasından değil eksik bağlamdan doğar; ama kullanıcı açısından sonuç aynıdır: yanlış cevap.

Bayat veri. Politika değişti, indeks güncellenmedi. RAG'in en sinsi hatası budur, çünkü sistem eski doğruyu tam bir güvenle söyler. İndeksleme kurulup unutulan bir iş değildir: değişiklik yakalama, yeniden gömme ve eski parçaların silinmesi düzenli işletilmelidir.

Yanlış geri getirme. Soru belirsizse veya belgelerde benzer konulu birden çok bölüm varsa, arama alakasız parçalar getirir. Model de önüne konan alakasız metne sadık kalarak yanlış cevap üretir. Hibrit arama, yeniden sıralama ve soruyu netleştirme adımları bu riski azaltır.

Çelişen kaynaklar. Arşivde aynı konuda birbiriyle çelişen iki doküman varsa RAG bu çelişkiyi çözmez; hangisini getirdiyse ona göre cevap verir.

Yetki sızıntısı. Herkesin erişmemesi gereken belgeler indekse girdiyse, doğru soruyu soran herkes o bilgiye ulaşır. Yetki kontrolünün yeri arama katmanıdır. Modelden "bunu kimseye söyleme" diye rica etmek güvenlik önlemi sayılmaz.

Bu sınırların hiçbiri RAG'i geçersiz kılmaz; hepsi mühendislik kararıdır. Ancak "belgeleri yükledik, hazır" beklentisiyle başlayan projeler tam da burada takılır. Ölçüm ve iyileştirme döngüsünün neden şart olduğunu süreç otomasyonuna nereden başlanır yazımızda ayrıntılı ele aldık.

RAG ile ince ayar (fine-⁠tuning) arasındaki fark

RAG bilgiyi cevap anında dışarıdan getirir; ince ayar (fine-tuning) ise bilgiyi ve davranışı eğitimle modelin ağırlıklarına işler. Sorun kurum bilgisine erişimse ihtiyaç duyulan çoğu zaman ilkidir. Bilgi sık değişiyorsa, kaynağı göstermeniz gerekiyorsa veya veri hassassa ince ayar bu karşılaştırmayı kaybeder.

İnce ayarın güçlü olduğu bir alan var: modelin cevap biçimi ve üslubu. Sabit bir çıktı formatı, alana özgü terminoloji, tutarlı bir ton, dar bir sınıflandırma görevi. Bunları uzun istemlerle kovalamak yorucudur; modele öğretmek daha kalıcı sonuç verir.

Pratik kural: önce RAG kurun, ölçün. Sorun bilgiye erişimde değil de cevabın biçiminde çıkıyorsa ince ayarı o zaman gündeme alın. İkisi birlikte de çalışır; ince ayarlı bir model, RAG ile beslenebilir.

RAG'i ajan mimarisine bağlamak

RAG tek başına bir soru-cevap katmanıdır. Asıl değeri, bir iş akışının parçası hâline geldiğinde ortaya çıkar: bilgiyi bulan, karar veren ve bir işlem başlatan sistemler. Yapay zeka ajanları, RAG'i araçlarından biri olarak kullanır; belgeden bilgiyi çeker, kural motoruyla doğrular, gerektiğinde bir kayıt açar veya konuyu bir insana devreder. RAG tabanlı yapay zeka aramasıyla da çalışabilen N2B ve FSNest'i ürünler sayfamızda inceleyebilirsiniz.

Sık Sorulan Sorular

RAG için kendi dil modelimi eğitmem gerekir mi?

Hayır. RAG'in temel avantajı, hazır bir dil modelini kendi verinizle çalışır hâle getirmesidir. Model eğitimi gerekmez; ihtiyaç duyulan üç bileşen şudur: düzenli belgeler, bir gömme modeli ve vektör araması yapabilen bir depo.

RAG halüsinasyonu tamamen bitirir mi?

Bitirmez, azaltır. Model doğru bağlamı aldığında uydurma ihtimali düşer; yanlış parça getirilirse veya bağlam eksikse hatalı cevap yine çıkar. Bu riski yönetmenin üç yolu kaynak gösterimi, "bilgi bulunamadı" davranışı ve gerçek sorularla düzenli değerlendirmedir.

Ne kadar belgeyle başlanabilir, az belgeyle RAG kurmak mantıklı mı?

Elinizdeki metnin tamamı modelin bağlam penceresine rahatça sığıyorsa RAG gereksiz karmaşıklık getirebilir; belgeyi doğrudan isteme koymak daha basit bir yoldur. Anthropic, bağlamsal geri getirme yazısında 200 bin token'ın (yaklaşık 500 sayfa) altındaki bilgi tabanları için bu yolun yeterli olabileceğini belirtir; bu sınır kullandığınız modelin bağlam penceresine göre değişir. RAG; bundan büyük, sık güncellenen ve yetkiye göre ayrışan arşivlerde anlam kazanır. Kalite de sayıdan önemlidir: güncel, çelişkisiz ve iyi başlıklandırılmış az sayıda doküman, çoğu zaman dağınık binlerce dosyadan daha iyi sonuç verir.

Verilerim dışarı çıkar mı?

Bu, mimari tercihine bağlıdır. Belgeler ve vektörleri kendi altyapınızdaki veritabanında durabilir. Ancak bulut tabanlı bir gömme modeli kullanıyorsanız indeksleme sırasında belgelerin metni o servise gönderilir; sorgu anında da soru ve seçilen parçalar dil modeline gider. Verinin hiç dışarı çıkmaması isteniyorsa gömme ve dil modeli olarak kendi ortamınızda çalışan açık kaynak modeller kullanılabilir.

RAG ile arama motoru arasındaki fark nedir?

Arama motoru size belge listesi verir, okumayı size bırakır. RAG ilgili parçaları bulup cevabı doğal dilde birleştirir ve kaynağı gösterir. Altında yine bir arama vardır; fark, sonucun sunulma biçiminde ve birden çok parçayı tek cevapta toplayabilmesindedir.

Son güncelleme: 15 Ekim 2026