kolay 40 puan

RAG Anatomisi: 5 Adımlı Pipeline

Embed → Store → Retrieve → Augment → Generate. Her adımın görevi, popüler vektör DB seçenekleri (Pinecone, Qdrant, Chroma, pgvector) ve güven sınırları haritası.

RAG Anatomisi: 5 Adımlı Pipeline

Günümüzde modern kurumsal LLM uygulamalarının %90'ından fazlası tek bir temel mimari üzerinde inşa ediliyor: RAG (Retrieval-Augmented Generation - Geri Getirmeyle Zenginleştirilmiş Üretim).

ChatGPT'nin sadece kendi kapalı eğitim verisiyle "kendi başına" konuştuğu klasik LLM mimarisinden farklı olarak RAG, modelin hafızasını kurumun kendi iç belgeleriyle genişletmesine olanak tanır. Bir müşteri destek botu firmanın SSS (FAQ) sayfalarını okur; bir hukuk asistanı 50.000 sayfalık sözleşme arşivini saniyeler içinde tarar; bir şirket içi asistan Confluence sayfalarından bağlam çeker.

Bu eğitim yolculuğunda RAG'ın hem iş zekası için bir mucize hem de devasa bir saldırı yüzeyi olduğunu göreceksiniz. Bu ilk oda, işin güvenlik boyutuna geçmeden önce mimari iskeleti netleştirmek için tasarlandı.


RAG'ın 5 Adımı

İNDEXLEME (Çevrimdışı / Periyodik) Belge Kaynağı Confluence · SharePoint · PDF 1) EMBED Metni vektöre 2) STORE Vektör DB VEKTÖR DB Pinecone · Qdrant · Chroma SORGU ZAMANI (Çevrimiçi / Her İstekte) Kullanıcı Sorusu "İzin politikası?" 3) RETRIEVE Top-K döndür 4) AUGMENT Prompt'a ekle 5) GENERATE LLM cevap Top-K belgeleri çek Cevap
Renk Kodu
Güvenilmez İçerik KaynaklarıBelge kaynakları (Confluence, SharePoint, PDF) + Vektör DB — her dış içerik üçüncü-parti güvenilmez veri sayılır
Sistem BileşenleriEmbed, Store, Retrieve, Augment, Generate — pipeline'ın kurum kontrolündeki katmanları
Kullanıcı / CevapSorgu zamanında giren ve dönen veri akışı
Kritik Güven Sınırı

En kritik güven sınırı: Vektör DB → LLM context'i geçişi. Bu noktada güvenilmez içerik LLM'in akıl yürütme bağlamına karışır — RAG Poisoning'in başlangıç noktasıdır.

Beş adımı teknik detaylarıyla inceleyelim:

1. EMBED (Vektöre Çevirme)

Belge kaynaklarınız (Confluence, SharePoint, PDF arşivi, Slack kanalları vb.) metin parçalarına ayrılır ve bir "embedding" modelinden geçirilir. Her bir metin parçası (chunk), matematiksel olarak yüksek boyutlu bir vektöre dönüştürülür.

Sektörde sık kullanılan embedding modelleri:

  • OpenAI text-embedding-3-small/large: Kapalı kaynak, yüksek kaliteli ancak API maliyeti yaratır.
  • BAAI/bge-large-en-v1.5: Açık kaynak, ücretsiz ve kurumsal self-host kurulumlarında çok popülerdir.
  • all-MiniLM-L6-v2: Boyutu küçük ve hızlıdır, ancak performansı eski nesil kalır.
  • Cohere embed-v3: Çok dilli (multi-lingual) yapısı güçlü, orta yol bir çözümdür.

2. STORE (Saklama)

Oluşturulan vektörler ve bu vektörlere karşılık gelen orijinal metin parçaları bir vektör veritabanında (Vector DB) saklanır.

Sektördeki başlıca seçenekler:

Vektör DBÖzellikleri
PineconeTamamen SaaS (Yönetilen Hizmet), hızlı ve kurumsal alanda çok popülerdir.
QdrantAçık Kaynak + Cloud seçeneği sunar, Rust ile yazılmıştır, performansı çok yüksektir.
WeaviateAçık Kaynak + Cloud seçeneği sunar, kullanışlı bir GraphQL arayüzü vardır.
ChromaAçık kaynaklı, hafif ve geliştirici (developer) dostudur; genelde prototiplemede kullanılır.
Milvus / ZillizAçık Kaynak + Yönetilen Hizmet, çok büyük ölçekli veriler için tasarlanmıştır.
pgvectorPostgreSQL eklentisidir. Mevcut ilişkisel veritabanı altyapısını bozmak istemeyenler için idealdir.
Elastic / OpenSearchKlasik metin araması (BM25) ile vektör aramasını birleştiren hibrit (hybrid) çözümlerdir.
Önemli Not

MongoDB Atlas Vector Search ve Redis Search gibi platformlar da vektör desteği eklemiştir; ancak bunlar çekirdekten "vektör-native" değillerdir. Klasik veritabanı mimarisinin üzerine inşa edilmiş eklenti yetenekleridir.

3. RETRIEVE (Geri Getirme / Çekme)

Kullanıcı sisteme bir soru sorduğunda olaylar zinciri şöyle başlar:

  1. Kullanıcının sorusu aynı embedding modelinden geçirilerek bir soru vektörü elde edilir.
  2. Vektör veritabanı, bu soru vektörüne matematiksel olarak en yakın K adet belgeyi (Top-K) bulup döndürür.
  3. Tipik K değeri mimariye göre 3 ile 10 arasında değişir.

4. AUGMENT (Bağlam ile Zenginleştirme)

Veritabanından çekilen (retrieve edilen) bu belgeler, LLM'in prompt'una (istem) dinamik olarak eklenir.

Tipik bir RAG prompt şablonu şu şekildedir:

Prompt Örneği
System: Sen kurumsal bir asistansın. Sadece aşağıdaki belgelerden faydalanarak
kullanıcının sorusunu cevapla. Aradığın bilgi belgelerde yoksa, kendi 
bilgini kullanma ve "bilmiyorum" de.

