Les vecteurs sont le nouveau JSON de PostgreSQL

xguru · 2023-06-28T11:05:01+09:00

Les vecteurs sont des structures mathématiques bien étudiées, tandis que JSON est un format d’échange de données Mais dans le monde du stockage et de la recherche de données, ces deux modes de représentation sont devenus un langage commun, et ils deviendront bientôt des éléments essentiels du développement d’applications modernes Si la tendance actuelle se poursuit, les vecteurs deviendront eux aussi aussi importants que JSON dans la construction d’applications PostgreSQL s’est naturellement imposé comme choix pour stocker et interroger les résultats de l’IA générative Mais il ne s’agit pas d’un nouveau modèle de données. Les vecteurs, en tant que concept mathématique, existent depuis des centaines d’années Les tableaux, structure de données de base des vecteurs, sont enseignés dans la plupart des cours d’introduction à l’informatique. PostgreSQL prend également en charge les opérations vectorielles depuis plus de 20 ans Alors, qu’y a-t-il de nouveau ? C’est l’"accessibilité" de ces algorithmes IA/ML et la facilité avec laquelle certaines structures du "monde réel" (texte, image, vidéo) peuvent être représentées sous forme de vecteurs puis utilisées ensuite dans les applications On peut aussi dire que stocker dans une base de données les sorties ("embeddings") de ces systèmes n’est pas non plus nouveau, mais le nouveau modèle est l’"accessibilité" consistant à interroger et renvoyer ces données dans presque toutes les applications, quasiment en temps réel Quel rapport avec PostgreSQL ? Un modèle commun pour stocker et rechercher efficacement des types de données a considérablement simplifié le développement d’applications, en permettant aux gens de stocker les données dans le même espace et de travailler avec les outils existants Nous avons vu cela avec JSON il y a 10 ans, et nous observons maintenant le même modèle avec les données vectorielles Bref historique de JSON dans PostgreSQL (Voir l’article original) L’essor des vecteurs, un "nouveau type de JSON" Leur popularité grimpe en flèche ces jours-ci Le cas d’usage général consiste à construire un modèle à partir de données stockées, à les convertir au format vectoriel, puis à les utiliser pour la "recherche sémantique" Dans ce cas, une nouvelle entrée de recherche est convertie au format vectoriel, puis la base de données recherche ce qui s’en rapproche le plus La similarité s’appuie sur des fonctions de distance comme la distance euclidienne ou cosinus, et les résultats sont souvent limités au k-NN (Nearest Neighbors) ou aux k objets les plus similaires Comme l’encodage du jeu d’entraînement des vecteurs peut prendre beaucoup de temps, il est préférable de le mettre en cache dans un endroit comme une base de données et d’y exécuter les requêtes k-NN Le fait de disposer d’un ensemble de vecteurs prêts à être interrogés pour la recherche sémantique offre généralement une meilleure expérience utilisateur, d’où l’émergence du besoin d’une "base de données vectorielle" Le stockage de vecteurs n’est pas nouveau pour PostgreSQL En fait, le terme est trompeur, car PostgreSQL peut stocker des données multidimensionnelles (par ex. des matrices) Par défaut, les tableaux de PostgreSQL incluent bien certaines fonctions limitées pour les vecteurs, comme le calcul de la "distance" entre deux tableaux Il est possible d’écrire des procédures stockées, mais cela demande un peu plus de travail aux développeurs Heureusement, le type de données cube permet de dépasser ces limites cube est utilisé depuis plus de 20 ans et a été conçu pour effectuer des opérations sur des vecteurs de grande dimension cube inclut la plupart des fonctions de distance couramment utilisées dans la recherche de similarité vectorielle, y compris la distance euclidienne Il permet aussi d’exécuter efficacement des requêtes K-NN à l’aide d’index GiST Mais cube ne peut stocker que des vecteurs jusqu’à 100 dimensions, alors que les systèmes IA/ML modernes exigent des dimensions supérieures pgvector : extension open source pour stocker et rechercher des vecteurs dans PostgreSQL Avec pgvector, il est possible de stocker des vecteurs et d’exécuter des requêtes k-NN avec diverses métriques de distance (euclidienne, cosinus, produit scalaire, etc.) Actuellement, pvector est fourni avec un seul index, ivfflat, qui implémente la méthode d’indexation vectorielle IVR FLAT Interroger des données vectorielles indexées peut être différent de l’interrogation de données classiques En raison du coût d’une recherche des plus proches voisins dans des vecteurs de grande dimension, de nombreuses méthodes d’indexation vectorielle cherchent une réponse "approximative" "suffisamment proche" de la bonne réponse Cela mène au domaine de la recherche "ANN (Approximate Nearest Neighbor)" Les deux dimensions que les gens examinent pour les requêtes ANN sont l’équilibre entre performance et "recall" (le pourcentage de résultats pertinents renvoyés) Si l’on prend ivfflat comme exemple, on décide lors de la création de l’index ivfflat combien de listes il doit contenir Chaque liste représente un "centre", calculé via l’algorithme k-means Une fois tous les centres déterminés, ivfflat décide de quel centre chaque vecteur est le plus proche, puis l’ajoute à l’index Au moment d’interroger les données vectorielles, la variable ivfflat.probes détermine combien de centres doivent être vérifiés C’est là qu’apparaît le compromis performance/recall de l’ANN. Plus on visite de centres, plus le résultat est précis, mais les performances baissent Les prochaines étapes pour un meilleur support des vecteurs dans PostgreSQL Comme à l’époque de PostgreSQL 9.2, qui a officiellement pris en charge le type JSON, nous en sommes aux premières étapes de la manière de stocker des données vectorielles dans PostgreSQL PostgreSQL et pgvector sont déjà bons, mais ils vont encore beaucoup s’améliorer pgvector peut déjà traiter les cas de données IA/ML courants. De nombreux utilisateurs l’ont déjà déployé en production L’étape suivante consiste à aider à l’amélioration et à l’extension, et la plupart de ces travaux sont déjà en cours Ajouter davantage de parallélisation Prendre en charge les vecteurs de plus de 2 000 dimensions Exploiter l’accélération matérielle pour augmenter la vitesse de calcul Il y a beaucoup d’attentes autour de l’usage de PostgreSQL comme "base de données" vectorielle Comme l’histoire de JSON l’a montré, la communauté PostgreSQL trouvera un moyen de fournir ce support d’une manière extensible et sûre

