RAG ile Kurumsal Bilgi Tabanı: Mimari, Maliyet, Güvenlik ve İlk 90 Gün Yol Haritası

Neden saf LLM yetmiyor

Saf bir ChatGPT veya Claude erişimi, kurumsal soruların %60-70'inde halüsinasyon riski taşır. Çünkü model şirketinizin son sözleşmesini, dünkü ticket'ı, üç hafta önce güncellenen prosedürü bilmez. Model genel bilgiyle, sizin kurumsal verinizle değil eğitilmiştir.

Üç çözüm yolu var: fine-tuning, context window'a tüm doküman yapıştırma, RAG. Fine-tuning pahalı ve yavaş güncellenir, doküman yapıştırma ise binlerce sayfada imkânsız. RAG bu iki ucun ortasıdır. Kurumsal dokümanları indexler, soruya en alakalı parçaları getirir, modele bağlam olarak verir. Model yanıtı kurumsal veriden destekli üretir.

Bu yazıda kurumsal RAG sisteminin yedi katmanını, her birinin teknik kararlarını, KVKK uyumunu ve gerçek maliyetini açıklıyorum. İlk 90 günde nereden başlanır, hangi sırayla genişler, hangi tuzaklara düşülmez.

Katman 1: Doküman Alımı (Ingestion)

Hangi kaynaklardan veri alacaksınız? Tipik kurumsal envanter:

• Yapılandırılmış: SharePoint, Confluence, Notion, Jira, ticket sistemleri
• Yarı-yapılandırılmış: PDF kontratlar, Word politika dokümanları, e-posta arşivi
• Konuşma: Slack/Teams kanalları, müşteri görüşme transkriptleri
• Veritabanı: CRM kayıtları, ERP modülleri, ürün katalogları

Her kaynak farklı konnektör ister. SharePoint için Microsoft Graph API, Confluence için REST, Notion için Notion API, PDF için pypdf2 veya unstructured.io, e-posta için IMAP. Açık kaynak ingestion framework'leri (LlamaIndex, Haystack, Unstructured) bu konnektörlerin çoğunu hazır sunar.

Tipik hata: "Her şeyi indeksleyelim" deyip 500 bin doküman yüklemek. Sonuç: çok gürültü, düşük kalite, yüksek maliyet. Doğru yaklaşım: önce 5-10 bin yüksek değerli dokümanla başlamak. SSS, ürün belgeleri, sık değişmeyen politika dokümanları. Sonra kullanım metriklerine göre genişletmek.

KVKK / PII filtreleme: Alım katmanında otomatik PII/PHI tarayıcı çalışmalı. TCKN, telefon, e-posta, kart numarası regex pattern'leri ile yakalanabilir; isim ve adres için spaCy + Türkçe NER modeli gerekir. Sürekli kişisel veri içeren dokümanlar (örnek: özlük dosyaları, hasta raporları) ayrı bir bucket'a alınır, erişim kontrolü çok daha sıkı uygulanır.

Katman 2: Chunking Stratejisi

Bir 50 sayfalık PDF doğrudan vektörlenemez. Önce parçalanır (chunk). Chunk boyutu sonucun kalitesini doğrudan etkiler.

Üç ana strateji:

1. Sabit boyut (fixed-size): Her chunk 500 token, %20 overlap. En basit, hızlı index. Ama cümle ortasından kesme riski yüksek.

2. Cümle / paragraf bazlı (semantic-aware): Doğal sınırlardan böler. Sentence-transformers ile cümle bütünlüğü korunur. SQL kontrat ve politika dokümanlarında daha iyi.

3. Hiyerarşik (parent-child): Küçük chunk'lar (200 token) ile arama yapılır, bulunan chunk'un büyük parent paragrafı (1500 token) modele context olarak verilir. Yüksek precision + yüksek context. LlamaIndex'in HierarchicalNodeParser'ı bunu hazır sunar.

Pratik öneri: Sözleşme ve uzun politika dokümanları için hiyerarşik. SSS ve ürün açıklamaları için cümle bazlı. Slack mesajları için sabit boyut (zaten kısa).

Tipik hata: Her dokümanı aynı stratejiyle parçalamak. 200 sayfalık ISO 27001 dokümanı ile 3 cümlelik SSS aynı strateji ile işlenirse, biri çok genel, diğeri çok parçalı olur.

Katman 3: Embedding Modeli Seçimi

Chunk'lar vektörlere dönüştürülür. Embedding modeli üç ana kategoride değerlendirilir:

Türkçe içerik için pratik öneri: Cohere multilingual-v3 veya local olarak BGE-M3. OpenAI modelleri Türkçeyi destekler ama bazı domain spesifik terimlerde (hukuki, tıbbi, mühendislik) ince ayrımları kaçırır.

Domain-specific fine-tuning: Eğer kurumsal terim sözlüğünüz çok özelse (örnek: kardiyoloji kliniği, savunma sanayii, hukuk büroları) BGE-M3 üzerinde 5-10 bin Türkçe domain örneğiyle contrastive fine-tuning, semantik aramada %15-25 iyileşme sağlayabilir.

Maliyet hesabı: 50 bin doküman × ortalama 800 token = 40 milyon token. OpenAI text-embedding-3-small ile bir kerelik 800 USD. Bu sadece ilk index. Doküman güncellendikçe re-embed maliyeti gelir, ama tipik kurumda aylık 30-50 USD civarı.

Katman 4: Vektör Veritabanı Seçimi

Vektörleri arayabilir ve sorgu zamanında alabilir bir altyapıya ihtiyaç var. Beş ana seçenek:

Küçük-orta kurum için pratik öneri (50K-1M chunk): pgvector. Çünkü:

• Mevcut PostgreSQL'i kullanır, ek operasyonel maliyet az
• ACID compliance ile metadata + vektör tek transaction
• Hibrit arama için pg_trgm veya tsvector ile keyword search aynı DB'de

Büyük ölçek (10M+ chunk): Qdrant veya Weaviate. Daha optimize HNSW index, daha hızlı sorgu.

KVKK / lokasyon uyumu: Türkiye'de veri ikametgâhı zorunluysa (sağlık verileri, savunma) self-hosted seçenek tek opsiyon. Pinecone gibi US-only managed servisler KVKK m.9 yurt dışı transfer şartlarına takılır.

Katman 5: Hibrit Arama

Saf semantic search yeterli değildir. Çünkü kullanıcılar bazen "tam bu numara" diye arar. "TS-2024-1547 kararı" gibi.

Hibrit yaklaşım:

1. Kullanıcı sorgusu hem embedding'lenir (semantic), hem keyword olarak parse edilir (BM25 / tf-idf).
2. İki arama paralel çalışır, her biri top-50 sonuç döner.
3. Reciprocal Rank Fusion (RRF) ile birleştirilir.

def rrf(semantic_results, keyword_results, k=60):
    scores = {}
    for rank, doc in enumerate(semantic_results):
        scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank)
    for rank, doc in enumerate(keyword_results):
        scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank)
    return sorted(scores.items(), key=lambda x: -x[1])

Pratik kazanç: Sadece semantic'e göre precision@10 %15-25 iyileşir. Özellikle teknik terim, ürün kodu, mevzuat numarası içeren sorgularda.

Katman 6: Reranking

Hibrit arama 50 sonuç döner. LLM'e bunların hepsini context olarak vermek hem pahalı hem dikkat dağıtıcı. Reranker, 50'den 5-10'a indirir, sıralamayı yeniden yapar.

Seçenekler:

• Cohere rerank-3: Managed, çok güçlü, ~2 USD / 1K query
• BGE-reranker-v2-m3: Açık kaynak, local GPU çalışır, ücretsiz
• Cross-encoder (sentence-transformers): Açık kaynak, CPU bile çalışır, daha yavaş

Kazanç: Reranking olmadan vs reranking ile, son LLM yanıt kalitesi (groundedness, faithfulness) ölçümlerinde %20-30 iyileşme tipik.

Katman 7: LLM Yanıt Üretimi

Son katman: getirilen 5-10 chunk + sistem prompt + kullanıcı sorusu modele gider. Yanıt üretilir.

Sistem prompt iskeleti:

Sen [şirket adı] kurumsal bilgi asistanısın. Aşağıdaki dokümanlardan
faydalanarak kullanıcı sorusunu yanıtla.

