Ajuste de índices HNSW y escalamiento de la búsqueda vectorial para RAG en producción

Un prototipo de generación mejorada por recuperación (RAG) con unos pocos miles de vectores responde al instante en casi cualquier configuración. A medida que la colección crece hasta alcanzar millones de elementos, la latencia y el consumo de recursos comienzan a ser un problema importante, y la configuración del índice se convierte en una cuestión crítica para el funcionamiento en producción. Esta guía aborda los dos parámetros de HNSW más importantes, cómo configurarlos en Chroma, y cómo reconocer cuándo ya no es suficiente ajustarlos y el sistema necesita escalar.

Los dos parámetros de HNSW que controlan casi todo

No es necesario conocer toda la teoría de los grafos HNSW (Hierarchical Navigable Small World) para ajustarlos. El índice conecta cada vector con vectores cercanos en varios niveles, y una consulta recorre este grafo hacia sus vecinos más próximos. Dos parámetros determinan la estructura de ese grafo y el recorrido realizado. Para más información, consulte nuestra explicación sobre cómo funcionan las bases de datos vectoriales, desde los embeddings hasta la búsqueda híbrida.

M: conexiones máximas por nodo

M establece el número máximo de enlaces a vecinos que cada nodo mantiene en el grafo.

• M bajo: menos enlaces, un índice más pequeño, menos memoria y un recorrido más rápido, pero una menor tasa de recuperación ya que la búsqueda dispone de menos rutas hacia candidatos adecuados.

Alto M: más enlaces por nodo, más memoria, un índice más grande y una construcción más lenta. Las consultas se vuelven algo más lentas, pero la capacidad de recuperación mejora porque el grafo ofrece más rutas hacia los verdaderos vecinos más cercanos.

M se fija al crear el índice, por lo que cambiarlo posteriormente implica reconstruir el índice.

ef: cuán intensa es la búsqueda

ef controla cuántos candidatos mantiene el índice en consideración mientras busca los vecinos más cercanos de una consulta.

• Bajo ef: se examinan menos candidatos, por lo que la recuperación es rápida, pero pueden pasarse por alto documentos relevantes y disminuye la precisión.
• Alto ef: se examinan más candidatos, por lo que la recuperación es más lenta, pero el conjunto de resultados está mucho más cerca de los verdaderos vecinos más cercanos.

Muchos motores dividen esto en un valor de tiempo de construcción, que controla con qué cuidado se crea el grafo, y un valor de tiempo de búsqueda que generalmente se puede cambiar sin tener que reconstruirlo, lo que lo convierte en el parámetro más económico para experimentar.

Equilibrando precisión, velocidad y memoria

La configuración de HNSW implica un compromiso entre precisión, velocidad y memoria. Estas combinaciones son puntos de partida razonables para las etapas comunes de un proyecto, donde ef representa el valor de tiempo de búsqueda:

+----------------+----+-----+----------+
| Use Case       | M  | ef  | Priority |
+----------------+----+-----+----------+
| Prototype      | 16 | 40  | Speed    |
| Production     | 16 | 100 | Balanced |
| High accuracy  | 32 | 200 | Accuracy |
+----------------+----+-----+----------+

Trátalos como puntos de referencia para hacer pruebas de rendimiento: mida la tasa de recuperación y la latencia en consultas representativas antes y después de cada cambio.

Configuración de los parámetros de HNSW en Chroma

Cada base de datos vectorial expone estos parámetros de manera diferente. En Chroma, se pueden pasar como metadatos de la colección al crearla. El ejemplo a continuación establece M en 16, el ef de tiempo de construcción en 100 y el ef de tiempo de búsqueda en 50:

#Chroma-HNSW Settings
collection=client.create_collection(
name='new_collection',
metadata={
'hnsw:M':16,
'hnsw:construction_ef': 100,
'hnsw:search_ef': 50
}
)

Este estilo de clave de metadatos puede variar en versiones más recientes de Chroma, las cuales también ofrecen un objeto de configuración dedicado; por lo tanto, consulte la documentación actual correspondiente a su versión. Establezca M y el ef de construcción antes de ingresar datos, ya que se integran directamente en el grafo.

Cuando ajustar ya no es suficiente

Incluso un índice bien ajustado eventualmente llega a su límite. Cuando la recuperación de datos tarda regularmente 100 ms o más, una causa común es que el índice ya no cabe cómodamente en la memoria, y los ajustes adicionales de parámetros no solucionarán ese problema. Una estimación aproximada ayuda: el almacenamiento de vectores en bruto corresponde al número de vectores multiplicado por sus dimensiones y luego por 4 bytes para flotantes de 32 bits, y el grafo HNSW añade una sobrecarga que crece con M. En ese punto, la solución radica en la escalabilidad, que se presenta de dos maneras.

Escalabilidad vertical

Para colecciones con un rango de aproximadamente 5 a 10 millones de vectores, añadir RAM o CPU al equipo existente suele ser el primer paso. Con suficiente memoria, todo el índice cabe en RAM, lo que restaura una recuperación rápida y mejora la eficiencia general.

La escala vertical no requiere cambios arquitectónicos ni en el código, pero una sola máquina tiene un límite de memoria, y las instancias más grandes se vuelven costosas rápidamente.

Escala horizontal

Más allá de unos 10 millones de vectores, la escala horizontal se convierte en la opción práctica. La colección se fragmenta, lo que significa que los datos se distribuyen en varias instancias, y cada fragmento almacena e investiga su propia porción.

Esto elimina el límite impuesto por una sola máquina. El precio a pagar es la complejidad: cada consulta se distribuye entre los fragmentos, y sus resultados parciales deben combinarse en una lista ordenada, lo que aumenta la latencia y el trabajo operativo.

Puntos clave

• M influye en el gráfico: valores más altos aumentan la capacidad de recuperación y el uso de memoria, y cambiarlo requiere una reconstrucción.
• ef influye en la búsqueda: aumentar el valor del tiempo de búsqueda es la forma más económica de intercambiar latencia por capacidad de recuperación.

Comience con una configuración equilibrada como M 16 con un umbral de búsqueda ef de 100, y luego realice pruebas de rendimiento con sus propias consultas.

La mayoría de los sistemas RAG en producción se arreglan con el ajuste del índice y la escalabilidad vertical; el sharding es poderoso pero rara vez necesario, así que guárdelo para colecciones que realmente superen las capacidades de una sola máquina.

Lecturas relacionadas