Gestisci gli indici vettoriali

Questo documento descrive come creare e gestire gli indici vettoriali per accelerare le ricerche Vector Search.

Un indice vettoriale è una struttura di dati progettata per consentire alla funzione VECTOR_SEARCH e alla funzione AI.SEARCH di essere eseguite in modo più efficiente, in particolare su set di dati di grandi dimensioni. Quando si utilizza un indice, queste funzioni di ricerca utilizzano algoritmi Approximate Nearest Neighbor (ANN) per ridurre la latenza delle query e il costo di calcolo. Sebbene ANN introduca un certo grado di approssimazione, il che significa che il richiamo potrebbe non essere del 100%, i miglioramenti del rendimento in genere offrono un vantaggio per la maggior parte delle applicazioni.

Ruoli e autorizzazioni

Per creare un indice vettoriale, devi disporre dell'autorizzazione IAM bigquery.tables.createIndex sulla tabella in cui stai creando l'indice. Per eliminare un indice vettoriale, devi disporre dell'autorizzazione bigquery.tables.deleteIndex. Ciascuno dei seguenti ruoli IAM predefiniti include le autorizzazioni necessarie per lavorare con gli indici vettoriali:

• BigQuery Data Owner (roles/bigquery.dataOwner)
• Editor dati BigQuery (roles/bigquery.dataEditor)

Scegliere un tipo di indice vettoriale

BigQuery offre due tipi di indici vettoriali, IVF e TreeAH, ciascuno dei quali supporta diversi casi d'uso. BigQuery supporta il batch per la ricerca vettoriale elaborando più righe dei dati di input in VECTOR_SEARCH. Per i piccoli batch di query, sono preferibili gli indici IVF. Per i batch di query di grandi dimensioni, sono preferiti gli indici TreeAH, creati con l'algoritmo ScaNN di Google.

Indice IVF

IVF è un indice di file invertito che utilizza un algoritmo k-means per raggruppare i dati vettoriali e quindi li partiziona in base a questi cluster. Le funzioni VECTOR_SEARCH e AI.SEARCH possono utilizzare queste partizioni per ridurre la quantità di dati che devono leggere per determinare un risultato.

Indice TreeAH

Il tipo di indice TreeAH prende il nome dalla combinazione di una struttura ad albero e dall'utilizzo dell'hashing asimmetrico (AH), una tecnica di quantizzazione di base dell'algoritmo ScaNN sottostante. Un indice TreeAH funziona nel seguente modo:

1. La tabella di base è suddivisa in shard più piccoli e gestibili.
2. Viene addestrato un modello di clustering, con il numero di cluster derivato dall'opzione leaf_node_embedding_count nell'argomento tree_ah_options dell'istruzione CREATE VECTOR INDEX.
3. I vettori vengono compressi con la quantizzazione del prodotto, una tecnica che riduce la memoria utilizzata. I vettori compressi vengono quindi archiviati nelle tabelle dell'indice anziché nei vettori originali, riducendo così le dimensioni dell'indice vettoriale.
4. Quando viene eseguita la funzione VECTOR_SEARCH o AI.SEARCH, viene calcolato in modo efficiente un elenco di candidati per ogni vettore di query utilizzando l'hashing asimmetrico, ottimizzato a livello hardware per i calcoli della distanza approssimativa. Questi candidati vengono quindi riassegnati e riordinati utilizzando gli incorporamenti esatti.

L'algoritmo TreeAH è ottimizzato per le query batch che elaborano centinaia o più vettori di query. L'utilizzo della quantizzazione del prodotto può ridurre significativamente la latenza e i costi, potenzialmente di ordini di grandezza rispetto a IVF. Tuttavia, a causa dell'aumento dell'overhead, l'algoritmo IVF potrebbe essere più adatto quando hai un numero inferiore di vettori di query.

Ti suggeriamo di provare il tipo di indice TreeAH se il tuo caso d'uso soddisfa i seguenti criteri:

• La tabella contiene un massimo di 200 milioni di righe.

• Esegui spesso query batch di grandi dimensioni che coinvolgono centinaia o più vettori di query.

Per query in batch di piccole dimensioni con il tipo di indice TreeAH, VECTOR_SEARCH o AI.SEARCH potrebbero tornare alla ricerca brute force. In questo caso, viene fornito un IndexUnusedReason per spiegare perché l'indice vettoriale non è stato utilizzato.

Crea un indice vettoriale IVF

Per creare un indice vettoriale IVF, utilizza l'istruzione DDL (Data Definition Language) CREATE VECTOR INDEX:

1. Vai alla pagina BigQuery.

   Vai a BigQuery

2. Nell'editor di query, esegui la seguente istruzione SQL:

   Per creare un indice vettoriale IVF:

   CREATE [ OR REPLACE ] VECTOR INDEX [ IF NOT EXISTS ] INDEX_NAME
   ON DATASET_NAME.TABLE_NAME(COLUMN_NAME)
   STORING(STORED_COLUMN_NAME [, ...])
   OPTIONS(index_type = 'IVF',
     distance_type = 'DISTANCE_TYPE',
     ivf_options = '{"num_lists":NUM_LISTS}')

   Sostituisci quanto segue:

   • INDEX_NAME: il nome dell'indice vettoriale che stai creando. Poiché l'indice viene sempre creato nello stesso progetto e set di dati della tabella di base, non è necessario specificarli nel nome.
   • DATASET_NAME: il nome del set di dati che contiene la tabella.
   • TABLE_NAME: il nome della tabella che contiene la colonna con i dati degli embedding.

   • COLUMN_NAME: il nome di una colonna che contiene i dati degli incorporamenti. La colonna deve essere di tipo ARRAY<FLOAT64> o, se utilizzi la generazione di embedding autonomi, di tipo STRUCT<result ARRAY<FLOAT64>, status STRING>.

     In tutti i casi, tutti gli elementi dell'array di embedding non devono essere NULL e tutti i valori della colonna devono avere le stesse dimensioni dell'array.

     Se il tipo di colonna è STRUCT<result ARRAY<FLOAT64>, status STRING>, il valore STRUCT può essere NULL o l'array result può essere NULL. Le righe con NULL per questi valori vengono ignorate.

   • STORED_COLUMN_NAME: il nome di una colonna di primo livello della tabella da archiviare nell'indice vettoriale. Il tipo di colonna non può essere RANGE. Le colonne archiviate non vengono utilizzate se la tabella ha una policy di accesso a livello di riga o se la colonna ha un tag di criteri. Per informazioni su come attivare le colonne archiviate, consulta Archivia le colonne e pre-filtraggio.

   • DISTANCE_TYPE: specifica il tipo di distanza predefinito da utilizzare quando si esegue una Vector Search utilizzando questo indice. I valori supportati sono EUCLIDEAN, COSINE e DOT_PRODUCT. EUCLIDEAN è il valore predefinito.

     La creazione dell'indice utilizza sempre la distanza EUCLIDEAN per l'addestramento, ma la distanza utilizzata nella funzione di ricerca può essere diversa.

     Se specifichi un valore per l'argomento distance_type della funzione VECTOR_SEARCH o AI.SEARCH, questo valore viene utilizzato al posto del valore DISTANCE_TYPE.

   • NUM_LISTS: un valore INT64 che specifica il numero di elenchi in cui l'indice IVF raggruppa e poi suddivide i dati vettoriali. Questo valore deve essere pari o inferiore a 5000. Durante l'indicizzazione, i vettori vengono assegnati all'elenco corrispondente al baricentro del cluster più vicino. Se ometti questo argomento, BigQuery determina un valore predefinito in base alle caratteristiche dei dati. Il valore predefinito è adatto alla maggior parte dei casi d'uso.

     NUM_LISTS controlla la granularità dell'ottimizzazione delle query. Valori più alti creano più elenchi, quindi puoi impostare l'opzione fraction_lists_to_search della funzione di ricerca per analizzare una percentuale inferiore dell'indice. Ad esempio, la scansione dell'1% di 100 elenchi anziché la scansione del 10% di 10 elenchi. In questo modo, puoi controllare in modo più preciso la velocità di ricerca e il richiamo, ma il costo di indicizzazione aumenta leggermente. Imposta questo valore dell'argomento in base alla precisione con cui devi ottimizzare l'ambito della query.

