Technical Tutorials

Pendant des années, le modèle de « persistance polyglotte » dictait que les types de données nécessitaient des moteurs de stockage différents. Les données transactionnelles résidaient dans des bases de données relationnelles, tandis que les journaux non structurés allaient vers des magasins de documents. Mais l'essor de l'IA générative et des grands modèles de langage (LLM) a introduit un nouveau type de données qui défie ce paradigme : le vecteur. À mesure que les applications s'appuient de plus en plus sur la recherche sémantique et l'appariement de similarité, la gestion de tableaux de haute dimension est devenue critique. Entrez dans le monde de pgvector, une extension puissante pour PostgreSQL qui apporte la recherche de similarité vectorielle native à la base de données relationnelle la plus populaire au monde.

Pourquoi pgvector ?

Les développeurs font souvent face à un dilemme lors de l'implémentation de la recherche vectorielle : doivent-ils introduire une base de données vectorielle spécialisée comme Pinecone ou Weaviate, ajoutant une complexité opérationnelle et une surcharge de synchronisation des données, ou doivent-ils s'en tenir à leur infrastructure existante ? pgvector résout ce problème en vous permettant de stocker et de rechercher des vecteurs directement dans vos données relationnelles.

Les avantages clés incluent :

Conformité ACID : Les données vectorielles sont transactionnelles. Vous pouvez mettre à jour un vecteur et annuler les modifications si une insertion échoue, une fonctionnalité souvent absente des magasins vectoriels NoSQL.
Capacités de jointure : Vous pouvez effectuer des jointures entre les résultats de recherche vectorielle et d'autres logiques métier (par exemple, profils d'utilisateurs, autorisations) dans une seule requête SQL.
Simplicité opérationnelle : Si vous utilisez déjà PostgreSQL, vous n'avez pas besoin de maintenir un cluster séparé. Les stratégies de sauvegarde, de surveillance et de mise à l'échelle restent cohérentes.

Commencer : Conception du schéma

La configuration de pgvector est simple. Assurez-vous d'abord que l'extension est installée sur votre instance PostgreSQL (la version 13 ou supérieure est recommandée). Ensuite, créez l'extension et définissez votre table :

CREATE EXTENSION vector;

CREATE TABLE embeddings (
    id BIGSERIAL PRIMARY KEY,
    metadata JSONB,
    embedding VECTOR(384) -- En supposant un vecteur de 384 dimensions
);

Remarquez le type VECTOR(384). La dimension doit correspondre à la taille de sortie de votre modèle d'embedding (par exemple, text-embedding-ada-002 d'OpenAI produit des vecteurs de 1536 dimensions, tandis que certains modèles locaux produisent 384). Des dimensions non correspondantes entraîneront une erreur lors de l'insertion.

Stratégies d'indexation : HNSW vs. IVFFlat

Le balayage par force brute est viable pour les petits jeux de données (moins de 10 000 lignes), mais les performances se dégradent linéairement à mesure que les données augmentent. Pour passer à l'échelle, vous devez utiliser un index. pgvector prend en charge deux algorithmes principaux :

1. IVFFlat (Inverted File Index with Flat quantization)

IVFFlat regroupe les vecteurs dans un nombre fixe de listes en utilisant k-means. Lors de la requête, il ne recherche que les clusters les plus proches (probes). Il est efficace en mémoire et idéal pour les charges de travail axées sur la lecture avec de grands jeux de données.

2. HNSW (Hierarchical Navigable Small World)

HNSW construit une structure de graphe de vecteurs. Il offre un rappel plus élevé et des temps de requête plus rapides, mais nécessite considérablement plus de RAM lors de l'indexation et de la requête. Pour la plupart des applications IA modernes où la latence est critique, HNSW est le choix privilégié.

Voici comment créer un index HNSW :

CREATE INDEX ON embeddings 
USING hnsw (embedding vector_cosine_ops);

Note : La classe d'opérateurs vector_cosine_ops détermine la métrique de distance. Vous pouvez également utiliser vector_l2_ops (euclidienne) ou vector_ip_ops (produit scalaire). Choisissez en fonction de la normalisation de la sortie de votre modèle.

Effectuer une recherche sémantique

Une fois indexé, effectuer une recherche de similarité ressemble à une requête SQL standard. Supposons que vous ayez un vecteur de requête utilisateur : [0.1, 0.5, ...] (384 dimensions). Vous pouvez trouver les 10 enregistrements les plus similaires en utilisant l'opérateur de distance cosinus (<=>).

SELECT 
    id, 
    metadata, 
    embedding <=> '[0.1, 0.5, ...]' AS distance
FROM 
    embeddings
ORDER BY 
    distance
LIMIT 10;

Le résultat est ordonné par distance. Pour la similarité cosinus, une distance de 0 signifie des vecteurs identiques, tandis que 2 signifie des vecteurs opposés. De nombreux développeurs préfèrent retourner le score de similarité à la place. Vous pouvez y parvenir en convertissant la distance en score de similarité :

SELECT 
    id, 
    metadata, 
    1 - (embedding <=> '[0.1, 0.5, ...]') AS similarity
FROM 
    embeddings
ORDER BY 
    embedding <=> '[0.1, 0.5, ...]'
LIMIT 10;

Astuce d'optimisation des performances

Choisir la bonne métrique : Si vos embeddings sont normalisés à une longueur unitaire, la similarité cosinus et la distance euclidienne sont mathématiquement équivalentes. Dans ce cas, utilisez L2 (<->) car il est souvent plus rapide à calculer. S'ils ne sont pas normalisés, tenez-vous à Cosine (<=>) pour une précision sémantique meilleure.
Ajuster les paramètres HNSW : Le paramètre m contrôle le nombre de connexions par nœud (plus élevé = plus précis mais index plus volumineux). Le paramètre ef_search contrôle le nombre de candidats considérés lors de la recherche (plus élevé = plus lent mais plus précis). Commencez avec les valeurs par défaut (m=16) et augmentez ef_search si vous constatez que votre rappel tombe en dessous des niveaux acceptables.
Partitionnement : Pour les applications multi-locataires, envisagez de partitionner votre table par identifiant de locataire. Cela garantit que les opérations de recherche vectorielle ne scannent que les partitions pertinentes, réduisant considérablement l'E/S et l'utilisation de la mémoire.

Conclusion

pgvector est passé d'une extension de niche à une solution prête pour la production pour les applications pilotées par l'IA. Il comble le fossé entre les données relationnelles traditionnelles et la recherche sémantique moderne, offrant aux développeurs une plateforme unifiée qui est sécurisée, évolutive et facile à maintenir. Bien que les bases de données vectorielles spécialisées puissent encore offrir des optimisations pour les cas limites sur des jeux de données à l'échelle du milliard, pgvector reste le meilleur choix pour la grande majorité des applications IA, offrant le parfait équilibre entre performance, flexibilité et simplicité opérationnelle.