Descripción general de la evaluación comparativa (benchmark) de MongoDB Vector Search

cuantización

La cuantización reduce la precisión de las incrustaciones vectoriales para disminuir el uso de memoria y mejorar la velocidad de búsqueda, con compensaciones en la precisión de la búsqueda.

Dimensionalidad vectorial

Utilizamos el modelo voyage-3-large de Voyage IA para incrustar los conjuntos de datos de vectores de tamaño medio (5.5M) y grande (15.3M) conjuntos de datos de vectores. Elegimos este modelo de incrustación por su excelente rendimiento en muchos benchmarks IR y por haber sido entrenado considerando tanto el Aprendizaje en Representación Matrioska como la cuantización. Por lo tanto, se desempeña bien en dimensiones bajas con cuantización habilitada, incluso con altos volúmenes de vectores.

Aprovechamos la indexación en vistas para producir campos adicionales que dividen las primeras N dimensiones del vector de dimensiones de origen 2048 para producir 1024, 512 y 256 vectores de dimensiones e indexarlos como lo haríamos con el campo de origen.

db.createView(
  "all_dims_amazon_dataset",
  "2048d_amazon_dataset",
  [
    {
      $addFields: {
        "1024_embedding": { $slice: ["$embedding", 1024] },
        "512_embedding": { $slice: ["$embedding", 512] },
        "256_embedding": { $slice: ["$embedding", 256] }
      }
    }
  ]
)

db.all_dims_amazon_dataset.createSearchIndex(
  "all_dims_vector_index",
  "vectorSearch",
  {
    "fields": [
      {
        "numDimensions": 2048,
        "path": "embedding", // original 2048d embedding produced by voyage-3-large
        "quantization": "scalar", // adjust to binary when needed
        "similarity": "dotProduct",
        "type": "vector"
      },
      {
        "numDimensions": 1024,
        "path": "1024_embedding",
        "quantization": "scalar",
        "similarity": "cosine", // sliced embeddings aren't normalized, so must use cosine
        "type": "vector"
      },
      {
        "numDimensions": 512,
        "path": "512_embedding",
        "quantization": "scalar",
        "similarity": "cosine",
        "type": "vector"
      },
      {
        "numDimensions": 256,
        "path": "256_embedding",
        "quantization": "scalar",
        "similarity": "cosine",
        "type": "vector"
      }
    ]
  }
)

De manera similar a las diferentes representaciones en cada posición, las diferentes dimensiones afectan la capacidad de representación de cada vector. Por lo tanto, puedes lograr una mayor precisión con vectores de 2048dimensiones en comparación con vectores de 256dimensiones, especialmente cuando se mide frente a una línea base de ENN de coma flotante de 2048dimensiones.

Además de requerir más almacenamiento y memoria, los vectores de mayor dimensionalidad son algo más lentos de consultar en comparación con los vectores de menor dimensionalidad, pero esto se mitiga significativamente ya que MongoDB Vector Search aprovecha las instrucciones SIMD al realizar comparaciones vectoriales.

Filtrado

También creamos una definición de índice separada sobre la colección que contiene todos los artículos 15.3M, lo que incluye filtros en dos campos para habilitar consultas prefiltradas contra este conjunto de datos.

db.large_amazon_dataset.createSearchIndex(
  "vectorSearch",
  "large_vector_index",
  {
    "fields": [
      {
        "numDimensions": 2048,
        "path": "embedding",
        "quantization": "scalar", // adjust to binary when needed
        "similarity": "dotProduct",
        "type": "vector"
      },
      {
        "path": "category",
        "type": "filter"
      },
      {
        "path": "price",
        "type": "filter"
      }
    ]
  }
)

Ejecutamos consultas de búsqueda vectorial, tanto sin filtro como con filtro, en el gran conjunto de datos indexado:

# unfiltered query
query = [
  {
    "$vectorSearch": {
      "index": "large_vector_index",
      "path": "embedding",
      "queryVector": embedding.tolist(),
      "limit": k,
      "numCandidates": candidates,
    }
  },
  {
    "$project": {"embedding": 0}
  }
]

# filtered query
query = [
  {
    "$vectorSearch": {
      "index": "large_vector_index",
      "path": "embedding",
      "queryVector": embedding.tolist(),
      "limit": k,
      "numCandidates": candidates,
      "filter": {"$and": [{'price': {'$lte': 1000}}, {'category': {'$eq': "Pet Supplies"}}]}
    }
  },
  {
    "$project": {"embedding": 0}
  }
]

Configuración del nodo de búsqueda

El rendimiento de MongoDB Vector Search se escala con Search Nodes dedicados, que manejan los cálculos vectoriales por separado de la carga de trabajo principal de la base de datos y hacen un uso eficiente de las instancias de hardware dedicadas. Todas las pruebas se realizaron con un M20 clúster base, pero dependiendo del tipo de prueba, reconfiguramos los Search Nodes utilizados para que se ajustaran mejor a nuestro caso de prueba. Todas las pruebas se ejecutaron con Search Nodes en AWS 1us-east-, con una2 instancia EC también en us-east-1 realizando solicitudes. Hay tres tipos de Search Nodes que puede aprovisionar en AWS, que varían en términos de disco, RAM y vCPU disponibles:

binData Compresión de vectores

Para el conjunto de datos grande, aprovechamos una funcionalidad adicional llamada compresión vectorial, que reduce la huella de cada vector en la colección fuente en aproximadamente un 60%. Esto acelera el paso dentro de una query cuando los ID son hidratados en la colección fuente, y este es un paso recomendado para todas las cargas de trabajo grandes.

Simultaneidad

Evaluamos no solo la latencia de query en serie, sino también el rendimiento total/QPS cuando se emiten solicitudes 10 y 100 de manera simultánea.

particionado

Evaluamos el impacto de particionar nuestro clúster y la colección en el campo _id sobre el rendimiento del sistema, centrando el análisis en la concurrencia de solicitudes de 10 y 100 para el índice binario cuantificado grande.