Bu yazı bir “nasıl yapılır” rehberi veya teknik bir tutorial değildir.
Bu yazı, kurumsal RAG mimarisi projelerinde sıkça karşılaşılan, PoC (Proof of Concept) aşamasında harikalar yaratan, ancak bir Güvenlik ve Mimari Denetimi (Audit) masasına geldiğinde neden üretime geçiş onayı alamadığını anlatan bir vaka analizidir.
Eğer şirketinizde “Private AI” adı altında kurulan sistemlerin RAG mimarisi denetimi süreçlerinden geçip geçmeyeceğini sorgulamanız gerekir. Bu sadece bir teknik borç değil, aynı zamanda bir uyumluluk riskidir.
1️⃣ Bağlam: RAG Mimarisi Denetimi ve Temsilî Yapı
Aşağıdaki yapı, GitHub’daki popüler repository’lerde, framework dokümantasyonlarında ve sayısız kurumsal demoda görülen standart akıştır. Özellikle RAG mimarisi denetimi süreçlerinde en sık karşımıza çıkan senaryolarda bu şablon tercih edilir.
Genel işleyiş şöyledir:
- Kurum içi PDF/Word dosyaları parçalanır (Chunking).
- Vektör veritabanına kaydedilir (Embedding).
- Kullanıcı soru sorar.
- Sistem en alakalı metin parçalarını bulur (Retrieval).
- LLM (Büyük Dil Modeli) bu parçaları kullanarak cevabı oluşturur.
Bu sistem demoda sorunsuz çalışır. Sorulara mantıklı ve akıcı cevaplar verir. Ancak bir denetim perspektifinden bakıldığında, bu bir “çözüm” değil, henüz yönetilmemiş bir risk paketidir. Sağlam bir kurumsal RAG mimarisi, sadece doğru cevabı vermekle yükümlü değildir; aynı zamanda cevabı güvenli ve izlenebilir kılmak zorundadır.
2️⃣ Temel Varsayımlar ve Riskler
Bu yapıyı kurgulayan ekipler, genellikle şu varsayımlara dayanarak projeyi geliştirir:
- Varsayım 1: “Model doğru cevap veriyorsa sistem başarılıdır.”
- Varsayım 2: “Retrieval (geri getirme) mekanizması dokümanı bulduysa risk düşüktür.”
- Varsayım 3: “Kaynak göstermek şık bir özelliktir (nice-to-have), zorunlu bir güvenlik katmanı değildir.”
Profesyonel bir RAG mimarisi denetimi süreci, tam olarak bu varsayımların geçerliliğini yitirdiği noktada başlar. Bir sistemin “akıllı” olması, onun “güvenli” olduğu anlamına gelmez.
3️⃣ Audit Sorusu
Kapsamlı bir RAG mimarisi denetimi gerçekleştirirken sorulması gereken asıl soru “Model ne kadar başarılı?” değildir. Kritik soru şudur:
“Bu sistem yanlış veya zararlı bir cevap ürettiğinde, bunun nedenini teknik ve hukuki olarak kanıtlayabilir miyiz?”
Standart kurumsal RAG mimarisi örneklerinde bu sorunun cevabı genellikle olumsuzdur. İzlenebilirliğin olmadığı yerde kurumsallıktan bahsedilemez.
4️⃣ Bulgular (3 Kritik Red Sebebi)
Temsilî bir yapıda RAG mimarisi denetimi yapıldığında, sistemi reddetmeye sebep olan 3 ana bulgu öne çıkar:
1. Kanıt Zorunluluğu Yok (Traceability Gap)
Sistem cevap verir ve cevaplar mantıklıdır. Ancak audit sırasında şu sorunun yanıtı aranır: “Bu cevabın, veritabanındaki X dokümanının Y paragrafından türetildiğini %100 garanti edebilir misiniz?”
Çoğu mimaride bu bağ deterministik değildir. Modelin “öyle yaptığını” varsayarız. Ancak finansal veya hukuki verilerde “sanmak” kabul edilemez. Cevap, modelin kendi halüsinasyonu mu yoksa gerçekten kurum verisi mi? Eğer sistem, cevabın kaynağını kesin ve izlenebilir bir bağla sunamıyorsa, o sistem denetimden geçemez. Bu durum, yanlış bilgilendirme durumunda hukuki sorumluluğu belirsizleştirir.
2. Eval Göstermelik (Superficial Evaluation)
Projelerde genellikle “Doğruluk” (Accuracy) veya “Alaka” (Relevance) metrikleri ölçülür.
Ancak “Güvenlik Riski” çoğu zaman ölçülmez.
- Model bir “Prompt Injection” saldırısına uğradığında ne yapıyor?
- Sistem, cevaplayamayacağı bir soruya zorlandığında sessiz mi kalıyor yoksa inandırıcı bir yalan mı uyduruyor?
- Kullanıcı sistemi manipüle etmeye çalıştığında (Jailbreak) defans mekanizması var mı?
Sadece doğruluğa odaklanan bir “Evaluation” süreci, güvenlik açıklarını maskelemektedir. Örneğin OWASP Top 10 for LLM listesindeki riskler göz ardı edilirse, proje canlıya alındığı gün büyük bir güvenlik açığına dönüşebilir.
3. Erişim Bağlamı Zayıf (Broken Access Control)
Bu, veri güvenliği açısından en kritik mimari hatadır.
Tipik senaryoda, şirketin tüm dokümanları (hassas İK, maaş listeleri veya finans verileri dahil) tek bir vektör havuzuna (Vector Database) atılır. Bir kullanıcı sisteme girip yetkisi olmayan bir veriyi (örneğin “Genel Müdürün maaşı nedir?”) sorguladığında, Retrieval mekanizması görevini yapar ve veriyi getirir.
Sorun modelde değildir. Sorun, kullanıcı kimliği ile veri erişim yetkisinin (ACL) vektör seviyesinde ayrışmamış olmasıdır. Arayüzde login olmak, veriye erişim yetkisini doğrulamaz. Bu katmanın eksik olduğu yapılar, potansiyel bir veri sızıntısıdır ve KVKK/GDPR uyumluluğunu doğrudan ihlal eder.
5️⃣ Audit Kararı
Bu mimari Audit’ten geçemez.
Sistem “çalışıyor” olabilir. Ancak başarılı bir RAG mimarisi denetimi için gereken izlenebilirlik ve güvenlik standartlarını karşılamamaktadır.
Bu tür sistemlerde, üretim öncesi bağımsız bir değerlendirme almak, ileride oluşabilecek itibar ve veri kayıplarını önlemenin en düşük maliyetli yollarından biridir.
Not: Burada reddedilen şey kullanılan teknoloji, LLM modelleri veya açık kaynak kütüphaneler değildir. Reddedilen şey, bu araçların üzerine inşa edildiği eksik mimari varsayımlardır.
Bir yanıt yazın