Partage via

Recherche vectorielle dans Azure Cosmos DB for NoSQL (préversion)

  • Article

S’APPLIQUE À : NoSQL

Azure Cosmos DB pour NoSQL propose désormais l’indexation et la recherche vectorielle en préversion. Cette fonctionnalité est conçue pour gérer des vecteurs à haute dimension, ce qui permet une recherche vectorielle efficace et précise à n’importe quelle échelle. Vous pouvez désormais stocker des vecteurs directement dans les documents en même temps que vos données. Chaque document de votre base de données peut contenir non seulement des données sans schéma traditionnelles, mais également des vecteurs à haute dimension représentant d’autres propriétés des documents. Cette colocalisation des données et des vecteurs permet une indexation et une recherche efficaces, car les vecteurs sont stockés dans la même unité logique que les données qu’ils représentent. Le fait de conserver les vecteurs et les données ensemble simplifie la gestion des données, les architectures d’applications IA et l’efficacité des opérations basées sur des vecteurs.

Azure Cosmos DB pour NoSQL offre une flexibilité en permettant de choisir la méthode d’indexation de vecteurs :

  • Une recherche exacte des plus proches voisins K (kNN, parfois appelée « force brute ») ou « plate » peut fournir un rappel de récupération de 100 % pour les recherches vectorielles plus petites et ciblées. en particulier lorsqu’elle est combinée avec des filtres de requête et des clés de partition.
  • Index plat quantifié qui compresse les vecteurs à l’aide de méthodes de quantification basées sur DiskANN pour une meilleure efficacité dans la recherche kNN.
  • DiskANN, une suite d’algorithmes d’indexation de vecteurs de pointe développée par Microsoft Research pour alimenter la recherche vectorielle efficace et de haute précision à n’importe quelle échelle.

En savoir plus sur l’indexation de vecteurs ici

La recherche vectorielle dans Azure Cosmos DB peut être combinée avec tous les autres filtres et index de requête NoSQL Azure Cosmos DB pris en charge à l’aide de clauses WHERE. Cela permet à vos recherches vectorielles de former les données les plus pertinentes pour vos applications.

Cette fonctionnalité améliore les fonctionnalités principales d’Azure Cosmos DB, ce qui le rend plus polyvalent pour gérer les données vectorielles et les exigences de recherche dans les applications IA.

Qu'est-ce qu'un stockage vectoriel ?

Un stockage vectoriel ou une base de données vectorielle est une base de données conçue pour stocker et gérer des incorporations vectorielles, qui sont des représentations mathématiques de données dans un espace de grande dimension. Dans cet espace, chaque dimension correspond à une caractéristique des données, et des dizaines de milliers de dimensions peuvent être utilisées pour représenter des données sophistiquées. La position d’un vecteur dans cet espace représente ses caractéristiques. Les mots, expressions ou documents entiers, ainsi que les images, l’audio et d’autres types de données peuvent tous être vectorisés.

Comment fonctionne un magasin de vecteurs ?

Dans un magasin de vecteurs, des algorithmes de recherche vectorielle sont utilisés pour indexer et interroger les incorporations. Parmi les algorithmes de recherche vectorielle connus figurent entre autres HNSW (Hierarchical Navigable Small World), IVF (Inverted File), DiskANN. La recherche vectorielle est une méthode qui vous aide à trouver des éléments similaires en fonction de leurs caractéristiques de données, plutôt que des correspondances exactes sur un champ de propriété. Cette technique est utile dans des applications comme la recherche de texte similaire, la recherche d’images associées, la création de recommandations ou même la détection d’anomalies. Elle est utilisée pour interroger les incorporations vectorielles des données que vous avez créées en utilisant un modèle de Machine Learning à l’aide d’une API d’incorporation. Des exemples d’API d’incorporation sont Incorporations Azure OpenAI et Hugging Face sur Azure. La recherche vectorielle mesure la distance entre les vecteurs de données et votre vecteur de requête. Les vecteurs de données les plus proches de votre vecteur de requête sont ceux qui se révèlent les plus similaires sémantiquement.

Dans la base de données vectorielle intégrée dans Azure Cosmos DB for NoSQL, les incorporations peuvent être stockées, indexées et interrogées en même temps que les données d’origine. Cette approche élimine le coût supplémentaire dû à la réplication des données dans une base de données vectorielle pure distincte. De plus, cette architecture conserve les incorporations vectorielles et les données d’origine ensemble, ce qui facilite les opérations de données multimodales et permet d’accroître la cohérence, la mise à l’échelle et le niveau de performance des données.

S’inscrire à la fonctionnalité d’aperçu de la recherche vectorielle

