Base de données vectorielle avec Chroma DB et RAG

Comment récupérer du contexte à l’aide de RAG & Chroma DB ?

Pour être précis, nous parlons de génération augmentée par récupération (RAG) basée sur Vector DB. La semaine dernière, nous avons exploré comment transformer les données brutes en formats structurés et organisés alignés sur des « besoins de récupération » spécifiques.

Pourquoi utiliser une base de données vectorielle ?

Tout d’abord, c’est plus rapide. Par exemple, dans les requêtes de recherche de similarité, une base de données vectorielle bien optimisée peut être jusqu’à trois fois plus rapide qu’une requête Cypher dans #Neo4j bases de données de graphes. Plus la requête est complexe, plus la différence de performances est importante.

Plus important encore, lorsqu’il s’agit d’applications à grande échelle et d’une récupération contextuelle approfondie, les bases de données vectorielles sont la solution la plus efficace. Ils sont conçus pour les recherches de similarité de grande dimension, ce qui les rend idéaux pour les scénarios où le contexte implique des relations sémantiques complexes.

Vous pouvez obtenir des résultats similaires avec des bases de données de graphes utilisant des algorithmes tels que GraphSAGE ou Node2Vec, mais le défi consiste à relier votre LLM à votre système de mémoire. La clé consiste à utiliser les intégrations générées par le LLM lui-même, en veillant à ce que les mêmes « vecteurs » soient produits pour des « jetons » identiques dans les deux environnements. Cet alignement est essentiel pour maintenir la cohérence et la pertinence lors de la récupération.

Pour info technique : L’écart se produit parce que le LLM a ses propres paramètres et poids, qui lui servent de mémoire, stockés sous forme de vecteurs. Si les vecteurs de votre base de données de vecteurs ne s’alignent pas sur ceux de LLM, le processus de récupération ne fonctionnera pas car les vecteurs ne représenteront pas le même espace sémantique sous-jacent.

Ainsi, une fois que vous utilisez les plongements de votre LLM, vous pouvez indexer les propriétés du nœud, son étiquette et les relations. Pour cela, nous utilisons les algorithmes FAISS, en bref :

– Flat (force brute)
Avantage : Garantit les résultats les plus précis en comparant tous les points de données.
Inconvénient : Lent pour les grands ensembles de données en raison de la recherche exhaustive.

– FIV (index des fichiers inversés)
Avantage : recherche plus rapide grâce au partitionnement des données en clusters.
Inconvénient : Moins précis que la force brute car il saute certains points.

– HNSW (Archiarchical Navigable Small World)
Avantage : Recherche extrêmement rapide avec une grande précision sur de grands ensembles de données.
Inconvénient : nécessite une mémoire importante pour maintenir la structure du graphique.

– LSH (hachage sensible à la localité)
Avantage : efficace pour les données de grande dimension en hachant des points similaires dans le même compartiment.
Inconvénient : Précision inférieure par rapport aux autres méthodes, en particulier pour les similitudes à grain fin.

Après avoir exécuté plus d’un millier de tests, la règle d’or actuelle est la suivante : ne pas indexer pour une récupération facile ; index pour les extractions complexes ou les bases de données volumineuses.

Dans notre environnement, nous utilisons Chroma DB car il est compatible avec toutes les technologies que nous utilisons, telles que FAISS, NumPy, scikit-learn, LangChain et LlamaIndex. D’autres bases de données vectorielles, comme Pinecone ou Weaviate, ne sont que des solutions cloud.