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

Yedi açık kaynak, kendi kendine barındırılan vektör veritabanını bir RAG pipeline'ının erişim katmanı olarak benchmark ettik; her biri aynı bge-m3 embedding'leri ve gerçek tıbbi ve teknik sorgular üzerinde teker çalıştırıldı, böylece veritabanı endeksi tek değişken oldu. İş yükü; doğruluk ve erişim kalitesinden hız, bellek, filtrelenmiş ve hibrit arama, oluşturma maliyeti ve canlı değişime kadar sekiz boyutta MedRAG-50k, TechQA-28k ve 2,25M vektörlük bir korpusu kapsadı.

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

Her motor aynı recall seviyesinde değerlendirilir; bu ortak çalışma noktasında arama parametresi (ef veya nprobe), Recall@10 değeri 0,95'e ulaşana kadar ayarlanır ve hız rakamlarının adil bir şekilde karşılaştırılmasına olanak tanır.

Tek bir istemci iş parçacığında Redis, MedRAG-50k üzerinde 764 QPS sunar ve 559 MB tepe RAM kullanır; bu, setteki en yüksek verim ve en düşük bellektir. Tek iş parçacıklı sıralama şöyledir: Redis 764, Qdrant 377, Milvus 342, Weaviate 341, pgvector 257, Chroma 197, LanceDB 70; baştan sona 10x yayılım. LanceDB, RAM'i gecikme ile takas eden disk üzerinde çalışan aykırı değerdir ve p95 değeri 22 ms civarındadır. Redis en hızlı, LanceDB ise TechQA-28k (651'e 81) ve 2,25M (495'e 28) üzerinde en yavaş olmaya devam eder; ancak orta sıralar ölçekte yeniden şekillenir, 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ı takip eder.

Redis kalıcılık kapalı olarak çalıştırıldı (RDB anlık görüntüsü veya append-only dosyası olmadan), bu nedenle hız ve bellek rakamları geçici, dayanıklılık olmayan bir yapılandırma içindir.

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ında verimdir ve cevap, istemcinin nasıl oluşturulduğuna bağlıdır, yalnızca veritabanına değil.

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

İstek eşzamanlılığı 32'ye kadar işçi süreci boyunca 1'den 512'ye yükseldikçe, verim çizgileri kesişir. Redis bir istekte en yüksekten başlar ve en düşükte biterken, Weaviate grubun en altından 512 istekte 8330 QPS'lik bir platoya tırmanır ve yolda 32'de 7.114'ü geçer. Tek bir asenkron süreçte sıralama bunun yerine Python istemci ayrıştırma verimliliğini izler, çünkü Redis'in RESP'i seri durumdan çıkarması en hafif olanıdır ve GIL'den en az kaybeder.

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

Redis setteki en düşük tek sorgu gecikmesine sahiptir (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 ters ölçeklenir (RediSearch'ün WORKERS sorgu iş parçacığı havuzu varsayılan olarak kapalıdır). Weaviate ve Milvus (çok iş parçacıklı sunucular) ve pgvector (bağlantı başına 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. 100ms altı p99 bütçesinde çok süreçli sıralama şöyledir: Weaviate 8290, pgvector 4828, Milvus 4725, Qdrant 1737, Redis 1642.

Qdrant'ın daha ağır gRPC ayrıştırması, eş konumlu sayısını bir sunucu sınırı yerine istemci sınırlı hale getirir, çünkü yalnızca süreç sayısı onu bir süreçte 455 QPS'den 32'de 1859'a taşır. Chroma ve LanceDB çok süreçli çalıştırmanın dışında tutuldu. Chroma ef'yi koleksiyon oluşturmada sabitler ve ters ölçeklenir, 512 istekte p99 değeri 13 saniyedir ve LanceDB gömülüdür, bu nedenle ağ istemci hikayesi geçerli değildir.

Bellek ayak izi

50k vektörde, tepe RAM 559 MB'den (Redis, RAM içi, kalıcılık kapalı) 3.300 MB'ye (Milvus) kadar uzanır; Weaviate 1.201'de, LanceDB 1.574'te, Chroma 1.800'de ve pgvector 2.024'tedir. Sıralama 2,25M'değişir; burada bellek içi-disk takası açılır.

2,25M'de beş bellek içi motorda tepe RAM, 17,0 GB'den (Milvus) 62,4 GB'ye (Chroma) kadar uzanır; 3,7x aralık veya milyon vektör başına 7,5 GB ila 27,7 GB. Milvus en düşük seviyede kalır çünkü endeksi diske yükler (DiskANN tarzı), tamamen RAM içi HNSW motorları ise en hızlı büyür; bu nedenle 50k'de en ağır (3.300 MB) olan Milvus, 2,25M'de en düşük (17,0 GB) olurken, Chroma 62,4 GB ile en ağırdır.

İki disk üzerinde motor, bu RAM karşılaştırmasının dışındadır çünkü ayak izleri RAM yerine disktir. pgvector 2,25M'de 18,4 GB disk üzerinde endeks, LanceDB ise 12,0 GB disk üzerinde endeks tutar ve sunum RAM'leri tam çalışma seti yerine bu endeks üzerinde bir sayfa önbelleğidir; bu ölçülmemiştir. Bellek içi rakamlarda da bir uyarı bulunur. Bunlar oluşturma ve sunumun en yüksek seviyesidir, yalnızca sunum ayak izi değil; bu nedenle yalnızca sunum yeniden ölçümü açık bir iyileştirmedir.

Canlı değişim altında tazelik, yazma ve silme

Diğer yedi boyut statik bir toplu yükleme ve ardından okuma korpusunu ölçer. Gerçek RAG bilgi tabanları, endeks arka planda birleşirken sürekli olarak doküman ekler, günceller ve siler. Bu değişim iş yükü, ayrı bir 8 vCPU'lu kutuda MedRAG-50k üzerinde çalıştırıldı; bu nedenle verimi bu bölüme özeldir ve 32 çekirdekli hız rakamlarıyla karşılaştırılamaz. Doğruluk sinyalleri (recall ve mezar taşı kontrolleri) donanımdan bağımsızdır.

Tazelik (yazma sonrası okuma). Her motorun yapılandırıldığı tutarlılık ayarında, hepsi yazma sonrası okumadır. Yeni yazılan bir doküman hemen aranabilir ve yaklaşık 150 yazmadan sıfırı görünmez. Yazma onayından aramada görünürlüğe gecikme Redis için 2 ms p50, 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 grafına daha sonra girer), bu nedenle 12 ms'si büyüyen segment aranabilirliğidir; geçerli bir kullanıcıya dönük yazma sonrası okumadır.

Karma yük altında yazma ve okuma. 150 yazma/s hedefleyen bir yazıcı ve 60 saniye boyunca sorgulayan altı okuyucu ile okuma recall'ı her motor için 0,96 ile 1,00 arasında kaldı ve hiçbir endeks eşzamanlı yazmalar altında bozulmadı. Tek satır yazma verimi motorları 57x ayırır ve sıralama statik oluşturma sıralamasının neredeyse tersidir.

LanceDB satır başına bir yazma üzerine kopyalama commit'i, Chroma ise satır başına bir HTTP eklemesi öder; bu nedenle en hızlı statik oluşturucular değişim altında en yavaştır. Buradaki yazma verimi, eşzamanlı okumalar altında 150/s hedefine karşı elde edilen orandır; bu nedenle hızlı motorlar zirvelerini göstermek yerine 150 civarında sınırlanır. Bunu toplu alım değil, tek satırlı, 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ı setin rastgele %20'sini silip %20 yeni doküman yeniden eklerken, mezar taşı sızıntısı her motor için sıfırdı. Silinen bir kimlik aramada asla yeniden ortaya çıkmadı ve Recall@10 tam döngüden sonra 0,97 ile 1,00 arasında kaldı. Doğruluk değişim altında her yerde korunur. Maliyet motora göre farklılık gösterir. pgvector 53 saniyelik bir VACUUM, Milvus ise 11 saniyelik bir sıkıştırma öderken, yavaş yazma yapan motorların yeniden eklemesi baskındır (Chroma yaklaşık 6.000 doküman için 276 s, LanceDB 1139 s).

Weaviate bu bölümü 30.000 yerine 3.000 başlangıç dokümanında çalıştırdı (senkron toplu alımı küçük kutuda yavaştır), bu nedenle okuma QPS'si daha küçük bir korpustadır. Bu ölçekte düzeltilmiş tazeliği yaklaşık 5 ms ve yazma hızı yaklaşık 102/s'dir; bu da her ikisini orta sıralara yerleştirir.

Metrikler açıklandı

ANN Recall@10, veritabanının endekslediği aynı embedding'ler üzerinde kesin kaba kuvvet kNN oracle'ına göre 10 gerçek en yakın vektörün yaklaşık endeks tarafından döndürülen kesridir. Embedding'i değil, veritabanını (endeks türü, ef/nprobe, uygulama) izole eder.

nDCG@10, insan etiketli doğru dokümanın sonuç listesinin üst sıralarına yakın olup olmadığını gösteren konum ağırlıklı 0-1 arası bir puandır. Uçtan uca erişim ilgililiğini ölçer; bu, büyük ölçüde burada her motorda sabit tutulan embedding model'in bir özelliğidir.

Δ (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 cevap kalitesine dönüştürür; hem bir oracle hem de insan etiketleri tuttuğumuz için raporlanabilir.

Vektör veritabanı benchmark bulguları

Yedi motor erişim doğruluğunda eşit

MedRAG-50k üzerinde Recall@10 = 0,95'te, nDCG@10 0,803 (pgvector) ile 0,817 (LanceDB) arasında yer alır; 0,014 yayılım. Oracle'a delta köprüsü 0,009 (LanceDB) ile 0,023 (pgvector) arasında uzanır; bu nedenle veritabanının yaklaşımı en fazla 0,023 nDCG puanı cevap kalitesine mal olur.

Bu embedding, korpus, k=10 ve 0,95 çalışma noktası altında, veritabanı seçimi nDCG@10'u en fazla 0,014 hareket ettirir; buna karşılık yukarıda gösterilen tek iş parçacıklı verimde 10x yayılım ve tepe bellekte 3,7x yayılım. Endeks seçimi kaliteyi Recall@10 = 0,99 veya daha yüksekte, daha büyük k'de, çok daha büyük korpuslarda veya nicemlenmiş endekslerle hareket ettirmeye başlar.

Erişim güvenilirliği, hangi veritabanının yanıtladığından çok bir sorgunun ne sorduğuna göre değişir. Kesin kNN oracle'ında 154 MedRAG sorgusu üzerinde, olgusal aramalar 0,888 nDCG@10, koşullu sorular 0,836, karşılaştırmalı sorular 0,779 ve cümle-varlık soruları 0,763 puan alır. Olgusal ve cümle-varlık arasındaki 0,125 fark, yedi motorun tamamında aynı şekilde mevcuttur.

Metadata filtreleri verimi düşürür, recall'ı değil

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

Ayrım verimdir. Chroma (11-19 QPS) ve pgvector (10-56 QPS), recall'ı diğerlerinden 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'ını (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'ı büyük ölçüde her motorun tam tarama eşiğinin altındaki sorgu planlayıcısının kesin tam tarama dalıdır, filtrelenebilir HNSW değil; motor başına açıklanmıştır.

*LanceDB'nin filtrelenmiş recall'ı ilk olarak kümelenmiş filtrelerde 0,24 olarak ölçüldü, sonra geri çekildi. Tarama ef değiştirildi, ancak LanceDB'nin recall ayarı nprobes'dir; bu nedenle bölümlerin yaklaşık %9'u varsayılanında çalıştı. Uygun nprobes'te yeniden ölçüldüğünde, kümelenmiş Recall@10 0,24'ten 0,76'ya (nprobes=128) ve yaklaşık 1,00'e (nprobes=256) kadar toparlanır; 3 ila 5x daha düşük QPS ile. LanceDB filtrelenmiş recall'ı yavaşça korur. Recall eşleşmeli, aynı sunucuda filtrelenmiş verim yeniden ölçümü hala beklemededir; bu nedenle LanceDB'nin filtrelenmiş QPS'si listelenmemiştir.

Hibrit arama 0,067 nDCG'ye kadar ekler

Standart bir BM25 anahtar kelime kolu ekleyip bunu karşılıklı sıra fusion (RRF, k=60) ile yoğun kolla birleştirmek, bir anahtar kelime kolu olan her motor için nDCG@10'u 0,030 ila 0,067 artırır. MedRAG'da yoğun ve BM25 kolları bireysel olarak neredeyse eşit güçtedir (her biri yaklaşık 0,80), bu nedenle artış bir kolun baskın olmasından ziyade her kolun hatalarını telafi eder.

Güçlü BM25 koluna sahip motorlar en fazla kazancı elde eder ve pgvector ile Weaviate daha zayıf anahtar kelime kollarını (0,740 ve 0,782) takip ederek daha az kazanır. Doğru ölçüldüğünde hiçbir motorun hibriti yoğun kolunun altına düşmez.

Motorları ayıran şey, yerel fusion ile istemci tarafı gidiş-gelişlerdir; Milvus 340 QPS yerelden, pgvector 12 QPS istemci tarafına kadar. Dört motor yerel olarak birleştirir (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 gidiş-geliş yapar ve Python'da birleştirir. pgvector'ın fusion API'si yoktur, istemci tarafında birleştirir ve anahtar kelime kolu Postgres ts_rank'dir (uzunluk normalleştirmeli terim frekansı, IDF yok), bu da bir OR tam metin taramasıyla 12 QPS'de çalışır. Kendi kendine barındırılan Chroma'nın hiç sıralı anahtar kelime araması yoktur (BM25 bir Chroma Cloud özelliğidir), bu nedenle hibrit satırı yoktur.

Endeks oluşturma süresi 13x aralığında

50k vektörde, endeks oluşturma 7 saniyeden (LanceDB) ve 11 ila 13 saniyeden (Weaviate, Milvus) 88 saniyeye (pgvector) kadar sürer. 2,25M'de yayılım 13x'e ulaşır. LanceDB ve Milvus 7 ila 8 dakikada tamamlarken, Redis 44 dakika ve pgvector 92 dakika sürer. Kutu ücretine normalize edildiğinde, oluşturma maliyeti 1M vektör başına €0,04 (LanceDB) ve €0,05'ten (Milvus) €0,58'e (pgvector) kadar uzanır. Oluşturma tek seferlik bir maliyettir, yalnızca korpus yeniden endekslendiğinde tekrar ödenir.

2,25M vektörde erişim kalitesi

Gerçek insan etiketlerini korurken ölçekte kaliteyi test etmek için 2,25M vektörlük bir korpus oluşturduk. 50k etiketli MedRAG dokümanını 2,2M pubmed çeldiricisi ile birleştirir; hepsi aynı bge-m3 uzayındadır, 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 setleri insan ilgililik etiketleri taşımaz, bu nedenle sonra ne olacağını gösteremezler.

Geometrik ANN recall'ı ölçekte korunur. Her motor 2,25M'de hala Recall@10 değerini 0,973'ün üzerinde tutar (Qdrant ve Milvus 0,999'da), böylece endeks gerçek en yakın vektörleri bulur. Anlamsal cevap kalitesi korunmaz. nDCG@10, 50k'de yaklaşık 0,81'den 2,25M'de yaklaşık 0,56'ya düşer; çünkü doğru doküman 2,2M çeldirici arasında gömülüdür.

Çöküş bir veritabanı etkisi değildir. Kesin kNN oracle'ını aynı şekilde vurur (2,25M'de oracle nDCG@10 0,572'dir ve her motor bu tavanda yaklaşık 0,55 ila 0,57 arasında oturur). Sebebin embedding'in tavanı mı, korpus belirsizliği mi, yoksa şimdi ilgili olan yakın kopyaları kaçıran tek pozitif etiketler mi olduğu burada karara bağlanmamıştır. Bu nedenleri ayırmak, yeni en üst sıradaki dokümanların insan tarafından yeniden etiketlenmesini gerektirir. Raporlanabilir gerçek, korpusu 45x ölçeklendirmenin, her ANN endeksi mükemmele yakın recall raporlarken cevap kalitesinin yaklaşık üçte birini sildiğidir (nDCG@10 0,81'den 0,56'ya); geometrik odaklı bir benchmark'ın kaçıracağı bir etki.

Motora göre dayanıklılık, yüksek erişilebilirlik 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ü) de bu motorları ayırır. Bu yetenek envanteri, benchmark edilen açık kaynak sürümünde her motorun resmi dokümantasyonundan belgelenmiştir. Bu bir yetenek envanteridir, kaos testi değildir. Gerçek yük devri 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 belirli bir noktaya kurtarma (Postgres WAL arşivleme yoluyla) ve satır düzeyinde güvenlik sunar. Qdrant, Milvus ve Weaviate açık kaynak yapılarında replikasyon ve RBAC sunar; Milvus'un yüksek erişilebilirliğinin burada ölçülen bağımsız yapıda değil, daha ağır dağıtık modda olduğu uyarısıyla. Yedi motordan hiçbiri disk üzerinde veriyi yerel olarak şifrelemez. Hepsi altyapı katmanında disk veya birim şifrelemesine dayanır.

Bir filtrenin erişim kontrol sınırı olarak ikiye katlandığı ç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 dokümanlarını sızdırmak yerine eksik döndürür; bu bir tamlı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ı, doküman başına bir yüksek boyutlu vektör depolar 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 tanesini döndürür. Kesin en yakın komşu araması, sorguyu depolanan her vektöre karşı karşılaştırır; bu doğrudur ancak korpus boyutuyla doğrusal ölçeklenir. 50k vektörde bu hızlıdır. Milyonlarda sunum için çok yavaştır.

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

Bu ayar recall ile hızı sürekli olarak takas ettiğinden, 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 hepsini aynı recall'da okur. Bu eşleşen recall noktası (burada Recall@10 = 0,95), bu benchmark'taki QPS, gecikme ve bellek rakamları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

Benchmark 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 imajlarında. Redis kalıcılık kapalı olarak çalıştırıldı (RDB anlık görüntüsü veya append-only dosyası olmadan).

Donanım. Doğruluk, hız, bellek, filtrelenmiş ve oluşturma için bir Hetzner CCX53 (32 özel vCPU, 128 GB RAM, NVMe, nbg1); her seferinde bir konteyner çalışır, endeks oluşturma başına taze konteyner ve eş konumlu tek iş parçacıklı istemci. Canlı değişim boyutu bir CCX33 (8 vCPU, 32 GB) üzerinde çalıştırıldı.

Embedding. bge-m3, 1024 boyut, L2 normalize float32 üzerinde kosinüs, k=10, seed 42, motorlar arasında bayt olarak özdeş. Sorgular tek pozitif insan etiketleri taşır (target_doc_id).

Korpuslar. Erişim kalitesi için MedRAG-50k (154 sorgu) ve TechQA-28k (151 sorgu) ve ölçek katmanı için 2,25M vektörlük bir korpus (50k etiketli artı 2,2M çeldirici). Hibrit boyutu yerel Docker'da yeniden çalıştırıldı, bu nedenle QPS'si kutu rakamlarıyla değil hibrit satırlar arasında karşılaştırılabilir. nDCG ve Δ donanımdan bağımsızdır.

İstatistikler. Ölçüm başına 100+ çalıştırma, 3,0x'te 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. p99.9 bu sayılarda tanımsızdır.

Çift zemin gerçeği. Bir vektör veritabanının iki bağımsız zemin gerçeği vardır ve bu benchmark her ikisini de puanlar. Geometrik zemin gerçeği (aynı vektörler üzerinde kesin kaba kuvvet oracle'ına karşı ANN Recall@10), endeksin gerçek en yakın vektörleri döndürüp döndürmediğini sorar ve veritabanını izole eder. Anlamsal zemin gerçeği (insan etiketlerine karşı nDCG@10, MRR, Hit@k), döndürülen dokümanların ilgili olup olmadığını sorar; bu büyük ölçüde sabit tutulan embedding'dir. Embedding dondurulduğu için motorları ham anlamsal puanlara göre sıralamak embedding'i sıralar. Veritabanının gücü, eşleşen ANN recall'ında hız ve bellek olarak gösterilir ve Δ köprüsü yaklaşım kaybını cevap kalitesine dönüştürür.

Doğruluk çapası. Her motor tarifi (filtre ve hibrit), tam sürümde resmi dokümanlardan alındı ve kodlamadan önce çekişmeli olarak doğrulandı. Hibrit boyutu bağımsız bir BM25 cevap anahtarı taşır (iki referans yaklaşık 0,81 nDCG'de uyuşur), bu nedenle ondan uzak puan alan herhangi bir motor bir bulgu değil, test düzeneği hatası sinyali verir. Bu koruma, üç ilk geçiş ölçüm hatasını işaretledi; hepsi bizim test düzeneğimizdeydi (Weaviate'ta bir asenkron endeks zamanlama yapaylığı, yanlış bir Postgres sıralama fonksiyonu ve HNSW'nin ef ayarını görmezden gelmesine neden olan bir SQL fusion hatası); bunları, beş zaten doğru motorun rakamlarını tam olarak yeniden ürettiği tek bir tutarlı ortamda yedi motorun tamamını yeniden ölçerek düzelttik. Eşzamanlılık ve değişim boyutları aynı çapayı taşır (recall ve mezar taşı yeniden kontrolleri), bu nedenle hiçbir raporlanan rakam hızlı-ama-yanlış değildir.

İstatistiksel anlamlılık

Her raporlanan rakam, 1.000 yeniden örneklemeden %95 güven aralığı ile 100+ çalıştırma üzerinde bir bootstrap nokta tahminidir ve bir fark, iki aralık örtüşmediğinde gerçek olarak sayılır.

Hibrit artışı yakın çağrıdır, bu nedenle aralıkları belirleyici kanıttır. Dört motor sıfırı aşar ve ikisi aşmaz:

Erişim doğruluğu aynı kuralın diğer yönden okunmasıdır. Yedi motorun nDCG@10 değerleri 0,014 yayılım boyunca örtüşen aralıklar içinde kalır; bu nedenle hiçbiri kazanmaz, eşitliğin anlamı budur. Hız ve bellek sıralamaları bu belirsizliğin çok dışında kalır; boşluklar (10x tek iş parçacıklı verim, 3,7x tepe bellek) bootstrap gürültüsünü gölgede bırakır.

Test edilen motorlar

Sınırlamalar

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

İnsan etiketleri tek pozitiftir (sorgu başına bir doğru doküman), dereceli ilgililik 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 tutulmuştur. Embedding aileleri, boyutlar ve çok dilli davranış ayrı bir benchmark'tır. Bu çalıştırma erişim katmanını izole eder. Bir RAG pipeline'ının yeniden sıralayıcı (cross-encoder) ve LLM cevap üretimi aşamaları kapsam dışındadır. Yönetilen bulut motorları (Pinecone, Zilliz ve diğerleri) daha sonraki bir aşamadır. Dayanıklılık ve güvenlik karşılaştırması belge temellidir, kaos testi değildir.

Daha fazla okuma

• Embedding model benchmark'ı
• Yeniden sıralayıcı benchmark'ı
• Vektör veritabanı hesaplayıcısı
• Açık kaynak embedding modeller
• Çok dilli embedding modeller
• Çok modlu embedding'ler
• Ajan temelli RAG framework'leri

Bu araştırmayı 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ı Benchmark: 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}
}

Ekrem Sarı

Yapay Zeka Araştırmacısı

Takip Et

Ekrem, AIMultiple'da yapay zeka araştırmacısı olarak çalışmakta olup, akıllı otomasyon, GPU'lar, yapay zeka ajanları ve RAG çerçeveleri üzerine yoğunlaşmaktadı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