Dentro de las bases de datos vectoriales: IVF, árboles, HNSW y cuantización de productos

Términos como RAG, bases de datos vectoriales, recuperación de información y fragmentación se mencionan constantemente, y suenan más complejos de lo que son en realidad. Este artículo comienza con las bases de datos vectoriales: qué almacenan y cómo funciona realmente la búsqueda dentro de ellas.

De dónde provienen los vectores

Los modelos de embedding, entrenados con enormes colecciones de texto, convierten el significado de una oración en una lista de números. Algunos están alojados en la nube, como los embeddings de texto de OpenAI y los modelos de embedding Gemini de Google. Otros se ejecutan localmente, como la familia de embeddings Qwen3 en tamaños de 8B, 4B y 0.6B, o el modelo de texto v5-small de Jina con aproximadamente 677 millones de parámetros. Al pasar tu texto por uno de ellos, el resultado es un vector que puedes almacenar y recuperar posteriormente.

El vocabulario

Un puñado de términos aparecen repetidamente en todas las bases de datos vectoriales:

• Colección. Un espacio de nombres que contiene puntos que comparten una dimensionalidad fija y una métrica de distancia.
• Punto. Un vector junto con su ID y un conjunto de metadatos.
• Métrica de distancia. La forma en que se mide la cercanía, generalmente la similitud coseno, el producto escalar o la distancia euclidiana.
• Upsert. La operación que inserta datos, añadiendo nuevos puntos y actualizando los existentes.
• Búsqueda. La operación de consulta para la cual existe todo lo demás.

La intuición: exacto versus aproximado

La forma ingenua de encontrar los vectores relacionados con una consulta entre 10,000 o más es calcular la similitud de coseno con cada vector almacenado y conservar los k mejores. El resultado es el conjunto de vecinos más cercanos exactos. Sin embargo, con millones de vectores, ese análisis por fuerza bruta deja de ser práctico debido a las limitaciones de memoria y tiempo. Por eso, los sistemas pasaron a utilizar búsquedas de vecinos más cercanos aproximados (ANN), que aceptan una pequeña pérdida de precisión a cambio de una gran ganancia en velocidad.

Ese compromiso se puede lograr de dos maneras principales. El indexado reduce la cantidad de comparaciones necesarias. La cuantización disminuye el costo de cada comparación. Juntos, constituyen la herramienta básica para las búsquedas de vecinos más cercanos aproximados.

Indexado, primera opción: clustering con IVF

Un índice de archivo invertido (IVF) divide los vectores en clústeres, cada uno con un centroide. Primero se compara la consulta únicamente con los centroides. Una vez encontrado el clúster más cercano, la consulta se compara solo con los vectores de ese clúster, y se seleccionan los k mejores resultados.

Las debilidades que conviene conocer son:

• Se pasan por alto los vecinos cercanos a los bordes de la celda. Si la coincidencia real se encuentra en una celda que no se examinó, nunca se detectará. Revisar más celdas ayuda, pero ralentiza la búsqueda y socava su objetivo.
• La calidad disminuye a medida que cambian los datos. Los clústeres se fijan en el momento de su creación, por lo que los nuevos datos siguen terminando en celdas antiguas, y la calidad de la búsqueda empeora. Se requieren reconstrucciones periódicas.

Los clústeres irregulares hacen que la velocidad sea impredecible. Algunas celdas crecen enormemente mientras que otras permanecen pequeñas, por lo que una consulta que llega a una celda grande es lenta y una que llega a una celda pequeña es rápida.

Requiere datos de entrenamiento previos. El índice no puede crearse hasta que existan suficientes datos para formar clústeres significativos, lo cual resulta problemático para aplicaciones que comienzan desde cero.

Hay dos parámetros difíciles de ajustar. Tanto la cantidad de clústeres como el número de elementos buscados por consulta afectan los resultados, y valores incorrectos hacen que la búsqueda sea lenta o inexacta.

Las altas dimensiones difuminan los clústeres. Con vectores muy largos, los clústeres se vuelven poco definidos, por lo que la precisión por unidad de trabajo queda por debajo de la de HNSW.

