Autrefois, tout était simple : une base de données, c’était des lignes, des colonnes, des relations bien ficelées, et un langage bien rangé appelé SQL. Mais voilà qu’aujourd’hui, des termes comme vector search, embedding, ou encore similarité cosinus s’invitent à la table. Que s’est-il passé ? Tentons de démystifier tout ça, sans transformer cet article en thèse de doctorat.
1. Les bases de données relationnelles : le bon vieux classeur
Les bases de données relationnelles (comme MySQL, PostgreSQL, ou SQLite) sont comme des classeurs bien organisés. Chaque table est une feuille bien rangée avec des colonnes prédéfinies : nom, prénom, date de naissance… On stocke de la donnée structurée, c’est-à-dire des informations que l’on peut parfaitement modéliser en tableaux.
Elles brillent quand il s’agit de rechercher précisément :
« Donne-moi tous les clients dont le prénom est Jacques et qui habitent à Clermont-Ferrand ».
Ici, on veut une réponse exacte, sans ambiguïté. C’est le domaine de la logique booléenne : vrai ou faux, Jacques ou pas Jacques.
2. Les bases de données vectorielles : la mémoire du futur
À l’inverse, les bases de données vectorielles (comme FAISS, Milvus ou Pinecone) ne s’occupent pas de stocker des noms ou des adresses, mais plutôt des représentations numériques de concepts.
Un exemple ? Imaginons que vous donniez une image de volcan au système. Il ne va pas la stocker telle quelle, mais la transformer en un vecteur de nombres (souvent des centaines de dimensions). Ce vecteur résume le contenu de l’image d’un point de vue sémantique.
Ces bases sont donc faites pour des recherches approximatives intelligentes :
« Trouve-moi les documents les plus similaires à celui-ci »,
ou
« Quels sont les produits qui ressemblent à celui-ci, même si leur nom ne le dit pas explicitement ? »
C’est la recherche par proximité sémantique, pas par égalité stricte.
3. L’exactitude contre la similarité
| Caractéristique | Base relationnelle | Base vectorielle |
|---|---|---|
| Type de données | Structurées | Non structurées ou semi-structurées |
| Requête | Exacte (SQL) | Approximative (similarité) |
| Exemples d’usage | Comptabilité, gestion client, ERP | Recherche d’images, NLP, recommandation |
| Indexation | Index B-tree, Hash | Indexes de vecteurs (ANN, HNSW, etc.) |
| Résultat | Oui/non, égalité | Degré de ressemblance (score de similarité) |
4. Peut-on les marier ?
Bonne nouvelle : ces deux mondes ne sont pas incompatibles. De nombreuses architectures modernes utilisent les deux :
- Une base relationnelle pour gérer la structure métier (utilisateurs, produits, commandes),
- Et une base vectorielle pour enrichir l’expérience (recommandations, recherche sémantique, filtres intelligents…).
C’est un peu comme avoir un cerveau gauche logique (relationnel) et un cerveau droit intuitif (vectoriel) : les deux ensemble, c’est encore mieux.
Conclusion :
Les bases relationnelles sont le socle robuste de l’informatique depuis des décennies. Les bases vectorielles, quant à elles, ouvrent la voie à une informatique plus intuitive, capable de comprendre le sens des choses. Ensemble, elles permettent de répondre à la fois à la question « qui est Jacques ? » et à « qu’est-ce qui ressemble à Jacques, mais n’est pas exactement lui ? »
Figure : Représentation visuelle des différences fondamentales entre une base de données relationnelle (structurée) et une base vectorielle (non structurée ou semi-structurée).