Diese Seite wurde von der Cloud Translation API übersetzt.

Datenbank mit natürlicher Sprache abfragen

Auf dieser Seite wird eine Vorabversion beschrieben, die mit AlloyDB Omni verfügbar ist und mit der Sie Ihre Datenbank mithilfe natürlicher Sprache abfragen können.

Übersicht

Mit AlloyDB Omni können Sie eine Reihe experimenteller Funktionen in der Vorschau ansehen, mit denen Ihre databasengetriebene Anwendung Suchanfragen in natürlicher Sprache von Nutzern Ihrer Anwendung sicherer ausführen kann, z. B. „Wo ist mein Paket?“ oder „Wer ist der Top-Empfänger in jeder Abteilung?“ AlloyDB Omni übersetzt die Eingabe in natürlicher Sprache in eine SQL-Abfrage, die speziell auf Ihre Datenbank zugeschnitten ist. Die Ergebnisse werden auf die Daten beschränkt, die der Nutzer Ihrer Anwendung sehen darf.

Die Vorteile und Risiken von Abfragen in natürlicher Sprache

Mit Large Language Models wie Gemini Pro können Sie in Ihrer Anwendung Datenbankabfragen auf der Grundlage von Abfragen in natürlicher Sprache ausführen, die von den Endnutzern Ihrer Anwendung erstellt wurden. Ein Modell mit Zugriff auf das Datenbankschema Ihrer Anwendung kann beispielsweise Eingaben von Endnutzern wie diese verarbeiten:

What are the cheapest direct flights from Boston to Denver in July?

und in eine SQL-Abfrage wie diese übersetzen:

SELECT flight.id, flight.price, carrier.name, [...]
FROM [...]
WHERE [...]
ORDER BY flight.price ASC 
LIMIT 10

Abfragen in natürlicher Sprache können ein leistungsstarkes Tool für Ihre Anwendung sein, um Nutzern zu helfen. Diese Technologie birgt jedoch auch Sicherheitsrisiken, die Sie berücksichtigen müssen, bevor Sie Endnutzern erlauben, beliebige Abfragen in Ihren Datenbanktabellen auszuführen. Auch wenn Sie Ihre Anwendung so konfiguriert haben, dass sie sich als Datenbanknutzer mit eingeschränktem Zugriff und Lesezugriff mit Ihrer Datenbank verbindet, kann eine Anwendung, die Suchanfragen in natürlicher Sprache zulässt, anfällig für Folgendes sein:

Böswillige Nutzer können Prompt-Injection-Angriffe ausführen, um das zugrunde liegende Modell zu manipulieren und alle Daten zu enthüllen, auf die die Anwendung Zugriff hat.
Das Modell selbst kann SQL-Abfragen generieren, die weiter gefasst sind als angebracht, und so auch bei gut gemeinten Nutzeranfragen sensible Daten offenlegen.

Abfragen mit parametrisierten sicheren Ansichten bereinigen

Um die im vorherigen Abschnitt beschriebenen Risiken zu minimieren, hat Google parametrisierte sichere Ansichten entwickelt. Das ist eine experimentelle Funktion, die Sie mit den auf dieser Seite beschriebenen Methoden in der Vorabversion testen können.

Mit parametrisierten sicheren Ansichten können Sie die Tabellen und Spalten explizit definieren, aus denen Daten mit Abfragen in natürlicher Sprache abgerufen werden können, und zusätzliche Einschränkungen für den Zeilenbereich hinzufügen, der für einen einzelnen Anwendungsnutzer verfügbar ist. Mit diesen Einschränkungen können Sie genau steuern, welche Daten Nutzer Ihrer Anwendung über Suchanfragen in natürlicher Sprache sehen können, unabhängig davon, wie sie diese Anfragen formulieren.

Wenn Sie diese Vorabversion aktivieren, erhalten Sie Zugriff auf die experimentellen Erweiterungen alloydb_ai_nl und parameterized_views, die von Google entwickelt wurden.

