Choisir et alimenter une base vectorielle

Une équipe déploie un service vectoriel spécialisé pour 12 000 fragments. Six semaines plus tard, il faut restreindre la recherche aux documents visibles par l'utilisateur connecté, et les droits vivent dans PostgreSQL. Il n'existe aucune jointure entre les deux systèmes. L'équipe finit par récupérer 200 résultats du service vectoriel, puis interroger PostgreSQL pour savoir lesquels sont autorisés, et n'en garder que trois. La latence triple, le rappel s'effondre dès qu'un utilisateur a peu de droits, et 12 000 vecteurs auraient tenu dans 50 mégaoctets de mémoire.

Le choix d'une base vectorielle est presque toujours présenté comme une question de performance de recherche. Pour la grande majorité des projets, ce n'est pas le critère décisif : en dessous de quelques millions de vecteurs, toutes les options sont assez rapides. Ce qui décide, c'est votre capacité à filtrer par métadonnées, à maintenir la cohérence entre vos vecteurs et votre source de vérité, et à supprimer proprement un document. Choisissez sur ces trois axes, pas sur un test de vitesse.