La recherche vectorielle pour Azure Cosmos DB for NoSQL nécessite une inscription aux fonctionnalités en préversion dans la page Fonctionnalités de votre Azure Cosmos DB. Suivez les étapes ci-dessous pour vous inscrire :

  1. Accédez à votre page de ressource Azure Cosmos DB for NoSQL.

  2. Sélectionnez le volet « Fonctionnalités » sous l’élément de menu « Paramètres ».

  3. Sélectionnez « Recherche vectorielle dans Azure Cosmos DB for NoSQL ».

  4. Lisez la description de la fonctionnalité pour confirmer que vous souhaitez vous inscrire à la préversion.

  5. Sélectionnez « Activer » pour vous inscrire avec la préversion.

Remarque

La demande d’inscription est approuvée automatiquement, mais l’opération peut prendre parfois plusieurs minutes.

Remarque

DiskANN est disponible en préversion contrôlée et nécessite de remplir ce formulaire. Vous serez contacté par un membre de l’équipe Azure Cosmos DB lorsque votre ressource a été intégrée pour utiliser l’index DiskANN.

Conseil

Vous pouvez également utiliser Azure CLI pour mettre à jour les fonctionnalités de votre compte pour prendre en charge la recherche vectorielle NoSQL.

az cosmosdb update \
     --resource-group <resource-group-name> \
     --name <account-name> \
     --capabilities EnableNoSQLVectorSearch

Utiliser le niveau gratuit d’Azure Cosmos DB valable pendant toute la durée de vie du compte

Stratégies de vecteur de conteneur

L’exécution d’une recherche vectorielle avec Azure Cosmos DB pour NoSQL vous oblige à définir une stratégie vectorielle pour le conteneur. Cela fournit des informations essentielles pour que le moteur de base de données effectue une recherche efficace de vecteurs trouvés dans les documents du conteneur. Cela donne également à la stratégie d’indexation de vecteurs les informations nécessaires, si vous choisissez d’en spécifier une. Les informations suivantes sont incluses dans la stratégie de vecteur contenu :

  • « chemin » : propriété contenant le vecteur (obligatoire).
  • « type de données » : type de données de la propriété de vecteur (Float32 par défaut). 
  • « dimensions » : dimensionnalité ou longueur de chaque vecteur dans le chemin. Tous les vecteurs d’un chemin doivent avoir le même nombre de dimensions. (1536 par défaut).
  • « distanceFunction » : métrique utilisée pour calculer la distance/similarité. Métriques prises en charge :
    • cosinus, qui a des valeurs comprises entre -1 (le moins similaire) et +1 (le plus similaire).
    • produit scalaire, qui a des valeurs allant de -inf (le moins similaire) à +inf (le plus similaire).
    • euclidienne, qui a des valeurs comprises entre 0 (le plus similaire) et +inf) (le moins similaire).

Remarque

Chaque chemin unique peut disposer au maximum d’une stratégie. Toutefois, plusieurs stratégies peuvent être spécifiées à condition qu’elles ciblent toutes un chemin différent.

La stratégie de vecteur de conteneur peut être décrite en tant qu’objets JSON. Voici deux exemples de stratégies de vecteur de conteneur valides :

Une stratégie avec un tracé vectoriel unique

{
    "vectorEmbeddings": [
        {
            "path":"/vector1",
            "dataType":"float32",
            "distanceFunction":"cosine",
            "dimensions":1536
        }
    ]
}

Une stratégie avec deux tracés vectoriels

{
    "vectorEmbeddings": [
        {
            "path":"/vector1",
            "dataType":"float32",
            "distanceFunction":"cosine",
            "dimensions":1536
        },
        {
            "path":"/vector2",
            "dataType":"int8",
            "distanceFunction":"dotproduct",
            "dimensions":100
        }
    ]
}

Stratégies d’indexation de vecteurs

Les index vectoriels augmentent l’efficacité lors de l’exécution de recherches vectorielles à l’aide de la fonction système VectorDistance. Les recherches vectorielles ont une latence plus faible, un débit plus élevé et moins de consommation de RU lors de l’utilisation d’un index vectoriel. Vous pouvez spécifier les types de stratégies d’index vectoriel suivants :

Type Description Dimensions maximales
flat Stocke les vecteurs sur le même index que d’autres propriétés indexées. 505
quantizedFlat Quantifie (compresse) les vecteurs avant le stockage sur l’index. Cela peut améliorer la latence et le débit au prix d’une précision légèrement moins grande. 4096
diskANN Crée un index basé sur DiskANN pour une recherche approximative rapide et efficace. 4096