L'esempio seguente crea un indice vettoriale sulla colonna embedding di my_table:

CREATE TABLE my_dataset.my_table(embedding ARRAY<FLOAT64>);

CREATE VECTOR INDEX my_index ON my_dataset.my_table(embedding)
OPTIONS(index_type = 'IVF');

L'esempio seguente crea un indice vettoriale sulla colonna embedding di my_table e specifica il tipo di distanza da utilizzare e le opzioni IVF:

CREATE TABLE my_dataset.my_table(embedding ARRAY<FLOAT64>);

CREATE VECTOR INDEX my_index ON my_dataset.my_table(embedding)
OPTIONS(index_type = 'IVF', distance_type = 'COSINE',
ivf_options = '{"num_lists": 2500}')

L'esempio seguente crea una tabella con la generazione di embedding autonomi abilitata e crea un indice vettoriale sulla tabella. La colonna di embedding description_embedding viene generata automaticamente in base alla colonna description.

CREATE TABLE mydataset.products (
  description STRING,
  description_embedding STRUCT<result ARRAY<FLOAT64>, status STRING>
    GENERATED ALWAYS AS (
      AI.EMBED(description, connection_id => 'us.example_connection',
        endpoint => 'text-embedding-005'))
    STORED OPTIONS( asynchronous = TRUE ));

CREATE VECTOR INDEX my_index ON my_dataset.my_table(description_embedding)
OPTIONS(index_type = 'IVF');

Crea un indice vettoriale TreeAH

Per creare un indice vettoriale TreeAH, utilizza l'istruzione CREATE VECTOR INDEX DDL (Data Definition Language):

1. Vai alla pagina BigQuery.

   Vai a BigQuery

2. Nell'editor di query, esegui la seguente istruzione SQL:

   CREATE [ OR REPLACE ] VECTOR INDEX [ IF NOT EXISTS ] INDEX_NAME
   ON DATASET_NAME.TABLE_NAME(COLUMN_NAME)
   STORING(STORED_COLUMN_NAME [, ...])
   OPTIONS(index_type = 'TREE_AH',
     distance_type = 'DISTANCE_TYPE',
     tree_ah_options = '{"leaf_node_embedding_count":LEAF_NODE_EMBEDDING_COUNT,
       "normalization_type":"NORMALIZATION_TYPE"}')

   Sostituisci quanto segue:

   • INDEX_NAME: il nome dell'indice vettoriale che stai creando. Poiché l'indice viene sempre creato nello stesso progetto e set di dati della tabella di base, non è necessario specificarli nel nome.
   • DATASET_NAME: il nome del set di dati che contiene la tabella.
   • TABLE_NAME: il nome della tabella che contiene la colonna con i dati degli embedding.

   • COLUMN_NAME: il nome di una colonna che contiene i dati degli embedding. La colonna deve essere di tipo ARRAY<FLOAT64> o, se utilizzi la generazione di embedding autonomi, di tipo STRUCT<result ARRAY<FLOAT64>, status STRING>.

     In tutti i casi, tutti gli elementi dell'array di embedding non devono essere NULL e tutti i valori della colonna devono avere le stesse dimensioni dell'array. La dimensione dell'array deve essere almeno 2.

     Se il tipo di colonna è STRUCT<result ARRAY<FLOAT64>, status STRING>, il valore STRUCT può essere NULL o l'array result può essere NULL. Tutte le righe con NULL per questi valori vengono ignorate.

   • STORED_COLUMN_NAME: il nome di una colonna di primo livello nella tabella da archiviare nell'indice vettoriale. Il tipo di colonna non può essere RANGE. Le colonne archiviate non vengono utilizzate se la tabella ha una policy di accesso a livello di riga o se la colonna ha un tag di criteri. Per informazioni su come attivare le colonne archiviate, consulta Archivia colonne e pre-filtraggio.

   • DISTANCE_TYPE: un argomento facoltativo che specifica il tipo di distanza predefinito da utilizzare quando si esegue una Vector Search utilizzando questo indice. I valori supportati sono EUCLIDEAN, COSINE e DOT_PRODUCT. EUCLIDEAN è il valore predefinito.

     La creazione dell'indice utilizza sempre la distanza EUCLIDEAN per l'addestramento, ma la distanza utilizzata nella funzione di ricerca può essere diversa.

     Se specifichi un valore per l'argomento distance_type della funzione VECTOR_SEARCH o AI.SEARCH, questo valore viene utilizzato al posto del valore DISTANCE_TYPE.

   • LEAF_NODE_EMBEDDING_COUNT: un valore INT64 maggiore o uguale a 500 che specifica il numero approssimativo di vettori in ogni nodo foglia dell'albero creato dall'algoritmo TreeAH. L'algoritmo TreeAH divide l'intero spazio dati in un numero di elenchi, ciascuno dei quali contiene circa LEAF_NODE_EMBEDDING_COUNT punti dati. Un valore più basso crea più elenchi con meno punti dati, mentre un valore più alto crea meno elenchi con più punti dati. Il valore predefinito è 1000, che è appropriato per la maggior parte dei set di dati.

   • NORMALIZATION_TYPE: un valore STRING. I valori supportati sono NONE o L2. Il valore predefinito è NONE. La normalizzazione avviene prima di qualsiasi elaborazione, sia per i dati della tabella di base sia per i dati della query, ma non modifica la colonna di incorporamento COLUMN_NAME in TABLE_NAME. A seconda del set di dati, del modello di embedding e del tipo di distanza utilizzato durante la ricerca, la normalizzazione degli embedding potrebbe migliorare il recall.