Die parameterized_views-Erweiterung bietet folgende Funktionen:

Parametrisierte sichere Ansichten, eine Variante von SQL-Ansichten, mit der der Datenbereich eingeschränkt wird, auf den eine Abfrage zugreifen kann.
Die Funktion execute_parameterized_views(), mit der Sie Ihre parametrisierten sicheren Datenansichten abfragen können.

Die alloydb_ai_nl-Erweiterung bietet folgende Funktion:

Die Funktion google_get_sql_current_schema(), die Abfragen in natürlicher Sprache in SQL-Abfragen von Tabellen und Ansichten in Ihrem aktuellen Schema umwandelt.

In den folgenden Abschnitten wird beschrieben, wie Sie diese Funktionen verwenden und wie sie zusammenwirken können.

Hinweise

Installieren Sie AlloyDB Omni Version 15.5.1 oder höher, einschließlich der Integration von KI-Modellen. Weitere Informationen finden Sie unter AlloyDB Omni mit AlloyDB for PostgreSQL AI installieren.

Datenbank für parametrisierte sichere Ansichten einrichten

Verbinden Sie sich über psql mit Ihrem AlloyDB Omni-Cluster.
Bearbeiten Sie den Inhalt von /var/alloydb/config/postgresql.conf so, dass der Wert der shared_preload_libraries-Direktive alloydb_ai_nl und parameterized_views enthält. Die bearbeitete Richtlinie sollte in etwa so aussehen:
```
shared_preload_libraries='g_stats,google_job_scheduler,google_insights,pg_stat_statements,google_db_advisor,google_columnar_engine,alloydb_ai_nl,parameterized_views'
```
Hinweis :Wenn Sie die Vorabversion der vereinfachten Installationsmethode für AlloyDB Omni verwenden, müssen Sie Ihrer postgresql.conf-Datei möglicherweise die Anweisung shared_preload_libraries mit dem Wert alloydb_ai_nl,parameterized_views hinzufügen.
AlloyDB Omni beenden
Starten Sie AlloyDB Omni.

Aktivieren Sie die Erweiterungen alloydb_ai_nl und parameterized_views:

CREATE EXTENSION google_ml_integration;
ALTER SYSTEM SET google_ml_integration.enable_model_support=on;
ALTER SYSTEM SET alloydb_ai_nl.enabled=on;
ALTER SYSTEM SET parameterized_views.enabled=on;
SELECT pg_reload_conf();
CREATE EXTENSION alloydb_ai_nl CASCADE;
CREATE EXTENSION parameterized_views;

Registrieren Sie ein neues Sprachmodell auf der Grundlage der Gemini Pro API mit der Modellendpunktverwaltung:
```
CALL google_ml.create_model(
    model_id => 'MODEL_ID',
    model_request_url => 'https://us-central1-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/us-central1/publishers/google/models/gemini-pro:streamGenerateContent',
    model_provider => 'google',
    model_auth_type => 'alloydb_service_agent_iam');
```
Ersetzen Sie Folgendes:
- MODEL_ID: Eine ID, die diesem Modell zugewiesen werden soll. Weitere Informationen zur Verwaltung von Modellendpunkten finden Sie unter Remote-KI-Modelle in AlloyDB Omni registrieren und aufrufen.
- PROJECT_ID: Die ID Ihres Google Cloud -Projekts.
Erstellen Sie einen neuen Datenbanknutzer. Weisen Sie ihm noch keine Berechtigungen oder Rollen zu. In einem nachfolgenden Schritt dieses Verfahrens werden dem Nutzer die erforderlichen Berechtigungen gewährt.

Parametrisierte sichere Ansichten

