Esta página explora los resultados de nuestra búsqueda de vectores de MongoDB punto de referencia de rendimiento.
Resumen de resultados
En 15.3M vectores utilizando
voyage-3-largeincrustaciones en dimensiones 2048, MongoDB Vector Search con cuantificación configurada conserva una precisión del 90-95% con una latencia de consulta de < 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 cuantificación.
Los filtros selectivos pueden mejorar o empeorar el rendimiento según el valor seleccionado para
numCandidates.El costo adicional de volver a puntuar para la cuantificación binaria se refleja en un menor rendimiento cuando se ejecutan cargas de trabajo altamente concurrentes.
La fragmentación mejora ligeramente el rendimiento, pero aún así recomendamos escalar la cantidad de nodos de búsqueda o la cantidad de núcleos disponibles en un nodo de búsqueda para mejorar el rendimiento.
Análisis de recuperación y latencia en un punto de referencia 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 el gráfico completo, consulte la Artefacto de 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 trabajamos con un conjunto de datos grande, recomendamos tener una dimensionalidad de al menos 1024d y aplicar cuantificación a escala que tener una dimensionalidad menor y no usar cuantificación, siendo la cantidad de vectores solicitados para el caso de uso también un factor.
Resultados de referencia más amplios
Para el conjunto de datos vectoriales más grande, 15.3M, fijamos la dimensionalidad en 2048d y examinamos el impacto de la cuantificación, el filtrado y la concurrencia en el rendimiento. Optamos por 2048d basándonos en los resultados del conjunto de pruebas anterior, que mostraban que las dimensiones más altas conservaban la recuperación de forma más favorable, aunque 1024d probablemente habría sido igual de eficaz para alcanzar el objetivo de recuperación 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 cuando se utiliza un filtro selectivo en el conjunto de datos para ~500k artículos de los 15.3M artículos que se encuentran en la categoría Suministros para mascotas (~3% 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 futuras mejoras en Lucene,10 que admiten1 estrategias de búsqueda Acorn- para mundos pequeños navegables jerárquicamente, podrían mejorar este proceso. Sin embargo, realizar ENN cuando el número de candidatos solicitados excede 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 la consulta, independientemente del régimen de cuantificación seleccionado.
Simultaneidad
Estas pruebas escalan las solicitudes concurrentes entre 1, 10 y 100 en los distintos valores limit al usar cuantificación escalar y binaria. numCandidates se seleccionan eligiendo valores que permitan alcanzar un 90-95% de recuperación:
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 cuantificación escalar, lo que produce un QPS significativamente mayor. Esto probablemente se deba a la falta de repunte, y los valores limit más bajos implican menos comparaciones para esta consulta, lo que permite que cada solicitud regrese más rápido y que los núcleos estén disponibles para atender otras consultas.
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 fragmentados tienen un QPS más alto en el límite 10, ya que se puede proporcionar el valor inferior de numCandidates para producir resultados en el rango de recuperación del 90-95%. Esto se debe a que el conjunto de datos 15.3M está dividido en tres fragmentos, cada uno de los cuales tiene sus propios índices llenos de 5.1M vectores distribuidos en segmentos que contienen grafos HNSW. Funcionalmente, estamos realizando una búsqueda menos avanzada donde es más probable que cada dispersión de consultas recopilada en 3 fragmentos simultáneamente pueda encontrar los n vectores más cercanos. Por esta razón, el QPS es ligeramente mayor al fragmentar, ya que se puede reducir numCandidates y tener más núcleos disponibles para atender consultas, pero la diferencia no es tan significativa como para justificar el aumento del costo de fragmentar el clúster. La mayoría de las veces, se debe fragmentar el clúster por razones relacionadas con la carga de trabajo operativa, no porque se necesite escalar el rendimiento para la búsqueda de vectores.
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.