En una frase: la IVF es sencilla y ahorra memoria, pero pierde precisión cerca de los límites y no soporta actualizaciones frecuentes, por lo que brilla a escala de mil millones cuando se combina con cuantización de productos, mientras que HNSW gana en búsquedas en tiempo real de alta precisión.

Indexación, segunda opción: particionamiento basado en árboles

La indexación basada en árboles toma prestada la idea de la búsqueda binaria. En lugar de comparar la consulta con cada vector, el espacio se divide repetidamente por la mitad, y solo se examina la mitad que contiene la consulta.

Para construir el índice, se toma todo el espacio y se divide con una línea divisoria; luego se divide cada mitad nuevamente, continuando hasta que cada región pequeña contenga solo unos pocos vectores. Cada región es una hoja. En dos dimensiones, la primera división podría hacerse a lo largo del eje x, la siguiente a lo largo del eje y, y así sucesivamente. Todas estas divisiones forman un árbol binario en el cual cada nodo representa una pregunta de tipo sí o no, como por ejemplo si x es menor que 5, y las hojas se encuentran en la parte inferior.

Cuando llega una consulta, se parte de la raíz y se responde una pregunta a la vez: ¿a la izquierda de esta división o a la derecha? Cada respuesta descarta la mitad del espacio restante. Después de aproximadamente log n preguntas, unas 20 para un millón de vectores, se llega a una pequeña hoja y se compara la consulta con los pocos vectores que contiene.

Hay un problema. El verdadero vecino más cercano podría encontrarse justo al otro lado de una línea divisoria, a poca distancia pero en otra hoja, y un único árbol nunca lo detectaría. Por eso, bibliotecas como Annoy de Spotify crean muchos árboles, cada uno con divisiones aleatorias diferentes. Cada árbol propone candidatos, se fusionan las propuestas y se devuelven las mejores. Lo que un árbol pasa por alto, otro suele detectarlo.

Las desventajas:

• El problema de los límites es peor que en IVF. En IVF, no detectar un límite significa verificar una celda más. En un árbol, tomar un camino equivocado cerca de la cima envía la búsqueda a una región completamente diferente.
• La solución consume memoria y velocidad. Un bosque de 50 árboles implica almacenar el índice 50 veces y realizar búsquedas 50 veces por consulta, lo que permite obtener precisión a costa de recursos.
• Los vectores largos lo superan. Los árboles funcionan bien en 2D, 3D, mapas y juegos. Los embeddings modernos tienen cientos o miles de dimensiones, donde una línea divisoria casi no separa nada de manera significativa, ya que los puntos en lados opuestos pueden estar casi a la misma distancia. Esa es la razón principal por la cual este método dejó de usarse para la búsqueda de embeddings.
• El índice es estático. Los árboles se construyen una sola vez a partir de datos existentes y no pueden aceptar nuevos vectores de manera sencilla. Por ejemplo, Annoy necesita una reconstrucción completa para agregar datos, lo cual resulta inadecuado para colecciones que cambian con frecuencia.
• En general, está superado. A igual precisión, HNSW es más rápido, y a igual memoria, IVF con cuantización por producto permite escalar aún más. Los árboles siguen utilizándose principalmente en sistemas heredados y en aquellos donde son importantes los archivos de índice pequeños que se pueden mapear en memoria.

En resumen, los árboles son sencillos y fáciles de crear, pero las incrustaciones de alta dimensión disuelven sus divisiones y no permiten actualizaciones, por lo que hoy en día sirven principalmente como paso intermedio para la explicación y no como opción para uso en producción.

Indexación, tercera opción: HNSW

Hierarchical Navigable Small Worlds, o HNSW, es la técnica que subyace a la mayoría de las bases de datos vectoriales. Organiza los vectores en un grafo con varios niveles. Las capas superiores contienen solo unos pocos vectores con enlaces a larga distancia, como autopistas entre ciudades, mientras que las capas inferiores albergan progresivamente más vectores con enlaces más cortos, hasta llegar a la capa inferior que contiene todos los vectores.

