Guide des performances de recherche vectorielle

La recherche vectorielle De mosaïque AI est conçue pour une récupération rapide et évolutive. Les performances de recherche vectorielle dépendent de nombreux facteurs, notamment le choix de la référence SKU, la taille de l’index, le type de requête, la dimensionnalité vectorielle, les méthodes d’authentification et la façon dont votre application gère les pics de trafic. La plupart des charges de travail fonctionnent correctement en dehors de la zone, mais pour les situations où vous devez mettre à l’échelle ou optimiser la latence, ce guide présente des conseils pratiques et des modèles courants pour vous aider à configurer votre système pour optimiser les performances de recherche vectorielle.

Facteurs affectant les performances

Les performances ne sont pas un seul nombre : il s’agit d’une plage qui dépend des caractéristiques de la charge de travail, des choix de configuration et de l’implémentation du client. Ce guide est conçu pour vous aider à créer un modèle mental clair de fonctionnement des performances afin de pouvoir utiliser la Recherche vectorielle d’IA Mosaïque plus efficacement.

Voici les facteurs clés qui influencent le comportement du système :

• Choix de référence SKU : optimisé pour le stockage ou la norme.
• Taille de l’index : nombre de vecteurs stockés.
• Taille d’incorporation : généralement 384 à 1536.
• Type de requête : voisin le plus proche (ANN) ou hybride.
• Nombre de résultats demandés : des valeurs plus élevées augmentent le temps de récupération.
• Type d’incorporation : géré ou autogéré.
• Charge de requête : le trafic atteint le point de terminaison au fil du temps.
• Méthode d’authentification : connexion de votre application à Databricks.

Le reste de cet article fournit des conseils pratiques pour l’optimisation de chacune de ces variables et explique comment elles affectent la latence de recherche et le débit de requête dans les déploiements réels.

Choisir la référence SKU appropriée

Mosaic AI Vector Search offre deux références SKU, chacune conçue pour équilibrer la latence, l’extensibilité et l’efficacité des coûts en fonction de la charge de travail. Le choix de la référence SKU appropriée pour votre application est le premier levier de réglage des performances.

En général :

• Choisissez des points de terminaison standard lorsque la latence est critique et que votre index est bien inférieur à 320 Millions de vecteurs.
• Choisissez des points de terminaison optimisés pour le stockage lorsque vous utilisez des vecteurs de 10 M+, peut tolérer une latence supplémentaire et avoir besoin d’une meilleure efficacité des coûts par vecteur (jusqu’à 7x moins cher).

Le tableau suivant présente des instructions de performances attendues.

Comprendre la taille de l’index

Les performances sont les plus élevées lorsque votre index s’inscrit dans une seule unité de recherche vectorielle, avec un espace supplémentaire pour gérer une charge de requête supplémentaire. À mesure que les charges de travail sont mises à l’échelle au-delà d’une seule unité de recherche vectorielle (c’est-à-dire des vecteurs 2M+ pour standard ou 64M+ pour le stockage optimisé), la latence augmente et les types QPS sont désactivés. Finalement, QPS plateaux à environ 30 QPS (ANN).

Les performances dépendent de nombreux facteurs propres à chaque charge de travail, tels que les modèles de requête, les filtres, la dimensionnalité vectorielle et la concurrence. Les nombres suivants sont des points de référence.

Réduire la taille d’incorporation

La dimensionnalité vectorielle fait référence au nombre de caractéristiques de chaque vecteur. Les valeurs classiques sont 384, 768, 1024 ou 1536. Les dimensions supérieures fournissent des représentations plus expressives qui peuvent améliorer la qualité, mais viennent à un coût de calcul. Les vecteurs de dimension inférieure nécessitent moins de calcul lors de la récupération, ce qui se traduit par des temps de requête plus rapides et des QPS plus élevés. À l’inverse, les vecteurs à dimension supérieure augmentent la charge de calcul et réduisent le débit.

En règle générale, choisissez la plus petite dimensionnalité qui conserve la qualité de récupération pour votre cas d’usage.

Par exemple, la réduction de la dimensionnalité par un facteur de deux (par exemple, de 768 à 384) améliore généralement QPS d’environ 1,5x et réduit la latence d’environ 20%, en fonction de la taille de l’index et du modèle de requête. Ces gains s’ajoutent à des dimensions très faibles. Par exemple, l’utilisation de vecteurs 64 dimensionnels peut fournir des QPS considérablement plus élevés et une latence beaucoup plus faible par rapport aux benchmarks de dimension 768 indiqués dans le tableau. Cela rend 384 dimensions et moins particulièrement attrayantes pour les cas d’usage sensibles à la latence, tant que la qualité de récupération reste acceptable.

Utiliser ANN pour l’efficacité et utiliser hybride si nécessaire

Utilisez des requêtes ANN dans la mesure du possible. Ils sont les plus efficaces en calcul et prennent en charge le QPS le plus élevé.

Utilisez la recherche hybride si nécessaire. La recherche hybride améliore le rappel dans certaines applications, en particulier lorsque les mots clés spécifiques au domaine sont importants. La recherche hybride utilise généralement environ deux fois plus de ressources que ANN et peut réduire considérablement le débit.

Utiliser 10 à 100 résultats

Chaque requête inclut un num_results paramètre, qui correspond au nombre de résultats de recherche à retourner. Cette valeur a un impact direct sur les performances. La récupération de résultats supplémentaires nécessite une analyse plus approfondie de l’index, ce qui augmente la latence et réduit QPS. L’effet devient plus significatif à des valeurs plus élevées. Par exemple, l’augmentation num_results de 10x peut doubler la latence des requêtes et réduire la capacité QPS de 3x, en fonction de la taille et de la configuration de l’index.

