À retenir
- Comme nous l’expliquons dans notre livre et notre cours, récupérer des documents ou du texte utile est nécessaire pour tous les produits fondés sur des LLMs.
- Vous devez fournir de l’information supplémentaire à votre LLM pour le rendre réellement utile.
- Vous devez comparer l’embedding de votre requête à toutes vos données.
ChatGPT est plutôt utile, mais vous ne pouvez pas en faire un produit.
Cela fait plusieurs vidéos que je parle du RAG, et ce n’est pas pour rien. Comme nous l’expliquons dans notre livre et notre cours, récupérer des documents ou du texte utile est nécessaire pour tous les produits fondés sur des LLMs.
Vous devez fournir de l’information supplémentaire à votre LLM pour le rendre réellement utile. Cela signifie qu’il doit être plus qu’un simple assistant Google. Il lui faut un contexte à jour et de l’information pertinente à transmettre à votre utilisateur. En gros, vous voulez votre propre LLM sans payer le coût de son entraînement. Voilà pourquoi le RAG existe.
Mais que se passe-t-il si votre base de données est immense ou s’il faut comparer une énorme quantité d’information? Comment pouvons-nous nous assurer que la partie « recherche » du pipeline ne nous ralentit pas?
Pour commencer, il faut savoir que la récupération d’information passe par un processus appelé l’indexation. Toute notre information est donc stockée dans une base de données, puis nous voulons l’« indexer » le plus efficacement possible en vue de recherches futures. Voyons comment y arriver.
D’abord, dans les bases de données ou les requêtes de recherche classiques, les données sont stockées sous forme de lignes, tandis que les colonnes fournissent davantage d’information sur le document, comme des métadonnées sur sa date, ses auteurs, etc. À partir de la requête d’un utilisateur, généralement une question, nous cherchions auparavant des correspondances exactes ou très semblables. Tout cela a changé avec la révolution des LLMs. Au lieu de trouver seulement des correspondances précises, nous utilisons une base de données vectorielle. Celle-ci contient essentiellement toute la base de données que nous avons transmise à notre LLM pour en obtenir sa propre compréhension, soit nos embeddings. Ces embeddings sont simplement d’immenses listes de nombres associées au sens général de chaque bloc de texte de notre base de données. Pour chaque nouvelle requête, nous pouvons ensuite la transmettre à notre système d’embeddings et utiliser cette liste de nombres pour la comparer manuellement à tous les embeddings ou vecteurs de notre base de données, puis récupérer les plus semblables. En bref, dans une base de données vectorielle, nous utilisons le contenu lui-même, soit la recherche sémantique, pour obtenir du contenu semblable.
Mais le problème de volume demeure. Que se passe-t-il si nous avons des millions et des millions de vecteurs? Comparons-nous encore chacun des vecteurs de notre base de données à celui de notre requête? Pas vraiment! C’est là qu’un bon index vectoriel devient nécessaire.
Alors, qu’est-ce qu’un index vectoriel exactement? Il s’agit d’une structure de données qui recherche et récupère un embedding vectoriel dans un vaste dataset d’objets. Elle doit être à la fois rapide et précise. Comme nous l’avons vu, un embedding correspond à la conversion d’un objet en une liste de nombres. Les embeddings semblables sont placés près les uns des autres dans l’espace vectoriel. Comment savoir si deux embeddings se ressemblent? Nous utilisons des métriques de distance comme la similarité cosinus, le produit scalaire ou la distance euclidienne pour mesurer la distance et rapprocher les plus semblables. Ce sont essentiellement différentes façons de comparer les nombres de grandes listes, ce qui nous donne une valeur pour mesurer leur similarité.
Il existe différentes méthodes pour créer des index vectoriels. Examinons en détail certaines des méthodes populaires. La plus simple est le Flat Index, ou index plat. Nous convertissons le texte en embedding vectoriel et le stockons tel quel. Nous lançons une requête pour le chercher et récupérer l’information la plus semblable. L’avantage est sa très grande précision. Son désavantage demeure toutefois la lenteur de la recherche. Vous devez comparer l’embedding de votre requête à toutes vos données.
Le type d’indexation suivant est le Locality Sensitive Hashing (LSH). Dans cette approche, les vecteurs sont regroupés dans des buckets selon leur similarité à l’aide de fonctions de hachage spécialisées et sensibles à la localité. Lorsqu’un vecteur de requête est présenté, il est haché avec les mêmes fonctions afin de trouver le bucket le plus semblable. Seuls les vecteurs de ce bucket sont ensuite parcourus pour trouver une correspondance. Imaginez une bibliothèque où tous les livres sont classés selon qu’il s’agit de fiction, puis par genre. Si vous cherchez un livre précis, vous devez seulement parcourir la catégorie de son genre au lieu de toute la bibliothèque. Vous pouvez ensuite la classer selon le nom de famille et tout trouver en quelques secondes! Cette méthode rassemble les éléments semblables et rend le processus de recherche efficace et précis.
Un autre type d’indexation porte le nom d’Inverted File Index. Il ressemble au LSH que nous venons de voir, mais utilise le clustering pour regrouper les vecteurs plutôt que le hachage pour créer des buckets. Nous choisissons un centroïde et calculons les clusters. Nous calculons donc tous les embeddings de notre dataset, puis les regroupons au moyen d’algorithmes automatiques qui les répartissent en groupes denses selon leurs ressemblances. Dans notre exemple de bibliothèque, tous les livres humoristiques pourraient se retrouver ensemble parce qu’ils font rire ou partagent d’autres caractéristiques semblables.
Cette méthode présente un problème lorsqu’une requête se trouve à la frontière de plusieurs clusters, puisque nous avons tendance à les parcourir tous. Une version améliorée porte le nom d’Inverted File Product Quantization (IVFPQ). Dans IVFPQ, chaque vecteur d’un cluster est subdivisé en sous-vecteurs plus petits, qui sont ensuite encodés en bits par un processus appelé Product Quantization. Celui-ci accélère énormément la comparaison. Nous comparons alors ces petits bits encodés plutôt que les embeddings originaux pour gagner en efficacité.
- Nous devons d’abord construire un graphe : vous partez d’un graphe vide qui ressemble à ceci. Lorsque vous ajoutez un document, vous commencez à la couche supérieure et naviguez vers le bas en vous connectant à des éléments semblables à chaque couche. Chaque nœud est relié à ses voisins les plus proches, ce qui crée une structure à plusieurs couches.
- Ensuite, vous cherchez : pour chercher un vecteur, vous commencez de nouveau à la couche supérieure. Vous trouvez le voisin le plus proche et descendez en suivant ses voisins les plus proches. Le processus se poursuit couche par couche jusqu’à la couche inférieure, où vous trouvez le très petit nombre de vecteurs les plus semblables.
Ce processus élimine la grande majorité des données en descendant progressivement d’une couche à l’autre parmi des vecteurs globalement semblables.
Nous savons maintenant à quoi ressemble un bon index. Récapitulons la façon dont toutes les pièces s’assemblent.
Le texte ou les données de votre base de données sont divisés en petites parties. Nous appelons ces parties de texte des nœuds. Il s’agit essentiellement de segments ou d’unités individuelles des données originales, soit des blocs de texte dans notre exemple simple. Ces nœuds sont ensuite convertis en embeddings, qui sont des représentations numériques du texte, puis stockés dans une base de données dotée d’un index vectoriel. Lorsque votre utilisateur pose une question, celle-ci devient notre requête et est convertie en embedding vectoriel. Grâce à la méthode d’indexation, la base de données cherche et retourne les meilleurs résultats correspondant à la requête.
Il s’agit d’une configuration de base, et vous pouvez l’améliorer de nombreuses façons. Une première amélioration rapide serait d’utiliser des techniques de prompting pour ajouter du contexte à la question de l’utilisateur et aider votre système de recherche à trouver l’information la plus pertinente possible. Certaines questions peuvent manquer de détails et demeurer très générales, ce qui produit des embeddings déconnectés de ce que vous cherchez.
Vous pouvez aussi implémenter d’autres méthodes de recherche fondées sur des mots-clés ou une recherche hybride afin d’améliorer encore le système et d’aider votre système d’indexation à récupérer l’information souhaitée. Vous pouvez également explorer de nouvelles méthodes d’indexation comme le Multi-Scale Tree Graph (MSTG). Nous couvrons tout cela en profondeur dans les leçons du cours et notre livre, dont les liens se trouvent ci-dessous si vous regardez cette vidéo sur YouTube.
Dans tous les cas, l’utilisation d’index vectoriels dans les systèmes RAG rend la recherche d’information pertinente rapide, précise et facile à mettre à l’échelle. En convertissant le texte en embeddings vectoriels et en les stockant dans une base de données structurée autour d’un index vectoriel, le système peut trouver rapidement et efficacement du contenu sémantiquement semblable. En bref, les méthodes d’indexation avancées comme HNSW, LSH, Product Quantization ou MSTG réduisent l’espace de recherche et assurent la grande pertinence de l’information récupérée.
Tout cela peut être réalisé avec d’excellentes plateformes de bases de données vectorielles comme ChromaDB ou Pinecone, en utilisant LlamaIndex, comme nous le voyons dans le cours.
J’espère que vous comprenez un peu mieux ce qui se passe en arrière-plan pendant l’indexation et pourquoi il est important d’en mettre une en place.
FAQ
Pourquoi la recherche vectorielle a-t-elle besoin d’un index?
Comparer une requête à chaque vecteur stocké devient trop lent et coûteux à mesure que la collection grandit.
Qu’est-ce que la recherche exacte des plus proches voisins?
Elle compare la requête à tous les vecteurs et retourne les plus proches, ce qui maximise le rappel au prix d’un coût de calcul élevé.
Quel compromis fait la recherche approximative des plus proches voisins?
Elle sacrifie une petite part de rappel afin de récupérer beaucoup plus rapidement les vecteurs pertinents à grande échelle.
Comment les équipes devraient-elles choisir une méthode d’indexation?
Mesurez le rappel, la latence, la mémoire, la fréquence des mises à jour, les filtres et la taille de la collection sur des requêtes représentatives.
Un meilleur index vectoriel peut-il corriger de mauvais documents RAG?
Non. La vitesse de l’index ne peut pas compenser un mauvais découpage, du contenu manquant ou des embeddings qui ne représentent pas la pertinence.