# RAG (Retrieval-Augmented Generation) Üretim Rehberi: Türk Şirketleri İçin Uçtan Uca Mimari

> Source: https://sukruyusufkaya.com/blog/rag-uygulama-rehberi-turkiye
> Updated: 2026-08-24T00:37:21.120Z
> Type: blog
> Category: yapay-zeka
**TLDR:** Retrieval-Augmented Generation (RAG) sistemlerinin tasarımı, ölçeklendirilmesi ve KVKK uyumlu üretime alınması için kapsamlı referans rehber. Türkçe embedding modeli seçimi, vektör DB karşılaştırması, chunking stratejileri, hybrid search, re-ranking, hallucination kontrolü, eval harness ve 3 anonim Türk şirketi vaka çalışması ile uçtan uca üretim mimarisi.

<tldr data-summary="[&#34;RAG, LLM cevaplarını sizin verilerinizle besleyen bir mimaridir — fine-tuning yerine, üretim AI sistemlerinin %80&#39;inin tercih ettiği yaklaşımdır.&#34;,&#34;RAG sistemleri 6 katmandan oluşur: yutkulama, parçalama, embedding, dizinleme, getirme, yanıtlama. Her katmanda yanlış karar üretime ulaşır.&#34;,&#34;Türkçe RAG için tek bir doğru kombinasyon yoktur; BGE-M3 + Qdrant + GPT-5/Claude Opus 4.7 bugünkü en kararlı varsayılan başlangıç noktasıdır.&#34;,&#34;Hallucination kontrolü, eval harness olmadan mümkün değildir. RAGAS, DeepEval ve özelleştirilmiş metrikler üretim-öncesi yatırımdır.&#34;,&#34;KVKK uyumu bir tasarım kararıdır, sonradan eklenen bir özellik değildir — anonimleştirme, veri yerleşimi ve cross-border transfer ilk gün belirlenir.&#34;]" data-one-line="RAG, LLM’in sınırlı bilgisini sizin güncel verilerinizle genişleten — fine-tuning gerektirmeden doğruluk, izlenebilirlik ve maliyet kontrolü sağlayan üretim-odaklı bir AI mimarisidir."></tldr>

## 1. RAG Nedir ve Niye Şu An En Önemli Mimari?

LLM'ler ne kadar büyük olursa olsun üç temel sınırla karşılaşır: **(1)** bilgileri eğitim kesim tarihiyle sınırlı (knowledge cutoff), **(2)** şirketinizin özel verilerini bilmezler, **(3)** kaynak göstermezler. **Retrieval-Augmented Generation (RAG)** bu üç sınırı tek bir mimari kararla çözer: LLM'in yanıt vermeden önce ilgili veriyi bir arama katmanından getirip prompt'a iliştirir.

<definition-box data-term="Retrieval-Augmented Generation (RAG)" data-definition="Bir LLM'in yanıt üretmeden önce, sorguya uygun belgeleri harici bir bilgi tabanından (vektör DB veya hibrit arama) getirip prompt'a ekleyen mimari kalıp. Sonuç: model kendi eğitim verisinin dışındaki güncel, özel ve doğrulanabilir bilgilere dayalı yanıt üretebilir." data-also="RAG, Bilgi-Destekli Üretim" data-wikidata="Q123073860"></definition-box>

2026 itibarıyla üretim AI sistemlerinin yaklaşık **%80'i RAG mimarisini kullanır**; bu, fine-tuning'in çok-ötesinde bir tercih oranıdır. Sebep basit: RAG, modelin "bilmediğini bilme" sorununu kısmen çözer, içerik güncellemesini saniyeler içinde mümkün kılar ve denetim izlerini doğal olarak üretir.

<stat-callout data-value="%80" data-context="Kurumsal LLM kullanım vakalarında 2025-2026 döneminde tercih edilen mimari" data-outcome="RAG'dir — fine-tuning ya da agent yapıları RAG katmanının üzerinde inşa edilir, RAG'ın yerine değil." data-source="{&#34;label&#34;:&#34;Databricks State of Data + AI 2025&#34;,&#34;url&#34;:&#34;https://www.databricks.com/resources&#34;,&#34;date&#34;:&#34;2025&#34;}"></stat-callout>

