Abfragen mit optimierten KI-Funktionen beschleunigen

Mit optimierten KI-Funktionen in AlloyDB for PostgreSQL können Sie die Betriebskosten senken und die Reaktionsfähigkeit von Abfragen verbessern. Optimierte KI-Funktionen minimieren die Verwendung von Large Language Models (LLMs) für zeilenweise Klassifizierungs- oder Filteraufgaben, indem die meisten Ihrer Abfragen mit einem kleineren, schnelleren Proxy-Modell verarbeitet werden. Nur bei Bedarf wird auf ein größeres LLM zurückgegriffen.

AlloyDB KI-Funktionen wie ai.if() können aufgrund von Remote-Aufrufen an LLMs eine hohe Latenz haben. Optimierte Funktionen beheben dieses Latenzproblem, indem sie kleinere, lokal trainierte Proxymodelle (z. B. logistische Regressionsmodelle) verwenden, um Ihre Abfragen zu verarbeiten. Diese Modelle werden mit einer Stichprobe Ihrer Daten trainiert, wobei die Ausgabe des LLM als „Source of Truth“ verwendet wird.

Sie können Genauigkeitsprüfungen so konfigurieren, dass sie zur Laufzeit ausgeführt werden. Verwenden Sie dazu das Flag google_ml_integration.proxy_models_enable_accuracy_check, das standardmäßig auf off festgelegt ist. Bei Genauigkeitsprüfungen wird eine Stichprobe von Zeilen aus der Abfrage mit dem Baseline-LLM ausgewertet, um sicherzustellen, dass die Genauigkeit den durch das Flag google_ml_integration.proxy_models_f1_score_threshold definierten Schwellenwert erreicht. Wenn die Genauigkeitsprüfung fehlschlägt, wird die Abfrage auf das LLM zurückgesetzt (oder es wird ein Fehler ausgegeben, wenn das Fallback deaktiviert ist).

Optimierter Workflow für KI-Funktionen

Wenn Sie eine optimierte KI-Funktion verwenden und das Flag google_ml_integration.proxy_models_enable_accuracy_check auf true setzen, führt AlloyDB die folgenden Schritte aus.

  1. Training planen: Wenn Sie eine Abfrage mit der Funktion ai.if() für eine Tabelle ausführen, plant AlloyDB automatisch das Training eines einfachen Proxymodells im Hintergrund.

  2. Fallback auf das LLM: Während das Proxymodell trainiert wird oder wenn kein Proxymodell verfügbar ist, greift AlloyDB auf das Remote-LLM zurück, um die Abfrage auszuwerten (es sei denn, der Fallback ist deaktiviert).

  3. Führt optimierte Abfragen aus: Nachdem das Modell trainiert wurde, verwendet AlloyDB das trainierte Proxy-Modell, um nachfolgende Abfragen lokal zu verarbeiten, was die Leistung beschleunigt.

Das folgende Diagramm zeigt den logischen Ablauf für die Verarbeitung von Abfragen mit optimierten KI-Funktionen:

Flussdiagramm für optimierte KI-Funktionen

Hinweis

Bevor Sie optimierte KI-Funktionen verwenden, müssen Sie Folgendes tun:

Optimierte Abfrage ausführen

