Una base de datos vectorial está diseñada para guardar representaciones numéricas y localizar registros próximos según una medida de similitud. Su utilidad no consiste en almacenar “significado” de forma legible, sino en hacer búsquedas sobre un espacio de vectores acompañado de información que la aplicación sí pueda interpretar.
Este tipo de almacenamiento suele aparecer en buscadores semánticos y sistemas RAG, pero no es sinónimo de RAG. Puede servir para recomendar documentos, localizar imágenes parecidas o detectar agrupaciones sin que exista un modelo generativo en la arquitectura.
Qué guarda realmente
Un registro vectorial suele incluir un identificador, el vector, el texto u objeto asociado y metadatos. El vector procede de un modelo de embeddings y sus dimensiones dependen de ese modelo. Los metadatos pueden indicar idioma, producto, propietario, versión, fecha o permisos.
Separar el vector del contenido original es importante. La similitud puede decir que dos registros están próximos, pero la interfaz necesita recuperar el texto, la imagen o el documento que corresponde al resultado. Si solo se conserva el vector, la búsqueda puede funcionar y aun así ser imposible de explicar.
Cómo se calcula la proximidad
La consulta también se transforma en un vector. El motor compara esa representación con las almacenadas mediante una función como distancia coseno, producto escalar o distancia euclídea, según el modelo y la configuración. El resultado no es una verdad universal: expresa una relación dentro del espacio construido por un modelo concreto.
Dos textos con palabras diferentes pueden quedar cerca y dos frases con vocabulario parecido pueden quedar lejos si el contexto cambia. Por eso la similitud debe validarse con ejemplos del dominio. Una puntuación alta no sustituye la revisión de relevancia.
Índices y filtros
Comparar una consulta con todos los vectores puede resultar costoso cuando el conjunto crece. Los índices de búsqueda aproximada reducen el trabajo buscando en una estructura preparada para localizar vecinos cercanos. A cambio, pueden introducir una pequeña diferencia frente a una comparación exhaustiva y requieren ajustar memoria, construcción y actualización.
Los filtros de metadatos resuelven otra parte del problema. Una empresa puede buscar solo entre documentos de un cliente, una versión concreta o un idioma. En un asistente de documentación, filtrar por permisos antes de devolver resultados es una condición de seguridad, no una mejora cosmética de relevancia.
El ciclo de vida de los registros
Insertar datos implica generar el embedding y guardar la correspondencia con la fuente. Actualizar un documento exige decidir si se reemplaza el vector, si se conserva un historial o si se marca la versión anterior como no vigente. Borrar solo el texto y dejar el vector huérfano puede producir resultados que ya no deberían aparecer.
La persistencia debe formar parte del diseño. Hay que conocer dónde se almacenan los datos, cómo se hacen copias, cómo se restaura el índice y qué ocurre si la reconstrucción requiere volver a generar miles de embeddings. La base vectorial puede ser crítica aunque el contenido original esté en otro sistema.
Escala, concurrencia y coste
El tamaño de los vectores, la cantidad de registros, el número de consultas y la frecuencia de cambios afectan al consumo. Un índice pequeño puede caber cómodamente en memoria; otro con alta concurrencia puede necesitar particionado, réplicas o una estrategia de caché. Añadir almacenamiento no resuelve por sí solo una consulta mal formulada o un modelo de embeddings inadecuado.
También existe un coste de mantenimiento: reindexación, control de versiones, monitorización y pruebas de calidad. El equipo debe medir tiempo de respuesta, tasa de resultados irrelevantes y errores de ingestión, no únicamente el tamaño del índice.
Cuándo combinarla con una base relacional
Las bases relacionales siguen siendo apropiadas para relaciones exactas, transacciones, restricciones e informes estructurados. Una aplicación puede usar una consulta SQL para restringir el conjunto permitido y una búsqueda vectorial para ordenar los candidatos por proximidad semántica. No es necesario convertir todos los datos en vectores.
Por ejemplo, una consulta sobre manuales puede filtrar por producto y versión mediante metadatos o SQL, y después buscar los fragmentos más próximos. Esa separación permite que la política de acceso y la información operativa sigan dependiendo de controles deterministas.
Cuándo aporta valor una búsqueda vectorial
Es una buena candidata cuando las consultas expresan una intención con palabras variables y existe un conjunto de objetos que conviene relacionar por contenido. Antes de adoptarla, compara sus resultados con una búsqueda por palabras clave y define cómo se revisarán los falsos positivos. La similitud vectorial es una herramienta de recuperación, no una garantía de que el resultado sea el correcto.
Calidad de los datos antes que complejidad del índice
Un índice sofisticado no corrige un contenido mal segmentado. Si cada registro pierde el título, el idioma o la relación con su documento original, el motor puede devolver vecinos cercanos que resultan difíciles de interpretar. Conviene conservar un identificador estable y poder reconstruir el registro desde la fuente.
Las pruebas deberían incluir consultas equivalentes con redacciones distintas, términos ambiguos y preguntas para las que no existe ningún documento pertinente. El resultado esperado no siempre es un registro: a veces es detectar que la colección no contiene evidencia suficiente.
Consistencia entre texto, vector y metadatos
Una actualización parcial genera problemas sutiles. Si se cambia el texto pero se conserva el vector antiguo, la proximidad se calcula sobre una versión distinta de la que se muestra al usuario. Si se actualiza el vector y no los metadatos, un filtro por fecha o producto puede dejar de representar la realidad. Las operaciones de escritura deben tratar esas piezas como una unidad lógica.
También hay que definir cómo se comportan las copias de seguridad y las restauraciones. La base puede reconstruirse desde documentos originales, pero esa reconstrucción requiere el mismo modelo o una nueva evaluación. Documentar el modelo, la configuración del índice y la fecha de carga evita confundir una restauración con una reindexación diferente.
Comparar con una búsqueda convencional
Una prueba honesta enfrenta búsqueda vectorial, palabras clave y una combinación de ambas con el mismo conjunto de consultas. Las palabras clave suelen destacar identificadores exactos y términos raros; los vectores pueden ayudar con paráfrasis. Un sistema híbrido puede aprovechar las dos señales, aunque también necesita una forma clara de ordenar resultados y resolver conflictos.