Vektör Veritabanı Kıyaslaması: RAG için 7 Açık Kaynak Motor

Yedi açık kaynak, kendi barındırılan vektör veritabanını bir RAG pipeline'ının getirme katmanı olarak kıyasladık; her biri aynı bge-m3 embedding'leri ve gerçek tıbbi ve teknik sorgular üzerinde birer kez çalıştırıldı, böylece veritabanı indeksi tek değişken oldu. İş yükü; doğruluk ve getirme kalitesinden hız, bellek, filtrelenmiş ve hibrit arama, derleme maliyeti ve canlı değişime kadar sekiz boyutta MedRAG-50k, TechQA-28k ve 2.25M-vektörlük bir külliyatı kapsadı.

Tek iş parçacığı hızı

Her motor, arama parametresi (ef veya nprobe) 10 Recall değeri 0.95'e ulaşana kadar ayarlandığı ortak çalışma noktası olan aynı recall seviyesinde değerlendirilir; bu da hız sayılarının adil bir şekilde karşılaştırılmasını sağlar.

Tek istemci iş parçacığında Redis, MedRAG-50k üzerinde 559 MB tepe RAM ile 764 QPS sunar; bu, setteki en yüksek verim ve en düşük bellektir. Tek iş parçacığı sıralaması Redis 764, Qdrant 377, Milvus 342, Weaviate 341, pgvector 257, Chroma 197, LanceDB 70 şeklindedir; tepeden tabana 10x fark vardır. LanceDB, RAM yerine gecikmeyi takas eden disk üzerindeki aykırı değerdir; p95 değeri yaklaşık 22 ms'dir. Redis, TechQA-28k (651 ile 81) ve 2.25M (495 ile 28) üzerinde en hızlı, LanceDB ise en yavaş olmaya devam eder; ancak ölçekte orta sıralar yer değiştirir ve Milvus üçüncülükten altıncılığa düşer.

RAG için kuyruk gecikmesi, kullanıcı deneyimini ham verimden daha fazla etkiler. Eşleşen recall'da 154 sorgunun 100 çalıştırması üzerinden havuzlanan sorgu başına gecikme, verim sıralamasını izler.

Redis kalıcılık kapalıyken çalıştı (RDB anlık görüntüsü veya append-only dosyası yok), bu nedenle hız ve bellek değerleri geçici, dayanıklılık içermeyen bir yapılandırmaya aittir.

Eşzamanlılık altında verim

Tek iş parçacıklı QPS, bir sorgunun ne kadar hızlı olduğunu yanıtlar. Üretim sorusu, birçok eşzamanlı istemci altındaki verimdir ve yanıt, yalnızca veritabanına değil, istemcinin nasıl oluşturulduğuna bağlıdır.

Kapalı döngü bir istemci iki şekilde sürülebilir ve her ikisi de Python RAG uygulamalarında yaygındır. Tek bir asenkron veya iş parçacıklı süreç, her eşzamanlı sonucu (gRPC/protobuf veya RESP) tek bir GIL üzerinde deserialize eder; bu nedenle verimi sunucu değil istemci sınırlar. Birçok worker süreci (gunicorn -w N deseni) her biri kendi GIL'ine sahip olur ve sunucu kapasitesinin çok daha fazlasını açığa çıkarır. Her ikisini de tek bir 32-vCPU kutuda sabit ef=128 değerinde ölçtük ve her noktayı recall ile doğruladık.

İstek eşzamanlılığı, en fazla 32 worker sürecinde 1'den 512'ye çıktıkça verim çizgileri kesişir. Redis bir istekte en yüksekten başlar ve en düşükte biter; Weaviate ise grubun dibinden 512 istekte 8330 QPS'lik bir platoya tırmanır ve 32 istekte yolda 7.114'ü geçer. Tek asenkron süreçte sıralama bunun yerine Python istemci ayrıştırma verimliliğini izler; çünkü Redis'in RESP'i deserialize edilmesi en hafif olanıdır ve GIL'e en az kaybeder.