L'esempio seguente crea un indice vettoriale sulla colonna embedding di my_table e specifica il tipo di distanza da utilizzare e le opzioni TreeAH:

CREATE TABLE my_dataset.my_table(id INT64, embedding ARRAY<FLOAT64>);

CREATE VECTOR INDEX my_index ON my_dataset.my_table(embedding)
OPTIONS (index_type = 'TREE_AH', distance_type = 'EUCLIDEAN',
tree_ah_options = '{"normalization_type": "L2"}');

Utilizzare gli indici vettoriali con la ricerca ibrida

Per migliorare il rendimento delle query di ricerca ibrida, puoi aggiungere al tuo indice vettoriale le informazioni sulle parole chiave necessarie per l'elaborazione di una ricerca lessicale specificando lexical_search_columns nell'istruzione CREATE VECTOR INDEX. Questa operazione può essere eseguita per qualsiasi tipo esistente di indice vettoriale, ad esempio IVF o TreeAH. La seguente istruzione CREATE VECTOR INDEX di esempio include informazioni sulle parole chiave. In questo esempio, l'opzione lexical_search_columns elenca tutte le colonne utilizzate per la parte lessicale di una query di ricerca ibrida. Qualsiasi colonna aggiunta all'elenco lexical_search_columns deve essere aggiunta anche come colonna archiviata nella clausola STORING:

CREATE [ OR REPLACE ] VECTOR INDEX [ IF NOT EXISTS ] INDEX_NAME
ON DATASET_NAME.TABLE_NAME(COLUMN_NAME)
STORING(STORED_COLUMN_NAME [, ...])
OPTIONS(
  index_type = 'INDEX_TYPE',
  distance_type = 'DISTANCE_TYPE',
  ivf_options = '{"num_lists":NUM_LISTS}'
  lexical_search_columns = [LEXICAL_COLUMN_NAME [, ...]])

L'esempio di ricerca ibrida seguente crea un indice vettoriale nella colonna di embedding in my_table. Le colonne header, content e footer vengono utilizzate per la ricerca lessicale nelle query di ricerca ibrida:

CREATE VECTOR INDEX `hybrid_index`
ON `my_dataset.my_table`(`embedding`)
    STORING(`header`, `content`, `footer`)
  OPTIONS (
    index_type = 'IVF',
    distance_type = 'EUCLIDEAN',
    lexical_search_columns = ['header', 'content', 'footer']);

Filtri

Le sezioni seguenti spiegano in che modo i prefiltri e i postfiltri influiscono sui risultati della ricerca vettoriale e come eseguire il prefiltraggio utilizzando colonne e partizioni archiviate nell'indice vettoriale.

Prefiltri e post-filtri

Nelle chiamate BigQuery VECTOR_SEARCH o AI.SEARCH, sia il pre-filtraggio sia il post-filtraggio servono a perfezionare i risultati di ricerca, applicando condizioni basate su colonne di metadati associate agli incorporamenti vettoriali. È importante comprendere le differenze, l'implementazione e l'impatto per ottimizzare le prestazioni, i costi e l'accuratezza delle query.

Il pre-filtraggio e il post-filtraggio sono definiti come segue:

• Pre-filtraggio: applica le condizioni di filtro prima che la ricerca del vicino più prossimo approssimato (ANN) esegua i calcoli della distanza sui vettori candidati. In questo modo, l'insieme di vettori presi in considerazione durante la ricerca viene ridotto. Di conseguenza, il pre-filtraggio spesso comporta tempi di query più rapidi e costi di calcolo ridotti, poiché la ricerca ANN valuta un numero inferiore di potenziali candidati.
• Post-filtraggio: applica le condizioni filtro dopo che i primi top_k vicini più prossimi sono stati identificati dalla ricerca ANN. In questo modo, l'insieme di risultati finali viene perfezionato in base ai criteri specificati.

La posizione della clausola WHERE determina se un filtro agisce come pre-filtro o post-filtro.

Per creare un pre-filtraggio, la clausola WHERE della query deve essere applicata all'argomento della tabella di base della funzione di ricerca. Affinché il pre-filtraggio esegua il pruning dei dati e ottimizzi la ricerca nell'indice, il predicato deve essere applicato a una colonna archiviata o a una colonna di partizionamento. Se il predicato si applica a qualsiasi altra colonna, inclusa una colonna in cluster non archiviata, agisce come post-filtraggio e genera una scansione completa.

Il seguente esempio mostra come creare un pre-filtraggio:

-- Pre-filter on a stored column. The index speeds up the query.
SELECT *
FROM
  VECTOR_SEARCH(
    (SELECT * FROM my_dataset.my_table WHERE type = 'animal'),
    'embedding',
    TABLE my_dataset.my_testdata);

SELECT *
FROM
  AI.SEARCH(
    (SELECT * FROM my_dataset.my_table WHERE type = 'animal'),
    'content',
    'dog');

-- Filter on a column that isn't stored. The index is used to search the
-- entire table, and then the results are post-filtered. You might see fewer
-- than 5 matches returned for some embeddings.
SELECT query.test_id, base.type, distance
FROM
  VECTOR_SEARCH(
    (SELECT * FROM my_dataset.my_table WHERE id = 123),
    'embedding',
    TABLE my_dataset.my_testdata,
    top_k => 5);

-- Use pre-filters with brute force. The data is filtered and then searched
-- with brute force for exact results.
SELECT query.test_id, base.type, distance
FROM
  VECTOR_SEARCH(
    (SELECT * FROM my_dataset.my_table WHERE id = 123),
    'embedding',
    TABLE my_dataset.my_testdata,
    options => '{"use_brute_force":true}');

Per creare un post-filtraggio, la clausola WHERE della query deve essere applicata all'esterno della funzione VECTOR_SEARCH, in modo da filtrare i risultati restituiti dalla ricerca.

Il seguente esempio mostra come creare un post-filtro:

-- Use post-filters. The index is used, but the entire table is searched and
-- the post-filtering might reduce the number of results.
SELECT query.test_id, base.type, distance
FROM
  VECTOR_SEARCH(
    TABLE my_dataset.my_table,
    'embedding',
    TABLE my_dataset.my_testdata,
    top_k => 5)
WHERE base.type = 'animal';

SELECT base.id, distance
FROM
  VECTOR_SEARCH(
    TABLE mydataset.base_table,
    'embedding',
    (SELECT embedding FROM mydataset.query_table),
    top_k => 10
  )
WHERE type = 'document' AND year > 2022

Quando utilizzi il post-filtraggio o quando i filtri della tabella di base che specifichi fanno riferimento a colonne non archiviate e quindi agiscono come post-filtri, il set di risultati finale potrebbe contenere meno di top_k righe, potenzialmente anche zero righe, se il predicato è selettivo. Se hai bisogno di un numero specifico di risultati dopo il filtro, valuta la possibilità di specificare un valore top_k più grande o di aumentare il valore fraction_lists_to_search nella chiamata di funzione di ricerca.

