Kurumsal RAG Mimarisi: Vector DB, Chunking ve Değerlendirme Rehberi

RAG (Retrieval-Augmented Generation) son üç yılda kurumsal AI projelerinin baskın mimarisi haline geldi. KVKK uyumu, hassas veri yönetimi, kurum-içi bilgi tabanlarıyla çalışma gereksinimleri açık modelleri fine-tune etmekten çok daha pratik bir yol açtı: temel modeli olduğu gibi bırak, kurumun belgelerini çağrı anında modele besle, cevap ürettir. Slogan basit; uygulama disiplinsizliği projeleri çürütüyor. Üretime giden RAG ile demo amaçlı RAG arasındaki fark mimari kalitedir — vector DB seçiminden chunking stratejisine, hybrid search'ten reranker katmanına, evaluation framework'ünden production monitoring'e kadar her katman ölçülmüş ve test edilmiş olmak zorundadır.

Bizim RAG sistem mühendisliği ve vector database mühendisliği hizmetlerimiz kapsamında son 18 ayda 12 kurumsal RAG projesinde çalıştık ve kendi AIGENCY v4 platformumuzu RAG-yoğun mimari ile işletiyoruz. Bu yazıda kurumsal RAG mimarisinin yedi kritik kararını sırayla anlatıyoruz: doc store seçimi, chunking stratejisi, embedding model, hybrid search, reranker katmanı, evaluation framework ve production monitoring.

1. Stratejik karar — RAG mı, fine-tuning mi, hibrit mi?

İlk soru "RAG kullanalım" değil — "bu problem için RAG doğru araç mı?" olmalı. Üç olası yaklaşım var:

• Pure RAG — temel model değişmez, her sorgu için kurum belgeleri çağrı anında çekilir. Veri sık güncellenen, audit gerektiren, izleme şart olan senaryolar için ideal (hukuk, müşteri destek, kurumsal bilgi tabanı).
• Fine-tuning — belirli bir ton, format veya alan-özgü görev için temel model özelleştirilir. Sabit ve dar görevler için iyi (medikal raporlama, kod stili dönüşümü, ürün açıklaması üretimi).
• Hibrit (RAG + fine-tuning) — fine-tuned model temel knowledge tutar (alan terminolojisi, format), RAG ise sürekli güncellenen veriyi sağlar. Karmaşık ve yüksek hacimli kurumsal senaryolarda baskın yaklaşım.

Karar testi: "Bilgi günlük güncelleniyorsa RAG; davranış/format öğrenilmesi gerekiyorsa fine-tuning; ikisi de gerekiyorsa hibrit." Kurumsal projelerin yaklaşık %70'i pure RAG ile başlıyor; gerçek production volume'una ulaşınca yaklaşık yarısı hibrit'e geçiyor. Saf fine-tuning kurumsal kullanımda azınlık çünkü her bilgi değişikliğinde yeniden eğitim maliyetli ve audit zor.

İkinci pratik nokta: RAG silver bullet değil. Yanlış uygulandığında hallucination oranı artar (LLM ilgisiz belgeleri "kaynak" sayar), latency yükselir, maliyet patlar. Doğru uygulandığında ise modelin "bilmiyorum" demesi gereken yerde gerçekten bilmiyorum demesini, bildiği yerde de kaynak göstererek cevap vermesini sağlar. Fark mimari disipline bağlı.

2. Doc store seçimi — pgvector vs Qdrant vs Milvus vs yönetilen servisler

Vector database seçimi RAG mimarisinin iskelet kararıdır; sonradan değiştirmek migration acısı ve aylık sıkıntı demektir. Üç ana kategori:

PostgreSQL + pgvector — mevcut PostgreSQL üstüne eklenti olarak yüklenir. Tek veritabanı, tek backup, tek operasyon. 100K-500K embedding ölçeği için pratik. Avantaj: SQL ile metadata filter, transactional consistency, ekibinizin zaten bildiği araç. Dezavantaj: 1M+ scale'de HNSW indeksleme yavaşlar, filtre + vector search kombinasyonu özel tuning ister. Bizim önerimiz: küçük-orta kurumsal projeler için default seçim.

