Bases vectorielles : faut-il vraiment en installer une

La question de la base vectorielle arrive toujours au même moment : quelqu'un a fait fonctionner une recherche sémantique sur un jeu de documents, ça marche, et il faut maintenant décider où stocker les vecteurs pour de bon. À ce stade, le réflexe est d'aller chercher un moteur spécialisé, parce que c'est ce dont tout le monde parle.

Ce réflexe est souvent une erreur de calendrier. Une base vectorielle dédiée résout des problèmes réels, mais ce sont des problèmes d'échelle, et la majorité des projets d'entreprise n'atteignent jamais cette échelle. Beaucoup fonctionnent très bien avec quelques dizaines de milliers de vecteurs stockés dans la base de données qu'ils avaient déjà.

Cet article compare les trois options disponibles, donne les seuils de volume à partir desquels la question se pose sérieusement, et liste les critères qui font réellement basculer une décision. L'objectif est de vous permettre de trancher en une demi-journée, sur des chiffres tirés de votre projet.

Base vectorielle : ce que ça fait, et ce que ça ne fait pas

Une base vectorielle stocke des vecteurs de nombres et sait retrouver rapidement les plus proches d'un vecteur donné, selon une mesure de distance. C'est tout. Elle ne comprend pas le sens : le sens vient du modèle qui a produit les vecteurs, sujet que nous avons traité dans notre explication des embeddings et de la vectorisation.

Le problème technique qu'elle résout s'appelle la recherche de plus proches voisins approximative. Comparer un vecteur à un million d'autres, un par un, est faisable mais lent. Les index spécialisés, dont le plus répandu est HNSW (un graphe de navigation hiérarchique décrit dans un article de recherche de 2016), échangent une petite perte de précision contre un gain de vitesse de plusieurs ordres de grandeur.

Deux points sont mal compris et méritent d'être posés d'emblée.

• Sans index, ça marche aussi. Une recherche exhaustive sur 20 000 ou 50 000 vecteurs prend quelques dizaines de millisecondes sur du matériel ordinaire. L'index ne devient nécessaire qu'à partir de volumes bien supérieurs.
• La qualité de la recherche vient d'ailleurs. Le découpage des documents, le modèle d'embedding et le reclassement des résultats pèsent bien plus lourd sur la pertinence que le choix du moteur. Changer de base vectorielle pour améliorer des résultats médiocres ne fonctionne jamais.

Trois options, trois profils de projet

Les solutions se rangent en trois familles, et le choix se joue davantage sur l'exploitation que sur la performance brute.

Le clivage réel n'est pas technique, il est organisationnel : avez-vous quelqu'un pour exploiter un service de plus ? C'est le même arbitrage que celui décrit à propos du choix entre auto-hébergement et service en ligne pour l'automatisation, et il se tranche de la même façon.

À partir de combien de vecteurs la question se pose

Quelques ordres de grandeur permettent de situer son projet. Un vecteur de 1 536 dimensions en simple précision occupe environ 6 kilo-octets. Un document de 20 pages découpé en fragments de 500 mots donne une trentaine de vecteurs.

La première ligne surprend souvent. Une base de connaissances interne de cinq cents documents, ce qui correspond déjà à une belle documentation d'entreprise, tient dans une centaine de méga-octets et se recherche sans index. Pour la plupart des projets de recherche augmentée sur les documents d'entreprise, la réponse honnête à « quelle base vectorielle choisir » est : celle que vous avez déjà.

Deux précisions techniques utiles. La consommation mémoire d'un index HNSW dépasse nettement la taille brute des vecteurs, souvent d'un facteur deux à trois, et cette mémoire doit être disponible sur le serveur de base de données. Par ailleurs, du côté de pgvector, l'indexation impose des limites de dimensions plus basses que le stockage : on peut stocker des vecteurs jusqu'à 16 000 dimensions mais l'index standard s'arrête bien avant, ce qui n'est un problème que pour des modèles à très forte dimensionnalité.

Ce que vous perdez en ajoutant un moteur dédié

Les comparatifs mettent en avant ce que le moteur spécialisé apporte. Il est plus instructif de regarder ce qu'il retire.

