Vektör Veritabanı Nedir? Anlamsal Arama, Embedding ve Kurumsal Yapay Zekada Doğru Seçim

Vektör veritabanı, metin, görsel veya ses gibi içerikleri anlamını temsil eden sayı dizileri (vektörler, embedding) olarak saklayan ve bir soruya anlamca en yakın kayıtları çok kısa sürede bulan veri deposudur. Anahtar kelime eşleşmesi yerine anlam benzerliğiyle arar; kurumsal yapay zeka asistanlarının belge bulma katmanı çoğunlukla budur.

Vektör veritabanı sorusu nereden çıkar?

Bu soru genellikle bir yapay zeka projesinin ortasında gelir. Ekip bir belge asistanı ya da akıllı arama pilotu kurmuştur; ilk denemeler iyidir ama belge sayısı arttıkça yanıtlar yavaşlar, alakasız paragraflar gelir ve biri "Bize bir vektör veritabanı lazım" der. Ardından sorular çoğalır: Mevcut veritabanımız bunu yapamaz mı, ayrı bir ürün mü almalıyız, veri nerede duracak?

Karışıklığın kaynağı, vektör veritabanının tek başına bir çözüm değil, bir altyapı parçası olmasıdır. Kullanıcı vektör veritabanını görmez; yalnızca asistanın doğru belgeyi bulup bulmadığını görür. Belgeden yanıt üreten mimarinin bütününü RAG nedir yazımızda anlattık; bu yazı o mimarinin "getirme" katmanına, yani vektörlerin nasıl saklandığına ve arandığına odaklanıyor. Kullanıcının arama ekranında ne gördüğünü ise yapay zeka destekli kurumsal arama yazımızda ele aldık.

Embedding ve anlamsal arama: vektör veritabanı nasıl çalışır?

Bir embedding modeli, bir cümleyi ya da paragrafı yüzlerce, hatta binlerce boyutlu bir sayı dizisine çevirir. Anlamca yakın metinler bu uzayda birbirine yakın noktalara düşer. "Yıllık izin kaç gün?" sorusu ile "Çalışanlara her yıl tanınan dinlenme süresi" başlıklı paragraf ortak kelime taşımasa da vektörleri birbirine yakındır.

Vektör veritabanı bu noktaları saklar ve gelen bir soru vektörüne en yakın komşuları bulur. Milyonlarca vektörü tek tek karşılaştırmak yavaş olacağı için yaklaşık en yakın komşu (ANN) dizinleri kullanılır. Yaygın yöntemler şunlardır:

• HNSW (katmanlı yakınlık grafiği): Hızlı ve isabetlidir, ancak bellek tüketimi yüksektir.
• IVF (kümeleme tabanlı dizin): Vektörleri kümelere ayırır; daha az bellekle çalışır, ayarı daha dikkat ister.
• Sıkıştırma (quantization): Vektörleri küçülterek bellek ve disk ihtiyacını düşürür; karşılığında isabet biraz azalabilir.

Arama sonucunu belirleyen yalnızca dizin değildir. Her vektörün yanında belge adı, sürüm, bölüm, tarih ve yetki grubu gibi üst veriler saklanır; sorgu "yalnızca geçerli sürümler ve bu kullanıcının görebildiği belgeler" diye süzülür. Türkçenin eklemeli yapısı nedeniyle embedding modelinin Türkçe başarımı da sonucu doğrudan etkiler; ayrıntısı Türkçe doğal dil işleme yazısında.

Yanlış kurulan vektör katmanının maliyeti

Vektör deposu, şirket belgelerinin anlamsal bir kopyasıdır. Bu yüzden OWASP Top 10 for LLM Applications 2025 listesi "Vektör ve Gömme (Embedding) Zayıflıkları" başlığını (LLM08:2025) ayrı bir risk olarak sınıflıyor. Yetki süzgeci olmayan, farklı kaynakları tek havuzda karıştıran ya da dışarıdan zehirlenebilen bir vektör deposu, asistanın yanlış kişiye yanlış belgeyi getirmesine yol açar.

IBM Cost of a Data Breach Report 2025 bültenine göre kuruluşların %13'ü yapay zeka modeli veya uygulamasında ihlal yaşadı; bunların %97'sinde uygun yapay zeka erişim kontrolleri yoktu.