In alcuni casi, soprattutto se il prefiltro è molto selettivo, il prefiltraggio può anche ridurre le dimensioni del set di risultati. In questo caso, prova ad aumentare il valore fraction_lists_to_search nella chiamata di funzione di ricerca.

Pre-filtraggio con le colonne archiviate

Per migliorare ulteriormente l'efficienza dell'indice vettoriale, puoi specificare le colonne della tabella di base da archiviare nell'indice vettoriale. L'utilizzo delle colonne archiviate può ottimizzare le query che chiamano le funzioni VECTOR_SEARCH o AI.SEARCH nei seguenti modi:

• Anziché cercare in un'intera tabella, puoi chiamare una funzione di ricerca su un'istruzione di query che prefiltra la tabella di base con una clausola WHERE. Se la tabella ha un indice e filtri solo sulle colonne archiviate, BigQuery ottimizza la query filtrando i dati prima della ricerca e poi utilizzando l'indice per cercare nel set di risultati più piccolo. Se filtri in base a colonne non archiviate, BigQuery applica il filtro dopo la ricerca nella tabella o il post-filtraggio.

• Le funzioni VECTOR_SEARCH e AI.SEARCH restituiscono una struttura chiamata base che contiene tutte le colonne della tabella di base. Senza colonne archiviate, è necessaria una join potenzialmente costosa per recuperare le colonne archiviate in base. Se utilizzi un indice IVF e la query seleziona solo le colonne archiviate da base, BigQuery ottimizza la query per eliminare il join. Per gli indici TreeAH, la join con la tabella di base non viene rimossa. Le colonne archiviate negli indici TreeAH vengono utilizzate solo per scopi di prefiltraggio.

Per memorizzare le colonne, elencale nella clausola STORING dell'istruzione CREATE VECTOR INDEX. L'archiviazione delle colonne aumenta le dimensioni dell'indice vettoriale, quindi è meglio archiviare solo le colonne utilizzate o filtrate più di frequente.

L'esempio seguente crea un indice vettoriale con colonne archiviate, quindi esegue una query di ricerca vettoriale che seleziona solo le colonne archiviate:

-- Create a table that contains an embedding.
CREATE TABLE my_dataset.my_table(embedding ARRAY<FLOAT64>, type STRING, creation_time DATETIME, id INT64);

-- Create a query table that contains an embedding.
CREATE TABLE my_dataset.my_testdata(embedding ARRAY<FLOAT64>, test_id INT64);

-- Create a vector index with stored columns.
CREATE VECTOR INDEX my_index ON my_dataset.my_table(embedding)
STORING (type, creation_time)
OPTIONS (index_type = 'IVF');

-- Select only stored columns from a vector search to avoid an expensive join.
SELECT query, base.type, distance
FROM
  VECTOR_SEARCH(
    TABLE my_dataset.my_table,
    'embedding'
    TABLE my_dataset.my_testdata);

Limitazioni delle colonne archiviate

• Se la modalità, il tipo o lo schema di una colonna vengono modificati nella tabella di base e se si tratta di una colonna archiviata nell'indice vettoriale, potrebbe verificarsi un ritardo prima che la modifica venga applicata all'indice vettoriale. Finché gli aggiornamenti non vengono applicati all'indice, le query di ricerca vettoriale utilizzano le colonne archiviate modificate della tabella di base.
• Se selezioni una colonna di tipo STRUCT dall'output query di una query di ricerca su una tabella con un indice con colonne archiviate, l'intera query potrebbe non riuscire.

Pre-filtraggio con le partizioni

Se la tabella su cui stai creando l'indice vettoriale è partizionata, puoi scegliere di partizionare anche l'indice vettoriale. Il partizionamento dell'indice vettoriale offre i seguenti vantaggi:

• La potatura delle partizioni viene applicata agli indici vettoriali oltre alle partizioni della tabella. La riduzione delle partizioni si verifica quando Vector Search utilizza un filtro idoneo sul valore della colonna di partizionamento. In questo modo, BigQuery può analizzare le partizioni che corrispondono al filtro e saltare quelle rimanenti. La riduzione delle partizioni può ridurre i costi di I/O. Per ulteriori informazioni sul pruning delle partizioni, vedi Eseguire query sulle tabelle partizionate.
• È meno probabile che la ricerca vettoriale non trovi risultati se pre-filtri in base alla colonna di partizionamento.

Puoi partizionare solo gli indici vettoriali TreeAH. Non puoi creare un indice vettoriale partizionato su una colonna di embedding generata automaticamente.

Il partizionamento di un indice vettoriale è consigliato solo se utilizzi il pre-filtraggio per limitare la maggior parte delle ricerche Vector Search a poche partizioni.

Per creare un indice partizionato, utilizza la clausola PARTITION BY dell'istruzione CREATE VECTOR INDEX. La clausola PARTITION BY specificata nell'istruzione CREATE VECTOR INDEX deve essere la stessa della clausola PARTITION BY specificata nell'istruzione CREATE TABLE della tabella su cui stai creando l'indice vettoriale, come mostrato nell'esempio seguente:

-- Create a date-partitioned table.
CREATE TABLE my_dataset.my_table(
  embeddings ARRAY,
  id INT64,
  date DATE,
)
PARTITION BY date;

-- Create a partitioned vector index on the table.
CREATE VECTOR INDEX my_index ON my_dataset.my_table(embeddings)
PARTITION BY date
OPTIONS(index_type='TREE_AH', distance_type='COSINE');

Se la tabella utilizza il partizionamento delle colonne per intervallo di numeri interi o unità di tempo, la colonna di partizionamento viene archiviata nell'indice vettoriale, il che aumenta il costo di archiviazione. Se una colonna della tabella viene utilizzata sia nella clausola STORING che nella clausola PARTITION BY dell'istruzione CREATE VECTOR INDEX, la colonna viene archiviata una sola volta.

Per utilizzare la partizione dell'indice vettoriale, filtra in base alla colonna di partizionamento nella sottoquery della tabella di base della chiamata VECTOR_SEARCH o AI.SEARCH. Nell'esempio seguente, la tabella samples.items è partizionata in base alla colonna produced_date, quindi la sottoquery della tabella di base nell'istruzione VECTOR_SEARCH filtra in base alla colonna produced_date:

SELECT query.id, base.id, distance
FROM VECTOR_SEARCH(
  (SELECT * FROM my_dataset.my_table WHERE produced_date = '2025-01-01'),
  'embedding',
  TABLE samples.test,
  distance_type => 'COSINE',
  top_k => 10
);

Esempi

Crea un indice vettoriale partizionato in una tabella partizionata in base alla data e all'ora:

-- Create a datetime-partitioned table.
CREATE TABLE my_dataset.my_table(
  id INT64,
  produced_date DATETIME,
  embeddings ARRAY
)
PARTITION BY produced_date;

