Accelera le query utilizzando funzioni AI ottimizzate

Puoi ridurre i costi operativi e migliorare la reattività delle query utilizzando funzioni AI ottimizzate in AlloyDB per PostgreSQL. Le funzioni AI ottimizzate riducono al minimo l'utilizzo di modelli linguistici di grandi dimensioni (LLM) per le attività di classificazione o filtro riga per riga elaborando la maggior parte delle query con un modello proxy più piccolo e veloce e ricorrendo a un LLM più grande solo quando necessario.

Le funzioni AI di AlloyDB come ai.if() possono avere una latenza elevata a causa delle chiamate remote agli LLM. Le funzioni ottimizzate risolvono questo problema di latenza utilizzando modelli proxy più piccoli, addestrati localmente (come i modelli di regressione logistica) per elaborare le query. Questi modelli vengono addestrati su un campione dei tuoi dati, utilizzando l'output dell'LLM come fonte attendibile.

Puoi configurare i controlli di accuratezza da eseguire in fase di runtime utilizzando il flag google_ml_integration.proxy_models_enable_accuracy_check, impostato su off per impostazione predefinita. I controlli di accuratezza valutano un campione di righe della query utilizzando l'LLM di base per garantire che l'accuratezza soddisfi la soglia definita dal flag google_ml_integration.proxy_models_f1_score_threshold. Se il controllo di accuratezza non va a buon fine, la query torna a utilizzare l'LLM (o genera un errore se il fallback è disattivato).

Workflow delle funzioni AI ottimizzato

Quando utilizzi una funzione AI ottimizzata e imposti il flag google_ml_integration.proxy_models_enable_accuracy_check su true, AlloyDB esegue le seguenti operazioni.

  1. Pianifica l'addestramento: quando esegui una query contenente la funzione ai.if() su una tabella, AlloyDB pianifica automaticamente l'addestramento di un modello proxy leggero in background.

  2. Utilizza l'LLM come riserva: mentre il modello proxy è in fase di addestramento o se non è disponibile un modello proxy, AlloyDB utilizza l'LLM remoto come riserva per valutare la query (a meno che il fallback non sia disattivato).

  3. Esegue query ottimizzate: dopo l'addestramento del modello, AlloyDB utilizza il modello proxy addestrato per elaborare le query successive localmente, accelerando le prestazioni.

Il seguente diagramma mostra il flusso logico per l'elaborazione delle query con funzioni AI ottimizzate:

Diagramma di flusso delle funzioni AI ottimizzate

Prima di iniziare

Prima di utilizzare le funzioni AI ottimizzate, segui questi passaggi:

Esegui una query ottimizzata

Segui questo esempio per eseguire un'istruzione SELECT standard con la funzione ai.if():

  1. Crea una tabella restaurant_reviews. La colonna review che contiene i dati di origine è di tipo TEXT, mentre la colonna review_embedding utilizzata per le query è di tipo VECTOR(768).

    CREATE TABLE restaurant_reviews (
    id SERIAL,
    name VARCHAR(64),
    city VARCHAR(64),
    review TEXT,
    review_embedding VECTOR(768)
);

  2. Genera vector embedding per i dati di origine utilizzando la procedura ai.initialize_embeddings():

    CALL ai.initialize_embeddings(
    model_id => 'text-embedding-005',
    table_name => 'restaurant_reviews',
    content_column => 'review',
    embedding_column => 'review_embedding'
);

    La generazione di embedding è necessaria perché le funzioni AI ottimizzate si basano su vector embedding come input delle caratteristiche per addestrare e valutare il modello proxy leggero. Anziché inviare testo non elaborato a un LLM remoto per ogni riga, il modello proxy esegue un'inferenza locale rapida direttamente sulle rappresentazioni vettoriali. Se gli embedding non vengono generati, AlloyDB non può addestrare il modello proxy e torna alla valutazione di tutte le righe con l'LLM remoto.

    Tieni presente i seguenti requisiti di incorporamento:

    • L'output ai.if() restituisce NULL se la colonna di embedding contiene valori NULL. Sia l'addestramento che l'inferenza del modello richiedono embedding validi.
    • La funzione ai.if() genera un errore se le dimensioni di embedding della query non corrispondono a quelle memorizzate nel modello proxy addestrato.

    Per saperne di più sulle opzioni di embedding e sugli aggiornamenti incrementali, consulta Genera e gestisci vector embedding automatici per tabelle di grandi dimensioni.

  3. Esegui un'istruzione SELECT con la funzione ai.if(). Questa query pianifica automaticamente l'addestramento di un modello proxy per le funzioni AI ottimizzate in background:

    SELECT r.name, r.city