La búsqueda comienza en la capa superior y se desplaza con avidez hacia el vecino más cercano a la consulta. Cuando no hay ningún vecino más cercano, baja un nivel y repite el proceso desde allí, utilizando enlaces más detallados. En la capa inferior, explora un área más amplia y devuelve las mejores coincidencias. Los saltos largos recorren grandes distancias rápidamente, mientras que los saltos cortos perfeccionan la respuesta; por eso la cantidad de comparaciones se mantiene baja incluso con colecciones enormes.

Algunos parámetros controlan el equilibrio entre velocidad y precisión:

• M determina cuántos enlaces mantiene cada vector. Más enlaces mejoran la precisión y la capacidad de recuperación, pero consumen más memoria.
• efConstruction establece cuán amplia debe ser la búsqueda de candidatos durante la construcción del grafo. Valores más altos generan un grafo de mejor calidad, pero su construcción es más lenta.

efSearch determina cuán amplia será la lista de resultados en el momento de la consulta. Aumentarlo eleva tanto la precisión como la latencia.

Al observar cómo una consulta atraviesa las diferentes capas y cómo estos ajustes influyen en su recorrido, se comprende cómo cambiarlos modifica el comportamiento de la búsqueda.

Cuantización: hacer que cada comparación sea más económica

El indexado reduce la cantidad de comparaciones necesarias. La cuantización disminuye el costo de cada una de ellas. Un vector de 1536 dimensiones compuesto por flotantes de 32 bits ocupa 1536 veces 4, es decir, 6144 bytes. Para mil millones de vectores, eso significa terabytes de almacenamiento, mucho más de lo que cabe en la RAM.

Cuantización de producto

La cuantización de productos divide cada vector grande en segmentos más pequeños de tamaño igual. Un vector de 16 dimensiones podría convertirse, por ejemplo, en cuatro segmentos de cuatro dimensiones cada uno. Para cada posición de segmento, se entrena un libro de códigos con los datos almacenados, que contiene 256 entradas, cada una representando un subvector típico. Luego, cada segmento se reemplaza por el número de la entrada del libro de códigos más cercana, lo cual solo requiere un byte.

Así, un vector que ocupaba miles de bytes se convierte en una cadena corta de pequeños enteros. Para realizar búsquedas, la consulta se divide de la misma manera, y las distancias hasta las entradas del libro de códigos se calculan una sola vez y se reutilizan mediante búsquedas para cada vector almacenado. El cálculo es altamente aproximado, pero la mejora en velocidad y el ahorro de memoria son significativos.

Elegir entre ellas

Una comparación rápida resume todo:

• IVF es sencillo y requiere poca memoria. Úsalo junto con la cuantización de productos para colecciones estáticas muy grandes.
• Árboles son fáciles de entender y económicos de crear, pero son adecuados para dimensiones bajas y datos que no cambian.
• HNSW ofrece alta precisión y búsquedas en tiempo real rápidas, pero a costa de más memoria.
• Cuantización de productos comprime los vectores y acelera los cálculos de distancia, con una pérdida controlada de precisión, y se combina con los índices anteriores.

Conocer estos compromisos te ayuda a decidir cuándo es apropiada una búsqueda aproximada, qué algoritmo se adapta a una carga de trabajo y cuándo la fuerza bruta sigue siendo la respuesta adecuada, como en colecciones pequeñas donde la exactitud no cuesta mucho.

Leer más

• Depura la pipeline, no el LLM: un modelo mental para los fallos en RAG — Cuando un bot RAG da respuestas incorrectas, rara vez es el modelo el culpable. Rastrea los fallos a través de las etapas de ingestión, recuperación, generación, evaluación y bucles de agente para identificar la capa defectuosa.
• Notas prácticas: Los límites de la búsqueda vectorial en RAG — Similitud coseno y — Guía práctica de Notas prácticas: Los límites de la búsqueda vectorial en RAG — Similitud coseno y: contratos, verificaciones y espacios de código listos para usar para los equipos que implementan este patrón.