KURALLAR:
1. Sadece verilen dokümanlardaki bilgiyi kullan. Genel bilgi ekleme.
2. Her iddia için kaynak doküman numarasını [#1], [#2] formatında belirt.
3. Verilen dokümanlarda cevap yoksa "Bu konuda elimde yeterli bilgi yok"
   de, uydurma.
4. Yanıt Türkçe, açık ve özet ol.

DOKÜMANLAR:
{retrieved_chunks}

SORU: {user_question}

Model seçimi:

• Yüksek hız + ucuz: GPT-4o-mini, Claude Haiku, Gemini Flash. Çoğu sorguda yeterli.
• Karmaşık akıl yürütme: Claude Sonnet 4 veya GPT-4.1. Hukuki yorum, çok-adımlı muhakeme.
• Yerel (gizli veri): Llama 3.3 70B, Qwen 2.5 72B. Hassas veriler bulutta dolaşmasın isteniyorsa.

Citation enforcement: Modelin verdiği [#1], [#2] referansları frontend'de tıklanabilir kaynak doküman linkine dönüştürülmeli. Kullanıcı kaynağı görür, güven artar, model halüsinasyonu erken yakalanır.

Toplam Sahip Olma Maliyeti (TCO)

Orta ölçek senaryo (50 bin doküman, 200 günlük aktif kullanıcı, ortalama 8 sorgu / kullanıcı / gün):

Bu rakamlar Türkiye'de orta ölçek bir kurum için tipik. Büyük şirketlerde (1000+ aktif kullanıcı) yıllık 60 bin - 150 bin USD'ye çıkar. Hâlâ tam zamanlı bir AI engineer maaşının altında, ama operasyonel kontrol içeride.

KVKK ve Erişim Kontrolü

Üç katmanlı yaklaşım:

1. Alım katmanı (filtre): PII içeren dokümanlar otomatik tespit, anonimleştirme veya farklı bucket'a yönlendirme.
2. Sorgu katmanı (RBAC): Kullanıcının rolüne göre erişebileceği doküman havuzu kısıtlanır. Vektör DB'de metadata filtresi: WHERE org_id = ? AND user_role IN (...).
3. Yanıt katmanı (denetim): Her sorgu, kullanıcı, getirilen chunk'lar, üretilen yanıt loglanır. KVKK m.12 işleme aktivite kaydı için bu zorunlu.

Tipik hata: Erişim kontrolünü sadece prompt'ta uygulamak ("kullanıcı X bunu görmemeli, eğer şu doküman gelirse cevap verme"). LLM bunu güvenilir biçimde uygulayamaz. Filtre vektör DB sorgu seviyesinde fiziksel olmalı.

İlk 90 Gün Yol Haritası

Gün 1-15: Discovery + scope

• Hangi 5-10 kullanım senaryosu en yüksek değer üretir?
• Hangi 3-5 doküman kaynağı bu senaryoları besler?
• Erişim hakları ve KVKK gereksinimleri belgelenir.

Gün 16-45: MVP

• Tek kaynak (örnek: SharePoint) + tek senaryo (örnek: İK SSS) ile başla.
• Stack: pgvector + OpenAI embedding + Claude Sonnet + basit web UI.
• 5 dahili pilot kullanıcı.

Gün 46-75: Genişleme

• 3-5 kaynak konnektörü eklenir.
• Hibrit arama + reranker entegre edilir.
• Citation UI eklenir.
• 30-50 aktif kullanıcı.

Gün 76-90: Production

• Monitoring (latency, faithfulness, kullanıcı feedback skoru) kurulur.
• KVKK audit log tamamlanır.
• Tüm hedef kullanıcı kitlesine açılır.
• İyileştirme döngüsü (haftalık prompt + chunking + retrieval tuning) başlatılır.

Sonuç

Kurumsal RAG, doğru kurulduğunda bilgi erişiminde %40-60 zaman tasarrufu ve çağrı merkezi/destek ekiplerinde %20-30 yük azaltma sağlar. Yanlış kurulduğunda halüsinasyon, güven kaybı ve sessiz terk edilmiş bir proje üretir.

Fark mimari kararlarda, chunking ve embedding stratejisinde, hibrit arama + reranker katmanında ve KVKK uyumlu erişim kontrolünde gizli. Saf bir LLM çağrısının ötesinde yedi katmanlı bir sistemdir; her katmanın kendi optimizasyonu ve maliyet ödünleşmesi vardır.

İlk 90 günde küçük bir scope ile başlamak, hızlı geri besleme almak ve genişlemek; "her şeyi bir anda yapma" hatasına karşı en güçlü panzehirdir.