Vektör Veritabanı Boyutlandırma: Kimsenin Söylemediği Maliyet Gerçeği

Veri Platformu vektor-veritabani, rag

Bir milyon vektörün Pinecone, Qdrant, Weaviate ve pgvector üzerindeki gerçek maliyeti ve faturayı 5 kat değiştiren üç konfigürasyon kaldıracı.

  • Yazar: Orzed Team
  • 1 dk okuma
Önemli çıkarımlar
  • Gömme boyutu (dimensionality) en büyük maliyet sürücüsüdür; 1536 boyuttan 768 boyuta inmek depolamayı ve sorgu maliyetini yaklaşık yarıya indirir.
  • Replikasyon faktörü faturayı 2 ila 3 katına çıkarır ve genellikle iş yükünün gerçekte ihtiyaç duyduğundan yüksek ayarlanır.
  • Hibrit arama (BM25 + yoğun vektör) maliyeti artırsa da heterojen veri setlerinde sağladığı erişim (recall) artışına değer.
  • Yaklaşık 5 milyon vektörün altında küçük bir VM üzerinde Qdrant veya pgvector barındırmak yönetilen servislerden çok daha ekonomiktir.

Bir projede vektör veritabanını ilk kez boyutlandırırken ekibe beklenen sorgu hacmini ve hedef gecikmeyi sorduk; ikisini de ölçmemişlerdi. Yalnızca OpenAI varsayılanı olan 1536 boyutu kullandıklarını biliyorlardı. Yönetilen bir Pinecone faturası çıkardığımızda odada sessizlik oldu. İki haftalık profillemenin ardından gerçek ihtiyaçlarının ayda 100 dolarlık 4 vCPU’lu bir sanal sunucudaki Qdrant kurulumu olduğu ortaya çıktı; maliyet farkı 12 kattı ve bunun veritabanı markasıyla hiçbir ilgisi yoktu.

Faturayı 5 Kat Değiştiren Üç Konfigürasyon Kaldıracı

  1. Gömme Boyutu (Dimensionality): Float32 formatında 1536 boyutlu bir vektör 6 KB, 768 boyutlu bir vektör ise 3 KB yer kaplar; üstelik HNSW bellekte ham vektörün 1.5 ila 2 katı büyüklüğünde indeks tutar. Geçen çeyrek denetlediğimiz bir derlemde 1536 boyuttan 768 boyuta inmek recall@5 değerini sadece 0.91’den 0.89’a düşürürken depolamayı %50, toplam aylık faturayı ise %45 azalttı.
  2. Replikasyon Faktörü: Ekipler varsayılan olarak 3 replikalı yüksek erişilebilirlik (HA) açar ve faturayı üçe katlar. Müşteriye dönük canlı yollarda 2 replika, iç arama araçlarında 1 replika, gecelik toplu işlerde ise sıfır replika yeterlidir.
  3. Hibrit (BM25 + Yoğun) vs Sadece Yoğun Arama: Ürün kodları ve özel isimler içeren sorgularda hibrit arama recall değerini %5 ila %15 artırır ancak sorgu başı maliyeti ikiye katlar; yalnızca sohbet tarzı kavramsal sorgularınız varsa sadece yoğun vektör kullanın.

Kendi Barındırdığın vs Yönetilen Servis ve Operasyonel Tuzaklar

1 milyon vektörün altında mevcut Postgres üzerindeki pgvector, 1 ila 10 milyon vektör arasında ise 100-300 dolarlık bir VM üzerindeki Qdrant en rasyonel seçimdir. Canlı operasyonda üç tuzağa dikkat edilmelidir: HNSW indeks yeniden oluşturma işlemlerini yoğun trafik saatlerinde tek replika üzerinde yapmayın, sağlayıcı gömme modelini değiştirdiğinde tüm derlemi yeniden vektörleştirme maliyetini hesaba katın ve karmaşık meta veri filtrelerini (WHERE category = X AND date > Y) boş filtrelerle değil gerçek yükle test edin.

Sıkça sorulanlar

Sıkça sorulan sorular

Kendi sunucumuzda mı barındırmalıyız yoksa yönetilen (managed) servis mi kullanmalıyız?

5 milyon vektörün altında ve tek replikada, küçük bir sanal sunucuda kendi barındırdığınız Qdrant veya mevcut Postgres üzerindeki pgvector çok daha ucuzdur. 10 milyon vektörün üzerinde ve çok bölgeli yüksek QPS senaryolarında ise yönetilen servisler mühendislik bakım süresinden tasarruf ettirir.

pgvector canlı üretim ortamı için gerçekten yeterli mi?

Orta ölçek için kesinlikle evet. HNSW indekslemeli pgvector on milyonlarca vektörü kabul edilebilir gecikmeyle taşır. Mevcut Postgres altyapınız içinde kalmanın getirdiği operasyonel sadelik ciddi bir avantajdır.

Boyut küçültme (dimensionality reduction) arama kalitesini ne kadar düşürür?

Matryoshka eğitimi almış modellerde (örneğin text-embedding-3-large) 1536 boyuttan 768 boyuta kırpmak recall@5 değerinde yalnızca %1 ila %3 kayıp yaratırken depolama maliyetini %50 düşürür.