Vektör Veritabanı Nedir? Ve Ne Zaman Gerekir

Ne sakladığı

Vektör veritabanı gömüleri — bir metin parçasının, görselin ya da sesin anlamını temsil eden sayı listelerini — saklar ve tek bir soruyu hızla yanıtlar: saklanan öğelerden hangileri buna en yakın? O sayısal uzaydaki yakınlık anlamdaki benzerliğe karşılık gelir; "planımı iptal etmek" hakkındaki bir sorgunun tek bir anahtar kelime paylaşmadan "aboneliğinizi sonlandırma" başlıklı bir belgeyi getirebilmesinin nedeni budur. Değer önerisi tamamen budur; geri kalan her şey onun etrafındaki mühendisliktir.

Sıradan aramanın neden yetmediği

Anahtar kelime araması dizgileri eşler. Kullanıcı belgelerinizin kullandığı kelimeleri yazdığında mükemmeldir, yazmadığında başarısız olur — destekte, dokümantasyonda ve şirket içi bilgide çoğu zaman öyledir. Anlamsal arama bu boşluğu kapatır. Ayrıca yeni bir hata da getirir: ilgili hiçbir şey olmadığında bile her zaman en yakın öğeleri döndürür; yani derleminizde bulunmayan bir şey hakkındaki sorgu, en az ilgisiz olanı güven verici görünen bir benzerlik puanıyla döndürür. Bu boş durumu açıkça ele almak, "bilmiyorum" diyen bir aramayla kendinden emin biçimde yanlış belgeyi getiren bir arama arasındaki farktır.

Aramanın nasıl çalıştığı

Bir sorguyu saklanan her vektörle karşılaştırmak tamdır ve birkaç yüz bin öğeden sonra fazla yavaştır; bu yüzden bu sistemler yaklaşık en yakın komşu dizinleri kullanır — en yaygın olarak HNSW, en iyiye yakın bir cevaba çok daha kısa sürede varmak için indiğiniz katmanlı bir grafik. Yaklaşık sözcüğü süs değildir: az miktarda geri getirmeyi çok miktarda hızla takas ediyorsunuz ve dizin parametreleri bu takası denetler. Sıkıştırma teknikleri vektörleri daha da küçültür, çünkü on milyon tam duyarlıklı gömü onlarca gigabayt bellek kaplar.

Özel bir tanesine ihtiyacınız olmayabilir

Sağlayıcıların atladığı kısım budur. pgvector eklentili Postgres yüz binlerce vektörü rahatça idare eder, gömülerinizi zaten işlettiğiniz ve yedeklediğiniz veritabanında tutar ve aynı sorguda kiracıya, tarihe ya da izne göre filtrelemenize izin verir. Özel bir vektör veritabanı gerçekten büyük ölçekte, çok yüksek sorgu hacminde ya da uzmanlaştığı özelliklere ihtiyaç duyduğunuzda yerini hak eder. Ayrı bir sistemle başlamak, ihtiyacınız olup olmadığını bilmeden önce iki depoyu işletmek, güvenceye almak ve eşitlemek demektir.

Kaliteyi gerçekte belirleyen parçalar

Ekipler kötü getirmeyi veritabanına yükleyip veritabanı değiştirme eğilimindedir ve bu neredeyse hiç yardım etmez. Getirme kalitesi akış yukarısında belirlenir: belgeleri parçalara nasıl böldüğünüz, hangi gömü modelini kullandığınız ve en iyi sonuçları kullanmadan önce daha pahalı bir modelle yeniden sıralayıp sıralamadığınız. Parçalama en sonuçlu ve en az konuşulanıdır: çok küçük bölerseniz pasajlar onları anlamlı kılan bağlamı yitirir, çok büyük bölerseniz gömü birkaç konuyu hiçbirini kesin eşleştirmeyen bir vektörde ortalar.

Operasyonel tuzak

Farklı modellerden gelen gömüler karşılaştırılabilir değildir. Gömü modelinizi değiştirin, saklanan her vektör yeni sorgular karşısında anlamsızlaşır; bu da tüm derlemin baştan gömülmesi anlamına gelir — küçümsenmesi kolay ve yarım yapılması imkânsız bir göç. Bunu planlayın: her vektörü hangi modelin ürettiğini kaydedin ve bir model yükseltmesini bir yapılandırma değişikliği değil bir veri göçü olarak ele alın.

Kısa özet

Vektör veritabanı özelleşmiş bir dizindir, doğruluk kaynağı değil. Belgelerinizi yaşadıkları yerde tutun, vektörleri yeniden kurabileceğiniz türetilmiş bir ürün sayın ve zaten işlettiğiniz veritabanıyla başlayın. Özel bir sisteme, başlarken değil ölçülmüş bir nedeniniz olduğunda uzanın.