RAG Nedir? Retrieval-Augmented Generation ile Doğrulanabilir Kurumsal Yapay Zekâ (2025 Rehberi)

RAG (Retrieval-Augmented Generation), büyük dil modellerinin (LLM) “bildiği kadarıyla” cevap vermesi yerine, yanıtı üretmeden hemen önce ilgili kurumsal içerikleri bulup (retrieve) bu içeriklere dayanarak cevap üretmesini sağlayan bir mimaridir. Kurum içi dokümanlar (PDF’ler, prosedürler, poliçe metinleri, müşteri yazışmaları, confluence, wiki sayfaları, ticket kayıtları vb.) sürekli değişir; LLM ise eğitildiği anda “dondurulmuş” bir bilgiyle gelir. RAG bu boşluğu kapatır: modelin güncel ve doğrulanabilir içerikle konuşmasını sağlar. Bu sayede daha doğru, izlenebilir ve işletilebilir yanıtlar elde edilir; “halüsinasyon” (olmayan bilgi uydurma) riski azalır ve kurumun kendi verisiyle değer üretmek mümkün olur.

RAG’in Temel Mantığı

RAG’in özü, “soruya cevap bulma” işini iki parçaya ayırmaktır: Önce doğru bilgiyi bul, sonra o bilgiye dayanarak anlat. Klasik LLM kullanımında model, soruyu alır ve eğitim sırasında öğrendiklerini ve prompt’taki bağlamı kullanarak cevap üretir. Eğer kurum içi bilginin güncel hali modelin eğitiminde yoksa, model ya eksik yada yanlış cevap verir ya da özgüvenli şekilde uydurur(halüsinasyon). RAG yaklaşımında ise modelin karşısına “kanıt” koyulur: Soruya en yakın doküman parçaları getirilir ve model bu parçaları referans alarak üretim yapar. Bu yüzden RAG, özellikle mevzuat, prosedür, poliçe, sözleşme, ürün katalogları, teknik dokümantasyon gibi doğruluk isteyen alanlarda çok etkilidir.

RAG, LLM’e Neyi Ekler?

RAG, LLM’e temelde üç kritik şey ekler:

• Güncel ve kuruma özel bilgi: Model “dışarıdan” çekilen içerikle konuştuğu için, yeni yayımlanan dokümanlar, güncellenen süreçler veya son fiyat/ürün değişiklikleri gibi eğitim sonrası oluşan bilgiler de cevaplara yansır.
• İzlenebilirlik (traceability): Cevabın hangi doküman parçalarına dayandığı gösterilebilir. Bu, kurumsal kullanımda “neden böyle dedi?” sorusunu cevaplar ve güven inşa eder.
• Kontrol edilebilirlik: Erişim yetkileri, departman bazlı filtreler, yalnızca belirli kaynakları kullanma, alıntı zorunluluğu gibi kurallar uygulanabilir. Böylece hem güvenlik hem kalite yönetimi daha kolay olur.

Önemli bir nokta: RAG, LLM’in “zeka seviyesini” büyütmekten çok, onu doğru bilgiye bağlamanın bir yoludur. Yani RAG, iyi bir bilgi altyapısı ve iyi bir geri getirme (retrieval) kalitesi ister; aksi halde model çok iyi olsa bile yanlış parçaları alıp yanlış(halüsinasyon) ama akıcı cevaplar üretebilir.

“Arama + Üretim” Birlikte Nasıl Çalışır?

RAG’de iki ana motor vardır: retriever (bulucu) ve generator (üretici). Retriever’ın işi, kullanıcının sorusunu bir arama problemine çevirmek ve veri havuzundan en alakalı parçaları çıkarmaktır. Generator ise bu parçaları okur, birleştirir, gerekirse özetler ve kullanıcıya doğal dilde yanıt üretir.

Pratikte bu işleyiş şöyle olur:

