Vektör Aramada Doğruluk ve Gecikme Dengesi: Recall@K, HNSW, IVF ve PQ
Yaklaşık en yakın komşu aramasında doğruluk, gecikme, bellek tüketimi ve indeks oluşturma maliyetlerinin HNSW, IVF ve Product Quantization parametreleriyle nasıl dengelendiğini karşılaştırmalı ölçüm yaklaşımıyla ele alır.
Vektör arama altyapısını seçerken “hangi indeks daha hızlı?” sorusu tek başına yeterli değildir. Bir yapı daha düşük gecikme sağlarken daha fazla bellek tüketebilir; başka bir yapı daha küçük bellekle çalışırken Recall@K değerini düşürebilir. Bu nedenle algoritmaları tek bir skorla değil, aynı veri kümesi ve aynı sorgu yükü altında karşılaştırmak gerekir.
Ben böyle bir karşılaştırmayı önce hedefleri sabitleyerek yapmayı tercih ederim.
Önce kabul edilebilir doğruluk düzeyi belirlenir
Yaklaşık en yakın komşu (ANN) yöntemlerinde amaç her zaman tam aramayla bire bir aynı sonucu üretmek değildir. Bunun yerine kabul edilebilir hesaplama maliyeti içinde yeterli komşuları bulmak hedeflenir.
Recall@K bu karşılaştırmanın temel ölçülerinden biridir. Örneğin exact search ile bulunan ilk 10 komşunun 9'u ANN sonucunda da bulunuyorsa Recall@10 yaklaşık 0,9'dur.
Ancak “0,9 iyi midir?” sorusunun cevabı uygulamaya bağlıdır. Aday üretme aşamasında arkasından güçlü bir reranker çalışıyorsa daha düşük recall kabul edilebilir veya tam tersine aday kaybı sonradan telafi edilemeyeceği için daha yüksek recall gerekebilir.
HNSW: arama genişliği ile maliyet birlikte büyür
HNSW graf tabanlı bir yapıdır. Arama sırasında daha fazla düğüm incelemek genellikle recall değerini yükseltir; bunun karşılığında gecikme ve CPU maliyeti artar.
Pratik karşılaştırmada özellikle şu parametrelerin aynı tabloda tutulması yararlıdır:
efSearch,- Recall@K,
- P50/P95/P99 sorgu süresi,
- indeks belleği,
- indeks oluşturma süresi.
Yalnız ortalama sorgu süresine bakıldığında yüksek yüzdeliklerde ortaya çıkan gecikme gözden kaçabilir.
IVF: kaç hücrenin taranacağı sonucu değiştirir
Inverted File Index yaklaşımında vektör uzayı kümelere ayrılır. Sorguda yalnızca en yakın bazı kümeler aranır.
FAISS tarafındaki nprobe, kaç listenin taranacağını belirleyen önemli ayarlardan biridir. nprobe arttıkça recall çoğunlukla yükselir; fakat daha fazla aday değerlendirildiği için sorgu maliyeti de artar.
Bu nedenle nprobe=1 ile nprobe=32 sonuçlarını yalnız hız açısından karşılaştırmak anlamlı değildir. Her iki ayarda elde edilen Recall@K ile gecikmeyi birlikte görmek gerekir.
PQ: bellek kazancı karşılığında bilgi kaybı
Product Quantization, yüksek boyutlu vektörleri daha küçük kodlarla temsil ederek bellek kullanımını ve bazı arama maliyetlerini düşürebilir. Bunun bedeli kuantizasyon hatasıdır.
PQ kullanan bir deneyde en az şu değerleri ölçmek gerekir:
- vektör başına bayt,
- toplam indeks boyutu,
- Recall@K,
- sorgu gecikmesi,
- yeniden sıralama varsa nihai kalite.
Bellek tüketimini ciddi biçimde azaltan bir yapı, recall kaybı kabul edilebilir düzeydeyse büyük veri kümelerinde daha doğru sistem tercihi olabilir.
Karşılaştırma tablosu nasıl kurulmalı?
Aynı testte şu değişkenleri sabit tutmak gerekir:
- embedding modeli,
- veri kümesi,
- sorgu kümesi,
- K değeri,
- donanım,
- thread sayısı,
- warm-up yaklaşımı,
- ölçüm süresi.
Ardından her indeks ayarı için en az şu çıktıları kaydederim:
| Ölçü | Neden gerekli? | |---|---| | Recall@K | Tam aramaya göre kalite kaybını gösterir | | P50 | Tipik sorgu süresini gösterir | | P95/P99 | Kuyruk veya pahalı aramaların etkisini gösterir | | QPS | Taşınabilen sorgu hacmini gösterir | | Bellek | Kapasite sınırını belirler | | İndeks oluşturma süresi | Yeniden indeksleme maliyetini gösterir |
Bu şekilde “en hızlı” indeks yerine belirli bir hizmet seviyesi için en uygun ayar bulunabilir.
Son karar tek bir algoritma adına indirgenmemeli
HNSW, IVF ve PQ birbirinin her durumda doğrudan alternatifi değildir; bazı sistemlerde birlikte de kullanılabilirler. Veri kümesinin büyüklüğü, güncelleme sıklığı, bellek sınırı ve gecikme hedefi seçim üzerinde en az algoritma kadar etkilidir.
Vektör veritabanı seçimini de aynı nedenle ürün veya algoritma adından önce ölçüm hedefleriyle yapmak gerekir. FAISS indeks mimarisi bu yapıların uygulama düzeyindeki ayrıntılarını tamamlar.
Doğru yapı, en yüksek teorik recall değerine veya en düşük tekil sorgu süresine sahip olan değil; gerekli Recall@K düzeyini kabul edilebilir P95/P99 gecikme ve kaynak bütçesi içinde sürekli sağlayabilen yapıdır.