Sorun geçen yılda kalmadı: IBM'in 2026 Veri İhlali Maliyeti bülteninde kuruluşların %20'sinden fazlası yapay zeka modellerini veya uygulamalarını hedef alan bir ihlal bildirdi. Erişim kontrolü vektör katmanında kurulmazsa, dosya sunucusundaki yetkiler ne kadar düzgün olursa olsun asistan onları atlar.

Kalite tarafında da bedel var. Stanford HAI AI Index Report 2026 verisine göre AA-Omniscience bilgi testinde 26 önde gelen modelin halüsinasyon oranı %22 ile %94 arasında değişti. Modelin yalnızca kendi bilgisine güvenmek yerine şirket belgesine dayanması bu yüzden önemlidir; ancak getirme katmanı yanlış ya da eski paragrafı bulursa model o paragrafa dayanarak yine ikna edici ama hatalı bir yanıt yazar; bu konuyu yapay zeka halüsinasyonu rehberimizde ayrıca ele aldık.

Ayrı vektör veritabanı mı, mevcut veritabanına eklenti mi?

Kurumsal projelerde en sık tartışılan karar budur. Üç temel seçenek vardır ve hiçbiri her durumda doğru değildir:

Pratik kural şudur: vektör sayısı birkaç milyonu aşmıyorsa ve ekip zaten bir ilişkisel veritabanı işletiyorsa, eklentiyle başlamak çoğu zaman yeterlidir. On milyonlarca vektör, yüksek eşzamanlı sorgu ve katı gecikme hedefleri birlikte geldiğinde ayrı bir vektör veritabanı değerlendirilir. Bu eşikler kesin sınır değildir; donanıma, dizin ayarına ve süzme ihtiyacına göre değişir, bu yüzden karar pilot ölçümüyle verilmelidir.

Vektör veritabanı, raporlama için kurulan yapıların yerini de almaz. Veri ambarı sayısal soruları ("geçen çeyrek bölgelere göre satış") yanıtlar; vektör deposu anlamsal soruları ("iade sürecinde müşteriye ne söylüyoruz?"). Ham verinin tutulduğu katmanlarla farkını veri gölü ile veri ambarı karşılaştırmasında, sensör verisine özel depoları zaman serisi veritabanı yazısında anlattık.

Vektör veritabanı seçmeden önce yanıtlanması gereken 7 soru

1. Ne aranacak? Prosedür, sözleşme, teknik kılavuz, e-posta, ürün kataloğu ya da görsel. İçerik türü, parçalama (chunking) yöntemini ve embedding modelini belirler.
2. Hacim ve büyüme ne? Bugünkü belge sayısını ve yıllık artışı tahmin edin. Vektör sayısı belge sayısının katlarıdır, çünkü belgeler parçalara bölünür; uzun bir kılavuz tek başına onlarca parça üretebilir.
3. Kesin ifadeler önemli mi? Ürün kodu, madde numarası, parça no gibi değerler anlamsal aramada kaçabilir. Bunlar varsa hibrit arama (anahtar kelime + vektör) şarttır.
4. Yetki modeli nasıl? Her parçanın hangi gruba açık olduğu vektörle birlikte saklanmalı ve sorgu anında süzülmelidir. Mevcut klasör yetkilerinin nasıl kurgulandığını dosya paylaşım yetkilendirme yazımızda anlattık.
5. Veri nerede durmalı? Kişisel veri içeren belgelerde embedding'ler de kişisel veri taşıyabilir. Bulut mu kurum içi mi kararı KVKK açısından değerlendirilmelidir; genel çerçeve yapay zeka ve KVKK yazımızda.
6. Güncelleme nasıl olacak? Belge değiştiğinde eski parçaların silinip yenilerinin eklenmesi otomatik olmalı. Aksi halde asistan iptal edilmiş prosedürden yanıt verir.
7. Başarı nasıl ölçülecek? Gerçek kullanıcı sorularından bir test seti hazırlayın ve "doğru parça ilk beş sonuçta mı?" sorusunu düzenli ölçün. Model ya da dizin ayarı değiştiğinde test tekrarlanmalıdır.

