Multi-Tenant RAG İzolasyonu: Hangi Vektör DB, Filtre Atlanırsa Ne Sızar?
Pinecone / Qdrant / Weaviate / Milvus / pgvector için karar tablosu + 23 maddelik doğrulama listesi

Multi-Tenant RAG İzolasyonu Nedir?

Multi-tenant RAG izolasyonu, tek bir vektör veritabanında birden fazla müşterinin (tenant) belge gömme vektörlerini tutarken, bir tenant'a ait sorgunun yalnızca kendi verisiyle eşleşmesini teknik olarak garanti eden savunma katmanıdır. İzolasyon; kimliğin belge alımından (ingestion) üretim (generation) aşamasına kadar taşınması, benzerlik aramasında tenant sınırının zorlanması ve sonuçların model bağlamına girmeden önce doğrulanmasıyla sağlanır. Bu sınır bir noktada gevşerse ortaya cross-tenant veri sızıntısı çıkar: A müşterisinin sorusuna B müşterisinin sözleşmesi, faturası veya kişisel verisi cevap olarak döner.

Bu yazı kavramsal tasarım rehberi değildir; onu RAG tenant izolasyonu: kimliği uçtan uca taşımak yazısında ayrıntılı işledik. Buradaki amaç bir karar aracı sunmak: hangi vektör veritabanının izolasyonu hangi mekanizmayla yaptığını, o mekanizma atlanırsa pratikte ne sızdığını ve KVKK Madde 12 karşısında ne anlama geldiğini yan yana koymak.

İzolasyon Modelleri: Silo, Havuz, Köprü

Multi-tenant mimarilerde izolasyonu üç temel desende ele almak, hangi vektör DB özelliğine ihtiyaç duyduğunuzu netleştirir. Literatürde bu Silo, Pool (Havuz), Bridge (Köprü) taksonomisi olarak tanımlanır ve dört düzlemde (veri, vektör, orkestrasyon, LLM) ayrı ayrı değerlendirilir.

• Silo (izole): Her tenant için ayrı koleksiyon/indeks/veritabanı. En güçlü izolasyon, en yüksek işletme maliyeti. Küçük ve çok hassas tenant sayısında mantıklıdır.
• Havuz (paylaşımlı): Tüm tenant'lar tek indeksi paylaşır, ayrım bir tenant_id alanı üzerinden metadata/payload filtresiyle yapılır. En ölçeklenebilir ama filtreye en bağımlı; sızıntının çoğu bu desende doğar.
• Köprü (melez): Büyük veya düzenlemeye tabi tenant'lar silo, geri kalanı havuz. Pratikte en yaygın kurumsal tercih.

Dört düzlem önemlidir çünkü vektör düzleminde (DB) izolasyonu doğru kursanız bile orkestrasyon düzleminde önbellek paylaşımı veya LLM düzleminde bağlam karışması sızıntı üretebilir. Tek bir katmanı sağlamlaştırmak yetmez.

Vektör DB Karşılaştırma Tablosu: İzolasyon Mekanizması ve Sızıntı Senaryosu

Aşağıdaki tablo beş yaygın vektör veritabanının tenant izolasyon mekanizmasını, granülerliğini, ilgili mekanizma atlanırsa ne sızdığını ve KVKK Madde 12 (teknik tedbir) karşılığını yan yana koyar. Mekanizma isimleri sürümle değişebilir; üretimde her zaman ilgili ürünün güncel dokümanıyla teyit edin.

Karar özeti: Zaten PostgreSQL işleten ve moderat ölçekli ekipler için pgvector + RLS, izolasyonu tanıdık ve denetlenebilir bir katmana taşır. Yüksek hacim ve düşük gecikme gerektiren havuz senaryolarında Qdrant ya da Pinecone namespace modeli; sıkı kiracı ayrımı isteyen SaaS'larda Weaviate yerleşik çok-kiracılığı öne çıkar. Hiçbir mekanizma "seç ve unut" değildir; hepsi doğru uygulanmaya bağımlıdır.

5 Gerçek Yanlış-Yapılandırma Kalıbı

Sızıntıların büyük çoğunluğu vektör DB'nin kusuru değil, izolasyon özelliğinin yanlış kullanımıdır. En sık gördüğümüz beş kalıp:

