Choisir la bonne base de données pour votre cas d’utilisation de l’IA générative

Façons de fournir des données à un modèle

De nombreuses organisations explorent désormais la puissance de l’IA générative pour améliorer leur efficacité et acquérir de nouvelles capacités. Dans la plupart des cas, pour libérer pleinement ces pouvoirs, l’IA doit avoir accès aux données pertinentes de l’entreprise. Les grands modèles linguistiques (LLM) sont formés sur des données accessibles au public (par exemple, des articles Wikipédia, des livres, un index Web, etc.), ce qui est suffisant pour de nombreuses applications à usage général, mais il en existe de nombreuses autres qui dépendent fortement de données privées. en particulier dans les environnements d’entreprise.

Il existe trois manières principales de fournir de nouvelles données à un modèle :

1. Pré-entraîner un modèle à partir de zéro. Cela a rarement du sens pour la plupart des entreprises, car cela coûte très cher et nécessite beaucoup de ressources et d’expertise technique.
2. Affiner un LLM à usage général existant. Cela peut réduire les besoins en ressources par rapport à la pré-formation, mais nécessite néanmoins des ressources et une expertise importantes. Le réglage fin produit des modèles spécialisés qui offrent de meilleures performances dans un domaine pour lequel il est optimisé, mais qui peuvent avoir de moins bonnes performances dans d’autres.
3. Génération augmentée de récupération (RAG). L’idée est de récupérer les données pertinentes pour une requête et de les inclure dans le contexte LLM afin qu’il puisse « ancrer » ses propres résultats dans ces informations. Ces données pertinentes dans ce contexte sont appelées « données de base ». RAG complète les modèles LLM génériques, mais la quantité d’informations pouvant être fournies est limitée par la taille de la fenêtre contextuelle du LLM (quantité de texte que le LLM peut traiter simultanément, lorsque les informations sont générées).

Actuellement, RAG est le moyen le plus accessible de fournir de nouvelles informations à un LLM, alors concentrons-nous sur cette méthode et approfondissons un peu.

Génération augmentée de récupération

En général, RAG signifie utiliser un moteur de recherche ou de récupération pour récupérer un ensemble de documents pertinent pour une requête spécifiée.

Pour cela, nous pouvons utiliser de nombreux systèmes existants : un moteur de recherche en texte intégral (comme Elasticsearch + techniques traditionnelles de recherche d’informations), une base de données à usage général avec une extension de recherche vectorielle (Postgres avec pgvector, Elasticsearch avec plugin de recherche vectorielle), ou une base de données spécialisée créée spécifiquement pour la recherche de vecteurs.

Dans deux derniers cas, RAG est similaire à la recherche sémantique. Pendant longtemps, la recherche sémantique a été un domaine hautement spécialisé et complexe avec des langages de requête exotiques et des bases de données de niche. L’indexation des données a nécessité une préparation approfondie et la création de graphiques de connaissances, mais les progrès récents en matière d’apprentissage profond ont radicalement changé le paysage. Les applications de recherche sémantique modernes dépendent désormais de l’intégration de modèles capables d’apprendre avec succès les modèles sémantiques dans les données présentées. Ces modèles prennent des données non structurées (texte, audio ou même vidéo) en entrée et les transforment en vecteurs de nombres d’une longueur fixe, transformant ainsi les données non structurées en une forme numérique pouvant être utilisée pour des calculs. Il devient alors possible de calculer la distance. entre les vecteurs en utilisant une métrique de distance choisie, et la distance résultante reflétera la similarité sémantique entre les vecteurs et, à son tour, entre les éléments de données originales.

Ces vecteurs sont indexés par une base de données de vecteurs et, lors de l’interrogation, notre requête est également transformée en vecteur. La base de données recherche les N vecteurs les plus proches (selon une métrique de distance choisie comme la similarité cosinus) d’un vecteur de requête et les renvoie.

Une base de données vectorielles est responsable de ces 3 choses :

1. Indexage. La base de données crée un index de vecteurs à l’aide d’un algorithme intégré (par exemple, le hachage sensible à la localité (LSH) ou le petit monde navigable hiérarchique (HNSW)) pour précalculer les données afin d’accélérer les requêtes.
2. Interrogation. La base de données utilise un vecteur de requête et un index pour trouver les vecteurs les plus pertinents dans une base de données.
3. Post-traitement. Une fois l’ensemble de résultats formé, nous pouvons parfois souhaiter exécuter une étape supplémentaire telle que le filtrage des métadonnées ou le reclassement dans l’ensemble de résultats pour améliorer le résultat.

Le but d’une base de données vectorielle est de fournir un moyen rapide, fiable et efficace de stocker et d’interroger des données. La vitesse de récupération et la qualité de la recherche peuvent être influencées par la sélection du type d’index. En plus des LSH et HNSW déjà mentionnés, il en existe d’autres, chacun avec ses propres forces et faiblesses. La plupart des bases de données font le choix à notre place, mais dans certaines, vous pouvez choisir un type d’index manuellement pour contrôler le compromis entre vitesse et précision.

