Des bases de données, il y en a de toutes les sortes de nos jours : des relationnelles bien entendu, des bases orientées documents, des bases graphe, des bases clé-valeur et même des bases blockchain, la liste est longue ! (sans parler des portées disparues : bases hiérarchiques, objets, XML, …). A priori de quoi satisfaire les plus exigeants …
Pourtant voilà qu’un nouveau type de bases de données commence à émerger, porté par des cas d’usage bien spécifiques : les bases vectorielles.
Pourquoi maintenant ?
Depuis l’irruption de ChatGPT auprès du grand public fin 2022 les résultats impressionnants des intelligences artificielles génératives de type LLM (Large Language Model) ont déclenché un engouement exceptionnel et complètement démocratisé l’utilisation de l’IA.
Au fur et à mesure de leur utilisation certaines faiblesses inhérentes aux LLM ont été mises en lumière, pouvant limiter leur adoption dans des domaines très techniques ou spécialisés
- Un LLM peut halluciner, inventer complètement une réponse
- Un LLM ne peut pas avoir connaissance de faits qui se sont produits après son apprentissage (exemple : un changement de norme, une nouvelle découverte scientifique, un renversement de jurisprudence, … )
Pour remédier à ces faiblesses il est possible d’apporter des compléments d’information au modèle afin d’améliorer la pertinence des résultats obtenus : RAG (Retrieval-Augmented Generation) est un processus d’optimisation qui permet de référencer une base de connaissances spécifique, distincte des sources de données de formation du modèle, avant de générer une réponse.
Ces données spécifiques étant stockées sous forme de vecteurs, les bases de données vectorielles permettent donc d’étendre les capacités des LLM à des domaines particuliers ou à la base de connaissances interne d’une organisation, le tout sans qu’il soit nécessaire de ré-entraîner le modèle.
source Axians Data Analytics
Pourquoi des bases vectorielles ?
source Axians Data Analytics
source Axians Data Analytics
Différentes mesures de similarité peuvent être utilisées : distance euclidienne, produit scalaire, cosinus, …
Une fois les vecteurs générés et stockés, lorsqu’un utilisateur soumet une requête (encodée elle-même sous forme de vecteur), l’objectif est d’identifier les « k » vecteurs les plus similaires à celui soumis. Afin d’accélérer les recherches de similarité une base vectorielle va utiliser des algorithmes de type « Approximate Nearest Neighbor » ou ANN, en utilisant des types d’indexes dédiés.
On distingue plusieurs stratégies de structuration des données :
- Fichier inversé (exemple : Inverted file Index – IVF)
- Structure en arbre (exemple : ANNOY)
- Structure en graphes (exemple Hierarchical Navigable Small World – HNSW ou Vamana)
Quelles bases vectorielles ?
Si certaines solutions de bases vectorielles étaient déjà présentes avant le « boom » des LLM, celui-ci les a mis en lumière et a permis l’émergence de nouveaux acteurs.
Parmi les acteurs spécialisés on va trouver par exemple : Pinecone, Milvus, Weaviate, Qdrant, Vespa ; ils se différencient par leurs stratégies d’hébergement (cloud / on premise), leurs modes de gestion (managé ou pas) ainsi que par leurs caractéristiques techniques (types d’indexs disponibles, nombre de dimensions maximum des vecteurs,…. )
Par ailleurs il n’a pas fallu longtemps pour que les éditeurs SGDB existants intègrent à leurs solutions des possibilités de stockage de vecteurs et de recherche de similarité. Ainsi ElasticSearch, MongoDB (Atlas), Cassandra, PostgreSQL (via pgvector), Oracle (à partir de la version 23), Redis, etc ont commencé à implémenter ces fonctionnalités, de manière plus ou moins complète et en intégrant le plus souvent des librairies open-source.
Et bien évidemment les principaux cloud providers ne sont pas en reste, ainsi AWS, Azure, Google.
La question subsidiaire
Est celle que tout le monde va poser : « Quelle base vectorielle utiliser ? »
Bien évidemment la réponse est : « ça dépend » 🙂
- des données à intégrer, des types de recherche et de la meilleure structure pour optimiser celles-ci
- de la dimension des vecteurs utilisés
- de la volonté ou la possibilité d’héberger vos données spécifiques sur le cloud public
- de votre capacité à intégrer, exploiter, monitorer de nouveaux moteurs de bases de données
- du besoin de coupler les recherches vectorielles avec des critères SQL classiques
- ….
Comme nous l’avons vu le choix est vaste, à vous de sélectionner la plus adaptée à votre contexte.
Pour cela n’hésitez pas à nous contacter si vous avez besoin d’informations complémentaires ou souhaitez de l’assistance pour votre projet !