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

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

Dans cet article, vous découvrirez pourquoi les applications d'IA en production nécessitent à la fois une base de données vectorielle pour la récupération sémantique et une base de données relationnelle pour les charges de travail structurées et transactionnelles.

Sujets abordés :

• Ce que les bases de données vectorielles font bien et où elles échouent dans les systèmes d'IA en production.
• Pourquoi les bases de données relationnelles restent essentielles pour les permissions, les métadonnées, la facturation et l'état de l'application.
• Comment les architectures hybrides, y compris l'utilisation de pgvector, combinent les deux approches en une couche de données pratique.

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

Les bases de données vectorielles alimentent l'étape de récupération dans la génération augmentée par récupération (RAG), un modèle qui permet de fournir un contexte spécifique et propriétaire à un modèle de langage pour réduire les hallucinations. Lorsqu'un utilisateur interroge votre agent IA, l'application intègre cette requête dans un vecteur de haute dimension et recherche le contenu le plus sémantiquement similaire dans votre corpus.

Avantages clés :

• 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 faire ressortir des passages pertinents même si ces documents n'utilisent jamais l'expression « conditions de vie dangereuses ».

• Gestion des erreurs : Les bases de données vectorielles gèrent les fautes de frappe, la paraphrase et le contexte implicite, ce qui les rend idéales pour rechercher des données non structurées.

Limitations :

• Imprécision des recherches structurées : Les bases de données vectorielles ne peuvent garantir 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.

• Agrégation impraticable : 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.

• Gestion de l'état : Les mises à jour conditionnelles d'un champ de profil utilisateur ou l'enregistrement d'une conversation archivée sont des écritures transactionnelles contre des données structurées. Les bases de données vectorielles ne sont pas optimisées pour cela.

Si votre application IA fait plus que répondre à des questions sur un corpus de documents statiques, vous avez besoin d'une base de données relationnelle pour gérer ces responsabilités.

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

La base de données relationnelle gère chaque « fait concret » dans votre système IA. Cela signifie qu'elle est responsable de 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.