Her motorun tek süreç zirvesi ve 32 süreç zirvesi, 1'den 512'ye kadar tüm taramadaki tavanlardır; herhangi bir istek sayısındaki verim değildir.

Redis, setteki en düşük tek sorgu gecikmesini korur (yaklaşık 1.6 ms) ve tek iş parçacıklı arama çekirdeği 32 eşzamanlı istekte yaklaşık 1642 QPS'de doygunluğa ulaşır, sonra bunun ötesinde tersine ölçeklenir (RediSearch'in WORKERS sorgu-iş parçacığı havuzu varsayılan olarak kapalıdır). Weaviate ve Milvus (çok iş parçacıklı sunucular) ve pgvector (her bağlantı için bağımsız bir Postgres arka ucu) 32 çekirdek boyunca ölçeklenir. pgvector en düşük tek süreç zirvesine (536) ve en yüksek ikinci 32 süreç zirvesine (4832) sahiptir. p99'u 100ms'nin altında tutma bütçesinde çok süreçli sıralama Weaviate 8290, pgvector 4828, Milvus 4725, Qdrant 1737, Redis 1642 şeklindedir.

Qdrant'ın daha ağır gRPC ayrıştırması, birlikte konumlandırılmış sayısını sunucu sınırı yerine istemciye bağlı hale getirir; çünkü yalnızca süreç sayısı onu tek süreçte 455 QPS'den 32 süreçte 1859'a taşır. Chroma ve LanceDB çok süreçli çalıştırmanın dışında tutuldu. Chroma, ef değerini koleksiyon oluşturmada sabitler ve tersine ölçeklenir; 512 istekte p99 değeri 13 saniyedir ve LanceDB gömülü olduğu için ağ istemcisi senaryosu geçerli değildir.

Bellek ayak izi

50k vektörde, tepe RAM kullanımı 559 MB'den (Redis, RAM içinde, kalıcılık kapalı) 3.300 MB'ye (Milvus) kadar uzanır; Weaviate 1.201, LanceDB 1.574, Chroma 1.800 ve pgvector 2.024 MB'dedir. Sıralama, bellek içi ile disk arasındaki takasın ortaya çıktığı 2.25M noktasında değişir.

Beş bellek içi motorda 2.25M vektördeki tepe RAM, 17.0 GB (Milvus) ile 62.4 GB (Chroma) arasında değişir; bu 3.7x aralık veya milyon vektör başına 7.5 GB ile 27.7 GB'dir. Milvus en düşük seviyede kalır çünkü indeksi diske (DiskANN tarzı) taşır; tamamen RAM kullanan HNSW motorları ise en hızlı büyür. Böylece 50k'de en ağır olan Milvus (3.300 MB), 2.25M'de en hafiftir (17.0 GB); Chroma ise 62.4 GB ile en ağırdır.

İki disk tabanlı motor, ayak izleri RAM yerine disk olduğu için bu RAM karşılaştırmasının dışında kalır. pgvector 2.25M'de 18.4 GB disk üstü indeks, LanceDB ise 12.0 GB disk üstü indeks tutar ve sunum RAM'leri tam çalışma kümesi yerine bu indeks üzerindeki bir sayfa önbelleğidir; bu ölçülmedi. Bellek içi değerlerde de bir uyarı vardır. Bunlar derleme ve sunum yüksek su işaretidir, yalnızca sunum ayak izi değildir; bu nedenle yalnızca sunum yeniden ölçümü açık bir iyileştirmedir.

Canlı değişim altında güncellik, yazmalar ve silmeler

Diğer yedi boyut, statik bir toplu yükleme sonrası okunan bir külliyatı ölçer. Gerçek RAG bilgi tabanları, indeks arka planda birleşirken belgeleri sürekli ekler, günceller ve siler. Bu değişim iş yükü, ayrı bir 8-vCPU kutuda MedRAG-50k üzerinde çalıştırıldı; bu nedenle verimi bu bölüme özgüdür ve 32 çekirdekli hız sayılarıyla karşılaştırılamaz. Doğruluk sinyalleri (recall ve tombstone kontrolleri) donanımdan bağımsızdır.