Qdrant — Rust ile yazılmış, vector-first veritabanı. HNSW indeks performansı çok iyi, payload filter native olarak destekli, REST + gRPC API. 1M-50M embedding sweet spot'u. Self-hosted veya managed cloud. Kurumsal projelerde 2023'ten beri popülerleşti. Bizim AIGENCY pipeline'ında 8M embedding'i Qdrant cluster'da tutuyoruz.

Milvus — büyük ölçek için (10M-1B+ embedding) tasarlanmış, distributed mimari. Operasyon yükü yüksek (Kubernetes, etcd, MinIO bileşenleri); ekibinizde dedike DevOps yoksa zor. Avantaj: GPU-accelerated index, IVF/HNSW/DiskANN gibi gelişmiş indeks seçenekleri.

Pinecone / Weaviate Cloud / Zilliz Cloud — yönetilen servisler. Operasyonel yük yok, dakikalar içinde production-ready. Maliyet: aylık 70-1.500 USD aralığı küçük-orta yük için, kurumsal SLA için 3.000-15.000 USD. KVKK perspektifinden veri lokasyonu kritik — Pinecone EU region, Weaviate self-hosted veya AWS Frankfurt seçeneği var; sözleşme DPA (Data Processing Agreement) zorunlu.

Karar matrisi:

Kriter	pgvector	Qdrant	Milvus	Managed
Sweet spot ölçek	<500K	1M-50M	10M-1B+	Her ölçek
Operasyon yükü	Düşük	Orta	Yüksek	Yok
Aylık altyapı maliyeti	TRY 500-3.000	TRY 3.000-15.000	TRY 10.000-40.000	USD 70-15.000
KVKK kontrol	Tam	Tam	Tam	Sözleşmeye bağlı
Hybrid search	Manual	Native	Native	Native
Latency p95	30-100ms	10-50ms	5-30ms	20-100ms

Pratik öneri: pgvector ile başlayın. 500K embedding sınırına yaklaştığınızda Qdrant'a göç planlayın. 10M+ üstünde Milvus veya yönetilen servis düşünün. "Önden büyük seçim" yapmaya çalışmak çoğu projede operasyon yorgunluğu ve gereksiz maliyet yaratır.

3. Chunking stratejisi — sabit boyut yetmiyor

RAG kalitesinin en kritik tek faktörü chunking stratejisidir. Hatalı chunk'lar dünyada en iyi embedding modelini bile boşa çıkarır. Üç temel pattern:

Fixed-size chunking — belge sabit token sayısına bölünür (örnek: 500 token, %15 overlap). En basit, en hızlı; serbest metin (e-posta, sohbet log) için kabul edilebilir. Dezavantaj: paragraf ortasında, cümle ortasında kesim olabilir; semantic boundary kayar.

Structure-aware chunking — belge yapısına göre bölünür: Markdown başlığa göre (#, ##), HTML section/article tag'ine göre, PDF'te font değişikliği veya bullet point'e göre. Teknik doküman, hukuki metin, ürün spec'i için 2-3 kat daha iyi recall verir. Implementation: Unstructured.io, LlamaIndex node parsers, LangChain text splitters kütüphaneleri hazır parserlar sunar.

Semantic chunking — embedding-aware bölme; iki ardışık cümlenin embedding cosine distance'ı bir eşiği aşınca yeni chunk başlatılır. En sofistike ama hesap-yoğun (her belge için ekstra embedding pass'i). Karmaşık ve uzun metin için (akademik makale, rapor) gerçek değer üretir.

Optimum chunk boyutu domain-bağımlı:

Belge tipi	Önerilen chunk	Overlap	Strateji
Sözleşme, hukuki metin	600-900 token	%20	Structure-aware (madde/fıkra)
Teknik dokümantasyon	400-600 token	%15	Structure-aware (başlık)
Müşteri destek FAQ	200-400 token	%10	Q-A bütünü tek chunk
E-posta, sohbet log	300-500 token	%15	Fixed + sliding window
Akademik makale	500-800 token	%20	Semantic
Kod dosyası	Fonksiyon bütünü	0	AST-aware (Tree-sitter)

