6 défis critiques liés à la production de la recherche de vecteurs

Vous avez décidé d'utiliser la recherche vectorielle dans votre application, produit ou entreprise. Vous avez étudié comment et pourquoi les intégrations et la recherche vectorielle permettent de résoudre un problème ou peuvent activer de nouvelles fonctionnalités. Vous avez plongé vos orteils dans le domaine chaud et émergent des algorithmes approximatifs du plus proche voisin et des bases de données vectorielles.

Presque immédiatement après la production d’applications de recherche vectorielle, vous commencerez à rencontrer des difficultés très difficiles et potentiellement imprévues. Ce blog tente de vous donner une certaine connaissance de votre avenir, des problèmes auxquels vous serez confrontés et des questions que vous ne savez peut-être pas encore et que vous devez poser.

1. Recherche de vecteurs ≠ base de données de vecteurs

La recherche de vecteurs et tous les algorithmes intelligents associés constituent l’intelligence centrale de tout système essayant d’exploiter les vecteurs. Cependant, toute l’infrastructure associée pour la rendre utile au maximum et prête pour la production est énorme et très, très facile à sous-estimer.

Pour le dire aussi clairement que possible : une base de données vectorielle prête pour la production résoudra beaucoup plus de problèmes de « base de données » que de problèmes de « vecteur » . La recherche vectorielle n’est en aucun cas un problème « facile » (et nous aborderons de nombreux sous-problèmes difficiles ci-dessous), mais la montagne de problèmes de bases de données traditionnelles qu’une base de données vectorielles doit résoudre reste certainement la « partie la plus difficile ». »

Les bases de données résolvent une multitude de problèmes très réels et très bien étudiés concernant l'atomicité et les transactions, la cohérence, l'optimisation des performances et des requêtes, la durabilité, les sauvegardes, le contrôle d'accès, la multi-location, la mise à l'échelle et le partitionnement et bien plus encore. Les bases de données vectorielles nécessiteront des réponses dans toutes ces dimensions pour tout produit, entreprise ou entreprise.

Méfiez-vous beaucoup des « infras de recherche vectorielle » maison. Il n'est pas si difficile de télécharger une bibliothèque de recherche de vecteurs de pointe et de commencer à vous frayer un chemin vers un prototype intéressant. Cependant, continuer sur cette voie revient à réinventer accidentellement votre propre base de données. C'est probablement un choix que vous souhaitez faire consciemment.

2. Indexation incrémentale des vecteurs

En raison de la nature des algorithmes de recherche de vecteurs ANN les plus modernes, la mise à jour incrémentielle d’un index vectoriel constitue un défi de taille. Il s’agit d’un « problème difficile » bien connu. Le problème ici est que ces index sont soigneusement organisés pour des recherches rapides et que toute tentative de les mettre à jour progressivement avec de nouveaux vecteurs détériorera rapidement les propriétés de recherche rapide. En tant que tel, afin de maintenir des recherches rapides à mesure que des vecteurs sont ajoutés, ces index doivent être périodiquement reconstruits à partir de zéro.

Toute application espérant diffuser de nouveaux vecteurs en continu, avec pour exigences que les vecteurs apparaissent rapidement dans l'index et que les requêtes restent rapides, aura besoin d'une prise en charge sérieuse pour le problème de « l'indexation incrémentale ». Il s’agit d’un domaine très crucial que vous devez comprendre concernant votre base de données et un bon endroit pour poser un certain nombre de questions difficiles.

Il existe de nombreuses approches potentielles qu'une base de données peut adopter pour vous aider à résoudre ce problème. Une étude approfondie de ces approches remplirait de nombreux articles de blog de cette taille. Il est important de comprendre certains détails techniques de l'approche de votre base de données, car elle peut entraîner des compromis ou des conséquences inattendues dans votre application. Par exemple, si une base de données choisit d'effectuer une réindexation complète à une certaine fréquence, cela peut entraîner une charge CPU élevée et donc affecter périodiquement les latences des requêtes.

Vous devez comprendre les besoins de vos applications en matière d'indexation incrémentielle et les capacités du système sur lequel vous comptez pour vous servir.

3. Latence des données pour les vecteurs et les métadonnées

Chaque application doit comprendre ses besoins et sa tolérance en matière de latence des données. Les index vectoriels ont, du moins par rapport aux autres normes de bases de données, des coûts d'indexation relativement élevés. Il existe un compromis important entre le coût et la latence des données.

Combien de temps après avoir « créé » un vecteur avez-vous besoin qu'il soit consultable dans votre index ? Si c'est bientôt le cas, la latence vectorielle est un point de conception majeur dans ces systèmes.

Il en va de même pour les métadonnées de votre système. En règle générale, la mutation des métadonnées est assez courante (par exemple, changer si un utilisateur est en ligne ou non), et il est donc généralement très important que les requêtes filtrées par les métadonnées réagissent rapidement aux mises à jour des métadonnées. En prenant l'exemple ci-dessus, cela n'est pas utile si votre recherche vectorielle renvoie une requête pour quelqu'un qui s'est récemment déconnecté !

Si vous devez diffuser des vecteurs en continu sur le système ou mettre à jour les métadonnées de ces vecteurs en continu, vous aurez besoin d'une architecture de base de données sous-jacente différente de celle s'il est acceptable pour votre cas d'utilisation, par exemple de reconstruire l'index complet chaque soir pour l'utiliser le lendemain. .

4. Filtrage des métadonnées

Je soulignerai ce point avec force : je pense que dans presque toutes les circonstances, l'expérience produit sera meilleure si l'infrastructure de recherche vectorielle sous-jacente peut être augmentée par le filtrage des métadonnées (ou la recherche hybride).

Montrez-moi tous les restaurants qui pourraient me plaire (recherche vectorielle) situés dans un rayon de 10 miles et dont les prix sont bas à moyens (filtre de métadonnées).

La deuxième partie de cette requête est une clause WHERE traditionnelle de type SQL recoupée, dans la première partie, un résultat de recherche vectorielle. En raison de la nature de ces grands index vectoriels relativement statiques et relativement monolithiques, il est très difficile d'effectuer efficacement une recherche conjointe vecteur + métadonnées. Il s’agit d’un autre « problème difficile » bien connu que les bases de données vectorielles doivent résoudre en votre nom.

Il existe de nombreuses approches techniques que les bases de données peuvent adopter pour résoudre ce problème à votre place. Vous pouvez « pré-filtrer », ce qui signifie appliquer d'abord le filtre, puis effectuer une recherche vectorielle. Cette approche souffre de ne pas pouvoir exploiter efficacement l’index vectoriel prédéfini. Vous pouvez « post-filtrer » les résultats après avoir effectué une recherche vectorielle complète. Cela fonctionne très bien à moins que votre filtre ne soit très sélectif, auquel cas vous passez énormément de temps à trouver des vecteurs que vous rejetez plus tard parce qu'ils ne répondent pas aux critères spécifiés. Parfois, comme c'est le cas dans Rockset, vous pouvez effectuer un filtrage « en une seule étape » qui consiste à tenter de fusionner l'étape de filtrage des métadonnées avec l'étape de recherche vectorielle d'une manière qui préserve le meilleur des deux mondes.

Si vous pensez que le filtrage des métadonnées sera essentiel pour votre application (et je postule plus haut que ce sera presque toujours le cas), les compromis et les fonctionnalités du filtrage des métadonnées deviendront quelque chose que vous souhaiterez examiner très attentivement.

5. Langage de requête de métadonnées

Si j'ai raison et que le filtrage des métadonnées est crucial pour l'application que vous créez, félicitations, vous avez encore un autre problème. Vous avez besoin d'un moyen de spécifier des filtres sur ces métadonnées. Il s'agit d'un langage de requête.

Venant du point de vue de la base de données, et comme il s'agit d'un blog Rockset, vous pouvez probablement vous attendre à où je veux en venir. SQL est le moyen standard de l'industrie pour exprimer ce type d'instructions. Les « filtres de métadonnées » en langage vectoriel sont simplement « la clause WHERE » d'une base de données traditionnelle. Il présente l’avantage d’être également relativement facile à porter entre différents systèmes.

De plus, ces filtres sont des requêtes et les requêtes peuvent être optimisées. La sophistication de l'optimiseur de requêtes peut avoir un impact énorme sur les performances de vos requêtes. Par exemple, des optimiseurs sophistiqués tenteront d'appliquer d'abord le filtre de métadonnées le plus sélectif, car cela minimisera le travail requis par les étapes ultérieures du filtrage, ce qui entraînera un gain de performances important.

Si vous envisagez d'écrire des applications non triviales à l'aide de filtres de recherche vectorielle et de métadonnées, il est important de comprendre et d'être à l'aise avec le langage de requête, tant en termes d'ergonomie que de mise en œuvre, que vous vous inscrivez pour utiliser, écrire et maintenir.

6. Gestion du cycle de vie des vecteurs

Très bien, vous êtes arrivé jusqu'ici. Vous disposez d'une base de données vectorielle qui possède tous les principes fondamentaux de base de données dont vous avez besoin, dispose de la bonne stratégie d'indexation incrémentielle pour votre cas d'utilisation, a une bonne histoire autour de vos besoins en matière de filtrage de métadonnées et maintiendra son index à jour avec les latences. vous pouvez tolérer. Génial.

Votre équipe ML (ou peut-être OpenAI) propose une nouvelle version de son modèle d'intégration. Vous disposez d’une gigantesque base de données remplie d’anciens vecteurs qui doivent maintenant être mis à jour. Maintenant quoi? Où allez-vous exécuter ce gros travail batch-ML ? Comment allez-vous stocker les résultats intermédiaires ? Comment allez-vous procéder pour passer à la nouvelle version ? Comment comptez-vous procéder sans affecter votre charge de travail de production ?

Posez les questions difficiles

La recherche de vecteurs est un domaine en pleine émergence et nous constatons que de nombreux utilisateurs commencent à mettre des applications en production. Mon objectif pour cet article était de vous armer de certaines des questions cruciales et difficiles que vous ne savez peut-être pas encore poser. Et vous bénéficierez grandement d’une réponse le plus tôt possible.

Dans cet article, je n'ai pas expliqué comment Rockset a travaillé et travaille pour résoudre tous ces problèmes et pourquoi certaines de nos solutions sont révolutionnaires et meilleures que la plupart des autres tentatives de pointe. Pour couvrir cela, il faudrait de nombreux articles de blog de cette taille, ce qui est, je pense, précisément ce que nous allons faire. Restez à l'écoute pour plus.