Chez Simseo, nous pensons que la technique est là pour rester. Le réglage fin peut nécessiter une préparation de données très sophistiquée pour transformer un texte brut en données prêtes à être entraînées, et c’est plus un art qu’une science d’amener les LLM à « apprendre » de nouveaux faits grâce à un réglage fin tout en maintenant leurs connaissances générales et le respect des instructions. comportement.

Les LLM sont généralement très efficaces pour appliquer les connaissances fournies dans leur contexte, en particulier lorsque seul le matériel le plus pertinent est fourni. Un bon système de récupération est donc crucial.

A noter que le choix du modèle d’intégration utilisé pour RAG est essentiel. Il ne fait pas partie de la base de données et le choix du modèle d’intégration approprié pour votre application est essentiel pour obtenir de bonnes performances. De plus, alors que de nouveaux modèles améliorés sont constamment publiés, le passage à un nouveau modèle nécessite de réindexer l’intégralité de votre base de données.

Évaluer vos options

Choisir une base de données dans un environnement d’entreprise n’est pas une tâche facile. Une base de données est souvent le cœur de votre infrastructure logicielle qui gère un actif commercial très important : les données.

Généralement, lorsque nous choisissons une base de données, nous voulons :

• Stockage fiable
• Interrogation efficace
• Possibilité d’insérer, de mettre à jour et de supprimer des données de manière granulaire (CRUD)
• Configurer plusieurs utilisateurs avec différents niveaux d’accès pour eux (RBAC)
• Cohérence des données (comportement prévisible lors de la modification des données)
• Capacité à se remettre des échecs
• Évolutivité à la taille de nos données

Cette liste n’est pas exhaustive et peut paraître un peu évidente, mais toutes les nouvelles bases de données vectorielles ne disposent pas de ces fonctionnalités. Souvent, c’est la disponibilité des fonctionnalités d’entreprise qui détermine le choix final entre une base de données mature bien connue qui fournit une recherche vectorielle via des extensions et une base de données plus récente uniquement vectorielle.

Les bases de données vectorielles uniquement prennent en charge nativement la recherche vectorielle et peuvent exécuter des requêtes très rapidement, mais manquent souvent de fonctionnalités d’entreprise et sont relativement immatures. Gardez à l’esprit qu’il faut des années pour créer des fonctionnalités complexes et les tester. Il n’est donc pas surprenant que les premiers utilisateurs soient confrontés à des pannes et à des pertes de données. D’un autre côté, dans les bases de données existantes qui proposent une recherche vectorielle via des extensions, un vecteur n’est pas un citoyen de première classe et les performances des requêtes peuvent être bien pires.

Nous classerons toutes les bases de données actuelles proposant une recherche vectorielle dans les groupes suivants, puis en discuterons plus en détail :

• Bibliothèques de recherche de vecteurs
• Bases de données vectorielles uniquement
• Bases de données NoSQL avec recherche vectorielle
• Bases de données SQL avec recherche vectorielle
• Solutions de recherche de vecteurs de fournisseurs cloud

Bibliothèques de recherche de vecteurs

Les bibliothèques de recherche de vecteurs comme FAISS et ANNOY ne sont pas des bases de données. Elles fournissent plutôt des indices vectoriels en mémoire et uniquement des options limitées de persistance des données. Bien que ces fonctionnalités ne soient pas idéales pour les utilisateurs nécessitant une base de données d’entreprise complète, elles permettent une recherche très rapide du voisin le plus proche et sont open source. Ils offrent une bonne prise en charge des données de grande dimension et sont hautement configurables (vous pouvez choisir le type d’index et d’autres paramètres).

Dans l’ensemble, ils conviennent au prototypage et à l’intégration dans des applications simples, mais ils ne conviennent pas au stockage de données multi-utilisateurs à long terme.

Bases de données vectorielles uniquement

Ce groupe comprend divers produits comme Milvus, Chroma, Pinecone, Weaviate et autres. Il existe des différences notables entre eux, mais tous sont spécifiquement conçus pour stocker et récupérer des vecteurs. Ils sont optimisés pour une recherche de similarité efficace avec indexation et prennent en charge de manière native les données de grande dimension et les opérations vectorielles.

La plupart d’entre eux sont plus récents et peuvent ne pas avoir les fonctionnalités d’entreprise mentionnées ci-dessus, par exemple certains d’entre eux n’ont pas de CRUD, pas de récupération après panne prouvée, RBAC, etc. Pour la plupart, ils peuvent stocker les données brutes, le vecteur d’intégration et une petite quantité de métadonnées, mais ils ne peuvent pas stocker d’autres types d’index ou de données relationnelles, ce qui signifie que vous devrez utiliser une autre base de données secondaire et maintenir la cohérence. entre eux.

