Por Qué los Vectores Necesitan una Base de Datos Dedicada
Los embeddings son arrays de flotantes de alta dimensión (384–1536 dimensiones). Una base de datos SQL puede almacenarlos pero no buscarlos: “encuentra las 5 filas más similares” significa calcular la distancia a cada fila: un escaneo completo. Las bases de datos vectoriales especializan en esto con índices de vecino más cercano aproximado (ANN) que responden en milisegundos sobre millones de vectores.
| Propiedad | SQL | Vector DB |
|---|---|---|
| Búsqueda | WHERE, índices por claves | Similitud en espacio de embeddings |
| Consulta “más cercano” | No nativo | Nativo, milisegundos |
| Filtros | De primera | Aplicados alrededor del ANN |
| Metadatos + vectores | Aproximado | Diseñado juntos |
Métricas de Similitud
| Métrica | Cuándo usar |
|---|---|
| Similitud coseno | Por defecto para embeddings de texto normalizados |
| Distancia euclidiana | Cuando la magnitud carga significado |
| Producto punto | Optimizado, funciona con vectores normalizados |
Para embeddings normalizados, la similitud coseno y el producto punto coinciden: la elección de métrica es una decisión de velocidad vs interpretabilidad.
Búsqueda Exacta vs Aproximada
El k-NN exacto escanea todo (O(n)) — bien para miles de vectores, imposible para millones. Los índices ANN comercian una pequeña cantidad de recall por órdenes de magnitud de velocidad: en lugar de garantizar el top-k verdadero, devuelven el casi top-k. Dos diseños dominantes:
HNSW: Un Grafo de Múltiples Niveles
El HNSW construye capas de grafos de vecinos. La búsqueda comienza en una capa dispersa superior, desciende greedy y se acerca a la capa densa inferior con los verdaderos vecinos más cercanos. El resultado: tiempo de búsqueda logarítmico con excelente recall.
- M (conexiones por nodo) — M mayor = mejor recall, más memoria.
- efSearch — más candidatos examinados = mejor recall, más lento.
IVF: Índice por Archivo Invertido
El IVF agrupa los vectores (k-means) y almacena cada vector con su cluster. La búsqueda solo sondea los clusters más cercanos a la consulta, reduciendo el espacio de búsqueda. Añade PQ (cuantización por productos) para comprimir vectores y ahorrar memoria. El IVF es ligero en memoria y bien entendido; el HNSW suele ser más rápido con un mayor coste de memoria.
Búsqueda Híbrida y Filtrado
Las consultas reales mezclan similitud y estructura: “documentos sobre reembolsos de los últimos 30 días”. La búsqueda híbrida combina similitud vectorial con palabras clave (BM25) y/o filtros de metadatos. Una base de datos vectorial que no pueda filtrar antes del ANN — o re-ordenar correctamente después — devuelve resultados incorrectos o escanea demasiado.
Ajuste de Recall vs Latencia
| Parámetro | Efecto |
|---|---|
| Más candidatos (efSearch / sondas) | Recall ↑, latencia ↑ |
| Más grande M / más clusters | Recall ↑, memoria ↑ |
| Menos clusters sondeados | Latencia ↓, recall ↓ |
No hay solución universal: elige el punto de operación que cumple tu objetivo de recall dentro del presupuesto de latencia, luego mide: nunca ajustes a ciegas.
Cuándo es la Herramienta Correcta
Una base de datos vectorial es la herramienta correcta cuando necesitas búsqueda de similitud sobre millones de embeddings con latencia baja: recuperación RAG, deduplicación semántica, recomendación por similitud, detección de anomalías. Para unos pocos miles de vectores, una búsqueda en memoria sobre un array de NumPy es más simple y barata. Elige por escala, no por defecto.
Trayectoria de Práctica
- Explica por qué un escaneo vectorial completo falla a escala de millones.
- Describe la búsqueda HNSW en tres frases.
- Elige un punto de operación de recall/latencia para un chatbot con un presupuesto de 200 ms.
- Diseña una consulta híbrida que combine similitud con un filtro temporal.
- Decide entre búsqueda en memoria y una base de datos vectorial para una wiki de 5k documentos.