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

Özet (TL;DR)

Tek cümlelik cevap: 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.

• RAG, LLM cevaplarını sizin verilerinizle besleyen bir mimaridir — fine-tuning yerine, üretim AI sistemlerinin %80'inin tercih ettiği yaklaşımdır.
• RAG sistemleri 6 katmandan oluşur: yutkulama, parçalama, embedding, dizinleme, getirme, yanıtlama. Her katmanda yanlış karar üretime ulaşır.
• 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.
• Hallucination kontrolü, eval harness olmadan mümkün değildir. RAGAS, DeepEval ve özelleştirilmiş metrikler üretim-öncesi yatırımdır.
• 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.

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.

Tanım

Retrieval-Augmented Generation (RAG)

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.

Ayrıca: RAG, Bilgi-Destekli Üretim

Wikidata: Q123073860

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.

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.

RAG vs Fine-tuning vs Prompt Engineering

Boyut	RAG	Fine-tuning	Prompt Engineering
Veri Güncelliği	Saniyeler içinde	Yeniden eğitim gerekli	Statik
Maliyet	Orta (vektör DB + LLM)	Yüksek (GPU saatleri)	Düşük
Kaynak Gösterme	Doğal	Yok	Yok
Domain Uyumu	Hızlı	Çok güçlü	Sınırlı
Halüsinasyon	Belirgin azalır	Hafif azalır	Değişmez
Ne Zaman	Bilgi tabanı + güncel veri	Stil/format/yapı	MVP, basit görevler

Ü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.

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 → filter: {year: 2024, category: "banka"} + semantic: "ürünler". 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.

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).

Türkçe için Embedding Modelleri (2026 Seçim Rehberi)

Model	Boyut	Türkçe Skoru	Maliyet	Yerel Kullanım
BGE-M3 (BAAI)	1024	Yüksek (multilingual)	Düşük (self-hosted)	✓
E5-mistral-7b-instruct	4096	Yüksek	Yüksek (GPU)	✓
OpenAI text-embedding-3-large	3072	Yüksek	Orta (API)	✗
Cohere embed-multilingual-v3	1024	Orta-yüksek	Orta (API)	✗
jina-embeddings-v3	1024	Orta	Düşük	Hibrit

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.

2026 Vektör DB Karşılaştırması (Kurumsal RAG)

Vektör DB	Yerel Çalışma	Hybrid Search	Maliyet	Türk Bankası Onayı
Qdrant	Tam	Native (sparse + dense)	Düşük (open-source)	✓
Weaviate	Tam	Native	Orta	✓
Milvus	Tam	Native	Orta	✓
Pinecone	Yok	Native	Yüksek (managed)	✗
pgvector (Postgres)	Tam	SQL + HNSW	Çok düşük	✓
Elasticsearch	Tam	Mükemmel BM25	Orta	✓

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).

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.

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.

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."

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.

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.

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.

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.

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.

Kaynaklar

1. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — Lewis et al., NeurIPS · 2020-05-22
2. BGE M3-Embedding: Multi-Lingual, Multi-Functionality, Multi-Granularity — Chen et al., BAAI · 2024-02-05
3. RAGAS: Automated Evaluation of Retrieval Augmented Generation — Es et al., arXiv · 2023-09-26
4. Lost in the Middle: How Language Models Use Long Contexts — Liu et al., arXiv · 2023-07-06
5. Reciprocal Rank Fusion — Cormack, Clarke, Buettcher, SIGIR · 2009
6. Databricks State of Data + AI 2025 — Databricks, Databricks · 2025
7. Qdrant Documentation — Qdrant, Qdrant · 2025
8. LangChain RAG Cookbook — LangChain, LangChain · 2025
9. KVKK - 6698 Sayılı Kanun — T.C. KVKK, Türkiye Cumhuriyeti · 2016-04-07
10. EU Artificial Intelligence Act — European Commission, EU · 2024-03-13

---

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.