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 filtradas como sin filtrar, contra el gran conjunto de datos indexados:

# 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 escala con Nodos de Búsqueda Dedicados, los cuales gestionan los cálculos vectoriales independientemente de la carga de trabajo primaria de la base de datos y aprovechan eficientemente instancias de hardware dedicadas. Todas las pruebas se realizaron utilizando un clúster base M20, pero, dependiendo del tipo de prueba, reconfiguramos los Nodos de búsqueda utilizados para adaptarse mejor a nuestro caso de prueba. Todas las pruebas se realizaron utilizando Nodos de búsqueda en AWS us-east-1, con una instancia EC2 también en us-east-1 realizando solicitudes. Hay tres tipos de nodos de búsqueda que puedes provisionar en AWS, los cuales varían en términos de disco, RAM y vCPU disponibles:

binData Compresión de vectores

Para el gran conjunto de datos, aprovechamos una función adicional llamada compresión vectorial, que reduce la huella de cada vector en la colección de origen en aproximadamente un 60%. Esto acelera el paso dentro de una consulta cuando los ID se hidratan en la colección de origen, y es un paso recomendado para todas las cargas de trabajo grandes.

Simultaneidad

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

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.