Qdrant'tan 10 milyar vektörlük ücretsiz test verisi: Vektör veritabanlarını nasıl karşılaştırırsın?

Önce kısa bir hatırlatma

Bir metni yapay zekâ modeline verdiğinde, anlamını temsil eden bir sayı dizisi alırsın: vektör (embedding). Anlamca yakın metinlerin vektörleri de birbirine yakın düşer. Bir soruya en alakalı belgeleri bulmak (RAG, anlamsal arama) bu yüzden “en yakın komşuları bul” problemine dönüşür.

Milyonlarca vektörde her birine tek tek bakmak çok yavaş. Bu yüzden veritabanları yaklaşık arama yapar (HNSW gibi indekslerle). Hızlıdır ama bazen gerçek en yakın komşulardan birini kaçırır. Kaçırmama oranına recall denir: %95 recall, doğru cevapların yüzde 95’ini bulduğun anlamına gelir. Hız ile recall arasında hep bir takas var. Hızlıyım diyen bir veritabanının hangi recall seviyesinde hızlı olduğunu bilmeden grafiği okuyamazsın.

Mevcut testlerin iki sorunu

Better Stack’in videosu sorunu iki başlıkta topluyor:

1. Veri çok küçük. Yaygın test setleri bir milyon civarı vektör. Bu kadarı bir makinenin belleğine sığar, yani gerçek ölçekte diske taşan, parçalara bölünen bir sistemin davranışını göstermez.
2. Doğru cevaplar yok. Recall ölçmek için her sorgunun gerçek en yakın komşularını bilmen gerekir. Bunu milyarlarca vektörde kaba kuvvetle (brute force) hesaplamak çok pahalı olduğu için kimse yapmıyordu.

FineWeb-10B’de ne var?

Qdrant 1 Eylül’de Qdrant-FineWeb-10B setini Hugging Face’te yayınladı. Kaynak, Hugging Face’in Common Crawl’dan süzdüğü İngilizce web metni koleksiyonu FineWeb. İçindekiler:

• 10,07 milyar yoğun (dense) vektör, 768 boyutlu, gte-multilingual-base modeliyle üretilmiş. Aynı sayıda seyrek (sparse) vektör de var.
• Toplam yaklaşık 53 TB: 24,5 TB vektör, gerisi kaynak metin ve üst veri.
• 119.953 sorgu, her biri için ilk 1000 gerçek komşu. 100 bini düz yoğun arama, gerisi seyrek ve filtreli arama sorguları.
• Qdrant’a göre bu cevap anahtarı için GPU’larda bir katrilyondan fazla uzaklık hesaplandı.
• Lisans ODC-BY. Ama bir uyarı var: Sorgular MS MARCO’dan geliyor, o kısım sadece ticari olmayan araştırmaya açık ve dağıtılmıyor. Sorgu vektörlerini verilen betiklerle kendin üretiyorsun.

Seti üretmek için kullanılan araç zinciri de açık kaynak: Supernova (Apache-2.0). Vektör üretme, kaba kuvvetle doğru cevap hesaplama, veritabanına yükleme ve yük testi adımlarını ayrı komutlar olarak sunuyor. İşleri birden çok makineye dağıtabiliyor.

Dilim alınca cevap anahtarı bozulur

Videodaki en öğretici nokta bu. 53 TB’ı kimse evde indirmez, bir dilim alırsın. Ama hazır cevap anahtarı tüm 10 milyar vektöre göre hesaplandı. Bir sorgunun gerçek en yakın komşusu senin dilimin dışında kalmış olabilir. O zaman veritabanın kusursuz çalışsa bile recall düşük çıkar. Çözüm: Kendi dilimin için doğru cevapları yeniden, kaba kuvvetle hesaplamak. Better Stack’in paylaştığı betik tam olarak bunu yapıyor ve dört motoru bu tek cevap anahtarıyla ölçüyor.

Sonuçlar (videoya göre)

Her motorun “arama çabası” ayarı (Qdrant’ta hnsw_ef, Elasticsearch’te num_candidates gibi) adım adım artırılıp bir hız–recall eğrisi çizilmiş. Videoya göre Elasticsearch yaklaşık %94 recall’a kadar en hızlısı. Ama orada duruyor. Qdrant ve Milvus ise %98’e kadar tırmanmaya devam ediyor. Yani “en hızlı” cevabı, ne kadar doğruluğa ihtiyacın olduğuna bağlı.

Video bir uyarıyı da açıkça yapıyor: Bu hâlâ bir üreticinin hazırladığı veri seti. Fark şu ki veri ve araçlar açık, herkes kendi donanımında tekrar edebilir.

Düşün

• Senin uygulamanda %94 recall yeterli mi, yoksa kaçırılan her belge bir sorun mu?
• Kendi verin FineWeb’deki İngilizce web metnine ne kadar benziyor? Türkçe belgelerde sonuçlar aynı kalır mı?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.