Filtros en coincidencias de vectores

Cuando realizas la coincidencia de vectores en Vertex Matching Engine, puedes restringir las búsquedas a un subconjunto del índice mediante reglas booleanas. Puedes especificar predicados booleanos que le indiquen a Matching Engine qué vectores en el índice se deben ignorar de las búsquedas de similitud.

Atributos vectoriales

Imagina una aplicación de ejemplo que realiza una búsqueda de similitud vectorial en una base de datos de vectores. Cada vector también se describe con cero o más atributos (o tokens) de cada una de varias categorías de atributos (o espacios de nombres).

En esta aplicación de ejemplo, los vectores se etiquetan con color y shape:

  • color y shape son espacios de nombres.
  • red y blue son tokens del espacio de nombres color.
  • square y circle son tokens del espacio de nombres shape.

Especifica atributos vectoriales

Para especificar atributos de vectores en la aplicación de ejemplo, haz lo siguiente:

  • Para especificar un “círculo rojo”, usa {color: red}, {shape: circle}.
  • Para especificar un "cuadrado rojo y azul", usa {color: red, blue}, {shape: square}.
  • Para especificar un objeto sin color, no omitas el espacio de nombres “color” en las restricciones.

Consulta la sección “Formato de datos de entrada para especificar atributos y espacios de nombres” a fin de ver el esquema de especificación de estos datos.

Consultas

  • Una consulta que especifica, **{color: red, blue}, {shape: square, circle}**, coincide con todos los puntos de la base de datos que cumplen con **(red || blue) && (square || circle)**. Las consultas expresan un Y en los espacios de nombres y un O dentro de cada espacio de nombres.
  • Una consulta que especifique, **{color: red}**, coincidirá con todos los objetos **red** de cualquier tipo, sin restricción en **shape**.

Lista de bloqueo

Para habilitar situaciones más avanzadas, admitimos una forma especial de negación, conocida como tokens de lista de bloqueo. Cuando una consulta incluye un token en la lista de bloqueo, las coincidencias se excluirán con cualquier punto de datos que tenga el token de lista de bloqueo. Ten en cuenta que, si un espacio de nombres de consulta solo tiene tokens de lista de bloqueo, todos los puntos que no estén en la lista de bloqueo explícita coincidirán, de la misma manera en que un espacio de nombres vacío coincide con todos los puntos.

Los puntos de datos también pueden incluir en la lista de bloqueo un token, sin incluir las coincidencias con cualquier consulta que especifique ese token.

A continuación, se presentan algunos ejemplos a fin de aclarar las capacidades del filtro. Definamos los siguientes datos con los tokens especificados:

  1. {} // el conjunto vacío coincide con todo

rojo

// solo un token "rojo"

blue

// solo un token "azul"

orange

// solo un token "naranja"

rojo, azul

// varios tokens

rojo, !azul

// rechazar el token "azul"

rojo, azul, !azul

// un caso extraño edge

azul

// de solo rechazo (similar a empty-set)

Este es el comportamiento intuitivo que la mayoría de las personas esperan del sistema.

  • Los espacios de nombres de consulta vacíos son comodines para coincidir con todos. Por ejemplo, Q:{} coincide con DB:{color:red}
  • Los espacios de nombres de puntos de datos vacíos no. Por ejemplo, Q:{color:red} no coincide con DB:{}.

Gráfico que muestra los puntos de consulta y base de datos

Especifica espacios de nombres y tokens en los datos de entrada

Para aprender a estructurar los datos de entrada en general, consulta Estructura y formato de los datos de entrada.

En esta sección, se describe cómo especificar los espacios de nombres y los tokens asociados con cada vector de entrada.

JSON

  • Para el registro de cada vector, agrega un campo llamado "restricts", que debe contener un array de objetos, cada uno de los cuales será un espacio de nombres.

    • Cada objeto debe tener un campo llamado "namespace". Este es el TokenNamespace.namespace.
    • El valor del campo “allow”, si está presente, debe ser un arreglo de strings. Esta es la lista de TokenNamespace.string_tokens.
    • El valor del campo “deny”, si está presente, debe ser un arreglo de strings. Esta es la lista de TokenNamespace.string_denylist_tokens.

Los siguientes son dos registros de ejemplo en formato JSON:

{"id": "42", "embedding": [0.5, 1.0], "restricts": [{"namespace": "class",
"allow": ["cat", "pet"]},{"namespace": "category", "allow": ["feline"]}]}
{"id": "43", "embedding": [0.6, 1.0], "restricts": [{"namespace":
"class", "allow": ["dog", "pet"]},{"namespace": "category", "allow":
["canine"]}]}

Avro

Los registros de Avro deben tener una estructura similar a la definida en formato JSON. En particular, la estructura debe cumplir con el siguiente esquema:

{
   "type": "record",
   "name": "FeatureVector",
   "fields": [
      {"name": "id", "type": "string"},
      {"name": "embedding",
       "type": {
          "type": "array",
    "items": "float"
  }
      },
      {"name": "restricts",
       "type": [
         "null",
         {"type": "array",
          "items": {
          "type": "record",
          "name": "Restrict",
          "fields": [
            {"name": "namespace", "type": "string"},
            {"name": "allow", "type": ["null", {"type": "array", "items": "string"}]},
            {"name": "deny", "type": ["null", {"type": "array", "items": "string"}]}]}}]},
      {"name": "crowding_tag", "type": ["null", "string"]}]
}

¿Qué sigue?