Vector Database Nedir? Yapay Zekâ Milyonlarca Belge Arasında İlgili Bilgiyi Nasıl Buluyor?

Bu tür ilişkileri yakalamak için içerikler sayısal vektörlerle temsil edilebilir. Kullanıcının sorusu da uyumlu bir vektöre dönüştürülür ve yakın temsiller aranır.

Vector Database (Vektör Veritabanı), bu vektörleri saklamak, indekslemek ve benzerlik sorgularıyla erişilebilir hâle getirmek için kullanılan altyapıdır.

Ancak vektör veritabanı belgelerin doğruluğunu denetlemez. Arama sonucunda bulunan içerik, soruyla benzer görünebilir ama eski, eksik veya yanlış olabilir. Benzerlik ile doğru cevap aynı şey değildir.

Vector Database Nedir?

Vektör veritabanı, çok boyutlu sayısal vektörlerin saklanmasını ve bu vektörler arasında benzerlik araması yapılmasını destekleyen veritabanıdır.

Yapay zekâ uygulamalarında bu vektörler çoğunlukla embedding modelleriyle oluşturulur. Metin, görüntü veya ses gibi verilerin belirli özellikleri sayısal temsillere dönüştürülür.

Bir kayıt yalnızca vektörden oluşmak zorunda değildir. Şunlar da saklanabilir:

• Belge veya parça kimliği.
• Kaynak metin.
• Belgenin tarihi ve sürümü.
• Kategori veya dil bilgisi.
• Erişim yetkileriyle ilişkili alanlar.
• Kaynak dosyaya ilişkin bilgiler.

Bazı sistemler metni veritabanında tutar; bazıları ise yalnızca başka bir depoya işaret eden kimlikleri saklar.

Embedding ile Vektör Veritabanı Arasındaki Fark

Embedding modeli, içeriği sayısal bir temsile dönüştürür.

Vektör veritabanı, bu temsilleri saklar ve arama işlemlerini yürütür.

Dolayısıyla veritabanı, anlam ilişkilerini tek başına oluşturmaz. Aramanın yakalayabileceği ilişkiler büyük ölçüde kullanılan temsil yöntemine bağlıdır.

Ayrıca vektör veritabanında saklanan her vektörün mutlaka bir dil modeli tarafından üretilmesi gerekmez. Başka sayısal özellik temsilleri de kullanılabilir.

Veritabanı vektörlerle çalışır; bu vektörlerin nasıl oluşturulduğu ayrı bir tasarım kararıdır.

Belgeler Neden Parçalara Ayrılıyor?

Uzun bir belgenin tamamını tek vektörle temsil etmek, içindeki belirli ayrıntıların bulunmasını zorlaştırabilir. Bu nedenle RAG uygulamalarında belgeler çoğunlukla daha küçük parçalara ayrılır.

Örneğin bir kullanım kılavuzunda kurulum, bakım ve garanti koşulları farklı bölümlerdir. “Garanti kapsamına hangi durumlar girmez?” sorusu için bütün kılavuz yerine ilgili bölümün getirilmesi daha yararlı olabilir.

Parçalama sırasında şu denge önemlidir:

Çok küçük parçalar, gerekli bağlamı kaybedebilir.

Çok büyük parçalar, farklı konuları aynı temsilde birleştirebilir.

Başlıkların korunması, tabloların doğru işlenmesi ve parçaların kaynak belgeyle ilişkilendirilmesi arama kalitesini etkiler. Parça sınırlarında bilgi kaybını azaltmak için örtüşme kullanılabilir; ancak bu, tekrar ve depolama maliyetini artırabilir.

Vector Database Nasıl Çalışır?

Tipik bir belge arama süreci iki aşamadan oluşur: İçeriklerin hazırlanması ve sorgunun çalıştırılması.

İçerik hazırlama

Belgeler okunur, temizlenir ve uygun parçalara ayrılır. Her parça için embedding oluşturulur. Vektörler, kaynak bilgileriyle birlikte veritabanına kaydedilir ve indekslenir.

Sorgulama

Kullanıcının sorusu, belge vektörleriyle karşılaştırılabilecek bir temsile dönüştürülür. Ardından uygun filtreler uygulanır ve yakın vektörler aranır.