Güncellik (yazmadan sonra okuma). Her motorun yapılandırıldığı tutarlılık ayarında, her biri yazmadan sonra okumayı sağlar. Yeni yazılan bir belge anında aranabilir; yaklaşık 150 yazmadan sıfırı görünmez. Yazma onayından aramada görünürlüğe kadar gecikme Redis için p50 2 ms, Weaviate için 4 ms, Qdrant için 9 ms, Milvus için 12 ms, pgvector için 14 ms, LanceDB için 31 ms ve Chroma için 41 ms'dir. Milvus yeni satırı, henüz mühürlenmemiş büyüyen segmentin güçlü tutarlılık taramasıyla bulur (vektör kalıcı HNSW grafiğine daha sonra girer); bu nedenle 12 ms değeri, kullanıcıya dönük geçerli bir yazmadan sonra okumayı temsil eden büyüyen segment aranabilirliğidir.

Karma yük altında yazma ve okuma. Saniyede 150 yazmayı hedefleyen bir yazıcı ve 60 saniye boyunca sorgulayan altı okuyucu ile okuma recall değeri her motor için 0.96 ile 1.00 arasında kaldı ve eşzamanlı yazmalar altında hiçbir indeks bozulmadı. Tek satır yazma verimi motorları 57x ile ayırır ve sıralama statik derleme sıralamasının neredeyse tersidir.

LanceDB her satır için bir kopyalama-üzerine-yazma commit'i, Chroma ise her satır için bir HTTP eklemesi öder; bu nedenle en hızlı statik derleyiciler değişim altında en yavaş olur. Buradaki yazma verimi, eşzamanlı okumalar altında 150/s hedefe karşı ulaşılan orandır; bu nedenle hızlı motorlar zirvelerini göstermek yerine 150 civarında sınırlanır. Bunu toplu veri alımı değil, tek satırlık, yüksek frekanslı çevrimiçi yazma davranışı olarak okuyun; toplu alım bu motorların tasarım noktasıdır ve burada test edilmemiştir.

Silme ve sıkıştırma. Canlı kümenin rastgele %20'sini silip %20 yeni belge yeniden eklerken, tombstone sızıntısı her motorda sıfırdı. Silinen bir id aramada asla yeniden ortaya çıkmadı ve tam döngü sonrasında Recall@10 0.97 ile 1.00 arasında kaldı. Değişim altında doğruluk her yerde korunur. Maliyet motora göre değişir. pgvector 53 saniyelik VACUUM, Milvus 11 saniyelik sıkıştırma öder; yavaş yazan motorların yeniden eklemesi ise baskındır (yaklaşık 6.000 belge için Chroma 276 sn, LanceDB 1139 sn).

Weaviate bu bölümü 3.000 başlangıç belgesiyle 30.000 yerine çalıştırdı (senkron toplu alımı küçük kutuda yavaştır); bu nedenle okuma QPS değeri daha küçük bir külliyata aittir. Bu ölçekte düzeltilmiş güncelliği yaklaşık 5 ms ve yazma oranı yaklaşık 102/s'dir; bu da her ikisini orta sıraya yerleştirir.

Metrikler açıklandı

ANN Recall@10, DB'nin indekslediği aynı embedding'ler üzerindeki tam kaba kuvvet kNN oracle'a göre 10 gerçek en yakın vektörün yaklaşık indeks tarafından döndürülen kesridir. Bu, embedding'i değil veritabanını (indeks türü, ef/nprobe, uygulama) izole eder.

nDCG@10, insan etiketli doğru belgenin sonuç listesinin üst sırasına yakın olup olmadığını gösteren konum ağırlıklı 0-1 arası bir puandır. Bu, uçtan uca getirme alaka düzeyini ölçer; bu büyük ölçüde embedding modelinin bir özelliğidir ve burada her motorda sabit tutulmuştur.

