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 ezberine güvenmez; her soruda güncel kaynağa gider, ilgili parçaları çeker ve cevabı bu parçaların üzerine kurar. Terimi 2020'de Lewis ve arkadaşlarının Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks başlıklı makalesi tanımladı; makale, dış bir kaynaktan getirilen metnin üretim adımına bağlanmasını 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. 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 bir sonraki kelimeyi olasılık hesabıyla seçer. Bilmediği bir konuda susmak yerine, dilbilgisel olarak kusursuz ama içerik olarak uydurma bir cevap üretir. 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" der. Kulağa mütevazı bir özellik gibi geliyor; kurumsal yapay zeka projelerinde güvenin neredeyse tamamı buna dayanıyor.

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.

Toplam 4 adım var ve bunlardan biri diğer 3'ünün toplamından fazla emek ister.

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.

Rakam vermek gerekirse, kurumsal metinlerde 300-600 token aralığındaki parçalar ve aralarında bırakılan 50-100 token'lık örtüşme işi görüyor. 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. Destek kayıtları gibi zaten kısa ve kendi içinde bütün metinlerde bölmeye hiç 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 4 kalem kaynak bilgisini (dosya adı, başlık, tarih, bölüm numarası) iliştirir. Tablolar, iç içe geçmiş maddeler ve taranmış PDF'ten dönüştürülen sayfalar burada başa bela olur. Kurduğumuz sistemlerde en çok kırılan yer tam olarak burası: tabloyu düzgün taşıyamayan bir dönüştürücü, aylarca fark edilmeyen yanlış cevaplar üretir. Çü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 1.536, text-embedding-3-large 3.072 boyut üretir; Google'ın Vertex AI gömme modelleri 768 boyutlu çıktıyı standart seçenek olarak sunar. Maliyet tarafında gömme, üretim çağrılarının yanında ucuz kalır. Fatura birim fiyattan değil tekrar sayısından şişer: gömme modelini değiştirdiğiniz gün arşivin tamamını baştan gömmeniz gerekir, çünkü eski vektörlerle yenileri 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. Tipik olarak 3-8 parça bağlama konur. Daha fazlasını yığmak cevabı iyileştirmiyor, modelin dikkatini dağıtıyor.

Olgun sistemlerde bu adım tek başına bırakılmaz. Anahtar kelime aramasıyla birleştirilen hibrit arama, 3 tür metadata filtresi (departman, tarih aralığı, dil) ve sonuçları tekrar sıralayan yeniden sıralama (reranking) modelleri devreye girer. Yaygın kurgu şöyledir: vektör aramasıyla 20-30 aday çekilir, yeniden sıralama modeli bunları puanlar, en iyi 5 tanesi modele gider.

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 3 açık talimat içerir: 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ının neredeyse tamamı ayrıca metadata saklar ve arama sırasında bununla filtrelemeye izin verir; kurumsal senaryolarda yetki bazlı filtreleme için zorunlu bir özellik.

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 600 MB civarı vektör demektir. Pratikte 3 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. Orta ölçekli kurumsal bilgi tabanlarında en sade yol 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.

Başarısız RAG projelerinin ortak noktası

Açık konuşalım: gördüğümüz başarısız RAG projelerinin neredeyse tamamında sorun model seçiminde değildi. Sorun parçalama stratejisinde ve doküman kalitesindeydi.

Ekipler haftalarca hangi modelin daha iyi olduğunu tartışıyor, bu arada indeksin içinde aynı prosedürün 3 farklı sürümü duruyor. Model değiştirmenin kazancı birkaç puanla ölçülür. Ç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 hep aynı: 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ı ayağa kaldırmak 1 günlük iştir. Onu doğru veriyle doldurmak haftalar alır. 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. Sahada en sık gördüğümüz 5 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. Teknik tanıma göre buna halüsinasyon denmiyor. Bunu, cevabı yanlış çıkan kullanıcıya anlatmayı deneyin.

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 gömer. Kurumsal projelerde ihtiyaç duyulan şey 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 açık ara kazandığı 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 çok 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 beslenir.

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. Kurumunuzda hangi verinin bu mimariye uygun olduğunu konuşmak için hizmetlerimiz sayfasındaki çözüm başlıklarını 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 3 bileşen şudur: düzenli belgeler, bir gömme modeli ve vektör araması yapabilen bir depo.

RAG halüsinasyonu tamamen bitirir mi?

Bitirmez, belirgin biçimde 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. Kaynak gösterimi, "bilgi bulunamadı" davranışı ve düzenli değerlendirme bu riski yönetmenin 3 yoludur.

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

Elinizdeki metnin tamamı modelin bağlam penceresine rahatça sığıyorsa — kabaca 30-50 sayfalık tek bir el kitabı gibi — RAG gereksiz karmaşıklık getirir; belgeyi doğrudan isteme koymak daha ucuz ve daha doğrudur. RAG, birkaç yüz sayfayı aşan, sık güncellenen ve yetkiye göre ayrışan arşivlerde anlam kazanır. Kalite sayıdan önemlidir: güncel, çelişkisiz ve iyi başlıklandırılmış birkaç düzine doküman, dağınık binlerce dosyadan iyi sonuç verir.

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

Bu, mimari tercihine bağlıdır. Belgeler kendi altyapınızdaki vektör veritabanında durur; yalnızca soruya karşılık seçilen 3-8 parça dil modeline gönderilir. Tamamen kapalı bir kurulum isteniyorsa, kendi ortamınızda çalışan açık kaynak modellerle de RAG kurulur.

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.