Qdrant Turbo4 benchmark: TurboQuant'a karşı 9 kat depolama tasarrufu, 3 puana varan recall kaybı

Benchmark neyi ölçtü

dev.to'da yayımlanan tekrarlanabilir bir benchmark, Qdrant 1.19 ile gelen yalnızca depolamaya yönelik vektör veri tipi Turbo4 arkasındaki ödünleşime somut sayılar kazandırıyor. Turbo4 her vektörün yalnızca 4 bitlik sıkıştırılmış halini tutuyor ve float32 orijinallerini atıyor; böylece bir koleksiyonun depolama ayak izini deterministik biçimde 9 kat küçültüyor. Catch yapısal: Diskte tam hassasiyetli bir kopya kalmadığı için arama adaylarını yeniden puanlayacak bir şey yok ve 4 bitlik temsil üzerinde hesaplanan mesafe nihai skor oluyor. Geleneksel olarak nicemleme hatalarını düzelten güvenlik ağı tasarım gereği ortadan kalkmış durumda.

Baseline, çoğu üretim kullanıcısının Qdrant 1.18'de çalıştırdığı yapılandırma: Google Research'e atfedilen Hadamard dönüşümü tekniğine dayanan, sıkıştırmadan önce bilgiyi koordinatlar arasında eşit dağıtan 4 bitlik bir nicemleme katmanı olan TurboQuant. TurboQuant ikili kopya mimarisidir — HNSW grafiğinde hızlı tarama için RAM'de 4 bitlik bir kopya, artı son bir yeniden puanlama turu için diskte orijinal float32 vektörler. dev.to yazısına göre bu yapılandırma 1 milyon belgelik OpenAI koleksiyonunda %98,2 recall'a ulaştı; ancak tam hassasiyetli kopyalar pahalı: 1.536 boyutta yalnızca ham koordinatlar 6,9 GB yer kaplıyor ve 10 milyon belgelik bir büyüme, yeniden puanlama seçeneğini canlı tutmak için tek başına 65 GB'dan fazla talep edecekti.

Test nasıl yürütüldü

Yazar, 500.000 Wikipedia özeti üzerinde 384'ten 3.072 boyuta uzanan beş embedding modelini değerlendirdi — sonuçları yağlayacak sentetik kümeler yerine bilinçli olarak dağınık, çeşitli veriler. Tüm koşular aynı donanımı, aynı HNSW ayarlarını (m=16, ef_construct=128), kosinüs mesafesini ve sorgu kümelerini paylaştı; tek değişken depolama veri tipiydi. Ground truth, kapsamlı bir brute-force aramadan geldi ve recall, her yapılandırma için 1.000 sorgu üzerinden ortalandı.

Recall: Kazananı boyut belirliyor

Çoğu RAG pipeline'ının kullandığı ayar olan top-10 erişiminde Turbo4, modele bağlı olarak doğru sonuçların %96,1 ile %98,9'unu geri getirdi; yeniden puanlama etkinleştirilmiş TurboQuant'a karşı açık yaklaşık yarım puandan üç puana kadar değişti.

Embedding boyutu belirleyici değişken oldu. 384 boyutlu bir vektördeki yuvarlama hataları oransal olarak daha çok önem taşırken, 3.072 boyutlu bir vektörde büyük ölçüde birbirini götürüyor — benchmark'ın büyük sayılar yasasına atfettiği bir etki. Pratikte 384 boyuttaki açık, kabaca her 37 sorgudan birinin ilgili bir belgeyi kaybettiği anlamına geliyor; 1.536 boyut ve üzerinde bu oran yaklaşık 100'de bire düşüyor ve erişim adımının arkasındaki bir reranker genellikle kalan bu farkı da emiyor. Daha derin erişimde (k=100) açık hafifçe genişliyor, yine çoğunlukla daha kısa vektörlerde.

Depolama ve throughput

Depolama oranı ölçümden çok aritmetik: TurboQuant koordinat başına 36 bit depoluyor — 32 bitlik orijinal artı 4 bitlik sıkıştırılmış kopya — iken Turbo4 yalnızca 4 bitlik değeri depoluyor ve bu da 9 katlık azalmayı üretiyor. OpenAI'nin en büyük modelini kullanan 10 milyon vektörlük bir koleksiyon, TurboQuant altında yaklaşık 130 GB, Turbo4 altında ise kabaca 14,4 GB gerektiriyor; dev.to yazısı bu farkı, özel bir yüksek bellekli sunucu ile sıradan bir cloud instance arasında bir seçim olarak çerçeveliyor.

Throughput da mekanik bir nedenle Turbo4 lehine hareket etti. TurboQuant'ın yeniden puanlama turu, en iyi adayları için orijinal vektörleri diskten çekmek zorunda; oversampling, yeniden kontrol öncesinde ek adaylar getiriyor (örneğin 10'luk bir limit için 20 aday). Turbo4 orijinalleri hiç okumıyor çünkü hiç yok ve benchmark bu temelde arama hızında iyileşme raporluyor.

Neden önemli

Benchmark, bir vendor değer önerisini iki tarafı da nicelleştirilmiş bir mühendislik kararına dönüştürüyor. Aşağı akışında reranker bulunan, yüksek boyutlu embedding'lere (1.536 boyut ve üzeri) dayanan pipeline'lar için Turbo4'ün recall maliyeti yüz sorguda bir kayıp belge civarında; birçok ekip bunu, 9 kat depolama kesimi ve daha basit, daha hızlı tek kopyalı arama yolu karşılığında memnuniyetle kabul edecektir. Kısa 384 boyutlu vektörler veya k=100'deki derin erişim için ise doğruluk kaybı, ikili kopyalı TurboQuant yapılandırmasının ve disk yükünün sorumlu varsayılan olarak kalmasını gerektirecek kadar önemli. Daha geniş çerçevede, vektör veritabanı kullanıcılarının önündeki mimari seçimi açık hale getiriyor: birinci sınıf bir veri tipi olarak yalnızca sıkıştırılmış depolama mı, yoksa tam hassasiyetli verinin üzerine katmanlanan bir hızlandırıcı olarak nicemleme mi.