La compresión de vectores está cobrando cada vez más importancia porque los índices domésticos en crecimiento compiten por una RAM, capacidad SSD, localidad de caché y ancho de banda de copias de seguridad limitados.
Un millón de vectores de 768 dimensiones almacenados como números de coma flotante de 32 bits requieren aproximadamente 3 GB antes de añadir enlaces de grafo, metadatos, réplicas y sobrecarga del sistema de archivos. Las fotos, los fragmentos de documentos, los segmentos de audio y varias versiones de embeddings pueden multiplicar rápidamente ese espacio. La compresión intercambia precisión numérica y trabajo de decodificación por índices residentes más pequeños, lo que convierte la frontera calidad-memoria en una decisión fundamental para un servidor doméstico con recursos locales limitados.
Las dimensiones de los embeddings multiplican el coste de infraestructura
El almacenamiento de un vector sin comprimir es igual al número de dimensiones multiplicado por los bytes de cada componente. Float32 utiliza cuatro bytes; float16 reduce esa cantidad a la mitad; la cuantización escalar o binaria puede reducirla aún más. El índice de búsqueda añade después vecinos del grafo, identificadores, metadatos, eliminaciones lógicas y espacio temporal de compilación, elementos que los cálculos vectoriales simples omiten.
Una guía centrada en el almacenamiento sobre la cuantización de vectores explica cómo los métodos escalares, de producto y binarios intercambian el tamaño de la representación por la precisión de las distancias y el coste de procesamiento.
Los vectores más pequeños pueden mantener más candidatos en la RAM o en la caché de páginas del sistema operativo, reduciendo las lecturas aleatorias del SSD. Por tanto, la mejora de velocidad puede deberse a la localidad de memoria y no a una aritmética más rápida. La compresión cambia toda la ruta de servicio, no solo la cifra que aparece en el uso del disco.
La cuantización de producto sustituye los vectores por códigos compactos
La cuantización de producto divide cada vector en subvectores y los asigna a entradas de libros de códigos aprendidos. La base de datos almacena códigos pequeños en lugar de cada componente de coma flotante y después aproxima las distancias de consulta mediante tablas de búsqueda. Esto puede reducir drásticamente el espacio ocupado y conservar al mismo tiempo suficiente estructura de vecindad para recuperar candidatos.
Un estudio de 2026 sobre la cuantización de producto optimizada para la caché reorganiza las comparaciones de centroides para mejorar la localidad de la caché de la CPU y demuestra que el diseño del códec afecta tanto a la construcción del índice como a la eficiencia del hardware.
La compresión también puede permitir un diseño de dos niveles: utilizar vectores compactos para una búsqueda amplia de candidatos y después volver a puntuar un conjunto más pequeño con vectores de precisión completa almacenados en medios más lentos. Esto refleja la recuperación y la reordenación, separando la recuperación eficiente en memoria de la precisión final, más costosa.
Dónde la compresión daña la vecindad
Una cuantización agresiva puede eliminar pequeñas diferencias de distancia e intercambiar el orden de los vecinos cercanos. Los nombres poco frecuentes, los fragmentos cortos, el texto multilingüe y la similitud de imágenes con diferencias sutiles pueden ser especialmente sensibles. Un método que funciona bien en un benchmark público aún puede distorsionar un corpus doméstico con una geometría diferente.
Un diseño de almacenamiento desacoplado de vectores publicado en 2026 separa los datos vectoriales de los metadatos del índice e informa de hasta un 58,7 % menos de almacenamiento, manteniendo al mismo tiempo un comportamiento de búsqueda competitivo.
El límite se mide mediante la recuperación y el coste de reconstrucción. La compresión puede requerir entrenar libros de códigos y reconstruir los índices cuando cambia la distribución de los embeddings. Un tamaño menor no siempre implica un coste inferior si una recuperación baja obliga a realizar búsquedas con conjuntos de candidatos más amplios, una reordenación adicional o una reindexación frecuente.
Selecciona la compresión a partir de una frontera de calidad y memoria
Calcula por separado los vectores sin comprimir, la sobrecarga del grafo, los metadatos, las réplicas, el espacio de trabajo de compilación y las copias de seguridad. Compara las opciones float32, float16, escalar, de producto o binaria con las mismas consultas reservadas y los mismos vecinos exactos de referencia.
Utiliza el almacenamiento de un millón de vectores como referencia sin comprimir y después informa de Recall@k, nDCG, latencia p95, memoria residente, tamaño del índice, tiempo de compilación y carga de reordenación para cada códec.
Elige la representación más ligera que se mantenga dentro del umbral de relevancia para cada segmento de consultas protegido. Conserva el texto original y los metadatos de los embeddings para poder reconstruirlos, mantén la precisión completa para volver a puntuar cuando sea necesario y repite las pruebas después de cambiar el modelo de embeddings o la combinación de idiomas del corpus.
Centro de Tecnología e IA
Más para leer

¿Por qué la compatibilidad con embeddings multilingües está mejorando la búsqueda privada en el hogar en 2026?
Descubre cómo los espacios compartidos permiten la recuperación entre idiomas, por qué es importante equilibrar el entrenamiento y en qué casos siguen fallando los...

¿Por qué la recuperación de la IA doméstica se orienta hacia puntos de control coordinados de modelos e índices en 2026?
Descubre por qué las copias de seguridad crean un estado de IA con versiones mezcladas, cómo los puntos de control coordinados restauran la coherencia...

¿Por qué el almacenamiento de servidores domésticos avanza hacia una clasificación por niveles según la carga de trabajo en 2026?
Comprende cómo las señales de carga de trabajo colocan los datos activos en medios rápidos, por qué la IA cambia las decisiones de jerarquización...