1. Kullanıcının sorusu alınır ve sistem bu soruyu, LLM’in anlamsal kavrayışını arama motoru gibi kullanabilmek için “anlamsal bir imzaya” dönüştürür: embedding. Böylece arama, kelime eşleşmesine değil, anlam benzerliğine dayanır.
2. Veri havuzundaki doküman parçaları (chunk’lar) arasında benzerlik aranır. Sonuç olarak ilk k parça seçilir.
3. Seçilen parçalar, bir prompt şablonuyla LLM’e verilir. “Sadece aşağıdaki kaynaklara dayanarak cevapla” gibi kurallar eklenir.
4. LLM cevap üretir. İstenirse her paragrafın sonunda kaynak/alıntı bağlantıları eklenir.

Bu yaklaşımın en güzel tarafı şudur: LLM’i yeniden eğitmeden (fine-tune etmeden) bile, kurumsal bilgiyle yüksek doğrulukta soru-cevap sistemi kurabilirsiniz. Ayrıca veriyi güncellemek, model güncellemekten daha hızlıdır: dokümanı ekle → index’e gir → yeni bilgi anında yanıtlanır.

RAG Akışının 5 Adımı

1. Ingestion (Veriyi içeri alma): PDF, Word, HTML, e-posta, ticket, wiki gibi kaynaklar toplanır. Metin çıkarımı (OCR gerekiyorsa OCR), temizlik ve standartlaştırma yapılır.
2. Chunking (Parçalama): Dokümanlar anlamlı parçalara bölünür. Çok büyük parça “alakayı” düşürür, çok küçük parça ise “bağlamı” koparır. Genelde başlık hiyerarşisi, paragraf sınırları, tablolar ve liste yapıları gibi öğeler dikkate alınır. GIGO (Garbage In, Garbage Out) prensibinin RAG’deki en net karşılığı da burasıdır: kötü parçalama, doğru içeriğin bulunmasını zorlaştırır; yanlış bağlam modele gider ve sistemin tamamı “doğru görünen ama yanlış” cevaplara sürüklenir.
3. Embedding (Vektörleme): Her chunk bir embedding modelinden geçirilir ve sayısal bir vektör olarak saklanır. Bu vektörler “anlamsal benzerlik” araması yapmayı sağlar.
4. Retrieval (Geri getirme): Kullanıcının sorusu da embed edilir; en yakın chunk’lar bulunur. Gerekirse metadata filtreleri (departman, tarih, doküman türü, yetki) uygulanır.
5. Generation (Cevap üretimi): LLM, getirilen chunk’ları bağlam olarak alır ve cevap üretir. İyi tasarımda model, yeterli kanıt yoksa “bilmiyorum / dokümanda yok” demeye yönlendirilir.

Bu 5 adımın her biri kaliteyi doğrudan etkiler. Örneğin chunking kötüyse doğru içerik bulunamaz; retrieval kötüyse yanlış parçalar gelir; prompt tasarımı kötüyse model kaynak dışına taşar. RAG’i “çalıştırmak” kolaydır; “güvenilir ve ürünleşebilir” hale getirmek ise bu adımların her birini ölçerek ve iteratif iyileştirerek mümkün olur.

RAG Ne Zaman “Gerekli”, Ne Zaman “Gereksiz” Olur?

RAG’in gerekli olduğu senaryoların ortak özelliği: Cevap, güvenilir bir kaynağa dayanmak zorundadır ve bilgi sürekli değişebilir. Örneğin:

• Kurumsal doküman Q&A: prosedür, yönetmelik, sözleşme, ürün/poliçe metinleri
• Müşteri destek: “Bu hata neden oluyor?”, “İade süreci nedir?” gibi bilgi tabanına bağlı sorular
• Operasyon rehberliği: ekiplerin adım adım süreç sorması (onboarding, iş akışları)
• Denetim ve uyum: “Bu karar hangi maddeye dayanıyor?” gibi kanıt isteyen kullanım

RAG’in gereksiz (veya ikinci planda) olduğu durumlar ise şunlardır:

