Qué hace una base de datos vectorial, y por qué seguimos en Postgres

Todos los tutoriales para armar un asistente de IA empiezan igual: elige una base de datos vectorial. Se presenta como la primera decisión, el cimiento, lo que no puedes equivocar.

Para casi todos los que leen esos tutoriales es la decisión menos importante que van a tomar. Nosotros servimos la recuperación de cada workspace de WelcomeAI desde PostgreSQL con una extensión vectorial, y vale la pena escribir los motivos, porque son motivos que puedes contrastar con tu propia situación en lugar de una preferencia.

Qué hace realmente esa pieza

Sin el marketing, una base de datos vectorial hace cuatro trabajos.

Guarda una lista de números junto a cada fragmento de texto, el embedding. Indexa esas listas para que encontrar las más cercanas no implique compararlas contra todas las filas. Busca, devolviendo los vecinos más cercanos al embedding de la consulta. Y filtra, para que una búsqueda se limite a un workspace, a una base de conocimiento, a un idioma.

Tres de esos cuatro trabajos los hace una base relacional desde siempre. El interesante es el índice, porque una búsqueda ingenua de vecinos compara tu pregunta contra cada vector guardado, y eso se pone lento justo cuando tu corpus se pone interesante.

Los índices especializados lo resuelven siendo aproximados a propósito: miran una fracción de los candidatos y aceptan una probabilidad pequeña de perderse la coincidencia más cercana a cambio de velocidad. Ese canje, exhaustividad contra latencia, es el producto que vende una base vectorial. Las extensiones de Postgres implementan los mismos tipos de índice; un sistema dedicado te da más perillas y más herramientas alrededor.

¿Necesitas una?

Fíjate que dos de las tres condiciones son de escala y la tercera es de equipo. Ninguna tiene que ver con si estás "haciendo bien la IA".

Qué pierdes al sumar una

Esta es la parte que los tutoriales se saltean, y es la razón de nuestra elección.

Un almacén vectorial aparte significa que tu texto vive en un sistema y sus embeddings en otro, y nada obliga a que coincidan. Borras un documento en la base y los vectores siguen ahí hasta que algún proceso los elimine. Ese proceso falla una noche, y tu asistente responde desde una página que ya no existe, con total seguridad y citando un enlace muerto.

En una sola base esa clase de error no existe. Un fragmento pertenece a un documento por una clave foránea, borrar el documento se lleva sus fragmentos en la misma transacción, y un backup es un backup de todo. Para un producto donde la falla que más duele es una respuesta vieja, esa consistencia vale más que un índice más rápido que no notaríamos.

De ahí se desprenden dos cosas más. La recuperación híbrida, que corre búsqueda por significado y por palabras clave a la vez, ocurre en una consulta y en un solo lugar en vez de entre dos sistemas. Y filtrar por workspace es una condición de esa misma consulta, que es como debería verse el aislamiento multi-tenant.

Para qué cree la gente que la necesita

Aparecen tres cosas en casi toda conversación, y ninguna es un problema de base de datos.

Las respuestas que citan la página equivocada suelen ser un problema de fragmentación o de contenido. Las respuestas lentas suelen ser el modelo escribiendo, no la búsqueda encontrando. Y un asistente que no sabe algo que debería saber casi siempre no tiene ese contenido, no le falta índice. Cambiar de base no arregla ninguna de las tres, que es la forma cara de descubrir que nunca fueron la causa.

Preguntas frecuentes

Si estás en el principio de esto, dedica la tarde que ibas a usar comparando bases vectoriales a tu contenido. La base es lo más fácil de cambiar después, y el contenido es lo que decide si algo de esto responde bien.