guide de performances de recherche IA
L'IA Search est conçue pour une récupération rapide et évolutive. Les performances de l'IA Search dépendent de nombreux facteurs, notamment le choix de l'SKU, la taille de l'index, le type de query, 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 bien d'emblée, mais pour les situations où vous devez monter en charge ou optimiser la latence, ce guide présente des conseils pratiques et des modèles courants pour vous aider à configurer votre système afin d'obtenir des performances optimales.
Databricks AI Search était auparavant connu sous le nom de Databricks Vector Search.
Facteurs qui affectent les performances
La performance n’est pas un simple chiffre. 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 à élaborer un modèle mental clair du fonctionnement des performances afin que vous puissiez utiliser la recherche IA plus efficacement.
Voici les facteurs clés qui influencent le comportement du système :
- Choix de SKU : standard ou optimisé pour le stockage.
- Taille de l'index : nombre de vecteurs stockés.
- Taille d'intégration : généralement de 384 à 1536.
- Type de query : plus proche voisin approximatif (ANN) ou hybride.
- Nombre de résultats demandés : des valeurs plus élevées augmentent le temps de récupération.
- Type d'intégration : gérée ou autogérée.
- Charge de query : combien de trafic atteint l'Endpoint au fil du temps.
- Méthode d’authentification : comment votre application se connecte à Databricks.
Le reste de cet article fournit des conseils pratiques pour régler chacune de ces variables et explique comment elles affectent la latence de recherche et le throughput des requêtes dans les déploiements réels.
Choisissez le bon SKU
AI Search propose deux SKU, chacun conçu pour équilibrer la latence, l’évolutivité et la rentabilité en fonction de la charge de travail. Choisir le bon SKU pour votre application est le premier levier d'optimisation des performances.
En général :
- Choisissez des Endpoint standard lorsque la latence est critique et que votre index est bien inférieur à 320 millions de vecteurs.
- Choisissez des endpoints optimisés pour le stockage lorsque vous travaillez avec plus de 10 M de vecteurs, pouvez tolérer une latence supplémentaire et avez besoin d’une meilleure efficacité des coûts par vecteur (jusqu’à 7 fois moins cher).
Le tableau suivant présente quelques directives de performance attendues.
SKU | Latence | QPS | Capacité de l’Endpoint | Taille de l'unité de recherche vectorielle (VSU) |
|---|---|---|---|---|
Standard | 20 - 50 ms | de 30 à plus de 200 | 320 M de vecteurs | 2 millions de vecteurs |
Stockage optimisé | de 300 à 500 ms | de 30 à 50 | 1 Md de vecteurs | 64 millions de vecteurs |
Comprendre la taille de l'index
Les performances sont maximales lorsque votre index tient dans une seule unité de recherche vectorielle, avec un espace supplémentaire pour gérer la charge de requêtes supplémentaire. Lorsque les charges de travail montent en charge au-delà d'une seule unité de recherche vectorielle (c'est-à-dire, plus de 2 millions de vecteurs pour la version standard ou plus de 64 millions pour la version optimisée pour le stockage), la latence augmente et le QPS diminue progressivement. Finalement, le nombre de requêtes par seconde (QPS) se stabilise à environ 30 QPS (ANN).
La performance dépend de nombreux facteurs propres à chaque charge de travail, tels que les modèles de query, les filtres, la dimensionnalité des vecteurs et la concurrence. Les numéros suivants sont des points de référence.
SKU | Vecteurs | Dimension | Latence | QPS | Requêtes mensuelles |
|---|---|---|---|---|---|
Standard | 10 000 | 768 | 20 ms | 200+ | 500M+ |
10 M | 768 | 40 ms | 30 | 78M | |
100 M | 768 | 50 ms | 30 | 78M | |
Stockage optimisé | 10 M | 768 | 300 ms | 50 | 130 M |
100 M | 768 | 400 ms | 40 | 100 M | |
1B | 768 | 500 ms | 30 | 78M |
Minimiser la taille d'intégration
La dimensionnalité des vecteurs fait référence au nombre de caractéristiques dans chaque vecteur. Les valeurs typiques sont 384, 768, 1024 ou 1536. Des dimensions plus élevées offrent des représentations plus expressives qui peuvent améliorer la qualité, mais ont un coût de calcul (compute). Les vecteurs de plus faible dimensionnalité nécessitent moins de calculs lors de la récupération, ce qui se traduit par des temps de query plus rapides et un QPS plus élevé. Inversement, les vecteurs de dimension supérieure augmentent la charge de calcul (compute) et réduisent le throughput.
En règle générale, choisissez la plus petite dimensionnalité qui préserve la qualité de l'extraction pour votre cas d'utilisation.
Par exemple, la réduction de la dimensionnalité d'un facteur deux (disons, de 768 à 384) améliore généralement le 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 query. Ces gains s'accumulent davantage à des dimensions très faibles. Par exemple, l'utilisation de vecteurs de 64 dimensions peut offrir un QPS nettement plus élevé et une latence considérablement plus faible par rapport aux références de 768 dimensions présentées dans le tableau. Cela rend les dimensions inférieures ou égales à 384 particulièrement attrayantes pour les cas d'utilisation à haut throughput et sensibles à la latence, tant que la qualité de la récupération reste acceptable.
Utilisez l'ANN pour l'efficacité, et utilisez un hybride si nécessaire
Utilisez les query ANN dans la mesure du possible. Ils sont les plus efficients en matière de compute et prennent en charge les QPS les plus élevés.
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 l'ANN et peut réduire considérablement le throughput.
Utiliser de 10 à 100 résultats
Chaque query inclut un parameter num_results, qui représente le nombre de résultats de recherche à renvoyer. Cette valeur a un impact direct sur les performances. La récupération de plus de résultats nécessite une analyse plus approfondie de l'index, ce qui augmente la latence et réduit le QPS. L'effet devient plus significatif à des valeurs plus élevées. Par exemple, l'augmentation de num_results par 10 peut doubler la latence des query et réduire la capacité QPS par 3, selon la taille et la configuration de l'index.
En tant que bonne pratique, maintenez num_results dans la plage de 10 à 100, à moins que votre application n'exige spécifiquement davantage. Essayez différentes valeurs num_results à l'aide de queries réalistes pour comprendre l'impact sur votre workload.
Évitez le dimensionnement à zéro pour la production
AI Search prend en charge deux types d'embeddings avec des compromis de performance différents.
Les intégrations gérées sont les plus pratiques. Avec les intégrations gérées, Databricks génère automatiquement des intégrations pour vos lignes et vos queries. Au moment de la query, le texte de la query est transmis à un Endpoint de déploiement de modèle pour générer l'intégration, ce qui ajoute de la latence. Si le modèle d'intégration est externe, il introduit également une surcharge réseau supplémentaire.
Les intégrations autogérées vous permettent de compute les intégrations à l'avance et de transmettre les vecteurs directement au moment de la query. Cela évite la génération à l'exécution et permet la récupération la plus rapide. Tous les chiffres de performance inclus dans cet article sont basés sur des intégrations autogérées.
Pour les cas d'utilisation de production en temps réel, évitez les Endpoint de modèle qui montent en charge zéro. Les démarrages à froid peuvent retarder les réponses de plusieurs minutes, voire provoquer des échecs si l'Endpoint est inactif lorsqu'une query arrive.
Plan pour les pics de query.
Cette section décrit ce qu'il faut attendre à mesure que le trafic augmente et comment rester en dessous des limites critiques qui Trigger 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 % de sa capacité QPS, il commence à renvoyer des erreurs 429. Si vous n'avez pas configuré de backoff approprié, l'application pourrait devenir non réactive.
Les erreurs 429 servent de mécanisme de sécurité pour protéger le système. Ils demandent au client de se retirer et de réessayer plus tard afin que l'endpoint reste sain et réactif, même en cas de pics de trafic soudains.
En guise de bonne pratique, utilisez le SDK Python d'AI Search, qui inclut une gestion intégrée des nouvelles tentatives et du backoff.
Si vous utilisez l'API REST, mettez en œuvre un mécanisme d'interruption exponentielle avec gigue. Consultez cet article de blog AWS.
Utilisez des Service Principal avec des jetons OAuth.
Utilisez des méthodes d'authentification efficaces pour des performances optimales. Databricks recommande d'utiliser un Service Principal 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 d'une infrastructure optimisée pour le réseau afin de permettre au système de fonctionner à pleine capacité.
Évitez d'utiliser les jetons d'accès personnels (PAT), car ils entraînent une surcharge réseau, ajoutent des centaines de millisecondes de latence et réduisent considérablement le QPS que votre endpoint peut supporter.
Utiliser le SDK Python
Utilisez la dernière version du SDK Python pour bénéficier des optimisations de performances et de fiabilité intégrées.
Réutilisez l'objet d'index sur plusieurs 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(...)
C'est important lors de l'utilisation de l'index de recherche IA dans les environnements MLFlow, où vous pouvez créer l'objet d'index lors de l'initialisation de l'endpoint et le réutiliser ensuite pour chaque requête.
Ce guide est particulièrement utile dans les applications en temps réel, sensibles à la latence. Dans les configurations RAG avec plusieurs index ou les flux d'autorisation au nom de l'utilisateur, où la sélection d'index ou les informations d'identification ne sont disponibles qu'au moment de la query, l'initialisation de l'objet index une seule fois peut ne pas être faisable. Cette optimisation n'est pas nécessaire dans ces scénarios.
Monter en charge le throughput de l'endpoint avec un QPS élevé
Par default, les endpoints standard prennent en charge de 20 à 200 QPS selon la taille de l'index. Les applications en temps réel telles que les barres de recherche, les systèmes de recommandation et la correspondance d'entités nécessitent souvent de 100 à plus de 1 000 QPS. Sur les Endpoint standard uniquement, vous pouvez définir un QPS cible. Databricks met à disposition l'infrastructure pour correspondre au mieux à ce niveau de throughput (au mieux, non garanti) lorsque les index sont créés ou synchronisés.
Utiliser QPS élevé lorsque :
- Votre application nécessite plus de 50 QPS de throughput soutenu.
- Vous recevez des erreurs 429 (Too Many Requests) sous une charge normale.
- La latence se dégrade à mesure que le trafic augmente, même lorsque l'utilisation moyenne semble faible.
Vous pouvez définir un QPS cible à l'aide de l'interface utilisateur, du SDK ou de l'API REST de Databricks. Consultez Monter en charge le throughput de l'Endpoint de recherche IA avec un QPS élevé.
Paralléliser sur les Endpoint
Si un QPS élevé n'est pas disponible dans votre workspace, ou si vous avez besoin d'un throughput extrêmement élevé au-delà d'un seul endpoint, Databricks recommande les stratégies suivantes :
- Fractionnez les index entre les endpoints. Si vous avez plusieurs index qui reçoivent chacun une part importante du trafic, hébergez-les sur des endpoints distincts pour atteindre une bande passante totale plus élevée.
- Répliquez l'index sur les Endpoint. Si la plupart du trafic atteint un seul index, dupliquez-le sur plusieurs Endpoint et répartissez le trafic uniformément au niveau du client pour des gains linéaires de QPS.
Utilisez les tests de charge pour vous assurer que vos Endpoints sont correctement dimensionnés
Un test de charge mesure les performances de votre Endpoint de recherche IA sous différents niveaux de trafic, simulant une utilisation réelle et vous aidant à dimensionner correctement votre Endpoint pour répondre à vos exigences de production. Consultez Configurer un test de charge pour les Endpoint AI Search pour plus de détails sur la création et l'exécution d'un test de charge.