Machine Learning Mastery : pourquoi une base vectorielle ne suffit pas aux applications d'IA

Machine Learning Mastery s'est penché sur une erreur courante dans l'architecture des applications d'IA : considérer le vector store comme une base de données complète pour tout le produit. Au stade de la démo, cela suffit souvent, mais en production, une couche relationnelle classique est presque toujours nécessaire à côté de la recherche vectorielle.

Où le vector store excelle

Les bases vectorielles sont devenues un élément standard des systèmes RAG parce qu'elles résolvent une tâche que le SQL classique gère mal : chercher par le sens plutôt que par correspondance exacte des mots. Quand l'utilisateur pose une question, le système la transforme en embedding et cherche les fragments de documents les plus proches par le sens. L'IA peut ainsi trouver des textes pertinents même lorsqu'ils n'emploient pas les mêmes formulations que la requête.

C'est particulièrement utile sur des données non structurées : documents internes, correspondance, PDF et bases de connaissances. Si quelqu'un demande quels sont les droits d'un locataire face à de la moisissure dans un appartement, la recherche vectorielle trouvera les sections sur les normes de décence du logement ou les obligations du bailleur, même si l'expression « conditions de vie dangereuses » n'apparaît pas dans le document. Cette approche tolère mieux les fautes de frappe, les reformulations et le contexte implicite. C'est pourquoi le vector store est devenu un composant de base de la recherche par IA là où les formulations ne coïncident presque jamais mot pour mot.

Où le SQL est nécessaire

Le problème, c'est que la souplesse de la recherche vectorielle en fait aussi un outil imprécis pour les tâches opérationnelles. Elle répond bien à la question « qu'est-ce qui se ressemble par le sens », mais convient mal quand il faut une réponse ferme, sans probabilités ni marges de tolérance. Dès qu'un produit compte des utilisateurs, des quotas, des paiements et des statuts d'objets, la recherche approximative se met à gêner plutôt qu'à aider.

C'est pourquoi, dans un système en production, la base relationnelle reste l'endroit où vivent tous les « faits durs » :

• droits d'accès et frontières entre tenants, où une erreur se traduit par une fuite de données ;
• métadonnées des documents : auteur, URL, date de téléversement, hash du fichier, statut 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 forfait a l'utilisateur.

Il y a aussi un point pratique : un filtrage SQL précis réduit les hallucinations du modèle. Si l'IA doit résumer uniquement les tickets de haute priorité clos au cours des 7 derniers jours par l'équipe frontend, il faut d'abord sélectionner strictement ces enregistrements, puis seulement transmettre leur texte au modèle. C'est moins cher, plus rapide et plus sûr que d'espérer que la recherche vectorielle seule renvoie par hasard un jeu de données parfaitement délimité. Au fond, le SQL ne concurrence pas ici le LLM : il lui prépare un espace de travail correct.

Un schéma hybride

L'auteur propose de ne pas choisir entre les deux approches, mais de les réunir dans une seule couche de données. Un scénario type : la base relationnelle vérifie d'abord l'utilisateur, son rôle et la liste des documents auxquels il a accès, et seulement ensuite le vector store cherche des correspondances sémantiques au sein de ce sous-ensemble sûr. Pour les assistants d'IA d'entreprise, ce n'est pas une optimisation mais une frontière de sécurité. Sans ce préfiltre, le système risque d'afficher à un utilisateur des données d'une autre équipe, voire d'un autre client.

Le schéma inverse fonctionne aussi. Une fois que la recherche vectorielle a renvoyé les fragments pertinents, l'application peut aller chercher dans SQL les métadonnées : qui est l'auteur du document, quand il a été mis à jour, quel est son statut de confiance. Le modèle répond alors non de façon abstraite, mais avec du contexte, par exemple en tenant compte de la fraîcheur du document ou du service qui l'a publié. Pour les bases de connaissances internes et les agents de support, cela renforce nettement la confiance dans la réponse et aide l'utilisateur à en vérifier rapidement l'origine.

Pour les équipes qui ne veulent pas maintenir deux bases distinctes, Machine Learning Mastery met en avant pgvector, une extension de PostgreSQL dédiée à la recherche par similarité. Dans ce cas, les embeddings se trouvent à côté des champs structurés, et une seule requête peut vérifier les droits, filtrer les enregistrements par date et statut, puis les classer par proximité sémantique. Le compromis est simple : à échelle modérée, cela simplifie nettement l'infrastructure, mais à des milliards de vecteurs, les systèmes spécialisés comme Pinecone ou Milvus restent plus rapides. En revanche, pour des centaines de milliers ou quelques millions de vecteurs, cette approche est souvent le point de départ le plus pragmatique.

Ce que cela signifie

La conclusion principale est simple : le vector store est un élément important de la pile d'IA, mais pas son remplaçant intégral. Si un produit manipule des utilisateurs, des accès, de l'argent et l'état du système, on ne peut pas se passer d'une base relationnelle. Pour la plupart des équipes, un départ raisonnable consiste à utiliser PostgreSQL avec pgvector, ou l'association de SQL et d'une base vectorielle distincte, chaque technologie ne traitant que la classe de tâches où elle excelle. Plus tôt cette séparation apparaît dans l'architecture, moins la démo risque de s'effondrer dès la première vraie montée en charge.