• La cohérence transactionnelle. Avec une extension, supprimer un document et ses vecteurs se fait dans la même transaction. Avec deux systèmes, une panne au mauvais moment laisse des vecteurs orphelins qui remontent dans les résultats et citent des documents supprimés.
• Les jointures. Filtrer sur « les documents du service juridique, valides, en français, mis à jour depuis un an » est une clause SQL triviale. Les moteurs dédiés proposent du filtrage, mais avec un modèle de données plus pauvre et parfois une dégradation de performance quand le filtre est très sélectif.
• Les sauvegardes. Votre base est sauvegardée et restaurée selon une procédure éprouvée. Un service supplémentaire signifie une deuxième procédure, à écrire, à tester et à maintenir.
• La gestion des droits. Les droits d'accès existent déjà dans votre base. Les rejouer dans un second système est une source classique de fuite de données.
• Un composant de plus à surveiller. Supervision, mises à jour de sécurité, montée de version. Le coût n'est pas dans l'installation, il est dans les trois ans qui suivent.

Les critères qui font vraiment basculer

Cinq situations justifient un moteur dédié, et il faut en cocher au moins une.

1. Le volume dépasse quelques millions de vecteurs avec une exigence de latence sous les cent millisecondes. C'est le critère le plus net.
2. Le multi-locataire est structurel. Un produit servant des centaines de clients dont les données doivent rester strictement cloisonnées bénéficie des mécanismes de partitionnement des moteurs spécialisés.
3. Les mises à jour sont massives et continues. Un flux permanent d'insertions et de suppressions met à l'épreuve la reconstruction d'index, domaine où les moteurs dédiés sont plus outillés.
4. La recherche hybride est centrale. Combiner un score lexical et un score vectoriel avec une fusion pondérée est faisable partout, mais nativement mieux pris en charge par les moteurs de recherche et les bases vectorielles récentes.
5. Vous avez besoin de quantification agressive. Au-delà de dix millions de vecteurs, la compression devient nécessaire pour tenir en mémoire, et c'est une spécialité des moteurs dédiés.

Si aucun de ces cinq points ne s'applique, l'extension de votre base existante est le choix par défaut, et le rester est une décision parfaitement défendable.

Comment décider en une demi-journée

Une procédure simple, applicable sans expertise préalable.

1. Comptez vos vecteurs à douze mois. Nombre de documents multiplié par le nombre moyen de fragments, avec une hypothèse de croissance. C'est le chiffre qui détermine tout le reste.
2. Comptez vos requêtes par seconde en pointe. La plupart des projets internes sont à moins d'une requête par seconde, ce qui rend le débat sur la performance largement théorique.
3. Mesurez avec ce que vous avez. Chargez vos vecteurs dans une extension, sans index, et chronométrez. Si la réponse arrive en cinquante millisecondes, la question est close pour cette année.
4. Testez la pertinence avant la performance. Constituez trente questions avec la bonne réponse attendue, et mesurez le taux de récupération. Si ce taux est mauvais, aucun changement de moteur ne le corrigera.
5. Notez la décision et sa date de révision. « Extension jusqu'à un million de vecteurs, réexamen si la latence dépasse 200 millisecondes. » Un critère de sortie écrit évite la migration réflexe.

Pour comparer des moteurs sur des critères objectifs, il existe des bancs d'essai publics de recherche de plus proches voisins qui mesurent une quarantaine d'implémentations sur des jeux de données standard, avec le compromis rappel contre débit. Ils sont utiles pour comprendre les familles d'algorithmes, moins pour prédire vos performances, qui dépendent de vos données et de votre matériel.

Ce qu'il faut retenir

La base vectorielle est un composant d'infrastructure, pas un facteur de qualité. Le choix se joue sur le volume, la latence exigée et votre capacité à exploiter un service supplémentaire, dans cet ordre. En dessous d'un million de vecteurs, l'extension de la base de données que vous administrez déjà couvre la quasi-totalité des besoins, avec un avantage décisif : elle ne crée aucune dette d'exploitation.

La question à se poser n'est donc pas « quelle base vectorielle installer » mais « ai-je un problème que ma base actuelle ne sait pas traiter ». Tant que la réponse est non, chaque euro et chaque heure économisés sur l'infrastructure sont mieux investis dans le découpage des documents et l'évaluation de la pertinence.