• Genel sohbet / yaratıcılık: hikâye yazma, fikir üretme, pazarlama metni gibi “kanıt” gerekmeyen işler. Burada retrieval eklemek çoğu zaman fayda getirmez.
• Saf akıl yürütme / matematik: Eğer gereken bilgi zaten sorunun içinde varsa (ve dış kaynağa ihtiyaç yoksa), modelin muhakemesi daha belirleyicidir. RAG sadece gürültü katabilir.
• Veri çok küçük ve sabitse: Çok az doküman var ve sık değişmiyorsa, iyi bir prompt + manuel bağlam ekleme yeterli olabilir.

Özetle: RAG, “modeli daha akıllı” yapmaktan çok “modeli doğru bilgiye bağlar”. Doğruluk, güncellik, kaynak gösterme ve yetki kontrolü sizin için kritikse RAG neredeyse şarttır. Ama hedefiniz yaratıcı üretim veya bilgiye dayanmayan genel cevaplar ise RAG’e girmek yerine iyi bir prompt, iyi bir model seçimi ve basit bir içerik yönetimi daha hızlı sonuç verir.

RAG Mimarisi

RAG mimarisi, en basit haliyle “doğru bilgiyi bul” ve “o bilgiye dayanarak cevap üret” yaklaşımını ürünleştirir.Bunu yaparken üç temel bileşen birlikte çalışır: Retriever (getiren), Index (indeks/vektör depo),Generator (üreten). Kaliteyi belirleyen şey, bu üçlünün tek tek “iyi” olması değil; aralarındaki zincirin kopmamasıdır.Retriever yanlış içerik getirirse generator ne kadar güçlü olursa olsun, cevap “akıcı ama hatalı” olabilir.

Bileşenler: Retriever, Index, Generator

• Retriever: Kullanıcı sorusunu arama problemine dönüştürür ve en alakalı içerik parçalarını (chunk) bulur. Burada amaç “kelime eşleşmesi” değil, anlam yakınlığıdır. Gerekirse metadata filtreleri (tarih, departman, doküman türü, yetki seviyesi) uygulanır.
• Index (Vektör İndeksi / Vector DB): Dokümanlardan üretilen chunk’ların embedding’lerini saklar ve hızlı benzerlik araması yapar. Index’in görevi sadece depolama değil; aynı zamanda düşük gecikme ile top-k sonuç döndürmektir.
• Generator (LLM): Retriever’ın getirdiği chunk’ları bağlam olarak alır ve yanıt üretir. İyi bir RAG kurgusunda LLM, “kaynağa dayanarak cevapla” kuralına uyar; yeterli kanıt yoksa bunu açıkça belirtir.

Embedding Modeli ve Vektör Temsili

Embedding, metni sayısal bir vektöre çevirerek “anlamı ölçülebilir” hale getirir. RAG’de bu şu anlama gelir:LLM’in dilsel/anlamsal anlayışı, arka planda bir semantic arama motoru gibi kullanılır.Soru ve doküman parçaları aynı “anlam uzayında” temsil edildiği için sistem, kelime bazlı eşleşmeden bağımsız şekildebenzer niyet ve anlam taşıyan chunk’ları bulabilir.

Buradaki kritik nokta şudur: Embedding modeli, RAG’in arama kalbidir. Yanlış embedding seçimi veya tutarsız embedding üretimi;doğru dokümanın hiç bulunamamasına, yanlış dokümanın sürekli üstte gelmesine ve sonuçta “GIGO (Garbage in, garbage out)” etkisine yol açar.Bu yüzden embedding seçiminde dil (Türkçe), domain (sigorta/finans gibi) ve performans (latency/maliyet) birlikte düşünülmelidir.

Chunking ve Overlap Stratejileri

Chunking, dokümanı “geri getirilebilir” birimlere bölme işidir. Ama burada hedef sadece parçalamak değil;her parçanın tek başına anlamlı olmasını sağlamaktır. Çok büyük chunk, alaka (relevance) sinyalini düşürür;çünkü içinde çok fazla konu barındırır. Çok küçük chunk ise bağlamı koparır; çünkü cevap için gereken cümleler farklı parçalara dağılır.