### RAG mi, Fine-tuning mi?

İkisi rakip değil tamamlayıcıdır. **Fine-tuning** modelin *stilini, tonunu, format alışkanlığını* değiştirir; **RAG** ise modelin *bildiği bilgiyi* genişletir. Çoğu üretim sistemi önce RAG ile başlar, gerekirse fine-tuning'i tonu sabitlemek için ekler.

<comparison-table data-caption="RAG vs Fine-tuning vs Prompt Engineering" data-headers="[&#34;Boyut&#34;,&#34;RAG&#34;,&#34;Fine-tuning&#34;,&#34;Prompt Engineering&#34;]" data-rows="[{&#34;feature&#34;:&#34;Veri Güncelliği&#34;,&#34;values&#34;:[&#34;Saniyeler içinde&#34;,&#34;Yeniden eğitim gerekli&#34;,&#34;Statik&#34;]},{&#34;feature&#34;:&#34;Maliyet&#34;,&#34;values&#34;:[&#34;Orta (vektör DB + LLM)&#34;,&#34;Yüksek (GPU saatleri)&#34;,&#34;Düşük&#34;]},{&#34;feature&#34;:&#34;Kaynak Gösterme&#34;,&#34;values&#34;:[&#34;Doğal&#34;,&#34;Yok&#34;,&#34;Yok&#34;]},{&#34;feature&#34;:&#34;Domain Uyumu&#34;,&#34;values&#34;:[&#34;Hızlı&#34;,&#34;Çok güçlü&#34;,&#34;Sınırlı&#34;]},{&#34;feature&#34;:&#34;Halüsinasyon&#34;,&#34;values&#34;:[&#34;Belirgin azalır&#34;,&#34;Hafif azalır&#34;,&#34;Değişmez&#34;]},{&#34;feature&#34;:&#34;Ne Zaman&#34;,&#34;values&#34;:[&#34;Bilgi tabanı + güncel veri&#34;,&#34;Stil/format/yapı&#34;,&#34;MVP, basit görevler&#34;]}]"></comparison-table>

## 2. RAG'ın Anatomisi: Altı Katman

Üretim-kalitesinde RAG sisteminin altı katmanı vardır. Her katmanda alınan zayıf karar, son cevaba kadar yansır.

### 2.1. Yutkulama (Ingestion)

Belgelerin sisteme akışını sağlayan katman. Kaynaklar: PDF'ler, web sayfaları, SharePoint, e-posta, Confluence, Notion, veritabanları, ticket sistemleri. Bu katmanda kritik kararlar: zamanlama (real-time vs batch), kimlik doğrulama, KVKK riski olan kişisel veri filtreleme.

### 2.2. Parçalama (Chunking)

Belgeleri model context window'una sığacak ve anlamlı semantik birimler oluşturacak şekilde böler. Kötü chunking, RAG'ın gizli katilidir.

### 2.3. Gömme (Embedding)

Her chunk'ı yüksek-boyutlu bir vektöre çevirir. Türkçe için doğru embedding modeli seçimi kritik; aşağıda detaylandırıyoruz.

### 2.4. Dizinleme (Indexing)

Vektörleri ve metadata'yı vektör DB'ye yazar. Vektör DB seçimi, ölçeklenme stratejisi ve update mekanizmaları burada belirlenir.

### 2.5. Getirme (Retrieval)

Kullanıcının sorgusu için ilgili chunk'ları bulur. **Hybrid search** (BM25 + vektör) + **re-ranking** ile başarı ciddi şekilde artar.

### 2.6. Yanıtlama (Generation)

LLM, getirilen bağlam ile birlikte cevabı oluşturur. Sistem prompt'u, hallucination dirençli bir tasarımla yazılır; kaynak göstermesi zorunlu kılınır.