Eine parametrisierte sichere Ansicht funktioniert ähnlich wie eine gewöhnliche sichere PostgreSQL-Ansicht: im Grunde eine gespeicherte SELECT-Anweisung. Bei parametrisierten sicheren Ansichten können Sie außerdem einen oder mehrere benannte Parameterwerte angeben, die bei der Abfrage an die Ansicht übergeben werden. Das funktioniert ähnlich wie bei Bindevariablen bei normalen Datenbankabfragen.

Angenommen, Sie führen eine Anwendung aus, deren Datenbank die Lieferungen von Artikeln an Kunden erfasst. Ein Nutzer, der mit der ID 12345 in der Abfrage Where is my package? in dieser Anwendung angemeldet ist Mithilfe von parametrisierten sicheren Ansichten können Sie dafür sorgen, dass die folgenden Anforderungen für die Ausführung dieser Abfrage in AlloyDB for PostgreSQL gelten:

Die Abfrage kann nur die Datenbankspalten lesen, die Sie explizit in den parametrisierten sicheren Ansichten Ihrer Datenbank aufgeführt haben. In diesem Fall können das bestimmte Spalten in den Tabellen items, users und shipments sein.
Die Abfrage kann nur die Datenbankzeilen lesen, die mit dem Nutzer verknüpft sind, der die Abfrage gestellt hat. In diesem Fall müssen die zurückgegebenen Zeilen möglicherweise eine Datenbeziehung zur Tabelle users haben, deren Wert in der Spalte id 12345 ist.

Parameterisierte sichere Ansicht erstellen

Verwenden Sie den PostgreSQL-DDL-Befehl CREATE VIEW mit den folgenden Attributen, um eine parametrisierte sichere Ansicht zu erstellen:

Erstellen Sie die Ansicht mit der Option security_barrier.
Wenn Sie festlegen möchten, dass Anwendungsnutzer nur die Zeilen sehen können, die für sie sichtbar sind, fügen Sie in der WHERE-Klausel erforderliche Parameter mit der Syntax $@PARAMETER_NAME hinzu. Ein häufiger Anwendungsfall ist die Prüfung des Werts einer Spalte mit WHERE COLUMN = $@PARAMETER_NAME.

Die folgende Beispiel-parametrisierte sichere Ansicht ermöglicht den Zugriff auf drei Spalten aus einer Tabelle mit dem Namen users und schränkt die Ergebnisse auf Zeilen ein, in denen users.id mit einem erforderlichen Parameter übereinstimmt:

CREATE VIEW user_psv WITH (security_barrier) AS 
SELECT 
  username,
  full_name,
  birthday
FROM 
  users
WHERE 
  users.id = $@user_id;

Die SELECT-Anweisungen, die den Kern sicherer parametrischer Ansichten bilden, können genauso komplex sein wie die Anweisungen, die in gewöhnlichen PostgreSQL-Ansichten zulässig sind.

Nachdem Sie eine Ansicht erstellt haben, müssen Sie dem zuvor erstellten Nutzer die Berechtigung erteilen, SELECT-Abfragen für die Ansicht auszuführen:

GRANT SELECT ON VIEW_NAME TO NL_DB_USER;

Ersetzen Sie Folgendes:

VIEW_NAME: Der Name der Ansicht, die Sie im vorherigen Schritt erstellt haben.
NL_DB_USER: Der Name des Datenbanknutzers, den Sie zum Ausführen von Suchanfragen in natürlicher Sprache festgelegt haben.

Parametrisierte sichere Ansicht abfragen

Trotz ihrer Ähnlichkeit mit gewöhnlichen PostgreSQL-Ansichten können Sie parametrisierte sichere Ansichten nicht direkt abfragen. Stattdessen verwenden Sie die Funktion execute_parameterized_query(), die von der Erweiterung parameterized_views bereitgestellt wird. Die Funktion hat die folgende Syntax:

SELECT * FROM
parameterized_views.execute_parameterized_query(
    query => SQL_QUERY
    param_names => ARRAY [PARAMETER_NAMES],
    param_values => ARRAY [PARAMETER_VALUES]
)

