Bonnes pratiques concernant la recherche vectorielle

Ce document fournit des recommandations pour optimiser les performances de la recherche vectorielle dans Spanner.

Comprendre les bases de Spanner

Pour effectuer des tests efficaces sur les performances de la recherche vectorielle dans Spanner, vous devez comprendre les bases de Spanner. Par exemple, la réexécution immédiate de la même requête peut être plus rapide en raison des caches. Pour tester les performances d'une application qui utilise principalement des données chaudes, effectuez d'abord une lecture de préchauffage.

Consultez les guides suivants :

Spanner traite les requêtes en parallèle en fonction des divisions de la base de données. Les tests avec une charge de requêtes de production soutenue peuvent activer la division basée sur la charge, ce qui améliore les performances des requêtes grâce à un parallélisme accru. Pour augmenter le parallélisme pour les charges futures, envisagez de prédécouper votre base de données, en particulier pour KNN.

Bonnes pratiques de recherche vectorielle

Ce document décrit les bonnes pratiques de recherche vectorielle suivantes :

Annoter la colonne d'embeddings

Annotez la colonne d'embeddings avec vector_length. Cette annotation permet d'optimiser les performances de la recherche des k plus proches voisins (KNN) et constitue une condition préalable à la recherche des plus proches voisins approximatifs (ANN) search.

Utiliser une requête top-k

Pour trouver les plus proches voisins, utilisez une clause ORDER BY avec LIMIT. Les requêtes top-k sont hautement optimisées pour la recherche vectorielle. Évitez de filtrer par seuil de distance dans une clause WHERE.

Par exemple, la requête suivante n'est pas recommandée :

SELECT d.DocId
FROM Documents AS d
WHERE COSINE_DISTANCE(d.DocEmbedding, @vector) < 1;

Utilisez plutôt :

SELECT d.DocId
FROM Documents AS d
ORDER BY COSINE_DISTANCE(d.DocEmbedding, @vector)
LIMIT 10;

L'utilisation d'une requête top-k est non seulement plus simple, car elle élimine le réglage du seuil de distance, mais elle permet également d'optimiser les performances spécialisées pour la recherche vectorielle.

Utiliser des littéraux SQL pour la clause LIMIT

Si la limite top-k est fixe, utilisez un littéral SQL au lieu d'un paramètre. Par exemple, utilisez LIMIT 10 au lieu de LIMIT @limit. L'optimiseur de requêtes Spanner dispose ainsi de plus d'informations pour sélectionner le meilleur .

Utiliser l'analyse orientée par lot

Les requêtes de recherche vectorielle sont très gourmandes en analyses. Pour les requêtes KNN, envisagez d'utiliser l'analyse orientée par lot avec l' scan_method=batch indicateur de requête. Il s'agit de la méthode d'analyse par défaut pour les requêtes ANN.

Utiliser KNN pour les petits ensembles de données

Si KNN est suffisant pour votre budget de latence, ne créez pas d'index vectoriel. KNN est plus précis, évite les coûts de création et de maintenance d'index, et peut être plus performant qu'ANN lorsque le nombre de lignes d'entrée après tout filtrage est faible.

Accélérer le KNN filtré avec un index secondaire

Pour améliorer les performances d'une requête KNN filtrée, créez un index secondaire sur la colonne de filtrage. Par exemple, examinez la requête suivante :

SELECT d.DocId
FROM Documents AS d
WHERE Category = 'toy'
ORDER BY COSINE_DISTANCE(d.DocEmbedding, @vector)
LIMIT 10;

Si le nombre de documents par catégorie est inférieur à quelques dizaines de milliers et que votre application peut accepter une latence de requête de 100 ms, créez un index secondaire sur la colonne Category. Stockez la colonne DocEmbedding dans l'index :

CREATE INDEX ON Documents(Category) STORING (DocEmbedding);

Cette création d'index permet d'accélérer la requête filtrée.

Utiliser ANN pour les grands ensembles de données

Si le nombre de lignes est élevé après l'évaluation des filtres, créez un index vectoriel et utilisez la recherche ANN. Plusieurs techniques peuvent accélérer le filtrage avec ANN :

  • Stocker les colonnes de filtrage : pour activer le filtrage lors de la traversée de la recherche vectorielle, stockez les colonnes de filtrage dans l'index vectoriel. Cela permet de supprimer les lignes non qualifiées au début de l'exécution.

    CREATE VECTOR INDEX ON Documents(DocEmbedding) STORING(Category);

  • Colonnes de filtrage de clés : pour accélérer le filtrage des colonnes hautement sélectives qui suppriment de nombreux résultats, organisez ces colonnes en tant que colonnes de clés supplémentaires dans l'index vectoriel. Les requêtes qui spécifient une égalité exacte (à l'aide de l'opérateur =) pour ces clés supplémentaires sont celles qui s'accélèrent le plus. L'utilisation de la clause IN pour l'une de ces clés supplémentaires n'atteint pas le même niveau d'accélération.

    CREATE VECTOR INDEX ON Documents(DocEmbedding, Category);

  • Éviter de stocker des colonnes volumineuses ou de les utiliser comme clés : cela pourrait diluer les blocs de données pour les embeddings, ce qui pourrait réduire l'efficacité de la lecture. Vous pouvez également utiliser une colonne de hachage dans l'index et utiliser la colonne volumineuse d'origine comme post-filtre après le top-k.

  • Créer un index vectoriel filtré (partiel) : si vous n'interrogez qu'un sous-ensemble de l' ensemble de données et qu'une condition de filtrage définit ce sous-ensemble, par exemple Category = "Tech", créez un index vectoriel filtré ou partiel.