-- Create a partitioned vector index on the table.
CREATE VECTOR INDEX index0 ON my_dataset.my_table(embeddings)
PARTITION BY produced_date
OPTIONS(index_type='TREE_AH', distance_type='COSINE');

Crea un indice vettoriale partizionato su una tabella partizionata per timestamp:

-- Create a timestamp-partitioned table.
CREATE TABLE my_dataset.my_table(
  id INT64,
  produced_time TIMESTAMP,
  embeddings ARRAY
)
PARTITION BY TIMESTAMP_TRUNC(produced_time, HOUR);

-- Create a partitioned vector index on the table.
CREATE VECTOR INDEX index0 ON my_dataset.my_table(embeddings)
PARTITION BY TIMESTAMP_TRUNC(produced_time, HOUR)
OPTIONS(index_type='TREE_AH', distance_type='COSINE');

Crea un indice vettoriale partizionato su una tabella partizionata per intervalli di numeri interi:

-- Create an integer range-partitioned table.
CREATE TABLE my_dataset.my_table(
  id INT64,
  embeddings ARRAY
)
PARTITION BY RANGE_BUCKET(id, GENERATE_ARRAY(-100, 100, 20));

-- Create a partitioned vector index on the table.
CREATE VECTOR INDEX index0 ON my_dataset.my_table(embeddings)
PARTITION BY RANGE_BUCKET(id, GENERATE_ARRAY(-100, 100, 20))
OPTIONS(index_type='TREE_AH', distance_type='COSINE');

Crea un indice vettoriale partizionato in una tabella partizionata per data di importazione:

-- Create an ingestion time-partitioned table.
CREATE TABLE my_dataset.my_table(
  id INT64,
  embeddings ARRAY
)
PARTITION BY TIMESTAMP_TRUNC(_PARTITIONTIME, DAY);

-- Create a partitioned vector index on the table.
CREATE VECTOR INDEX index0 ON my_dataset.my_table(embeddings)
PARTITION BY TIMESTAMP_TRUNC(_PARTITIONTIME, DAY)
OPTIONS(index_type='TREE_AH', distance_type='COSINE');

Limitazioni del pre-filtraggio

• Non puoi utilizzare viste logiche nel pre-filtro.
• Se il pre-filtraggio contiene una subquery, potrebbe interferire con l'utilizzo dell'indice.
• La riduzione dei dati di pre-filtraggio è ottimizzata solo quando si applica un filtro alle colonne partizionate o alle colonne archiviate, non alle colonne raggruppate.

Avviso: il filtro sulle colonne in cluster che non sono anche colonne archiviate nell'indice vettoriale nella sottoquery di pre-filtraggio non elimina i blocchi in cluster e comporta una scansione completa della tabella.

Informazioni su quando vengono indicizzati i dati

Gli indici vettoriali sono completamente gestiti da BigQuery e vengono aggiornati automaticamente quando la tabella indicizzata cambia.

L'indicizzazione è asincrona. Si verifica un ritardo tra l'aggiunta di nuove righe alla tabella di base e la loro visualizzazione nell'indice. Tuttavia, le funzioni VECTOR_SEARCH e AI.SEARCH tengono comunque conto di tutte le righe e non tralasciano le righe non indicizzate. La ricerca delle funzioni utilizza l'indice per i record indicizzati e la ricerca esaustiva per i record non ancora indicizzati.

Se crei un indice vettoriale su una colonna di embedding generata automaticamente, l'addestramento dell'indice inizia non appena almeno l'80% delle righe ha generato embedding.

Se crei un indice vettoriale su una tabella di dimensioni inferiori a 10 MB, l'indice vettoriale non viene compilato. Analogamente, se elimini i dati da una tabella indicizzata e le dimensioni della tabella scendono al di sotto di 10 MB, l'indice vettoriale viene temporaneamente disattivato. In questo caso, le query di ricerca vettoriale non utilizzano l'indice e il codice indexUnusedReasons nella sezione vectorSearchStatistics della risorsa Job è BASE_TABLE_TOO_SMALL. Senza l'indice, la funzione di ricerca utilizza automaticamente la forza bruta per trovare i vicini più prossimi degli embedding.

Se elimini la colonna indicizzata in una tabella o rinomini la tabella stessa, l'indice vettoriale viene eliminato automaticamente.

Monitoraggio dello stato degli indici vettoriali

Puoi monitorare l'integrità degli indici vettoriali eseguendo query sulle visualizzazioni INFORMATION_SCHEMA. Le seguenti visualizzazioni contengono metadati sugli indici vettoriali:

• La vista INFORMATION_SCHEMA.VECTOR_INDEXES contiene informazioni sugli indici vettoriali in un set di dati.

  Al termine dell'istruzione CREATE VECTOR INDEX, l'indice deve essere ancora compilato prima di poterlo utilizzare. Puoi utilizzare le colonne last_refresh_time e coverage_percentage per verificare l'idoneità di un indice vettoriale. Se l'indice vettoriale non è pronto, puoi comunque utilizzare le funzioni VECTOR_SEARCH e AI.SEARCH su una tabella, ma potrebbero essere eseguite più lentamente senza l'indice.

• La vista INFORMATION_SCHEMA.VECTOR_INDEX_COLUMNS contiene informazioni sulle colonne indicizzate in base ai vettori per tutte le tabelle di un set di dati.

• La vista INFORMATION_SCHEMA.VECTOR_INDEX_OPTIONS contiene informazioni sulle opzioni utilizzate dagli indici vettoriali in un set di dati.

Esempi di indice vettoriale

L'esempio seguente mostra tutti gli indici vettoriali attivi sulle tabelle nel set di dati my_dataset, che si trova nel progetto my_project. Include i nomi, le istruzioni DDL utilizzate per crearli e la percentuale di copertura. Se una tabella di base indicizzata è inferiore a 10 MB, l'indice non viene compilato e in questo caso il valore coverage_percentage è 0.

SELECT table_name, index_name, ddl, coverage_percentage
FROM my_project.my_dataset.INFORMATION_SCHEMA.VECTOR_INDEXES
WHERE index_status = 'ACTIVE';

Il risultato è simile al seguente:

+------------+------------+-------------------------------------------------------------------------------------------------+---------------------+
| table_name | index_name | ddl                                                                                             | coverage_percentage |
+------------+------------+-------------------------------------------------------------------------------------------------+---------------------+
| table1     | indexa     | CREATE VECTOR INDEX `indexa` ON `my_project.my_dataset.table1`(embeddings)                      | 100                 |
|            |            | OPTIONS (distance_type = 'EUCLIDEAN', index_type = 'IVF', ivf_options = '{"num_lists": 100}')   |                     |
+------------+------------+-------------------------------------------------------------------------------------------------+---------------------+
| table2     | indexb     | CREATE VECTOR INDEX `indexb` ON `my_project.my_dataset.table2`(vectors)                         | 42                  |
|            |            | OPTIONS (distance_type = 'COSINE', index_type = 'IVF', ivf_options = '{"num_lists": 500}')      |                     |
+------------+------------+-------------------------------------------------------------------------------------------------+---------------------+
| table3     | indexc     | CREATE VECTOR INDEX `indexc` ON `my_project.my_dataset.table3`(vectors)                         | 98                  |
|            |            | OPTIONS (distance_type = 'DOT_PRODUCT', index_type = 'TREE_AH',                                 |                     |
|            |            |          tree_ah_options = '{"leaf_node_embedding_count": 1000, "normalization_type": "NONE"}') |                     |
+------------+------------+-------------------------------------------------------------------------------------------------+---------------------+

Esempi di colonne di indice vettoriale

La seguente query estrae informazioni sulle colonne con indici vettoriali:

SELECT table_name, index_name, index_column_name, index_field_path
FROM my_project.dataset.INFORMATION_SCHEMA.VECTOR_INDEX_COLUMNS;

Il risultato è simile al seguente:

+------------+------------+-------------------+------------------+
| table_name | index_name | index_column_name | index_field_path |
+------------+------------+-------------------+------------------+
| table1     | indexa     | embeddings        | embeddings       |
| table2     | indexb     | vectors           | vectors          |
| table3     | indexc     | vectors           | vectors          |
+------------+------------+-------------------+------------------+

Esempi di opzioni per gli indici vettoriali

La seguente query estrae informazioni sulle opzioni dell'indice vettoriale:

SELECT table_name, index_name, option_name, option_type, option_value
FROM my_project.dataset.INFORMATION_SCHEMA.VECTOR_INDEX_OPTIONS;

Il risultato è simile al seguente:

+------------+------------+------------------+------------------+-------------------------------------------------------------------+
| table_name | index_name | option_name      | option_type      | option_value                                                      |
+------------+------------+------------------+------------------+-------------------------------------------------------------------+
| table1     | indexa     | index_type       | STRING           | IVF                                                               |
| table1     | indexa     | distance_type    | STRING           | EUCLIDEAN                                                         |
| table1     | indexa     | ivf_options      | STRING           | {"num_lists": 100}                                                |
| table2     | indexb     | index_type       | STRING           | IVF                                                               |
| table2     | indexb     | distance_type    | STRING           | COSINE                                                            |
| table2     | indexb     | ivf_options      | STRING           | {"num_lists": 500}                                                |
| table3     | indexc     | index_type       | STRING           | TREE_AH                                                           |
| table3     | indexc     | distance_type    | STRING           | DOT_PRODUCT                                                       |
| table3     | indexc     | tree_ah_options  | STRING           | {"leaf_node_embedding_count": 1000, "normalization_type": "NONE"} |
+------------+------------+------------------+------------------+-------------------------------------------------------------------+

Verifica dell'utilizzo dell'indice vettoriale

Le informazioni sull'utilizzo dell'indice vettoriale sono disponibili nei metadati del job che ha eseguito la query di ricerca vettoriale. Puoi visualizzare i metadati del job utilizzando la console Google Cloud , lo strumento a riga di comando bq, l'API BigQuery o le librerie client.

Quando utilizzi la console Google Cloud , puoi trovare le informazioni sull'utilizzo dell'indice vettoriale nei campi Modalità di utilizzo dell'indice vettoriale e Motivi del mancato utilizzo dell'indice vettoriale.

Quando utilizzi lo strumento bq o l'API BigQuery, puoi trovare le informazioni sull'utilizzo dell'indice vettoriale nella sezione VectorSearchStatistics della risorsa Job.

La modalità di utilizzo dell'indice indica se è stato utilizzato un indice vettoriale fornendo uno dei seguenti valori:

• UNUSED: non è stato utilizzato alcun indice vettoriale.
• PARTIALLY_USED: alcune funzioni di ricerca nella query hanno utilizzato indici vettoriali e altre no.
• FULLY_USED: ogni funzione di ricerca nella query ha utilizzato un indice vettoriale.

Quando il valore della modalità di utilizzo dell'indice è UNUSED o PARTIALLY_USED, i motivi del mancato utilizzo dell'indice indicano perché gli indici vettoriali non sono stati utilizzati nella query.

Ad esempio, i seguenti risultati restituiti da bq show --format=prettyjson -j my_job_id mostrano che l'indice non è stato utilizzato perché l'opzione use_brute_force è stata specificata nella funzione VECTOR_SEARCH:

"vectorSearchStatistics": {
  "indexUnusedReasons": [
    {
      "baseTable": {
        "datasetId": "my_dataset",
        "projectId": "my_project",
        "tableId": "my_table"
      },
      "code": "INDEX_SUPPRESSED_BY_FUNCTION_OPTION",
      "message": "No vector index was used for the base table `my_project:my_dataset.my_table` because use_brute_force option has been specified."
    }
  ],
  "indexUsageMode": "UNUSED"
}

Problema noto: l'utilizzo dell'indice vettoriale potrebbe essere impreciso quando la query è in esecuzione, viene annullata o non è riuscita.

Opzioni di gestione degli indici

Per creare indici e fare in modo che BigQuery li gestisca, hai due opzioni:

• Utilizza il pool di slot condiviso predefinito: se i dati che prevedi di indicizzare sono inferiori al limite per organizzazione, puoi utilizzare il pool di slot condiviso senza costi per la gestione dell'indice.
• Utilizza la tua prenotazione: Per ottenere un avanzamento dell'indicizzazione più prevedibile e coerente nei carichi di lavoro di produzione più grandi, puoi utilizzare le tue prenotazioni per la gestione dell'indice.

Utilizza gli slot condivisi

Se non hai configurato il tuo progetto per utilizzare una prenotazione dedicata per l'indicizzazione, la gestione dell'indice viene gestita nel pool di slot condivisi senza costi, soggetto ai seguenti vincoli.

Se aggiungi dati a una tabella che fa sì che le dimensioni totali delle tabelle indicizzate superino il limite della tua organizzazione, BigQuery mette in pausa la gestione degli indici per quella tabella. In questo caso, il campo index_status nella visualizzazione INFORMATION_SCHEMA.VECTOR_INDEXES mostra PENDING DISABLEMENT e l'indice viene messo in coda per l'eliminazione. Mentre l'indice è in attesa di essere disabilitato, viene ancora utilizzato nelle query e ti viene addebitato il costo di archiviazione dell'indice. Dopo l'eliminazione dell'indice, il campo index_status mostra l'indice come TEMPORARILY DISABLED. In questo stato, le query non utilizzano l'indice e non ti viene addebitato alcun costo per l'archiviazione dell'indice. In questo caso, il codice IndexUnusedReason è BASE_TABLE_TOO_LARGE.

