¿Estamos en el pico de las bases de datos vectoriales?
En medio de un auge de herramientas para almacenar y buscar embeddings generados por IA, muchos ingenieros cuestionan si las “bases de datos vectoriales” especializadas son excesivas para la mayoría de los usos reales, donde los volúmenes de datos son modestos y la búsqueda por fuerza bruta en RAM o extensiones de PostgreSQL como pgvector funcionan bien. Los comentaristas sostienen que la búsqueda por similitud coseno es solo una función que las bases de datos tradicionales probablemente absorberán, y que los problemas más difíciles y valiosos están en el ajuste fino de modelos, la búsqueda híbrida léxico-vectores y las cuestiones operativas como la regeneración de embeddings y la escala. Hay un amplio escepticismo sobre las perspectivas a largo plazo de numerosas startups de bases de datos vectoriales, junto con el acuerdo de que la búsqueda vectorial sigue siendo importante, aunque todavía no es una tecnología totalmente “resuelta”.
Alcance y necesidad de las bases de datos vectoriales
- Muchos sostienen que la mayoría de los casos de uso actuales de RAG y de “copilot” son lo bastante pequeños como para que la búsqueda por fuerza bruta sobre vectores en memoria (NumPy, PyTorch, Pandas, Parquet+FAISS) sea suficiente hasta ~100k–1M filas, y a veces más.
- Las bases de datos vectoriales solo se vuelven convincentes a escalas mayores (millones–miles de millones de vectores), con requisitos estrictos de latencia/QPS, o cuando los datos no caben en RAM.
- Varios señalan que calcular embeddings (especialmente con modelos basados en LLM) es órdenes de magnitud más costoso que la similitud coseno, por lo que la consulta rara vez es el cuello de botella principal en las etapas iniciales.
- Otros replican que esto subestima las consultas repetidas, los costes de indexación y la presión de memoria al almacenar grandes cantidades de vectores.
Postgres, extensiones y la visión de “función, no producto”
- Existe una fuerte sensación de que la búsqueda vectorial es una “función” que será absorbida por las bases de datos convencionales (Postgres, MySQL, etc.), como ocurrió con JSON, OLAP, grafos y los almacenes de documentos.
- pgvector (y extensiones similares como Lantern, SQLite VSS) se considera “suficientemente bueno” para muchos sistemas de producción hasta millones de documentos, con mejoras recientes como construcciones de índices multihilo.
- Algunas personas ven a las bases de datos vectoriales dedicadas como carentes de un foso defensivo duradero y probablemente desplazadas a medida que los RDBMS tradicionales amplíen sus capacidades vectoriales y la búsqueda híbrida.
Limitaciones algorítmicas y de investigación
- La ANN / indexación vectorial se describe todavía como un área de investigación abierta con compromisos insatisfactorios; a diferencia de los B-tree, los métodos actuales son aproximados y frágiles en altas dimensiones.
- La búsqueda de máximo producto interno se destaca como incluso más difícil que la ANN estándar debido a una geometría poco aprovechable y a distribuciones de consulta frente a índice que difieren.
- Se discuten la distancia coseno frente a la distancia euclídea en altas dimensiones, y el comportamiento de los embeddings como compresión con pérdida / hashes perceptuales.
Más allá de “similitud coseno como servicio”
- Varios ven la “búsqueda de similitud coseno como servicio” como una commodity o algo exagerado; el trabajo más difícil y valioso es:
- Ajustar finamente modelos de embeddings para consultas específicas de dominio.
- Gestionar el ciclo de vida de los embeddings: volver a generarlos cuando cambian los modelos, almacenamiento y recomputación.
- Recuperación híbrida: combinar lo léxico (BM25), filtros de metadatos y vectores, además de ranking.
- Preprocesamiento para RAG: dividir en fragmentos, añadir hechos inferidos o pares de preguntas y respuestas, usar LLMs para enriquecer documentos antes de generar embeddings.
Hype de mercado y direcciones futuras
- Las opiniones difieren sobre si estamos en el “pico” de las bases de datos vectoriales o solo en una fase temprana de fiebre del oro.
- Muchos esperan consolidación: capacidades vectoriales dentro de plataformas LLM y bases de datos, además de unos pocos servicios de nivel superior tipo “Algolia para RAG” que oculten la complejidad del troceado y la indexación.
- Se señala la búsqueda vectorial en dispositivo / edge (por ejemplo, para búsqueda privada de fotos) como un área emergente pero todavía desatendida.