Préparer SQL pour la recherche vectorielle

  • 10 minutes

Avant de pouvoir exécuter des recherches vectorielles, vous devez stocker des vecteurs dans votre base de données et décider de la façon dont ces recherches s’exécutent. Cette unité couvre les décisions de conception que vous prenez avant d’écrire votre première requête vectorielle.

La recherche vectorielle recherche des lignes basées sur une similarité mathématique plutôt que sur des correspondances exactes. Pour effectuer ce travail, vous stockez des incorporations sous forme de vecteurs, choisissez comment mesurer la similarité et décider de rechercher tous les vecteurs exactement ou d’utiliser un index pour obtenir des résultats approximatifs plus rapides.

Stocker des vecteurs avec le type de données vector

SQL Server et Azure SQL Database fournissent un type de données vectorielle natif conçu pour stocker des incorporations. Chaque vecteur est un tableau de nombres à virgule flottante, stocké dans un format binaire optimisé, mais exposé en tant que tableaux JSON pour des raisons pratiques.

Lorsque vous définissez une colonne vectorielle, vous spécifiez le nombre de dimensions :

CREATE TABLE dbo.Products
(
    ProductID INT PRIMARY KEY,
    Name NVARCHAR(100),
    Description NVARCHAR(MAX),
    DescriptionVector VECTOR(1536) NOT NULL
);

Le nombre entre parenthèses correspond aux dimensions produites par votre modèle d’incorporation. Par exemple, le modèle text-embedding-3-small d’OpenAI produit 1 536 dimensions, de sorte que votre colonne soit VECTOR(1536). Le maximum pris en charge est de 1 998 dimensions.

Chaque élément est stocké sous la forme d’un float simple précision (4 octets). Un vecteur de dimension de 1 536 utilise environ 6 Ko par ligne. Lors de la conception de votre table, tenez compte de la façon dont cette colonne affecte le stockage et la mémoire à mesure que vos données augmentent.

Comprendre les métriques de distance

La recherche vectorielle fonctionne en calculant la distance entre les vecteurs. Les vecteurs plus proches représentent des concepts plus similaires. SQL Server prend en charge trois métriques de distance :

La distance cosinus mesure l’angle entre les vecteurs, ignorant leur magnitude. Deux vecteurs pointant dans la même direction ont une distance cosinus de 0, quelle que soit leur longueur. Cette métrique fonctionne bien lorsque vous vous souciez de la direction de la signification, et non de l’intensité. La distance cosinus est comprise entre 0 (identique) et 2 (opposé).

La distance euclide mesure la distance droite entre deux points dans l’espace vectoriel. Il considère à la fois la direction et l’ampleur. La distance euclide est comprise entre 0 (identique) et l’infini.

Dot product calcule la somme des produits à l’échelle des éléments. SQL Server retourne le produit point négatif afin que les valeurs plus petites indiquent des vecteurs plus similaires, cohérents avec les autres métriques.

La plupart des modèles d'empaquetage sont optimisés pour la similarité cosinus, ce qui fait de la distance cosinus un choix commun. Toutefois, la meilleure métrique dépend de la façon dont vos embeddings ont été entraînés.

Lorsque vous recherchez des vecteurs similaires, vous avez deux options : recherche exacte du voisin le plus proche (ENN) et recherche approximativement du voisin le plus proche (ANN).

La recherche voisine la plus proche compare votre vecteur de requête à chaque vecteur de la table. Elle garantit les résultats les plus précis, mais nécessite le calcul de la distance à chaque ligne. Utilisez la VECTOR_DISTANCE fonction pour effectuer une recherche exacte :

DECLARE @query VECTOR(1536) = '[0.1, 0.2, ...]';

SELECT TOP 10 ProductID, Name,
    VECTOR_DISTANCE('cosine', @query, DescriptionVector) AS Distance
FROM dbo.Products
ORDER BY Distance;

Cette requête calcule la distance de cosinus entre @query chaque ligne DescriptionVector, puis retourne les 10 correspondances les plus proches. Pour les petites tables (moins de 50 000 vecteurs comme indication générale), la recherche exacte fonctionne bien.