Se elimini i dati dalla tabella e la dimensione totale delle tabelle indicizzate scende al di sotto del limite per organizzazione, la gestione degli indici viene ripresa. Il campo index_status nella vista INFORMATION_SCHEMA.VECTOR_INDEXES è ACTIVE, le query possono utilizzare l'indice e ti viene addebitato il costo dello spazio di archiviazione dell'indice.

Puoi utilizzare la visualizzazione INFORMATION_SCHEMA.SEARCH_INDEXES_BY_ORGANIZATION per comprendere il tuo consumo attuale rispetto al limite per organizzazione in una determinata regione, suddiviso per progetti e tabelle.

BigQuery non fornisce garanzie sulla capacità disponibile del pool condiviso o sul throughput di indicizzazione visualizzato. Per le applicazioni di produzione, potresti voler utilizzare slot dedicati per l'elaborazione degli indici.

Utilizza la tua prenotazione

Anziché utilizzare il pool di slot condivisi predefinito, puoi facoltativamente designare la tua prenotazione per indicizzare le tabelle. L'utilizzo della tua prenotazione garantisce prestazioni prevedibili e coerenti dei job di gestione degli indici, come la creazione, l'aggiornamento e le ottimizzazioni in background.

• Non esistono limiti di dimensioni delle tabelle quando un job di indicizzazione viene eseguito nella tua prenotazione.
• L'utilizzo della tua prenotazione ti offre flessibilità nella gestione degli indici. Se devi creare un indice molto grande o apportare un aggiornamento principale a una tabella indicizzata, puoi aggiungere temporaneamente altri slot all'assegnazione.

Per indicizzare le tabelle in un progetto con una prenotazione designata, crea una prenotazione nella regione in cui si trovano le tabelle. Poi, assegna il progetto alla prenotazione con job_type impostato su BACKGROUND, che condivide le risorse tra i job di ottimizzazione in background:

SQL

Utilizza l'istruzione DDL CREATE ASSIGNMENT.

1. Nella console Google Cloud , vai alla pagina BigQuery.

   Vai a BigQuery

2. Nell'editor di query, inserisci la seguente istruzione:

   CREATE ASSIGNMENT
     `ADMIN_PROJECT_ID.region-LOCATION.RESERVATION_NAME.ASSIGNMENT_ID`
   OPTIONS (
     assignee = 'projects/PROJECT_ID',
     job_type = 'BACKGROUND');

   Sostituisci quanto segue:

   • ADMIN_PROJECT_ID: l'ID progetto del progetto di amministrazione proprietario della risorsa di prenotazione
   • LOCATION: la posizione della prenotazione
   • RESERVATION_NAME: il nome della prenotazione

   • ASSIGNMENT_ID: l'ID dell'assegnazione

     L'ID deve essere univoco per il progetto e la località, iniziare e terminare con una lettera minuscola o un numero e contenere solo lettere minuscole, numeri e trattini.

   • PROJECT_ID: l'ID del progetto contenente le tabelle da indicizzare. Questo progetto è assegnato alla prenotazione.

3. Fai clic su Esegui.

Per saperne di più su come eseguire le query, consulta Eseguire una query interattiva.

bq

Utilizza il comando bq mk:

bq mk \
    --project_id=ADMIN_PROJECT_ID \
    --location=LOCATION \
    --reservation_assignment \
    --reservation_id=RESERVATION_NAME \
    --assignee_id=PROJECT_ID \
    --job_type=BACKGROUND \
    --assignee_type=PROJECT

Sostituisci quanto segue:

• ADMIN_PROJECT_ID: l'ID progetto del progetto di amministrazione proprietario della risorsa di prenotazione
• LOCATION: la posizione della prenotazione
• RESERVATION_NAME: il nome della prenotazione
• PROJECT_ID: l'ID del progetto da assegnare a questa prenotazione

Visualizza i job di indicizzazione

Ogni volta che viene creato o aggiornato un indice su una singola tabella, viene creato un nuovo job di indicizzazione. Per visualizzare le informazioni sul job, esegui una query sulle viste INFORMATION_SCHEMA.JOBS*. Puoi filtrare i job di indicizzazione impostando job_type IS NULL AND SEARCH(job_id, '`search_index`') nella clausola WHERE della query. L'esempio seguente elenca i cinque job di indicizzazione più recenti nel progetto my_project:

SELECT *
FROM
 region-us.INFORMATION_SCHEMA.JOBS
WHERE
  project_id  = 'my_project'
  AND job_type IS NULL
  AND SEARCH(job_id, '`search_index`')
ORDER BY
 creation_time DESC
LIMIT 5;

Nota: non puoi visualizzare informazioni sui job di indicizzazione eseguiti nel pool di slot condivisi predefinito.

Scegli le dimensioni della prenotazione

Per scegliere il numero corretto di slot per la prenotazione, devi considerare quando vengono eseguiti i job di gestione degli indici, quanti slot utilizzano e l'utilizzo nel tempo. BigQuery attiva un job di gestione degli indici nelle seguenti situazioni:

• Crei un indice su una tabella.
• I dati vengono modificati in una tabella indicizzata.
• Lo schema di una tabella cambia e questo influisce sulle colonne indicizzate.
• I dati e i metadati dell'indice vengono periodicamente ottimizzati o aggiornati.

Il numero di slot necessari per un job di gestione degli indici su una tabella dipende dai seguenti fattori:

• Le dimensioni della tabella
• La frequenza di importazione dati nella tabella
• La frequenza delle istruzioni DML applicate alla tabella
• Il ritardo accettabile per la creazione e la manutenzione dell'indice
• La complessità dell'indice, in genere determinata dagli attributi dei dati, come il numero di termini duplicati.

Monitorare l'utilizzo e l'avanzamento

Il modo migliore per valutare il numero di slot necessari per eseguire in modo efficiente i job di gestione degli indici è monitorare l'utilizzo degli slot e regolare di conseguenza le dimensioni della prenotazione. La seguente query produce l'utilizzo giornaliero degli slot per i job di gestione degli indici. Solo gli ultimi 30 giorni sono inclusi nella regione us-west1:

SELECT
  TIMESTAMP_TRUNC(job.creation_time, DAY) AS usage_date,
  -- Aggregate total_slots_ms used for index-management jobs in a day and divide
  -- by the number of milliseconds in a day. This value is most accurate for
  -- days with consistent slot usage.
  SAFE_DIVIDE(SUM(job.total_slot_ms), (1000 * 60 * 60 * 24)) AS average_daily_slot_usage
FROM
  `region-us-west1`.INFORMATION_SCHEMA.JOBS job
WHERE
  project_id = 'my_project'
  AND job_type IS NULL
  AND SEARCH(job_id, '`search_index`')
GROUP BY
  usage_date
ORDER BY
  usage_date DESC
limit 30;