[BELGELER]
Belge 1: [Vektör DB'den çekilen parça 1]
Belge 2: [Vektör DB'den çekilen parça 2]
...

[SORU]
Kullanıcının sorusu: {kullanici_sorusu}

5. GENERATE (Üretim)

Son aşamada LLM, kurum içi belgelerle zenginleştirilmiş ve sınırları çizilmiş bu prompt'u işler, analiz eder ve kullanıcıya nihai cevabı üretir.


Güven Sınırları (Trust Boundaries)

Bir RAG mimarisindeki en kritik güven sınırı, Vektör Veritabanı ile LLM Context'i (Bağlamı) arasındaki geçiş noktasıdır. Bunun temel nedenleri şunlardır:

  1. Vektör DB içeriği dinamiktir: Sürekli yeni belgeler eklenir, eskileri güncellenir veya silinir.
  2. Belge kaynakları genellikle güvenilmezdir (untrusted): Confluence sayfaları ortaklaşa düzenlenir, SharePoint'e dışarıdan dosyalar yüklenebilir veya dışarıdan gelen (müşteri/üçüncü parti) PDF'ler sisteme beslenir.
  3. Retrieval süreci otomatiktir: Model, veritabanından gelen belgeyi "matematiksel olarak alakalı" bulduğu için varsayılan olarak "iyi niyetli ve güvenilir" kabul eder.

İşte tam da bu yüzden RAG Poisoning (RAG Zehirlenmesi), Dolaylı Prompt Enjeksiyonu (Indirect Prompt Injection) ailesinin en popüler ve savunulması en zor saldırı türüdür. Bu tehdidi Yapay Zeka Temelleri ve Prompt Güvenliği eğitimlerinde yüzeyel olarak işlemiştik; bu modülde (Modül 2.1 ve 2.2) işin derin teknik detaylarına iniyoruz.


Pratik Mimari Kararlar ve Güvenlik Etkileri

Sahada RAG sistemi kurarken alınan temel mimari kararların güvenlik üzerindeki doğrudan etkileri:

Alınan KararTipik SeçimGüvenlik Etkisi
Embedding ModeliOpenAI text-embedding-3-smallKurum verisi sızdırmaz ancak her sorguda veri kapalı bir API'ye (dışarıya) gider.
Embedding Modelibge-large-en-v1.5 (Kurum içi)Veri gizliliği maksimize edilir ancak modelin tedarik zinciri güvenliği kurumun omzundadır.
Vektör DBPinecone (SaaS)Operasyonel yük hafiftir ancak kurumun vektör verisi 3. parti bir platformda tutulur.
Vektör DBQdrant (Self-hosted)Tam kontrol sağlanır; veri güvenliği, ağ izolasyonu ve yama yönetimi tamamen kurumun sorumluluğundadır.
Chunk (Parça) Boyutu500-1000 TokenStandarttır; ancak chunk boyutu çok büyük tutulursa, olası bir veri zehirlenmesinde saldırganın etki alanı genişler.
Top-K Değeri3-5 Arasıİdealdir; bu değer gereğinden yüksek tutulursa LLM context'ine fazladan/alakasız (ve potansiyel olarak manipüle edilmiş) veriler girebilir.
Retrieval StratejisiSadece Vektör (Semantic)Tasarımı basittir ve hızlı çalışır.
Retrieval StratejisiHibrit (BM25 + Vektör)Çok daha doğru arama sonuçları verir ancak sistemde iki farklı arama motoru çalıştığı için saldırı yüzeyi ikiye katlanır.
Kiracı (Tenant) İzolasyonuNamespace / Collection ayrımıStandarttır; mimari tasarlanırken ilk günden düşünülmelidir.
Kiracı İzolasyonuŞifreleme + Satır bazlı (Row-level) filtreDaha olgun bir güvenlik yaklaşımıdır; canlı ortam (production) sistemleri için zorunludur.

OWASP Top 10 Eşleşmesi

Bu odada anlatılan kavramların OWASP for LLM standartlarındaki doğrudan karşılıkları:

OWASP MaddesiRAG Mimarisindeki Karşılığı
LLM01 (Indirect Prompt Injection)RAG Zehirlenmesi (Poisoning) — Modül 2.1'in ana odak noktası.
LLM03 (Training Data Poisoning)Embedding modelinin eğitim verisine sızılması, dolaylı yoldan RAG sistemini de bozar.
LLM06 (Sensitive Info Disclosure)Cross-tenant (kiracılar arası) veri sızıntıları ve Embedding Inversion (Modül 2.2) saldırıları.
LLM10 (Model Theft)Açıkta bırakılan veya manipüle edilen Embedding modeli üzerinden model çalma (distillation) operasyonları.

Bölüm Özeti

  • RAG (Retrieval-Augmented Generation): LLM'in genel ve kapalı dünyasını, kurumun dinamik ve özel belgeleriyle genişleten en popüler mimaridir.
  • 5 Çekirdek Adım: Embed (Çevir) → Store (Sakla) → Retrieve (Getir) → Augment (Zenginleştir) → Generate (Üret).
  • Vektör Veritabanları: Sektörde Pinecone, Qdrant, Chroma, pgvector ve Weaviate baskın araçlardır.
  • Kritik Güvenlik Zafiyeti: RAG mimarisindeki en zayıf halka ve RAG Poisoning saldırılarının başlangıç noktası Vektör DB → LLM context geçişidir.
  • OWASP Uyumluluğu: RAG sistemleri ağırlıklı olarak LLM01, LLM03, LLM06 ve LLM10 zafiyet eksenlerinde incelenmelidir.

Sıradaki Oda: RAG'ın görünmeyen arka planındaki matematiksel hesap mekanizmalarına — Embedding ve Vektör Uzayı Güvenliği'ne — geçiyoruz.

Görevler

Görevleri çözmek ve puan kazanmak için giriş yap ya da kayıt ol.
  1. 01
    RAG kısaltmasının açılımı nedir? (üç kelime, İngilizce)
    10 P
  2. 02
    RAG pipeline'ının 5 adımlı DOĞRU sırası hangisidir?
    10 P
  3. 03
    Aşağıdakilerden hangisi **vektör veritabanı** olarak kullanılmak için tasarlanmamıştır?
    İpucu
    MongoDB Atlas Vector Search eklentisi var ama temelde belge DB'si.
    10 P
  4. 04
    Bir RAG sisteminde **en kritik güven sınırı** (trust boundary) hangi geçişte oluşur?
    10 P