Ersetzen Sie Folgendes:

SQL_QUERY: Eine SQL-Abfrage, deren FROM-Klausel sich auf eine oder mehrere parametrisierte sichere Ansichten bezieht.
PARAMETER_NAMES: Eine Liste von Parameternamen, die als Strings übergeben werden.
PARAMETER_VALUES: Eine Liste von Parameterwerten, die übergeben werden sollen. Diese Liste muss dieselbe Größe wie die param_names-Liste haben. Die Reihenfolge der Werte entspricht der Reihenfolge der Namen.

Die Funktion gibt eine Tabelle mit JSON-Objekten zurück. Jede Zeile in der Tabelle entspricht dem row_to_json()-Wert der ursprünglichen Abfrageergebniszeile.

Bei normalem Gebrauch wird der Wert des query-Arguments nicht durch Ihren eigenen Code, sondern durch ein KI-Modell generiert, das Sie in Ihre AlloyDB for PostgreSQL-Datenbank eingebunden haben.

Das folgende Beispiel zeigt, wie Sie eine parametrisierte sichere Ansicht in Python abfragen und dann die Ergebnisse anzeigen können. Es baut auf der Beispielansicht user_psv aus dem vorherigen Abschnitt auf:

# Assume a get_user_id() function that returns the ID of the current
# application user.
app_user_id = get_user_id()

pool = await asyncpg.create_pool(
    host=INSTANCE_IP
    user=NL_DB_USER
    password=NL_DB_PASSWORD
    database=DB_NAME
)

table_name = "user_psv"

query = f"""
    SELECT 
      full_name,
      birthday
    FROM 
      {table_name} 
"""
params = {
    "user_id": app_user_id
}

param_query = f"""
SELECT * FROM parameterized_views.execute_parameterized_query(
  query => '{query}',
  param_names => $1,
  param_values => $2
);
"""

sql_results = await pool.execute(
    param_query, 
    params.keys(), 
    params.values()
)

for row in sql_results:
    print(json.loads(row))

Abfrage in natürlicher Sprache ausführen

Die Ausführung einer Abfrage in natürlicher Sprache mit parametrisierten sicheren Ansichten erfolgt in zwei Schritten:

Als Datenbanknutzer mit nur SELECT-Zugriff auf die entsprechenden parametrisierten sicheren Ansichten können Sie die Abfrage in natürlicher Sprache mithilfe eines Large Language Model in SQL konvertieren.
Verarbeiten Sie die SQL-Anfrage mit der Funktion execute_parameterized_query() und binden Sie sie an Parameterwerte, die der aktuellen Nutzersitzung entsprechen.

Diese Schritte werden in den folgenden Abschnitten näher erläutert.

Natürliche Sprache in SQL konvertieren

Verwenden Sie die Funktion google_get_sql_current_schema(), die in der Technologievorschau für parameterisierte sichere Ansichten enthalten ist, um Eingaben in natürlicher Sprache in SQL zu übersetzen:

SELECT alloydb_ai_nl.google_get_sql_current_schema(
  sql_text => 'NL_TEXT',
  model_id => 'MODEL_ID',
  prompt_text => 'HINT_TEXT'
);

Ersetzen Sie Folgendes:

NL_TEXT: Der Text in natürlicher Sprache, der in eine SQL-Abfrage umgewandelt werden soll.
MODEL_ID: Die ID des Modells, das Sie beim Einrichten Ihrer Datenbank für parametrisierte sichere Ansichten im Modellkatalog registriert haben.
HINT_TEXT: Zusätzliche Informationen zum Datenbankschema, ausgedrückt in natürlicher Sprache. So können Sie dem Modell zusätzliche Hinweise zu wichtigen Aspekten des Schemas geben, die es möglicherweise nicht nur durch die Analyse der Tabellen-, Spalten- und Beziehungsstrukturen extrahieren kann. Beispiel: When joining flights and seats, be sure to join on flights.id = seats.flight_id.