Bulunan adaylar doğrudan gösterilebilir veya yeniden sıralama aşamasından geçirilebilir. RAG sisteminde seçilen içerikler dil modeline bağlam olarak verilir.

Sorgu ve belge temsilleri aynı vektör uzayında uyumlu olmalıdır. Bazı embedding sistemleri sorgular ve belgeler için farklı talimatlar veya ayrı fakat birlikte eğitilmiş kodlayıcılar kullanabilir.

Benzerlik Nasıl Hesaplanıyor?

Vektörlerin yakınlığı farklı ölçülerle değerlendirilebilir.

Hangi ölçünün uygun olduğu embedding modeline ve vektörlerin nasıl hazırlandığına bağlıdır. Normalize edilmiş vektörlerde bazı ölçüler aynı sıralamayı üretebilir.

Ayrıca benzerlik puanı genellikle cevabın doğru olma olasılığı değildir. Bir puanın yüksek çıkması, belgenin güncel veya soruyu gerçekten cevaplıyor olduğunu kanıtlamaz.

Milyonlarca Vektör Arasında Arama Nasıl Hızlanıyor?

Bütün vektörleri sorguyla tek tek karşılaştırmak mümkündür. Bu, tam arama yaklaşımıdır; ancak büyük koleksiyonlarda maliyetli olabilir.

Ölçek büyüdüğünde Approximate Nearest Neighbor (ANN), yani yaklaşık en yakın komşu araması kullanılabilir.

ANN yöntemleri, bütün koleksiyonu eksiksiz taramak yerine indeks yapılarından yararlanarak güçlü adaylara daha hızlı ulaşmayı hedefler. HNSW veya IVF tabanlı yöntemler buna örnektir.

Burada bir denge bulunur:

• Daha hızlı sorgu.
• Daha düşük kaynak tüketimi.
• Gerçek en yakın sonuçları bulma oranı.

Yaklaşık arama, her sorguda matematiksel olarak en yakın bütün sonuçların bulunacağını garanti etmez. İndeks ve arama ayarları, hız ile sonuç yakalama oranı arasında denge kurar.

SQL Veritabanlarından Tamamen Farklı mı?

SQL veritabanlarını yalnızca tam eşleşme yapan sistemler olarak tanımlamak eksiktir. Bu sistemler aralık sorguları, birleştirmeler, toplulaştırmalar ve farklı arama özellikleri sunabilir. Bazıları vektör aramasını da destekler.

Dolayısıyla seçim her zaman “SQL veya vektör veritabanı” şeklinde yapılmaz.

Mevcut veritabanına vektör araması eklemek bazı projelerde yeterli olabilir. Başka projelerde özel bir vektör veritabanı kullanmak daha uygun olabilir.

Hibrit Arama Nedir?

Vektör araması, anlam ilişkilerinde faydalı olabilir. Ancak ürün kodları, özel isimler veya nadir teknik terimlerde kelime eşleşmesi önemini korur.

Hibrit arama, anahtar kelime araması ile vektör aramasını birlikte kullanır.

Örneğin “X200 modelinin garanti koşulları” sorgusunda hem model kodunun doğru eşleşmesi hem de garantiyle ilgili içeriğin bulunması gerekir.

Hibrit arama yalnızca SQL ile vektör aramasının birlikte kullanılması demek değildir. Genellikle sözcüksel arama sonuçlarıyla vektör arama sonuçlarının uygun bir yöntemle birleştirilmesini anlatır.

Metadata ve Erişim Kontrolü Neden Önemli?

En benzer belge, kullanıcının görmeye yetkili olmadığı bir belge olabilir. Kurumsal aramada bu nedenle erişim kuralları arama sürecine dâhil edilmelidir.

Metadata filtreleriyle şu koşullar uygulanabilir:

• Yalnızca belirli bir departmanın belgeleri.
• Belirli dildeki içerikler.
• Geçerli sürümler.
• Kullanıcının erişebildiği kayıtlar.

Ancak filtreleme ile yaklaşık arama birlikte çalışırken performans ve sonuç sayısı değişebilir. Filtrelerin indeksleme ve sorgulama düzeniyle nasıl uygulandığı önemlidir.

