Base de données vectorielle Python
Une base de données vectorielle permet de retrouver un contenu par son sens, même lorsque la requête n'utilise pas les mêmes mots. Avec Python, PostgreSQL et pgvector, vous pouvez tester cette recherche sémantique sans ajouter une nouvelle base à votre architecture. L'exemple plus bas couvre la génération d'embeddings, leur insertion et la recherche.
Comprendre les bases de données vectorielles
Le principe : transformer n'importe quel contenu en une série de nombres, un vecteur. Texte, image, audio ou vidéo, tout peut être converti en une représentation mathématique qui capture son sens. Deux contenus similaires en signification produisent des vecteurs proches dans l'espace mathématique, même si leur forme originale est différente.
Un exemple : "Je cherche un développeur Python expérimenté" et "Besoin d'un ingénieur senior maîtrisant Python". Aucun mot identique, mais le sens est le même. Une base vectorielle place ces phrases proches l'une de l'autre, et les retrouve toutes les deux quelle que soit la formulation de la requête. La distance entre deux points reflète leur proximité de sens, pas leur similitude de mots.
Ça change la façon de penser la recherche d'information. Plus de correspondances exactes de mots-clés : les bases vectorielles comprennent le contexte et l'intention. Elles peuvent même croiser les médias, chercher une image à partir d'une description textuelle, ou retrouver un document correspondant au contenu d'une photo.
Ce que ça change pour votre produit
Pensez à la façon dont vos utilisateurs interagissent avec vos données aujourd'hui : ils saisissent des mots-clés, filtrent, trient, parfois renoncent. Avec une base vectorielle, ils peuvent converser avec votre produit comme avec un expert qui connaît toute votre base de connaissances. C'est difficile à reproduire pour un concurrent qui n'a pas fait ce travail.
Quand Notion a intégré son assistant IA ou qu'Intercom a lancé Fin, la valeur perçue de leur produit a changé. Derrière ces interfaces, des bases vectorielles indexent toute la documentation. L'utilisateur voit une interface naturelle, le système fait une recherche sémantique parmi des millions de fragments d'information.
Concrètement : un outil de gestion de projet pourrait suggérer automatiquement des collaborateurs en analysant la nature d'une tâche. Une plateforme e-commerce pourrait permettre de chercher "quelque chose d'élégant pour un mariage en été" plutôt que de naviguer dans des catégories rigides. Un logiciel RH pourrait matcher candidats et postes en comprenant les compétences au-delà des mots-clés. Ce n'est pas une fonctionnalité de plus, c'est une friction en moins dans le parcours utilisateur.
Cas d'usage concrets
Le knowledge management est le cas d'usage le plus immédiat. Si votre équipe passe des heures à chercher l'information dispersée dans Notion, Slack ou Google Drive, un moteur vectoriel règle le problème. L'employé pose une question en langage naturel, le système parcourt tous vos documents et extrait les passages pertinents, même avec une terminologie différente.
Le support client est un autre terrain à fort ROI. Plutôt que de former vos agents sur des centaines de pages de documentation, vous déployez un assistant qui connaît votre produit. Il comprend la question dans son contexte et synthétise une réponse personnalisée. Pour une startup en croissance, ça permet de scaler le support sans multiplier les effectifs proportionnellement.
Les applications sectorielles vont encore plus loin. Dans le juridique ou le financier, retrouver tous les précédents similaires en quelques secondes. Dans la santé, trouver des cas cliniques comparables. Dans le recrutement, matcher sur des affinités de compétences et d'expérience, pas juste des mots-clés dans un CV. Pour certaines startups, c'est le coeur même de la proposition de valeur.
Choisir sa stack intelligemment
Le paysage technologique s'est enrichi ces dernières années. Les solutions spécialisées comme Pinecone ou Weaviate offrent des performances optimales mais avec des coûts variables qui peuvent exploser. À l'inverse, pgvector pour PostgreSQL permet d'ajouter des capacités vectorielles à votre base relationnelle existante, avec une courbe d'apprentissage plus douce et un coût prévisible.
Le piège : penser que vous devez tout migrer vers une architecture vectorielle. La plupart des startups ont besoin d'une approche hybride. Vos données transactionnelles restent adaptées à SQL. Ce sont vos fonctionnalités de recherche sémantique et d'IA conversationnelle qui bénéficieront du vectoriel. Complémentarité, pas remplacement.
N'oubliez pas les questions de confidentialité et de souveraineté, particulièrement en Europe. Héberger vos vecteurs chez un provider américain peut poser des problèmes RGPD. Regardez les solutions offrant un déploiement on-premise ou dans le cloud de votre choix. Pensez aussi à l'intégration avec votre stack IA : assurez-vous que votre base vectorielle peut facilement ingérer les embeddings produits par OpenAI ou Anthropic.
Exemple Python avec pgvector
Un embedding est une liste de nombres qui représente le sens d'un texte. Le modèle transforme chaque document en vecteur, puis pgvector compare ces vecteurs. Deux textes proches par leur sens obtiennent une forte similarité, même s'ils partagent peu de mots.
J'utilise cette approche sur CAPSTON.ai pour rapprocher des citations et des pages par similarité sémantique. La première requête est assez simple. En production, le travail consiste surtout à garder les embeddings synchronisés avec le contenu et à surveiller le volume de la table.
L'exemple suivant utilise le modèle text-embedding-3-small, dont les vecteurs comportent 1 536 dimensions par défaut. La colonne PostgreSQL doit utiliser la même dimension. Installez d'abord les clients Python :
pip install openai "psycopg[binary]" pgvector
Définissez ensuite OPENAI_API_KEY et DATABASE_URL dans votre environnement, puis exécutez ce script :
import os
import psycopg
from openai import OpenAI
from pgvector import Vector
from pgvector.psycopg import register_vector
client = OpenAI()
def create_embedding(text: str) -> list[float]:
response = client.embeddings.create(
model='text-embedding-3-small',
input=text,
)
return response.data[0].embedding
documents = [
'Notre CTO accompagne les équipes deux jours par semaine.',
'La sauvegarde quotidienne limite le risque de perte de données.',
'pgvector ajoute la recherche sémantique à PostgreSQL.',
]
with psycopg.connect(os.environ['DATABASE_URL'], autocommit=True) as connection:
connection.execute('CREATE EXTENSION IF NOT EXISTS vector')
register_vector(connection)
connection.execute(
'''
CREATE TABLE IF NOT EXISTS documents (
id BIGSERIAL PRIMARY KEY,
content TEXT UNIQUE NOT NULL,
embedding VECTOR(1536) NOT NULL
)
'''
)
connection.execute(
'''
CREATE INDEX IF NOT EXISTS documents_embedding_hnsw
ON documents USING hnsw (embedding vector_cosine_ops)
'''
)
for content in documents:
embedding = Vector(create_embedding(content))
connection.execute(
'''
INSERT INTO documents (content, embedding)
VALUES (%s, %s)
ON CONFLICT (content)
DO UPDATE SET embedding = EXCLUDED.embedding
''',
(content, embedding),
)
question = 'Comment retrouver des contenus proches dans Postgres ?'
query_embedding = Vector(create_embedding(question))
results = connection.execute(
'''
SELECT content, 1 - (embedding <=> %s) AS similarity
FROM documents
ORDER BY embedding <=> %s
LIMIT 3
''',
(query_embedding, query_embedding),
).fetchall()
for content, similarity in results:
print(f'{similarity:.3f} - {content}')
L'opérateur <=> calcule la distance cosinus. La requête la soustrait à 1 pour obtenir un score de similarité plus lisible : plus il se rapproche de 1, plus les contenus sont proches. L'index HNSW accélère les recherches lorsque le volume augmente, au prix d'un index plus lourd et d'insertions un peu plus coûteuses.
Ce prototype suffit pour valider un moteur de recherche interne ou une première brique de RAG. En production, ajoutez une file de traitement pour recalculer les embeddings quand un document change, versionnez le modèle utilisé et mesurez le coût avant d'indexer tout votre historique. Les exemples officiels de pgvector pour Python et le guide OpenAI sur les embeddings détaillent les autres clients et options d'indexation.
Si votre cas d'usage va au-delà de la recherche et doit générer des réponses, la comparaison entre RAG et fine-tuning aide à choisir l'architecture adaptée.
Un prototype doit aussi rester proportionné au produit et aux données disponibles. Mon offre d'ingénierie IA et LLM couvre ce cadrage avant de multiplier les modèles, les index et les coûts d'API.
Ce qu'il faut retenir
Une base vectorielle complète votre base relationnelle au lieu de la remplacer. PostgreSQL conserve les données transactionnelles, tandis que pgvector ajoute la comparaison sémantique. Commencez par un cas d'usage limité, comme une recherche interne ou un chatbot documentaire, puis mesurez la qualité des résultats et le coût des embeddings avant d'élargir le périmètre.
Questions fréquentes
Quelle est la différence entre une base vectorielle et une base relationnelle ?
Une base relationnelle cherche des correspondances exactes de mots-clés. Une base vectorielle transforme le contenu en représentations mathématiques et compare leur proximité sémantique. Deux phrases différentes ayant le même sens seront proches dans l'espace vectoriel.
Faut-il remplacer sa base de données actuelle ?
Non. La plupart des startups ont besoin d'une approche hybride : SQL pour les données transactionnelles, vectoriel pour la recherche sémantique et l'IA. Des solutions comme pgvector permettent d'ajouter des capacités vectorielles directement à PostgreSQL.
Comment créer une base de données vectorielle en Python ?
Activez l'extension pgvector dans PostgreSQL, créez une colonne VECTOR avec la dimension attendue, puis générez les embeddings dans Python. Vous pouvez ensuite insérer ces vecteurs avec Psycopg et les comparer avec un opérateur de distance comme <=>.
Conclusion
Vous voulez valider un cas d'usage de recherche sémantique sans surdimensionner l'architecture ? Réservez un échange de 30 minutes pour cadrer un premier prototype.
Newsletter
Une anecdote tech par semaine
Retours d'expérience tirés du terrain : architecture, dette technique, leadership produit.



