Vektör Aramayı Üretmenin 6 Kritik Zorluğu

Uygulamanızda, ürününüzde veya işletmenizde vektör aramayı kullanmaya karar verdiniz. Yerleştirmelerin ve vektör aramanın bir sorunu nasıl ve neden çözülebilir hale getirdiğini veya yeni özellikleri mümkün kıldığını araştırdınız. Yaklaşık en yakın komşu algoritmaları ve vektör veritabanlarının yeni gelişen alanına ayak parmaklarınızı soktunuz.

Vektör arama uygulamalarını üretmeye başlar başlamaz, çok zorlu ve potansiyel olarak öngörülemeyen zorluklarla karşılaşmaya başlayacaksınız. Bu blog sizi geleceğiniz, karşılaşacağınız sorunlar ve henüz bilmediğiniz ve sormanız gereken sorular hakkında bazı bilgilerle donatmaya çalışıyor.

1. Vektör arama ≠ vektör veritabanı

Vektör arama ve ilgili tüm akıllı algoritmalar, vektörlerden yararlanmaya çalışan herhangi bir sistemin merkezi zekasıdır. Bununla birlikte, onu maksimum düzeyde kullanışlı ve üretime hazır hale getirmek için gereken tüm altyapı muazzamdır ve hafife alınması çok çok kolaydır.

Bunu elimden geldiğince güçlü bir şekilde ifade etmek gerekirse: üretime hazır bir vektör veritabanı, "vektör" sorunlarından çok çok daha fazla "veritabanı" sorununu çözecektir . Vektör aramanın kendisi kesinlikle "kolay" bir sorun değildir (ve aşağıda pek çok zorlu alt problemi ele alacağız), ancak bir vektör veritabanının çözmesi gereken geleneksel veritabanı sorunları yığını kesinlikle "zor kısım" olarak kalmaya devam ediyor. ”

Veritabanları, atomiklik ve işlemler, tutarlılık, performans ve sorgu optimizasyonu, dayanıklılık, yedeklemeler, erişim kontrolü, çoklu kiracılık, ölçeklendirme ve parçalama ve çok daha fazlasına ilişkin çok gerçek ve çok iyi çalışılmış bir dizi sorunu çözer. Vektör veritabanları, herhangi bir ürün, işletme veya kuruluş için bu boyutların tamamında yanıtlar gerektirecektir.

Evde yapılan "vektör arama altyapısına" karşı çok dikkatli olun. Son teknoloji ürünü bir vektör arama kütüphanesini indirmek ve ilginç bir prototipe doğru yaklaşık olarak en yakın komşuyu bulmaya başlamak o kadar da zor değil. Ancak bu yola devam etmek, kendi veritabanınızı yanlışlıkla yeniden keşfetmenin yoludur. Bu muhtemelen bilinçli olarak yapmak isteyeceğiniz bir seçimdir.

2. Vektörlerin artımlı indekslenmesi

En modern YSA vektör arama algoritmalarının doğası gereği, bir vektör indeksinin aşamalı olarak güncellenmesi büyük bir zorluktur. Bu çok iyi bilinen bir “zor problem”dir. Buradaki sorun, bu dizinlerin hızlı aramalar için dikkatli bir şekilde organize edilmiş olmasıdır ve bunları yeni vektörlerle aşamalı olarak güncellemeye yönelik herhangi bir girişim, hızlı arama özelliklerini hızla bozacaktır. Bu nedenle, vektörler eklendikçe hızlı aramaları sürdürmek için bu dizinlerin periyodik olarak sıfırdan yeniden oluşturulması gerekir.

Hem vektörlerin dizinde hızlı bir şekilde görünmesi hem de sorguların hızlı kalması gereksinimleriyle sürekli olarak yeni vektörlerin akışını sağlamayı ümit eden herhangi bir uygulama, "artımlı indeksleme" sorunu için ciddi desteğe ihtiyaç duyacaktır. Bu, veritabanınızı anlamanız için çok önemli bir alandır ve bir takım zor soruları sormak için iyi bir yerdir.

Bir veritabanının bu sorunu sizin için çözmeye yardımcı olabilecek birçok potansiyel yaklaşımı vardır. Bu yaklaşımlara ilişkin uygun bir araştırma, bu büyüklükteki birçok blog yazısını dolduracaktır. Veritabanınızın yaklaşımının bazı teknik ayrıntılarını anlamak önemlidir çünkü uygulamanızda beklenmedik değişimler veya sonuçlar doğurabilir. Örneğin, bir veritabanı belirli bir sıklıkta tam yeniden dizin oluşturmayı seçerse, bu durum yüksek CPU yüküne neden olabilir ve dolayısıyla sorgu gecikmelerini periyodik olarak etkileyebilir.

Uygulamalarınızın artımlı indekslemeye olan ihtiyacını ve size hizmet vermesine güvendiğiniz sistemin yeteneklerini anlamalısınız.

3. Hem vektörler hem de meta veriler için veri gecikmesi

Her uygulama, veri gecikmesine olan ihtiyacını ve toleransını anlamalıdır. Vektör bazlı indeksler, en azından diğer veritabanı standartlarına göre nispeten yüksek indeksleme maliyetlerine sahiptir. Maliyet ve veri gecikmesi arasında önemli bir denge vardır.

Bir vektörü 'yarattıktan' ne kadar süre sonra onun dizininizde aranabilir olmasına ihtiyacınız var? Yakında olursa, vektör gecikmesi bu sistemlerde önemli bir tasarım noktasıdır.

Aynı durum sisteminizin meta verileri için de geçerlidir. Genel bir kural olarak, meta verileri değiştirmek oldukça yaygındır (örneğin, bir kullanıcının çevrimiçi olup olmadığını değiştirmek) ve bu nedenle, meta veri filtreli sorguların meta veri güncellemelerine hızla tepki vermesi genellikle çok önemlidir. Yukarıdaki örneği ele alırsak, vektör aramanız yakın zamanda çevrimdışı olan biri için bir sorgu döndürüyorsa bu yararlı değildir!

Vektörleri sürekli olarak sisteme aktarmanız veya bu vektörlerin meta verilerini sürekli olarak güncellemeniz gerekiyorsa, örneğin ertesi gün kullanılmak üzere her akşam tam dizini yeniden oluşturmak gibi kullanım durumunuz için kabul edilebilir olandan farklı bir temel veritabanı mimarisine ihtiyacınız olacaktır. .

4. Meta veri filtreleme

Bu noktayı şiddetle belirteceğim: Hemen hemen her durumda, temeldeki vektör arama altyapısının meta veri filtreleme (veya hibrit arama) ile güçlendirilmesi durumunda ürün deneyiminin daha iyi olacağını düşünüyorum .

Bana 10 mil mesafede bulunan ve düşük ila orta fiyatlı (meta veri filtresi) beğenebileceğim tüm restoranları göster (vektör araması).

Bu sorgunun ikinci kısmı, ilk kısımda bir vektör arama sonucuyla kesişen geleneksel sql benzeri bir WHERE cümlesidir. Bu büyük, nispeten statik, nispeten monolitik vektör indekslerinin doğasından dolayı, ortak vektör + meta veri aramasını verimli bir şekilde yapmak çok zordur. Bu, vektör veritabanlarının sizin adınıza çözmesi gereken iyi bilinen "zor sorunlardan" bir diğeridir.

Veritabanlarının bu sorunu sizin için çözmek için kullanabileceği birçok teknik yaklaşım vardır. Önce filtreyi uygulamak ve ardından bir vektör araması yapmak anlamına gelen "ön filtre" uygulayabilirsiniz. Bu yaklaşım, önceden oluşturulmuş vektör indeksinden etkili bir şekilde yararlanamamaktan dolayı sıkıntı çekmektedir. Tam bir vektör araması yaptıktan sonra sonuçları "sonradan filtreleyebilirsiniz". Filtreniz çok seçici olmadığı sürece bu harika işe yarar; bu durumda, belirtilen kriterleri karşılamadıkları için daha sonra atacağınız vektörleri bulmak için çok fazla zaman harcarsınız. Bazen, Rockset'te olduğu gibi, meta veri filtreleme aşamasını vektör arama aşamasıyla her iki dünyanın en iyilerini koruyacak şekilde birleştirmeye çalışan "tek aşamalı" filtreleme yapabilirsiniz.

Meta veri filtrelemenin uygulamanız için kritik olacağına inanıyorsanız (ve yukarıda neredeyse her zaman öyle olacağını öne sürüyorum), meta veri filtreleme değiş tokuşları ve işlevselliği çok dikkatli bir şekilde incelemek isteyeceğiniz bir şey haline gelecektir.

5. Meta veri sorgulama dili

Haklıysam ve meta veri filtreleme, oluşturduğunuz uygulama için çok önemliyse, tebrikler, başka bir sorununuz var demektir. Bu meta veriler üzerinde filtreleri belirtmenin bir yoluna ihtiyacınız var. Bu bir sorgulama dilidir.

Veritabanı açısından geliyorum ve bu bir Rockset blogu olduğundan, muhtemelen bununla nereye varacağımı bekleyebilirsiniz. SQL, bu tür ifadeleri ifade etmenin endüstri standardı yoludur. Vektör dilindeki "Meta veri filtreleri", geleneksel bir veritabanının basitçe " WHERE cümlesidir". Farklı sistemler arasında taşınmasının nispeten kolay olması avantajına da sahiptir.

Ayrıca bu filtreler sorgulardır ve sorgular optimize edilebilir. Sorgu iyileştiricinin karmaşıklığı, sorgularınızın performansı üzerinde büyük bir etkiye sahip olabilir. Örneğin, gelişmiş optimize ediciler ilk olarak meta veri filtrelerinin en seçici olanını uygulamaya çalışacaklardır çünkü bu, filtrelemenin sonraki aşamalarının gerektirdiği işi en aza indirecek ve büyük bir performans kazancıyla sonuçlanacaktır.

Vektör arama ve meta veri filtreleri kullanarak önemsiz olmayan uygulamalar yazmayı planlıyorsanız, kullanmak, yazmak ve bakımını yapmak için kaydolduğunuz sorgu dilini hem ergonomi hem de uygulama açısından anlamak ve bu dilde rahat olmak önemlidir.

6. Vektör yaşam döngüsü yönetimi

Tamam, buraya kadar başardın. İhtiyaç duyduğunuz tüm doğru veritabanı temellerine sahip, kullanım durumunuz için doğru artımlı indeksleme stratejisine sahip, meta veri filtreleme ihtiyaçlarınız hakkında iyi bir hikayeye sahip ve indeksini gecikmelerle güncel tutacak bir vektör veritabanınız var. tahammül edebilirsin. Mükemmel.

ML ekibiniz (veya belki OpenAI) yerleştirme modellerinin yeni bir versiyonunu çıkarır. Artık güncellenmesi gereken eski vektörlerle dolu devasa bir veritabanınız var. Şimdi ne olacak? Bu büyük toplu makine öğrenimi işini nerede çalıştıracaksınız? Ara sonuçları nasıl saklayacaksınız? Yeni versiyona geçişi nasıl yapacaksınız? Üretim iş yükünüzü etkilemeyecek şekilde bunu nasıl yapmayı planlıyorsunuz?

Zor Soruları Sorun

Vektör arama hızla gelişen bir alandır ve birçok kullanıcının uygulamaları üretime taşımaya başladığını görüyoruz. Bu yazıdaki amacım, henüz sormayı bilmediğiniz bazı önemli zor sorularla sizi donatmaktı. Ve bunların bir an önce yanıtlanmasının büyük faydasını göreceksiniz.

Bu yazıda Rockset'in tüm bu sorunları nasıl çözdüğü ve çözmeye çalıştığı ve bunlara yönelik çözümlerimizden bazılarının neden çığır açıcı ve en ileri teknolojideki diğer birçok girişimden daha iyi olduğu konusunu ele almadım. Bunu ele almak için bu boyutta çok sayıda blog yazısı gerekir, sanırım bizim de tam olarak yapacağımız şey bu. Daha fazlası için bizi takip etmeye devam edin.