Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Mosaic AI Vector Search se ha creado para una recuperación rápida y escalable. El rendimiento de la búsqueda vectorial depende de muchos factores, como la elección de SKU, el tamaño del índice, el tipo de consulta, la dimensionalidad vectorial, los métodos de autenticación y la forma en que la aplicación controla los picos de tráfico. La mayoría de las cargas de trabajo funcionan correctamente, pero en situaciones en las que es necesario escalar o optimizar la latencia, esta guía presenta sugerencias prácticas y patrones comunes que le ayudarán a configurar el sistema para obtener un rendimiento óptimo de búsqueda vectorial.
Factores que afectan al rendimiento
El rendimiento no es un solo número: es un intervalo que depende de las características de la carga de trabajo, las opciones de configuración y la implementación del cliente. Esta guía está diseñada para ayudarle a crear un modelo mental claro de cómo funciona el rendimiento para que pueda usar mosaic AI Vector Search de forma más eficaz.
A continuación se muestran los factores clave que influyen en el comportamiento del sistema:
- Opción de SKU: optimizada para almacenamiento o estándar.
- Tamaño del índice: número de vectores almacenados.
- Tamaño de inserción: normalmente 384–1536.
- Tipo de consulta: vecino más cercano (ANN) o híbrido.
- Número de resultados solicitados: los valores más altos aumentan el tiempo de recuperación.
- Tipo de inserción: administrado o autoadministrado.
- Carga de consultas: cuánto tráfico alcanza el punto de conexión a lo largo del tiempo.
- Método de autenticación: cómo se conecta la aplicación a Databricks.
En el resto de este artículo se proporcionan sugerencias prácticas para ajustar cada una de estas variables y se explica cómo afectan a la latencia de búsqueda y al rendimiento de las consultas en las implementaciones del mundo real.
Selección de la SKU correcta
Mosaic AI Vector Search ofrece dos SKU, cada una diseñada para equilibrar la latencia, escalabilidad y rentabilidad en función de la carga de trabajo. Elegir la SKU adecuada para la aplicación es la primera palanca para optimizar el rendimiento.
En general:
- Elija puntos de conexión estándar cuando la latencia sea crítica y el índice esté bien bajo vectores de 320M.
- Elija puntos de conexión optimizados para almacenamiento cuando trabaje con vectores de más de 10 M+, puede tolerar cierta latencia adicional y necesita una mejor eficiencia de costos por vector (hasta 7 veces más barato).
En la tabla siguiente se muestran algunas directrices de rendimiento esperadas.
| SKU | Latencia | QPS | Capacidad de índice | Tamaño de la unidad de búsqueda vectorial (VSU) |
|---|---|---|---|---|
| Estándar | 20–50 ms | 30–200+ | Vectores de 320M | Vectores 2M |
| Optimizado para almacenamiento | 300–500 ms | 30–50 | Vectores 1B | Vectores de 64 M |
Descripción del tamaño del índice
El rendimiento es mayor cuando el índice se ajusta dentro de una sola unidad de búsqueda vectorial, con espacio adicional para controlar la carga de consultas adicional. A medida que las cargas de trabajo se escalan más allá de una sola unidad de búsqueda vectorial (es decir, 2M+ vectores para estándar o 64M+ para optimizados para almacenamiento), aumenta la latencia y se desactivan los pulsadores de QPS. Finalmente, QPS se encuentra en aproximadamente 30 QPS (ANN).
El rendimiento depende de muchos factores únicos para cada carga de trabajo, como patrones de consulta, filtros, dimensionalidad vectorial y simultaneidad. Los números siguientes son puntos de referencia.
| SKU | Vectors | Dimensión | Latencia | QPS | Consultas mensuales |
|---|---|---|---|---|---|
| Estándar | 10 000 | 768 | 20 ms | 200+ | 500 M+ |
| 10 millones | 768 | 40 ms | 30 | 78 M | |
| 100 M | 768 | 50 ms | 30 | 78 M | |
| Optimizado para almacenamiento | 10 millones | 768 | 300 ms | 50 | 130 M |
| 100 M | 768 | 400 ms | 40 | 100 M | |
| 1B | 768 | 500 ms | 30 | 78 M |
Minimizar el tamaño de inserción
La dimensionalidad vectorial hace referencia al número de características de cada vector. Los valores típicos son 384, 768, 1024 o 1536. Las dimensiones más altas proporcionan representaciones más expresivas que pueden mejorar la calidad, pero tienen un costo de proceso. Los vectores dimensionales inferiores requieren menos cálculo durante la recuperación, lo que se traduce en tiempos de consulta más rápidos y QPS superiores. Por el contrario, los vectores de mayor dimensión aumentan la carga de proceso y reducen el rendimiento.
Como regla general, elija la dimensionalidad más pequeña que conserva la calidad de recuperación para su caso de uso.
Por ejemplo, reducir la dimensionalidad por un factor de dos (por ejemplo, de 768 a 384) normalmente mejora QPS en aproximadamente 1,5x y reduce la latencia en aproximadamente 20%, según el tamaño del índice y el patrón de consulta. Estos beneficios se componen aún más en dimensiones muy bajas. Por ejemplo, el uso de vectores 64 dimensionales puede ofrecer QPS considerablemente más alto y una latencia significativamente menor en comparación con las pruebas comparativas de 768 dimensiones que se muestran en la tabla. Esto hace que 384 dimensiones y por debajo sean especialmente atractivas para casos de uso sensibles a la latencia y alto rendimiento, siempre y cuando la calidad de recuperación siga siendo aceptable.
Usar ANN para mejorar la eficacia y usar híbrido cuando sea necesario
Use consultas ANN siempre que sea posible. Son los más eficientes para el proceso y admiten el QPS más alto.
Use la búsqueda híbrida cuando sea necesario. La búsqueda híbrida mejora la recuperación en algunas aplicaciones, especialmente cuando las palabras clave específicas del dominio son importantes. La búsqueda híbrida normalmente usa aproximadamente el doble de recursos que ANN y puede reducir significativamente el rendimiento.
Usar resultados de 10 a 100
Cada consulta incluye un num_results parámetro , que es el número de resultados de búsqueda que se van a devolver. Este valor afecta directamente al rendimiento. La recuperación de más resultados requiere un examen más profundo del índice, lo que aumenta la latencia y reduce QPS. El efecto se vuelve más significativo en valores más altos. Por ejemplo, aumentar num_results en 10x puede duplicar la latencia de las consultas y reducir la capacidad de QPS en 3 veces, en función del tamaño y la configuración del índice.
Como procedimiento recomendado, mantenga num_results en el intervalo de 10 a 100 a menos que la aplicación requiera más. Pruebe valores diferentes num_results mediante consultas realistas para comprender el impacto en la carga de trabajo.
Evitar la escala a cero para producción
La búsqueda de vectores admite dos tipos de incrustaciones con diferentes ventajas de rendimiento.
Las incrustaciones administradas son las más convenientes. Con las inserciones administradas, Databricks genera inserciones para las filas y las consultas automáticamente. En el momento de la consulta, el texto de la consulta se pasa a un punto de conexión de servicio del modelo para generar la inserción, lo que agrega latencia. Si el modelo de inserción es externo, también presenta una sobrecarga de red adicional.
Las incrustaciones autoadministradas permiten calcular las incrustaciones de antemano y pasar los vectores directamente en el momento de la consulta. Esto evita la generación en tiempo de ejecución y permite la recuperación más rápida. Todos los números de rendimiento incluidos en este artículo se basan en incrustaciones autoadministradas.
Para casos de uso de producción en tiempo real, evite los puntos de conexión del modelo que se escalan a cero. Los inicios en frío pueden retrasar las respuestas durante varios minutos o incluso provocar errores si el punto de conexión está inactivo cuando llega una consulta.
Planear picos de consulta
En esta sección se describe qué esperar a medida que aumenta el tráfico y cómo mantenerse por debajo de los límites críticos que desencadenan picos de latencia o errores 429 (demasiadas solicitudes).
La latencia permanece baja cuando la carga es moderada y aumenta gradualmente a medida que se aproxima a la capacidad máxima de QPS. Cuando el sistema alcanza 100% capacidad de QPS, comienza a devolver 429 errores. Si no ha configurado el retroceso adecuado, es posible que la aplicación deje de responder.
Los errores 429 sirven como mecanismo de seguridad para proteger el sistema. Indican al cliente que vuelva a intentarlo y vuelva a intentarlo más adelante para que el punto de conexión siga siendo correcto y con capacidad de respuesta, incluso bajo picos de tráfico repentinos.
Como procedimiento recomendado, use el SDK de Python de Búsqueda de vectores, que incluye retroceso integrado y control de reintentos.
Si usa la API REST, implemente retroceso exponencial con vibración. Consulte Antipatrones de Azure.
Uso de entidades de servicio con tokens de OAuth
Use métodos de autenticación eficaces para mejorar el rendimiento. Databricks recomienda usar una entidad de servicio con el token de OAuth en todos los entornos de producción. Los tokens de acceso de OAuth proporcionan mayor seguridad y también aprovechan la infraestructura optimizada para red para permitir que el sistema funcione a plena capacidad.
Evite usar tokens de acceso personal (PAT), ya que introducen sobrecarga de red, agregan cientos de milisegundos de latencia y reducen significativamente el QPS que puede mantener el punto de conexión.
Uso del SDK de Python
Use la versión más reciente del SDK de Python para beneficiarse de las optimizaciones integradas de rendimiento y confiabilidad.
Vuelva a usar el objeto de índice en las consultas. Evite llamar a client.get_index(...).similarity_search(...) en cada solicitud, ya que este patrón agrega latencia innecesaria.
En su lugar, inicialice el índice una vez y reutilícelo:
# Initialize once
index = client.get_index(...)
# Then use it for every query
index.similarity_search(...)
Esto es importante al usar el índice de búsqueda vectorial en entornos de MLFlow, donde puede crear el objeto de índice en la inicialización del punto de conexión y, a continuación, reutilizarlo para cada consulta.
Esta guía es especialmente útil en aplicaciones sensibles a la latencia en tiempo real. En las configuraciones de RAG con varios índices o flujos de autorización en nombre de usuario , donde la selección de índices o las credenciales solo están disponibles en el momento de la consulta, es posible que la inicialización del objeto de índice una vez no sea factible. Esta optimización no es necesaria en esos escenarios.
Paralelización entre puntos de conexión
Databricks recomienda explorar las siguientes estrategias para aumentar el total de QPS en el sistema:
- Dividir índices entre puntos de conexión. Si tiene varios índices que reciben una parte significativa del tráfico, hospede en puntos de conexión independientes para alcanzar un mayor ancho de banda total.
- Replique el índice entre puntos de conexión. Si la mayoría del tráfico alcanza un único índice, duplique en varios puntos de conexión. Divida el tráfico uniformemente en el nivel de cliente para las ganancias lineales de QPS.
Use pruebas de carga para asegurarse de que los puntos de conexión tienen el tamaño correcto.
Una prueba de carga mide el rendimiento del punto de conexión de búsqueda vectorial en diferentes niveles de tráfico, simulando el uso del mundo real y ayudando a ajustar el tamaño del punto de conexión correctamente para satisfacer los requisitos de producción. Consulte Configuración de una prueba de carga para puntos de conexión de búsqueda vectorial para obtener más información sobre cómo crear y ejecutar una prueba de carga.