Se non sono disponibili slot sufficienti per eseguire i job di gestione degli indici, un indice può non essere sincronizzato con la tabella e i job di indicizzazione potrebbero non riuscire. In questo caso, BigQuery ricrea l'indice da zero. Per evitare di avere un indice non sincronizzato, assicurati di avere slot sufficienti per supportare gli aggiornamenti dell'indice dall'importazione dati e dall'ottimizzazione. Per saperne di più sul monitoraggio dell'utilizzo degli slot, consulta Grafici delle risorse di amministrazione.

Ricostruisci un indice vettoriale

Quando i dati della tabella cambiano in modo significativo dopo la creazione di un indice vettoriale, quest'ultimo può diventare meno efficiente. Quando un indice vettoriale è meno efficiente, una query di ricerca vettoriale che inizialmente aveva un recupero elevato quando utilizza l'indice avrà un recupero inferiore, perché lo spostamento della distribuzione dei dati nella tabella di base non è rappresentato nell'indice vettoriale.

Se vuoi migliorare il richiamo senza aumentare la latenza delle query di ricerca, ricrea l'indice vettoriale. In alternativa, puoi aumentare il valore dell'opzione fraction_lists_to_search della ricerca vettoriale per migliorare il richiamo, ma in genere la query di ricerca diventa più lenta. Per scoprire quando è stato creato l'ultimo indice, esegui questa query:

SELECT last_model_build_time
FROM DATASET_NAME.INFORMATION_SCHEMA.VECTOR_INDEXES
WHERE table_name = TABLE_NAME;

Puoi utilizzare la funzione VECTOR_INDEX.STATISTICS per calcolare la variazione dei dati di una tabella indicizzata tra il momento in cui è stato creato un indice vettoriale e il momento attuale.

Se i dati della tabella sono cambiati a tal punto da richiedere la ricompilazione di un indice vettoriale, puoi utilizzare l'istruzione ALTER VECTOR INDEX REBUILD per ricompilare l'indice vettoriale senza doverlo eliminare e senza tempi di inattività dell'indice. Quando esegui l'istruzione, BigQuery crea un indice shadow, un indice solo in background che eredita la configurazione dell'indice corrente, sulla tabella e lo addestra in background. BigQuery promuove l'indice shadow a indice attivo quando l'indice shadow ha una copertura sufficiente.

Per ricreare un indice vettoriale:

1. Vai alla pagina BigQuery.

   Vai a BigQuery

2. Nell'editor di query, esegui la seguente istruzione SQL per controllare la deviazione dei dati della tabella indicizzata:

   SELECT * FROM VECTOR_INDEX.STATISTICS(TABLE DATASET_NAME.TABLE_NAME);

   Sostituisci quanto segue:

   • DATASET_NAME: il nome del set di dati che contiene la tabella indicizzata.
   • TABLE_NAME: il nome della tabella che contiene l'indice vettoriale.

   La funzione restituisce un valore FLOAT64 nell'intervallo [0,1). Un valore inferiore indica una deviazione minore. In genere, un valore pari o superiore a 0.3 è considerato una modifica sufficientemente significativa da indicare che la ricostruzione di un indice vettoriale potrebbe essere vantaggiosa.

3. Se la funzione VECTOR_INDEX.STATISTICS indica che la deviazione dei dati della tabella è significativa, esegui la seguente istruzione SQL per ricostruire l'indice vettoriale:

   ALTER VECTOR INDEX IF EXISTS INDEX_NAME
   ON DATASET_NAME.TABLE_NAME
   REBUILD;

   Sostituisci quanto segue:

   • INDEX_NAME: il nome dell'indice vettoriale che stai ricreando.
   • DATASET_NAME: il nome del set di dati che contiene la tabella indicizzata.
   • TABLE_NAME: il nome della tabella che contiene l'indice vettoriale.

Monitora una ricostruzione

Per monitorare la ricostruzione dell'indice, esegui una query sulla vista INFORMATION_SCHEMA.VECTOR_INDEXES. Ad esempio, la query seguente mostra lo stato di ricompilazione di tutti gli indici nelle tabelle del set di dati my_dataset nel progetto my_project. Se un indice non è in fase di ricostruzione, il valore di last_index_alteration_info è NULL.

SELECT
  table_name,
  index_name,
  last_index_alteration_info.status AS status,
  last_index_alteration_info.new_coverage_percentage AS coverage
FROM my_project.my_dataset.INFORMATION_SCHEMA.VECTOR_INDEXES

Il risultato è simile al seguente:

+------------+------------+-------------+----------+
| table_name | index_name | status      | coverage |
+------------+------------+-------------+----------+
| table1     | index_a    | IN_PROGRESS | 50       |
| table2     | index_b    | null        | null     |
+------------+------------+-------------+----------+

Annulla una ricostruzione

Per annullare la ricostruzione di un indice vettoriale, utilizza la procedura di sistema BQ.CANCEL_INDEX_ALTERATION. Un'operazione di modifica dell'indice potrebbe essere completata prima che la richiesta di annullamento venga elaborata. Per verificare se l'operazione è stata annullata correttamente, esegui una query sulla vista INFORMATION_SCHEMA.VECTOR_INDEXES. Se l'annullamento è andato a buon fine, il campo last_model_build_time non viene aggiornato e il campo last_index_alteration_info non è presente per l'indice.

Elimina un indice vettoriale

Quando non hai più bisogno di un indice vettoriale o vuoi modificare la colonna indicizzata in una tabella, puoi eliminare l'indice della tabella utilizzando l'istruzione DDL DROP VECTOR INDEX:

1. Vai alla pagina BigQuery.

   Vai a BigQuery

2. Nell'editor di query, esegui la seguente istruzione SQL:

   DROP VECTOR INDEX INDEX_NAME ON DATASET_NAME.TABLE_NAME;

   Sostituisci quanto segue:

   • INDEX_NAME: il nome dell'indice vettoriale che stai eliminando.
   • DATASET_NAME: il nome del set di dati che contiene la tabella indicizzata.
   • TABLE_NAME: il nome della tabella che contiene l'indice vettoriale.

Se una tabella indicizzata viene eliminata, il relativo indice viene eliminato automaticamente.

Esporta gli embedding in Vector Search

Per abilitare applicazioni online con latenza ultra bassa, utilizza l'integrazione di BigQuery con Vector Search di Gemini Enterprise Agent Platform per importare gli embedding di BigQuery in Vector Search ed eseguire il deployment di endpoint a bassa latenza. Per saperne di più, consulta Importa i dati dell'indice da BigQuery.

Passaggi successivi

• Per una panoramica dei casi d'uso, dei prezzi e delle limitazioni dell'indice vettoriale, consulta la Introduzione a Vector Search.
• Scopri come eseguire una Vector Search utilizzando la funzione VECTOR_SEARCH.
• Scopri come eseguire la ricerca semantica utilizzando la funzione AI.SEARCH.
• Scopri di più sull'istruzione CREATE VECTOR INDEX.
• Prova il tutorial Cerca embedding con Vector Search.