Kesin kaba kuvvet arama, 100 bin vektörün altında vektör veritabanlarını gereksiz kılıyor

Neler ölçüldü

Çoğu retrieval-augmented generation eğitimi bir vektör veritabanı kurulumuyla başlar. RecallRun hesabından dev.to üzerinde yayımlanan bir benchmark, bu bağımlılığın gerçekten gerekli olup olmadığını soruyor ve görüş yerine zamanlamalarla yanıtlıyor: yaklaşık 100.000 chunk'ın altında, düz bir numpy matris çarpımı neredeyse her RAG iş yükü için yeterince hızlı.

Test, kesin aramayı — normalize edilmiş embedding'ler üzerinde tek bir matris-vektör çarpımı ve kısmi bir sıralama — faiss IndexFlatIP ile ve hnswlib ile kurulmuş HNSW dizinleriyle (M=16, ef_construction=200) karşılaştırıyor. Üç yaygın embedding boyutu kapsandı: MiniLM sınıfı modeller için 384, BERT-base sınıfı kodlayıcılar için 768 ve OpenAI text-embedding-3-small'ın varsayılan boyutu olan 1536. Donanım bilinçli olarak küçüktü — 2,1 GHz'de çalışan 2 vCPU'lu Intel Xeon ve 7 GB RAM — ve tüm gecikmeler sentetik, normalize edilmiş float32 vektörler üzerinden medyan değerlerdir.

Kesin arama uzun süre ucuz kalıyor

Kesin arama sayıları argümanın çekirdeği. 384 boyutlu 100.000 vektörde numpy en yakın 10 komşuyu 3,5 ms'de döndürdü, faiss ise 8,3 ms aldı. 1 milyon vektöre ölçeklendiğinde kesin arama 384 boyutta 62 ms'de, 768 boyutta 114 ms'de tamamlandı. dev.to yazısına göre numpy, tek sorgularda her yerde faiss'i yaklaşık 2 kat geçti; çünkü faiss toplu istekler (batch) için ayarlanmış — yazarın, toplu istek sunan herkese hatırlattığı bir uyarı.

Gecikme, vektör sayısı çarpı boyut ile doğrusal ölçeklendi; yazar bunu işlemin hesaplamadan çok bellek bant genişliğine bağlı olmasına bağlıyor. Bu da gerçek sınırı RAM yapıyor: 1 milyon vektörün 1.536 boyutta, herhangi bir metadata öncesinde yaklaşık 6 GB float32 yer tutması gerekiyor — bu yüzden o yapılandırma 7 GB'lık test makinesinde atlandı.

HNSW ne kazandırıyor, neye mal oluyor

Yaklaşık dizinler sorgu başına çok daha hızlı — ölçülen HNSW aramaları bu boyutlarda kesin aramadan 10 ila 100 kat hızlıydı — ancak benchmark iki maliyeti öne çıkarıyor.

İlki kurulum süresi: 500.000 vektörlü dizini 2 çekirdek üzerinde kurmak 4,5 dakikadan uzun sürdü; bu maliyet, örneğin embedding modeli değiştirildikten sonra yapılan her tam yeniden dizinlemede tekrarlanıyor.

İkincisi recall ve veri şekline göre çarpıcı biçimde değişiyor. 2.000 sıkışık kümeden oluşan sentetik kümelenmiş veride ef=64, 100 bin vektörde gerçek ilk 10'un yüzde 98,5 ila 99,5'ini döndürdü. Düzgün rastgele yönlerde aynı ayarlar çöktü: 100 bin vektör ve 384 boyutta yüzde 20,6 recall, 500 binde ise yalnızca yüzde 5,7. Gerçek embedding'ler bu uçlar arasında, genellikle kümelenmiş olana daha yakın durur; bu yüzden yazarın tavsiyesi, varsayılan ayarlara güvenmeden önce kendi vektörlerinizle recall'ı ölçmeniz.

Uygulamacılar için bir boyutlandırma kuralı

Benchmark arama adımını bağlamına oturtuyor: tipik bir RAG isteği LLM'in üretim yapmasını beklerken 1 ila 5 saniye harcıyor, bu da 3,5 ms'lik bir aramayı görünmez kılıyor. 1 milyon vektör için 60-110 ms bile yalnızca p99 gecikmesini takip ediyorsanız veya tek bir makineden saniyede çok sayıda sorgu geçiriyorsanız önem taşır. Ölçek için: bir PDF sayfası kabaca 2-3 chunk'tır, dolayısıyla 100.000 chunk yaklaşık 30.000 ila 50.000 sayfaya karşılık gelir — birçok iç dokümantasyon sohbet projesinin hiç ulaşmadığı bir rakam.

Yazıdan çıkan pratik kural şu: 100 bin chunk'ın altında numpy veya dizinsiz pgvector kullanın, vektörleri bir .npy dosyasında ya da Postgres'te tutun; 100 bin ile 1 milyon arasında kesin arama düşük sorgu hızlarında hâlâ çalışır, p95 gecikmesi veya throughput gerektirdiğinde HNSW ekleyin; 1 milyon vektörün ötesinde veya çok kiracılı durumlarda pgvector HNSW, Qdrant, Milvus veya OpenSearch gibi düzgün bir ANN kurulumuna geçin. Yazar ayrıca vektör deposunu tek bir arayüzün arkasında tutmayı öneriyor, böylece arka uç, hattın geri kalanına dokunmadan sonradan değiştirilebilir.

Neden önemli

Bu, yaygın bir erken optimizasyon sorununa somut bir yanıt. Kesin arama ücretsiz olarak mükemmel recall garantisi verir, kötü RAG yanıtlarını hata ayıklarken bir değişkeni ortadan kaldırır ve birçok ekibin ilk gün benimsediği bir altyapı bağımlılığını erteler. Uyarılar açıkça belirtilmiş: sayılar tek bir küçük makinede sentetik vektörlerden geliyor. Kesin arama gecikmesi vektörlerin anlamına bağlı olmadığı için iyi aktarılabilir, ancak HNSW recall'ı kesinlikle öyle değil — benchmark'ın tam da bu yüzden okuyuculara kimsenin varsayılanlarına güvenmek yerine kendi embedding'leri üzerinde ölçüm yapmalarını söyleyerek bitmesi boşuna değil.