Δ (delta köprüsü), belirli bir arama ayarında oracle'ın nDCG@10 değerinden veritabanının nDCG@10 değerinin çıkarılmasıdır. Her motorun yaklaşım hatasını, hızının maliyetlendirdiği yanıt kalitesine dönüştürür; bunu raporlayabiliriz çünkü hem bir oracle hem de insan etiketleri elimizde bulunur.

Vektör veritabanı kıyaslamasından bulgular

Yedi motor getirme doğruluğunda berabere

MedRAG-50k üzerinde Recall@10 = 0.95 iken nDCG@10, 0.803 (pgvector) ile 0.817 (LanceDB) arasında yer alır; fark 0.014'tür. Delta-oracle köprüsü 0.009 (LanceDB) ile 0.023 (pgvector) arasında çalışır; bu nedenle veritabanının yaklaşımı yanıt kalitesinden en fazla 0.023 nDCG puanına mal olur.

Bu embedding, külliyat, k=10 ve 0.95 çalışma noktasında, veritabanı seçimi nDCG@10 değerini en fazla 0.014 değiştirir; bu, yukarıda gösterilen tek iş parçacıklı verimdeki 10x farka ve tepe bellekteki 3.7x farka karşı küçüktür. İndeks seçimi, Recall@10 = 0.99 veya daha yüksekte, daha büyük k'de, çok daha büyük külliyatlarda veya nicemlenmiş indekslerde kaliteyi etkilemeye başlar.

Getirme güvenilirliği, hangi veritabanının yanıtladığından çok sorgunun ne sorduğuna göre değişir. Tam-kNN oracle üzerindeki 154 MedRAG sorgusunda, factoid aramalar 0.888 nDCG@10 puanı, koşullu sorular 0.836, karşılaştırmalı sorular 0.779 ve madde-varlığı soruları 0.763 puanı alır. Factoid ile madde-varlığı arasındaki 0.125 fark, yedi motorun tümünde aynı şekilde mevcuttur.

Meta veri filtreleri verimi maliyetlendirir, recall'ı değil

Bir meta veri koşulu uygulandığında, en kötü durum Recall@10 değeri 0.968 (Redis) ile 1.00 (Weaviate, pgvector, LanceDB) arasında kalır; seçicilik (1/5/20/%50) ve koşul korelasyonu (dağınık ve kümelenmiş) ızgarasında. Ayrım filtrelenmiş verimdedir.

