RAG Mimarisi Nasıl Kurulur? Chunking'den Eval'e Üretim Rehberi

RAG mimarisi nasıl kurulur? RAG mimarisi, bir dil modelini dış bir bilgi kaynağıyla besleyen ve iki boru hattından oluşan uçtan uca bir sistem tasarımıdır: kaynak belgeleri chunking ile parçalayıp embedding ile vektöre çeviren ve bir vektör veritabanına indeksleyen çevrimdışı indeksleme hattı; ve kullanıcı sorusuna karşı dense, sparse veya hybrid search ile ilgili parçaları getiren, reranking ile en alakalıları öne alan ve dil modeliyle yanıtı ürettiren çevrimiçi sorgu hattı. Üretim kalitesinde bir RAG mimarisi bu ikisinin üzerine evaluation, gözlemlenebilirlik, güvenlik/KVKK ve ölçekleme katmanlarını ekler.

Bir demoyu ayakta tutmak kolaydır; bir RAG mimarisini üretimde güvenilir kılmak zordur. Aradaki fark, tek tek bileşenlerde değil, bu bileşenlerin doğru sırayla, doğru ödünleşimlerle ve ölçülebilir biçimde birbirine bağlanmasındadır. Bu rehber, bir yönetim ve teknik danışman titizliğiyle, RAG mimarisini uçtan uca ele alıyor: veri hazırlığından chunking stratejilerine, embedding ve vektör veritabanı seçiminden retrieval (dense, sparse, hybrid search) ve reranking katmanlarına, prompt ve generation tasarımından evaluation, gözlemlenebilirlik, ölçekleme ve KVKK/EU AI Act uyumuna kadar. RAG kavramının temeline hâkim değilseniz önce RAG nedir yazısını, dil modelinin ne olduğunu görmek için LLM nedir rehberini okumanız faydalı olur.

Tanım

RAG Mimarisi (Retrieval-Augmented Generation Mimarisi)

Bir dil modelini dış bir bilgi kaynağıyla besleyen uçtan uca sistem tasarımıdır. RAG mimarisi iki boru hattından oluşur: kaynak belgeleri chunking ile parçalayıp embedding ile vektöre çeviren ve vektör veritabanına indeksleyen çevrimdışı indeksleme hattı; ve kullanıcı sorusuna karşı dense/sparse/hybrid search ile getirme, reranking ile yeniden sıralama ve dil modeliyle üretim yapan çevrimiçi sorgu hattı. Üretim kalitesinde bir RAG mimarisi; evaluation, gözlemlenebilirlik, güvenlik/KVKK ve ölçekleme katmanlarını da içerir.

Ayrıca: retrieval augmented generation mimarisi, kurumsal RAG mimarisi, RAG boru hattı, RAG sistem tasarımı

Bir hafta sonu bir dil modeline birkaç PDF bağlayıp "belgelerimle konuşan" bir prototip kurmak bugün herkesin harcıdır. Ama aynı prototipi binlerce belge, yüzlerce eşzamanlı kullanıcı, sıkı gecikme hedefleri, denetlenebilirlik ve KVKK yükümlülükleri altında çalıştırmak bambaşka bir mühendislik problemidir. RAG mimarisinin asıl zorluğu, "çalışan bir demo" ile "güvenilir bir üretim sistemi" arasındaki bu uçurumdadır.

Bu uçurumun birinci nedeni, kalitenin görünmez katmandan gelmesidir. Kullanıcı yalnızca nihai yanıtı görür; oysa yanıtın doğruluğu, çoğunlukla modelden değil, o yanıta zemin oluşturan getirme katmanından kaynaklanır. Yanlış parça getirildiyse, dünyanın en güçlü dil modeli bile doğru cevabı üretemez. Bu yüzden RAG mimarisinde emeğin çoğu, modeli değiştirmeye değil, indeksleme ve retrieval katmanını doğru kurmaya harcanır.

İkinci neden, hataların sessiz olmasıdır. Klasik bir yazılım hatası bir istisna fırlatır ve loglarda görünür. Bir RAG hatası ise sessizdir: sistem akıcı, kendinden emin ve tamamen yanlış bir yanıt üretir. Bu tür bir halüsinasyonu yakalamak için özel bir değerlendirme ve gözlemlenebilirlik disiplini gerekir; halüsinasyonun doğasını yapay zeka halüsinasyonu nedir yazısında ele alıyoruz. Ölçmeyen bir RAG mimarisi, kör uçan bir uçaktır.

Üçüncü neden, ödünleşimlerin her yerde olmasıdır. Daha büyük parçalar daha çok bağlam taşır ama daha çok gürültü ve maliyet ekler. Daha derin bir retrieval daha yüksek recall verir ama gecikmeyi artırır. Daha güçlü bir reranker isabeti yükseltir ama saniyeler ekleyebilir. RAG mimarisi kurmak, bu ödünleşimleri bilinçli ve ölçülü seçmektir; ve bu seçimlerin doğruluğu ancak evaluation ile kanıtlanır. Bu rehberin geri kalanı, tam olarak bu bilinçli seçimlerin haritasıdır.

Bir RAG mimarisini anlamanın en net yolu, onu iki ayrı boru hattı olarak görmektir. Bunlar farklı zamanlarda, farklı performans hedefleriyle çalışır ve karıştırıldıklarında sistem tasarımı bulanıklaşır.

Birinci hat, çevrimdışı indeksleme hattıdır (offline / ingestion). Bu hat kullanıcı beklemezken, arka planda çalışır. Görevi bilgiyi arama için hazır hale getirmektir: kaynakları toplar, temizler, chunking ile parçalar, her parçayı embedding ile bir vektöre çevirir ve bir vektör veritabanına, metadata ile birlikte indeksler. Bu hat toplu (batch) çalışabilir; hızdan çok doğruluk ve eksiksizlik önemlidir. Belgeler değiştikçe bu hat yeniden veya artımlı olarak çalıştırılır.

İkinci hat, çevrimiçi sorgu hattıdır (online / query). Bu hat kullanıcı beklerken, gerçek zamanlı çalışır ve gecikmeye duyarlıdır. Kullanıcının sorusunu alır, aynı embedding modeliyle vektöre çevirir, vektör veritabanından dense, sparse veya hybrid search ile aday parçaları getirir, reranking ile en alakalıları seçer, bunları bir prompt şablonuna yerleştirir ve dil modeline yanıtı ürettirir. Yanıt, hangi kaynaklara dayandığını gösteren atıflarla birlikte sunulur.

Nasıl Yapılır

RAG mimarisi uçtan uca boru hattı

Bir belgenin indekslenmesinden bir kullanıcı sorusunun yanıtlanmasına kadar RAG mimarisinin izlediği temel adımlar.

1. 1

   Topla ve temizle

   Kaynak belgeler (PDF, wiki, veritabanı, e-posta) toplanır, gürültü temizlenir ve normalize edilir.

2. 2

   Chunking ile parçala

   Belgeler anlamlı, kendi kendine yeten parçalara bölünür; metadata (kaynak, tarih, yetki) eklenir.

3. 3

   Embedding ile vektöre çevir

   Her parça bir embedding modeliyle anlamsal vektöre dönüştürülür.

4. 4

   Vektör veritabanına indeksle

   Vektörler ve metadata, yaklaşık en yakın komşu indeksiyle vektör veritabanına yazılır.

5. 5

   Getir (retrieval)

   Kullanıcı sorusu embedding'e çevrilir; dense, sparse veya hybrid search ile aday parçalar getirilir.

6. 6

   Reranking uygula

   Adaylar çapraz kodlayıcıyla yeniden sıralanır; en alakalı birkaç parça seçilir.

7. 7

   Bağlamla üret (generation)

   Seçilen parçalar prompt'a yerleştirilir ve dil modeli, kaynak göstererek yanıtı üretir.

8. 8

   Ölç ve izle

   Evaluation metrikleri ve gözlemlenebilirlik ile her adımın kalitesi sürekli izlenir.

Bu iki hattı ayrı düşünmenin pratik değeri büyüktür. İndeksleme kalitesi bir kez iyi kurulduğunda tüm sorguların tavanını yükseltir; sorgu hattı ise her istekte gecikme ve maliyet ödünleşimini yönetir. Bir RAG mimarisini iyileştirirken "sorun indekslemede mi, sorguda mı?" diye ayırmak, çözümü hızlandırır. İki hattın da ortak dili embedding'dir; bu kavramın temeli için embedding nedir ve arama mantığı için semantik arama nedir yazıları iyi bir zemin sağlar.

Her RAG mimarisi, beslendiği veri kadar iyidir. "Çöp girer, çöp çıkar" ilkesi burada acımasızca işler: dağınık, güncelliğini yitirmiş veya çelişkili kaynaklarla beslenen bir sistem, en zarif retrieval ve reranking katmanlarına rağmen güvenilmez yanıtlar üretir. Bu yüzden veri hazırlığı, RAG mimarisinin görünmeyen ama belirleyici ilk adımıdır.

İlk karar kaynak seçimidir. Hangi belgeler bilgi tabanına girecek? Burada "ne kadar çok o kadar iyi" yanılgısına düşmemek gerekir. Çelişen iki politika belgesi, güncelliğini yitirmiş bir kılavuz veya taslak halindeki bir doküman, sisteme dahil edildiğinde retrieval'ı bozar ve modeli yanlış yönlendirir. Sağlıklı yaklaşım, otoriter ve güncel kaynakları seçip her birine bir güven ve tazelik etiketi vermektir; çelişki olduğunda hangi kaynağın kazanacağı baştan tanımlanmalıdır.