Bu yüzden çoğu RAG sisteminde overlap (örtüşme) kullanılır: Chunk’lar belirli bir miktar “üst üste bindirilir”.Ama overlap’in de maliyeti vardır: indeks boyutu büyür, benzer içerikler çoğalır, aynı bilginin farklı chunk’larda tekrar etmesiretrieval sonuçlarını “tek bir dokümanda dönüp durma” eğilimine sokabilir.

• Overlap neden işe yarar? Cümle sınırları chunk sınırına denk gelmez. Overlap, kritik bağlamın kaybolmasını engeller.
• Overlap ne zaman zararlı? Aynı cümleler çok fazla tekrar ederse index şişer ve retrieval çeşitliliği düşer.
• Alternatif yaklaşım: Sabit karakter sayısı yerine başlık/paragraf yapısına dayalı “semantik chunking”.

Chunk Boyutu Nasıl Seçilir?

Tek bir “doğru chunk boyutu” yoktur; doğru seçim, doküman türüne ve kullanıcı sorularının tipine bağlıdır.Yine de pratikte şu basit çerçeve işe yarar:

• Kısa ve net dokümanlar (SSS, kısa prosedür): Daha büyük chunk’lar (daha az parçaya bölme) genellikle yeterlidir.
• Uzun dokümanlar (poliçe metni, sözleşme, yönetmelik): Daha küçük ve başlık bazlı chunk’lar daha iyi çalışır; çünkü kullanıcı soruları genelde belirli bir madde/başlık etrafında döner.
• Tablo ve maddeli listeler: Satır/öğe bazlı chunking gerekebilir; aksi halde model tablo bağlamını kaybedebilir.

Burada en kritik test şudur: “Bu chunk tek başına okunsa, kullanıcı sorusuna cevap olacak kadar bağlam taşıyor mu?”Cevap hayırsa ya chunk büyütülmeli ya da overlap/semantik chunking ile bağlam desteklenmelidir.Ve unutma: RAG’de kötü chunking, GIGO’nun en net karşılığıdır. Kötü parçalama → kötü retrieval → kötü yanıt.

Vektör Veritabanı ve İndeksleme Seçenekleri

RAG tarafında “vektör veritabanı” dediğimiz katman, aslında anlamsal arama motorunun indeks kısmıdır.Görevi; milyonlarca chunk embedding’i arasında düşük gecikmeyle en yakın (top-k) sonuçları bulmak vebunu yaparken filtre, sıralama ve güncelleme ihtiyaçlarını yönetmektir.

FAISS, Milvus, Qdrant, pgvector Mantıksal Rolü

Bu araçların hepsi aynı probleme çözüm üretir: yakın komşu arama (ANN/KNN).Aralarındaki fark, “hangi ölçekte / hangi operasyonel beklentiyle” kullanıldıklarında ortaya çıkar.

• FAISS: Bir “kütüphane” gibi düşün. Uygulamanın içine gömülür; çok hızlı ANN araması sağlar. Ancak tek başına; kullanıcı/tenant izolasyonu, erişim kontrolü, replikasyon, gözlemlenebilirlik gibi “ürünleşme” ihtiyaçlarını senin tamamlaman gerekir. Prototip ve tek makine senaryoları için idealdir.
• Milvus: Dağıtık ölçek ve yüksek veri hacmi için tasarlanmış vektör veritabanı yaklaşımı. Büyük indekslerde yatay ölçekleme, yönetilen servis kurguları ve operasyonel özellikler (cluster, replication vb.) daha ön plandadır.
• Qdrant: “Ürün odaklı” vektör DB yaklaşımı. Metadata filtreleme, koleksiyon yönetimi, payload alanları, API ergonomisi gibi pratikler güçlüdür. RAG’de sık ihtiyacın olan “filtre + vektör” birleşimini kolaylaştırır.
• pgvector: Vektörleri PostgreSQL içinde tutarak; tek yerde veri, ACID, SQL ile filtreleme gibi avantajlar sağlar. Özellikle kurumsal ekiplerde operasyonel sadeleşme (tek DB, tek backup, tek yetkilendirme) için çok değerlidir. Vektör arama performansı/büyüklük ölçeği hedefe göre değerlendirilmelidir.

