Pourquoi avons-nous fini par stocker des vecteurs 2D pour la recherche vectorielle ?

Problème

• Pour la recherche sémantique/en langage naturel et le RAG, il faut effectuer des embeddings vectoriels
• La plupart des modèles d’embedding ont une limite de longueur en entrée
  • Ajuster convenablement la longueur d’entrée est lié à la qualité de la recherche
  • À cause de cette limite, on stocke le plus souvent les paragraphes après les avoir découpés
• En stockant le texte source après l’avoir découpé, un document unique se retrouve fragmenté en plusieurs documents
  • La plupart des documents ne sont pas composés d’une seule donnée textuelle, mais aussi de métadonnées et d’autres champs longs
  • Pour stocker les données découpées, il faut soit dupliquer le texte source fragmenté et les informations annexes, soit les stocker dans des collections (ou tables) séparées
    • La duplication entraîne une hausse de l’espace de stockage et donc une inefficacité, tandis que des collections séparées augmentent la complexité lors de la recherche avec des jointures, le calcul des scores, le comptage des documents, etc.
  • C’est un problème fréquent lorsqu’on utilise la plupart des vector stores

Solution

• Nous avons cherché une autre méthode qui ne découpe pas le texte source
• Nous avons modifié la base de données et les bibliothèques associées afin que le champ où sont stockées les données d’embedding puisse recevoir des données en 2 dimensions
  • Cela permet de stocker, sans découper le texte source, des données vectorielles de longueur variable par document, même lorsqu’il est subdivisé en une ou plusieurs parties
  • Avec cette méthode, le texte source et les données vectorielles séparées peuvent coexister sans séparer les collections, ce qui simplifie la gestion des données et les requêtes