Die Ausgabe der Funktion ist ein String mit einer SQL-Abfrage.

Konvertierte SQL-Abfrage mit Parametern ausführen

Nachdem Sie die Abfrage in natürlicher Sprache in SQL konvertiert haben, können Sie execute_parameterized_views() wie oben auf dieser Seite beschrieben aufrufen und alle Parameter übergeben, die für Ihre parametrisierten sicheren Ansichten erforderlich sind.

Die Funktion funktioniert, wenn Sie ihr bei einer bestimmten Abfrage mehr Parameter als erforderlich übergeben. Sie können sie also mit allen Parametern aufrufen, die von allen parametrisierten sicheren Ansichten verwendet werden, für die Ihre Anwendung Werte hat. Die Funktion löst eine Ausnahme aus, wenn versucht wird, eine Abfrage auszuführen, für die ein nicht definierter Parameter erforderlich ist.

Beispiel für die Ausführung einer Abfrage in natürlicher Sprache

In diesem Abschnitt wird der vollständige Ablauf von der Eingabe in natürlicher Sprache bis zum SQL-Ergebnisbereich veranschaulicht. Die Codebeispiele zeigen die zugrunde liegenden SQL-Abfragen und ‑Funktionen, die in einer Anwendung ausgeführt werden.

Für diesen Beispielablauf wird Folgendes über Ihre Anwendung vorausgesetzt:

Ihre datenbankgestützte Anwendung überwacht Produktlieferungen an Kunden.
Sie haben ein Gemini Pro-basiertes Modell namens my-gemini-model im Modellkatalog registriert.
Sie haben in Ihrer Datenbank eine parametrisierte sichere Ansicht mit dem Namen shipment_view definiert.
- In der Ansicht werden Daten aus mehreren Tabellen ausgewählt, die für Lieferungen an Kunden relevant sind.
- Für die Ansicht ist ein user_id-Parameter erforderlich, dessen Wert die ID eines Endnutzers der Anwendung ist.

Ein Endnutzer mit der Anwendungsnutzer-ID 12345 gibt in Ihrer Webanwendung „Wo ist mein Paket?“ ein.
Ihre Anwendung ruft google_get_sql_current_schema() auf, um die Eingabe in SQL zu übersetzen:
```
SELECT alloydb_ai_nl.google_get_sql_current_schema(
  sql_text => 'Where is my package?'
  model_id => 'my-gemini-model'
);
```
Dieser Aufruf gibt einen String mit einer einzelnen SQL-SELECT-Abfrage zurück. Die Abfrage ist auf die parametrisierten sicheren Ansichten beschränkt, die für den Datenbanknutzer sichtbar sind, den Sie zum Arbeiten mit parametrisierten sicheren Ansichten erstellt haben.

Der aus Where is my package? generierte SQL-Code könnte in etwa so aussehen:
```
SELECT current_location, ship_date, ship_eta FROM shipment_view;
```
Da shipment_view eine parametrisierte sichere Ansicht und keine gewöhnliche PostgreSQL-Ansicht ist, muss Ihre Anwendung execute_parameterized_views() verwenden, um die Abfrage mit dem erforderlichen Parameter user_id sicher auszuführen, wie im nächsten Schritt gezeigt.
Ihre Anwendung gibt die SQL-Anfrage zusammen mit den Parametern, die die Ausgabe einschränken, an execute_parameterized_views() weiter. In unserem Beispiel ist das die ID des Endnutzers der Anwendung, der die Eingabe gemacht hat:
```
SELECT * FROM
parameterized_views.execute_parameterized_views(
    query => 'SELECT current_location, ship_date, ship_eta FROM shipment_view',
    param_names => ['user_id'],
    param_values => ['12345']
);
```
Die Ausgabe ist ein SQL-Ergebnisbereich, der als JSON-Daten dargestellt wird.
Ihre Anwendung verarbeitet die JSON-Daten nach Bedarf.