Folgen Sie diesem Beispiel, um eine Standard-SELECT-Anweisung mit der Funktion ai.if() auszuführen:

  1. Erstellen Sie eine restaurant_reviews-Tabelle. Die Spalte review, die die Quelldaten enthält, hat den Typ TEXT und die Spalte review_embedding, die für Abfragen verwendet wird, hat den Typ VECTOR(768).

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

  2. Generieren Sie mit dem Verfahren ai.initialize_embeddings() Vektoreinbettungen für die Quelldaten:

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

    Das Generieren von Einbettungen ist erforderlich, da optimierte KI-Funktionen Vektoreinbettungen als Feature-Eingaben verwenden, um das einfache Proxy-Modell zu trainieren und zu bewerten. Anstatt für jede Zeile Rohtext an ein Remote-LLM zu senden, führt das Proxy-Modell eine schnelle, lokale Inferenz direkt für die Vektordarstellungen aus. Wenn keine Einbettungen generiert werden, kann AlloyDB das Proxymodell nicht trainieren und greift auf die Bewertung aller Zeilen mit dem Remote-LLM zurück.

    Beachten Sie die folgenden Einbettungsanforderungen:

    • Die Ausgabe ai.if() wird als NULL ausgewertet, wenn die Einbettungsspalte NULL-Werte enthält. Sowohl für das Modelltraining als auch für die Inferenz sind gültige Einbettungen erforderlich.
    • Die Funktion ai.if() gibt einen Fehler aus, wenn die Dimensionen der Abfrageeinbettung nicht mit den im trainierten Proxymodell gespeicherten Dimensionen übereinstimmen.

    Weitere Informationen zu Einbettungsoptionen und inkrementellen Aktualisierungen finden Sie unter Automatische Vektoreinbettungen für große Tabellen generieren und verwalten.

  3. Führen Sie eine SELECT-Anweisung mit der Funktion ai.if() aus. Mit dieser Abfrage wird das Training eines Proxymodells für optimierte KI-Funktionen im Hintergrund automatisch geplant:

    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;

    Die erste Abfrageausführung löst das Training asynchron aus. Wenn das Flag google_ml_integration.proxy_models_enable_llm_fallback während des Trainings des Proxymodells auf on (Standard) gesetzt ist, wertet AlloyDB die Abfrage mit dem Remote-LLM aus und gibt eine Warnung zurück, dass die optimierte KI-Funktion noch nicht verfügbar ist. Wenn google_ml_integration.proxy_models_enable_llm_fallback auf off gesetzt ist, gibt die Abfrage einen Fehler zurück, anstatt ein Fallback auszuführen.

    Bei nachfolgenden Abfragen, die mit demselben Inhaltsausdruck (content_expr), derselben Einbettungsspalte und derselben Tabelle übereinstimmen, wird das trainierte Proxymodell zur Beschleunigung verwendet. Wenn Sie Zeilenwerte aktualisieren, Zeilen löschen oder Daten zur Tabelle hinzufügen, greift AlloyDB nicht auf das LLM zurück. Das Proxy-Modell verarbeitet die Daten weiterhin lokal und die Datendrift wird durch regelmäßiges Hintergrund-Retraining behoben.

    Proxy-Modelle werden eindeutig durch den Funktionstyp, die Tabellen-OID, den Inhaltsausdruck und die Einbettungsspalte (func_type, table_oid, content_expr, embedding_column) identifiziert. Mit dieser Architektur können Sie Modelle über verschiedene SQL-Abfragen hinweg freigeben, solange die Eingaben für ai.if() unverändert bleiben.

    AlloyDB verwendet das vorhandene Proxymodell nicht, sondern initiiert ein Hintergrundtraining für ein neues Proxymodell und greift in den folgenden Szenarien auf das Remote-LLM zurück (vorbehaltlich des Flags google_ml_integration.proxy_models_enable_llm_fallback):

    • Der Ausdruck CONTENT in ai.if() ändert sich (z. B. wird der Prompt-String oder der verkettete Spaltenausdruck geändert).
    • Der Name EMBEDDING_COLUMN in ai.if() ändert sich.
    • Der Parameter llm_model_id ändert sich.
    • Wenn Laufzeitgenauigkeitsprüfungen aktiviert sind und das Proxymodell die Genauigkeitsprüfung zu Beginn der Abfrage nicht besteht.

Onlinetraining und Blockierung der Ausführung

AlloyDB unterstützt einen Onlinetrainings-Workflow für optimierte Funktionen, der über das Datenbank-Flag google_ml_integration.proxy_models_enable_online_training gesteuert wird. Standardmäßig ist dieses Flag auf off gesetzt.

Wenn dieses Flag aktiviert ist und eine nicht trainierte ai.if()-Funktion ausgeführt wird, löst die Abfrage den Trainingsprozess aus und verwendet die blockierende Ausführung. Die erste Abfrage wird aktiv blockiert und wartet, bis das Proxy-Modelltraining im Hintergrund abgeschlossen ist, bevor sie fortgesetzt wird. So wird sichergestellt, dass die Abfrage sofort das optimierte Proxymodell verwendet und bei der ersten Ausführung keine Kosten für die Remote-LLM-Inferenz anfallen.

Die maximale Dauer, die die Abfrage blockiert und auf den Abschluss des Onlinetrainings wartet, wird durch das Flag google_ml_integration.proxy_models_training_wait_timeout (in Sekunden, Standardwert ist 60) gesteuert. Wenn das Training nicht innerhalb dieses Intervalls abgeschlossen wird, kommt es zu einer Zeitüberschreitung der Abfrage oder es wird ein Fallback gemäß Ihren Fallback-Einstellungen durchgeführt.

So aktivieren Sie das Onlinetraining:

-- 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;

Remote-LLM-Fallback konfigurieren

Standardmäßig ist der Fallback auf das Remote-LLM aktiviert. Wenn ein Proxymodell nicht trainiert ist, gerade trainiert wird oder die Genauigkeitsprüfungen nicht besteht, wird die Abfrage an das Remote-LLM weitergeleitet und es fallen die Standardkosten für die Agent Platform API an.