Özet karar mantığı: “Basitlik ve kurumsal entegrasyon” istiyorsan pgvector gibi tek DB yaklaşımı çok güçlüdür.“Çok büyük vektör hacmi ve yatay ölçek” hedefliyorsan Milvus/Qdrant gibi bağımsız vektör DB’ler öne çıkar.FAISS ise hızlı prototip / embedded senaryolarda harikadır.

Filtreleme (Metadata) ve Hibrit Arama (BM25 + Vector)

RAG’de kaliteyi uçuran iki özellik vardır: metadata filtreleme ve hibrit arama.Çünkü gerçek dünya sorularının önemli kısmı sadece “anlamsal benzerlik” değil, aynı zamanda kapsam ve yetki içerir.

• Metadata filtreleme: Chunk’lara doküman türü, tarih, departman, müşteri, dil, ürün, erişim seviyesi gibi alanlar eklenir. Arama sırasında “sadece bu departmanın dokümanları”, “son 6 ay”, “TR dokümanları” gibi filtreler uygulanır. Bu, hem doğruluğu artırır hem de KVKK/erişim kontrolü açısından kritiktir.
• Hibrit arama (BM25 + Vector): Bazı sorular “anahtar kelime” yakalamayı ister (örn. poliçe numarası, kod, hata mesajı, madde adı). Vector arama anlamı yakalar ama bazen özel terimleri kaçırabilir. BM25 ise kelime bazlı “keskin eşleşme” sağlar. Hibrit yaklaşım, ikisinin skorlarını birleştirerek daha dengeli sonuç verir.

Pratik ipucu: Kurumsal RAG’de “sadece vector” çoğu zaman yeterli olur; ama kodlar, numaralar, kısa teknik hata metinlerigibi içeriklerde hibrit arama fark yaratır. Metadata filtreleme ise neredeyse her zaman gerekir.

Çok Kiracılı (Multi-Tenant) Tasarım Notları

Multi-tenant bir RAG (ManselIQ gibi) tasarlarken en büyük risk: bir müşterinin verisinin diğer müşteriye “sızması”.Bu yüzden multi-tenant tasarımda temel hedef izolasyon + performans + yönetilebilirlik dengesidir.

• İzolasyon stratejisi:
  • Tenant başına koleksiyon/indeks: En temiz izolasyon. Yönetim maliyeti artar ama güvenlik nettir.
  • Tek koleksiyon + tenant_id filtre: Operasyonel olarak basit ama filtrelerin %100 zorunlu olduğundan emin olmalısın.
• Erişim kontrolü (RBAC/ABAC): Sadece tenant değil; departman/rol bazlı filtreler de gerekir. “Bu kullanıcı bu dokümanı görebilir mi?” kararı retrieval aşamasında uygulanmalıdır.
• Şifreleme ve anahtar yönetimi: En azından “at-rest” şifreleme; tercihen tenant bazlı anahtar politikası. (Özellikle sözleşme/poliçe gibi hassas verilerde.)
• Kaynak yönetimi (quota): Tenant başına indeks boyutu, sorgu limiti, embedding üretim kotası gibi limitler koymak, hem maliyeti hem de kötüye kullanımı kontrol eder.
• Silme ve unutulma: Bir doküman silindiğinde, ilgili chunk’ların indeksten de silindiğinden emin ol. “Soft delete” mi “hard delete” mi; log/audit ihtiyacına göre tasarla.
• Gözlemlenebilirlik: Tenant bazlı gecikme, recall/başarı, hata oranı, en sık sorular gibi metrikler kaliteyi yönetmek için şarttır.

Kısacası: Multi-tenant RAG’de arama kalitesi kadar yetki ve izolasyon da “ürün kalitesi”nin bir parçasıdır.En iyi retrieval bile, yanlış tenant verisi dönüyorsa ürünü bitirir.