está en el centro de la infraestructura de IA, impulsando múltiples funciones de IA, desde recuperación-generación aumentada (RAG) hasta habilidades de agencia y memoria a largo plazo. Como resultado, la demanda de indexar grandes conjuntos de datos está creciendo rápidamente. Para los equipos de ingeniería, la transición de un prototipo a pequeña escala a una solución de producción a gran escala es cuando el almacenamiento requerido y la factura correspondiente por la infraestructura de bases de datos vectoriales comienzan a convertirse en un problema importante. Aquí es cuando surge la necesidad de optimización.
En este artículo, exploro los principales enfoques para la optimización del almacenamiento de bases de datos vectoriales: cuantificación y aprendizaje de representación Matryoshka (MRL) y analizo cómo estas técnicas se pueden usar por separado o en conjunto para reducir los costos de infraestructura y al mismo tiempo mantener resultados de recuperación de alta calidad.
Buceo profundo
La anatomía de los costos de almacenamiento de vectores
Para entender cómo optimizar un índice, primero debemos observar los números brutos. ¿Por qué las bases de datos vectoriales se vuelven tan caras?
La huella de memoria de una base de datos vectorial está determinada por dos factores principales: precisión y dimensionalidad.
Precisión: un vector de incrustación normalmente se representa como una matriz de números de punto flotante de 32 bits (Float32). Esto significa que cada número individual dentro del vector requiere 4 bytes de memoria. Dimensionalidad: cuanto mayor es la dimensionalidad, más "espacio" tiene el modelo para encapsular los detalles semánticos de los datos subyacentes. Los modelos de incrustación modernos generalmente generan vectores con 768 o 1024 dimensiones.
Hagamos los cálculos para una incrustación estándar de 1024 dimensiones en un entorno de producción:
Tamaño del vector base: 1024 dimensiones * 4 bytes = 4 KB por vector. Alta disponibilidad: para garantizar la confiabilidad, las bases de datos de vectores de producción utilizan replicación (normalmente un factor de 3). Esto eleva el requisito de memoria real a 12 KB por vector indexado.
Si bien 12 KB suena trivial, cuando se pasa de una pequeña prueba de concepto a una aplicación de producción que ingiere millones de documentos, los requisitos de infraestructura se disparan:
1 millón de vectores: ~12 GB de RAM 100 millones de vectores: ~1,2 TB de RAM
Si asumimos que el precio del almacenamiento en la nube es de aproximadamente $5 USD por GB/mes, un índice de 100 millones de vectores costará alrededor de $6000 USD por mes. Fundamentalmente, esto es sólo para los vectores sin procesar. La estructura de datos de índice real (como HNSW) agrega una sobrecarga de memoria sustancial para almacenar las conexiones del gráfico jerárquico, lo que hace que el costo real sea aún mayor.
Para optimizar el almacenamiento y por tanto minimizar costes, existen dos técnicas principales:
Cuantización
La cuantización es la técnica de reducir el espacio (RAM o disco) necesario para almacenar el vector reduciendo la precisión de sus números subyacentes. Si bien un modelo de incrustación estándar genera números de punto flotante de 32 bits de alta precisión (float32), almacenar vectores con esa precisión es costoso, especialmente para índices grandes. Al reducir la precisión, podemos reducir drásticamente los costos de almacenamiento.
Hay tres tipos principales de cuantificación utilizados en bases de datos vectoriales:
Cuantización escalar: este es el tipo más común utilizado en los sistemas de producción. Reduce la precisión del número del vector de float32 (4 bytes) a int8 (1 byte), lo que proporciona una reducción de almacenamiento de hasta 4 veces y tiene un impacto mínimo en la calidad de recuperación. Además, la precisión reducida acelera los cálculos de distancia al comparar vectores, por lo que también reduce ligeramente la latencia.
Cuantización binaria: este es el extremo de la reducción de precisión. Convierte números float32 en un solo bit (por ejemplo, 1 si el número es > 0 y 0 si <= 0). Esto ofrece una enorme reducción de 32 veces el almacenamiento. Sin embargo, a menudo resulta en una fuerte caída en la calidad de la recuperación, ya que dicha representación binaria no proporciona suficiente precisión para describir características complejas y básicamente las borra.
Cuantización del producto: a diferencia de la cuantificación escalar y binaria, que opera con números individuales, la cuantificación del producto divide el vector en fragmentos, se agrupa en estos fragmentos para encontrar "centroides" y almacena solo el ID corto del centroide más cercano. Si bien la cuantificación del producto puede lograr una compresión extrema, depende en gran medida de la distribución del conjunto de datos subyacente e introduce una sobrecarga computacional para aproximar las distancias durante la búsqueda.
Nota: Debido a que los resultados de la cuantificación del producto dependen en gran medida del conjunto de datos, centraremos nuestros experimentos empíricos en la cuantificación escalar y binaria.
Aprendizaje de representación de matrioskas (MRL)
Matryoshka Representation Learning (MRL) aborda el problema del almacenamiento desde un ángulo completamente diferente. En lugar de reducir la precisión de los números individuales dentro del vector, MRL reduce la dimensionalidad general del propio vector.
Los modelos de integración que admiten MRL están entrenados para cargar la información semántica más crítica en las primeras dimensiones del vector. Al igual que las muñecas rusas que dan nombre a la técnica, una representación más pequeña y de gran capacidad está anidada dentro de la más grande. Esta capacitación única permite a los ingenieros simplemente truncar (cortar) el extremo final del vector, reduciendo drásticamente su dimensionalidad con solo una penalización mínima para las métricas de recuperación. Por ejemplo, un vector estándar de 1024 dimensiones se puede truncar limpiamente a 256, 128 o incluso 64 dimensiones preservando al mismo tiempo el significado semántico central. Como resultado, esta técnica por sí sola puede reducir el espacio de almacenamiento requerido hasta 16 veces (al pasar de 1024 a 64 dimensiones), lo que se traduce directamente en menores facturas de infraestructura.
El experimento
Nota: El código completo y reproducible para este experimento está disponible en el repositorio de GitHub.
Tanto MRL como la cuantificación son técnicas poderosas para encontrar el equilibrio adecuado entre las métricas de recuperación y los costos de infraestructura para mantener rentables las características del producto y al mismo tiempo brindar resultados de alta calidad a los usuarios. Para comprender las ventajas y desventajas exactas de estas técnicas y ver qué sucede cuando superamos los límites combinándolas, organizamos un experimento.
Aquí está la arquitectura de nuestro entorno de prueba:
Base de datos de vectores: FAISS, que utiliza específicamente el índice HNSW (Hierarchical Navigable Small World). HNSW es un algoritmo de vecino más cercano (ANN) basado en gráficos ampliamente utilizado en bases de datos vectoriales. Si bien acelera significativamente la recuperación, introduce una sobrecarga de computación y almacenamiento para mantener las relaciones gráficas entre vectores, lo que hace que la optimización en índices grandes sea aún más crítica. Conjunto de datos: utilizamos el conjunto de datos mteb/hotpotQA (licencia cc-by-sa-4.0) (disponible a través de Hugging Face). Es una colección sólida de pares de preguntas y respuestas, lo que la hace ideal para medir métricas de recuperación del mundo real. Tamaño del índice: para garantizar que este experimento siga siendo fácilmente reproducible, el tamaño del índice se limitó a 100.000 documentos. La dimensión de incorporación original es 384, lo que proporciona una base excelente para demostrar las ventajas y desventajas de los diferentes enfoques. Modelo de incrustación: Mixedbread-ai/mxbai-embed-xsmall-v1. Este es un modelo compacto y altamente eficiente con soporte MRL nativo, que proporciona un excelente equilibrio entre precisión y velocidad de recuperación.
Resultados de optimización del almacenamiento
Para comparar los enfoques discutidos anteriormente, medimos la huella de almacenamiento en diferentes dimensionalidades y métodos de cuantificación.
Nuestra base para el índice 100k (384 dimensiones, Float32) comenzó en 172,44 MB. Combinando ambas técnicas, la reducción es enorme:
Nuestros datos demuestran que, si bien cada técnica es muy efectiva de forma aislada, su aplicación en conjunto genera retornos compuestos para la eficiencia de la infraestructura:
Cuantización: pasar de Float32 a Scalar (Int8) en las 384 dimensiones originales reduce inmediatamente el almacenamiento en un 63,7 % (cayendo de 172,44 MB a 62,58 MB) con un esfuerzo mínimo. MRL: La utilización de MRL para truncar vectores a 128 dimensiones, incluso sin ninguna cuantificación, produce una respetable reducción del 56,6 % en el espacio de almacenamiento. Impacto combinado: cuando aplicamos la cuantificación escalar a un vector MRL de 128 dimensiones, logramos una enorme reducción del 77,9 % (lo que reduce el índice a solo 38,17 MB). Esto representa un aumento de casi 4,5 veces en la densidad de datos con casi cero cambios arquitectónicos en el sistema más amplio.
La compensación de la precisión: ¿cuánto perdemos?
Las optimizaciones del almacenamiento son, en última instancia, una compensación. Para comprender el "costo" de estas optimizaciones, evaluamos un índice de 100 000 documentos utilizando un conjunto de prueba de 1000 consultas del conjunto de datos de HospotQA. Nos centramos en dos métricas principales para un sistema de recuperación:
Recall@10: Mide la capacidad del sistema para incluir el documento relevante en cualquier lugar dentro de los 10 primeros resultados. Esta es la métrica crítica para los oleoductos RAG donde un LLM actúa como árbitro final. Rango recíproco medio (MRR@10): Mide la clasificación de la calidad teniendo en cuenta la posición del documento relevante. Un MRR más alto indica que el documento "oro" se coloca constantemente en la parte superior de los resultados.
Como podemos ver, la brecha entre Scalar (int8) y No Quantization es notablemente pequeña. En las 384 dimensiones de referencia, la caída de la recuperación es solo del 1,46 % (0,481 a 0,474) y el MRR sigue siendo casi idéntico con solo una disminución del 2,72 % (0,367 a 0,357).
Por el contrario, la cuantización binaria (1 bit) representa un "precipicio de rendimiento". En las 384 dimensiones de referencia, la recuperación binaria ya está por detrás de Scalar en más del 17 % en Recall y el 18,4 % en MRR. A medida que la dimensionalidad cae aún más a 64, la precisión binaria colapsa a una recuperación insignificante de 0,102, mientras que Scalar mantiene un 0,300, lo que la hace casi 3 veces más efectiva.
Conclusión
Si bien escalar una base de datos vectorial a miles de millones de vectores es cada vez más fácil, a esa escala los costos de infraestructura se convierten rápidamente en un importante cuello de botella. En este artículo, he explorado dos técnicas principales para la reducción de costos (cuantización y MRL) para cuantificar los ahorros potenciales y sus correspondientes compensaciones.
Según el experimento, almacenar datos en Float32 tiene pocos beneficios siempre que se utilicen vectores de alta dimensión. Como hemos visto, la aplicación de Scalar Quantization produce una reducción inmediata del 63,7% en el espacio de almacenamiento. Esto reduce significativamente los costos generales de infraestructura con un impacto insignificante en la calidad de la recuperación: experimentando solo una caída del 1,46 % en Recall@10 y una caída del 2,72 % en MRR@10, lo que demuestra que la cuantificación escalar es la optimización de infraestructura más fácil y eficiente que casi todos los casos de uso de RAG deberían adoptar.
Otro enfoque es combinar MRL y cuantificación. Como se muestra en el experimento, la combinación de MRL de 256 dimensiones con cuantificación escalar nos permite reducir aún más los costos de infraestructura en un 70,8%. Para nuestro ejemplo inicial de un índice vectorial de 100 millones y 1024 dimensiones, esto podría reducir los costos hasta en $50 000 por año y al mismo tiempo mantener resultados de recuperación de alta calidad (experimentando solo una reducción del 4,6 % en Recall@10 y una reducción del 4,4 % en MRR@10 en comparación con la línea de base).
Finalmente, Cuantización Binaria: Como era de esperar, proporciona las reducciones de espacio más extremas pero sufre una caída masiva en las métricas de recuperación. Como resultado, es mucho más beneficioso aplicar MRL más cuantificación escalar para lograr una reducción de espacio comparable con un compromiso mínimo en precisión. Según el experimento, es muy preferible utilizar una dimensionalidad más baja (128d) con cuantificación escalar, lo que produce una reducción de espacio del 77,9 %, en lugar de utilizar una cuantificación binaria en el índice de 384 dimensiones no acortado, ya que la primera demuestra una calidad de recuperación significativamente mayor.
Recomendaciones generales para casos de uso de producción:
Para obtener una solución equilibrada, utilice MRL + cuantificación escalar. Proporciona una reducción masiva de RAM/espacio en disco al tiempo que mantiene resultados de recuperación de alta calidad. La cuantización binaria debe reservarse estrictamente para casos de uso extremos en los que la reducción de RAM/espacio en disco es absolutamente crítica, y la baja calidad de recuperación resultante se puede compensar aumentando top_k y aplicando un reclasificador de codificador cruzado.
Referencias
[1]Código de experimento completo https://github.com/otereshin/matryoshka-quantization-analysis
[2]Modelo https://huggingface.co/mixedbread-ai/mxbai-embed-xsmall-v1
[3]Conjunto de datos mteb/hotpotqa https://huggingface.co/datasets/mteb/hotpotqa
[4]FAISS https://ai.meta.com/tools/faiss/
[5]Aprendizaje de representación de Matryoshka (MRL): Kusupati, A., Bhatt, G., Rege, A., Wallingford, M., Sinha, A., Ramanujan, V.,… & Farhadi, A. (2022). Aprendizaje de la representación de Matryoshka.