Machine Learning Mastery : pourquoi un vector store ne suffit pas pour les applications d'IA

Machine Learning Mastery a analysé une erreur courante en architecture d'applications d'IA : traiter un vector store comme une base de données complète pour l'ensemble du produit. Au stade de la démo, cela suffit souvent, mais en production, aux côtés de la recherche vectorielle, vous avez presque toujours besoin d'une couche relationnelle classique.

Où le vector store excelle

Les bases de données vectorielles sont devenues un composant standard des systèmes RAG car elles résolvent un problème que SQL ordinaire gère mal : rechercher par sens, et non par correspondance exacte de mots. Lorsqu'un utilisateur pose une question, le système la convertit en embedding et recherche les fragments de document les plus proches sémantiquement. Cela permet à l'IA de trouver des textes pertinents même lorsqu'ils ne contiennent pas la même formulation que la requête.

Ceci est particulièrement utile avec des données non structurées — documents internes, correspondance, PDF et bases de connaissances. Si quelqu'un demande des droits du locataire en cas de moisissure dans un appartement, la recherche vectorielle trouvera des sections sur les normes de logement ou les obligations du propriétaire, même si la phrase « conditions de vie dangereuses » n'apparaît pas dans le document. Cette approche gère mieux les fautes de frappe, les reformulations et le contexte implicite.

C'est pourquoi le vector store est devenu le composant de base de la recherche d'IA où les formulations ne correspondent presque jamais mot pour mot.

Où SQL est nécessaire

Le problème est que la flexibilité de la recherche vectorielle en fait simultanément un outil imprécis pour les tâches opérationnelles. Elle répond bien à « qu'est-ce qui est sémantiquement similaire », mais ne fonctionne pas où vous avez besoin d'une réponse stricte sans probabilités et tolérances. Une fois que les utilisateurs, les limites, les paiements et les états d'objets apparaissent dans un produit, la recherche approximative commence à entraver plutôt qu'à aider. C'est pourquoi dans un système de production, une base de données relationnelle reste l'endroit où vivent tous les « faits solides » :

• droits d'accès et limites de tenant, où une erreur devient une fuite de données ;
• métadonnées de documents — auteur, URL, date de téléchargement, hash de fichier, état de publication ;
• facturation, audit, logs et tout enregistrement qui doit être cohérent ;
• état de l'application : si un chat est archivé, si un flag est activé, quel plan l'utilisateur a.

Il y a aussi un autre aspect pratique : le filtrage SQL précis réduit les hallucinations du modèle. Si l'IA doit résumer uniquement les tickets de haute priorité fermés au cours des 7 derniers jours par l'équipe frontend, vous devez d'abord sélectionner strictement exactement ces enregistrements, et seulement ensuite passer leur texte au modèle. C'est moins cher, plus rapide et plus sûr que d'espérer que la recherche vectorielle seule retournera aléatoirement l'ensemble de données parfaitement limité. Essentiellement, SQL ici ne concurrence pas le LLM, mais prépare la zone de travail correcte pour celui-ci.

Schéma hybride

L'auteur propose de ne pas choisir entre les deux approches, mais de les combiner en une seule couche de données. Un scénario typique ressemble à ceci : d'abord, la base de données relationnelle vérifie l'utilisateur, son rôle et la liste des documents auxquels il a accès, et seulement ensuite le vector store recherche les correspondances sémantiques dans ce sous-ensemble sécurisé. Pour les assistants d'IA d'entreprise, ce n'est pas une optimisation, mais une limite de sécurité.

Sans tel filtrage préalable, le système risque de montrer aux utilisateurs des données d'une autre équipe ou même d'un autre client. Le motif inverse fonctionne aussi. Après que la recherche vectorielle retourne des fragments pertinents, l'application peut extraire les métadonnées de SQL : qui a autorisé le document, quand il a été mis à jour, quel statut de confiance il a.

Alors le modèle répond non pas abstraitement, mais avec contexte — par exemple, lié à la fraîcheur du document ou au département qui l'a émis. Pour les bases de connaissances internes et les agents de support, ceci augmente notablement la confiance dans la réponse et aide les utilisateurs à en vérifier rapidement l'origine.

Pour les équipes qui ne veulent pas maintenir deux bases de données différentes, Machine Learning Mastery met particulièrement en avant pgvector — une extension PostgreSQL pour la recherche par similarité. Dans cette variante, les embeddings vivent aux côtés des champs structurés, et une seule requête peut vérifier simultanément les permissions, filtrer les enregistrements par date et statut, puis les classer par proximité sémantique. Le compromis est simple : à l'échelle modérée, ceci simplifie notablement l'infrastructure, mais à des volumes de milliards de vecteurs, les systèmes spécialisés comme Pinecone ou Milvus sont encore plus rapides. Cependant, pour des centaines de milliers ou quelques millions de vecteurs, cette approche s'avère souvent être le point de départ le plus pragmatique.

Ce que cela signifie

La conclusion principale est simple : vector store est une partie importante de la pile d'IA, mais pas un remplacement complet de celle-ci. Si votre produit travaille avec des utilisateurs, des contrôles d'accès, des paiements et l'état du système, vous ne pouvez pas vous passer d'une base de données relationnelle. Pour la plupart des équipes, un bon début est PostgreSQL avec pgvector ou une combinaison de SQL plus une base de données vectorielle séparée, où chaque technologie gère uniquement la classe de tâches qu'elle résout le mieux. Plus tôt cette séparation apparaît dans l'architecture, moins il y a de chances que la version démo s'effondre lors de la première réelle croissance.