Base de datos vectorial: qué es y cómo funciona

Una base de datos vectorial es un sistema que almacena embeddings junto con identificadores y metadatos, construye un índice para buscar vecinos cercanos y devuelve elementos semánticamente similares a un vector de consulta. Puede ser un producto especializado o una capacidad añadida a un buscador o base tradicional; guardar vectores no basta sin estrategia de recuperación, filtros y evaluación.

Actualizado: 13 de julio de 2026.

Cómo funciona una base de datos vectorial

Una base de datos vectorial transforma una consulta en un problema de vecinos cercanos. El flujo habitual es:

1. dividir o seleccionar los elementos que se van a indexar;
2. convertir cada elemento en un embedding con un modelo concreto;
3. guardar vector, contenido, identificador y metadatos;
4. construir un índice de búsqueda exacta o aproximada;
5. convertir la consulta con un modelo compatible;
6. recuperar los k vecinos más cercanos;
7. aplicar filtros, re-ranking o búsqueda híbrida antes de consumirlos.

La documentación de búsqueda vectorial de Microsoft explica que la consulta y los documentos deben vivir en el mismo espacio de embeddings. Si se indexa con un modelo y se consulta con otro incompatible, las coordenadas ya no representan la misma geometría y la cercanía pierde significado.

Qué almacena realmente

Una entrada útil contiene más que una lista de números:

{
  "id": "manual-42#seccion-3",
  "vector": [0.014, -0.091, 0.227],
  "texto": "Las devoluciones se aceptan durante 30 días...",
  "metadata": {
    "tenant_id": "acme",
    "idioma": "es",
    "version": 7,
    "permiso": "soporte"
  }
}

El vector sirve para ordenar similitud; el ID permite rastrear la fuente; el texto aporta el contenido recuperable; los metadatos aplican filtros y control de acceso. En producción también conviene conservar el modelo de embedding, su versión, la fecha y el hash del documento para reindexar sin mezclar espacios incompatibles.

Búsqueda exacta y aproximada

KNN significa k-nearest neighbors: devuelve los k elementos más cercanos. Los algoritmos ANN sacrifican algo de exactitud para buscar más rápido. HNSW organiza los puntos en un grafo con atajos jerárquicos; parámetros de construcción y consulta cambian el equilibrio entre recall, latencia y memoria.

La búsqueda exhaustiva sigue siendo valiosa en conjuntos pequeños y para crear una referencia con la que medir el recall del índice aproximado. “Más rápido” no significa “mejor” si el sistema deja fuera el documento que contiene la respuesta.

Métricas de similitud

La métrica debe ser compatible con el modelo y la normalización usados. No elijas un umbral copiando el valor de otro sistema: incluso proveedores distintos pueden transformar la puntuación antes de devolverla. Calibra límites con consultas etiquetadas de tu dominio.

Base vectorial, índice vectorial y vector store

Los términos se usan de forma flexible:

• índice vectorial suele referirse a la estructura que acelera búsqueda por vecinos;
• vector store puede ser cualquier almacenamiento accesible por similitud;
• base de datos vectorial suele añadir persistencia, actualizaciones, filtros, replicación y APIs;
• motor de búsqueda puede combinar texto, vectores, facetas y ranking;
• extensión vectorial incorpora tipos e índices a una base relacional o documental.

Por eso “necesitamos una vector database” todavía no es un requisito técnico. Primero especifica volumen, frecuencia de actualización, aislamiento por cliente, filtros, consistencia, copias, latencia, recall y entorno operativo.

Base de datos vectorial vs. SQL y búsqueda textual

La similitud vectorial puede recuperar un texto conceptualmente relacionado aunque no comparta palabras. La búsqueda léxica suele ganar con códigos, nombres propios, cifras o términos exactos. Un sistema híbrido crea dos listas y puede fusionarlas con técnicas como Reciprocal Rank Fusion antes de reordenar.

Papel en un sistema RAG

En RAG, la base vectorial es una pieza del recuperador:

1. los documentos se dividen mediante chunking;
2. cada fragmento se vectoriza e indexa;
3. una pregunta genera un embedding de consulta;
4. la búsqueda devuelve candidatos autorizados;
5. un filtro o re-ranker mejora la lista;
6. el LLM recibe fragmentos y referencias;
7. el sistema verifica citas y abstiene cuando falta evidencia.

La guía qué es RAG y cómo funciona cubre el flujo completo. Una base vectorial no evita alucinaciones: puede recuperar contenido irrelevante, desactualizado o mal autorizado, y el modelo todavía puede interpretarlo mal.

Filtros y permisos

El control de acceso debe aplicarse durante o antes de la recuperación, no solo después de que el LLM vea el texto. Si dos empresas comparten índice, cada registro necesita un tenant_id verificable y la consulta debe imponerlo desde el servidor.

Prueba específicamente:

• filtros antes y después de ANN;
• comportamiento cuando un filtro deja pocos candidatos;
• documentos que cambian de permiso;
• borrado y reindexación;
• resultados entre clientes distintos;
• registros huérfanos o duplicados.

Un prompt que dice “no reveles datos de otros usuarios” no sustituye el aislamiento en la capa de recuperación.

Cómo elegir una solución

Evalúa con una carga representativa:

No compares solo consultas por segundo en un benchmark del proveedor. La forma del corpus, la dimensión, los filtros y el patrón de actualizaciones afectan el resultado.

Cómo evaluar la recuperación

Construye un conjunto de preguntas con documentos relevantes anotados y mide:

• Recall@k: proporción de relevantes recuperados entre los primeros k;
• Precision@k: proporción de recuperados que sí son relevantes;
• MRR: premia que el primer resultado relevante aparezca pronto;
• nDCG: considera relevancia graduada y posición;
• latencia p50/p95 y tasa de error;
• frescura después de altas, cambios y borrados;
• cobertura y violaciones de permisos;
• coste por consulta y por millón de vectores.

Después evalúa la respuesta final por separado. Una respuesta correcta puede ocultar una recuperación débil, y una buena recuperación puede terminar en una respuesta incorrecta.

Cuándo no hace falta

Evita añadir otra infraestructura si el corpus cabe en memoria, las consultas son exactas, un índice textual resuelve el caso o tu base actual ya ofrece el rendimiento necesario. Para decenas o cientos de fragmentos, una comparación exhaustiva puede ser simple, exacta y suficiente.

También conviene posponer la decisión si aún no existe un conjunto de evaluación. Cambiar de motor sin medir recuperación solo desplaza el problema. Primero valida embeddings, fragmentación, metadatos y consultas; después optimiza la infraestructura que resulte limitante.

Fuentes oficiales y técnicas

• Microsoft Learn — Relevance in vector search.
• Microsoft Learn — Create a vector index.
• Microsoft Learn — Create a vector query.