Vektör veritabanı seçimini benchmark'lar değil, filtreleme belirliyor
- RAG
- On-Premise
Vektör veritabanı karşılaştırmaları hep aynı eksende ilerliyor: saniyede kaç sorgu, ne kadar gecikme, hangi indeks tipi.
Bizim kurulumda bu sayıların hiçbiri karar vermedi. Karar veren üç şey oldu: filtreleme nasıl çalışıyor, veri nerede durabiliyor, güncelleme neye mal oluyor.
Kurumsal sorgu hiçbir zaman sadece anlamsal değil
Bir bilgi tabanına "yedekleme politikası nedir" diye sorulmuyor. "Bu müşterinin üretim ortamındaki yedekleme politikası nedir" diye soruluyor.
Yani her sorgunun anlamsal bir parçası, bir de kesin kısıt parçası var. İkincisi pazarlığa açık değil: başka müşterinin belgesi doğru cevabın parçası olamaz.
Sistemler tam burada ayrışıyor. Filtre arama sırasında mı uygulanıyor, sonrasında mı.
Sonradan filtreleme basit ama kırılgan. Önce en yakın k belge bulunuyor, sonra kısıta uymayanlar atılıyor. Kısıt darsa geriye hiçbir şey kalmayabiliyor - sistem "sonuç yok" diyor, oysa uygun belge indekste duruyor.
Arama sırasında filtreleme doğru davranış, uygulaması zor: indeksin filtreyi bilerek gezinmesi gerekiyor.
Bu farkı bir benchmark tablosunda göremezsiniz, çünkü tablolar filtresiz sorgu ölçüyor.
Kendi verimizle küçük bir test
Karar için gerçek belgeler, gerçek kısıtlar ve gerçek sorularla küçük bir kurulum yaptık. Baktığımız şey saniyedeki sorgu sayısı değildi.
| Soru | Neden önemli |
|---|---|
| Dar filtreyle sonuç dönüyor mu | Kısıt sıkılaştıkça boşalan sistem işe yaramıyor |
| Filtre gecikmeyi ne kadar artırıyor | Filtresiz hız yanıltıcı |
| Belge güncellenince ne oluyor | Yeniden indeksleme mi, yerinde güncelleme mi |
| Silme gerçekten siliyor mu | Veri saklama politikaları için zorunlu |
Son satır beklediğimizden önemli çıktı. Bir belgenin silinmesi gerektiğinde vektörünün de gerçekten kaybolması gerekiyor, ve bu her sistemde aynı şekilde çalışmıyor.
Nerede koştuğu, ne kadar hızlı koştuğundan önemli
Verisi kurum dışına çıkamayan bir ortamda barındırılan hizmetler daha karşılaştırma başlamadan eleniyor. Bu alanı ciddi biçimde daraltıyor.
Kendi sunucunuzda koşan seçenekler arasında ise operasyonel yük belirleyici: ayrı bir servis mi işleteceksiniz, yedeklemesi nasıl, mevcut izleme düzenine giriyor mu.
Burada gözden kaçan bir seçenek var. Veri hacmi orta ölçekteyse mevcut PostgreSQL kurulumunuz üzerinde vektör aramak, ayrı servis işletmekten ucuza gelebiliyor. Kısıtlar zaten SQL tarafında duruyor, filtreleme doğal olarak arama sırasında oluyor, yedekleme ve yetkilendirme mevcut düzenden geliyor.
Her ölçekte doğru değil elbette. Ama ayrı bir vektör servisi işletmenin maliyeti hiçbir karşılaştırma tablosunda görünmüyor.
Güncelleme profili sessiz maliyet
Karşılaştırmalarda neredeyse hiç konuşulmayan konu verinin ne sıklıkta değiştiği.
Statik bir belge kümesinde indeks bir kez kuruluyor, mesele bitiyor. Kurumsal bilgi tabanı statik değil: prosedürler güncelleniyor, sistemler ekleniyor, eskiler kaldırılıyor.
Sorulacak soru şu: tek bir belge değiştiğinde ne kadar iş çıkıyor. Sadece o belgenin parçaları mı güncelleniyor, yoksa daha geniş bir yeniden indeksleme mi gerekiyor.
Gömme modelini değiştirmek ise her durumda tam yeniden indeksleme demek. Bu yüzden gömme modeli seçimi, veritabanı seçiminden daha kalıcı bir karar - ve daha dikkatli verilmesi gereken.
Gecikme sayıları bizim seçimimizde neredeyse hiç rol oynamadı. Belirleyici olan filtrelemenin arama sırasında yapılıp yapılmadığı, verinin nerede durabildiği ve güncellemenin maliyetiydi.
Karar öncesi yapılacak en faydalı şey kendi kısıtlarınızla küçük bir test kurmak. Filtresiz benchmark, sizin hiç sormayacağınız soruyu ölçüyor.