¿Cómo intercambia HNSW memoria por capacidad de recuperación en una base de datos vectorial local?
HNSW intercambia memoria por capacidad de recuperación al almacenar un grafo navegable de vecinos cuya conectividad y amplitud de búsqueda determinan hasta qué punto las consultas exploran los vectores cercanos.
Una base de datos vectorial local puede almacenar embeddings de documentos del hogar, texto extraído mediante OCR, metadatos de fotos, manuales, transcripciones y registros de aplicaciones. La búsqueda por fuerza bruta compara la consulta con cada vector, mientras que HNSW intenta llegar al mismo vecindario útil recorriendo un grafo en capas. Este atajo es rápido porque la base de datos almacena previamente una estructura de grafo adicional, y su precisión depende de lo densamente conectado que esté el grafo y de cuántos candidatos se permita explorar a una consulta.
HNSW añade un grafo de proximidad en capas alrededor de los vectores almacenados
Cada vector se convierte en un nodo conectado a determinados vecinos. Un pequeño subconjunto de nodos también aparece en capas superiores, creando rutas de largo alcance que ayudan a la búsqueda a desplazarse rápidamente hacia la región donde probablemente se encuentren los vectores cercanos.
Un grafo de proximidad multicapa proporciona a HNSW rutas generales en las capas superiores y una navegación progresivamente más precisa entre vecinos cerca de la base de la jerarquía.
Esas aristas almacenadas son el primer intercambio de memoria. A diferencia de un arreglo plano de vectores, el índice conserva una topología que debe estar disponible durante el recorrido.
La jerarquía reduce la cantidad de elementos de la colección que visita una consulta normal, pero es aproximada: la ruta puede no encontrar un vecino real cuando el grafo o el presupuesto de búsqueda no exponen la ruta adecuada.
El parámetro M utiliza más memoria del grafo para crear más rutas
Las implementaciones de HNSW exponen un parámetro de conectividad llamado normalmente `m` o `M`. Aumentarlo permite que los nodos mantengan más enlaces con vecinos, lo que crea rutas alternativas a través de partes densas o irregulares del espacio vectorial.
Un valor m más alto en HNSW almacena más conexiones con vecinos por nodo, lo que normalmente mejora las opciones de navegación y la capacidad de recuperación, aunque aumenta la memoria del grafo y el trabajo de construcción.
El aumento de memoria procede de las aristas del grafo y de las estructuras de índice asociadas, no de que los valores de los embeddings originales sean más grandes. Con millones de vectores, unos pocos enlaces adicionales por nodo se acumulan en toda la colección. Reducir `m` puede hacer que un servidor doméstico con memoria limitada funcione con mayor comodidad, pero un grafo excesivamente disperso ofrece menos formas de sortear los callejones sin salida locales y puede reducir la capacidad de recuperación.
La construcción de Ef utiliza más trabajo de creación para mejorar el propio grafo
La calidad del grafo también se define mientras se insertan los vectores. `ef_construct` controla la amplitud del vecindario de candidatos que examina el proceso de construcción antes de elegir los enlaces para un nodo nuevo.
Usar efConstruction como factor de calidad de construcción permite que la creación del índice examine un vecindario de candidatos más amplio antes de elegir las aristas, mejorando la calidad del grafo a costa de más trabajo durante la construcción.
Este coste se paga durante la construcción o la reconstrucción, no en cada consulta. Para un corpus privado que cambia lentamente, puede ser aceptable dedicar más tiempo a la construcción si eso mejora la calidad de búsqueda sin aumentar permanentemente la precisión de los vectores.
Sin embargo, el esfuerzo de construcción no puede compensar indefinidamente un grafo gravemente insuficiente. `m`, la amplitud de construcción, la distribución de los datos y el historial de inserciones interactúan entre sí.
Ef Search utiliza trabajo de consulta en lugar de memoria permanente del grafo
Durante la consulta, HNSW mantiene una frontera de candidatos y explora los nodos prometedores del grafo. Un parámetro llamado normalmente `ef`, `ef_search` o `hnsw_ef` controla cuántos candidatos permanecen bajo consideración durante ese recorrido.
Aumentar la amplitud de exploración de la consulta permite que una solicitud examine más candidatos del grafo antes de establecer los resultados más cercanos, lo que normalmente aumenta la capacidad de recuperación, pero también la latencia de la consulta.
A diferencia de `m`, un `ef` de consulta más grande no requiere que cada nodo almacenado conserve más aristas permanentes. Su coste principal aparece como cálculos de distancia adicionales, más accesos a memoria y mayor latencia para esa solicitud. Esta distinción proporciona a un servidor doméstico dos controles diferentes: la conectividad del grafo determina la huella persistente del índice, mientras que la amplitud de consulta puede aumentarse solo para búsquedas difíciles que justifiquen el trabajo adicional.
La compresión de vectores no elimina el coste del grafo HNSW
La cuantización de embeddings puede hacer que cada vector almacenado sea mucho más pequeño, pero HNSW sigue necesitando sus relaciones con los vecinos. Por tanto, el índice completo contiene al menos dos componentes principales de memoria: los datos vectoriales y la topología del grafo.
Incluso cuando los valores de los vectores están comprimidos, la cuantización no reduce los enlaces del grafo; HNSW sigue necesitando la topología, los identificadores y las estructuras relacionadas alrededor de esos vectores.
Por eso, una relación de compresión de vectores de 4x o superior no produce automáticamente la misma reducción general de memoria de HNSW. Las aristas del grafo, los identificadores de objetos, los metadatos, la sobrecarga del asignador de memoria y las cachés permanecen.
En un servidor doméstico pequeño, mide el conjunto residente completo de la colección en lugar de estimar la RAM únicamente a partir de las dimensiones de los vectores.
La capacidad de recuperación debe medirse frente a vecinos exactos, no inferirse a partir de la configuración
Valores más altos de `m` y `ef` suelen acercar el sistema a una mejor capacidad de recuperación, pero ningún valor de parámetro garantiza una precisión fija para todos los modelos de embeddings, tamaños de corpus o distribuciones de documentos.
El coste de la memoria de los grafos HNSW en varias colecciones RAG se acumula cuando varias colecciones privadas permanecen activas junto a modelos locales, índices de metadatos, cachés y otros servicios del servidor doméstico.
Crea un conjunto representativo de consultas y compara los resultados aproximados con un escaneo exacto en una muestra manejable. Registra la capacidad de recuperación, la latencia, la RAM del índice, el tiempo de construcción y el efecto de las solicitudes simultáneas. Por tanto, el intercambio práctico de HNSW no consiste en que “más RAM siempre equivale a una mejor búsqueda”. Consiste en elegir suficiente conectividad del grafo y amplitud de exploración de consultas para alcanzar la capacidad de recuperación medida sin desplazar al resto de la pila de IA doméstica.
Productos recomendados
Centro de Tecnología e IA
Más para leer
¿Pueden las cámaras domésticas sincronizar eventos sin servicios de hora en la nube?
Una explicación centrada en el mecanismo del tiempo de la cámara sin nube, sus compensaciones por recursos compartidos, tres preguntas frecuentes sobre la propagación...
¿Puede un servicio de IA local detectar capas de modelo dañadas antes de la inferencia?
Una explicación basada primero en los mecanismos de la detección de capas de modelo dañadas, sus compensaciones en recursos compartidos, tres preguntas frecuentes sobre...
¿Se puede restaurar un sistema RAG sin regenerar cada embedding?
Una explicación centrada primero en el mecanismo de la restauración de RAG sin volver a generar embeddings, sus compromisos en el uso compartido de...