İkinci adım temizleme ve normalize etmedir. PDF'lerden gelen bozuk satır sonları, tekrarlanan üstbilgi/altbilgiler, gezinme menüleri, tablolardan kopan hücreler ve OCR hataları, embedding kalitesini doğrudan bozar. Bu gürültü ayıklanmalı; tablolar ve listeler anlamlı biçimde metne çevrilmeli; başlık hiyerarşisi korunmalıdır. Yapılandırılmış içerik (tablolar, kod, formlar) çoğu zaman özel işlem gerektirir; düz metne indirgenirse anlamı kaybolur.

Üçüncü adım zenginleştirme ve metadatadır. Her parçaya kaynak adı, bölüm başlığı, tarih, dil, gizlilik seviyesi ve erişim yetkisi gibi metadata eklemek, hem retrieval'ı hem de güvenliği güçlendirir. Bu metadata sayesinde sistem "yalnızca son bir yıla ait belgelerden getir" veya "yalnızca bu kullanıcının yetkili olduğu belgelerden getir" gibi filtreler uygulayabilir. Metadata olmadan bir RAG mimarisi, ne zaman filtreleme yapacağını bilemez ve güvenlik açıkları taşır.

Dördüncü ve sık atlanan adım, çelişki ve tekrar yönetimidir. Büyük bir bilgi tabanında aynı konuyu farklı biçimde anlatan, hatta birbiriyle çelişen belgeler kaçınılmazdır: eski ve yeni bir politika, iki farklı departmanın aynı konudaki notu, bir kılavuzun birden çok sürümü. Bu durumda retrieval, hangi belgenin doğru olduğunu kendiliğinden bilemez ve model çelişen parçalarla beslenirse tutarsız yanıt üretir. Sağlıklı bir RAG mimarisi, tazelik ve otorite metadatasıyla bu çelişkiyi çözer: en güncel ve en yetkili kaynağı önceliklendiren bir mantık kurar, mükerrer içeriği ayıklar ve gerektiğinde belge sürümlerini birbirine bağlar. Bu disiplin olmadan, bilgi tabanı büyüdükçe kalite düşer — çünkü daha çok belge, daha çok çelişki demektir.

Chunking, bir RAG mimarisinin en çok hafife alınan ama en belirleyici kararıdır. Chunking, belgeleri retrieval için parçalara bölme işlemidir; ve bu parçaların boyutu, sınırı ve örtüşmesi, doğru bilginin bulunup bulunamayacağını doğrudan belirler. Chunking'in temel kavramsal çerçevesi için chunking nedir yazısına bakabilirsiniz; burada üretim odaklı stratejilere odaklanıyoruz.

Chunking'in temel gerilimi şudur: parça çok küçükse, tek başına anlamlı bir yanıt taşımaz ve bağlam kopar; parça çok büyükse, ilgili cümlenin yanına alakasız içerik gelir, bu hem retrieval isabetini düşürür hem de token maliyetini ve gürültüyü artırır. İyi bir chunk, tek bir tipik soruya kendi kendine yeten, tam ve odaklı bir yanıt taşıyacak büyüklüktedir.

Sabit Boyutlu ve Örtüşmeli Chunking

En yaygın başlangıç stratejisi, belgeyi sabit sayıda token içeren parçalara bölmek ve komşu parçalar arasında bir miktar örtüşme (overlap) bırakmaktır. Örtüşme, bir cümlenin veya fikrin tam parça sınırında ikiye bölünüp bağlamının kopmasını engeller. Pratik bir başlangıç noktası, orta boy parçalar (örneğin birkaç yüz token) ve makul bir örtüşme oranıdır; ama bu değerler bir dogma değil, evaluation ile ayarlanacak hiperparametrelerdir. Token kavramının ne olduğunu token nedir yazısında bulabilirsiniz.

Yapı-Farkında Chunking

Belgeler nadiren düz metindir; başlıklar, bölümler, paragraflar, listeler ve tablolar taşırlar. Yapı-farkında chunking, bu doğal sınırlara saygı gösterir: bir parçayı bir başlığın ortasında değil, mantıksal bir birimin sonunda keser. Böylece her parça, ait olduğu bölümün başlığını ve bağlamını taşıyabilir. Bu strateji, kurumsal dokümantasyon, kılavuzlar ve yapılandırılmış içerikte çoğu zaman sabit boyutlu chunking'den belirgin biçimde daha iyi sonuç verir çünkü anlamsal bütünlüğü korur.

Semantik Chunking

Semantik chunking, sınırları belge yapısına değil, anlamın kendisine göre belirler. Ardışık cümlelerin embedding'leri karşılaştırılır ve anlamsal olarak kopuş yaşanan noktalarda parça sınırı çizilir. Bu yaklaşım, konu değiştiğinde parçayı bölerek her parçanın tek bir fikre odaklanmasını sağlar. Semantik chunking daha maliyetlidir çünkü indeksleme sırasında ek embedding hesaplaması gerektirir; ama tutarsız yapıya sahip veya çok konulu belgelerde retrieval kalitesini yükseltebilir.

Çok Katmanlı ve Bağlamsal Chunking

İleri seviye RAG mimarilerinde, aynı belge birden çok çözünürlükte indekslenir: küçük parçalar hassas retrieval için, büyük parçalar (veya ana belge) tam bağlam için. Bir yaygın desen, küçük parçayla arama yapıp modele o parçanın etrafındaki daha geniş pencereyi vermektir ("küçük getir, büyük besle"). Bir başka güçlü teknik, her parçaya onu özetleyen veya belge içindeki yerini açıklayan kısa bir bağlamsal başlık eklemektir; bu, izole bir parçanın bile nereye ait olduğunu bilmesini sağlar.

RAG mimarisinde chunking stratejilerinin karşılaştırması

Strateji	Güçlü olduğu yer	Ödünleşimi
Sabit boyut + örtüşme	Basit, hızlı, öngörülebilir	Anlam sınırlarını görmezden gelir
Yapı-farkında	Başlık/paragraf bütünlüğünü korur	Yapısız belgelerde işe yaramaz
Semantik	Konu değişimini yakalar	İndekslemede ek maliyet
Çok katmanlı / bağlamsal	Hassas arama + tam bağlam	Karmaşıklık ve depolama artışı

Chunking'de tek doğru yoktur; doğru strateji belge türüne, sorgu desenine ve dile bağlıdır. Türkçe belgelerde cümle sınırlarının ve çekim eklerinin embedding'e etkisi göz önünde tutulmalıdır. Kritik olan nokta şudur: chunking bir tahmin değil, evaluation ile ölçülüp iyileştirilen bir karardır. En doğru parça boyutunu, birkaç seçeneği aynı altın soru kümesiyle test ederek bulursunuz.

Embedding modeli, RAG mimarisinin anlamsal omurgasıdır: metni, anlamı temsil eden bir vektöre çeviren ve böylece anlamsal aramayı mümkün kılan bileşendir. Yanlış embedding modeli, en iyi chunking ve reranking'i bile boşa çıkarır çünkü aramanın temeli olan anlam temsili bozuk olur. Embedding kavramının derinini embedding nedir yazısında ele alıyoruz; burada seçim kriterlerine odaklanıyoruz.

Birinci kriter dil ve alan uyumudur. Türkçe ağırlıklı bir bilgi tabanı için, embedding modelinin Türkçeyi iyi temsil etmesi kritik önemdedir; yalnızca İngilizce için eğitilmiş bir model, Türkçe eş anlamlıları ve bağlamı zayıf yakalar. Çok dilli (multilingual) embedding modelleri bu ihtiyacı karşılar. Ayrıca hukuk, tıp veya finans gibi özel alanlarda, alana uyarlanmış embedding'ler genel modellerden daha iyi sonuç verebilir.

İkinci kriter vektör boyutu ve performanstır. Daha yüksek boyutlu embedding'ler daha zengin anlam temsil edebilir ama daha çok depolama ve daha yavaş arama gerektirir. Bazı modeller, tek bir modelden farklı boyutlarda vektör üretmeye izin veren esnek boyut (Matryoshka benzeri) yapıları sunar; bu, kalite ile maliyet arasında ayar yapmayı kolaylaştırır. Boyut seçimi de bir ödünleşimdir ve evaluation ile doğrulanmalıdır.

Üçüncü kriter dağıtım modelidir: embedding'i bir API üzerinden mi alacaksınız, yoksa kendi altyapınızda açık kaynak bir modeli mi barındıracaksınız? API kolaydır ve bakım gerektirmez ama veri dışarı çıkar ve hacimle maliyet büyür. Kendi barındırma, veri egemenliği ve KVKK açısından avantaj sağlar ama altyapı ve operasyon yükü getirir. Açık kaynak seçeneklerini açık kaynak LLM nedir yazısında, KVKK boyutunu ise ilerideki bölümde ele alıyoruz.

Dördüncü ve giderek önem kazanan kriter, embedding modelinin bağlam farkındalığı ve özel eğitilebilirliğidir. Genel amaçlı bir embedding modeli çoğu senaryo için yeterlidir; ancak alanınıza özgü terminoloji yoğunsa (örneğin bir sektörün kısaltmaları, ürün adları veya teknik jargonu), embedding modelini kendi verinizle ince ayarlamak retrieval kalitesini belirgin biçimde yükseltebilir. Bu, ek bir maliyet ve uzmanlık gerektirir; bu yüzden yalnızca genel modelin sınırına ulaşıldığı kanıtlandığında düşünülmelidir. Pratik yol şudur: önce güçlü bir hazır çok dilli embedding ile taban çizgisini kurun, evaluation ile ölçün ve ancak retrieval belirli terim gruplarında sistematik olarak başarısız oluyorsa alana özgü ince ayara yatırım yapın. Erken optimizasyon burada da tuzaktır; ölçmeden özelleştirmek, çoğu zaman getirisi belirsiz bir emek harcamasıdır.

Vektör veritabanı, embedding'leri saklayan ve bir soru vektörüne anlamca en yakın parçaları hızla bulan bileşendir. RAG mimarisinde bu bileşen, ölçek büyüdükçe gecikme ve maliyetin belirleyicisi olur. Temel kavram için vektör veritabanı nedir yazısına bakabilirsiniz; burada seçim ve indeksleme kararlarına odaklanıyoruz.

Milyonlarca vektör arasında en yakın komşuyu tam olarak aramak pahalıdır; bu yüzden vektör veritabanları yaklaşık en yakın komşu (ANN) indeksleri kullanır. Yaygın bir indeks ailesi olan HNSW (hiyerarşik gezilebilir küçük dünya grafiği), yüksek isabetle hızlı arama sunar ama bellek kullanır ve inşa parametreleri ayar gerektirir. Bu parametreler, isabet (recall) ile hız arasında bir ödünleşim sunar: daha yüksek isabet daha yavaş arama demektir. Doğru ayar, uygulamanızın gecikme hedefine ve kalite ihtiyacına bağlıdır.

