Partager via


Données de vecteur d’index dans Cosmos DB dans Fabric

Cosmos DB dans Fabric offre désormais une indexation et une recherche vectorielles efficaces. Cette fonctionnalité est conçue pour gérer des vecteurs multimodaux et haute dimensionnels, ce qui permet une recherche de vecteur 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 multimodaux à haute dimension comme 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.

Cosmos DB dans Fabric offre la flexibilité qu’il offre pour choisir la méthode d’indexation vectorielle :

  • 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 vectorielle de pointe développés par Microsoft Research pour alimenter une recherche vectorielle multimodale efficace et haute précision à n’importe quelle échelle.

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

Cette fonctionnalité améliore les fonctionnalités principales de 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 magasin vectoriel ?

Un magasin de vecteurs 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 des données dans un espace à haute 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 Cosmos DB dans Fabric, 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.

Stratégies de vecteur de conteneur

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

  • path: propriété contenant le vecteur (obligatoire).

  • datatype: type de données de la propriété de vecteur. Les types pris en charge sont float32 (par défaut), int8et uint8.

  • dimensions: dimensionnalité ou longueur de chaque vecteur dans le chemin. Tous les vecteurs d’un chemin doivent avoir le même nombre de dimensions. (par défaut 1536).

  • distanceFunction: Métrique utilisée pour calculer la distance/la similarité. Les métriques prises en charge sont les suivantes :

    • cosine, qui a des valeurs de $-1$ (moins similaires) à $+1$ (le plus similaire).

    • dot product, qui a des valeurs de $-\infty$ (moins similaire) à $+\infty$ (le plus similaire).

    • euclidean, qui a des valeurs comprises entre $0$ (le plus similaire) et $+\infty$ (moins similaire).

Remarque

Chaque chemin unique peut disposer au maximum d’une stratégie. Toutefois, plusieurs stratégies peuvent être spécifiées s’ils ciblent tous un chemin différent.

La stratégie de vecteur de conteneur peut être décrite sous forme d'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
    }
  ]
}

Pour plus d’informations et des exemples de paramètres d’une stratégie de vecteur de conteneur, consultez les exemples de stratégie d’indexation de vecteurs.

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 ces types de stratégies d’index vectoriel :

Descriptif 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. Cette stratégie peut améliorer la latence et le débit au coût d’une petite quantité de précision. 4096
diskANN Crée un index basé sur DiskANN pour une recherche approximative rapide et efficace. 4096

Remarque

Les index quantizedFlat et diskANN nécessitent l’insertion d’au moins 1 000 vecteurs. Ce minimum consiste à garantir la précision du processus de quantisation. 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.

Quelques points à noter :

  • Les types d’index flat et quantizedFlat utilisent l’index de Cosmos DB pour stocker et lire chaque vecteur pendant 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, ils sont assurés de trouver les vecteurs les plus similaires dans le jeu de données. Toutefois, une limitation existe des 505 dimensions 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. Cet index est une bonne option pour les scénarios plus petits ou les scénarios dans lesquels vous utilisez des filtres de requête pour affiner la recherche vectorielle sur un ensemble relativement petit de vecteurs. quantizedFlat est recommandé quand le nombre de vecteurs à indexer est aux alentours de 50 000 ou moins par partition physique. Toutefois, cette recommandation n’est qu’une recommandation générale et les performances réelles doivent être testées, car chaque scénario peut être différent.

  • 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 des latences les plus faibles, un débit parmi les plus élevés et des requêtes au coût de RU le plus bas, tout en conservant une grande exactitude. En général, DiskANN est le type d’index le plus performant de tous s’il existe plus de 50 000 vecteurs par partition physique.

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

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

Important

Chemin vectoriel ajouté à la excludedPaths section de la stratégie d’indexation afin d'optimiser les performances d'insertion. Ne pas ajouter le chemin de vecteur à excludedPaths entraînera des frais d’unités de requête et une latence plus élevés pour les insertions vectorielles.

Important

Les caractères génériques (*, []) ne sont actuellement pas pris en charge dans la politique de vecteur ou l’index vectoriel.

Effectuer une recherche vectorielle avec des requêtes à l’aide de VECTORDISTANCE

Une fois que vous avez créé un conteneur avec la stratégie de vecteur souhaitée et inséré des données vectorielles dans le conteneur, vous pouvez effectuer une recherche vectorielle en utilisant la fonction intégrée dans une requête. Voici un exemple de requête NoSQL qui projette le score de similarité en tant qu’alias score et trie dans l’ordre du plus similaire au moins similaire :

SELECT TOP 10
  c.title,
  VECTORDISTANCE(c.contentVector, [1,2,3]) AS score 
FROM
  container c
ORDER BY
  VECTORDISTANCE(c.contentVector, [1,2,3])   

Important

Utilisez toujours une clause TOP N dans l’instruction SELECT d’une requête. Sinon, la recherche vectorielle tente de retourner de nombreux résultats supplémentaires entraînant le coût de plus d’unités de requête (RU) et une latence plus élevée que nécessaire.