Esta página explora los resultados de nuestro MongoDB Vector Search punto de referencia de rendimiento.
Resumen de resultados
En 15.3M vectores utilizando
voyage-3-largeembeddings en 2048 dimensiones, MongoDB Vector Search con cuantificación configurada retiene un 90-95% de precisión con una latencia de query < 50ms.La cuantificación binaria es más lenta cuando se solicitan cientos de candidatos debido al coste adicional de volver a puntuar con vectores de fidelidad completa. Sin embargo, con un coste de ~1/4 por servir el índice, podría ser una opción preferible para muchas cargas de trabajo a gran escala.
Recomendamos más de 1024 dimensiones al ejecutar cargas de trabajo más grandes con cuantización.
Los filtros selectivos pueden mejorar o empeorar el rendimiento dependiendo del valor seleccionado para
numCandidates.El costo adicional de recalificación para la cuantización binaria se manifiesta en un rendimiento reducido al ejecutar cargas de trabajo altamente concurrentes.
El particionamiento mejora ligeramente el rendimiento, pero seguimos recomendando escalar la cantidad de Nodos de Búsqueda o el número de núcleos disponibles en un Nodo de Búsqueda para mejorar el rendimiento.
Recuperación y análisis de latencia en referencia a un benchmark multidimensional
El primer conjunto de resultados muestra las pruebas que ejecutamos contra un conjunto de datos de documentos 5.5M que contiene múltiples dimensionalidades de vectores (256, 512, 1024, 2048), todos producidos utilizando voyage-3-large, dentro de cada documento.
Para ver la gráfica completa, consulte la Artefacto Claude.
Los resultados cuantificados escalares parten de niveles superiores a los de cuantificación binaria, pero se mantienen en su nivel asintótico incluso al aumentar numCandidates. Por el contrario, las consultas cuantificadas binariamente producen resultados más precisos a medida que se solicitan más numCandidates, acercándose a la asíntota de la cuantificación escalar y, en algunos casos, superándola, a costa de una mayor latencia, especialmente por encima de numCandidates o 1000.
Generalmente, es más difícil acercarse a una precisión del 100% con valores bajos de limit, ya que los resultados máximos son más difíciles de identificar, y a menudo se requieren valores más altos de numCandidates para lograr mejores resultados. Esto se observa particularmente en el gráfico de cuantificación binaria. También se observa que los vectores de menor dimensión 256d y 512d sufren particularmente a gran escala con cualquiera de las dos formas de cuantificación. 256d nunca supera el 70% de recuperación y 512d nunca supera el 80% de recuperación en las pruebas de límite 10, donde el límite 100 requiere valores más altos de numCandidates para alcanzar la zona objetivo del 90-95%.
Dada esta información, determinamos que cuando se trabaja con un gran conjunto de datos, recomendamos tener una dimensionalidad de al menos 1024d y aplicar cuantización para escalar en lugar de tener menor dimensionalidad y no usar cuantización, y la cantidad de vectores solicitados para el caso de uso también juega un papel.
Resultados de benchmark más grandes
Para el conjunto de datos vectoriales 15.3M más grande, fijamos la dimensionalidad a 2048d y examinamos el impacto de la cuantización, el filtrado y la concurrencia en el rendimiento. Elegimos usar 2048d basándonos en los resultados de la prueba anterior, que mostraban que dimensiones superiores mantenían el recall de manera más favorable, aunque 1024d probablemente habría servido igual de bien para alcanzar el objetivo de recall del 90-95%.
Análisis de recuperación de datos y latencia
Observamos que se requiere significativamente más numCandidates al usar cuantificación binaria para alcanzar el objetivo de recuperación del 90-95% en comparación con la línea base. Un valor mayor de numCandidates generalmente implica una mayor latencia, pero esto puede variar.
Para ver la gráfica completa, consulta Artefacto Claude.
Filtrado
Observamos lo que sucede con la recuperación y la latencia al usar un filtro selectivo en el conjunto de datos para aproximadamente500mil elementos de los 15.3M de elementos que se encuentran en la Categoría de Suministros para mascotas (aproximadamente3% del corpus):
Para ver la gráfica completa, consulta Artefacto Claude.
Podemos observar que el filtro selectivo del 3% puede hacer que las consultas sean significativamente más caras. Para la cuantificación binaria con valores limit más bajos, esto fue aproximadamente 4veces más caro para lograr una recuperación del 90-95% en comparación con las consultas sin filtro.
Las mejoras futuras en Lucene 10, que admitan estrategias de búsqueda Acorn-1 para Mundos pequeños jerárquicamente navegables, podrían mejorar este proceso. Sin embargo, realizar ENN cuando el número de candidatos solicitados supera el número de vectores que coinciden con el filtro de metadatos dentro de un segmento, demuestra que la selectividad del filtro juega un papel importante en el rendimiento de las consultas, independientemente del régimen de cuantización seleccionado.
Simultaneidad
Estas pruebas escalan las solicitudes simultáneas entre 1, 10 y 100 en los diversos valores limit al usar cuantización escalar y binaria. numCandidates se seleccionan eligiendo valores que permiten alcanzar un 90-95% de recall:
Para ver la gráfica completa, consulta Artefacto Claude.
Observamos que la cuantización escalar logra sustancialmente mayor QPS en todos los valores del límite, probablemente porque se realiza menos trabajo por consulta con menor numCandidates y porque no se realiza la revalorización. Observamos cuellos de botella sustanciales en la CPU, como lo indica que los gráficos de concurrencia 10 y concurrencia 100 suelen estar muy cerca el uno del otro, lo que indica que se observaría una mayor latencia.
Un punto de datos excepcional es el límite 10, concurrencia 100 para la cuantización escalar que produce un QPS significativamente mayor. Esto se debe probablemente a la falta de re-evaluación y a que valores bajos de limit significa que se realizan menos comparaciones para esta query, lo que permite que cada solicitud se devuelva más rápidamente y que los núcleos estén disponibles para servir otras queries.
Escalar horizontalmente la cantidad de vCPU disponibles para atender solicitudes, ya sea escalando verticalmente el nivel del nodo de búsqueda o escalando horizontalmente la cantidad de nodos de búsqueda desde el mínimo de 2 hasta 32 nodos, podría ayudar a resolver cuellos de botella de concurrencia y permitirle escalar hasta miles de QPS.
particionado
También observamos qué sucedería si el clúster y la colección se fragmentaran (en _id) y se emitieran consultas sin filtrar contra un índice cuantificado binario.
Para ver la gráfica completa, consulta Artefacto Claude.
Aquí, vemos que los resultados particionado tienen un mayor QPS en el límite 10 ya que se puede proporcionar un valor inferior de numCandidates para obtener resultados en el rango de recuerdo 90-95%. Esto se debe a que el conjunto de datos 15.3M está repartido en tres particiones, cada uno de los cuales tiene sus propios índices llenos de 5.1M vectores repartidos en segmentos que contienen grafos HNSW. Funcionalmente estamos realizando una búsqueda menos avanzada donde es más probable que cada consulta dispersa y recopilada a través de 3 particiones simultáneamente pueda hallar los n vectores más cercanos. Por esta razón, el QPS es ligeramente superior cuando se particiona, ya que se puede reducir numCandidates y tener más núcleos disponibles para servir queries, pero la diferencia no es lo suficientemente significativa como para justificar el aumento del costo de particionar el clúster. La mayoría de las veces deberías particionar tu clúster por razones relacionadas con tu carga de trabajo operativa, no porque necesites escalar el rendimiento para la búsqueda vectorial.
Nota
Los valores son similares para el límite 100 y el número de candidatos 200. Se espera que esto funcione mejor en consultas filtradas con una coincidencia inteligente de claves de fragmentos como filtro.