1. Post-filter yerine pre-filter gerektiği yerde sonradan filtreleme: Önce benzerlik araması yapılıp sonra tenant_id ile eleme yapılırsa (post-filter), motor komşu tenant'ların vektörlerini zaten okumuş olur; top_k dolduğunda meşru sonuçlar dışarıda kalır, hata ayıklama loglarına yabancı veri düşer. Filtre arama öncesi (pre-filter) uygulanmalı.
2. Kullanıcı girdisinin tip zorlaması yapılmadan filtreye geçmesi: tenant_id istek gövdesinden alınıp filtreye string yerine ham/kontrolsüz tip olarak konursa, saldırgan filtre ifadesini değiştirebilir veya eşleşmeyi geçersiz kılabilir. Kimlik sunucu tarafında oturumdan türetilmeli, asla istemciden gelen değere güvenilmemeli.
3. Önbellek paylaşımı: Gömme (embedding) önbelleği veya sorgu-sonuç önbelleği tenant anahtarı olmadan paylaşılırsa, A'nın önbelleğe alınmış cevabı aynı soruyu soran B'ye döner. Her önbellek anahtarına tenant_id dahil edilmelidir.
4. Yeniden sıralayıcıya (reranker) ham liste geçirmek: Aday belgeler filtrelenmeden reranker'a verilir, reranker skoru düzeltir ama tenant sınırını bilmez; sonuçta yabancı belge en üste çıkabilir. Reranker'a giren aday listesi zaten tenant-filtreli olmalı.
5. Silo sanılan havuz: Ekip "her tenant'ın ayrı koleksiyonu var" varsayarken kod tek indekse yazıyordur (yanlış namespace/koleksiyon adı, varsayılan namespace'e düşme). Bağlantı ve namespace/koleksiyon adı her yazma ve okumada doğrulanmalı.

Filtre Atlanırsa Ne Sızar ve KVKK Madde 12

Cross-tenant sızıntı soyut bir risk değildir. Kurumsal RAG'da vektör deposunda tipik olarak sözleşme metinleri, destek talepleri, e-posta içerikleri, sağlık/finans kayıtları ve bunların içindeki kişisel veriler bulunur. Filtre atlandığında dönen komşu belge, doğrudan bir kişisel veri ihlali anlamına gelebilir.

KVKK Madde 12, veri sorumlusuna kişisel verilerin hukuka aykırı işlenmesini ve verilere hukuka aykırı erişimi önlemek için uygun teknik ve idari tedbirleri alma yükümlülüğü yükler. Multi-tenant RAG bağlamında tenant izolasyonu (namespace, payload filtresi, RLS) bu "teknik tedbir" yükümlülüğünün doğrudan karşılığıdır; sızıntı yalnızca bir mühendislik hatası değil, mevzuata aykırılık taşıyan bir olaydır. Kişisel verinin hangi maddeler kapsamında vektör deposundan sızabileceğini KVKK Madde 6 ve LLM sızıntı vektörleri yazısında ayrıştırdık. Uyum çerçevesini kurumsal düzeyde ele almak için AltaySec kvkk-ai-compliance-kit ve çıkış katmanında politika uygulayan Guardian (LLM güvenlik duvarı) ürünlerini bu izolasyon katmanının tamamlayıcısı olarak konumlandırır.

Tenant İzolasyon Doğrulama Kontrol Listesi (23 Madde)

Aşağıdaki 23 maddelik liste, bir multi-tenant RAG sistemini üretime almadan önce izolasyonun her katmanını denetlemek için kullanılabilir. Maddeler altı başlık altında gruplanmıştır.

A. Kimlik taşıma (belge alımından üretime)

1. Her belge, alım sırasında değişmez bir tenant_id ile etiketleniyor.
2. tenant_id istemciden değil, doğrulanmış sunucu oturumundan türetiliyor.
3. Alım hattında tenant_id'siz belge yazımı reddediliyor (zorunlu alan).
4. Sorgu bağlamı boyunca (arama, reranker, üretim) tek ve aynı tenant_id taşınıyor.

B. Filtre uygulama

5. Filtre benzerlik aramasından önce (pre-filter) uygulanıyor, sonrasında değil.
6. tenant_id filtreye eklenmeden çalışan sorgu yolu kod tabanında yok.
7. Filtre değeri filtreye geçmeden önce beklenen tipe zorlanıyor (tip doğrulama).
8. Qdrant/benzeri için tenant_id alanında keyword/uygun indeks tanımlı.
9. Varsayılan namespace/koleksiyona sessizce düşme (fallback) engellenmiş.

C. Depolama ve izolasyon mekanizması

10. Seçilen izolasyon deseni (silo/havuz/köprü) belgelenmiş ve kodla uyumlu.
11. pgvector kullanılıyorsa RLS etkin ve FORCE ROW LEVEL SECURITY ayarlı.
12. Uygulama, tabloları RLS'i baypas eden sahip/superuser bağlantısıyla sorgulamıyor.
13. Namespace/koleksiyon/tenant adı her okuma ve yazmada doğrulanıyor.

D. Önbellek ve yeniden sıralayıcı

14. Gömme ve sorgu-sonuç önbellek anahtarları tenant_id içeriyor.
15. Yeniden sıralayıcıya (reranker) giren aday listesi zaten tenant-filtreli.
16. Oturum/konuşma belleği tenant'lar arasında paylaşılmıyor.

E. Test ve regresyon

17. Cross-tenant sızıntı için otomatik negatif test var (A sorgusu B belgesini asla döndürmemeli).
18. Bu test CI hattında her sürümde çalışıyor (regresyon kapısı).
19. Model/gömme modeli yükseltmesinde izolasyon testleri yeniden koşuluyor.
20. Yük altında (yüksek top_k, eşzamanlı tenant) sızıntı testi yapılmış.

F. Uyum ve gözlemlenebilirlik

21. Erişim ve sorgu logları tenant_id ile etiketli ve denetlenebilir.
22. Loglara/hata mesajlarına yabancı tenant içeriği düşmüyor.
23. İzolasyon mekanizması KVKK Madde 12 teknik tedbir kaydına bağlanmış.

Hangi Vektör DB'yi Seçmeliyim?

Karar, izolasyon mekanizmasının gücünden çok ekibinizin onu doğru işletme kapasitesine bağlıdır. Pratik yönlendirme:

• Zaten PostgreSQL işletiyorsanız ve ölçek orta düzeydeyse: pgvector + RLS. İzolasyonu tanıdık, denetlenebilir ve mevcut yedekleme/erişim politikalarınıza gömülü bir katmana taşır.
• Yüksek hacim, düşük gecikme, havuz modeli: Qdrant (payload filtresi + shard) veya Pinecone (namespace). Her ikisi de pre-filter disiplinine ve tip zorlamasına mutlak bağımlıdır.
• Çok sayıda küçük tenant'lı SaaS, sıkı ayrım: Weaviate yerleşik çok-kiracılık veya Milvus'ta uygun katman (koleksiyon/veritabanı).

Hangi ürünü seçerseniz seçin, sızıntının kaynağı neredeyse hiçbir zaman veritabanının kendisi değil, yukarıdaki beş yanlış-yapılandırma kalıbından biridir. İzolasyonu bir kez kurup unutulacak bir ayar değil, her sürümde regresyon testiyle doğrulanan bir güvenlik sınırı olarak ele alın. Vektör deposunu çalışırken izlemek için RAG güvenlik izleme ve vektör DB yaklaşımını bu checklist'in üstüne koyabilirsiniz. Kurumsal bir doğrulama veya tenant izolasyon denetimi için AltaySec ile iletişime geçebilirsiniz.

Kaynaklar

• Pinecone Docs — Indexing overview ve namespace ile veri ayrımı
• Qdrant Documentation — Multitenancy (payload partitioning, tenant_id keyword index)
• Weaviate Docs — Multi-tenancy (tenant-bazlı shard izolasyonu)
• Milvus Docs — Multi-tenancy strategies (database/collection/partition-key)
• pgvector — Open-source vector similarity search for Postgres
• PostgreSQL Documentation — Row Security Policies (RLS)
• OWASP LLM08:2025 — Vector and Embedding Weaknesses
• 6698 Sayılı Kişisel Verilerin Korunması Kanunu — Madde 12 (Veri güvenliğine ilişkin yükümlülükler)

İlgili Yazılar

• RAG Tenant İzolasyonu: Kimliği Uçtan Uca Taşımak
• RAG Güvenlik İzleme ve Vektör Veritabanı
• KVKK Madde 6 ve LLM Sızıntı Vektörleri
• RAG Security Nedir?