Une base de données vectorielle stocke des représentations numériques du sens (embeddings) pour retrouver des passages proches d’une question. Voici ce que ça change par rapport à une base classique, comment ça s’articule avec le chunking, et quels exemples connaître sans en faire une religion.
Définition
Après le chunking, chaque morceau est transformé en vecteur par un modèle d’embedding. La base vectorielle stocke ces vecteurs (et souvent le texte + métadonnées) et répond à des requêtes du type : « quels chunks sont proches de cette question ? ». Des noms fréquents dans l’écosystème : Qdrant, Chroma, pgvector (extension PostgreSQL), et d’autres moteurs intégrés à des outils locaux.
Ce que le mot ne désigne pas : ce n’est pas une garantie de vérité. Ce n’est pas un remplacement automatique d’une base SQL pour la comptabilité ou les droits d’accès métiers. Ce n’est pas le reranker. Et ce n’est pas « l’IA » : sans bon découpage, sans bon embedding, sans politique de mise à jour des documents, la plus belle base renverra du bruit poli.
Opérationnellement, une base vectorielle implique aussi sauvegarde, restauration, et stratégie de purge : que devient un document retiré du partage métier ? S’il reste vectorisé, le chat peut continuer à le citer. Prévoir la synchro corpus / index fait partie du design, au même titre que le choix entre Qdrant, Chroma ou pgvector. Sans cette hygiène, l’outil devient une mémoire fantôme.
Un exemple du quotidien
Analogie : une bibliothèque classique range par cote ; une base vectorielle range aussi par « voisinage de sens ». Vous demandez un thème ; elle ramène des rayons proches, même si le mot exact diffère. Utile pour le langage naturel ; moins magique pour un numéro de pièce exact — d’où l’intérêt de la recherche hybride.
Dans un produit comme Open WebUI, la « knowledge base » s’appuie souvent sur une couche vectorielle plus ou moins visible. Vous uploadez des fichiers ; sous le capot, chunks et vecteurs sont créés. Comprendre qu’il y a une base évite de croire que le chat « a lu » le PDF à chaque message comme un humain feuilleterait.
Un exemple en Hauts-de-France
À Calais, une PME logistique veut interroger ses consignes sécurité et ses modes opératoires. Elle déploie une petite base vectorielle sur un serveur interne, y pousse des PDF validés, et branche un modèle local. Le succès dépend moins du logo de la base que de la fraîcheur des documents et des droits d’accès par équipe.
À Boulogne-sur-Mer, une coopérative teste d’abord une solution intégrée (moins de devops), puis envisage pgvector parce qu’elle a déjà PostgreSQL. L’atelier IAHDF rappelle : choisissez la complexity opérationnelle que vous savez maintenir. Le matériel compte ; la discipline de mise à jour des corpus compte davantage encore.
On confond souvent
Première confusion : base vectorielle = mémoire du chat. Non. Le chat a un contexte de conversation ; la base stocke un corpus. Deuxième confusion : croire qu’il faut toujours un produit dédié ultra-scalable. Pour un usage TPE, une option simple intégrée à l’outil peut suffire longtemps.
Autre mélange : confondre embedding et base. L’embedding calcule le vecteur ; la base l’indexe et le cherche. Changer d’embedding implique souvent de ré-indexer. Autre piège : oublier les métadonnées (date, service, confidentialité) : sans filtres, la similarité seule peut ramener un document hors périmètre.
En pratique, que faire avec ce mot
Pour débuter, utilisez la base proposée par votre stack locale, indexez un corpus petit et propre, testez des questions oracles. Ajoutez hybride et reranker si les ratés le justifient. Planifiez la ré-indexation quand les documents changent. Notez quel embedding a servi : sans cela, la base devient une boîte noire.
Évaluez Qdrant, Chroma, pgvector (ou l’intégré de votre UI) selon vos compétences d’exploitation, pas selon la hype. Croisez chunking, recherche hybride et le tutoriel Qwen. Et traitez les droits : une base vectorielle est un silo documentaire ; chiffrez, restreignez, auditez comme pour tout partage de fichiers sensibles.
Pour une première base vectorielle en Hauts-de-France, préférez un périmètre documentaire étroit et versionné : un dossier, un responsable, une date de mise à jour. Mesurez la pertinence sur vingt questions métier avant d’indexer tout le partage réseau. Une base vaste et sale donne des réponses fluides et fausses. La qualité du stock documentaire compte autant que le choix entre Qdrant, Chroma ou pgvector.
Termes voisins
- Embedding
- Vecteur qui représente le sens d’un texte ; entrée typique d’une base vectorielle.
- Chunk
- Segment de document indexé. Voir chunking.
- Similarité
- Mesure de proximité entre vecteurs question et chunks (selon métrique de l’index).
- Métadonnées
- Filtres utiles (source, date, service) pour restreindre la recherche au bon périmètre.
Pour aller plus loin
Compléments : chunking, reranker, recherche hybride. Ateliers : l’agenda. Communauté : l’inscription.
Questions fréquentes
C’est quoi une base vectorielle ?
C’est un système qui stocke des vecteurs (souvent des embeddings de passages) et permet de retrouver les plus proches d’une requête. Dans un RAG, elle sert à sélectionner des extraits à injecter dans le modèle. Elle ne « comprend » pas seule au sens humain : elle organise des proximités numériques. Sa valeur dépend de la qualité des chunks, de l’embedding et des filtres de métadonnées. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant.
Faut-il Qdrant, Chroma ou pgvector ?
Aucun choix unique. Chroma est souvent cité pour démarrer simplement ; Qdrant pour un service dédié ; pgvector si vous voulez rester dans PostgreSQL. Regardez surtout : installation, sauvegarde, filtres, charge prévue, compétences de l’équipe. Pour beaucoup de premiers projets locaux, la base intégrée à l’outil suffit. Migrez quand une limite réelle apparaît. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant. Conservez la version d’outil et du modèle pour pouvoir expliquer la décision à un collègue.
Une base vectorielle remplace-t-elle Google ou un GED ?
Non. Elle complète un usage conversationnel sur un corpus choisi. Une GED gère versions, droits, workflows. Un moteur web couvre l’ouvert. La base vectorielle brille pour « retrouver le passage utile » dans vos documents validés. Gardez clairement le rôle de chaque outil dans votre architecture d’information. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant. Conservez la version d’outil et du modèle pour pouvoir expliquer la décision à un collègue.
Que se passe-t-il si je change d’embedding ?
En général, il faut ré-indexer : les vecteurs d’anciens embeddings ne sont pas comparables avec les nouveaux dans le même espace. Planifiez le temps de recalcul et un test de non-régression sur vos questions oracles. Ne changez pas d’embedding chaque semaine sans raison. Documentez la version retenue comme vous documentez le tag du LLM. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant.
Quels risques de confidentialité ?
La base concentre des extraits potentiellement sensibles. Qui y a accès ? Est-elle chiffrée au repos ? Est-elle sauvegardée ? Des logs conservent-ils les questions ? Traitez-la comme un partage documentaire critique. Un modèle local devant une base mal protégée ne crée pas de « souveraineté » : il crée une fausse impression de sécurité. Prévoir aussi la purge quand un document est retiré du périmètre métier. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant.