Vektör Veritabanı Boyutlandırma ve Seçim Hesaplayıcı
RAG için kendi kendine barındırılan bir vektör veritabanının arkasındaki pratik soru, hangi motorun belirli bir sunucuya uyduğu ve hangisini iş yükünün elediğidir. Aşağıdaki hesaplayıcı, aynı embedding'ler üzerinde eşleşen geri çağırma oranında çalıştırılan yedi kendi kendine barındırılan vektör veritabanına ait kıyaslama sonuçlarımızdan her ikisini de yanıtlıyor.
Hesaplayıcı metrikleri açıklaması
Hesaplayıcının üst kısmındaki beş onay kutusu, beş yaygın RAG iş yükünü adlandırır ve her biri, bir satıcı iddiası yerine kıyaslamadan alınan ölçülen bir sınıra eşlenir. Birini işaretlemek, motor listesini belirli bir sayıya göre filtreler. İşaretlemeden bırakmak, iş yükünün geçerli olmadığı ve hiçbir motorun buna göre filtrelenmediği anlamına gelir. Her bir anahtarın ne istediği ve arkasındaki ölçüm:
Seçim ve boyutlandırma
Çalışan bir dizinden önce iki karar gelir. İlki seçimdir, çünkü bazı motorlar belirli bir işi yapamaz. Hesaplayıcı, her motoru yukarıdaki beş gereksinim anahtarına göre kontrol eder ve başarısız olanları eler. İkincisi boyutlandırmadır; yani hayatta kalan motorlardan hangilerinin kutuya sığdığı ve ne kadar boşluk payı olduğu anlamına gelir. Hayatta kalan her biri için uyuyor, sıkı veya uymuyor, ayrıca sunucunun tutacağı vektör sayısını bildirir. Hiçbir karar, geri çağırma kalitesine bağlı değildir, çünkü yedi motor, tam bir kNN oracle'ına karşı 0.014 nDCG yayılımı içinde berabere kalır.
2.25M vektörde ayak izi
2.25M vektörde kıyaslama, dizinin nerede yaşadığına göre bölünmüş iki ayak izi ölçtü. Beş bellek içi motor için, oluşturma ve hizmet sırasındaki en yüksek RAM miktarını, 17.0 GB'den (Milvus) 62.4 GB'ye (Chroma) kadar kaydetti. İki disk üstü motor için, diskteki dizini kaydetti: LanceDB için 12.0 GB ve pgvector için 18.4 GB; bu gigabayt başına çok daha ucuza mal olur. Bu sayılar ham ölçümlerdir, hesaplayıcının boyutlandırma girdileri değildir. Hesaplayıcı bunun yerine kararlı durum hizmetini boyutlandırır.
Bellek içi motorlar için bu, oluşturma-ve-hizmet zirvesinin altında çalışır ve disk üstü motorlar için, tablo kopyasını ve öbek metnini ölçülen dizinin üstüne ekler; bu nedenle aynı 2.25M derlem için sayıları, RAM'de buradaki çubuklardan daha düşük ve diskte daha yüksek çıkar. Aşağıdaki ölçülen-model karşılaştırması ikisini uzlaştırır. Hesaplayıcının arkasındaki, doğruluk, hız, filtrelenmiş ve hibrit arama, oluşturma maliyeti ve canlı dalgalanma genelindeki motor başına tam kıyaslama, açık kaynak vektör veritabanı karşılaştırması.
Boyutlandırma modeli
Girdiler derlem boyutu, öbekleme ve embedding modelini içerir ve hesaplayıcı, boyutlandırmayı yönlendiren iki sayıyı türetir. Derlem boyutu ve öbekleme vektör sayısını verir. 2 GB'lık bir derlem (ondalık, 2 milyar bayt) token başına 4 bayttan 500M token eder ve %15 çakışma ile 512 token'lık öbekler, 512 × 0.85 = 435.2 token'lık bir adım ilerletir, böylece sayı yuvarlak(500M ÷ 435.2) = 1,148,897 vektör olur. Embedding modeli boyutu verir, bu nedenle girdi ham bir sayı değil bir model seçimidir ve bge-m3 bunu 1024 olarak ayarlar.
Her motorun ayak izi daha sonra vektör başına bir maliyetin vektör sayısıyla çarpımı artı sabit bir süreç tabanıdır: footprint = base_gb + bytes_per_vector × N. Vektör başına maliyet, motorların ayrıştığı yerdir, çünkü bir vektör veritabanı ham vektörden daha fazlasını depolar. Ayrıca, aramayı hızlı yapan dizin grafını ve gerçek RAG için döndürmesi gereken öbek metnini de tutar. Aşağıdaki tablo, float32'de 1024 boyutta her motorun depolama düzeninin ürettiği vektör başına maliyettir.
Ayrımı çoğunlukla iki düzen gerçeği yapar. Redis her vektörün ikinci bir kopyasını tutar (bir kaynak hash'i artı dizin içi bir kopya) ve öbek metnini boşaltamaz, bu nedenle RAM'deki en ağır olanıdır. pgvector ayrıca her vektörü diskte iki kez depolar; bir kez tablo öbeğinde ve bir kez HNSW dizini içinde ve dizini 8 KB Postgres sayfalarına yuvarlanır, bu nedenle 1024 boyutlu bir float32 vektör tek başına tam bir sayfayı doldurur. Diğer dört bellek içi motor, öbek metnini diske boşaltır, bu nedenle RAM maliyetleri vektör artı küçük bir graftır. Öbek metnini sakla anahtarı, 512 token'da vektör başına yaklaşık 2 KB olan bu yükü kontrol eder. Redis onu RAM'de tutar, diğer tüm motorlar diskte tutar ve anahtarı kapatmak her yerden kaldırır.
Süreç tabanı motor başına bir kez eklenir: Milvus için 2.0 GB, Weaviate için 0.5, Chroma için 0.3, Qdrant için 0.2, Redis için 0.05 ve iki disk üstü motor için 0. Varsayılan 2 GB derlem (1.15M vektör) için 16 GB, 200 GB'lık bir sunucuda bir araya getirildiğinde: Qdrant 5.1 GB RAM'e ihtiyaç duyar, Milvus ve Weaviate 6.9 GB, Redis 12.5 GB, pgvector 16.5 GB disk ve LanceDB 8.5 GB.
Karar, bu ayak izini bağlayıcı kaynaktaki kutuyla karşılaştırır ve %80 çizgisi kasıtlı boşluk payıdır. RAM veya diskin %80'inde veya altında uyuyor olarak okunur, bu da kutunun yaklaşık beşte birini işletim sistemi sayfa önbelleği, sorgu tamponları ve büyüme için bırakır. 80 ila %100 arası sıkıdır ve daha fazlası uymaz. Bu rakam kararlı durum hizmetidir, bu nedenle dizini aynı kutuda oluşturmak veya yeniden oluşturmak, ölçülen zirveye daha yakın olarak, bu süre boyunca daha fazla RAM gerektirir. Aynı formülü geriye doğru çalıştırmak kapasiteyi verir, (box − base) ÷ bytes_per_vector: aynı 16 GB sunucu Redis'te nominal 1.47M vektör, Qdrant'ta 3.7M ve 200 GB diskinde pgvector'da 14.0M ve LanceDB'de 27.1M tutar; her biri, kesin bir çizgi yerine yanında gösterilen hata bandı içinde. Kuantizasyonu açmak, onu destekleyen motorlar için vektör kısmını böler (int8 4x, ürün kuantizasyonu 16x, ikili 32x) ve embedding modelini değiştirmek, her sayıyı boyut aracılığıyla yeniden ölçeklendirir.
Ölçülen modele karşı
Hesaplayıcı, kıyaslamanın ölçtüğünü modellediğinden ayırır, çünkü ikisi farklı güven taşır. Kıyaslamanın kaydettiği RAM rakamları, kararlı durum hizmetinden kabaca iki ila üç kat daha yüksek çalışan bir oluşturma-ve-hizmet zirvesidir ve Weaviate için yüksek bir Go bellek sınırı tarafından şişirilmiştir. Hesaplayıcı bu zirveye göre boyutlandırmaz. Beş bellek içi motoru, her satıcının kendi belgelenmiş hizmet formülüne, tablodaki eklemeli vektör-artı-graf maliyetlerine göre boyutlandırır ve ölçülen zirveyi bir üst sınır kontrolü olarak tutar. Dolayısıyla ölçüm, kıyaslamanın gözlemlediğini kaydederken, boyutlandırma kasıtlı olarak altında çalışır.
İki disk üstü motor bunun tersidir. Disk dizinleri doğrudan ölçüldü ve ayrı bir derlem üzerinde yüzde 1 ila 2 arasında tutuldu, bu nedenle hesaplayıcı onları ölçüme göre boyutlandırır. Her kapasite, bu ayrımı yansıtan görünür bir hata bandı taşır: modellenen bellek içi hizmet tahminleri için yüzde 25 ila 30, pgvector için yüzde 15 ve LanceDB'nin ölçülen diski için yüzde 1 ila 2. İki girdi, ölçümler yerine varsayım olarak etiketlenmiştir. Disk üstü motorlar için RAM önbelleği, dizinin yüzde 25'i olarak ayarlanmıştır ve düzenlenebilir, çünkü hizmet RAM'leri hiç ölçülmemiştir ve kuantizasyon oranları bu kıyaslamadan değil literatürden gelir, bu nedenle gerçek geri çağırma kaybı veriye göre değişir.
Yetenek kapısı
Hesaplayıcının seçim yarısı, bir puan değil, bir dizi ikili olgudur. Aşağıdaki tablo, yukarıdaki anahtarların motor başına tarafıdır. Her motor için, onu eleyen iş yüklerini ve hala yaptığı ancak işaretlenmiş bir oranda olanları gösterir. Milvus ve Weaviate, hiçbir anahtarda eleme taşımaz, bu yüzden temiz genelciler olarak okunurlar.
Redis, dayanıklılık konusunda elenmek yerine işaretlenmiştir çünkü append-only bir dosya ile çökme-korumalı hale getirilebilir. Kalıcılık kapalıyken kıyaslandı, bu nedenle işaret, sınırın motor değil bizim yapılandırmamız olduğunu belirtir.
Tercih edilen kaynak olarak ekleKıyaslama metodolojisi
Sayılar, yedi motorun tek sunuculu bir kıyaslamasından gelir; her biri, bir Hetzner CCX53 (32 vCPU, 128 GB RAM, NVMe) üzerinde sabitlenmiş bir Docker konteynerinde kendi başına çalıştırılmıştır. Her motor aynı bge-m3 vektörlerini (1024-boyut, L2-normalize edilmiş float32 üzerinde kosinüs) dizinledi ve ef veya nprobe'unu tarayarak ulaşılan 0.95'lik eşleşen bir Recall@10 ile okundu, k=10 ve seed 42 ile. Derlemler, kalite için MedRAG-50k ve TechQA-28k ve ölçek için 2.25M vektörlük bir MedRAG katmanıydı. Tam istatistikler, güven aralıkları ve motor başına sürümler kıyaslama makalesindedir.
Sınırlamalar
Bellek içi hizmet rakamları, doğrudan bir hizmet ölçümü değil, bir oluşturma-ve-hizmet zirvesine göre kalibre edilmiş satıcı formülleridir, bu nedenle hesaplayıcının gösterdiği yüzde 25 ila 30 bandını taşırlar. pgvector ve LanceDB için hizmet RAM'i, ölçülmemiş bir önbellek varsayımıdır, bu nedenle hesaplayıcı bu ikisini disk üzerinde boyutlandırır. Dağıtım biçimleri de tasarım gereği farklılık gösterir. LanceDB gömülü bir kütüphanedir, pgvector bir PostgreSQL uzantısıdır, diğer beşi bağımsız sunuculardır ve Redis kalıcılık kapalıyken çalıştı, bu nedenle her motorun ayak izi ve oranları, tek bir özdeş yapılandırmadan ziyade kendi operasyonel şeklini yansıtır. Kıyaslama, 1024 boyutta bir embedding modeli kullandı, bu nedenle farklı bir model veya boyut sayısı her ayak izini değiştirir, bu yüzden model sabit bir sayı yerine bir girdidir. Yönetilen ve bulut barındırılan motorlar ayrı bir karşılaştırmadır.
Sonuç
RAG'de kendi kendine barındırılan bir vektör veritabanı için seçim, bir doğruluk sorunundan ziyade bir boyutlandırma ve seçim sorunudur, çünkü yedi motor birbirinin 0.014 nDCG'si içinde kalır. Hesaplayıcı, ayak izi matematiğini ve ölçülen iş yükü sınırlarını, bir liderlik tablosu yerine belirli bir sunucu için tek bir yanıta dönüştürür. 1024 boyutta 16 GB'lık bir kutuda, RAM'de Redis'te 1.5M vektörden Qdrant'ta 3.7M'ye kadar tutar ve disk üstü motorlarda 14M ila 27M arası ve dalgalanma ağırlıklı bir iş yükünü açmak, Milvus ve Weaviate'ı temiz bırakırken Chroma ve LanceDB'yi eler. Bu sayıların her birinin arkasındaki ölçülen kıyaslama, açık kaynak vektör veritabanı karşılaştırmasıdır.
Daha fazla okuma
- Embedding modelleri kıyaslaması
- Yeniden sıralayıcı kıyaslaması
- RAG için vektör veritabanı
- Açık kaynak embedding modelleri
- Çok dilli embedding modelleri
- Çok modlu embedding'ler
- Ajan temelli RAG framework'leri
Bu benchmarkı kaynak gösterin
Yayınlayacağınız yere uygun formatı seçin. Bağlantılı sürümü CMS'inize yapıştırmak, geri bağlantıyı korur.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{Vektör Veritabanı Boyutlandırma ve Seçim Hesaplayıcı}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/vector-database-for-rag}},
note = {AIMultiple. Erişim tarihi: 20 Temmuz 2026}
}
Yorum yapan ilk kişi olun
E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir. Yorumlar orijinal dilinde bırakılır.