Leurs performances sont souvent inégalées et ils constituent une bonne option lorsqu’il s’agit de données multimodales (images, audio ou vidéo).

Bases de données NoSQL avec recherche vectorielle

De nombreuses bases de données dites NoSQL ont récemment ajouté la recherche vectorielle à leurs produits, notamment MongoDB, Redis, neo4j et ElasticSearch. Ils offrent de bonnes fonctionnalités d’entreprise, sont matures et disposent d’une communauté solide, mais ils fournissent des fonctionnalités de recherche vectorielle via des extensions qui peuvent conduire à des performances loin d’être idéales et à un manque de prise en charge de première classe pour la recherche vectorielle. Elasticsearch se démarque ici car il est conçu pour la recherche en texte intégral et dispose déjà de nombreuses fonctionnalités traditionnelles de récupération d’informations qui peuvent être utilisées conjointement avec la recherche vectorielle.

Les bases de données NoSQL avec recherche vectorielle sont un bon choix lorsque vous y êtes déjà investi et que vous avez besoin de la recherche vectorielle comme fonctionnalité supplémentaire, mais peu exigeante.

Bases de données SQL avec recherche vectorielle

Ce groupe est quelque peu similaire au groupe précédent, mais nous avons ici des acteurs établis comme PostgreSQL et ClickHouse. Ils offrent un large éventail de fonctionnalités d’entreprise, sont bien documentés et disposent de communautés solides. Quant à leurs inconvénients, ils sont conçus pour des données structurées et leur mise à l’échelle nécessite une expertise spécifique.

Leur cas d’utilisation est également similaire : un bon choix lorsque vous les possédez déjà et l’expertise nécessaire pour les mettre en place.

Solutions de recherche de vecteurs de fournisseurs cloud

Les hyperscalers proposent également des services de recherche de vecteurs. Ils ont généralement des fonctionnalités de base pour la recherche vectorielle (vous pouvez choisir un modèle d’intégration, un type d’index et d’autres paramètres), une bonne interopérabilité avec le reste de la plate-forme cloud et plus de flexibilité en termes de coût, surtout si vous utilisez d’autres services sur leur plateforme. Cependant, ils ont une maturité différente et des ensembles de fonctionnalités différents : la recherche vectorielle Google Cloud utilise un algorithme de recherche d’index propriétaire rapide appelé ScaNN et un filtrage de métadonnées, mais n’est pas très conviviale ; La recherche Azure Vector offre des fonctionnalités de recherche structurées, mais est en phase de préversion, etc.

Les entités de recherche vectorielle peuvent être gérées à l’aide des fonctionnalités d’entreprise de leur plate-forme telles que IAM (Identity and Access Management), mais elles ne sont pas si simples à utiliser et adaptées à une utilisation générale du cloud.

Faire le bon choix

Le principal cas d’utilisation des bases de données vectorielles dans ce contexte est de fournir des informations pertinentes à un modèle. Pour votre prochain projet LLM, vous pouvez choisir une base de données parmi une gamme existante de bases de données offrant des capacités de recherche de vecteurs via des extensions ou parmi de nouvelles bases de données uniquement vectorielles offrant une prise en charge native des vecteurs et des requêtes rapides.

Le choix dépend si vous avez besoin de fonctionnalités d’entreprise ou de performances à grande échelle, ainsi que de votre architecture de déploiement et de la maturité souhaitée (recherche, prototypage ou production). Il convient également de considérer quelles bases de données sont déjà présentes dans votre infrastructure et si vous disposez de données multimodales. Dans tous les cas, quel que soit le choix que vous ferez, il est bon de le protéger : traitez une nouvelle base de données comme un cache de stockage auxiliaire, plutôt que comme un point central d’opérations, et résumez les opérations de votre base de données dans le code pour faciliter l’ajustement au suivant. itération du paysage vectoriel RAG.

Comment Simseo peut vous aider

Il existe déjà de nombreuses options de bases de données vectorielles parmi lesquelles choisir. Ils ont chacun leurs avantages et leurs inconvénients : aucune base de données vectorielles ne conviendra à tous les cas d’utilisation de l’IA générative de votre organisation. C’est pourquoi il est important de conserver le caractère facultatif et d’exploiter une solution qui vous permet de personnaliser vos solutions d’IA générative en fonction de cas d’utilisation spécifiques et de les adapter à mesure que vos besoins changent ou que le marché évolue.

La plateforme Simseo AI vous permet d’apporter votre propre base de données vectorielles, selon celle qui convient à la solution que vous créez. Si vous avez besoin de modifications à l’avenir, vous pouvez échanger votre base de données vectorielles sans interrompre votre environnement de production et vos flux de travail.