(jkatz05.com)

26 points par xguru 2023-06-28 | 7 commentaires | Partager sur WhatsApp

Les vecteurs sont des structures mathématiques bien étudiées, tandis que JSON est un format d’échange de données
Mais dans le monde du stockage et de la recherche de données, ces deux modes de représentation sont devenus un langage commun, et ils deviendront bientôt des éléments essentiels du développement d’applications modernes
Si la tendance actuelle se poursuit, les vecteurs deviendront eux aussi aussi importants que JSON dans la construction d’applications
PostgreSQL s’est naturellement imposé comme choix pour stocker et interroger les résultats de l’IA générative
Mais il ne s’agit pas d’un nouveau modèle de données. Les vecteurs, en tant que concept mathématique, existent depuis des centaines d’années
Les tableaux, structure de données de base des vecteurs, sont enseignés dans la plupart des cours d’introduction à l’informatique. PostgreSQL prend également en charge les opérations vectorielles depuis plus de 20 ans
Alors, qu’y a-t-il de nouveau ? C’est l’"accessibilité" de ces algorithmes IA/ML et la facilité avec laquelle certaines structures du "monde réel" (texte, image, vidéo) peuvent être représentées sous forme de vecteurs puis utilisées ensuite dans les applications
On peut aussi dire que stocker dans une base de données les sorties ("embeddings") de ces systèmes n’est pas non plus nouveau, mais le nouveau modèle est l’"accessibilité" consistant à interroger et renvoyer ces données dans presque toutes les applications, quasiment en temps réel
Quel rapport avec PostgreSQL ?
- Un modèle commun pour stocker et rechercher efficacement des types de données a considérablement simplifié le développement d’applications, en permettant aux gens de stocker les données dans le même espace et de travailler avec les outils existants
- Nous avons vu cela avec JSON il y a 10 ans, et nous observons maintenant le même modèle avec les données vectorielles

Bref historique de JSON dans PostgreSQL

(Voir l’article original)

L’essor des vecteurs, un "nouveau type de JSON"

Leur popularité grimpe en flèche ces jours-ci
Le cas d’usage général consiste à construire un modèle à partir de données stockées, à les convertir au format vectoriel, puis à les utiliser pour la "recherche sémantique"
- Dans ce cas, une nouvelle entrée de recherche est convertie au format vectoriel, puis la base de données recherche ce qui s’en rapproche le plus
- La similarité s’appuie sur des fonctions de distance comme la distance euclidienne ou cosinus, et les résultats sont souvent limités au k-NN (Nearest Neighbors) ou aux k objets les plus similaires
- Comme l’encodage du jeu d’entraînement des vecteurs peut prendre beaucoup de temps, il est préférable de le mettre en cache dans un endroit comme une base de données et d’y exécuter les requêtes k-NN
- Le fait de disposer d’un ensemble de vecteurs prêts à être interrogés pour la recherche sémantique offre généralement une meilleure expérience utilisateur, d’où l’émergence du besoin d’une "base de données vectorielle"
Le stockage de vecteurs n’est pas nouveau pour PostgreSQL
- En fait, le terme est trompeur, car PostgreSQL peut stocker des données multidimensionnelles (par ex. des matrices)
- Par défaut, les tableaux de PostgreSQL incluent bien certaines fonctions limitées pour les vecteurs, comme le calcul de la "distance" entre deux tableaux
- Il est possible d’écrire des procédures stockées, mais cela demande un peu plus de travail aux développeurs
Heureusement, le type de données cube permet de dépasser ces limites
- cube est utilisé depuis plus de 20 ans et a été conçu pour effectuer des opérations sur des vecteurs de grande dimension
- cube inclut la plupart des fonctions de distance couramment utilisées dans la recherche de similarité vectorielle, y compris la distance euclidienne
- Il permet aussi d’exécuter efficacement des requêtes K-NN à l’aide d’index GiST
- Mais cube ne peut stocker que des vecteurs jusqu’à 100 dimensions, alors que les systèmes IA/ML modernes exigent des dimensions supérieures

