Bases vectorielles et relationnelles : l'alliance IA essentielle

Au-delà du magasin de vecteurs : Construire la couche de données complète pour les applications d'IA

Dans le développement des applications d'intelligence artificielle (IA), il est crucial de comprendre pourquoi une base de données vectorielle ne suffit pas à elle seule. En effet, pour les applications en production, il est nécessaire de combiner une base de données vectorielle pour la récupération sémantique avec une base de données relationnelle pour les charges de travail structurées et transactionnelles.

Bases de données vectorielles : Ce qu'elles font bien et où elles échouent

Les bases de données vectorielles sont au cœur de l'étape de récupération dans le modèle de génération augmentée par récupération (RAG). Ce modèle permet d'offrir un contexte spécifique et propriétaire à un modèle de langage, ce qui réduit les hallucinations. Lorsqu'un utilisateur interroge un agent IA, l'application transforme cette requête en un vecteur de haute dimension pour rechercher le contenu le plus sémantiquement similaire dans un corpus donné.

Avantages clés :

Les bases de données vectorielles excellent dans la récupération basée sur le sens. Par exemple, un agent IA juridique peut répondre à des questions sur les "droits des locataires concernant la moisissure et les conditions de vie dangereuses". Une recherche vectorielle peut identifier des passages pertinents même si les documents n'utilisent jamais l'expression "conditions de vie dangereuses". De plus, elles gèrent efficacement les fautes de frappe, la paraphrase et le contexte implicite, ce qui les rend idéales pour traiter des données non structurées.

Limitations :

Cependant, ces bases de données présentent des limitations notables. Elles ne garantissent pas l'exactitude pour des recherches structurées. Par exemple, pour récupérer tous les tickets de support créés par l'ID utilisateur user_4242 entre le 1er et le 31 janvier, une recherche de similarité vectorielle n'est pas appropriée. De plus, des opérations comme le comptage des sessions utilisateur actives ou la somme de l'utilisation des jetons API sont triviales en SQL mais inefficaces avec des embeddings vectoriels seuls. Enfin, pour des écritures transactionnelles contre des données structurées, comme les mises à jour conditionnelles d'un champ de profil utilisateur ou l'enregistrement d'une conversation archivée, les bases de données vectorielles ne sont pas optimisées.

Bases de données relationnelles : L'épine dorsale opérationnelle

Les bases de données relationnelles sont responsables de chaque "fait concret" dans un système IA. Elles gèrent plusieurs domaines critiques :

• Identité utilisateur et contrôle d'accès : L'authentification, les permissions basées sur les rôles (RBAC) et les frontières multi-locataires doivent être appliquées avec une précision absolue.
• Métadonnées pour vos embeddings : Si votre base de données vectorielle stocke la représentation sémantique d'un document PDF, vous devez également stocker l'URL d'origine, l'ID de l'auteur, l'horodatage de téléchargement, le hachage du fichier et les restrictions d'accès.
• Pré-filtrage du contexte pour réduire les hallucinations : Pour générer un résumé de "tous les tickets de haute priorité résolus au cours des 7 derniers jours pour l'équipe frontend", le système doit d'abord utiliser un filtrage SQL précis.
• Facturation, journaux d'audit et conformité : Tout déploiement d'entreprise nécessite un enregistrement transactionnel cohérent de ce qui s'est passé, quand et qui l'a autorisé.

Ce qui se casse sans la couche relationnelle

La limitation des bases de données relationnelles à l'ère de l'IA est simple : elles n'ont pas de compréhension native du sens sémantique. Rechercher des passages conceptuellement similaires à travers des millions de lignes de texte brut avec SQL est coûteux en calcul et produit de mauvais résultats. C'est précisément le vide que comblent les bases de données vectorielles.

L'architecture hybride : Mettre tout ensemble

Les applications IA les plus efficaces considèrent ces deux types de bases de données comme des couches complémentaires au sein d'un même système. La base de données vectorielle gère la récupération sémantique, tandis que la base de données relationnelle gère tout le reste. Et surtout, elles communiquent entre elles.

Le modèle de pré-filtrage

Le modèle hybride le plus courant consiste à utiliser SQL pour définir l'espace de recherche avant d'exécuter une requête vectorielle. Voici un exemple concret :

• Interroger la base de données relationnelle pour récupérer l'ID du locataire pour l'entreprise A, confirmer que le rôle de l'utilisateur a la permission d'accéder aux documents de politique, et obtenir les IDs des documents de politique actifs appartenant à ce locataire.
• Interroger la base de données vectorielle avec la question de l'utilisateur, mais en limitant la recherche uniquement aux IDs de documents retournés par l'étape précédente.
• Passer les passages récupérés au LLM avec la question de l'utilisateur.

Sans la première étape, la recherche vectorielle pourrait retourner des passages pertinents sémantiquement provenant des documents de l'entreprise B ou de documents de l'entreprise A auxquels ils n'ont pas accès, entraînant une fuite de données.

Le modèle d'enrichissement post-récupération

Le modèle inverse est également courant. Après qu'une recherche vectorielle ait retourné des morceaux sémantiquement pertinents, l'application interroge la base de données relationnelle pour enrichir ces résultats avec des métadonnées structurées.

Par exemple, un agent de base de connaissances interne pourrait récupérer les trois passages de documents les plus pertinents via une recherche vectorielle, puis les joindre à une table relationnelle pour attacher le nom de l'auteur, l'horodatage de la dernière mise à jour et le taux de confiance du document.

Stockage unifié avec pgvector

Pour de nombreuses équipes, faire fonctionner deux systèmes de bases de données distincts introduit une complexité opérationnelle difficile à justifier, surtout à une échelle modérée. C'est là que pgvector, l'extension de similarité vectorielle pour PostgreSQL, devient une option convaincante.

Avec pgvector, vous stockez les embeddings comme une colonne directement à côté de vos données relationnelles structurées. Une seule requête peut combiner des filtres SQL exacts, des jointures et une recherche de similarité vectorielle en une seule opération.