## 3. RAG Mimari Kalıpları: Hangisi Sizin İçin?

Tek bir RAG yoktur; problem yapısına göre seçilen 5 ana kalıp vardır.

### 3.1. Naive RAG

En basit form: belge → chunk → embed → retrieve → LLM. MVP ve düşük-stake use-case'ler için yeterli. Üretim için genelde yetersiz.

### 3.2. Hybrid RAG

BM25 (anahtar kelime arama) + vektör arama paralel çalışır, skorlar birleştirilir. **Türkçe sorgular için BM25 katkısı çok değerlidir** — özel isimler, ürün kodları, regülasyon numaraları gibi kesin eşleşmeler vektör aramada zayıf, BM25'te güçlüdür.

### 3.3. RAG-Fusion

Tek soruyu çoklu varyasyona dönüştürür (sorgu genişletme), her birinden retrieval yapar, sonuçları **Reciprocal Rank Fusion (RRF)** ile birleştirir. Karmaşık sorularda recall'u %20-40 artırır.

### 3.4. Self-Query RAG

LLM, kullanıcı sorgusunu önce yapılandırılmış filtre + semantik arama parçalarına ayrıştırır. Örnek: "2024'te yayınlanan banka ürünleri" sorgusu → <code>filter: {year: 2024, category: "banka"} + semantic: "ürünler"</code>. Metadata-zengin veri için kritik.

### 3.5. Agentic RAG

Bir agent, hangi kaynaktan getireceğini, ne zaman getireceğini ve gerekirse çoklu adım sorgu yapacağını otonom karar verir. Multi-document QA, karmaşık raporlama ve karar destek sistemleri için.

<callout-box data-variant="tip" data-title="Pratik Seçim">

%70 vakada **Hybrid RAG + Re-ranker** doğru başlangıç noktasıdır. RAG-Fusion ve Agentic RAG'a, naive sistem üretime alındıktan ve eval skorları stabil olduktan sonra geçin. Aksi halde karmaşıklığı çözmediğiniz yerde artırırsınız.

</callout-box>

## 4. Türkçe için Embedding Modeli Seçimi

Embedding modeli, RAG'ın en alttaki ama en kritik kararıdır — değiştirmek pahalıdır (tüm indeksi yeniden oluşturmak gerekir).

<comparison-table data-caption="Türkçe için Embedding Modelleri (2026 Seçim Rehberi)" data-headers="[&#34;Model&#34;,&#34;Boyut&#34;,&#34;Türkçe Skoru&#34;,&#34;Maliyet&#34;,&#34;Yerel Kullanım&#34;]" data-rows="[{&#34;feature&#34;:&#34;BGE-M3 (BAAI)&#34;,&#34;values&#34;:[&#34;1024&#34;,&#34;Yüksek (multilingual)&#34;,&#34;Düşük (self-hosted)&#34;,true]},{&#34;feature&#34;:&#34;E5-mistral-7b-instruct&#34;,&#34;values&#34;:[&#34;4096&#34;,&#34;Yüksek&#34;,&#34;Yüksek (GPU)&#34;,true]},{&#34;feature&#34;:&#34;OpenAI text-embedding-3-large&#34;,&#34;values&#34;:[&#34;3072&#34;,&#34;Yüksek&#34;,&#34;Orta (API)&#34;,false]},{&#34;feature&#34;:&#34;Cohere embed-multilingual-v3&#34;,&#34;values&#34;:[&#34;1024&#34;,&#34;Orta-yüksek&#34;,&#34;Orta (API)&#34;,false]},{&#34;feature&#34;:&#34;jina-embeddings-v3&#34;,&#34;values&#34;:[&#34;1024&#34;,&#34;Orta&#34;,&#34;Düşük&#34;,&#34;Hibrit&#34;]}]"></comparison-table>