La recherche voisine la plus proche utilise un index vectoriel pour rechercher des vecteurs similaires sans analyser chaque ligne. Il favorise la rapidité au détriment d’une précision absolue, en fournissant des résultats très proches de l’exactitude sans garantir qu’il s’agisse des voisins les plus proches au sens strict.

Créez un index vectoriel à l’aide de CREATE VECTOR INDEX:

CREATE VECTOR INDEX idx_Products_DescriptionVector
ON dbo.Products(DescriptionVector)
WITH (METRIC = 'cosine', TYPE = 'DiskANN');

SQL Server utilise l’algorithme DiskANN, qui génère une structure de graphe qui permet une navigation rapide vers des vecteurs proches. Une fois l’index existant, utilisez la VECTOR_SEARCH fonction pour la recherche approximative :

DECLARE @query VECTOR(1536) = '[0.1, 0.2, ...]';

SELECT t.ProductID, t.Name, s.distance
FROM VECTOR_SEARCH(
    TABLE = dbo.Products AS t,
    COLUMN = DescriptionVector,
    SIMILAR_TO = @query,
    METRIC = 'cosine',
    TOP_N = 10
) AS s
ORDER BY s.distance;

Décider quand utiliser chaque approche

Le choix entre la recherche exacte et approximative dépend de la taille et des exigences de précision de votre jeu de données.

Utilisez la recherche exacte (VECTOR_DISTANCE) quand :

  • Votre table comporte moins de 50 000 vecteurs
  • Vos filtres de requête restreignent l’ensemble des candidats à un nombre limité de lignes
  • Vous avez besoin de résultats précis garantis et pouvez accepter des temps de requête plus longs

Utilisez une recherche approximative (VECTOR_SEARCH avec un index) lorsque :

  • Votre table comporte des centaines de milliers ou des millions de vecteurs
  • La vitesse des requêtes est plus importante que la précision parfaite
  • Un rappel proche de 1 (ce qui signifie que la majorité des véritables voisins les plus proches sont identifiés) est considéré comme acceptable

Le rappel évalue la proportion de véritables voisins les plus proches renvoyés par la recherche approximative par rapport à une recherche exacte. DiskANN atteint généralement un rappel élevé, ce qui signifie que les résultats obtenus sont très proches de ceux fournis par une recherche exacte.

Prendre en compte les limitations d’index

Les index vectoriels dans SQL Server ont des exigences spécifiques à connaître :

  • La table doit avoir une clé primaire entière à colonne unique avec un index cluster
  • Les tables avec des index vectoriels deviennent en lecture seule pendant que l’index existe : vous devez supprimer l’index pour modifier les données, puis la recréer
  • Les index vectoriels ne peuvent pas être partitionnés

Note

Les index vectoriels sont actuellement en préversion. Dans Azure SQL Database et SQL Database dans Microsoft Fabric, vous pouvez définir la configuration au niveau de la base de données ALLOW_STALE_VECTOR_INDEX sur ON afin d’autoriser les écritures, mais l’index ne prend pas en compte les nouvelles données tant qu’il n’a pas été reconstruit Cette option n’est actuellement pas disponible dans SQL Server 2025. Consultez la documentation actuelle pour connaître la dernière version de ces limitations.

Ces limitations affectent la façon dont vous concevez vos tables et flux de travail de maintenance. Pour les tables qui changent fréquemment, vous pouvez utiliser une recherche exacte jusqu’à ce que les données se stabilisent, puis ajouter un index vectoriel.

Points clés à prendre

La préparation de SQL pour la recherche vectorielle implique de prendre trois décisions : le type de données et les dimensions à utiliser, quelle mesure de distance correspond à votre modèle d’incorporation et si la recherche exacte ou approximative correspond à la taille de votre jeu de données. La recherche exacte avec des VECTOR_DISTANCE jeux de données plus petits ou des requêtes filtrées fonctionne bien, tandis que la recherche approximative avec VECTOR_SEARCH et un index DiskANN gère efficacement les jeux de données plus volumineux. Dans l’unité suivante, vous allez apprendre les fonctions et les modèles de requête spécifiques pour l’exécution de recherches vectorielles.