3 milyar vektörü sorgulamak

(vickiboykis.com)

13 puan yazan GN⁺ 2026-03-09 | Henüz yorum yok. | WhatsApp'ta paylaş

Jeff Dean’in 3 milyar vektör sorgulama problemi nedeniyle, en uygun map-reduce çözümünü bizzat uygulama sürecini ele alan bir teknik deney kaydı
768 boyutlu float32 vektörlerden 3 milyar adet ve 1.000 sorgu vektörü için dot product hesaplayan naive uygulamayla başlayıp, numpy vektörizasyonu ve float32 dönüşümüyle adım adım performans iyileştirmesi elde ediliyor
3.000 vektör bazında naive yöntem yaklaşık 2 saniyeden, vektörizasyon sonrası 0,01 saniyeye; float32 uygulanınca 0,0045 saniyeye kadar düşüyor
Ölçek 3 milyara çıkarıldığında sonuç matrisi yaklaşık 8,6 TB bellek gerektiriyor ve OOM sorunu ortaya çıkıyor; toplu işleme, bellek eşleme, Rust/C ile yeniden yazım, SimSIMD gibi ek optimizasyonlar gerekiyor
Teknik çözümden çok, gereksinimlerin tanımlanmasının (dönüş biçimi, makine özellikleri, sıkıştırmaya izin verilip verilmemesi vb.) daha zor olan asıl mesele olduğu vurgulanıyor

Problemin çıkış noktası

Jeff Dean ve 3 milyar vektör sorgulama problemi hakkındaki paylaşımları gördükten sonra, en uygun map-reduce çözümünü doğrudan uygulamayı deneme girişimiyle başlanıyor
Vektörler, n boyutlu kayan noktalı sayı dizileri ve vektör arama anlamsal olarak benzer kelime ya da öğeleri bulmak için kullanılıyor
Arama, öneri sistemleri ve Cursor gibi üretken arama uygulamalarında embedding kullanımının yaygın bir örüntüsü olduğu belirtiliyor

Başlangıç varsayımı: Aranacak 3 milyar belge vektörü ve yaklaşık 1.000 sorgu vektörü var; hepsi diskte .npy biçiminde saklanıyor
Vektör boyutu 768; bu, birçok benzerlik tabanlı embedding sorgu modelinde kullanılan yaygın bir büyüklük
Her sorgu vektörünü tüm belge vektörleriyle karşılaştırıp dot product hesaplayan çift döngülü bir yöntem kullanılıyor
Önce 3.000 vektörle test edildiğinde, M2 MacBook üzerinde yaklaşık 2 saniye sürdüğü görülüyor (3 milyara göre 1 milyon kat daha küçük ölçek)

numpy’nin matris çarpımı işlemi (vectors_file @ query_vectors.T) ile çift döngünün yerine vektörize yaklaşım uygulanıyor
3.000 vektör bazında süre 0,0107 saniyeye kadar ciddi biçimde iyileşiyor
3 milyon vektöre ölçeklendiğinde süre 12,85 saniye oluyor

Veriler np.float32 tipine dönüştürülerek ek optimizasyon yapılıyor
3.000 vektör bazında süre 0,0045 saniyeye kadar düşüyor
3 milyon vektörde yaklaşık 13 saniye sürdüğü için, 3 milyarda bunun 1.000 katı olan yaklaşık 3.216 dakika süreceği tahmin ediliyor

3 milyar nesne float32 (4 bayt) ile işlendiğinde gereken bellek: yaklaşık 8,6 TB; çalıştırma sırasında OOM oluşuyor
Jeff Dean’in işaret ettiği yönde ek optimizasyonlar gerekiyor:
- Generator ve batch karşılaştırma işlemleriyle kodu değiştirmek
- Belirli aralıklarla diske yazmak ya da bellek eşleme kullanmak
- Sistem seviyesi optimizasyon için kodu Rust veya C ile yeniden yazmak
- SimSIMD gibi büyük ölçekli vektör benzerliği karşılaştırmalarına özel kütüphanelerden yararlanmak

Ek optimizasyondan önce, problemin kendisinde bazı belirsiz alanlar olduğu fark ediliyor:
- Tek bir sorgu vektörüyle 3 milyarın tamamını bir kez tarayıp tüm sonucu döndürmek mi gerekiyor, yoksa top-k ANN araması mı isteniyor
- Orijinal vektörlerin de birlikte döndürülmesi gerekiyor mu, benzerlik temelinde yeniden sıralama gerekip gerekmediği
- 1.000 sorgu vektörüyle tamamının tek seferde taranıp taranmayacağı
- Vektörlerin zaten bellekte mi olduğu, diskten tek tek mi okunduğu, yoksa streaming biçiminde mi işlendiği
- Yerelde mi çalıştırıldığı, makine özelliklerinin ne olduğu, GPU kullanımının mümkün olup olmadığı
- Embedding boyutunun sonuç temsili ile giriş/çıkış vektör boyutlarını nasıl etkilediği
- float64’ten float32’ye sıkıştırmanın doğruluk açısından kabul edilebilir olup olmadığı
- Bunun tek seferlik bir proje mi olduğu ve üretim için ne kadar süre tanındığı
Teknik çözümün kendisinden çok, gereksinimleri doğru tanımlamanın en zor görev olduğu vurgulanıyor