Ayrım verimdedir. Chroma (11-19 QPS) ve pgvector (10-56 QPS), recall değerini diğerlerine göre 20 ila 40x daha düşük filtrelenmiş verimde tutar. Milvus, seçicilik boyunca 268 ila 732 QPS ile en yüksek en kötü durum recall değerini (0.984) korurken, Redis düşük seçicilikte (%1'de 1.374 QPS) daha düşük bir recall tabanında (0.968) en hızlı çalışır. 1-%5 seçicilikte, 1.00 recall değeri büyük ölçüde her motorun tam tarama eşiğinin altındaki sorgu planlayıcısının tam tarama dalıdır; filtre edilebilir HNSW değildir, motor başına açıklanmıştır.

*LanceDB'nin filtrelenmiş recall değeri ilk olarak kümelenmiş filtrelerde 0.24 ölçüldü, sonra geri çekildi. Tarama ef değiştirdi, ancak LanceDB'nin recall ayarı nprobes olduğundan, varsayılan olarak bölümlerin yaklaşık %9'unda çalıştı. Uygun nprobes değerlerinde yeniden ölçüldüğünde, kümelenmiş Recall@10 0.24'ten 0.76'ya (nprobes=128) ve yaklaşık 1.00'e (nprobes=256) yükselir; 3 ila 5x daha düşük QPS ile. LanceDB filtrelenmiş recall değerini yavaşça korur. Recall eşleşmeli, aynı ana bilgisayarda filtrelenmiş verim yeniden ölçümü hâlâ beklemede olduğundan LanceDB'nin filtrelenmiş QPS değeri listelenmemiştir.

Hibrit arama 0.067 nDCG'ye kadar ekler

Standart bir BM25 anahtar kelime kolu eklemek ve onu yoğun kolla karşılıklı sıra fusion (RRF, k=60) ile birleştirmek, anahtar kelime koluna sahip her motorda nDCG@10 değerini 0.030 ile 0.067 arasında artırır. MedRAG'da yoğun ve BM25 kolları tek yaklaşık eşit güçtedir (her biri yaklaşık 0.80), bu nedenle artış bir kolun baskın olmasından çok her kolun hatalarını telafi eder.

Güçlü BM25 koluna sahip motorlar en çok kazanır; pgvector ve Weaviate ise daha zayıf anahtar kelime kollarını takip ederek daha az kazanır (0.740 ve 0.782). Doğru ölçüldüğünde hiçbir motorun hibrit değeri yoğun kolunun altına düşmez.

Motorları ayıran, yerel fusion ile istemci tarafı round-trip'lerdir; Milvus yerel olarak 340 QPS'de, pgvector istemci tarafında 12 QPS'de. Dört motor yerel olarak fusion yapar (Qdrant, Milvus, Weaviate, LanceDB). Redis yerel BM25 ve KNN çalıştırır, ancak bu sürümde sunucu tarafı fusion yoktur; bu nedenle istemci iki round trip yapar ve Python'da birleştirir. pgvector hiçbir fusion API'sine sahip değildir, istemci tarafında birleştirir ve anahtar kelime kolu Postgres ts_rank'dir (uzunluk normalizasyonlu terim frekansı, IDF yok); bu, OR tam metin taramasıyla 12 QPS'de çalışır. Kendi barındırılan Chroma'da sıralanmış anahtar kelime araması hiç yoktur (BM25 bir Chroma Cloud özelliğidir), bu nedenle hibrit satırı yoktur.

İndeks derleme süresi 13x fark eder

50k vektörde indeks derleme süresi 7 saniye (LanceDB) ve 11 ile 13 saniye (Weaviate, Milvus) arasından 88 saniyeye (pgvector) kadar çıkar. 2.25M'de fark 13x'e ulaşır. LanceDB ve Milvus 7 ila 8 dakikada bitirir; Redis 44 dakika, pgvector 92 dakika sürer. Kutu ücretine normalize edildiğinde derleme maliyeti 1M vektör başına €0.04 (LanceDB) ve €0.05 (Milvus) ile €0.58 (pgvector) arasında değişir. Derleme tek seferlik bir maliyettir ve yalnızca külliyat yeniden indekslendiğinde tekrar ödenir.

2.25M vektörde getirme kalitesi

Gerçek insan etiketlerini korurken kaliteyi ölçekte test etmek için 2.25M-vektörlük bir külliyat oluşturduk. 50k etiketli MedRAG belgesini 2.2M pubmed çeldiricisiyle aynı bge-m3 uzayında birleştirir; bütünlük kontrolü yapılmıştır, böylece hiçbir çeldirici yanlış etiketlenmiş bir hedef değildir. Standart milyar ölçekli ANN veri kümeleri insan alaka etiketleri taşımadığından, bir sonraki aşamada ne olacağını gösteremezler.

Geometrik ANN recall değeri ölçekte korunur. Her motor hâlâ Recall@10 değerini 0.973'ün üzerinde yakalar; bu, 2.25M'de gerçekleşir (Qdrant ve Milvus 0.999 ile), bu nedenle indeks gerçek en yakın vektörleri bulur. Semantik yanıt kalitesi korunmaz. nDCG@10 her motorda yaklaşık 0.81'den 50k'de yaklaşık 0.56'ya 2.25M'de düşer; çünkü doğru belge 2.2M çeldiricinin arasına gömülüdür.

Bu çöküş bir veritabanı etkisi değildir. Tam-kNN oracle'ı da aynı şekilde vurur (oracle nDCG@10 değeri 2.25M'de 0.572'dir ve her motor bu tavanda 0.55 ile 0.57 arasında oturur). Nedenin embedding tavanı mı, külliyat belirsizliği mi, yoksa artık ilgili yakın kopyaları kaçıran tek olumlu etiketler mi olduğu burada karara bağlanmamıştır. Bu nedenleri ayırmak, yeni en üst sıradaki belgelerin insan tarafından yeniden etiketlenmesini gerektirir. Raporlanabilir gerçek şudur: külliyatı 45x ölçeklendirmek yanıt kalitesinin yaklaşık üçte birini silmiştir (nDCG@10 0.81'den 0.56'ya) ve yine de her ANN indeksi neredeyse mükemmel recall bildirir; bu, yalnızca geometrik bir kıyaslamanın kaçıracağı bir etkidir.

Motora göre dayanıklılık, HA ve güvenlik

Hız, bellek ve recall ölçülen eksenlerdir. Bir üretim RAG dağıtımı için ölçülmeyen eksenler (dayanıklılık, yüksek erişilebilirlik, erişim kontrolü) bu motorları da ayırır. Bu yetenek envanteri, her motorun kıyaslanan açık kaynak sürümdeki resmi belgelerine dayanır. Bu bir yetenek envanteridir, kaos testi değildir. Gerçek failover süresi, çökme kurtarma veri kaybı penceresi ve yük altında kiracı izolasyonu burada ölçülmemiştir.

Yedi motor arasında yalnızca pgvector zamanda geri alımlı kurtarma (Postgres WAL arşivleme yoluyla) ve satır düzeyi güvenlik sunar. Qdrant, Milvus ve Weaviate açık kaynak derlemelerinde çoğaltma ve RBAC sağlar; ancak Milvus'un yüksek erişilebilirliği burada ölçülen bağımsız derlemede değil, daha ağır dağıtık modda bulunur. Yedi motordan hiçbiri disk üzerindeki verileri yerel olarak şifrelemez. Hepsi altyapı katmanında disk veya birim şifrelemesine dayanır.

Bir filtrenin erişim kontrolü sınırı olarak da görev yaptığı çok kiracılı RAG için Qdrant, Milvus, Weaviate ve pgvector, veritabanı içinde kiracı izolasyonu uygulayabilir. Chroma ve gömülü LanceDB bunu uygulamaya iter. Doğru bir ön filtre, başka bir kiracının belgelerini sızdırmak yerine eksik döndürür; bu bir bütünlük riskidir. Kiracılar arası sızıntı, bu motorların hiçbirinin kullanmadığı hatalı bir son filtre gerektirir.

Yaklaşık en yakın komşu araması nasıl çalışır

Bir vektör veritabanı her belge için yüksek boyutlu bir vektör saklar ve bir sorgu vektörü verildiğinde bir uzaklık metriğine göre (burada L2-normalize vektörler üzerinde kosinüs) en yakın k vektörü döndürür. Tam en yakın komşu araması sorguyu saklanan her vektörle karşılaştırır; bu doğrudur ancak külliyat boyutuyla doğrusal ölçeklenir. 50k vektörde bu hızlıdır. Milyonlarda sunulması çok yavaştır.

Yaklaşık en yakın komşu (ANN) indeksleri, saklanan vektörlerin bir kısmını aramak için bir miktar doğruluktan vazgeçer. Bu motorlardaki baskın yapı HNSW'dir; kaba bir giriş noktasından yoğun bir komşuluğa yürüyen ve bir arama ayarı (ef HNSW için, nprobe IVF için) tarafından belirlenen sınırlı sayıda adayı ziyaret eden katmanlı bir yakınlık grafıdır. Daha büyük ef daha fazla aday ziyaret eder, recall değerini artırır ve QPS'yi düşürür. Daha küçük ef tersini yapar.

Bu ayar sürekli olarak recall ile hız arasında takas yaptığından, iki motoru tek bir sabit ayarda karşılaştırmak yanıltıcıdır; çünkü biri hızı için daha fazla doğruluk harcıyor olabilir. Adil karşılaştırma ayarı tarar, her motorun recall-QPS eğrisini çizer ve tümünü aynı recall değerinde okur. Bu eşleşen recall noktası (burada Recall@10 = 0.95), bu kıyaslamadaki QPS, gecikme ve bellek sayılarının alındığı yerdir.

Kıyaslamalarımızı ve veri odaklı içgörülerimizi kaçırmayın. Düğme Google'ı açar; AIMultiple'ı seçmeniz, Google arama sonuçlarında AIMultiple'ı daha sık görmek istediğinizi onaylar.

Tercih edilen kaynak olarak ekle

Kıyaslama metodolojisi

Motorlar. Qdrant v1.18.1, Milvus v2.6.0, Weaviate 1.38.0, pgvector 0.8.x (Postgres 17), Chroma 1.5.0, Redis/RediSearch 8.2 ve LanceDB 0.34.0, sabitlenmiş Docker görüntüleriyle kullanıldı. Redis kalıcılık kapalıyken çalıştı (RDB anlık görüntüsü veya append-only dosyası yok).

Donanım. Doğruluk, hız, bellek, filtrelenmiş ve derleme için bir Hetzner CCX53 (32 adanmış vCPU, 128 GB RAM, NVMe, nbg1); aynı anda bir konteyner çalıştı, her indeks derlemesi için yeni bir konteyner ve aynı yerde konumlandırılmış tek iş parçacıklı istemci kullanıldı. Canlı değişim boyutu bir CCX33 (8 vCPU, 32 GB) üzerinde çalıştı.

Embedding. bge-m3, 1024 boyut, L2-normalize float32 üzerinde kosinüs, k=10, tohum 42, motorlar arasında bayt bayta aynı. Sorgular tek olumlu insan etiketi taşır (target_doc_id).

Külliyatlar. Getirme kalitesi için MedRAG-50k (154 sorgu) ve TechQA-28k (151 sorgu); ölçek kademesi için 2.25M-vektörlük bir külliyat (50k etiketli artı 2.2M çeldirici) kullanıldı. Hibrit boyut yerel Docker'da yeniden çalıştırıldı; bu nedenle QPS'si kutu sayılarıyla değil, hibrit satırlar arasında karşılaştırılabilir. nDCG ve Δ değerleri donanımdan bağımsızdır.

İstatistikler. Ölçüm başına 100+ çalıştırma, 3.0x değerinde IQR aykırı değer kırpma, perf_counter_ns zamanlaması. 154 ila 246 sorguluk havuzlar kuyruk raporlamasını p95'te, bazen p99'da sınırlar. Bu sayılarda p99.9 tanımsızdır.

Çift temel doğruluk. Bir vektör veritabanının iki bağımsız temel doğruluğu vardır ve bu kıyaslama her ikisini de puanlar. Geometrik temel doğruluk (aynı vektörler üzerindeki tam kaba kuvvet oracle'a karşı ANN Recall@10) indeksin gerçek en yakın vektörleri döndürüp döndürmediğini sorar ve veritabanını izole eder. Semantik temel doğruluk (insan etiketlerine karşı nDCG@10, MRR, Hit@k) döndürülen belgelerin ilgili olup olmadığını sorar; bu büyük ölçüde sabit tutulan embedding'dir. Embedding dondurulduğu için motorları ham semantik puanlara göre sıralamak embedding'i sıralamak olur. Veritabanının gücü, eşleşen ANN recall'da hız ve bellek olarak ortaya çıkar ve Δ köprüsü yaklaşım kaybını yanıt kalitesine dönüştürür.

Doğruluk çıpası. Her motor tarifi (filtre ve hibrit) tam sürümdeki resmi belgelerden alındı ve kodlamadan önce çelişkili biçimde doğrulandı. Hibrit boyut bağımsız bir BM25 yanıt anahtarı taşır (iki referans nDCG'de yaklaşık 0.81 değerinde hemfikirdir); bu nedenle ondan uzak puan alan herhangi bir motor bulgu değil, test donanımı hatası sinyali verir. Bu koruma, tümü bizim test donanımımızda olan üç ilk geçiş ölçüm hatasını işaretledi (Weaviate üzerinde eşzamansız indeks zamanlama artefaktı, yanlış bir Postgres sıralama fonksiyonu ve HNSW'nin ef ayarını yok saymasına neden olan bir SQL fusion hatası); biz bunları yedi motoru tek tutarlı ortamda yeniden ölçerek düzelttik; burada zaten doğru olan beş motor sayılarını tam olarak yeniden üretti. Eşzamanlılık ve değişim boyutları aynı çıpayı taşır (recall ve tombstone yeniden kontrolleri); bu nedenle hiçbir raporlanan sayı hızlı ama yanlış değildir.

İstatistiksel anlamlılık

Raporlanan her sayı, 100+ çalıştırma üzerinden bir bootstrap nokta tahminidir; %95 güven aralığı 1.000 yeniden örneklemeden gelir ve iki aralık örtüşmediğinde bir fark gerçek sayılır.

Hibrit artışı en yakın çağrıdır; bu nedenle onun aralıkları belirleyici kanıttır. Dört motor sıfırı geçer, ikisi geçmez:

Getirme doğruluğu aynı kuralın ters yönde okunmasıdır. Yedi motorun nDCG@10 değerleri 0.014 fark boyunca örtüşen aralıklara düşer; bu nedenle hiçbiri kazanmaz ve beraberlik bunu ifade eder. Hız ve bellek sıralamaları bu belirsizliğin çok dışında kalır; bootstrap gürültüsünü gölgede bırakan farklarla (10x tek iş parçacıklı verim, 3.7x tepe bellek).

Test edilen motorlar

Sınırlamalar

Redis kalıcılık kapalıyken çalıştı; bu nedenle bir AOF fsync yapılandırması, burada raporlanan geçici değerlerden yazma gecikmesini ve ayak izini değiştirir.

İnsan etiketleri tek olumludur (sorgu başına bir doğru belge), dereceli alaka veya açıklayıcılar arası uyum yoktur; bu nedenle nDCG@10, MRR@10 ve Hit@10 bu veride neredeyse aynı sinyali taşır. Embedding tasarım gereği sabit tutulur. Embedding aileleri, boyutları ve çok dilli davranış ayrı bir kıyaslamadır. Bu çalıştırma getirme katmanını izole eder. Bir RAG pipeline'ının reranker (çapraz kodlayıcı) ve LLM yanıt üretimi aşamaları kapsam dışıdır. Yönetilen bulut motorları (Pinecone, Zilliz ve diğerleri) daha sonraki bir aşamadadır. Dayanıklılık ve güvenlik karşılaştırması belgeye dayalıdır, kaos testiyle yapılmamıştır.

Daha fazla okuma

• Embedding modelleri kıyaslaması
• Reranker kıyaslaması
• Vektör veritabanı hesaplayıcı
• Açık kaynak embedding modelleri
• Çok dilli embedding modelleri
• Çok modlu embedding'ler
• Ajanik RAG çerçeveleri

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ı Kıyaslaması: RAG için 7 Açık Kaynak Motor}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/open-source-vector-databases}},
  note   = {AIMultiple. Erişim tarihi: 17 Temmuz 2026}
}

Değişiklik günlüğü

3 güncelleme

1. 202617 Tem

   Karşılaştırılan vektör veritabanı listesinde Faiss, LanceDB ile değiştirildi.

2. 27 Şub

   Milvus, Qdrant ve Chroma'ya Son güncellemeler eklendi.

3. 202514 Ağu

   Makaleye "Açık kaynaklı vektör veritabanlarının temel özellikleri" başlıklı yeni bir bölüm eklendi.

Ekrem Sarı

Yapay Zeka Araştırmacısı

Takip Et

Ekrem, AIMultiple'da Yapay Zeka Araştırmacısı ve Veri Bilimcidir. Yapay zeka ve LLM sistemleri için uygulamalı benchmark'lar tasarlar ve yürütür.

Tam Profili Görüntüle

Yorum yapan ilk kişi olun

E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir. Yorumlar orijinal dilinde bırakılır.

Ad

E-posta Adresi

Yorum

0/450

Yorumu Gönder