# Bases de datos vectoriales: buscar por parecido a escala

> Comparar un vector con un millón de vectores uno a uno es lento. Los índices vectoriales aproximan la búsqueda del vecino más cercano para que tarde milisegundos, a cambio de perder un poco de exactitud.

- Fuente canónica: https://www.ricardovelit.com/blog/p/bases-de-datos-vectoriales
- Nivel: intermedio · Lectura: 2 min · Publicado: 2026-09-09
- Etiquetas: vectores, rag, infraestructura
- Conviene leer antes: [que-son-los-embeddings](https://www.ricardovelit.com/blog/p/que-son-los-embeddings.md)
- Relacionados: [rag-recuperacion-aumentada](https://www.ricardovelit.com/blog/p/rag-recuperacion-aumentada.md)

---
## El problema de escala

Si tienes mil [embeddings](/p/que-son-los-embeddings), encontrar los más parecidos a una
consulta es trivial: calculas mil similitudes coseno y ordenas. Con diez millones, ya no:
diez millones de productos escalares por consulta, y cada vector tiene cientos o miles de
dimensiones.

Una base de datos vectorial resuelve exactamente eso: **responder "los k más cercanos"
sin mirar todos los vectores**.

## La idea: búsqueda aproximada

No existe atajo exacto para el vecino más cercano en alta dimensión. Lo que existe son
índices que **aproximan** la respuesta: devuelven casi siempre los mismos vecinos que la
búsqueda exhaustiva, en una fracción del tiempo. Se llama *ANN* (*Approximate Nearest
Neighbor*), y el intercambio es explícito:

```text
más velocidad  ⇄  algo menos de exactitud (recall)
```

Un recall del 95 % significa que, de los 10 vecinos verdaderos, el índice encontró 9 o
10. Para RAG es más que suficiente; para deduplicación exacta, puede que no.

## Dos familias de índices

| Índice | Cómo funciona | Cuándo |
| --- | --- | --- |
| **HNSW** | Un grafo de capas: arriba, pocos nodos y saltos largos; abajo, todos los nodos y saltos cortos. La búsqueda desciende afinando. | El estándar hoy. Rápido, buen recall, más memoria. |
| **IVF** | Agrupa los vectores en celdas (clusters). Solo se buscan las celdas más cercanas a la consulta. | Colecciones enormes donde la memoria manda. |

Ambos tienen perillas (cuántos vecinos por nodo, cuántas celdas visitar) que mueven el
punto en la balanza velocidad/recall. No hay valores universales: se miden con tus datos.

## Lo que de verdad importa al elegir

- **Filtrado por metadatos.** "Los 5 más parecidos *entre los documentos del cliente X*".
  Filtrar antes de buscar reduce el recall; filtrar después puede dejarte sin resultados.
  Cómo lo resuelve cada motor es la diferencia práctica más grande.
- **Actualizaciones.** Algunos índices se degradan al insertar y borrar mucho; otros se
  reconstruyen por lotes.
- **¿Necesitas una base nueva?** Postgres con `pgvector`, SQLite con extensiones o incluso
  un archivo en memoria cubren hasta cientos de miles de vectores. Una base dedicada se
  justifica por volumen o por operaciones, no por moda.

## Un cálculo honesto

```text
Vectores:  100 000
Dimensión: 1 536 (float32 → 6 KB por vector)
Memoria:   ~600 MB de vectores + índice
```

Cien mil documentos caben en la RAM de un portátil. Muchos proyectos que "necesitan una
base vectorial" están muy por debajo de eso.

## Para llevarte

Una base vectorial es un **índice de vecinos aproximados con filtros**. Elige por cómo
filtra y cómo actualiza, no por el benchmark de velocidad. Y antes de desplegar una, mide
si tu tamaño la necesita: el grafo de este hub se calcula entero en el build, sin ninguna.