**Pratik tavsiye.** 2026'da Türkçe RAG için en kararlı varsayılan **BGE-M3** (1024 boyut, multilingual, self-hosted, ücretsiz). Veri hassasiyeti çok düşükse **OpenAI text-embedding-3-large** API tercih edilebilir. Yüksek hassasiyetli kurumlarda **BGE-M3 self-hosted + Türkçe fine-tune** ideal.

### 4.1. Embedding Boyutu ve Maliyet

Boyut arttıkça arama kalitesi marjinal artar ama vektör DB maliyeti doğrusal büyür. 1024 boyut çoğu kurumsal RAG için **yeterli ve maliyet-optimum**.

## 5. Vektör Veritabanı Seçimi

<comparison-table data-caption="2026 Vektör DB Karşılaştırması (Kurumsal RAG)" data-headers="[&#34;Vektör DB&#34;,&#34;Yerel Çalışma&#34;,&#34;Hybrid Search&#34;,&#34;Maliyet&#34;,&#34;Türk Bankası Onayı&#34;]" data-rows="[{&#34;feature&#34;:&#34;Qdrant&#34;,&#34;values&#34;:[&#34;Tam&#34;,&#34;Native (sparse + dense)&#34;,&#34;Düşük (open-source)&#34;,true]},{&#34;feature&#34;:&#34;Weaviate&#34;,&#34;values&#34;:[&#34;Tam&#34;,&#34;Native&#34;,&#34;Orta&#34;,true]},{&#34;feature&#34;:&#34;Milvus&#34;,&#34;values&#34;:[&#34;Tam&#34;,&#34;Native&#34;,&#34;Orta&#34;,true]},{&#34;feature&#34;:&#34;Pinecone&#34;,&#34;values&#34;:[&#34;Yok&#34;,&#34;Native&#34;,&#34;Yüksek (managed)&#34;,false]},{&#34;feature&#34;:&#34;pgvector (Postgres)&#34;,&#34;values&#34;:[&#34;Tam&#34;,&#34;SQL + HNSW&#34;,&#34;Çok düşük&#34;,true]},{&#34;feature&#34;:&#34;Elasticsearch&#34;,&#34;values&#34;:[&#34;Tam&#34;,&#34;Mükemmel BM25&#34;,&#34;Orta&#34;,true]}]"></comparison-table>

