En esta página, se documenta la versión 15.7.1 de AlloyDB Omni con la opción de implementación de Kubernetes. Elige otra opción de implementación.

Se usó la API de Cloud Translation para traducir esta página.

Mide la recuperación de consultas vectoriales

Selecciona una versión de la documentación:

En esta página, se describe cómo medir la recuperación de las búsquedas vectoriales en AlloyDB Omni. En el contexto de la búsqueda de vectores, la recuperación hace referencia al porcentaje de vectores que devuelve el índice y que son vecinos más cercanos verdaderos. Por ejemplo, si una consulta de vecino más cercano para los 20 vecinos más cercanos devuelve 19 de los vecinos más cercanos de verdad fundamental, la recuperación será 19/20*100 = 95%.

En una búsqueda de vectores, la recuperación es importante porque mide el porcentaje de resultados relevantes que se recuperan de una búsqueda. La recuperación te ayuda a evaluar la precisión de los resultados de una búsqueda de vecino más cercano aproximado (ANN) en comparación con los resultados de una búsqueda de k vecinos más cercanos (KNN).

El ANN es un algoritmo que encuentra datos similares a un punto de búsqueda determinado y mejora la velocidad al encontrar los vecinos aproximados en lugar de los vecinos reales. Cuando usas ANN, equilibras la velocidad con la recuperación.

KNN es un algoritmo que encuentra los k vectores más similares a un vector de consulta determinado dentro de un conjunto de datos, según una métrica de similitud. k es la cantidad de vecinos que deseas que devuelva la consulta.

Puedes medir la recuperación de tu búsqueda de vectores para diferentes índices de vectores, incluidos los siguientes:

Vecinos más cercanos escalables (ScaNN): Es un algoritmo para la búsqueda eficiente de similitud de vectores.
Hierarchical Navigable Small World (HNSW): Es un algoritmo basado en grafos que se usa para la búsqueda eficiente de vecinos más cercanos aproximados en bases de datos de vectores.
Archivo invertido con compresión plana (IVFFLAT) y archivo invertido plano (IVF): Son tipos de índices vectoriales que se usan para las búsquedas de ANN, en especial en bases de datos como la extensión pgvector de PostgreSQL.

En esta página, se supone que conoces PostgreSQL, AlloyDB Omni y la búsqueda vectorial.

Antes de comenzar

Instala o actualiza la extensión pgvector.
1. Si no está instalada la extensión pgvector, instala la versión vector de la extensión 0.8.0.google-3 o una posterior para almacenar las embeddings generadas como valores vector. La extensión vector incluye operadores y funciones pgvector. Google extiende esta versión de pgvector con optimizaciones para AlloyDB Omni.
```
CREATE EXTENSION IF NOT EXISTS vector WITH VERSION '0.8.0.google-3';
```
  Para obtener más información, consulta Almacena, indexa y consulta vectores.
2. Si la extensión pgvector ya está instalada, actualiza la extensión vector a la versión 0.8.0.google-3 o posterior para obtener capacidades de evaluación de recuperación.
```
ALTER EXTENSION vector UPDATE TO '0.8.0.google-3';
```
Para crear índices de ScaNN, instala la extensión alloydb_scann.
```
CREATE EXTENSION IF NOT EXISTS alloydb_scann;
```

Evalúa la recuperación para las búsquedas vectoriales en un índice de vectores

Puedes encontrar la recuperación de una búsqueda vectorial en un índice de vectores para una configuración determinada con la función evaluate_query_recall. Esta función te permite ajustar tus parámetros para lograr los resultados de recuperación de la búsqueda vectorial que deseas. La recuperación es la métrica que se usa para la calidad de la búsqueda y se define como el porcentaje de los resultados devueltos que son objetivamente más cercanos a los vectores de la búsqueda. La función evaluate_query_recall está activada de forma predeterminada.

Cómo encontrar la recuperación para una búsqueda vectorial

Abre un editor de SQL en AlloyDB Studio o un cliente psql.
Crea un índice de vectores de ScaNN, HNSW o IVFFLAT.

Nota: Puedes crear índices de diferentes métodos en una sola columna de vectores y comparar el rendimiento de tu búsqueda con cada uno de los índices creados. Esto solo se recomienda para cargas de trabajo de desarrollo.
Asegúrate de que la marca enable_indexscan esté activada. Si la marca está desactivada, no se elige ningún análisis de índice y la recuperación para todos los índices es 1.

Ejecuta la función evaluate_query_recall, que toma la búsqueda como parámetro y devuelve la siguiente recuperación:

SELECT * FROM evaluate_query_recall( QUERY_TEXT, QUERY_TIME_CONFIGURATIONS, INDEX_METHODS )