FROM restaurant_reviews r
WHERE ai.if('Is the following a positive review? Review: ' || r.review, r.review_embedding, 'gemini-3.5-flash-lite')
GROUP BY r.name, r.city
HAVING COUNT(*) > 500;

    La prima esecuzione della query attiva l'addestramento in modo asincrono. Durante l'addestramento del modello proxy, se il flag google_ml_integration.proxy_models_enable_llm_fallback è impostato su on (valore predefinito), AlloyDB esegue il fallback alla valutazione della query con l'LLM remoto e restituisce un avviso che indica che la funzione AI ottimizzata non è ancora disponibile. Se google_ml_integration.proxy_models_enable_llm_fallback è impostato su off, la query restituisce un errore anziché eseguire il fallback.

    Le query successive che corrispondono alla stessa espressione di contenuto (content_expr), alla colonna di embedding e alla tabella utilizzano il modello proxy addestrato per l'accelerazione. L'aggiornamento dei valori delle righe, l'eliminazione delle righe o l'aggiunta di dati alla tabella non comportano il ritorno di AlloyDB all'LLM. Il modello proxy continua a elaborare i dati localmente e la deviazione dei dati viene gestita tramite un riaddestramento periodico in background.

    I modelli proxy sono identificati in modo univoco dal tipo di funzione, dall'OID della tabella, dall'espressione dei contenuti e dalla colonna di embedding (func_type, table_oid, content_expr, embedding_column). Con questa architettura, puoi condividere i modelli tra diverse query SQL, a condizione che gli input di ai.if() rimangano invariati.

    AlloyDB non utilizza il modello proxy esistente, ma avvia l'addestramento in background per un nuovo modello proxy e utilizza l'LLM remoto (soggetto al flag google_ml_integration.proxy_models_enable_llm_fallback) nei seguenti scenari:

    • L'espressione CONTENT all'interno di ai.if() cambia (ad esempio, la stringa del prompt o l'espressione della colonna concatenata viene modificata).
    • Il nome EMBEDDING_COLUMN all'interno di ai.if() cambia.
    • Il parametro llm_model_id cambia.
    • Se i controlli di accuratezza in fase di runtime sono abilitati e il modello proxy non supera il controllo di accuratezza all'inizio della query.

Addestramento online e blocco dell'esecuzione

AlloyDB supporta un flusso di lavoro di addestramento online per le funzioni ottimizzate, controllato dal flag di database google_ml_integration.proxy_models_enable_online_training. Per impostazione predefinita, questo flag è impostato su off.

Quando questo flag è abilitato e viene eseguita una funzione ai.if() non addestrata, la query attiva il processo di addestramento e utilizza l'esecuzione di blocco. La query iniziale blocca attivamente e attende il completamento dell'addestramento del modello proxy in background prima di procedere. In questo modo, la query utilizza immediatamente il modello proxy ottimizzato, evitando i costi di inferenza dell'LLM remoto durante l'esecuzione iniziale.

La durata massima del blocco della query e dell'attesa del completamento dell'addestramento online è controllata dal flag google_ml_integration.proxy_models_training_wait_timeout (in secondi, il valore predefinito è 60). Se l'addestramento non viene completato entro questo intervallo, la query scade o viene eseguito il fallback in base alle impostazioni di fallback.

Per attivare l'addestramento online:

-- Enable online training (blocking execution)
SET google_ml_integration.proxy_models_enable_online_training = on;

-- Set the maximum wait timeout in seconds (default is 60)
SET google_ml_integration.proxy_models_training_wait_timeout = 30;

Configura il fallback LLM remoto

Per impostazione predefinita, il fallback all'LLM remoto è abilitato. Se un modello proxy non è addestrato, è in fase di addestramento o non supera i controlli di accuratezza, la query esegue il fallback all'LLM remoto e comporta i costi standard dell'API Agent Platform.

Puoi configurare il comportamento di fallback utilizzando il flag di database google_ml_integration.proxy_models_enable_llm_fallback:

  • Quando il fallback è abilitato (on, impostazione predefinita): se il modello proxy non è disponibile, AlloyDB valuta la query utilizzando l'LLM remoto e restituisce un avviso:

    WARNING: Optimized AI Function is unavailable. Expect reduced performance.

  • Quando il fallback è disattivato (off): se il modello proxy non è disponibile o non supera la convalida dell'accuratezza, la query genera immediatamente un errore anziché chiamare l'LLM remoto:

    ERROR: Optimized AI Function: Optimized model fallback to LLM prevented by GUC google_ml_integration.proxy_models_enable_llm_fallback

Per disattivare il fallback LLM per la sessione corrente:

SET google_ml_integration.proxy_models_enable_llm_fallback = off;

Per disattivare il fallback LLM per l'intero database:

ALTER DATABASE DATABASE_NAME SET google_ml_integration.proxy_models_enable_llm_fallback = off;

Sostituisci DATABASE_NAME con il nome del database.

Configura i controlli di accuratezza in fase di runtime

I controlli di accuratezza in fase di runtime valutano un campione di righe della query utilizzando l'LLM remoto per garantire che il modello proxy soddisfi i requisiti di accuratezza di base prima dell'esecuzione.

I controlli di accuratezza sono controllati dal flag di database google_ml_integration.proxy_models_enable_accuracy_check (disattivato per impostazione predefinita).

Per attivare i controlli di accuratezza per la sessione corrente:

SET google_ml_integration.proxy_models_enable_accuracy_check = on;

Per disattivare i controlli di accuratezza per la sessione corrente:

SET google_ml_integration.proxy_models_enable_accuracy_check = off;

Per attivare i controlli di accuratezza per l'intero database:

ALTER DATABASE DATABASE_NAME SET google_ml_integration.proxy_models_enable_accuracy_check = on;

Visualizza i modelli di proxy esistenti

Per ispezionare i modelli proxy esistenti, controllarne lo stato di addestramento ed esaminare i metadati del modello, esegui una query sulla vista google_ml.optimized_functions_view (o sul suo alias nello schema ai, ai.optimized_functions_view):

SELECT * FROM ai.optimized_functions_view;

Per le descrizioni delle colonne in questa visualizzazione, consulta Vista ai.optimized_functions_view.

Puoi filtrare questa visualizzazione in base a table_name o status per verificare se un modello ha completato l'addestramento (READY) o per identificare i valori esatti di content_expr e embedding_column necessari per l'addestramento manuale.

Riqualifica e gestisci i modelli proxy

I modelli proxy vengono addestrati sui dati presenti nella tabella al momento dell'addestramento iniziale. Se alla tabella vengono aggiunti dati più recenti o se le righe vengono modificate o eliminate, il modello proxy potrebbe diventare obsoleto nel tempo. Per mantenere l'accuratezza man mano che i dati cambiano, i modelli proxy possono essere riaddestrati automaticamente periodicamente in background o manualmente on demand.

Addestramento periodico in background

Sulle istanze con 32 o più vCPU con impostazioni di configurazione predefinite, AlloyDB può riaddestrare periodicamente i modelli proxy in background.

L'addestramento periodico è controllato dai seguenti flag di database:

Riqualificazione manuale

Puoi riaddestrare manualmente i modelli proxy utilizzando le funzioni nello schema ai (o i loro equivalenti nello schema google_ml).

Addestra nuovamente tutti i modelli per una tabella

Per riaddestrare tutti i modelli proxy associati a una tabella specifica o per riaddestrare un sottoinsieme filtrato di modelli per una tabella, chiama ai.retrain_optimized_models():

SELECT ai.retrain_optimized_models(
  table_name => 'restaurant_reviews',
  embedding_column => 'review_embedding', -- Optional
  content_expr => '(''Is the following a positive review? Review: ''::text || review)', -- Optional
  llm_model_id => 'LLM_MODEL_ID' -- Optional
);

Per le descrizioni dei parametri, consulta la funzione ai.retrain_optimized_models().

Addestra nuovamente un modello specifico in base all'ID modello

Per riaddestrare un modello proxy specifico utilizzando il suo identificatore univoco, chiama ai.retrain_optimized_model() con il parametro model_id:

SELECT ai.retrain_optimized_model(model_id => 'MODEL_ID');

Per le descrizioni dei parametri, consulta la funzione ai.retrain_optimized_model().

Riqualifica un modello specifico in base ai parametri di addestramento del modello

Per riaddestrare un modello proxy specifico utilizzando il nome della tabella, l'espressione dei contenuti e la colonna di embedding, chiama ai.retrain_optimized_model():

SELECT ai.retrain_optimized_model(
  table_name => 'restaurant_reviews',
  embedding_column => 'review_embedding',
  content_expr => '(''Is the following a positive review? Review: ''::text || review)',
  llm_model_id => 'LLM_MODEL_ID' -- Optional
);

Per le descrizioni dei parametri, consulta la funzione ai.retrain_optimized_model().

Elimina i modelli proxy

Puoi eliminare singoli modelli proxy o tutti i modelli utilizzando le seguenti funzioni. Queste operazioni devono essere eseguite da un utente con privilegi alloydbsuperuser o con autorizzazioni concesse da un amministratore.

Per trovare l'ID model_id interno necessario per eliminare un modello di proxy specifico, esegui una query sulla tabella google_ml.proxy_models_expr_mapping:

SELECT model_id, table_oid::regclass, content_expr
FROM google_ml.proxy_models_expr_mapping;

-- Delete a specific proxy model
SELECT ai.delete_optimized_model('com_if_12345_67890');

-- Delete all proxy models and stop the background automated retraining job
CALL ai.delete_all_optimized_models();

Monitoraggio

Puoi monitorare i job di addestramento dei worker in background e controllare lo stato di attività del modello.

Controlla lo stato e la cronologia di addestramento del modello

Per verificare se l'addestramento di un modello proxy è stato completato, non è riuscito o è in fase di riaddestramento, esegui una query su ai.optimized_functions_view:

SELECT table_name, content_expr, status, last_trained_at, training_duration
FROM ai.optimized_functions_view;

La colonna status indica lo stato di attività attuale del modello e fornisce i seguenti valori:

  • READY: l'addestramento del modello proxy è stato completato correttamente ed è pronto per accelerare le query in entrata.
  • UNTRAINED: il modello è stato registrato o pianificato, ma l'addestramento in background non è ancora terminato. Se l'addestramento in background iniziale non va a buon fine, il modello rimane nello stato UNTRAINED e le query vengono eseguite sull'LLM remoto (o generano un errore se il fallback è disattivato).
  • RETRAINING_IN_PROGRESS: l'addestramento in background è in corso.
  • RETRAINING_FAILED: l'esecuzione più recente dell'addestramento in background o manuale non è riuscita. Nella maggior parte degli scenari, se esistono pesi del modello pre-riaddestramento, AlloyDB continua a utilizzare i pesi del modello esistenti per l'inferenza. Se i pesi del modello esistente non sono disponibili (o se i controlli di accuratezza in fase di runtime non vanno a buon fine), AlloyDB torna a valutare le query utilizzando l'LLM remoto (soggetto a google_ml_integration.proxy_models_enable_llm_fallback) finché il modello non viene riaddestrato correttamente.

Per saperne di più su tutte le colonne disponibili in questa visualizzazione, consulta Visualizza i modelli proxy esistenti.

Limitazioni

  • Le funzioni AI ottimizzate supportano solo la funzione ai.if().
  • L'addestramento automatico periodico in background dei modelli proxy non è supportato nelle istanze di database con meno di 32 vCPU.
  • Sicurezza a livello di riga (RLS): i modelli addestrati su tabelle che utilizzano criteri di sicurezza a livello di riga (RLS) potrebbero divulgare informazioni sulla sicurezza se l'addestramento viene eseguito con le autorizzazioni di un utente specifico che ha avviato l'operazione. L'addestramento dei modelli proxy su tabelle con policy RLS è disabilitato.
  • Modifiche all'input: se modifichi la colonna dei contenuti di origine, la colonna di embedding, la stringa del prompt o l'ID del modello LLM di base fornito a ai.if(), il modello proxy esistente viene ignorato e viene avviata una nuova richiesta di addestramento in background per quella combinazione.
  • Limitazioni SQL:
    • La query deve contenere una clausola FROM valida.
    • Tutti gli argomenti della funzione AI devono provenire dallo stesso alias della tabella.
    • Includi le colonne nell'espressione ai.if() come colonne di origine per l'embedding.
    • Non inserire la funzione ai.if() all'interno di una sottoquery o di un'espressione di tabella comune (CTE).

Passaggi successivi