pgvector : extension open source pour stocker et rechercher des vecteurs dans PostgreSQL

Avec pgvector, il est possible de stocker des vecteurs et d’exécuter des requêtes k-NN avec diverses métriques de distance (euclidienne, cosinus, produit scalaire, etc.)
Actuellement, pvector est fourni avec un seul index, ivfflat, qui implémente la méthode d’indexation vectorielle IVR FLAT
Interroger des données vectorielles indexées peut être différent de l’interrogation de données classiques
En raison du coût d’une recherche des plus proches voisins dans des vecteurs de grande dimension, de nombreuses méthodes d’indexation vectorielle cherchent une réponse "approximative" "suffisamment proche" de la bonne réponse
Cela mène au domaine de la recherche "ANN (Approximate Nearest Neighbor)"
Les deux dimensions que les gens examinent pour les requêtes ANN sont l’équilibre entre performance et "recall" (le pourcentage de résultats pertinents renvoyés)
- Si l’on prend ivfflat comme exemple, on décide lors de la création de l’index ivfflat combien de listes il doit contenir
- Chaque liste représente un "centre", calculé via l’algorithme k-means
- Une fois tous les centres déterminés, ivfflat décide de quel centre chaque vecteur est le plus proche, puis l’ajoute à l’index
- Au moment d’interroger les données vectorielles, la variable ivfflat.probes détermine combien de centres doivent être vérifiés
- C’est là qu’apparaît le compromis performance/recall de l’ANN. Plus on visite de centres, plus le résultat est précis, mais les performances baissent

Les prochaines étapes pour un meilleur support des vecteurs dans PostgreSQL

Comme à l’époque de PostgreSQL 9.2, qui a officiellement pris en charge le type JSON, nous en sommes aux premières étapes de la manière de stocker des données vectorielles dans PostgreSQL
PostgreSQL et pgvector sont déjà bons, mais ils vont encore beaucoup s’améliorer
pgvector peut déjà traiter les cas de données IA/ML courants. De nombreux utilisateurs l’ont déjà déployé en production
L’étape suivante consiste à aider à l’amélioration et à l’extension, et la plupart de ces travaux sont déjà en cours
- Ajouter davantage de parallélisation
- Prendre en charge les vecteurs de plus de 2 000 dimensions
- Exploiter l’accélération matérielle pour augmenter la vitesse de calcul
Il y a beaucoup d’attentes autour de l’usage de PostgreSQL comme "base de données" vectorielle
Comme l’histoire de JSON l’a montré, la communauté PostgreSQL trouvera un moyen de fournir ce support d’une manière extensible et sûre

7 commentaires

atempest 2025-05-07

La polyvalence est sans doute élevée, mais au final, la vraie question ne sera-t-elle pas celle de la vitesse ?
Comparé aux vector DB pures, j’ai l’impression que ce sera d’une lenteur difficile à ignorer…

nicewook 2023-06-28

Je me demande pourquoi il y a de l’enthousiasme autour de PostgreSQL alors qu’il existe déjà des bases de données vectorielles comme Pinecone. @@

tkwlsrl 2023-06-28

D’après mon expérience, PostgreSQL était le plus accessible.

Quand on utilisait des solutions comme Pinecone, ChromaDB ou Weaviate, rien n’était standardisé pour pouvoir utiliser chaque base de données.

Autrement dit, il fallait utiliser un SDK différent pour chaque base de données, et comme leur utilisation différait aussi, il fallait réécrire le code pour chaque base. En plus, les langages pris en charge par les SDK officiels étaient limités, au point qu’il fallait parfois changer de langage.

Bien sûr, utiliser des vecteurs dans PostgreSQL est un peu similaire, mais au moins il suffit d’ajouter un peu de connaissances aux requêtes SQL existantes, donc l’accès est plus simple.

À l’heure actuelle, si on compare la vitesse des bases de données vectorielles, PostgreSQL est plutôt assez lent. J’espère qu’il sera vite amélioré. haha

xguru 2023-06-28

« Installer et administrer une seule base de données qui prend tout en charge, c’est pratique » + « l’intégration avec les autres fonctionnalités est plus simple », non ?
Quand le nombre d’instances augmente, ça devient de plus en plus pénible..

nicewook 2023-06-28

Ah, d'accord, j'ai compris.
C'est aussi pour ça que Redis ajoute un peu de tout, je vois, je vois.

iolothebard 2023-06-28

L’histoire se termine toujours par… des tenseurs…