Buscar a escala es un desafío. Por potente que sea la búsqueda vectorial, puede ser difícil saber cómo evaluar correctamente factores clave como la precisión, el costo y el rendimiento para cargas de trabajo más grandes. Recientemente publicamos Evaluación comparativa (benchmark) de MongoDB Benchmark para Atlas Vector Search, que describe las estrategias clave de optimización del rendimiento para la búsqueda vectorial y proporciona una guía completa para lograr resultados óptimos con grandes conjuntos de datos. El objetivo principal de nuestra guía es reducir significativamente la fricción para su primera prueba de vector a escala (>10 M vectores) al evaluar el rendimiento de Atlas Vector Search.
Con esta nueva guía, el objetivo es proporcionar más contexto sobre cómo utilizar el benchmark, explorar el conjunto de datos (incluidos los factores considerados) y resumir y contextualizar los resultados. ¡Vamos a verlo con detalle!
Una nota sobre los datos de benchmarking
Toda buena presentación incluye la diapositiva obligatoria de puerto seguro, y el arte y la ciencia del benchmarking no son diferentes. Embarcarse en una carga de trabajo vectorial a gran escala puede presentar obstáculos importantes derivados de la falta de información precisa y la fricción inherente de los benchmarks iniciales. Además, el panorama de la búsqueda vectorial y los modelos de incrustación evoluciona rápidamente, por lo que la información puede quedar desactualizada pronto, lo que puede llevar a los usuarios por caminos ineficientes o incorrectos. Sin una orientación clara y actualizada, los usuarios pueden tener dificultades para predecir el comportamiento del sistema, optimizar las configuraciones y asignar recursos con confianza.
También vale la pena señalar que numerosos factores (cuantización, dimensionalidad, filtrado, configuración del nodo de búsqueda, concurrencia, particionado y más) interactúan de formas complejas. Comprender estas interacciones y su impacto específico en una carga de trabajo en particular requiere perspectivas profundas y precisas. Sin esto, los usuarios pueden optimizar un aspecto solo para degradar inadvertidamente otro.
Este vacío informativo, sumado a los considerables gastos en general de configuración, el complejo ajuste de los parámetros y el costo de la experimentación que conlleva realizar la primera prueba de referencia, crea una barrera considerable para probar y escalar una solución. No obstante, consideramos que estas pruebas de referencia brindan confianza en las POC a nuestros clientes y les brindan un punto de partida para trabajar (en lugar de no tener una brújula con la que comenzar).
Teniendo en cuenta estos factores, veamos una descripción general del conjunto de datos.
Un vistazo al conjunto de datos
El núcleo de este análisis de rendimiento gira en torno a pruebas realizadas en subconjuntos del conjunto de datos de reseñas de Amazon de 2023, que contenía 48 millones de descripciones de artículos en 33 categorías de productos. El conjunto de datos se eligió debido a su capacidad para proporcionar un escenario de comercio electrónico realista y a gran escala, así como por ofrecer datos enriquecidos, incluidas reseñas de usuarios (calificaciones, texto, votos de utilidad), metadatos del artículo (precio, imágenes) y nombres y descripciones detallados del artículo, que son ideales para realizar búsquedas. Para las pruebas de dimensión variable, se utilizaron subconjuntos de 5.5 millones de artículos, integrados con voyage-3-large para producir vectores de 2048 dimensiones. Luego se crearon vistas para dividirlos en vectores de 1024, 512 y 256 dimensiones para probar diferentes dimensionalidades. Para la prueba de alta dimensión y gran escala, se utilizó un subconjunto de 15.3 millones de elementos, también incrustado con vectores de 2048 dimensiones de voyage-3-large.
Una de las conclusiones clave del informe es que, en la dimensión más alta (15.3 M de vectores que utilizan incrustaciones voyage-3-large en 2048 dimensiones), Atlas Vector Search con cuantificación escalar o binaria configurada mantiene una precisión del 90-95% con menos de 50 ms de latencia de query. Hay que tener en cuenta que la cuantificación binaria puede tener una mayor latencia cuando el número de candidatos solicitados asciende a cientos, debido al costo adicional de volver a puntuar con vectores de fidelidad completa, pero aún así puede ser preferible para muchas cargas de trabajo a gran escala debido a la relación costo-efectividad.
Metodología: benchmarking con el conjunto de datos de reseñas de Amazon
Ahora que hemos hablado un poco sobre los datos en sí y la información incluida, describamos algunos de los factores clave que tienen un impacto en el rendimiento de Atlas Vector Search y cómo configuramos nuestro benchmark para probarlos. También es importante reconocer por qué estas variables son críticas: no todos los clientes optimizarán su búsqueda para lo mismo. Con eso en mente, también intentaremos identificar la interacción y las compensaciones entre ellos.
Aunque esta lista no es exhaustiva (consulte el informe completo para ver más detalles), revisemos algunos de los factores de rendimiento clave:
Recuperación: la recuperación (una medida de la precisión de búsqueda) se ve significativamente afectada por la cuantificación y la dimensionalidad de los vectores. El informe destaca que, si bien la cuantificación escalar suele comenzar con una mayor capacidad de recuperación, la cuantificación binaria puede acercarse a niveles de precisión similares aumentando numCandidates, aunque esto a menudo implica una mayor latencia debido a un paso de repuntuación adicional. Además, los vectores de mayor dimensión (1024d y 2048d) mantienen sistemáticamente una mejor recuperación, en particular con conjuntos de datos más grandes y cuantificación, en comparación con las dimensiones más bajas (256d y 512d), que tienen dificultades para superar el 70-80% de recuperación.
Dimensionamiento y costo: la tabla del benchmark detalla los recursos necesarios (RAM, almacenamiento) y los costos asociados para los diferentes niveles de nodos de búsqueda en función de tres casos de prueba diferentes que implican tamaños de conjunto de datos variables, dimensiones vectoriales y métodos de cuantificación (escalar o binario). La guía proporciona un ejemplo de conjunto de datos de muestra que indica que los requisitos de recursos se ajustan linealmente, y señala cómo la cuantificación reduce sustancialmente los requisitos de memoria.
Concurrencia y rendimiento: el rendimiento se evalúa con varias solicitudes emitidas simultáneamente. La cuantificación escalar generalmente logra mayores queries por segundo (QPS) en varios valores límite debido a la menor cantidad de trabajo por consulta y a que no hay reclasificación. A menudo se observan cuellos de botella en la concurrencia, lo que indica que puede producirse una mayor latencia. Se recomienda escalar el número de nodos de búsqueda o aumentar las vCPU disponibles para resolver estos cuellos de botella y lograr un QPS más alto.
Cómo optimizar el rendimiento de la búsqueda vectorial
Este benchmark examina exhaustivamente el rendimiento de MongoDB Atlas Vector Search en varias configuraciones y grandes conjuntos de datos, específicamente el conjunto de datos de reseñas de Amazon de 2023. Explora el impacto de factores como la cuantificación (escalar y binaria), la dimensionalidad vectorial, el filtrado, las configuraciones del nodo de búsqueda, la compresión binData, la concurrencia y el particionado en la recuperación, la latencia y el rendimiento.
Aunque nunca existe una “solución milagrosa” debido a que la definición de “éxito” en la búsqueda varía para cada persona, queríamos destacar algunas de las diversas palancas a considerar y métodos para sacar el máximo partido a su propia implementación. El objetivo es proporcionar algunas consideraciones clave sobre cómo evaluar y mejorar el rendimiento de la búsqueda vectorial, y ayudar a ponderar y contextualizar adecuadamente los factores clave. ¿Listo para optimizar la experiencia de búsqueda vectorial?
Explore la guía de nuestra documentación.
Ejecútelo usted mismo con nuestro repositorio de GitHub.