Elegir y alimentar una base de datos vectorial

Un equipo despliega un servicio vectorial especializado para 12 000 fragmentos. Seis semanas después, hay que restringir la búsqueda a los documentos visibles para el usuario conectado, y los permisos viven en PostgreSQL. No existe ninguna unión (join) entre ambos sistemas. El equipo acaba recuperando 200 resultados del servicio vectorial, consultando después PostgreSQL para saber cuáles están autorizados y quedándose solo con tres. La latencia se triplica, la exhaustividad (recall) se desploma en cuanto un usuario tiene pocos permisos, y 12 000 vectores habrían cabido en 50 megabytes de memoria.

La elección de una base de datos vectorial se presenta casi siempre como una cuestión de rendimiento de búsqueda. Para la gran mayoría de los proyectos, no es el criterio decisivo: por debajo de unos pocos millones de vectores, todas las opciones son lo bastante rápidas. Lo que decide es su capacidad para filtrar por metadatos, para mantener la coherencia entre sus vectores y su fuente de verdad, y para eliminar limpiamente un documento. Elija según estos tres ejes, no según una prueba de velocidad.