Vektör veritabanı seçiminde ürün adından çok yetenekler önemlidir. Değerlendirilmesi gereken başlıca kriterler şunlardır: veri ölçeği ve büyüme, sorgu gecikmesi hedefi, metadata filtreleme desteği (retrieval'ı yetki ve tarihe göre kısıtlamak için), hybrid search desteği (dense ve sparse skorları harmanlamak için), yatay ölçeklenebilirlik, yedekleme/kurtarma ve mevcut altyapıyla uyum. Küçük ve orta ölçekte, mevcut ilişkisel veritabanınızın vektör eklentisi çoğu zaman yeterlidir ve operasyonu basitleştirir; çok büyük ölçekte özel bir vektör veritabanı belirgin avantaj sağlar.

RAG mimarisi için vektör veritabanı değerlendirme kriterleri

Kriter	Neden önemli	Dikkat edilmezse
ANN indeks tipi (örn. HNSW)	Hız-isabet dengesini belirler	Yavaş veya isabetsiz arama
Metadata filtreleme	Yetki ve tarih bazlı kısıtlama	Güvenlik açığı, alakasız sonuç
Hybrid search desteği	Anlam + tam terim birlikte	Nadir terimlerde recall düşüşü
Ölçeklenebilirlik	Hacim büyüdükçe gecikme sabit kalır	Ölçekte maliyet ve yavaşlama patlaması
Altyapı uyumu	Operasyon ve bakım yükü	Gereksiz karmaşıklık ve maliyet

İndekslemeyle ilgili sık atlanan bir konu, güncellemedir. Belgeler değişir, silinir ve eklenir; RAG mimarisinin bunu yöneten bir mekanizması olmalıdır. Silinen bir belgenin parçaları indeksten kaldırılmazsa, sistem artık var olmayan bir politikaya dayanarak yanıt üretmeye devam eder; bu, sessiz ama ciddi bir hata kaynağıdır. Artımlı indeksleme, sürümleme ve tazelik metadatası, üretim kalitesinde bir RAG mimarisinin ihmal edilemez parçalarıdır.

İndekslemenin bir başka boyutu, metadata filtreleme ile vektör aramanın birlikte nasıl çalıştığıdır. Yetki veya tarihe göre filtreleme, arama sırasında iki farklı stratejiyle uygulanabilir: önce filtreleyip sonra vektör araması yapmak (pre-filtering) ya da önce arayıp sonra filtrelemek (post-filtering). Pre-filtering daha güvenlidir çünkü yetkisiz belgeler hiç değerlendirilmez, ama çok kısıtlayıcı bir filtre yaklaşık en yakın komşu indeksinin verimini düşürebilir; post-filtering hızlıdır ama sonuç kümesi filtreden sonra çok küçülebilir. Doğru RAG mimarisi, bu ödünleşimi vektör veritabanının yeteneklerine göre seçer ve özellikle güvenlik açısından kritik filtrelerde (kullanıcı yetkisi gibi) pre-filtering'i tercih eder. Bu detay küçük görünse de, ölçekte hem gecikmeyi hem de güvenliği doğrudan etkiler.

Retrieval, RAG mimarisinin kalbidir: kullanıcı sorusuna karşı bilgi tabanından doğru parçaları bulma işidir. Yanıt kalitesi neredeyse tümüyle bu adımın isabetine bağlıdır; çünkü model yalnızca kendisine getirilen bağlam kadar iyi cevap verebilir. Retrieval'ın üç temel yaklaşımı vardır ve olgun bir RAG mimarisi çoğu zaman bunları birleştirir.

Dense Retrieval (Anlamsal Arama)

Dense retrieval, hem belgeleri hem soruyu embedding vektörlerine çevirir ve anlamca en yakın vektörleri arar. Gücü, kelime örtüşmesine değil anlama dayanmasıdır: "iade koşulları" sorusu, belgede "para geri ödeme şartları" yazsa bile doğru parçayı getirebilir. Zayıflığı, nadir ve tam eşleşmesi gereken terimlerde (ürün kodları, özel adlar, kısaltmalar, kod parçaları) bazen ıskalamasıdır çünkü bu terimler anlamsal uzayda ayırt edici olmayabilir.

Sparse Retrieval (Anahtar Kelime Arama)

Sparse retrieval, klasik bilgi getirme yöntemlerine dayanır; en bilineni BM25'tir. Bu yöntemler kelime örtüşmesini ve terim sıklığını puanlar. Gücü, tam terim eşleşmesindedir: bir hata kodunu, bir madde numarasını veya nadir bir teknik terimi güvenilir biçimde bulur. Zayıflığı ise anlamı görmemesidir; eş anlamlıları ve yeniden ifade edilmiş soruları yakalayamaz. Yani dense ve sparse yöntemlerin güçlü ve zayıf yönleri neredeyse birbirinin aynasıdır.

Hybrid Search (Melez Arama)

İşte bu tamamlayıcılık, hybrid search'ün mantığını doğurur. Hybrid search, dense ve sparse retrieval'ı birlikte çalıştırır ve iki yöntemin skorlarını harmanlar; böylece hem anlamı hem de tam terimi yakalar. Skorları birleştirmenin yaygın bir yolu, karşılıklı sıra füzyonu (RRF) gibi yöntemlerle iki listeyi tek bir sıralamada birleştirmektir. Üretim RAG mimarilerinde hybrid search, tek başına dense veya tek başına sparse yöntemden çoğunlukla daha yüksek ve daha kararlı recall verdiği için varsayılan tercih haline gelmiştir.

Hybrid search'ün değeri özellikle gerçek dünyanın karışık sorgularında ortaya çıkar. Kullanıcılar bazen doğal dilde ("garanti süresi ne kadar?"), bazen tam terimle ("Madde 7.2") arar; tek bir yöntem bu iki deseni birden iyi karşılayamaz. Hybrid search, RAG mimarisini bu çeşitliliğe karşı dayanıklı kılar. Ayrıca çok adımlı sorgularda, sorguyu yeniden yazma (query rewriting) ve alt sorulara bölme gibi teknikler retrieval'ı daha da güçlendirir; bu tekniklerin bir kısmı ajan tabanlı yaklaşımlarla birleşir ve agentic AI nedir yazısında ele aldığımız otonom akıl yürütmeyle bağlanır.

Dense, sparse ve hybrid search karşılaştırması

Yöntem	Güçlü olduğu	Zayıf olduğu	Tipik kullanım
Dense (anlamsal)	Eş anlam, yeniden ifade	Nadir terim, tam eşleşme	Doğal dil soruları
Sparse (BM25)	Tam terim, kod, kısaltma	Eş anlam, bağlam	Kesin terim aramaları
Hybrid search	İkisinin en iyisi	Kurulum ve ayar karmaşıklığı	Üretim varsayılanı

Retrieval'ı iyileştirmenin çoğu zaman gözden kaçan bir kaldıracı, kullanıcının ham sorusunu olduğu gibi aramamaktır. Kullanıcılar soruları eksik, belirsiz, konuşma bağlamına gömülü veya çok parçalı biçimde sorar; bu ham soru doğrudan embedding'e çevrilip aratıldığında retrieval isabeti düşebilir. Sorgu dönüşümü (query transformation), bu ham soruyu retrieval için daha uygun bir veya birkaç sorguya çeviren ara katmandır ve olgun bir RAG mimarisinde belirgin kalite kazancı sağlar.

En yaygın teknik sorgu yeniden yazmadır (query rewriting): bir dil modeli, kullanıcının kısa ve bağlama bağımlı sorusunu ("peki ya iadesi?") kendi kendine yeten açık bir soruya ("bu ürünün iade süresi ve koşulları nelerdir?") dönüştürür. Konuşma tabanlı bir asistanda bu adım kritiktir çünkü retrieval, önceki mesajların bağlamını taşımaz; soruyu bağımsız hale getirmek gerekir.

İkinci bir teknik çok-sorgulu getirmedir (multi-query): tek soru, farklı ifadelerle birkaç varyanta çoğaltılır, her varyantla ayrı arama yapılır ve sonuçlar birleştirilir. Bu, tek bir ifadenin kaçırdığı ilgili parçaları yakalama şansını artırır. Üçüncü bir teknik, sorguyu alt sorulara bölmedir (decomposition): "A ürünü ile B ürününün garanti farkı nedir?" gibi bileşik bir soru, iki alt soruya ayrılıp ayrı ayrı yanıtlanır ve sonra birleştirilir. Dördüncü bir yaklaşım, varsayımsal belge gömme (HyDE benzeri) fikridir: model önce soruya olası bir yanıt taslağı üretir, bu taslak embedding'e çevrilip aratılır; çünkü bir yanıt metni, ham sorudan çok, aranan belgeye anlamsal olarak daha yakın olabilir.

Sorgu dönüşümü ücretsiz değildir: her ek model çağrısı gecikme ve maliyet ekler. Bu yüzden hangi tekniğin gerçekten katkı verdiği evaluation ile ölçülmeli ve yalnızca kanıtlanmış olanlar üretime alınmalıdır. Basit ve net sorguların çoğunlukta olduğu bir sistemde ağır sorgu dönüşümü gereksiz olabilir; belirsiz ve konuşma bağlamlı sorguların yoğun olduğu bir sistemde ise retrieval kalitesini kurtaran katman tam da budur.

İlk getirme aşaması hız için tasarlanır: milyonlarca parça arasından hızla bir aday listesi (örneğin ilk 20-50 parça) döndürür. Ama bu hız bir bedelle gelir — aday listesindeki parçaların hepsi eşit derecede alakalı değildir ve sıralamaları her zaman doğru değildir. Reranking, tam olarak bu sorunu çözer: aday listesini alıp her parçayı soruya karşı yeniden, daha titizce puanlar ve en alakalıları öne alır. Reranker kavramının temeli için reranker nedir yazısına bakabilirsiniz.

Reranking'in gücü, kullandığı model tipinden gelir. İlk getirme genellikle bi-encoder mantığıyla çalışır: soru ve belge ayrı ayrı vektöre çevrilir ve karşılaştırılır; hızlıdır ama etkileşimi kaçırır. Reranker ise çapraz kodlayıcı (cross-encoder) kullanır: soru ve parçayı birlikte, aynı anda modele verir ve aralarındaki alakayı doğrudan puanlar. Bu, çok daha isabetli bir sinyaldir ama her aday için ayrı bir model çağrısı gerektirdiğinden yavaştır; bu yüzden tüm bilgi tabanına değil, yalnızca ilk getirmenin döndürdüğü küçük aday kümesine uygulanır.

Bu iki aşamalı tasarım — hızlı ve geniş ilk getirme, ardından yavaş ve isabetli reranking — RAG mimarisinin en zarif ödünleşimlerinden biridir. İlk getirme recall'ı (doğru parçanın aday listesine hiç girmesi) garanti etmeye çalışır; reranking ise precision'ı (doğru parçanın en üste çıkması) sağlar. İkisi birlikte, modele giden bağlamın hem eksiksiz hem odaklı olmasını sağlar.

Reranking'in ikinci bir faydası maliyet ve gürültü azaltımıdır. Reranking olmadan, modele emin olmak için çok sayıda parça göndermek gerekir; bu hem token maliyetini artırır hem de gerçekten önemli parçanın alakasız içerik arasında kaybolmasına ("bağlam içinde kaybolma") yol açar. Reranking, en iyi birkaç parçayı seçerek modele daha az ama daha nitelikli bağlam gönderir; bu genellikle hem daha ucuz hem daha doğru yanıt üretir. Bağlam penceresinin sınırlarını anlamak için context window nedir yazısı yol gösterir.

Retrieval doğru parçaları getirdikten sonra, sıra bu parçaları bir yanıta dönüştürecek generation katmanına gelir. Burada yaygın bir yanılgı, "iyi parça getirildiyse gerisi kendiliğinden olur" varsayımıdır. Gerçekte prompt tasarımı, RAG mimarisinin doğruluğunu ve güvenliğini doğrudan etkiler; kötü bir prompt, mükemmel bir retrieval'ı bile ziyan eder.

Generation katmanının temeli, iyi bir sistem promptudur. Bu prompt modele üç şeyi net biçimde söylemelidir: yalnızca kendisine verilen bağlama dayan; bağlamda cevap yoksa uydurma ve "bu bilgi kaynaklarımda yok" de; ve yanıtını hangi kaynağa dayandırdığını göster. Bu üç kural, halüsinasyonu belirgin biçimde azaltır ve yanıtları denetlenebilir kılar. Sistem promptunun rolü için prompt engineering nedir yazısı derinlemesine bağlam sunar.

Bağlamın prompt içine nasıl yerleştirildiği de önemlidir. Getirilen parçalar açık sınırlarla ayrılmalı, her birine kaynağı ve gerekiyorsa tarihi eklenmelidir; böylece model atıf yapabilir. Parçaların sırası da etkilidir: modeller bağlamın başındaki ve sonundaki bilgiye ortasındakinden daha çok dikkat etme eğilimindedir, bu yüzden en alakalı parçaları uçlara yerleştirmek işe yarayabilir. Ayrıca bağlam bütçesi yönetilmelidir: context window sınırlıdır ve gereğinden fazla parça hem maliyet hem gürültü ekler.

Generation katmanının bir başka önemli kararı, yanıt biçimi ve atıf tasarımıdır. Kullanıcı yalnızca doğru bilgiyi değil, o bilgiye nasıl güveneceğini de ister; bu yüzden yanıtın hangi cümlesinin hangi kaynağa dayandığını gösteren satır içi atıflar, güveni belirgin biçimde artırır. İyi bir RAG mimarisi, modele yalnızca "kaynak göster" demez; atıfların formatını, kaynak numaralandırmasını ve kullanıcının tıklayıp orijinal belgeye ulaşabilmesini de tasarlar. Ayrıca yanıt uzunluğu ve tonu, kullanım senaryosuna göre ayarlanmalıdır: bir hukuk asistanı temkinli ve ayrıntılı, bir müşteri destek asistanı kısa ve net olmalıdır. Bu biçimsel kararlar teknik retrieval kadar görünür değildir ama kullanıcının sistemi benimsemesini doğrudan etkiler.

Generation katmanının bir başka boyutu güvenlik ve sınırlardır. Model yalnızca doğru bilgiyi değil, kurumun izin verdiği biçimde ve sınırlar içinde yanıt vermelidir. Guardrail'ler, istenmeyen içerikleri, kişisel veri sızıntılarını ve prompt injection saldırılarını engeller; bu koruma katmanlarını guardrail nedir ve saldırı yüzeyini prompt injection nedir yazılarında ele alıyoruz. Bir RAG mimarisinde bilgi tabanına giren belgeler bile bir saldırı vektörü olabilir; bu yüzden getirilen içeriğe körü körüne güvenmemek, üretim güvenliğinin temelidir.

Evaluation olmadan bir RAG mimarisini iyileştirmek, gözleri kapalı ok atmaya benzer. "Chunk boyutunu değiştirdim, sanki daha iyi oldu" tarzı öznel izlenimler, sistematik iyileştirmenin düşmanıdır. Ciddi bir RAG mimarisi, her değişikliğin etkisini sayısal olarak ölçen bir evaluation disiplinine dayanır. Değerlendirme, iki katmanda ve mümkünse otomatik olarak yapılır. Dil modeli değerlendirmenin genel çerçevesi için LLM değerlendirme nedir yazısına bakabilirsiniz.

Retrieval Değerlendirme Metrikleri

Birinci katman, "doğru parçalar getirildi mi?" sorusunu ölçer ve modelden bağımsızdır. Başlıca metrikler şunlardır: recall (doğru parçaların ne kadarı aday listesine girdi), precision (getirilen parçaların ne kadarı gerçekten alakalı), MRR (ilk doğru parça ortalama kaçıncı sırada geldi) ve nDCG (sıralamanın kalitesini alaka derecesiyle ağırlıklandıran ölçüt). Bu metrikleri hesaplamak için bir altın küme gerekir: her test sorusu için hangi parçaların doğru cevabı içerdiği önceden işaretlenmiş bir veri kümesi. Retrieval katmanını izole ölçmek, sorunların çoğunun kaynağını doğrudan gösterir.

Generation Değerlendirme Metrikleri

İkinci katman, "getirilen bağlamdan iyi bir yanıt üretildi mi?" sorusunu ölçer. Üç temel boyut vardır: bağlılık (faithfulness) — yanıt yalnızca getirilen bağlama mı dayanıyor, yoksa uyduruyor mu; alaka (relevance) — yanıt kullanıcının sorusunu gerçekten karşılıyor mu; ve doğruluk (correctness) — yanıt altın cevapla uyumlu mu. Bağlılık özellikle kritiktir çünkü halüsinasyonu doğrudan yakalar: getirilen bağlamda olmayan bir iddia, bağlılık ihlalidir. Bu boyutları ölçmenin giderek yaygınlaşan yolu, bir dil modelini hakem olarak kullanmaktır (LLM-as-judge); bir güçlü model, yanıtı ve bağlamı okuyup bağlılık ve alakayı puanlar.

RAG mimarisi evaluation metrikleri: iki katman

Katman	Metrik	Neyi ölçer
Retrieval	Recall / Precision	Doğru parça getirildi mi, gürültü ne kadar
Retrieval	MRR / nDCG	Doğru parça ne kadar üstte, sıralama kalitesi
Generation	Bağlılık (faithfulness)	Yanıt bağlama sadık mı, halüsinasyon var mı
Generation	Alaka / Doğruluk	Soruyu karşılıyor mu, altın cevapla uyumlu mu

Sağlıklı bir evaluation pratiği birkaç ilkeye dayanır. Önce küçük ama temsili bir altın küme oluşturun (gerçek kullanıcı sorularından türetilmiş onlarca soru bile başlangıç için değerlidir). Sonra bir taban çizgisi ölçün ve her değişikliği tek tek, aynı küme üzerinde test edin; aynı anda birden çok değişkeni değiştirmek, hangisinin etki ettiğini gizler. Zamanla altın kümeyi büyütün ve üretimden gelen zor örneklerle zenginleştirin. Evaluation'ı sürekli entegrasyona (CI) bağlamak, bir değişikliğin kaliteyi bozması durumunda erken uyarı verir. Ölçmeden optimize etmek, RAG projelerinin en pahalı ve en yaygın hatasıdır.

Her evaluation'ın temeli bir altın kümedir (gold set): doğru cevabı ve doğru kaynak parçaları önceden işaretlenmiş, temsili bir soru koleksiyonu. Altın küme olmadan retrieval ve generation metrikleri hesaplanamaz; bu yüzden altın kümeyi hazırlamak, bir RAG mimarisi projesinin en yüksek getirili erken yatırımlarından biridir. İyi haber şudur: mükemmel ve büyük bir küme gerekmez; küçük ama gerçekçi bir küme bile taban çizgisi kurmak için yeterlidir.

Altın küme hazırlamanın en sağlıklı kaynağı, gerçek kullanıcı sorularıdır. Bir pilot sırasında toplanan sorular, sistemin gerçek dünyada nasıl kullanılacağını yansıttığı için sentetik sorulardan daha değerlidir. Kullanıcı sorusu henüz yoksa, konu uzmanlarına bilgi tabanındaki her önemli belge için birkaç tipik soru ürettirmek pratik bir başlangıçtır. Her soru için iki şey işaretlenir: hangi belge parçalarının doğru cevabı içerdiği (retrieval değerlendirmesi için) ve ideal yanıtın kendisi (generation değerlendirmesi için).

İyi bir altın küme, kolay soruların yanında zor örnekleri de içermelidir: eş anlamlıların kullanıldığı sorular, birden çok belgeyi birleştiren sorular, nadir terim içeren sorular ve bilgi tabanında yanıtı olmayan sorular. Özellikle son grup — cevabı olmayan sorular — kritiktir; çünkü sistemin "bilmiyorum" diyebilme yeteneğini bu sorularla ölçersiniz. Yanıtı olmayan bir soruya sistem kendinden emin uydurma bir cevap veriyorsa, bu bir bağlılık ihlalidir ve altın küme bunu yakalar.

Altın küme statik bir belge değil, yaşayan bir varlıktır. Üretimde ortaya çıkan başarısız sorular düzenli olarak kümeye eklenmeli, bilgi tabanı değiştikçe işaretlemeler güncellenmelidir. Zamanla büyüyen ve zorlaşan bir altın küme, RAG mimarisinin bir kez ölçülüp bırakılan değil, sürekli iyileşen bir sistem olmasını sağlar. Sentetik veri üretimi bu kümeyi genişletmede yardımcı olabilir ama insan doğrulaması olmadan sentetik altın küme yanıltıcı olabilir; en güvenilir işaretlemeler her zaman insan gözünden geçenlerdir.

Evaluation genellikle çevrimdışı ve test kümeleri üzerinde çalışır; ama üretimde gerçek kullanıcılar, öngörülemeyen sorular sorar. Gözlemlenebilirlik (observability), RAG mimarisinin canlı ortamda nasıl davrandığını görünür kılan katmandır. Bir dil modeli sistemini izlemenin ayrıntısını LLM gözlemlenebilirliği nedir yazısında ele alıyoruz; burada RAG'e özgü boyutlara odaklanıyoruz.

İyi bir gözlemlenebilirlik katmanı, her sorgunun izini (trace) uçtan uca kaydeder: kullanıcının sorusu, üretilen embedding, getirilen aday parçalar ve skorları, reranking sonrası seçilen parçalar, modele giden nihai prompt, modelin yanıtı, gecikme ve token maliyeti. Bu iz, bir yanıt yanlış olduğunda "hata nerede oldu?" sorusunu cevaplamayı mümkün kılar: doğru parça hiç getirilmedi mi, getirildi ama reranking'de mi düştü, yoksa bağlam doğruyken model mi yanlış yorumladı?

İzlenmesi gereken üretim metrikleri hem teknik hem iş odaklıdır. Teknik tarafta: uçtan uca gecikme ve bileşen bazlı dağılımı, retrieval hit oranı, token tüketimi ve maliyet, hata oranları. İş tarafında: kullanıcı memnuniyeti (başparmak yukarı/aşağı), "cevap bulunamadı" oranı, en sık sorulan sorular ve en çok başarısız olan sorular. Özellikle başarısız sorular altın değerindedir; bunlar hem chunking/retrieval iyileştirmeleri için hem de altın kümeyi büyütmek için doğrudan girdi sağlar.

Gözlemlenebilirliğin bir başka rolü kayma (drift) tespitidir. Kullanıcıların soru desenleri zamanla değişir, bilgi tabanı güncellenir ve model sürümleri yenilenir; bu değişiklikler kaliteyi sessizce aşındırabilir. Sürekli izleme, bir kalite düşüşünü kullanıcılar şikayet etmeden önce yakalar. Geri bildirim döngülerini kurmak — kullanıcı işaretlerini toplamak ve düzenli olarak gözden geçirmek — bir RAG mimarisini zamanla iyileşen bir sisteme dönüştürür.

Küçük bir pilot ile binlerce kullanıcıya hizmet veren bir üretim sistemi arasındaki fark, çoğunlukla ölçekleme mühendisliğidir. RAG mimarisi büyüdükçe üç eksende baskı artar: gecikme (kullanıcı ne kadar bekliyor), maliyet (her sorgu ne kadara mal oluyor) ve verimlilik (sistem eşzamanlı yükü kaldırıyor mu). Bu üçü çoğu zaman birbiriyle çelişir ve bilinçli ödünleşim gerektirir.

Gecikme tarafında, bir RAG sorgusunun süresi birkaç adımın toplamıdır: embedding hesaplama, vektör arama, reranking ve generation. Genellikle en yavaş adım generation'dır, ama derin bir aday getirme ve ağır bir reranker de ciddi süre ekleyebilir. Gecikmeyi yönetmenin yolları arasında yanıtı akış (streaming) halinde vermek, aday sayısını ve reranking derinliğini ayarlamak, sık sorulan sorular için önbellekleme yapmak ve embedding'leri önceden hesaplamak yer alır. Anlamsal önbellekleme — benzer sorulara verilen yanıtları yeniden kullanmak — hem gecikmeyi hem maliyeti düşürebilir.

Maliyet tarafında, iki ana kalem embedding/generation için model çağrıları ve vektör veritabanı altyapısıdır. Model maliyeti kullanımla büyür; bu yüzden reranking ile bağlamı daraltmak, gereksiz uzun promptlardan kaçınmak ve doğru boyutta bir model seçmek doğrudan tasarruf sağlar. Her soruya en pahalı modeli koşmak yerine, soruyu sınıflandırıp basit soruları daha küçük modele, karmaşık soruları güçlü modele yönlendirmek (yönlendirme / routing) maliyeti belirgin biçimde optimize edebilir. Bu ekonomiyi anlamak için token nedir yazısındaki token başına maliyet mantığı yol gösterir.

RAG mimarisinde ölçekleme kaldıraçları ve etkileri

Kaldıraç	Gecikmeye etkisi	Maliyete etkisi
Yanıt akışı (streaming)	Algılanan gecikmeyi düşürür	Nötr
Anlamsal önbellek	Tekrar eden sorularda çok düşürür	Model çağrısını azaltır
Reranking ile bağlam daraltma	Az artırır	Token maliyetini düşürür
Model yönlendirme (routing)	Basit sorularda düşürür	Belirgin tasarruf
ANN indeks ayarı	İsabet-hız dengesi	Altyapı maliyetini etkiler

Maliyet ve gecikme yönetiminde sık gözden kaçan bir kaldıraç da indeksleme sıklığı ile tazelik arasındaki ödünleşimdir. Her belge değişikliğinde tüm bilgi tabanını yeniden indekslemek pahalıdır ve gereksizdir; ama hiç güncellememek bayat bilgiye yol açar. Doğru RAG mimarisi, artımlı indekslemeyle yalnızca değişen belgeleri günceller ve tazelik ihtiyacına göre bir yenileme takvimi kurar: hızlı değişen kaynaklar (fiyatlar, stok) sık, kararlı kaynaklar (kılavuzlar, politikalar) seyrek indekslenir. Bu ayrım, hem altyapı maliyetini düşürür hem de kullanıcının her zaman güncel bilgiye dayanmasını sağlar. Ölçekte, indeksleme maliyeti sorgu maliyeti kadar önemli hale gelir ve bilinçli yönetilmezse sessizce büyür.

Ölçeklemenin operasyon boyutu, olgun bir MLOps/LLMOps disiplini gerektirir: sürümleme, otomatik dağıtım, geri alma (rollback), yük testi ve kapasite planlama. Bir RAG mimarisi canlıya alındıktan sonra bakılmayan bir proje değil, sürekli işletilen bir üründür. Bu operasyon disiplinini LLMOps nedir yazısında ele alıyoruz. Ölçekleme kararlarını erken düşünmek, "pilotta harika çalışıyordu ama üretimde çöktü" senaryosunu önler.

Bir RAG mimarisi çoğunlukla kurumun en değerli ve en hassas bilgisine (sözleşmeler, İK belgeleri, müşteri verileri, iç politikalar) erişir. Bu erişim büyük değer üretir ama aynı ölçüde risk taşır. Güvenlik ve uyum, RAG mimarisinin sonradan eklenen bir süsü değil, baştan tasarlanan bir temelidir. Not: bu bölüm bilgilendirme amaçlıdır ve hukuki tavsiye değildir; kurumunuzun özel durumunu hukuk ve uyum birimleriyle değerlendirmelisiniz.

Güvenliğin birinci ayağı erişim kontrolüdür. Bir RAG sisteminde tehlikeli bir varsayım, "bilgi tabanındaki her şey herkese açık" demektir. Doğru tasarım, retrieval'ı kullanıcının yetkisine göre filtreler: her kullanıcı yalnızca görme hakkı olan belgelerden getirilen parçalara dayanan yanıtlar alır. Bu, metadata bazlı filtreleme ile sağlanır ve indeksleme aşamasında her parçaya yetki etiketi eklemeyi gerektirir. Erişim kontrolü olmayan bir RAG mimarisi, tüm kurumsal bilgiyi sızdıran bir kapıya dönüşebilir.

KVKK açısından, RAG mimarisi kişisel veri işliyorsa birkaç yükümlülük öne çıkar: veri işleme envanteri ve hukuki dayanak, gerektiğinde anonimleştirme veya maskeleme, aydınlatma yükümlülüğü, saklama sürelerinin yönetimi ve silme hakkının teknik olarak uygulanabilmesi. KVKK kavramının temeli için KVKK nedir ve uyumlu mimari için KVKK uyumlu yapay zeka nedir yazıları temel oluşturur. Özellikle "unutulma hakkı", RAG'de teknik bir zorluk yaratır: bir kişi verisinin silinmesi, o veriye ait tüm parçaların indeksten de kaldırılmasını gerektirir.

EU AI Act açısından, sistemin kullanım senaryosunun risk sınıfı belirleyicidir. Kullanıcıyla etkileşen bir RAG asistanı için şeffaflık yükümlülükleri (kullanıcının bir yapay zeka ile konuştuğunu bilmesi) öne çıkar; yüksek riskli bir alanda (örneğin işe alım, kredi) kullanılıyorsa yükümlülükler ağırlaşır. Yasanın kapsamını EU AI Act nedir yazısında ele alıyoruz. Uluslararası yönetişim çerçeveleri olan ISO/IEC 42001 (yapay zeka yönetim sistemi) ve NIST AI RMF (risk yönetimi çerçevesi), bir RAG mimarisinin yönetişimini olgunlaştırmak için referans alınabilir.

RAG mimarisinin temel iskeleti her yerde aynı olsa da, ağırlık verilen katmanlar sektöre göre değişir; çünkü her sektörün belge türü, doğruluk hassasiyeti ve uyum yükü farklıdır. Aşağıdaki örnekler, hangi kararın hangi bağlamda öne çıktığını göstermek içindir.

Hukuk ve uyum alanında en kritik boyut, bağlılık ve atıftır. Bir hukuk asistanının uydurma bir madde ya da içtihat üretmesi kabul edilemez; bu yüzden reranking, katı bağlılık kontrolü ve her iddiayı kaynağa bağlama zorunludur. Chunking'de madde ve fıkra sınırlarına saygı gösteren yapı-farkında yaklaşım öne çıkar.

Finans ve bankacılıkta hem tam terim eşleşmesi (ürün kodları, mevzuat maddeleri) hem anlamsal arama gerektiğinden hybrid search neredeyse zorunludur; ayrıca düzenleyici denetlenebilirlik için gözlemlenebilirlik ve loglama ağırlık kazanır. Sağlıkta doğruluk hayatidir ve uyum yükü en ağırdır; burada RAG çoğunlukla bir karar desteği olarak, insan onayıyla birlikte konumlanır.

Müşteri hizmetlerinde öne çıkan boyut gecikme ve ölçektir: yüksek hacimli, eşzamanlı sorgular altında hızlı ve tutarlı yanıt gerekir; anlamsal önbellekleme ve model yönlendirme burada büyük değer üretir. İç bilgi yönetiminde (çalışanların dokümantasyona soru sorması) ise erişim kontrolü ve tazelik öne çıkar; farklı departmanların farklı yetkileri metadata filtreleme ile yönetilir. Tüm bu senaryolarda ortak ders şudur: RAG mimarisinin katmanları evrenseldir, ama her katmana ne kadar yatırım yapılacağı sektörün risk ve değer profiline göre belirlenir.

Bu farkları okumanın pratik bir yolu, her sektör için "yanlış yanıtın maliyeti nedir?" sorusunu sormaktır. Bu maliyet hafif bir rahatsızlıksa (iç bir sıkça sorulan sorular asistanı), hız ve kapsamı önceliklendirebilirsiniz; ama maliyet bir mevzuat ihlali veya bir güvenlik riskiyse (sağlık, finans, hukuk), gecikme pahasına bile olsa bağlılık, kaynak gösterme ve insan denetimini önceliklendirmeniz gerekir. Bu tek soru — yanlış olmanın maliyeti — retrieval derinliğini, reranking katılığını ve modelin yanıt verme ile çekimser kalma arasındaki eşiğini ne kadar muhafazakâr ayarlayacağınızı belirlemelidir. Olgun bir RAG mimarisi her yerde aynı ölçüde iddialı değildir; ait olduğu alanın riskine göre kalibre edilir. Türkiye bağlamında bu kalibrasyon, KVKK ve sektörel düzenlemelerin (örneğin finansta ek yükümlülükler) getirdiği sınırlarla birlikte düşünülmelidir; aynı teknik mimari, farklı düzenleyici ortamlarda farklı ayarlar gerektirir.

Aşağıdaki kontrol listesi, bir RAG mimarisini sıfırdan üretim kalitesine taşımak için pratik bir yol haritasıdır. Her adımı bilinçli geçmek, sonraki adımların üzerine sağlam kurulmasını sağlar; adım atlamak ise sorunu zincirin ilerisine erteler.

Nasıl Yapılır

RAG mimarisi kurulum kontrol listesi

Bir RAG mimarisini pilottan üretime taşımak için adım adım kontrol listesi.

1. 1

   Kullanım senaryosunu daralt

   Geniş 'her şeye cevap veren asistan' yerine dar, ölçülebilir, yüksek değerli bir senaryo seç.

2. 2

   Altın soru-cevap kümesi hazırla

   Gerçek sorulardan türetilmiş, doğru parçaları işaretlenmiş bir test kümesi oluştur.

3. 3

   Veriyi hazırla ve temizle

   Otoriter kaynakları seç, gürültüyü ayıkla, metadata ve yetki etiketi ekle.

4. 4

   Chunking stratejisini seç ve test et

   Yapı-farkında/semantik chunking dene, boyut ve örtüşmeyi evaluation ile ayarla.

5. 5

   Embedding modelini seç

   Dile ve alana uygun, çok dilli bir embedding seç; sorgu-belge tutarlılığını sağla.

6. 6

   Vektör veritabanını kur ve indeksle

   Metadata filtreleme ve hybrid search destekli bir vektör veritabanı seç, ANN indeksini ayarla.

7. 7

   Hybrid search ve reranking ekle

   Dense + sparse retrieval'ı birleştir, üzerine bir reranker uygula.

8. 8

   Prompt ve guardrail katmanını yaz

   Yalnızca bağlama dayan, kaynak göster, bilmiyorsa söyle; güvenlik sınırları koy.

9. 9

   Evaluation ile taban çizgisi ölç

   Retrieval ve generation metriklerini ölç; her iyileştirmeyi tek tek doğrula.

10. 10

    Gözlemlenebilirlik ve erişim kontrolü ekle

    Uçtan uca iz, üretim metrikleri ve yetki bazlı filtreleme kur.

Bu listeyi dar bir pilot üzerinde uygulamak, tüm kurumu tek seferde dönüştürmeye çalışmaktan çok daha akıllıcadır. Küçük ama ölçülen bir RAG mimarisi, hızla güven kazandırır ve sonraki genişlemeler için sağlam bir temel bırakır. Bir kurumsal RAG mimarisini uçtan uca kurmak için yapay zeka danışmanlığı ile başlayabilir, ekibinizin yetkinliğini geliştirmek için kurumsal eğitim seçeneklerine bakabilir ve kavramları derinleştirmek için öğrenme merkezini kullanabilirsiniz.

Deneyimli bir gözle bakıldığında, başarısız RAG mimarisi projeleri benzer hatalarla bozulur. Bu hataların çoğu, görünmez katmanları (retrieval, evaluation) ihmal edip görünür katmana (model, prompt) fazla odaklanmaktan kaynaklanır. En sık görülenler şunlardır:

• Ölçmeden optimize etmek: Evaluation olmadan yapılan her iyileştirme tahmindir. "Daha iyi oldu gibi" hissiyle karar vermek, RAG projelerinin en pahalı hatasıdır. Önce altın küme, sonra taban çizgisi, sonra ölçülü iyileştirme.
• Chunking'i hafife almak: Belgeleri gelişigüzel sabit boyutta kesmek, bağlamı koparır ve retrieval'ı baştan sakatlar. Chunking, modelden önce düşünülmesi gereken bir karardır.
• Yalnızca dense veya yalnızca sparse arama: Tek yönteme bağlı kalmak, ya nadir terimleri ya da anlamı kaçırır. Hybrid search, üretim dayanıklılığı için çoğu zaman şarttır.
• Reranking'i atlamak: İlk getirme doğru parçayı çoğu zaman aday listesine sokar ama üste çıkaramaz; reranking olmadan bu parça gürültü içinde kaybolur.
• Kaynak göstermemek ve 'bilmiyorum' dememek: Atıfsız ve sınırsız üreten bir RAG, halüsinasyonu davet eder ve denetlenemez hale gelir.
• Güncelleme ve tazeliği yönetmemek: Belgeler değiştiğinde indeksi güncellememek, sistemin artık geçersiz bilgiye dayanmasına yol açar; bu sessiz ama ciddi bir hatadır.
• Güvenliği sona bırakmak: Erişim kontrolü ve prompt injection savunması sonradan eklenmeye çalışıldığında hem zor hem eksik olur; baştan tasarlanmalıdır.
• Pilotu olduğu gibi ölçeklemek: Kontrollü bir pilotun kalitesini, gerçek dünyanın dağınık sorgularına ve yüküne olduğu gibi taşımak, gecikme ve isabet sürprizleri üretir.

Bir RAG mimarisinin başarısı, tek bir teknik metrikle değil, teknik ve iş göstergelerini birleştiren bir çerçeveyle ölçülür. Teknik olarak mükemmel ama kimsenin kullanmadığı bir sistem başarısızdır; benimsenmiş ama güvenilmez bir sistem de öyle. Sağlıklı ölçüm bu iki tarafı birlikte okur.

Teknik başarı göstergeleri, evaluation ve gözlemlenebilirlik katmanlarından gelir: retrieval recall ve precision, generation bağlılık ve doğruluk oranı, halüsinasyon oranı, "cevap bulunamadı" oranı, uçtan uca gecikme ve sorgu başına maliyet. Bu göstergeler, sistemin kalitesinin sayısal karnesidir ve zaman içinde bir eğilim olarak izlenmelidir; tek bir ölçüm değil, trend anlamlıdır.

İş başarısı göstergeleri ise değerin gerçekleşip gerçekleşmediğini gösterir: benimseme oranı (hedef kullanıcıların ne kadarı düzenli kullanıyor), kullanıcı memnuniyeti, çözülen sorgu oranı, kazanılan zaman ve azalan yük (örneğin destek ekibine düşen soru sayısındaki değişim). Bu göstergeleri bir taban çizgisiyle karşılaştırmadan "başarılı" demek mümkün değildir. Yapay zeka projelerinde değeri parasal olarak çerçevelemek için genel yatırım getirisi mantığı da yol gösterir.

Her iki tarafı birleştiren pratik yaklaşım, dört katmanlı bir gösterge seti kurmaktır: girdi (kullanım, benimseme), süreç (gecikme, retrieval isabeti), çıktı (çözülen soru, kazanılan zaman) ve sonuç (memnuniyet, risk azaltımı). Bu katmanları birlikte okumak, "sistem neden değer üretiyor ya da üretmiyor?" sorusunu cevaplar. Benimseme yüksek ama memnuniyet düşükse kalite sorunu; kalite yüksek ama benimseme düşükse değişim yönetimi sorunu vardır. RAG mimarisini bir kez kurup unutulan bir proje değil, ölçülüp iyileştirilen bir ürün olarak yönetmek, uzun vadeli başarının anahtarıdır.

Başarı ölçümünün bir başka boyutu, kullanıcı güveninin zaman içindeki seyridir. Bir RAG mimarisi teknik olarak iyi çalışsa bile, kullanıcılar birkaç belirgin yanlış yanıtla karşılaştıktan sonra sisteme güvenmeyi bırakabilir; ve güven bir kez kırıldığında, sistem doğru yanıt verse bile kullanıcı doğrulama ihtiyacı duyar, bu da faydayı azaltır. Bu yüzden erken dönemde birkaç görünür hatadan kaçınmak, ortalama doğruluğu bir puan artırmaktan daha değerli olabilir. Pratik sonuç şudur: bir RAG mimarisini yavaş ama güvenilir başlatmak, hızlı ama tutarsız başlatmaktan neredeyse her zaman daha iyidir. Güven, kaybedilmesi kolay, yeniden kazanılması zor bir varlıktır; ve uzun vadeli benimsemenin gerçek belirleyicisidir.

RAG mimarisi kurarken karşılaşılan bir başka karar, araç ekosistemidir: orkestrasyon çerçeveleri, embedding ve reranker sağlayıcıları, vektör veritabanları, evaluation kütüphaneleri ve gözlemlenebilirlik platformları. Burada ürün adı vermek yerine, doğru araç seçiminin ilkelerine odaklanmak daha kalıcı bir rehber sunar; çünkü araçlar hızla değişir, ilkeler kalıcıdır.

Birinci ilke, çerçeveyi ihtiyaca göre seçmektir. Orkestrasyon çerçeveleri (bileşenleri birbirine bağlayan kütüphaneler) hızlı başlangıç sağlar ama bir soyutlama katmanı ekler; bu katman basit projelerde hızlandırır, karmaşık projelerde ise kontrolü zorlaştırabilir. Çoğu olgun ekip, prototipi bir çerçeveyle hızlıca kurar, sonra üretimde kritik bileşenleri (özellikle retrieval ve prompt) daha fazla kontrol için doğrudan yönetir. Model çağırma protokollerini standartlaştıran yaklaşımları anlamak için MCP nedir yazısı bağlam sunar.

İkinci ilke, kritik bileşenlerde bağımsızlığı korumaktır. Embedding modeli, vektör veritabanı ve dil modeli, bir RAG mimarisinin değiştirilebilir olması gereken parçalarıdır; çünkü bu alanda daha iyi ve daha ucuz seçenekler sürekli çıkar. Mimariyi bu bileşenleri kolayca değiştirebilecek şekilde tasarlamak (arayüzler arkasına soyutlamak), tedarikçi kilidini önler ve gelecekteki iyileştirmeleri ucuzlatır.

Üçüncü ilke, evaluation ve gözlemlenebilirliği ilk günden araç setine katmaktır. Bu katmanları "sonra ekleriz" diye ertelemek, projeyi kör bırakır. Küçük başlayan ama ölçmeyi baştan kuran bir ekip, büyük başlayıp sonradan ölçmeye çalışan bir ekipten neredeyse her zaman daha hızlı ilerler. RAG mimarisi ile daha ileri bir yaklaşım olan graf tabanlı getirmeyi (GraphRAG) karşılaştırmak isterseniz GraphRAG nedir yazısı, bilgi grafiğini retrieval'a katan yaklaşımı ele alır ve bazı senaryolarda klasik RAG mimarisini tamamlar.

RAG mimarisini kurarken sık sorulan bir soru, alternatif ve tamamlayıcı yaklaşımlarla ilişkisidir. En yaygın karşılaştırma fine-tuning iledir. RAG bilgi ekler ve bunu modelden bağımsız, güncellenebilir biçimde yapar; fine-tuning ise modelin davranışını, tonunu ve çıktı formatını kalıcı olarak değiştirir. Sorun "model doğru ve güncel bilgiyi bilmiyor" ise RAG mimarisi doğru cevaptır; sorun "model bilgiyi yanlış biçimde veriyor" ise fine-tuning uygundur. Fine-tuning'in ne olduğunu fine-tuning nedir yazısında ele alıyoruz.

İkisi rakip değil, çoğu zaman tamamlayıcıdır. Olgun bir sistemde RAG bilgiyi getirir; hafif bir fine-tuning ise modeli kurumun tonuna, çıktı şablonuna ve alan diline uydurur. Böylece hem güncel ve doğrulanabilir bilgi (RAG'den) hem de tutarlı biçim (fine-tuning'den) elde edilir. Karar verirken pratik kural şudur: önce RAG mimarisiyle bilgiyi doğru getirmeyi çözün; biçim ve ton hâlâ sorunsa fine-tuning'i ekleyin. Bilgi problemini fine-tuning ile çözmeye çalışmak pahalı ve kırılgan bir yoldur çünkü bilgi her değiştiğinde yeniden eğitim gerekir.

GraphRAG ise klasik RAG mimarisini bir bilgi grafiğiyle zenginleştiren ileri bir yaklaşımdır. Klasik RAG, parçaları birbirinden bağımsız getirir; bu, "bu sözleşmedeki tüm tarafların ilişkisi nedir?" gibi çok parçayı birbirine bağlayan sorularda zayıf kalabilir. GraphRAG, varlıklar ve ilişkiler arasında bir grafik kurarak bu tür bütünsel soruları daha iyi yanıtlar; karşılığında kurulum ve bakım karmaşıklığı artar. Çoğu senaryo için iyi kurulmuş bir klasik RAG mimarisi yeterlidir; GraphRAG, ilişki-yoğun ve çok belgeli akıl yürütme gerektiren özel senaryolarda değer kazanır.

RAG mimarisi nasıl kurulur?

RAG mimarisi iki boru hattı olarak kurulur. Önce çevrimdışı indeksleme hattı: kaynak belgeler toplanır, temizlenir, chunking ile parçalanır, bir embedding modeliyle vektöre çevrilir ve vektör veritabanına indekslenir. Sonra çevrimiçi sorgu hattı: kullanıcı sorusu embedding'e çevrilir, dense/sparse/hybrid search ile ilgili parçalar getirilir, reranking ile en alakalılar seçilir, prompt katmanında bağlama yerleştirilir ve dil modeli yanıtı üretir. Üretim için bunun üzerine evaluation, gözlemlenebilirlik, güvenlik/KVKK ve ölçekleme eklenir. Küçük bir pilotla başlayıp her katmanı ölçerek büyütmek en sağlıklı yoldur.

RAG mimarisinde chunking stratejisi nasıl seçilir?

Chunking stratejisi belge türüne ve sorgu desenine göre seçilir. Başlangıç için sabit boyutlu (örneğin 300-500 token) ve makul örtüşmeli (örneğin %10-20) parçalama pratiktir. Yapılandırılmış belgelerde başlık/paragraf sınırlarına saygı gösteren yapı-farkında chunking; anlamsal bütünlüğün kritik olduğu yerlerde cümle gömmelerine dayanan semantik chunking tercih edilir. Doğru chunking, bir parçanın tek bir soruya tam ve kendi kendine yeten bir yanıt taşımasını hedefler; çok küçük parçalar bağlamı koparır, çok büyük parçalar gürültü ve maliyet ekler. En doğru boyut, evaluation ile ölçülerek bulunur.

Dense, sparse ve hybrid search arasındaki fark nedir?

Dense retrieval, metni embedding vektörlerine çevirip anlamsal yakınlığa göre arar; eş anlamlıları ve yeniden ifade edilmiş soruları yakalamada güçlüdür. Sparse retrieval (örneğin BM25), anahtar kelime örtüşmesine dayanır; nadir terimleri, kod, ürün kodu ve tam eşleşmeleri yakalamada güçlüdür. Hybrid search bu ikisini birleştirir ve skorları harmanlar; böylece hem anlamı hem de tam terimi yakalar. Üretim RAG mimarisinde hybrid search çoğunlukla tek başına dense veya sparse yöntemden daha yüksek ve daha kararlı recall verir.

Reranking neden gereklidir?

İlk getirme aşaması hız için tasarlanır ve genellikle çok sayıda aday parça döndürür; bunların hepsi eşit derecede alakalı değildir. Reranking, bu adayları bir çapraz kodlayıcı (cross-encoder) ile soruya karşı tek tek puanlayarak yeniden sıralar. Çapraz kodlayıcı soru ve parçayı birlikte değerlendirdiği için ilk getirmeden daha isabetlidir ama daha yavaştır; bu yüzden yalnızca ilk aday kümesine uygulanır. Reranking, modele giden bağlamın sinyal-gürültü oranını yükselterek hem yanıt doğruluğunu artırır hem de gereksiz token maliyetini düşürür.

RAG mimarisi nasıl değerlendirilir (evaluation)?

RAG evaluation iki katmanda yapılır. Retrieval katmanında recall, precision, MRR (ortalama karşılıklı sıra) ve nDCG gibi metriklerle "doğru parçalar getirildi mi?" sorusu ölçülür. Generation katmanında bağlılık (faithfulness — yanıt getirilen bağlama sadık mı), alaka (yanıt soruyu karşılıyor mu) ve doğruluk ölçülür; halüsinasyon oranı takip edilir. Değerlendirme, altın standart soru-cevap kümeleri ve giderek yaygınlaşan LLM-as-judge yaklaşımlarıyla otomatikleştirilir. Evaluation olmadan yapılan her iyileştirme tahmine dayanır; ölçmeden optimize etmek RAG projelerinin en yaygın hatasıdır.

RAG mimarisinde hangi vektör veritabanı seçilmeli?

Vektör veritabanı seçimi ürün adından çok gereksinimlere bağlıdır: veri hacmi, sorgu gecikmesi hedefi, metadata filtreleme ihtiyacı, hybrid search desteği, ölçeklenebilirlik ve mevcut altyapıyla uyum. Küçük ve orta ölçekte mevcut ilişkisel veritabanının vektör eklentisi yeterli olabilir; çok büyük ölçekte özel bir vektör veritabanı gecikme ve maliyet avantajı sağlar. Önemli olan indeksleme yöntemi (örneğin HNSW gibi yaklaşık en yakın komşu indeksleri), metadata filtreleme ve hybrid search yeteneğidir. Yanlış kurgulanmış bir indeks, en iyi embedding modelini bile yavaş ve isabetsiz kılar.

RAG ile fine-tuning arasında nasıl seçim yapılır?

RAG bilgi ekler, fine-tuning davranış/biçim değiştirir. Sorun "model doğru ve güncel bilgiyi bilmiyor" ise RAG mimarisi doğru yaklaşımdır; sorun "model bilgiyi yanlış tonda veya biçimde veriyor" ise fine-tuning uygundur. Çoğu kurumsal senaryoda önce RAG denenir çünkü daha hızlı, daha ucuz ve bilgiyi güncel tutmak kolaydır; kaynak gösterme ve doğrulanabilirlik de RAG'in doğal avantajıdır. İkisi birlikte de kullanılabilir: RAG bilgiyi getirir, hafif bir fine-tuning modeli kurumun tonuna ve çıktı formatına uydurur.

RAG mimarisi KVKK ve EU AI Act açısından nasıl kurulmalı?

RAG mimarisi kişisel veya gizli veri içeren belgelerle çalışıyorsa, erişim kontrolü baştan tasarlanmalıdır: her kullanıcı yalnızca yetkili olduğu belgelere erişebilmeli, retrieval bu yetkiye göre filtrelenmelidir. KVKK açısından veri işleme envanteri, anonimleştirme/maskeleme, aydınlatma ve saklama süreleri; EU AI Act açısından ise kullanım senaryosunun risk sınıfı ve şeffaflık yükümlülükleri değerlendirilmelidir. Kaynak gösterme ve loglama, hem denetlenebilirlik hem de güven için gereklidir. Bu bilgilendirme hukuki tavsiye değildir; kurumunuzun özel durumunu hukuk ve uyum birimleriyle değerlendirmelisiniz.

RAG yanıtları neden bazen yanlış olur ve nasıl düzeltilir?

En yaygın kök neden getirme katmanıdır: yanlış veya eksik parça getirildiğinde model doğru bilgiye dayanamaz. Kötü chunking, zayıf embedding, reranking eksikliği ve yalnızca dense veya yalnızca sparse arama kullanmak başlıca nedenlerdir. Düzeltme sırası genellikle şöyledir: önce chunking'i ve embedding modelini gözden geçirin, hybrid search ekleyin, ardından reranking uygulayın, prompt'ta modele yalnızca getirilen bağlama dayanmasını ve bilmiyorsa "bilmiyorum" demesini söyleyin. Her değişikliği evaluation ile ölçün; hangi adımın ne kadar katkı verdiğini görmeden yapılan düzeltmeler çoğu zaman körlemesine kalır.

Küçük bir ekip üretim kalitesinde RAG mimarisini nasıl kurar?

Küçük bir ekip, dar ve yüksek değerli bir kullanım senaryosuyla başlar (örneğin iç dokümantasyon üzerinde soru-cevap). Önce küçük bir altın soru-cevap kümesi hazırlar; sonra basit bir hattı ayağa kaldırır (yapı-farkında chunking, iyi bir çok dilli embedding, hybrid search destekli bir vektör veritabanı, bir reranker ve net bir sistem promptu). Ardından evaluation ile taban çizgisini ölçer ve tek seferde bir değişken değiştirerek iyileştirir. Gözlemlenebilirlik ve erişim kontrolü baştan eklenir. Küçük ama ölçülen bir RAG mimarisi, büyük ama ölçülmeyen bir sistemden her zaman daha güvenilirdir.

Özetle rag mimarisi nasıl kurulur sorusunun cevabı şudur: iki boru hattını doğru kurmak. İndeksleme hattı kaynakları hazırlar, chunking ile parçalar, embedding ile vektöre çevirir ve vektör veritabanına indeksler; sorgu hattı dense/sparse/hybrid search ile getirir, reranking ile en alakalıları öne alır ve dil modeliyle kaynak göstererek yanıt üretir. Bu iskeletin üzerine evaluation (retrieval ve generation metrikleri), gözlemlenebilirlik, güvenlik/KVKK erişim kontrolü ve ölçekleme kararları eklendiğinde, bir demo gerçek bir üretim sistemine dönüşür.

En önemli mesaj şudur: RAG mimarisinin kalitesi bir model seçiminden değil, bir sistem tasarımı disiplininden gelir. Görünmez katmanları — veri, chunking, retrieval, reranking, evaluation — ölçen ve iyileştiren ekipler, güvenilir ve ölçeklenebilir sistemler kurar. Temel kavramlar için RAG nedir, embedding nedir ve vektör veritabanı nedir yazılarına bakabilir; kurumunuza özel bir RAG mimarisi kurmak için yapay zeka danışmanlığı ile başlayabilir, ekip yetkinliği için kurumsal eğitim seçeneklerini inceleyebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz.