RAG Kurumsal Bilgi Tabanı: Mimari ve Maliyet

Neden saf LLM yetmiyor

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

Üç çözüm yolu var: fine-tuning, tüm dokümanı context window'a yapıştırma ve RAG. Fine-tuning pahalıdır ve yavaş güncellenir; doküman yapıştırma ise binlerce sayfada imkânsızdır. RAG bu iki ucun ortasıdır. Kurumsal dokümanları indeksler, soruya en alakalı parçaları getirir ve 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 doküman alım (ingestion) çatıları (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şlamaktır: SSS, ürün belgeleri, sık değişmeyen politika dokümanları. Sonra kullanım metriklerine göre genişletmektir.

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

Katman 2: Chunking Stratejisi

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

Üç ana strateji:

1. Sabit boyut (fixed-size): Her parça 500 token, %20 örtüşme. En basit ve en hızlı indeksleme yöntemidir; ancak cümle ortasından kesme riski yüksektir.

2. Cümle veya paragraf bazlı (semantic-aware): Doğal sınırlardan böler. Sentence-transformers ile cümle bütünlüğü korunur. Sözleşme ve politika dokümanlarında daha iyi çalışır.

3. Hiyerarşik (parent-child): Küçük parçalarla (200 token) arama yapılır, bulunan parçanın büyük üst paragrafı (1500 token) modele bağlam olarak verilir. Yüksek isabet ve yüksek bağlam sağlar. LlamaIndex'in HierarchicalNodeParser bileşeni 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 oldukları için) tercih edilir.

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

Katman 3: Embedding Modeli Seçimi

Parçalar 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 kendi sunucunuzda barındırılan BGE-M3. OpenAI modelleri Türkçeyi destekler ama bazı alana özgü terimlerde (hukuki, tıbbi, mühendislik) ince ayrımları kaçırır.

Alana özgü fine-tuning: Kurumsal terim sözlüğünüz çok özelse (örneğin kardiyoloji kliniği, savunma sanayii, hukuk büroları), BGE-M3 üzerinde 5-10 bin Türkçe alan örneğiyle yapılan contrastive fine-tuning, semantik aramada %15-25 iyileşme sağlayabilir.

Maliyet hesabı: 50 bin doküman çarpı ortalama 800 token, 40 milyon token eder. OpenAI text-embedding-3-small ile bu, bir kerelik 800 USD demektir. Bu yalnızca ilk indekstir. Doküman güncellendikçe yeniden embedding maliyeti gelir; ancak tipik kurumda aylık 30-50 USD civarındadır.

Katman 4: Vektör Veritabanı Seçimi

Vektörleri arayabilen ve sorgu anında getirebilen bir altyapıya ihtiyaç var. Beş ana seçenek:

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

• Mevcut PostgreSQL'i kullanır, ek operasyonel maliyeti azdır
• ACID uyumu sayesinde metadata ve vektör tek işlemde tutulur
• Hibrit arama için pg_trgm veya tsvector ile anahtar kelime araması aynı veritabanında yapılır

Büyük ölçek (10M+ parça): Qdrant veya Weaviate. Daha optimize HNSW indeksi ve daha hızlı sorgu sunar.

KVKK / lokasyon uyumu: Türkiye'de veri ikametgâhı zorunluysa (sağlık verileri, savunma), kendi sunucunuzda barındırılan seçenek tek yoldur. Pinecone gibi yalnızca ABD'de barındırılan yönetimli servisler KVKK m.9 yurt dışı transfer şartlarına takılır.

Katman 5: Hibrit Arama

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

Hibrit yaklaşım:

1. Kullanıcı sorgusu hem embedding'lenir (semantik), hem de anahtar kelime olarak ayrıştırılır (BM25 / tf-idf).
2. İki arama paralel çalışır ve her biri en iyi 50 sonucu döndürür.
3. Sonuçlar 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ç: Yalnızca semantik aramaya göre precision@10 değeri %15-25 iyileşir. Özellikle teknik terim, ürün kodu veya mevzuat numarası içeren sorgularda.

Katman 6: Reranking

Hibrit arama 50 sonuç döndürür. Bunların hepsini LLM'e bağlam olarak vermek hem pahalı hem de dikkat dağıtıcıdır. Yeniden sıralayıcı (reranker) sonuç sayısını 50'den 5-10'a indirir ve sıralamayı yeniden yapar.

Seçenekler:

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

Kazanç: Yeniden sıralama olmadan ve yeniden sıralama ile karşılaştırıldığında, son LLM yanıt kalitesi (groundedness, faithfulness) ölçümlerinde %20-30 iyileşme tipiktir.

Katman 7: LLM Yanıt Üretimi

Son katmanda getirilen 5-10 parça, sistem prompt'u ve 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 ve düşük maliyet: GPT-4o-mini, Claude Haiku, Gemini Flash. Çoğu sorguda yeterlidir.
• Karmaşık akıl yürütme: Claude Sonnet 4 veya GPT-4.1. Hukuki yorum ve çok adımlı muhakeme için uygundur.
• Yerel (gizli veri): Llama 3.3 70B, Qwen 2.5 72B. Hassas verilerin bulutta dolaşmaması isteniyorsa tercih edilir.

Kaynak gösterimi zorunluluğu: Modelin verdiği [#1], [#2] referansları arayüzde tıklanabilir kaynak doküman bağlantısına dönüştürülmelidir. Kullanıcı kaynağı görür, güven artar ve 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 tipiktir. Büyük şirketlerde (1000+ aktif kullanıcı) yıllık 60 bin - 150 bin USD'ye çıkar. Bu tutar hâlâ tam zamanlı bir yapay zeka mühendisi maaşının altındadır; üstelik operasyonel kontrol içeride kalır.

KVKK ve Erişim Kontrolü

Üç katmanlı yaklaşım:

1. Alım katmanı (filtre): PII içeren dokümanlar otomatik tespit edilir, anonimleştirilir veya farklı bir kovaya yönlendirilir.
2. Sorgu katmanı (RBAC): Kullanıcının rolüne göre erişebileceği doküman havuzu kısıtlanır. Vektör veritabanında metadata filtresi uygulanır: WHERE org_id = ? AND user_role IN (...).
3. Yanıt katmanı (denetim): Her sorgu, kullanıcı, getirilen parçalar ve üretilen yanıt kayda alınır. KVKK m.12 işleme aktivite kaydı için bu zorunludur.

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

İlk 90 Gün Yol Haritası

Gün 1-15: Keşif ve kapsam

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

Gün 16-45: Asgari uygulanabilir ürün (MVP)

• Tek kaynak (örneğin SharePoint) ve tek senaryo (örneğin İK SSS) ile başlanır.
• Yığın: pgvector, OpenAI embedding, Claude Sonnet ve basit bir web arayüzü.
• Beş dahili pilot kullanıcı.

Gün 46-75: Genişleme

• 3-5 kaynak konnektörü eklenir.
• Hibrit arama ve yeniden sıralayıcı entegre edilir.
• Kaynak gösterimi arayüzü eklenir.
• 30-50 aktif kullanıcı.

Gün 76-90: Üretim ortamı

• İzleme (gecikme, faithfulness, kullanıcı geri bildirim skoru) kurulur.
• KVKK denetim kaydı tamamlanır.
• Sistem tüm hedef kullanıcı kitlesine açılır.
• İyileştirme döngüsü (haftalık prompt, parçalama ve getirim ayarı) başlatılır.

Sonuç

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

Fark; mimari kararlarda, parçalama ve embedding stratejisinde, hibrit arama ile yeniden sıralayıcı katmanında ve KVKK uyumlu erişim kontrolünde gizlidir. Bu, 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 kapsamla başlamak, hızlı geri bildirim almak ve genişlemek, "her şeyi bir anda yapma" hatasına karşı en güçlü panzehirdir.

Kurumunuzun yapay zeka dönüşümünde destek için profesyonel danışmanlık hizmetlerini inceleyebilirsiniz.