Descripción general del punto de referencia de búsqueda vectorial de MongoDB

cuantización

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

Dimensionalidad vectorial

Utilizamos el modelo de Voyage AI para integrar los conjuntos de datos de vectores medianos (voyage-3-large 5.5M) y grandes (15.3M). Elegimos este modelo de integración por su excelente rendimiento en numerosas pruebas de IR y porque está entrenado con el aprendizaje de representación de Matryoshka y la cuantificación. Por lo tanto, funciona bien en dimensiones más pequeñas con la cuantificación activada, incluso con volúmenes de vectores más altos.

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"
      }
    ]
  }
)

Al igual que las diferentes representaciones en cada posición, las diferentes dimensionalidades afectan la capacidad de representación de cada vector. Por lo tanto, se puede lograr una mayor precisión con 2048vectores d en comparación con los 256vectores d, especialmente al medir con una 2048línea base ENN flotante d.

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

Filtrado

También creamos una definición de índice separada en la colección que contiene todos los 15.3M elementos, que incluye filtros en dos campos para permitir consultas prefiltradas en 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, que gestionan los cálculos vectoriales independientemente de la carga de trabajo de la base de datos principal y hacen un uso eficiente de las instancias de hardware dedicadas. Todas las pruebas se realizaron con un M20 clúster base, pero, según el tipo de prueba, reconfiguramos los nodos de búsqueda utilizados para que se ajustaran mejor a nuestro caso de prueba. Todas las pruebas se ejecutaron con nodos de búsqueda en AWS 1us-east-, con una2 instancia EC también en us-east-1 realizando solicitudes. Hay tres tipos de nodos de búsqueda que se pueden aprovisionar en AWS, que varían en cuanto a la capacidad 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 la fragmentación de nuestro clúster y colección en el _id campo en el rendimiento del sistema, centrándonos en la concurrencia de solicitudes de 10 y 100 para el gran índice binario cuantificado.