Belgeyi modele verdikten sonra gizlemeye çalışmak, erişim kontrolünün yerine geçmez. Yetkisiz içeriğin bağlama girmesi önlenmelidir.

FAISS Bir Vektör Veritabanı mı?

FAISS, benzerlik araması ve vektör indeksleme için kullanılan bir kütüphanedir. Tek başına bütün veritabanı işlevlerini sunan bir servis olarak düşünülmemelidir.

Bir vektör veritabanı ise aramanın yanında kayıt yönetimi, güncelleme, kalıcılık ve operasyonel özellikler sağlayabilir. Bu özelliklerin kapsamı ürüne göre değişir.

Arama kütüphanesi ile üretimde kullanılan veritabanı sistemi aynı katman değildir. Bir kütüphane, daha geniş bir sistemin bileşeni olabilir.

Güncelleme Sürecinde Neler Değişir?

Yeni belgeler eklendiğinde vektörleri oluşturulur. Belgeler değiştiğinde ilgili kayıtların güncellenmesi; silindiğinde ise eski parçaların aramadan kaldırılması gerekir.

Embedding modeli değişirse eski ve yeni vektörler doğrudan karşılaştırılamayabilir. Aynı boyuta sahip olmaları, uyumlu oldukları anlamına gelmez.

Geçiş sürecinde yeniden embedding oluşturma, model sürümü takibi ve indeks yenileme gerekebilir. Eski belgelerin sonuçlarda kalması, özellikle RAG uygulamalarında yanlış cevaplara neden olabilir.

Arama Kalitesi Nasıl Ölçülmeli?

Yalnızca sorgunun hızlı dönmesi yeterli değildir. Gerçek kullanıcı sorularıyla ilgili belgelerin bulunup bulunmadığı ölçülmelidir.

Belge yakalama oranı, sıralama kalitesi, gecikme ve kaynak tüketimi birlikte değerlendirilir. RAG kullanılıyorsa üretilen cevabın kaynaklarla desteklenip desteklenmediği de ayrıca incelenmelidir.

İyi bir vektör araması, başarılı RAG için önemli olabilir; fakat tek başına yeterli değildir.

Sık Sorulan Sorular

RAG için ayrı bir vektör veritabanı zorunlu mu?

Hayır. Küçük koleksiyonlarda farklı arama yöntemleri kullanılabilir. Mevcut veritabanlarının vektör özellikleri de yeterli olabilir.

Daha fazla sonuç getirmek cevabı iyileştirir mi?

Her zaman değil. Gereksiz veya çelişkili içerikler bağlamı kalabalıklaştırabilir. Sonuç sayısı ve yeniden sıralama birlikte değerlendirilmelidir.

Vektörlerden kaynak metin tamamen çıkarılabilir mi?

Birebir geri dönüş genel bir özellik değildir. Ancak embedding’ler hassas bilgilerle ilişkili olabilir; anonim veya zararsız veri oldukları varsayılmamalıdır.

Veritabanı, yanlış belgeleri ayıklayabilir mi?

Benzerlik araması tek başına bunu yapmaz. Kaynak doğrulama, sürüm yönetimi ve içerik kalite kontrolleri ayrıca gerekir.

Kaynaklar: Hervé Jégou, Matthijs Douze ve Cordelia Schmid — Product Quantization for Nearest Neighbor Search; Yu. A. Malkov ve D. A. Yashunin — Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs; Jeff Johnson, Matthijs Douze ve Hervé Jégou — Billion-Scale Similarity Search with GPUs.

Editör Notu

Bu içerik, vektör veritabanlarının çalışma mantığını ve yapay zekâ uygulamalarındaki kullanım koşullarını ele alan bir araştırma ve değerlendirme yazısıdır. İçerikte yer alan değerlendirmeler editoryal yorum niteliğindedir. Arama kalitesi ve performans; embedding modeline, belge hazırlığına, benzerlik ölçüsüne, indeks ayarlarına ve filtrelere bağlıdır. Vektör yakınlığı, içeriğin doğru, güncel veya kullanıcı için erişilebilir olduğunu tek başına göstermez.