Datenbankdesign für die Verarbeitung natürlicher Sprache

Die Funktion google_get_sql_current_schema(), die in dieser Technologievorschau bereitgestellt wird, dient hauptsächlich dazu, die Funktionalität parametrisierter sicherer Ansichten zu demonstrieren. So haben Sie die Möglichkeit, schon früh mit dieser sich entwickelnden Technologie zu experimentieren. Wie bei jeder Vorabversion sollten Sie diese Funktion nicht auf eine Produktionsanwendung anwenden.

Mit den Tipps in diesem Abschnitt können Sie die Qualität der google_get_sql_current_schema()-Ausgabe bei Ihren Tests verbessern.

Schema für die menschliche Wahrnehmung entwerfen

Geben Sie Ihren Datenbankstrukturen im Allgemeinen Namen und Kommentare, die klar genug sind, damit ein typischer Entwickler den Zweck der Tabellen, Spalten und Beziehungen ableiten kann. Diese Klarheit kann dazu beitragen, dass ein Large Language Model genauere SQL-Abfragen basierend auf Ihrem Schema generiert.

Verwenden Sie aussagekräftige Namen.

Verwenden Sie für Tabellen, Spalten und Beziehungen vorzugsweise beschreibende Namen. Vermeiden Sie Abkürzungen oder Akronyme. Das Modell funktioniert beispielsweise besser mit einer Tabelle namens users als mit einer Tabelle namens u.

Wenn vorhandene Datenstrukturen nicht umbenannt werden können, geben Sie dem Modell beim Aufrufen von google_get_sql_current_schema() Hinweise mit dem Argument prompt_text.

Bestimmte Datentypen verwenden

Das Modell kann bessere Rückschlüsse auf Ihre Daten ziehen, wenn Sie für Ihre Spalten spezifischere Datentypen verwenden. Wenn Sie eine Spalte beispielsweise ausschließlich zum Speichern von „Wahr“- oder „Falsch“-Werten verwenden, verwenden Sie einen boolean-Datentyp mit true und false anstelle eines integer-Datentyps mit 1 und 0.

Nach Aktivierung der Vorabversion mit Vorsicht ein Rollback durchführen

Wenn Sie die Technologievorschau für parametrisierte sichere Ansichten in Ihrer Datenbank aktiviert haben, aber AlloyDB Omni auf eine Version vor 15.5.0 zurücksetzen möchten, müssen Sie vor dem Downgrade einige manuelle Schritte zur Bereinigung ausführen.

Wenn Sie diese Schritte nicht ausführen, führt jeder Versuch, eine parametrisierte sichere Ansicht abzufragen, zu ändern oder zu löschen, zu einem SQL-Fehler. Dazu gehören Abfragen im Ansichtskatalog Ihrer Datenbank, die andernfalls parametrisierte sichere Ansichten in den Ergebnissen enthalten würden, z. B. SELECT * FROM pg_views.

So entfernen Sie diese Technologievorschau vor einem AlloyDB Omni-Rollback vollständig aus Ihrer Datenbank:

Verwenden Sie in psql den Befehl DROP VIEW, um alle parametrisierten sicheren Ansichten in Ihrer Datenbank zu löschen.
Verwenden Sie in psql den Befehl DROP EXTENSION, um die Erweiterungen alloydb_ai_nl und parameterized_views in Ihrer Datenbank zu deaktivieren.
Entfernen Sie in der Datei postgresql.conf die Verweise auf alloydb_ai_nl und parameterized_views aus der Anweisung shared_preload_libraries.

Weitere Informationen zum Zurücksetzen Ihrer AlloyDB Omni-Installation finden Sie unter Rollback für ein Upgrade durchführen.