Reducción de memoria en índices IVF con centroides FP8
RAG es una técnica que mejora cuantos más documentos haya disponibles en un indice. Un corpus amplio cubre consultas que una colección pequeña no contiene, pero también obliga a buscar entre muchos más vectores en cada query.
Con pocos vectores, una búsqueda exacta compara la query con todos los embeddings y ordena los resultados. El coste de esa fuerza bruta crece con el corpus y deja de ser sostenible con millones o miles de millones de vectores si el sistema necesita responder con poca latencia. Los índices de búsqueda aproximada de vecinos cercanos, o ANN, reducen el espacio que se explora antes de recuperar los candidatos. A cambio, puede ser que no devuelvan el vecino exacto, sino una aproximación.
Dos familias de índices aparecen a menudo en este escenario. HNSW construye un grafo navegable de vectores y suele conseguir buen recall con baja latencia. Su grafo y los vectores necesarios para recorrerlo crecen con el corpus y deben mantenerse en RAM en muchas configuraciones. IVF divide el espacio en regiones y primero elige cuáles merece la pena explorar. Puede dejar las listas de vectores fuera de memoria y mantener en RAM la capa que dirige la búsqueda.
En nuestro trabajo, Memory Optimization of IVF Indices for RAG Systems Using FP8 Centroid Quantization, nos centramos en la capa de routing de IVF por esa separación. Con IVF, los centroides pueden mantenerse en memoria mientras que los vectores de documentos pueden almacenarse en SSDs.
Estudiamos si los centroides pueden pasar de float32 a FP8 sin tocar los vectores de documentos ni sus listas de posting y cómo afecta eso a la calidad del routing.
Por qué los centroides están en el camino crítico
Un índice IVF divide los embeddings en nlist regiones. Cada región tiene un centroide. Para resolver una query, el índice compara su embedding con todos los centroides y selecciona las nprobe regiones más cercanas. Después busca solo dentro de esas listas de posting.
El índice empieza sin clusters asignados.
Esta separación permite que el corpus grande esté en almacenamiento más barato, pero la tabla de centroides se consulta en cada query y necesita permanecer en memoria. Su coste es:
donde es la memoria de routing, es la dimensionalidad del embedding y son los bytes por coordenada. En float32, es 4. En FP8 es 1.
El objetivo no es comprimir todo el índice, sino solo las representaciones usadas para decidir qué listas explorar. Una vez seleccionadas, los vectores de documentos y el ranking siguen usando la representación original del índice, ya que se cargan desde un almacenamiento más barato.
Precisión o rango
Probamos los formatos FP8: E4M3FN y E5M2. Ambos usan 8 bits, pero los reparten de forma diferente entre exponente y mantisa. E5M2 tiene más rango dinámico, mientras que E4M3FN dedica un bit adicional a la mantisa y representa los valores pequeños con más precisión.
Para la tabla de centroides, esa precisión local resultó más útil que un rango más amplio, ya que la asignación de clusters depende de comparaciones finas entre distancias similares. Un pequeño desplazamiento en un centroide puede cambiar qué lista se explora, aunque los vectores almacenados no hayan cambiado.
Evaluación
Para cada dataset, motor de búsqueda y formato FP8, entrenamos un índice IVF independiente. Extrajimos sus centroides en float32, los convertimos a E4M3FN o E5M2 y los restauramos a float32 antes de volver a insertarlos en el índice. El motor de búsqueda sigue así la misma ruta en float32 en todas las ejecuciones. Solo cambia el error de redondeo que deja la conversión a FP8 en la tabla de routing.
Ejecutamos el protocolo en FAISS y ScaNN, con el mismo corpus y la misma configuración de índice para cada baseline en FP32 y su versión FP8.
Para retrieval geométrico usamos glove-100-angular, que pide al índice recuperar los vectores más cercanos con distancia angular. Reportamos Recall@10 y comparamos los resultados para ver si los centroides FP8 cambian las zonas del espacio vectorial que explora IVF.
Para retrieval semántico codificamos tres datasets del benchamrk MTEB Retrieval con el modelo de 384 dimensiones all-MiniLM-L6-v2: FiQA2018, MLQuestions y QuoraRetrieval. Cubren preguntas financieras, retrieval de preguntas multilingües y preguntas duplicadas, con tamaños de corpus distintos. Reportamos nDCG@10, que recompensa documentos relevantes cerca del inicio del ranking, y MRR@10, que mide la posición del primer resultado relevante. En conjunto, los dos benchmarks evalúan la recuperación geométrica de vecinos y la calidad de retrieval sobre embeddings semánticos.
Resultados
E4M3FN tiene una mejor distribución de recall
Medimos la degradación absoluta de Recall@10 en todo el barrido de configuraciones de glove-100-angular. E4M3FN se mantiene más cerca del baseline FP32 en los dos motores, mientras que E5M2 produce una distribución más amplia y valores atípicos más altos. El bit extra de mantisa importa más que el rango adicional del exponente de E5M2 cuando IVF decide qué listas explorar.
Retrieval geométrico
En todo el barrido de configuraciones, la degradación media de Recall@10 con E4M3FN fue de 0,085% en FAISS y de 0,095% en ScaNN. E5M2 promedió 0,304% y 0,405%, respectivamente. Las fronteras de QPS y recall permanecen casi superpuestas a sus equivalentes en FP32. Incluimos QPS para mostrar las configuraciones evaluadas, no para afirmar que FP8 haga los motores más rápidos. Los centroides se restauran a FP32 antes de buscar, por lo que el experimento conserva la ruta de búsqueda y unicamente mide el error de routing que deja la conversión.
Retrieval semántico
En todos los valores de métrica del benchmark semántico, E4M3FN tuvo una diferencia absoluta media de 0,262 puntos porcentuales frente a FP32. E5M2 alcanzó 0,295 puntos porcentuales. Las diferencias son lo bastante pequeñas como para que el routing conserve el ranking. Pueden aparecer pequeñas mejoras puntuales cuando el routing aproximado intercambia candidatos casi empatados, no porque la cuantización mejore el retrieval. Las gráficas de abajo desglosan Recall@10, nDCG@10 y MRR@10 por motor y tarea.
Cuándo tiene sentido
FP8 para centroides es una optimización muy localizada. No reduce automáticamente el tamaño completo del índice, porque las listas de posting, los vectores, los metadatos y la estructura auxiliar pueden ocupar bastante más memoria. Su caso de uso aparece cuando la tabla de routing es suficientemente grande como para presionar la RAM, especialmente en arquitecturas híbridas donde el corpus vive fuera de memoria.
En estos experimentos, E4M3FN fue la opción FP8 más consistente. Conviene probarla con el modelo, la métrica y la distribución de embeddings que se usen en concreto. IVF busca una lista de posting o la descarta, así que el efecto de cuantizar los centroides depende del margen entre los centroides candidatos.
El paper completo, con el protocolo experimental y las tablas de resultados, está disponible en Springer.