**Pratik tavsiye.** KVKK + BDDK kısıtlı sektörler için **Qdrant on-prem** veya **pgvector** (mevcut Postgres'inizde). Hızlı MVP için **Pinecone** (cloud, ama Türk bankaları için tipik olarak veto edilir).

## 6. Chunking Stratejileri: RAG'ın Gizli Katili

Bir RAG sisteminin başarısını belirleyen en önemli karar — sıklıkla yetersiz dikkatle yapılan — **chunking** kararıdır.

### Sabit Boyut (Fixed-size)

Her chunk N token (örn. 512). Basit ama anlamlı sınırları keser; özellikle Türkçe gibi morfolojik dilde paragraf yapısını bozar.

### Tümce-Tabanlı (Sentence-aware)

Doğal cümle sınırlarında böler. spaCy veya nltk Türkçe destekli paketleri kullanılabilir.

### Yapı-Tabanlı (Structural)

Belgenin başlık hiyerarşisini takip eder (Markdown headers, PDF outline). Hukuki belgeler, kullanım kılavuzları ve regülatif dokümanlar için ideal.

### Semantik (Semantic)

Embedding benzerliği eşiğine göre döker. Yüksek kalite ama hesaplama maliyetli.

### Overlap (Bindirme)

Chunk'lar arasında 10-20% bindirme, bağlam kaybını azaltır. Hemen her senaryoda öneriyorum.

<callout-box data-variant="answer" data-title="Türk Hukuk Belgesi İçin Chunking">

Türk hukuki belgelerinde (kanun, yönetmelik, sözleşme) **yapı-tabanlı chunking + 15% overlap** en iyi sonuç verir. "Madde" sınırlarını korumak, mahkeme yorumunun bir maddenin tamamına atıfta bulunma yapısıyla uyumludur. Maddeleri ortadan bölmek, hallucination'a açık kapı bırakır.

</callout-box>

## 7. Hybrid Search ve Re-ranking

### Hybrid Search

Vektör araması anlam yakınlığını yakalar; BM25 tam eşleşmeleri yakalar. **İkisini paralel çalıştırıp Reciprocal Rank Fusion (RRF) ile birleştirmek**, vakaların büyük çoğunluğunda saf vektör aramadan %15-30 daha yüksek recall verir.

### Re-ranking

İlk getirme 50-100 sonuç döndürür; **cross-encoder re-ranker** bunları LLM kalitesinde yeniden sıralar. Önerilen modeller: **bge-reranker-v2-m3** (multilingual), **Cohere rerank-v3**, **Voyage rerank-2**. Maliyet düşük (her sorguda ~50ms eklenti), getiri yüksek.

<stat-callout data-value="2x" data-context="Türkçe bir kurumsal RAG sisteminde, hybrid search + re-ranker kombinasyonu" data-outcome="naive vektör aramaya kıyasla cevap kalitesini iki katına çıkarabilir (eval skoruna göre)." data-source="{&#34;label&#34;:&#34;İç Vaka Çalışması, Türk Bankası&#34;,&#34;url&#34;:&#34;https://sukruyusufkaya.com/blog/rag-uygulama-rehberi-turkiye&#34;,&#34;date&#34;:&#34;2025&#34;}"></stat-callout>

## 8. LLM Katmanı ve Prompt Tasarımı

### Model Seçimi

- **Düşük gecikme + maliyet:** GPT-4o-mini, Claude Haiku 4.5, Gemini Flash 3
- **Yüksek kalite:** GPT-5, Claude Opus 4.7, Gemini 3
- **Açık kaynak:** Llama 4 70B, Qwen 2.5, DeepSeek V3 (yerelde self-hosted)

### Sistem Prompt'u Şablonu

Üretim RAG'da sistem prompt'u şu davranışları kilitlemelidir:

1. "Sadece sağlanan bağlamı kullan, dış bilgi ekleme."
2. "Cevabın hangi kaynağa dayandığını belirt (Kaynak: doc_id)."
3. "Bağlamda yanıt yoksa, 'Bilmiyorum' de — uydurma."
4. "Cevap dili kullanıcı sorgusunun dilidir."

## 9. Hallucination Kontrolü ve Eval Harness

Hallucination, RAG'ı üretimde yıkan en yaygın problemdir. **Ölçemediğin halüsinasyonu kontrol edemezsin.**

### Temel Metrikler

- **Faithfulness:** Cevap, getirilen bağlama sadık mı?
- **Context Precision:** Getirilen chunk'lar gerçekten alakalı mı?
- **Context Recall:** Cevap için gerekli tüm bağlam getirildi mi?
- **Answer Relevance:** Cevap sorguya doğrudan yanıt veriyor mu?

### Eval Araçları

**RAGAS** (en yaygın açık kaynak), **DeepEval**, **TruLens**, **Langfuse evaluations**. Üretim-öncesi minimum 100 sorudan oluşan bir eval seti zorunludur.

<callout-box data-variant="warning" data-title="Eval Olmadan Üretime Çıkmayın">

Türk şirketlerinin %62'sinin POC'leri üretime alamamasının temel sebeplerinden biri **eval altyapısı olmadan ölçeklenmeye çalışmaktır**. Eval harness olmadan üretim, kullanıcıların hallucination'ı raporlamasını beklemektir — bu da marka için pahalıdır.

</callout-box>

## 10. KVKK Uyumlu RAG Mimarisi

Türkiye'de RAG'ın **birinci tasarım kararı** KVKK uyumudur — sonradan eklenmez.

### KVKK Riskini Azaltan 5 Karar

1. **Veri Yerleşimi.** Vektör DB ve embedding hizmeti Türkiye veya AB'de hosted.
2. **Anonimleştirme Katmanı.** Yutkulama sırasında kişisel veriler (TC kimlik no, ad-soyad, telefon, e-posta, adres) PII detection ile maskelenir.
3. **Açık Rıza & Amaç Sınırlaması.** Kullanıcılarınızdan toplanan verilerin AI'da işleneceği bilgilendirme metninde yer almalı.
4. **Cross-border Transfer Kontrolü.** OpenAI/Anthropic cloud çağrılarında kişisel veri gönderilmediği teyit edilir.
5. **Audit Log.** Her RAG sorgusu (sorgu, getirilen chunk ID'leri, üretilen cevap) denetim için saklanır.

## 11. Vaka Çalışmaları (Anonim)

### Vaka 1 — Türk Bankası: Müşteri Hizmetleri RAG

**Problem.** Çağrı merkezi temsilcilerinin müşteri sorularına 8-15 dakika içinde doğru cevap vermesi gerekiyor; ürün kataloğu, kampanya kuralları, regülatif değişiklikler haftalık güncelleniyor.

**Çözüm.** Hybrid RAG (BGE-M3 + Qdrant on-prem + BM25). Her sorguda 50 chunk getirildi, BGE re-ranker ile top-5'e indirildi, GPT-5 EU instance üzerinden yanıt. Anonimleştirme katmanı tüm müşteri verilerini maskeleyip vektörlemeden önce filtreliyor.

**Sonuç.** Temsilci cevap süresi 12 dk → 3 dk. Çağrı çözme oranı %18 arttı. RAG sistemi MAU 6.000 temsilcide kullanılıyor.

### Vaka 2 — Hukuk Bürosu: Sözleşme Analizi

**Problem.** Avukatların sözleşmedeki risk maddelerini, emsal davaları ve regülatif değişiklikleri saatler içinde toplayıp özet rapor üretmesi gerekiyor.

**Çözüm.** Yapı-tabanlı chunking (Madde başına), self-query RAG (filtre: kanun türü, yıl, mahkeme). Re-ranker olarak Cohere rerank-v3. LLM: Claude Opus 4.7 (1M context, uzun sözleşmeler için).

**Sonuç.** Sözleşme analiz süresi 4 saat → 35 dakika. Avukatlar üretim-final cevabı doğrudan değil, **kaynak gösterimi ile** alıyor — bu, hukuk profesyonellerinde güven sağladı.

### Vaka 3 — E-Ticaret Platformu: Ürün Sorgu Asistanı

**Problem.** Müşteri "kış için su geçirmez, 3000 TL altı, kadın bot" gibi yapılandırılmamış sorgular yapıyor; klasik filtre arayüzü yetersiz.

**Çözüm.** Self-query RAG + ürün metadata filtreleri. Embedding: jina-v3 (e-ticaret odaklı multilingual). Re-ranking: bge-reranker. Yanıt LLM: GPT-5.

**Sonuç.** Ürün sayfası dönüşüm oranı %23 arttı. Müşteri sorgu başına average 1.4 chat turu. Üretim trafiği günlük 80.000 sorgu.

## 12. Üretim Endişeleri

### Gecikme (Latency)

Tipik hedef: <2 saniye p50, <5 saniye p95. Optimizasyonlar: cache (sorgu + cevap), streaming, paralel retrieval.

### Maliyet

Maliyet üç katmandan oluşur: embedding (one-time + yenileme), vektör DB (storage + RAM), LLM (token başına). Tipik kurumsal RAG: aylık $1.500-$15.000 (10K-100K sorgu).

### Observability

Her sorguda izleyin: latency, getirilen chunk skorları, LLM token kullanımı, eval skoru. Araçlar: **Langfuse**, **Helicone**, **Arize Phoenix**.

## 13. Sıkça Sorulan Sorular

<callout-box data-variant="answer" data-title="RAG mı, fine-tuning mi yapmalıyım?">

Çoğunlukla **önce RAG** ile başlamalı, gerekirse fine-tuning'i tonu/formatı sabitlemek için eklemelisin. Bilgi tabanı + güncel veri içeren her use-case için RAG; stil/format sabitleyici görevler için fine-tuning.

</callout-box>

<callout-box data-variant="answer" data-title="Hangi vektör DB'yi seçmeliyim?">

Türkiye'de KVKK + BDDK kısıtlı sektörler için **Qdrant on-prem** veya **pgvector** (mevcut Postgres). Cloud kabul edilebilirse **Qdrant Cloud** veya **Weaviate Cloud**. Pinecone teknik olarak iyi ama Türk bankaları için tipik olarak veto edilir.

</callout-box>

<callout-box data-variant="answer" data-title="Türkçe için OpenAI embedding mi BGE-M3 mü?">

**BGE-M3** Türkçe RAG için 2026'nın en kararlı varsayılan tercihidir — self-hosted, ücretsiz, multilingual, KVKK dostu. Veri hassasiyeti çok düşükse OpenAI text-embedding-3-large alternatiftir. Karar maliyet ve veri yerleşimine bağlıdır.

</callout-box>

<callout-box data-variant="answer" data-title="Hallucination'ı nasıl azaltırım?">

Beş katmanda mücadele edilir: **(1)** Hybrid search + re-ranker, **(2)** Kaynak gösterimi zorunlu sistem prompt'u, **(3)** "Bilmiyorum" cevabı verilebilir sistem talimatı, **(4)** RAGAS faithfulness eval'i ile sürekli izleme, **(5)** İnsan-onaylı feedback döngüsü.

</callout-box>

<callout-box data-variant="answer" data-title="RAG üretimi ne kadar sürer?">

Tipik bir orta-karmaşıklık kurumsal RAG: **MVP 4-6 hafta, üretim sertleştirme 2-3 ay** (eval harness, observability, KVKK uyum, security review). Toplam: 3-5 ay.

</callout-box>

<callout-box data-variant="answer" data-title="LLM olarak hangisini seçmeliyim?">

**Yüksek kalite + uzun bağlam:** Claude Opus 4.7 (1M context); **OpenAI ekosistemi:** GPT-5; **Düşük maliyet + iyi yeterlilik:** Claude Haiku 4.5 veya GPT-4o-mini; **Self-hosted gerekli:** Llama 4 70B veya Qwen 2.5. Karar maliyet, gecikme ve veri yerleşimine bağlıdır.

</callout-box>

<callout-box data-variant="answer" data-title="RAG sistemim yavaş, nasıl hızlandırırım?">

Optimizasyon sırası: **(1)** Sorgu + cevap cache (en yaygın kazanım), **(2)** Streaming (algılanan gecikmeyi yarıya indirir), **(3)** Vektör DB index türü (HNSW vs IVF), **(4)** Re-ranker'ı top-50 yerine top-20'ye uygula, **(5)** LLM'i daha küçük modelle değiştir, eval'i izle.

</callout-box>

<callout-box data-variant="answer" data-title="Multi-tenant RAG nasıl yapılır?">

Üç pattern: **(1)** Tek vektör DB + metadata filtre (en yaygın), **(2)** Tenant başına ayrı collection (orta), **(3)** Tenant başına ayrı vektör DB instance (en yüksek izolasyon, en pahalı). KVKK riski yüksekse pattern 3, değilse pattern 1.

</callout-box>

## 14. Bir Sonraki Adım

RAG sisteminizi tasarlamak veya mevcut bir sistemi üretim kalitesine taşımak için:

1. **Mimari atölye.** Use-case, veri kaynakları, gereksinimler, KVKK riski 4 saatlik bir oturumda netleşir; çıktı: hedef RAG mimari diyagramı ve 8-12 haftalık MVP planı.
2. **Eval harness kurulumu.** Mevcut RAG'ınızın faithfulness, recall, precision skorlarını ölçeriz; iyileştirme yol haritası çıkartırız.
3. **Production audit.** Yayında bir RAG sisteminiz varsa hallucination, gecikme, maliyet ve KVKK uyumu için 360 derece denetim.

İletişim için site üzerindeki contact formu kullanılabilir.

<references-list data-items="[{&#34;title&#34;:&#34;Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks&#34;,&#34;url&#34;:&#34;https://arxiv.org/abs/2005.11401&#34;,&#34;author&#34;:&#34;Lewis et al.&#34;,&#34;publishedAt&#34;:&#34;2020-05-22&#34;,&#34;publisher&#34;:&#34;NeurIPS&#34;},{&#34;title&#34;:&#34;BGE M3-Embedding: Multi-Lingual, Multi-Functionality, Multi-Granularity&#34;,&#34;url&#34;:&#34;https://arxiv.org/abs/2402.03216&#34;,&#34;author&#34;:&#34;Chen et al.&#34;,&#34;publishedAt&#34;:&#34;2024-02-05&#34;,&#34;publisher&#34;:&#34;BAAI&#34;},{&#34;title&#34;:&#34;RAGAS: Automated Evaluation of Retrieval Augmented Generation&#34;,&#34;url&#34;:&#34;https://arxiv.org/abs/2309.15217&#34;,&#34;author&#34;:&#34;Es et al.&#34;,&#34;publishedAt&#34;:&#34;2023-09-26&#34;,&#34;publisher&#34;:&#34;arXiv&#34;},{&#34;title&#34;:&#34;Lost in the Middle: How Language Models Use Long Contexts&#34;,&#34;url&#34;:&#34;https://arxiv.org/abs/2307.03172&#34;,&#34;author&#34;:&#34;Liu et al.&#34;,&#34;publishedAt&#34;:&#34;2023-07-06&#34;,&#34;publisher&#34;:&#34;arXiv&#34;},{&#34;title&#34;:&#34;Reciprocal Rank Fusion&#34;,&#34;url&#34;:&#34;https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf&#34;,&#34;author&#34;:&#34;Cormack, Clarke, Buettcher&#34;,&#34;publishedAt&#34;:&#34;2009&#34;,&#34;publisher&#34;:&#34;SIGIR&#34;},{&#34;title&#34;:&#34;Databricks State of Data + AI 2025&#34;,&#34;url&#34;:&#34;https://www.databricks.com/resources&#34;,&#34;author&#34;:&#34;Databricks&#34;,&#34;publishedAt&#34;:&#34;2025&#34;,&#34;publisher&#34;:&#34;Databricks&#34;},{&#34;title&#34;:&#34;Qdrant Documentation&#34;,&#34;url&#34;:&#34;https://qdrant.tech/documentation/&#34;,&#34;author&#34;:&#34;Qdrant&#34;,&#34;publishedAt&#34;:&#34;2025&#34;,&#34;publisher&#34;:&#34;Qdrant&#34;},{&#34;title&#34;:&#34;LangChain RAG Cookbook&#34;,&#34;url&#34;:&#34;https://python.langchain.com/docs/tutorials/rag/&#34;,&#34;author&#34;:&#34;LangChain&#34;,&#34;publishedAt&#34;:&#34;2025&#34;,&#34;publisher&#34;:&#34;LangChain&#34;},{&#34;title&#34;:&#34;KVKK - 6698 Sayılı Kanun&#34;,&#34;url&#34;:&#34;https://www.kvkk.gov.tr/&#34;,&#34;author&#34;:&#34;T.C. KVKK&#34;,&#34;publishedAt&#34;:&#34;2016-04-07&#34;,&#34;publisher&#34;:&#34;Türkiye Cumhuriyeti&#34;},{&#34;title&#34;:&#34;EU Artificial Intelligence Act&#34;,&#34;url&#34;:&#34;https://artificialintelligenceact.eu/&#34;,&#34;author&#34;:&#34;European Commission&#34;,&#34;publishedAt&#34;:&#34;2024-03-13&#34;,&#34;publisher&#34;:&#34;EU&#34;}]"></references-list>

---

Bu rehber yaşayan bir belgedir; RAG ekosistemi (embedding modelleri, vektör DB'ler, eval araçları) her çeyrek değiştiği için **çeyreklik olarak güncellenmektedir**.