En guise de meilleure pratique, conservez num_results la plage comprise entre 10 et 100, sauf si votre application nécessite plus d’informations. Essayez différentes num_results valeurs à l’aide de requêtes réalistes pour comprendre l’impact sur votre charge de travail.

Évitez l'option de mise à zéro pour la production

La recherche vectorielle prend en charge deux types d’incorporations avec différents compromis de performances.

Les incorporations gérées sont les plus pratiques. Avec les incorporations managées, Databricks génère automatiquement des incorporations pour vos lignes et requêtes. Au moment de la requête, le texte de la requête est passé à un point de terminaison de service de modèle pour générer l’incorporation, ce qui ajoute la latence. Si le modèle d’incorporation est externe, il introduit également une surcharge réseau supplémentaire.

Les incorporations autogéées vous permettent de calculer des incorporations à l’avance et de passer les vecteurs directement au moment de la requête. Cela évite la génération du runtime et permet la récupération la plus rapide. Tous les numéros de performances inclus dans cet article sont basés sur des incorporations autogéées.

Pour les cas d’utilisation de production en temps réel, évitez les points de terminaison de modèle qui sont mis à l’échelle à zéro. Les démarrages à froid peuvent retarder les réponses de plusieurs minutes ou même provoquer des échecs si le point de terminaison est inactif lorsqu’une requête arrive.

Planifier pour les pics de requêtes

Cette section décrit ce qu’il faut attendre à mesure que le trafic s’accélère et comment rester en dessous des limites critiques qui déclenchent des pics de latence ou des erreurs 429 (trop de requêtes).

La latence reste faible lorsque la charge est modérée et augmente progressivement à mesure que vous approchez de la capacité QPS maximale. Lorsque le système atteint 100% capacité QPS, il commence à renvoyer des erreurs 429. Si vous n’avez pas configuré de sauvegarde appropriée, l’application risque de ne pas répondre.

429 erreurs servent de mécanisme de sécurité pour protéger le système. Ils demandent au client de se réactiver et de réessayer plus tard afin que le point de terminaison reste sain et réactif, même en cas de pics de trafic soudains.

En guise de bonne pratique, utilisez le KIT SDK Python De recherche vectorielle, qui inclut une interruption intégrée et la gestion des nouvelles tentatives.

Si vous utilisez l’API REST, implémentez une interruption exponentielle avec gigue. Consultez les antimodèles Azure.

Utiliser des principaux de service avec des jetons OAuth

Utilisez des méthodes d’authentification efficaces pour optimiser les performances. Databricks recommande d’utiliser un principal de service avec un jeton OAuth dans tous les environnements de production. Les jetons d’accès OAuth offrent une sécurité accrue et tirent également parti de l’infrastructure optimisée pour le réseau pour permettre au système de fonctionner à pleine capacité.

Évitez d’utiliser des jetons d’accès personnels (PAT), car ils introduisent une surcharge réseau, ajoutent des centaines de millisecondes de latence et réduisent considérablement le QPS que votre point de terminaison peut maintenir.

Utiliser le Kit de développement logiciel (SDK) Python

Utilisez la dernière version du Kit de développement logiciel (SDK) Python pour tirer parti des optimisations intégrées des performances et de la fiabilité.

Réutilisez l’objet d’index entre les requêtes. Évitez d’appeler client.get_index(...).similarity_search(...) chaque requête, car ce modèle ajoute une latence inutile.

Au lieu de cela, initialisez l’index une fois et réutilisez-le :

# Initialize once
index = client.get_index(...)

# Then use it for every query
index.similarity_search(...)

Cela est important lors de l’utilisation de l’index de recherche vectorielle dans les environnements MLFlow, où vous pouvez créer l’objet d’index lors de l’initialisation du point de terminaison, puis le réutiliser pour chaque requête.

Ces conseils sont particulièrement utiles dans les applications sensibles à la latence en temps réel. Dans les configurations RAG avec plusieurs index ou flux d’autorisation pour le compte de l’utilisateur , où la sélection d’index ou les informations d’identification sont disponibles uniquement au moment de la requête, l’initialisation de l’objet d’index une seule fois peut ne pas être réalisable. Cette optimisation n’est pas nécessaire dans ces scénarios.

Parallélisez les points de terminaison

Databricks recommande d’explorer les stratégies suivantes pour augmenter le nombre total de QPS dans le système :

• Fractionner les index entre les points de terminaison. Si vous avez plusieurs index qui reçoivent une partie significative du trafic, hébergez-les sur des points de terminaison distincts pour atteindre une bande passante totale supérieure.
• Répliquez l’index entre les points de terminaison. Si la plupart du trafic atteint un seul index, dupliquez-le sur plusieurs points de terminaison. Fractionnez le trafic uniformément au niveau du client pour obtenir des gains QPS linéaires.

Utilisez des tests de charge pour vous assurer que vos points de terminaison sont correctement dimensionnés

Un test de charge mesure les performances de votre point de terminaison de recherche vectorielle sous différents niveaux de trafic, en simulant l’utilisation réelle et en vous aidant à dimensionner correctement votre point de terminaison pour répondre à vos besoins de production. Consultez Configurer un test de charge pour les points de terminaison de recherche vectorielle pour plus d’informations sur la création et l’exécution d’un test de charge.