Comment fonctionnent réellement les bases de données vectorielles : des embeddings à la recherche hybride
Explique comment les embeddings encodent le sens, comment la recherche de similarité et l’indexation s’échelonnent, et quand les recherches hybrides et les bases de données vectorielles conviennent réellement aux systèmes d’IA d’entreprise.
Il y a une phrase qui revient constamment lorsque les développeurs commencent à travailler avec des systèmes GenAI :
« Je comprends comment fonctionnent les bases de données SQL. Mais les bases de données vectorielles me semblent toujours être une boîte noire. »
C’est une position tout à fait légitime.
Une base de données conventionnelle traite les requêtes grâce à des relations structurées :
SELECT * FROM customers WHERE country = 'India';
Une base de données vectorielle a été conçue pour répondre à un type de question fondamentalement différent :
« Quels éléments stockés ont un sens le plus proche de cette requête ? »
Cette évolution dans la nature des questions posées sous-tend une part étonnamment importante des applications actuelles basées sur l’IA.
Les pipelines RAG, la recherche sémantique, les systèmes de recommandation, les assistants basés sur des documents et les agents autonomes s’appuient tous fortement sur cette capacité.
Ce qui importe le plus, ce n’est pas la technologie de base de données elle-même.
Cela permet de comprendre ce qu’un vecteur encode réellement, comment on mesure la proximité entre les vecteurs, et pourquoi choisir la bonne méthode d’indexation est important.
Qu’est-ce qu’un embedding, exactement ?
Transformer le sens en nombres
Considérons cette phrase :
"Employees can work remotely for up to 30 days."
[0.021, -0.184, 0.731, 0.092, ...]
Évitez de penser que chaque nombre représente :
« Cette valeur particulière correspond au mot “employé”. »
Ce n’est pas un modèle mental précis.
En réalité, le vecteur est une encodage numérique appris des caractéristiques sémantiques du texte.
Ainsi, des phrases comme :
"I love my dog."
"My puppy is my favorite companion."
aboutiront généralement à des vecteurs situés plus proches les uns des autres que pour une paire telle que :
"I love my dog."
"The database connection timed out."
C’est là le mécanisme fondamental en jeu.
Le sens est traduit en quelque chose qui peut être recherché mathématiquement.
Génération d’un embedding
La création d’un embedding à l’aide d’un modèle suit un schéma simple :
from openai import OpenAI
client = OpenAI()
response = client.embeddings.create(
model="text-embedding-3-small",
input="Employees can work remotely for up to 30 days."
)
vector = response.data[0].embedding
print(len(vector))
print(vector[:5])
Le vecteur résultant n’est pas destiné à être lu par un humain.
C’est normal.
Les êtres humains ne font pas partie du public cible des nombres bruts.
L’objectif est de comparer ce vecteur avec d’autres vecteurs.
La similarité est l’idée principale
En son essence, une base de données vectorielle effectue des recherches dans un espace mathématique
Disons que vous disposez de trois documents sources :
A -> Remote work policy
B -> Travel reimbursement policy
C -> Employee leave policy
Et votre requête est :
"Can I work from home while travelling abroad?"
La requête est d’abord intégrée en embedding.
Puis ce vecteur de requête est comparé au vecteur de chaque document.
Une métrique de similarité largement utilisée ici est la similarité cosinus :
import numpy as np
def cosine_similarity(a, b):
return np.dot(a, b) / (
np.linalg.norm(a) *
np.linalg.norm(b)
)
Visuellement, cela ressemble à ceci :
Lorsque les vecteurs sont normalisés, la similarité cosinus devient mathématiquement proche de la similarité par produit scalaire.
Cette similitude explique pourquoi ces deux concepts apparaissent fréquemment dans les discussions sur les systèmes de recherche vectorielle.
Pourquoi ne pouvons-nous pas simplement comparer chaque vecteur ?
C’est l’échelle qui rend l’approche naïve inefficace
Imaginez un ensemble de données composé de :
1,000 documents
Au niveau de taille considéré, comparer la requête avec chacun des vecteurs est une tâche simple.
Imaginons maintenant :
100 million vectors
Mettre en œuvre une comparaison exhaustive avec chaque vecteur à cette échelle devient coûteux.
C’est précisément le problème que résout la indexation vectorielle.
Au lieu de vérifier chaque vecteur un par un, les techniques d’approximation du voisin le plus proche structurent l’espace vectoriel de manière à ce que la recherche de vecteurs fortement similaires se fasse bien plus rapidement.
Une famille bien connue de telles techniques est HNSW - Graphes hiérarchiques navigables du petit monde.
Vous n’avez pas besoin de construire HNSW vous-même pour bénéficier de la recherche vectorielle.
Ce que vous devez comprendre, c’est l’équilibre fondamental qui existe :
Un petit sacrifice en termes de précision de la recherche exacte vous permet d’obtenir une amélioration significative en vitesse ainsi que la capacité de s’échelonner.
Cet équilibre est au cœur du fonctionnement des bases de données vectorielles.
Que stocke réellement un index vectoriel ?
Dans une mise en œuvre réelle, chaque enregistrement stocké contient généralement bien plus que simplement l’embedding :
document = {
"id": "policy-1042",
"title": "Remote Work Policy",
"content": "Employees can work remotely...",
"department": "HR",
"country": "India",
"embedding": vector
}
Ce détail est très important.
L’incorporation ne remplace pas le document complet.
Elle fonctionne comme une représentation du document adaptée à l’indexation.
En plus de cela, vous devez toujours conserver :
- le texte original, les métadonnées, les identifiants uniques, les détails de contrôle d’accès et les références vers la source
Cela devient crucial lorsque vous développez des systèmes RAG pour un usage d’entreprise.
Azure AI Search
Le point d’intersection entre la recherche vectorielle et la recherche d’entreprise
Azure AI Search propose une recherche basée sur des vecteurs en plus de la recherche par mots-clés traditionnelle, ainsi que des combinaisons hybrides des deux.
Un exemple simplifié d’une requête vectorielle se présente comme suit :
from azure.search.documents.models import VectorizedQuery
vector_query = VectorizedQuery(
vector=query_vector,
k_nearest_neighbors=5,
fields="content_vector"
)
results = search_client.search(
search_text=None,
vector_queries=[vector_query],
select=["title", "content"]
)
Ce qui est retourné n’est pas présenté comme :
« Voici la phrase mathématiquement la plus proche. »
À la place, vous obtenez une collection de documents classés, ordonnés selon la configuration de recherche vectorielle que vous avez définie.
C’est là que les décisions architecturales commencent à avoir un impact réel.
Pourquoi la recherche hybride l’emporte souvent
La recherche basée sur le sens et la recherche par mots-clés se distinguent chacune dans des situations différentes
Prenons cette question :
"Que dit la politique HR-2026-17 ?"
Pour ce type de recherche, la recherche par mots-clés est très efficace.
Comparons-la maintenant à ceci :
"Un employé peut-il travailler temporairement depuis un autre pays ?"
Ici, la recherche sémantique a clairement l’avantage.
Au lieu de choisir une approche plutôt qu’une autre :
Keyword OR Vector
vous pouvez les combiner :
Keyword + Vector => Hybrid Ranking
Azure AI Search vous permet d’exécuter des requêtes hybrides qui associent la recherche de texte complet à la recherche vectorielle.
Cela révèle un schéma utile :
results = search_client.search(
search_text="remote work from another country",
vector_queries=[vector_query],
top=10
)
La configuration spécifique du classement variera en fonction du cas d’usage, mais le point essentiel est le suivant :
Ne résolvez pas tous les problèmes de recherche uniquement à l’aide d’embeddings.
Le filtrage des métadonnées n’est pas optionnel à l’échelle enterprise
Imaginez que votre index vectoriel contienne des documents tels que ceux-ci :
India HR policies
US HR policies
UK HR policies
Finance policies
Engineering documentation
Un utilisateur demande alors :
"Quel est le plafond de remboursement pour les voyages en Inde ?"
Se fier uniquement à la similarité sémantique pourrait faire apparaître des documents correspondants provenant de plusieurs régions différentes en même temps.
L’ajout de filtres métadonnées vous permet de restreindre la portée :
results = search_client.search(
search_text=query,
vector_queries=[vector_query],
filter="country eq 'India'",
top=5
)
Désormais, la recherche combine deux éléments :
Semantic relevance + Structured filtering
C’est en partie pour cette raison que les ingénieurs de données maîtrisent rapidement la recherche vectorielle de niveau enterprise.
Cela ne remplace pas ce que les bases de données font déjà bien.
À la place, il combine la récupération sémantique non structurée avec une approche basée sur des données structurées familière.
Pinecone, Weaviate et Databricks Vector Search
Différents fournisseurs, même concept de base
Quelques plateformes que vous rencontrerez probablement :
Pinecone
Une base de données vectorielle entièrement gérée conçue principalement pour une recherche vectorielle scalable.
Weaviate
Une base de données vectorielle open source offrant une recherche vectorielle, du filtrage ainsi que diverses fonctionnalités axées sur l’IA.
Databricks Vector Search
Une fonctionnalité de recherche vectorielle intégrée à la plateforme Databricks, particulièrement utile lorsque vos données d’entreprise se trouvent déjà dans un lakehouse.
Les interfaces et les détails opérationnels varient d’un outil à l’autre.
Le concept de base reste identique :
Ne traitez pas ces produits comme des technologies distinctes à maîtriser séparément.
Commencez par comprendre le modèle de recherche lui-même.
Lorsque vous l’aurez fait, chaque produit n’aura plus qu’une valeur de choix d’implémentation différente.
Où les bases de données vectorielles ont réellement du sens
Une base de données vectorielle n’est pas l’outil idéal pour tous les scénarios d’intelligence artificielle
Les cas d’usage pertinents incluent :
RAG d’entreprise
Localiser des politiques, des documents et des connaissances techniques pertinentes.
Recherche sémantique
Faire des correspondances sur des concepts sous-jacents plutôt que sur des mots-clés exacts.
Recommandations
Faire apparaître des produits, du contenu ou des documents présentant des caractéristiques similaires.
Systèmes d’assistance
Révéler des incidents ou des tickets antérieurs similaires au cas actuel.
Recherche de code
Localiser des fonctions ou des extraits qui sont sémantiquement liés à un problème donné.
Aides à l’ingénierie des données
Récupération de documents pertinents relatifs aux pipelines, de schémas, de guides d’exécution et d’historiques d’incidents.
Cela dit, ne recourez pas systématiquement à une base de données vectorielle pour les requêtes analytiques structurées.
Si la question est :
"Quel était le chiffre d’affaires au deuxième trimestre ?"
et que la réponse se trouve dans un entrepôt de données géré, SQL est généralement l’outil le plus adapté.
Structured question => SQL
Semantic question => Vector Search
Mixed question => SQL + Vector Search
Ce simple distinguo peut éviter de nombreux erreurs d’architecture.
L’architecture d’entreprise que je préfère
Un système de récupération bien conçu ressemble davantage à un pipeline qu’à un outil unique.
La base de données vectorielle n’est qu’une partie de ce pipeline.
C’est probablement le plus grand malentendu à corriger.
Une base de données vectorielle seule ne rend pas une application d’IA intelligente.
Ce qu’il offre, c’est un moyen efficace de récupérer des informations en se basant sur la proximité sémantique.
L’intelligence réelle provient de tout ce qui l’entoure :
- la stratégie d’incorporation, la manière dont le contenu est divisé en blocs, les métadonnées associées, la logique de récupération, les décisions de classement, la façon dont le contexte est assemblé, les pratiques d’évaluation, ainsi que le modèle lui-même
Le modèle mental à retenir
Si vous êtes ingénieur en données en train de passer à l’ingénierie en IA, ne commencez pas par mémoriser les noms de produits.
Préférez plutôt retenir ceci :
Embedding = numerical representation of meaning
Vector Search = find semantically similar representations
Vector Index = make nearest-neighbor search fast
Hybrid Search = semantic + lexical retrieval
Metadata Filter = apply structured constraints
Reranking = improve ordering of retrieved candidates
Lorsque ces six concepts vous sembleront naturels, des outils tels qu’Azure AI Search, Pinecone, Weaviate et Databricks Vector Search ne paraîtront plus comme des énigmes distinctes.
Ils ne sont en réalité que différentes façons de résoudre la même question fondamentale :
Face à une requête, comment extraire les informations les plus utiles d’une vaste collection de données ?
C’est précisément pour cette raison que les bases de données vectorielles sont importantes.
Elles ne représentent pas simplement une autre catégorie de bases de données.
Elles deviennent l’un des éléments essentiels qui permettent aux systèmes d’IA modernes de récupérer des informations.
Pour les ingénieurs en données, cela en fait des outils dignes d’une formation approfondie – non pas parce que chaque projet nécessite une base de données vectorielle, mais parce que de plus en plus, les applications d’IA ont besoin d’un moyen fiable pour trouver les bonnes informations avant de pouvoir produire la bonne réponse.
Lectures complémentaires
- Benchmarking des bases de données vectorielles pour la recherche sémantique à haute capacité — Découvrez une méthodologie pratique en Node.js et Python pour évaluer les bases de données vectorielles sous des charges réalistes, afin de prendre des décisions architecturales et de scaling éclairées.
- Les bases de données vectorielles expliquées : le moteur derrière la recherche RAG et l’IA — Apprenez comment les bases de données vectorielles transforment le texte en embeddings, alimentent la recherche sémantique et les pipelines RAG, et permettent le fonctionnement d’applications d’IA dans le monde réel comme les recommandations.