La siguiente respuesta fue escrita primero en inglés y luego traducida.
Hola @Rocio Zarate
Tras revisar el escenario, el comportamiento parece estar relacionado con los límites de capacidad vectorial de Azure AI Search y no con un agotamiento del almacenamiento general. En Azure AI Search, la cuota de almacenamiento y la cuota de tamaño del índice vectorial se administran por separado. La cuota de almacenamiento representa el espacio en disco utilizado por todos los índices, mientras que la cuota del índice vectorial depende de factores como las dimensiones de los vectores, la cantidad de documentos, el número de campos vectoriales, los tipos de datos y la memoria requerida por algoritmos de búsqueda vectorial como HNSW. Por esta razón, es posible observar una utilización baja del almacenamiento mientras la cuota vectorial ya se encuentra completamente consumida.
El primer paso consiste en confirmar si la limitación real corresponde a la cuota de almacenamiento o a la cuota del índice vectorial.
sta información puede validarse desde Azure AI Search > Overview > Usage, donde están disponibles las siguientes métricas:
- Almacenamiento utilizado / Cuota de almacenamiento
- Tamaño del índice vectorial utilizado / Cuota vectorial
- Nivel (tier) actual y configuración de particiones
Estas métricas permitirán determinar si la limitación está relacionada con el consumo de memoria de los vectores o con la capacidad general del servicio.
Aumentar el número de particiones o migrar a un nivel de mayor capacidad podría ser necesario en última instancia, pero primero se recomienda evaluar varias oportunidades de optimización.
- Reducir la huella vectorial La optimización con mayor impacto suele ser la reducción de la cantidad de datos vectoriales almacenados en el índice. Áreas recomendadas para revisar:
- Habilitar Scalar Quantization o Binary Quantization
- Revisar el uso de tipos de datos vectoriales más compactos cuando sea apropiado
- Eliminar almacenamiento vectorial innecesario cuando sea posible
- Revisar las dimensiones de embeddings El almacenamiento vectorial crece proporcionalmente a las dimensiones de los embeddings. Ejemplos como 3072 → 1536 o 1536 → 768 pueden reducir significativamente el consumo del índice vectorial cuando los requisitos de la carga de trabajo lo permiten.
- Revisar la estrategia de segmentación (chunking) Una estrategia de segmentación demasiado agresiva suele generar una gran cantidad de vectores que incrementan innecesariamente el tamaño del índice. Validaciones recomendadas:
- Revisar el tamaño promedio de los fragmentos
- Reducir la fragmentación excesiva
- Mantener fragmentos con significado semántico cuando sea posible
- Revisar el diseño de los campos vectoriales Cada campo vectorial contribuye a un consumo adicional del índice vectorial. Considerar:
- Eliminar campos vectoriales redundantes
- Consolidar representaciones vectoriales duplicadas cuando sea posible
- Evaluar la reconstrucción del índice Cuando se han producido numerosas actualizaciones o eliminaciones de documentos, reconstruir el índice utilizando un esquema optimizado puede ayudar a mejorar la eficiencia y eliminar contenido obsoleto.
Revisión de la configuración HNSW
Si el índice utiliza HNSW, vale la pena revisar los siguientes parámetros:
- m – Valores más altos suelen mejorar la recuperación de resultados, pero incrementan el consumo de memoria.
- efConstruction – Influye en la calidad de indexación y en el rendimiento de la construcción del índice.
- efSearch – Afecta principalmente el rendimiento y la latencia de las consultas.
Aunque los ajustes de HNSW pueden aportar mejoras, las técnicas de compresión y reducción de vectores suelen proporcionar beneficios significativamente mayores.
Evaluación de Exhaustive KNN
Para algunas cargas de trabajo, Exhaustive KNN puede considerarse como una alternativa.
- No mantiene un grafo HNSW en memoria
- No consume la cuota del índice vectorial de la misma forma que HNSW
- Continúa consumiendo almacenamiento
- Puede introducir compromisos de rendimiento dependiendo de las características de la carga de trabajo
Aclaración sobre la utilización del almacenamiento
Una utilización de almacenamiento observada de aproximadamente 24,8 % no significa que exista capacidad vectorial adicional disponible.
Azure AI Search considera:
- La cuota de almacenamiento (capacidad basada en disco)
- La cuota del índice vectorial (capacidad basada en memoria)
como recursos independientes.
Por este motivo, el almacenamiento no utilizado no puede reasignarse ni convertirse en cuota de índice vectorial.
Revisión de la capacidad del servicio
Los límites vectoriales varían en función de:
- El nivel del servicio (tier)
- La región
- El número de particiones
- La fecha de creación del servicio
Los servicios creados después de las actualizaciones de capacidad de abril de 2024 suelen beneficiarse de límites vectoriales significativamente más altos. Por lo tanto, se recomienda revisar la fecha de creación del servicio antes de realizar migraciones o cambios importantes en la arquitectura.
Cuándo es necesario escalar
Si los esfuerzos de optimización no proporcionan suficiente capacidad, las opciones de escalado admitidas son:
- Aumentar el número de particiones para ampliar la cuota vectorial disponible.
- Migrar a un nivel de Azure AI Search con mayor capacidad.
- Evaluar una migración a una configuración de servicio más reciente si las limitaciones actuales están relacionadas con la antigüedad del servicio o restricciones regionales.
Las siguientes referencias podrían ser útiles; por favor revísalas.
Por favor, háganos saber si la respuesta fue útil.
Gracias.