RAG Mimarisi Nasıl Çalışır? Modelin Kütüphaneye Gitmesi
RAG neden gerekli? Embedding-vektör veritabanı-retrieval-üretim zinciri nasıl işler, ne zaman RAG ne zaman fine-tuning tercih edilmeli anlatıyoruz.
RAGvektör veritabanıembeddingAI mimarisi
Model her şeyi biliyor gibi davranır — ama bilmiyor
Büyük dil modelleri hakkında en çok yanlış anlaşılan şeylerden biri şu: model, sorduğunuz her şeyi “biliyormuş” gibi cevap verir. Şirketinizin iade politikasını da sorsanız, dün açıklanan bir haberi de sorsanız, aynı özgüvenli tonla bir cevap üretir. Sorun şu ki bu ikisinden biri gerçek bilgiye dayanır, diğeri büyük ihtimalle “olası görünen” bir tahmindir.
Bunun iki nedeni var. Birincisi, modelin bilgisi eğitim verisinin toplandığı tarihte donar; o tarihten sonrasını, ve elbette şirketinize özel hiçbir dokümanı, hiç görmemiştir. İkincisi, model bir bilgi deposu değil bir tahmin makinesidir — bilmediği bir konuda bile en olası görünen cümleyi üretmeye devam eder. Buna halüsinasyon denir ve neden kaçınılmaz olduğunu ayrı bir yazıda ayrıntılı anlattım.
RAG — Retrieval-Augmented Generation, “getirmeyle güçlendirilmiş üretim” — tam olarak bu iki açığı kapatmak için tasarlandı. Fikri 2020’de Facebook AI Research’ten (bugünkü Meta AI) Patrick Lewis ve ekibinin yayımladığı bir makale ortaya attı: modeli sadece ezberiyle baş başa bırakmak yerine, cevap üretmeden önce ona ilgili belgeleri “okutmak”. Sözlükte RAG maddesine kısa tanımı bulabilirsiniz; bu yazıda mekanizmanın iç işleyişine ineceğiz.
Zincirin dört halkası
RAG tek bir işlem değil, art arda gelen dört adımın zinciridir.
1. Bölme (chunking). Önce kaynak belgeler — PDF’ler, wiki sayfaları, destek dokümanları, ürün katalogları — anlamlı parçalara bölünür. Bu parça boyutu önemlidir: çok küçük parçalar bağlamı koparır, çok büyük parçalar alakasız bilgiyi de sürükler.
2. Embedding’e çevirme. Her parça, embedding adı verilen bir sayı dizisine dönüştürülür. Embedding, bir metnin anlamını çok boyutlu bir uzayda bir noktaya sıkıştırır; anlamca yakın metinler bu uzayda birbirine yakın noktalara düşer. “Kargo ne zaman gelir” ile “teslimat süresi nedir” cümleleri farklı kelimeler kullanır ama embedding uzayında komşudur — çünkü anlamları yakındır.
3. Saklama ve arama (vektör veritabanı). Bu embedding’ler bir vektör veritabanında saklanır — Pinecone, Weaviate, pgvector gibi sistemler bu iş için özel olarak tasarlanmıştır. Kullanıcı bir soru sorduğunda, sorunun kendisi de aynı yöntemle embedding’e çevrilir ve veritabanında ona en yakın parçalar aranır (retrieval). Bu arama, anahtar kelime eşleştirmesi değildir; anlamsal yakınlık ölçer, bu yüzden kullanıcı farklı kelimelerle sorsa da doğru parçayı bulabilir.
4. Üretim (generation). Bulunan parçalar, kullanıcının sorusuyla birlikte modelin bağlam penceresine — yani modelin o an “önünde tuttuğu” metne — yerleştirilir. Model artık ezberinden değil, önüne konan bu somut metinden cevap üretir. Lewis ve ekibinin orijinal makalesi, bu yaklaşımın açık uçlu soru-cevap görevlerinde modelin daha spesifik, daha çeşitli ve daha isabetli cevaplar ürettiğini; sadece parametrik ezbere dayanan modellere göre üstün performans gösterdiğini deneysel olarak ortaya koydu.
Sonuç: model hâlâ aynı tahmin makinesi — ama artık boş kağıda değil, önüne konan gerçek belgeye bakarak tahmin ediyor.
Neden bu kadar hızlı yaygınlaştı?
RAG’ın patlamasının pratik bir nedeni var: güncelleme maliyeti. Şirket politikası değiştiğinde, yeni bir ürün eklendiğinde ya da bir mevzuat güncellendiğinde, RAG sisteminde tek yapmanız gereken ilgili belgeyi vektör veritabanına eklemek ya da güncellemektir — birkaç saniyelik bir işlem. Modelin kendisine hiç dokunulmaz.
İkinci neden: doğrulanabilirlik. RAG sistemleri genellikle cevapla birlikte “hangi belgeden geldiğini” de gösterebilir. Bu, kullanıcının iddiayı kaynağına kadar takip edebilmesi anlamına gelir — düz bir sohbet botunda bu imkan yoktur.
2023 sonunda Yunfan Gao ve ekibinin yayımladığı geniş kapsamlı bir tarama makalesi, RAG’ın artık tek bir teknik değil, kendi başına bir mimari akım haline geldiğini gösteriyor: sorguyu yeniden yazan, birden fazla arama turunu birleştiren, getirilen belgeleri yeniden sıralayan (re-ranking) gelişmiş varyantlar birbiri ardına ortaya çıktı. Ortak nokta değişmedi: model önce ara, sonra üret.
Ne zaman RAG, ne zaman fine-tuning?
Burada sık karıştırılan iki yöntemi ayırmak gerekiyor. Fine-tuning, modelin kendi ağırlıklarını — iç parametrelerini — belirli bir veri kümesiyle yeniden eğitip güncellemektir. RAG ise model hiç değişmeden, sadece ona doğru bağlamı sunmaktır. İkisi rakip değil, farklı problemlere cevap verir.
RAG’ı tercih edin eğer amacınız modele bilgi kazandırmaksa: güncel, sık değişen, doğrulanabilir olması gereken bilgi. Şirket dokümanları, ürün katalogları, güncel haberler, mevzuat — bunların hepsi RAG’ın doğal alanıdır.
Fine-tuning’i tercih edin eğer amacınız modele davranış veya biçim kazandırmaksa: belirli bir üslupla yazmasını, belirli bir formatta cevap vermesini, sektöre özgü bir jargonu doğal şekilde kullanmasını istiyorsanız. Fine-tuning “nasıl konuşacağını” öğretmekte güçlüdür; “ne bildiğini” güncellemekte zayıftır.
Bu son iddia havada değil: Oded Ovadia ve ekibinin 2023’te yayımladığı bir karşılaştırma çalışması, fine-tuning ile modele yeni bilgi enjekte etmeye çalışmanın hem eğitim sırasında görülen hem de tamamen yeni bilgilerde RAG’a kıyasla tutarlı biçimde daha zayıf kaldığını gösterdi. Modeller, denetimsiz fine-tuning yoluyla yeni olguları öğrenmekte zorlanıyor; RAG ise aynı bilgiyi doğrudan bağlama koyduğu için bu sorunu baştan bertaraf ediyor.
Pratikte pek çok ciddi sistem ikisini birlikte kullanır: model belirli bir üslup ve göreve fine-tuning ile alıştırılır, güncel ve doğrulanabilir bilgi ise RAG ile sağlanır. Bu ikisinin nasıl daha geniş bir sistemin parçaları olduğunu modern AI mimarisi yazısında bütün resimle birlikte ele alıyorum.
Sınırları da var
RAG sihirli değnek değildir. Getirilen parçalar bağlam penceresine sığmak zorundadır — çok fazla belge getirirseniz, ya alakasız gürültü karışır ya da pencere taşar. Arama adımı kötü çalışırsa — yanlış parçalar bulunursa — model de o yanlış parçalardan yanlış bir cevap üretir; RAG, kötü aramayı iyi üretime çeviremez. Ayrıca RAG halüsinasyonu azaltır ama sıfıra indirmez: model, getirilen belgeyi yanlış yorumlayarak ya da belgede olmayan bir ayrıntıyı “tamamlayarak” yine hata yapabilir.
Bu yüzden ciddi bir RAG sistemi kurmak, sadece bir vektör veritabanı bağlamaktan ibaret değildir; bölme stratejisi, arama kalitesi ve getirilen belgenin modele nasıl sunulduğu — üçü de ayrı ayrı özen ister.
Aklınızda kalsın
- RAG, modelin ezberine değil, arandığında bulunan belgelere dayanarak cevap üretmesidir — embedding, vektör veritabanı, retrieval, üretim: dört adımlık bir zincir.
- RAG bilgi güncelliği ve doğrulanabilirlik için, fine-tuning ise davranış ve üslup için daha uygundur; ikisi rakip değil, tamamlayıcıdır.
- RAG, kötü aramayı iyi cevaba çeviremez — sistemin gücü, arama kalitesiyle sınırlıdır.
Kaynaklar
- Lewis, P. vd. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. RAG yaklaşımını ilk tanımlayan; parametrik ve harici bilgiyi birleştiren üretim modelini öneren makale. arxiv.org/abs/2005.11401
- Gao, Y. vd. (2023). Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv. RAG’ın gelişen varyantlarını (yeniden sıralama, çok turlu arama, sorgu yeniden yazma) derleyen kapsamlı tarama. arxiv.org/abs/2312.10997
- Ovadia, O. vd. (2023). Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs. arXiv. Fine-tuning ile RAG’ı bilgi enjeksiyonu açısından karşılaştıran; RAG’ın tutarlı biçimde üstün çıktığını gösteren deneysel çalışma. arxiv.org/abs/2312.05934
Teoriyi anladın — şimdi uygula
Bu sitedeki her şey ücretsiz. Yapay zekâyı işinde gerçekten çalıştırmak istiyorsan — reklam, içerik, otomasyon — beAgents AI tam bunun için var.
beAgents AI'ı keşfet ↗