Sie können das Fallback-Verhalten mit dem Datenbank-Flag google_ml_integration.proxy_models_enable_llm_fallback konfigurieren:

  • Wenn der Fallback aktiviert ist (on, Standard): Wenn das Proxymodell nicht verfügbar ist, wertet AlloyDB die Abfrage mit dem Remote-LLM aus und gibt eine Warnung zurück:

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

  • Wenn das Fallback deaktiviert ist (off): Wenn das Proxy-Modell nicht verfügbar ist oder die Genauigkeitsvalidierung fehlschlägt, löst die Abfrage sofort einen Fehler aus, anstatt das Remote-LLM aufzurufen:

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

So deaktivieren Sie den LLM-Fallback für die aktuelle Sitzung:

SET google_ml_integration.proxy_models_enable_llm_fallback = off;

So deaktivieren Sie den LLM-Fallback für die gesamte Datenbank:

ALTER DATABASE DATABASE_NAME SET google_ml_integration.proxy_models_enable_llm_fallback = off;

Ersetzen Sie DATABASE_NAME durch den Namen Ihrer Datenbank.

Laufzeitgenauigkeitsprüfungen konfigurieren

Bei Laufzeit-Accuracy-Prüfungen wird eine Stichprobe von Zeilen aus der Abfrage mithilfe des Remote-LLM ausgewertet, um sicherzustellen, dass das Proxy-Modell die grundlegenden Accuracy-Anforderungen erfüllt, bevor es ausgeführt wird.

Genauigkeitsprüfungen werden über das Datenbank-Flag google_ml_integration.proxy_models_enable_accuracy_check gesteuert (standardmäßig deaktiviert).

So aktivieren Sie Genauigkeitsprüfungen für die aktuelle Sitzung:

SET google_ml_integration.proxy_models_enable_accuracy_check = on;

So deaktivieren Sie die Genauigkeitsprüfungen für die aktuelle Sitzung:

SET google_ml_integration.proxy_models_enable_accuracy_check = off;

So aktivieren Sie Genauigkeitsprüfungen für die gesamte Datenbank:

ALTER DATABASE DATABASE_NAME SET google_ml_integration.proxy_models_enable_accuracy_check = on;

Vorhandene Proxymodelle ansehen

Wenn Sie vorhandene Proxymodelle prüfen, ihren Trainingsstatus abrufen und ihre Modellmetadaten einsehen möchten, fragen Sie die Ansicht google_ml.optimized_functions_view (oder ihren Alias im Schema ai, ai.optimized_functions_view) ab:

SELECT * FROM ai.optimized_functions_view;

Beschreibungen der Spalten in dieser Ansicht finden Sie unter Ansicht ai.optimized_functions_view.

Sie können diese Ansicht nach table_name oder status filtern, um zu prüfen, ob ein Modell das Training abgeschlossen hat (READY), oder um die genauen Werte für content_expr und embedding_column zu ermitteln, die für ein manuelles erneutes Training erforderlich sind.

Proxy-Modelle neu trainieren und verwalten

Proxy-Modelle werden mit den Daten trainiert, die zum Zeitpunkt des ersten Trainings in Ihrer Tabelle vorhanden sind. Wenn der Tabelle neuere Daten hinzugefügt oder Zeilen geändert oder gelöscht werden, kann das Proxymodell mit der Zeit veralten. Damit die Genauigkeit bei Datenänderungen erhalten bleibt, können Proxy-Modelle regelmäßig im Hintergrund oder manuell bei Bedarf neu trainiert werden.

Regelmäßiges Neutrainieren im Hintergrund

Auf Instanzen mit 32 oder mehr vCPUs mit Standardkonfigurationseinstellungen kann AlloyDB Proxy-Modelle regelmäßig im Hintergrund neu trainieren.

Das regelmäßige Neulernen wird durch die folgenden Datenbank-Flags gesteuert:

Manuelles Neutraining

Sie können Proxy-Modelle manuell mit Funktionen im Schema ai (oder den entsprechenden Funktionen im Schema google_ml) neu trainieren.

Alle Modelle für eine Tabelle neu trainieren

Wenn Sie alle Proxy-Modelle, die mit einer bestimmten Tabelle verknüpft sind, oder eine gefilterte Teilmenge von Modellen für eine Tabelle neu trainieren möchten, rufen Sie ai.retrain_optimized_models() auf:

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
);

Parameterbeschreibungen finden Sie unter ai.retrain_optimized_models()-Funktion.

Bestimmtes Modell anhand der Modell-ID neu trainieren

Wenn Sie ein bestimmtes Proxymodell anhand seiner eindeutigen Modell-ID neu trainieren möchten, rufen Sie ai.retrain_optimized_model() mit dem Parameter model_id auf:

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

Parameterbeschreibungen finden Sie unter ai.retrain_optimized_model()-Funktion.

Bestimmtes Modell anhand von Modelltrainingsparametern neu trainieren

Wenn Sie ein bestimmtes Proxymodell mit seinem Tabellennamen, Inhaltsausdruck und seiner Einbettungsspalte neu trainieren möchten, rufen Sie ai.retrain_optimized_model() auf:

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
);

Parameterbeschreibungen finden Sie unter ai.retrain_optimized_model()-Funktion.

Proxy-Modelle löschen

Mit den folgenden Funktionen können Sie einzelne Proxymodelle oder alle Modelle löschen. Diese Vorgänge müssen von einem Nutzer mit alloydbsuperuser-Berechtigungen oder mit von einem Administrator gewährten Berechtigungen ausgeführt werden.

Wenn Sie die interne model_id ermitteln möchten, die zum Löschen eines bestimmten Proxymodells erforderlich ist, fragen Sie die Tabelle google_ml.proxy_models_expr_mapping ab:

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();

Überwachen

Sie können Trainingsjobs für Hintergrund-Worker überwachen und den Betriebsstatus des Modells prüfen.

Status und Verlauf des Modelltrainings prüfen

Fragen Sie ai.optimized_functions_view ab, um zu prüfen, ob das Training eines Proxymodells abgeschlossen wurde, fehlgeschlagen ist oder gerade neu trainiert wird:

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

Die Spalte status gibt den aktuellen Betriebsstatus des Modells an und enthält die folgenden Werte:

  • READY: Das Proxy-Modell wurde erfolgreich trainiert und ist bereit, eingehende Abfragen zu beschleunigen.
  • UNTRAINED: Das Modell wurde registriert oder geplant, aber das Hintergrundtraining ist noch nicht abgeschlossen. Wenn das anfängliche Hintergrundtraining fehlschlägt, bleibt das Modell im Status UNTRAINED und Abfragen greifen auf das Remote-LLM zurück (oder geben einen Fehler zurück, wenn das Fallback deaktiviert ist).
  • RETRAINING_IN_PROGRESS: Das Neutraining im Hintergrund wird ausgeführt.
  • RETRAINING_FAILED: Der letzte Hintergrund- oder manuelle Neutrainingslauf ist fehlgeschlagen. In den meisten Szenarien verwendet AlloyDB, wenn Modellgewichtungen vor dem erneuten Training vorhanden sind, diese vorhandenen Modellgewichtungen für die Inferenz. Wenn keine vorhandenen Modellgewichtungen verfügbar sind (oder wenn die Genauigkeitsprüfungen zur Laufzeit fehlschlagen), greift AlloyDB auf die Auswertung von Abfragen mit dem Remote-LLM zurück (vorbehaltlich google_ml_integration.proxy_models_enable_llm_fallback), bis das Modell erfolgreich neu trainiert wurde.

Weitere Informationen zu allen in dieser Ansicht verfügbaren Spalten finden Sie unter Vorhandene Proxymodelle ansehen.

Beschränkungen

  • Optimierte KI-Funktionen unterstützen nur die Funktion ai.if().
  • Das regelmäßige automatische Neutrainieren von Proxymodellen im Hintergrund wird auf Datenbankinstanzen mit weniger als 32 vCPUs nicht unterstützt.
  • Sicherheit auf Zeilenebene (Row-Level Security, RLS): Bei Modellen, die mit Tabellen trainiert wurden, für die Richtlinien für die Sicherheit auf Zeilenebene (RLS) gelten, können Sicherheitsinformationen preisgegeben werden, wenn das Training mit den Berechtigungen eines bestimmten initiierenden Nutzers erfolgt. Das Training von Proxymodellen für Tabellen mit RLS-Richtlinien ist deaktiviert.
  • Eingabeänderungen: Wenn Sie die Spalte mit dem Quellinhalt, die Spalte mit der Einbettung, den Prompt-String oder die Basis-LLM-Modell-ID ändern, die für ai.if() bereitgestellt wird, wird das vorhandene Proxymodell umgangen und eine neue Hintergrundtrainingsanfrage für diese Kombination initiiert.
  • SQL-Einschränkungen:
    • Die Abfrage muss eine gültige FROM-Klausel enthalten.
    • Alle Argumente für die KI-Funktion müssen aus demselben Tabellen-Alias stammen.
    • Fügen Sie Spalten im Ausdruck ai.if() als Quellspalten für die Einbettung ein.
    • Platzieren Sie die Funktion ai.if() nicht in einer Unterabfrage oder einem allgemeinen Tabellenausdruck (CTE).

Nächste Schritte