Bizim AIGENCY pipeline'ında doc-type classifier önce belgeyi sınıflandırıyor (sözleşme / e-posta / FAQ / log / makale), sonra tipine özel chunker çalıştırıyor. Bu yaklaşım tek-tip fixed chunking'e göre top-5 recall'u %35 yükseltti.

Üçüncü pratik nokta: metadata zenginleştirme. Her chunk'a sadece text değil; doc title, section heading, document type, source URL, language, last_updated tarihi, author gibi metadata ekleyin. Retrieval aşamasında filter (örnek: "sadece son 6 ayın belgelerinden"), generation aşamasında source attribution için bu metadata altın değerinde.

4. Embedding model — multilingual, dense, sparse, hibrit

Embedding modelin kalitesi retrieval kalitesinin üst tavanıdır. Yanlış model ile en iyi chunking bile düşük recall verir. 2026 itibariyle dört pratik aile:

OpenAI text-embedding-3-large — 3072 boyut, hem İngilizce hem Türkçe + Arapça'da güçlü, query başına ~0.00013 USD. Production'da popüler ama her sorgu OpenAI'ya gider — KVKK perspektifinden veri lokasyonu sorunu yaratabilir, sözleşme DPA gerekir.

Cohere embed-multilingual-v3 — 1024 boyut, 100+ dil; Türkçe ve Arapça'da OpenAI'dan biraz zayıf ama yine güçlü. Cohere'in EU region offering'i KVKK için avantaj. Maliyet OpenAI ile yakın.

Open-source: BGE-M3, mE5-large, multilingual-MiniLM — self-hosted, GPU üstünde çalışır. BGE-M3 hem dense hem sparse hem multi-vector mode'da çalışabilir (Cohere'in patentli yaklaşımına benzer). Avantaj: tam KVKK kontrol, no per-query cost, fine-tune edebilirsiniz. Dezavantaj: GPU operasyon yükü, latency ham OpenAI/Cohere'den 2-5 kat yüksek olabilir.

Domain-specific fine-tuned — kurum kendi corpus'unda BGE veya E5 üzerinde contrastive fine-tuning yapar. 5K-50K query-positive_doc çifti ile 1-3 epoch eğitim recall'u %10-25 artırır. Hukuk, finans, medikal gibi alan-özgü dil için gerçek değer var.

Pratik öneri: pilot ve PoC için OpenAI veya Cohere; KVKK kritik kurumsal için BGE-M3 self-hosted; gerçek volume + alan-özgü hassasiyet için fine-tuned BGE veya mE5. Embedding model değişikliği tüm corpus'u yeniden embed etmeyi gerektirir — bu maliyet ve süreyi her başlangıçta hesaba katın (1M doc x 2 saat re-embed x GPU saat ücreti).

5. Hybrid search — vector + BM25 + RRF

Saf vector search bazı sorguları kaçırır:

• Tam kelime eşleşmesi gerektiren ('XR-2050-A' ürün kodu, '5651 sayılı Kanun')
• Kişi/yer adları (embedding modelleri özel adları zayıf temsil eder)
• Acronym ve teknik terimler ('KVKK', 'MASAK', 'TS 13638')
• Negation ('KVKK uyumlu olmayan sistemler' — embedding negation'ı zayıf yakalar)

Çözüm hybrid search: BM25 (sparse) + vector (dense) aynı anda çalıştırılır, sonuçlar birleştirilir. İki birleştirme yaklaşımı:

Reciprocal Rank Fusion (RRF) — her sistemde belgenin rank'ı 1/(k+rank) formülüne sokulur (k=60 default), iki skor toplanır. Score normalizasyonu gerektirmez, robust. Production'da default seçim.

Weighted score — BM25 skoru ve vector skoru ayrı ayrı normalize edilir, ağırlık (örnek: 0.4 BM25, 0.6 vector) ile birleşir. Ağırlığı domain'e göre tune etmek gerekir; daha esnek ama tuning yorgun.

Implementation:

Vector DB	Hybrid desteği
pgvector	Manual (ts_vector + cosine, kod tarafında merge)
Qdrant	Native (Fusion API)
Weaviate	Native (hybrid query)
Milvus	Native (BM25 + vector + RRF)
Elasticsearch	Native (knn + match query)

Bizim ölçümlerimizde hybrid search saf vector'a göre top-5 recall'u %18-32 yükseltti, top-1 (en üst sonuç) doğruluğunu %25-40 artırdı. PoC dışında her production RAG için zorunlu kabul ediyoruz.

6. Reranker — pipeline'ın hassas filtresi

Retrieval aşaması "hızlı + geniş" (top-50, top-100 belge), reranker "yavaş + hassas" (cross-encoder ile her query-doc çiftini tek tek skorla, top-5'e indir). İki katmanlı yaklaşımın matematiği basit: bi-encoder embedding query ve doc'u ayrı vektörlere çevirir, sonra cosine distance hesaplar — kaybedilen bilgi olur. Cross-encoder query ve doc'u birlikte modele verir, daha hassas bir skor üretir; ama her query-doc çifti için ayrı bir model çağrısı gerektirdiği için yavaştır.

Pratik akış:

1. Query → embedding → vector DB top-100 retrieval (10-50ms)
2. Top-100 → reranker model → her çift için skor (50-300ms, 100 belge için)
3. Top-5 / top-10 → LLM context'ine yerleştir
4. LLM cevap üretir

Popüler reranker'lar:

• Cohere Rerank v3 — managed API, query başına 0.001-0.002 USD, 100ms latency. KVKK için EU region. Production'da en yaygın seçim.
• BGE Reranker (open-source) — self-hosted, GPU üstünde 50-150ms. Tam KVKK kontrol, no per-query cost. base/large/v2-m3 varyantları.
• ColBERT v2 — late-interaction mimari, query-token başına document-token başına skor. En hassas ama implementation ve operasyon karmaşık. Sadece çok yüksek hassasiyet gereken use case için.
• Cross-encoder ms-marco-MiniLM — küçük model, hızlı (CPU üstünde bile makul), recall artışı sınırlı.

Bizim AIGENCY'de Cohere Rerank v3 + fallback olarak self-hosted BGE Reranker kombinasyonu kullanıyoruz. Cohere unavailable durumunda otomatik fallback, latency budget'i koruyor.

Reranker'ın değer kanıtı: 200 query'lik bir benchmark'ta sadece retrieval + LLM kombinasyonu %62 doğruluk verirken, retrieval + rerank + LLM %84'e çıktı. Production RAG için reranker artık opsiyonel değil — zorunlu katman olarak kabul ediliyor.

7. Evaluation framework — sistemin gerçekten çalıştığını nereden biliyorsunuz?

Production RAG'ın en sık atlanan adımı evaluation. Sistem "demo'da çalışıyor" diye production'a alınır; 3 ay sonra "modelimiz neden 'bilmiyorum' diyor" şikayetleri başlar. Çözüm: üç katmanlı sürekli değerlendirme.

Katman 1 — Retrieval evaluation. Golden dataset (50-200 manuel etiketli query-positive_doc çifti) hazırlanır; sistem her sorgu için top-K retrieval döndürür; metric:

• Recall@K: doğru belge top-K içinde mi?
• MRR (Mean Reciprocal Rank): doğru belge ortalama hangi rank'ta?
• NDCG: relevance dereceli sıralama kalitesi.

Otomatize: Ragas, TruLens, Phoenix (Arize), DeepEval framework'leri retrieval + generation eval pattern'larını hazır sunuyor. Haftalık otomatik koşum + dashboard kurumsal projelerde minimum standart.

Katman 2 — Generation evaluation. LLM cevabı kalitesi:

• Faithfulness: cevap retrieved context'e sadık mı (hallucination yok)?
• Answer relevance: cevap query'ye yanıt veriyor mu?
• Context precision/recall: gerekli context kullanıldı mı?

LLM-as-judge pattern (GPT-4o, Claude Opus'a "bu cevap bu kaynağa sadık mı, 1-5 arası puan ver" diye sorma) hızlı ve ölçeklenir; ama subjektif — quarter'lık insan kalibrasyonu zorunlu (50-100 sample manuel etiket).

Katman 3 — Production monitoring. Gerçek kullanıcı sorgularında:

• Latency dağılımı (p50, p95, p99) — retrieval, rerank, LLM aşamaları ayrı ayrı.
• Cost per query — token tüketimi, vector DB query maliyeti.
• Thumbs up/down feedback rate — kullanıcı geri bildirimi.
• "I don't know" / clarification rate — model çok mu güvensiz, çok mu agresif?
• Hallucination spot-check — haftalık 20-50 random query'nin manuel kontrolü.

Bu üç katman birlikte çalışmazsa RAG'ın bozulduğunu fark etmek aylar alır. Bir embedding model upgrade'i, bir chunking parametresi değişikliği, bir vector DB index rebuild'i — sessizce kaliteyi düşürebilir. CI/CD pipeline'ına eval suite entegre etmek (her PR'da retrieval eval koşumu, regression varsa block) RAG'ın disiplinli evolution'unu mümkün kılar.

AI yönetişim çerçevemiz bu evaluation katmanlarının kurumsal audit gereksinimlerine nasıl entegre edileceğini detaylandırıyor. KVKK Veri Sorumlusu yükümlülüğü ile birleştiğinde bu eval ayrıca yasal kanıt görevi görüyor — "modelimiz nasıl çalışıyor, hangi kaynağa nasıl sadık" sorularına dokümante cevap.

Pratik özet — başlangıç check-list'i

İlk üretim RAG projeniz için doğru sıra:

1. Önce RAG mı doğru? — bilgi sık güncellenmiyorsa fine-tuning, davranış öğrenilmiyorsa RAG, ikisi de gerekiyorsa hibrit.
2. Doc store: pgvector ile başla (<500K embedding); volume büyürse Qdrant. Managed servisi sadece KVKK DPA tamam olduğunda seç.
3. Chunking: doc-type classifier + tipine özel chunker. Fixed-size sadece serbest metin için. Structure-aware her zaman default.
4. Embedding: OpenAI/Cohere ile başla (PoC), production için BGE-M3 self-hosted veya domain fine-tuned düşün.
5. Hybrid search: BM25 + vector + RRF. PoC dışında her zaman.
6. Reranker: Cohere Rerank veya BGE Reranker. Production'da zorunlu.
7. Evaluation: golden dataset → retrieval eval → LLM-judge → production monitoring. Üçü birden, haftalık otomatik.
8. Metadata: her chunk'a doc title, section, type, source URL, date, language ekle. Filter ve attribution için altın.
9. KVKK: veri lokasyonu (model, vector DB, log), DPA, retention policy, kullanıcı çıkarımı izlenebilirlik.
10. Continuous improvement: feedback loop'u kapatın — production'daki düşük rated query'leri analiz edin, golden dataset'i güncelleyin, chunker/embedding/reranker'ı iterate edin.

Bu liste minimum disiplin. Üzerine domain-spesifik gereksinimler (legal RAG için citation, medical RAG için confidence threshold, customer support RAG için escalation pattern) eklenir. RAG'ın değerini gerçek production'da almak için "demo çalışıyor" değil, "evaluation framework her hafta çalışıyor ve bozulma anında uyarı veriyor" durumuna ulaşmak gerekir.

Bizim ekibimiz Şanlıurfa Karaköprü'den AIGENCY v4 platformumuzu RAG-yoğun mimari ile işleterek ve kurumsal RAG sistem mühendisliği hizmeti vererek bu disiplini içselleştirdi. Kurumsal RAG pilotu, vector DB seçimi veya production-grade RAG mimari değerlendirmesi için iletişim formundan ulaşabilirsiniz — ilk değerlendirme görüşmesi ücretsizdir.

---

eCloud Tech — Şanlıurfa merkezli kurumsal yazılım, yapay zekâ, blockchain ve siber güvenlik ekibi. Building Tomorrow.