Antes de ejecutar este comando, realiza los siguientes reemplazos:

QUERY_TEXT: La consulta en SQL, incluida en $$.
QUERY_TIME_CONFIGURATIONS: Optional: the configuration that you can set for the ANN query. This must be in JSON format. The default value is NULL.

INDEX_METHODS: Optional: a text array that contains different vector index methods for which you want to calculate the recall. If you set an index method for which a corresponding index doesn't exist, the recall is 1. The input must be a subset of {scann, hnsw, ivf, ivfflat}. If no value is provided, the ScaNN method is used.

To view differences between query recall and execution time, change the query time parameters for your index.

The following table lists query time parameters for ScaNN, HNSW, and IVF/IVFFLAT index methods. The parameters are formatted as {"scann.num_leaves_to_search":1, "scann.pre_reordering_num_neighbors":10, "hnsw.ef_search": 1}.

Index type	Parameters
ScaNN	`scann.num_leaves_to_search` `scann.pre_reordering_num_neighbors` `scann.pct_leaves_to_search` `scann.num_search_threads`
HNSW	`hnsw.ef_search` `hnsw.iterative_scan` `hnsw.max_scan_tuples` `hnsw.scan_mem_multiplier`
IVF	`ivf.probes`
IVFFLAT	`ivfflat.probes` `ivfflat.iterative_scan` `ivfflat.max_probes`

For more information about ScaNN index methods, see AlloyDB Omni ScaNN Index reference. For more information about HNSW and IVF/IVFFLAT index methods, see pgvector.

Optional: You can also add configurations from pg_settings to the QUERY_TIME_CONFIGURATIONS. For example, to run a query with columnar engine scan enabled, add the following config from pg_settings as {"google_columnar_engine.enable_columnar_scan" : on}.

The configurations are set locally in the function. Adding these configurations doesn't impact the configurations that you set in your session. If you don't set any configurations, AlloyDB uses all of the configurations that you set in the session. You can also set only those configurations that are best suited for your use case.
Optional: To view the default configuration settings, run the SHOW command or view the pg_settings.

Optional: If you have a ScaNN index for which you want to tune the recall, see the tuning parameters in ScaNN index reference.

The following is an example output, where ann_execution_time is the time that it takes a vector query to execute using index scans. ground_truth_execution_time is the time that it takes the query to run using a sequential scan.

ann_execution_time and ground_truth_execution_time are different from but directly dependent on Execution time in the query plan. Execution time is the total time to execute the query from the client.

t=# SELECT * FROM evaluate_query_recall( $$ SELECT id FROM t1 ORDER BY val <=> '[1000,1000,49000]' LIMIT 10 $$, '{"scann.num_leaves_to_search":1, "scann.pre_reordering_num_neighbors":10, "hnsw.ef_search": 1}', ARRAY['scann', 'hnsw']);
NOTICE:  Recall is 1. This might mean that the vector index is not present on the table or index scan not chosen during query execution.
id|               query                                               |                                         configurations                                         |  recall |ann_execution_time | ground_truth_execution_time |  index_type
----+-------------------------------------------------------------------+------------------------------------------------------------------------------------------------+--------+--------------------+-----------------------------+------------
1 |  SELECT id FROM t1 ORDER BY val <=> '[1000,1000,49000]' LIMIT 10  | {"scann.num_leaves_to_search":1, "scann.pre_reordering_num_neighbors":10, "hnsw.ef_search": 1} |    0.5 |               4.23 |                     118.211 | scann
2 |  SELECT id FROM t1 ORDER BY val <=> '[1000,1000,49000]' LIMIT 10  | {"scann.num_leaves_to_search":1, "scann.pre_reordering_num_neighbors":10, "hnsw.ef_search": 1} |      1 |            107.198 |                     118.211 | hnsw
(2 rows)

Si el resultado es Recall is 1 (la recuperación de la búsqueda es 1), esto podría indicar que el índice vectorial no está presente en la tabla o que no se eligió durante la ejecución de la consulta. Esta situación se produce cuando no existe un índice de vectores en la tabla o cuando el optimizador no elige el análisis del índice de vectores.
Nota: No uses columnas en las consultas cuyo valor pueda generar valores de NULL. Si esas columnas son obligatorias, agrega la función COALESCE a la consulta.
Si la búsqueda es select id, name from table order by embedding <->'[1,2,3]' LIMIT 10;. y el valor esperado del nombre de la columna es NULL, cambia la búsqueda a una de las siguientes opciones:
select id, COALESCE(name, 'NULL') as name from table order by embedding <-> '[1,2,3]' LIMIT 10;

O
select id from table order by embedding <-> '[1,2,3]' LIMIT 10;