Bu soruların çoğu teknolojiden önce veri düzeniyle ilgilidir. Aynı belgenin üç sürümü varsa en iyi dizin bile yanlış sürümü bulabilir; mükerrer kayıt ve veri kalitesi yazımız bu temizliğin nasıl yapılacağını anlatıyor.

Vektör deposunu güvenli işletmek

OWASP'ın LLM08 başlığı altında toplanan riskler somut önlemlerle azaltılabilir. Kontrol listesi olarak şunları öneriyoruz:

• Yetkiyi sorguda uygulayın. Yetki süzgeci, sonuçlar geldikten sonra değil, arama sırasında uygulanmalı; aksi halde model yetkisiz parçayı görmüş olur.
• Kaynakları ayırın. Müşteri verisi, İK belgeleri ve genel prosedürler aynı dizinde karışmamalı; gerekirse ayrı koleksiyonlar kullanılmalı.
• Girişi denetleyin. Vektör deposuna yalnızca onaylı kaynaklardan belge girmeli; dışarıdan yüklenen dosyalar zehirleme riski taşır.
• Silmeyi kanıtlayın. Saklama süresi dolan ya da silinmesi istenen belgenin vektörleri de silinmeli ve bu kayıt altına alınmalı.
• Erişimi kaydedin. Kim hangi soruyla hangi parçalara ulaştı, kayıtlarda görülebilmeli.

Çalışanların genel yapay zeka servislerine şirket verisi kopyalaması ise ayrı bir risktir; bunu ChatGPT ve şirket verisi güvenliği yazımızda ele aldık. Vektör katmanının sızma ve yapılandırma denetimini siber güvenlik danışmanlığı kapsamında yapıyoruz.

Digital Bridge'de bu işi nasıl yapıyoruz?

Vektör veritabanını tek başına bir ürün olarak satmıyoruz; onu kurumsal LLM asistanı ya da anlamsal arama projesinin bir katmanı olarak kuruyoruz. İşleyişimiz şöyle:

• Keşif ve ihtiyaç analizi. Hangi belgelerin aranacağını, hacmi, yetki yapısını ve verinin nerede durması gerektiğini birlikte çıkarıyoruz. Bu aşamanın sonunda eklenti mi ayrı veritabanı mı kararını gerekçesiyle yazıyoruz.
• Veri hazırlığı. Belgeleri ayıklıyor, sürümleri netleştiriyor ve üst veri şemasını tanımlıyoruz. Bu iş veri yönetişimi ve kalite çalışmalarımızla aynı disiplinle yürüyor.
• Pilot. Tek bir alanda (ör. kalite prosedürleri) gerçek kullanıcı sorularıyla bir test seti oluşturup farklı embedding modellerini ve dizin ayarlarını karşılaştırıyoruz. Kararı ölçüme göre veriyoruz.
• Entegrasyon. Vektör katmanını ERP, doküman yönetimi, intranet ya da yardım masasına yapay zeka entegrasyonu ile bağlıyor, belge güncellendiğinde dizinin kendiliğinden yenilenmesini sağlıyoruz.
• Kurum içi seçenek. Verinin dışarı çıkamadığı yapılarda embedding modelini, vektör deposunu ve dil modelini tamamen kurum sunucusunda çalıştırabiliyoruz.

Terminolojisi çok özel alanlarda embedding ya da dil modelinin uyarlanması gerekebilir; hangi durumda gerektiğini firmaya özel yapay zeka modeli rehberimizde açıkladık. Hazır paket satmıyoruz; ihtiyaç analizinin ardından kapsamı ve aşamaları içeren yazılı bir teklif hazırlıyoruz.

Sonraki adım

Vektör veritabanı kararı bir ürün listesiyle değil, üç bilgiyle başlar: aranacak belge türleri, yaklaşık hacim ve kimin neyi görebileceği. Bu üçünü bir sayfaya yazın ve ekibinizin en sık sorduğu 30–50 soruyu ekleyin. Nereden başlayacağınızdan emin değilseniz önce şirketlerde yapay zekaya nereden başlanır yazımıza göz atın.

Listeniz hazırsa iletişim sayfamızdan bize ulaşın; birlikte inceleyip eklentiyle mi ayrı bir veritabanıyla mı başlamanın mantıklı olduğunu ve pilotun kapsamını çıkaralım. Diğer kullanım alanları için Yapay Zeka rehberimizin tamamına bakabilirsiniz.