Quelques points à noter :

  • Les types d’index flat et quantizedFlat utilisent l’index d’Azure Cosmos DB pour stocker, puis lire chaque vecteur lors de l’exécution d’une recherche vectorielle. Les recherches vectorielles avec un index flat sont des recherches par force brute et produisent une exactitude ou un rappel de 100 %. Autrement dit, vous êtes sûr de trouver les vecteurs les plus similaires dans le jeu de données. Toutefois, il existe une limitation de dimensions 505 pour les vecteurs sur un index plat.

  • L’index quantizedFlat stocke les vecteurs quantifiés (compressés) sur l’index. Les recherches vectorielles avec un index quantizedFlat sont également des recherches par force brute, mais leur exactitude peut être légèrement inférieure à 100 %, car les vecteurs sont quantifiés avant l’ajout à l’index. Toutefois, les recherches vectorielles avec quantized flat doivent avoir une latence plus faible, un débit plus élevé et un coût de RU moins élevé que les recherches vectorielles sur un index flat. Il s’agit d’une bonne option pour les scénarios plus petits ou ceux où vous utilisez des filtres de requête pour limiter la recherche vectorielle à un ensemble relativement petit de vecteurs. quantizedFlat doit être utilisé lorsqu’il existe au moins 1 000 vecteurs et moins de 100 000 vecteurs dans le conteneur.

  • L’index diskANN est un index distinct défini spécifiquement pour les vecteurs utilisant DiskANN, la suite d’algorithmes d’indexation de vecteurs hautes performances développée par Microsoft Research. Les index DiskANN peuvent offrir une certaine latence, le débit le plus élevé et les requêtes de coût de RU plus faibles, tout en conservant une exactitude élevée. Toutefois, puisque DiskANN est un index du plus proche voisin approximatif (ANN), l’exactitude peut être inférieure à quantizedFlat ou flat. DiskANN est disponible en préversion contrôlée et nécessite de remplir ce formulaire.

Voici des exemples de stratégies d’index vectoriel valides :

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": [
        {
            "path": "/_etag/?"
        }
    ],
    "vectorIndexes": [
        {
            "path": "/vector1",
            "type": "quantizedFlat"
        }
    ]
}

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": [
        {
            "path": "/_etag/?"
        }
    ],
    "vectorIndexes": [
        {
            "path": "/vector1",
            "type": "quantizedFlat"
        },
        {
            "path": "/vector2",
            "type": "DiskANN"
        }
    ]
}

Remarque

Les index plat quantifié et DiskANN nécessitent l’insertion d’au moins 1 000 vecteurs. Cela permet de garantir la précision du processus de quantification. S’il y a moins de 1 000 vecteurs, une analyse complète est exécutée à la place et entraîne des frais de RU plus élevés pour une requête de recherche vectorielle.

Important

À ce stade, dans la préversion de la recherche vectorielle, n’utilisez pas de chemin imbriqué ou de caractères génériques dans le chemin de la stratégie vectorielle. Les opérations de remplacement sur la stratégie vectorielle ne sont actuellement pas prises en charge.

Effectuer une recherche vectorielle avec des requêtes à l’aide de VectorDistance()

Après avoir créé un conteneur avec la stratégie vectorielle souhaitée et inséré des données vectorielles dans le conteneur, vous pouvez effectuer une recherche vectorielle à l’aide de la fonction système Distance vectorielle dans une requête. Voici un exemple de requête NoSQL qui projette le score de similarité en tant qu’alias SimilarityScore et trie dans l’ordre du plus similaire au moins similaire :

SELECT c.title, VectorDistance(c.contentVector, [1,2,3]) AS SimilarityScore   
FROM c  
ORDER BY VectorDistance(c.contentVector, [1,2,3])  

Limites et contraintes actuelles

L’indexation et la recherche vectorielles dans Azure Cosmos DB pour NoSQL présentent quelques limitations dans les premières phases de leur préversion publique.

  • Vous pouvez spécifier, au plus, un type d’index par chemin d’accès dans la stratégie d’index vectoriel
  • Vous pouvez spécifier, au plus, un type d’index DiskANN par conteneur
  • L’indexation vectorielle n’est prise en charge que sur les nouveaux conteneurs.
  • Les vecteurs indexés avec le type d’index flat peuvent être au maximum de 505 dimensions. Les vecteurs indexés avec le type d’index quantizedFlat ou DiskANN peuvent être au maximum de 4 096 dimensions.
  • quantizedFlat utilise la même méthode de quantification que DiskANN et n’est pas configurable pour l’instant.
  • Les bases de données de débit partagé ne peuvent pas utiliser la fonctionnalité d’aperçu de recherche vectorielle pour l’instant.
  • Le taux d’ingestion doit être limité lors de l’utilisation d’une préversion anticipée de DiskANN.

Étape suivante