Infrastruktur für eine RAG-fähige generative KI-Anwendung mit Vertex AI

Last reviewed 2024-06-07 UTC

In diesem Dokument wird eine Referenzarchitektur vorgestellt, mit der Sie die Infrastruktur für die Ausführung einer Anwendung mit generativer künstlicher Intelligenz (KI) mit Retrieval Augmented Generation (RAG) erstellen können. Die Zielgruppe für dieses Dokument umfasst Entwickler und Administratoren von generativen KI-Anwendungen und Cloud-Architekten. In diesem Dokument werden grundlegende Kenntnisse der Konzepte von KI, maschinellem Lernen (ML) und Large Language Model (LLM) vorausgesetzt. Dieses Dokument bietet keine Anleitung zum Entwerfen und Entwickeln einer generativen KI-Anwendung.

Architektur

Das folgende Diagramm zeigt eine allgemeine Ansicht einer Architektur für eine RAG-fähige generative KI-Anwendung in Google Cloud:

Allgemeine Architektur für eine RAG-fähige generative KI-Anwendung in Google Cloud

Die Architektur enthält die folgenden miteinander verbundenen Komponenten:

Komponente Zweck Interaktionen
Datenaufnahme-Subsystem Bereiten Sie die externen Daten vor, die zur Aktivierung der RAG-Funktion verwendet werden, und verarbeiten Sie sie. Das Datenaufnahmesubsystem interagiert über die Datenbankebene mit den anderen Subsystemen in der Architektur.
Subsystem für die Bereitstellung Verarbeiten des Anfrage-/Antwort-Ablaufs zwischen der generativen KI-Anwendung und ihren Nutzern. Das Bereitstellungssubsystem interagiert über die Datenbankebene mit dem Datenaufnahmesubsystem.
Subsystem zur Qualitätsbewertung Bewerten Sie die Qualität der Antworten, die das Bereitstellungs-Subsystem generiert. Das Subsystem zur Qualitätsbewertung interagiert direkt mit dem Bereitstellungssubsystem und über die Datenbankebene mit dem Datenaufnahmesubsystem.
Datenbanken Speichern Sie die folgenden Daten:
  • Aufforderungen
  • Vektorisierte Einbettungen der für RAG verwendeten Daten
  • Konfiguration der serverlosen Jobs in den Subsystemen für Datenaufnahme und Qualitätsbewertung
Alle Subsysteme in der Architektur interagieren mit den Datenbanken.

Im folgenden Diagramm sehen Sie eine detaillierte Ansicht der Architektur:

Eine detaillierte Architektur für eine RAG-fähige generative KI-Anwendung in Google Cloud.

Die folgenden Abschnitte enthalten detaillierte Beschreibungen der Komponenten und des Datenflusses in jedem Subsystem der Architektur.

Datenaufnahme-Subsystem

Das Datenaufnahme-Subsystem nimmt Daten aus externen Quellen wie Dateien, Datenbanken und Streamingdiensten auf. Die hochgeladenen Daten enthalten Aufforderungen zur Qualitätsbewertung. Das Datenaufnahme-Subsystem bietet die RAG-Funktion in der Architektur. Das folgende Diagramm zeigt Details des Datenaufnahme-Subsystems in der Architektur:

Das Datenaufnahme-Subsystem für eine RAG-fähige generative KI-Anwendung in Google Cloud.

Folgende Schritte sind im Ablauf der Datenaufnahme erforderlich:

  1. Die Daten werden in einen Cloud Storage-Bucket hochgeladen. Die Datenquelle kann ein Anwendungsnutzer sein, der einen Upload, eine Datenbankaufnahme oder Streaming-Daten durchführt.
  2. Beim Hochladen von Daten wird eine Benachrichtigung an ein Pub/Sub-Thema gesendet.
  3. Pub/Sub löst einen Cloud Run-Job aus, um die hochgeladenen Daten zu verarbeiten.
  4. Cloud Run startet den Job mit Konfigurationsdaten, die in einer AlloyDB for PostgreSQL-Datenbank gespeichert sind.
  5. Der Cloud Run-Job verwendet Document AI, um die Daten für die weitere Verarbeitung vorzubereiten. Die Vorbereitung kann beispielsweise das Parsen der Daten, das Konvertieren der Daten in das erforderliche Format und das Aufteilen der Daten in Blöcke umfassen.

  6. Der Cloud Run-Job verwendet das Modell „Vertex AI Embeddings for Text“, um vektorisierte Einbettungen der aufgenommenen Daten zu erstellen.

  7. Cloud Run speichert die Einbettungen in einer AlloyDB for PostgreSQL-Datenbank, für die die Erweiterung pgvector aktiviert ist. Wie im folgenden Abschnitt beschrieben, verwendet das Bereitstellungssubsystem Nutzeranfragen mithilfe der Einbettungen in der Vektordatenbank, um relevante domainspezifische Daten abzurufen.

Subsystem für die Bereitstellung

Das Bereitstellungssubsystem verarbeitet den Anfrage-Antwort-Fluss zwischen der generativen KI-Anwendung und ihren Nutzern. Das folgende Diagramm zeigt Details des Bereitstellungs-Subsystems in der Architektur:

Das Bereitstellungssubsystem für eine RAG-fähige generative KI-Anwendung in Google Cloud.

Die folgenden Schritte sind im Anfrage-Antwort-Ablauf im Bereitstellungs-Subsystem dargestellt:

  1. Nutzer senden Anfragen über ein Frontend (z. B. einen Chatbot oder eine mobile App) an die generative KI-Anwendung.

  2. Die generative KI-Anwendung konvertiert die Natural Language-Anfrage in Einbettungen.

  3. Die Anwendung schließt den Abrufteil des RAG-Ansatzes ab:

    1. Die Anwendung führt eine semantische Suche nach der Einbettung im AlloyDB for PostgreSQL-Vektorspeicher durch, der vom Datenaufnahme-Subsystem verwaltet wird. Mit der semantischen Suche lassen sich Einbettungen anhand der Absicht eines Prompts und nicht anhand ihres Textinhalts finden.
    2. Die Anwendung kombiniert die ursprüngliche Anfrage mit den Rohdaten, die basierend auf der übereinstimmenden Einbettung abgerufen werden, um einen kontextbezogenen Prompt zu erstellen.

  4. Die Anwendung sendet die kontextbezogene Eingabeaufforderung an einen LLM-Inferenz-Stack, der in Vertex AI ausgeführt wird.

  5. Der LLM-Inferenz-Stack verwendet ein generatives KI-LLM, das ein Basis-LLM oder ein benutzerdefiniertes LLM sein kann, und generiert eine Antwort, die auf den bereitgestellten Kontext beschränkt ist.

    1. Die Anwendung kann Logs der Anfrage-Antwort-Aktivität in Cloud Logging speichern. Sie können die Logs für Monitoring mit Cloud Monitoring aufrufen und verwenden. Google greift nicht auf Protokolldaten zu und verwendet sie auch nicht.
    2. Die Anwendung lädt die Antworten zur Offlineanalyse in BigQuery.

  6. Die Anwendung prüft die Antworten mithilfe von verantwortungsbewussten KI-Filtern.

  7. Die Anwendung sendet die geprüften Antworten über das Frontend an Nutzer.

Subsystem zur Qualitätsbewertung

Das folgende Diagramm zeigt Details des Subsystems für die Qualitätsbewertung in der Architektur:

Das Subsystem zur Qualitätsbewertung für eine RAG-fähige generative KI-Anwendung in Google Cloud.

Wenn das Subsystem zur Qualitätsbewertung eine Anfrage erhält, führt es folgende Schritte aus:

  1. Pub/Sub löst einen Cloud Run-Job aus.
  2. Cloud Run startet den Job mit Konfigurationsdaten, die in einer AlloyDB for PostgreSQL-Datenbank gespeichert sind.
  3. Der Cloud Run-Job ruft Bewertungs-Prompts aus einer AlloyDB for PostgreSQL-Datenbank ab. Die Eingabeaufforderungen wurden zuvor vom Datenaufnahme-Subsystem in die Datenbank hochgeladen.

  4. Der Cloud Run-Job verwendet die Bewertungsaufforderungen, um die Qualität der Antworten zu bewerten, die das Bereitstellungssubsystem generiert.

    Das Ergebnis dieser Bewertung besteht aus Bewertungswerten für Messwerte wie sachliche Genauigkeit und Relevanz.

  5. Cloud Run lädt die Bewertungsergebnisse sowie die Eingabeaufforderungen und Antworten, die für die zukünftige Analyse in BigQuery ausgewertet wurden.

Verwendete Produkte

Im Folgenden finden Sie eine Zusammenfassung aller Google Cloud-Produkte, die in der vorherigen Architektur verwendet werden:

  • Vertex AI: Eine ML-Plattform, mit der Sie ML-Modelle und KI-Anwendungen trainieren und bereitstellen und LLMs für die Verwendung in KI-basierten Anwendungen anpassen können.
  • Cloud Run ist eine serverlose Computing-Plattform, mit der Sie Container direkt auf der skalierbaren Infrastruktur von Google ausführen können.
  • BigQuery: Ein Data Warehouse für Unternehmen, mit dem Sie Ihre Daten mit integrierten Features wie raumbezogenen Analysen für maschinelles Lernen und Business Intelligence verwalten und analysieren können.
  • Cloud Storage: Ein kostengünstiger, unbegrenzter Objektspeicher für verschiedene Datentypen. Auf Daten kann von innerhalb und außerhalb von Google Cloud zugegriffen werden. Sie werden zu Redundanzzwecken über Standorte hinweg repliziert.
  • AlloyDB for PostgreSQL: Ein vollständig verwalteter, PostgreSQL-kompatibler Datenbankdienst, der für Ihre anspruchsvollsten Arbeitslasten entwickelt wurde, einschließlich hybrider transaktionsorientierter und analytischer Verarbeitung.
  • Document AI: Eine Plattform zur Dokumentverarbeitung, die unstrukturierte Daten aus Dokumenten in strukturierte Daten transformiert.
  • Pub/Sub: Ein asynchroner, skalierbarer Messaging-Dienst, der Dienste entkoppelt, die Nachrichten von Diensten erzeugen, die diese Nachrichten verarbeiten.
  • Cloud Logging: Ein Echtzeit-Log-Verwaltungssystem mit Speicher, Suche, Analyse und Benachrichtigungen.
  • Cloud Monitoring: Ein Dienst, der Einblicke in die Leistung, Verfügbarkeit und Integrität Ihrer Anwendungen und Infrastruktur bietet.

Anwendungsfälle

RAG ist eine effektive Technik, um die Qualität der von einem LLM generierten Ausgabe zu verbessern. In diesem Abschnitt finden Sie Beispiele für Anwendungsfälle, in denen Sie RAG-fähige generative KI-Anwendungen verwenden können.

Personalisierte Produktempfehlungen

Eine Online-Shopping-Website verwendet möglicherweise einen LLM-gestützten Chatbot, um Kunden bei der Suche nach Produkten oder bei der Hilfe beim Einkaufen zu unterstützen. Die Fragen eines Nutzers können mithilfe von Verlaufsdaten zum Kaufverhalten des Nutzers und zu Website-Interaktionsmustern erweitert werden. Die Daten können Nutzerrezensionen und -feedback enthalten, die in einem unstrukturierten Datenspeicher oder suchbezogenen Messwerten, die in einem Webanalyse-Data-Warehouse gespeichert werden. Die erweiterte Frage kann dann vom LLM verarbeitet werden, um personalisierte Antworten zu generieren, die für den Nutzer ansprechender und ansprechender sind.

Klinische Unterstützungssysteme

Ärzte in Krankenhäusern müssen den Gesundheitszustand eines Patienten schnell analysieren und diagnostizieren, um Entscheidungen über eine angemessene Versorgung und Medikamente treffen zu können. Eine generative KI-Anwendung, die ein medizinisches LLM wie Med-PaLM verwendet, kann verwendet werden, um Ärzte bei ihrem klinischen Diagnoseprozess zu unterstützen. Die von der Anwendung generierten Antworten können auf historischen Patientenakten basieren, indem die Aufforderungen der Ärzte mit Daten aus der EHR-Datenbank (Electronic Health Record) des Krankenhauses oder aus einer externen Wissensdatenbank wie PubMed in Beziehung gesetzt werden:

Mit der generativen KI-basierten Rechtsforschung können Anwälte große Mengen von Gesetzen und Fallgesetzen schnell abfragen, um relevante Prädikate zu ermitteln oder komplexe rechtliche Konzepte zusammenzufassen. Das Ergebnis einer solchen Forschungsarbeit kann durch die Erweiterung der Aufforderungen eines Anwalts mit Daten aus dem proprietären Korpus von Verträgen, früheren rechtlichen Mitteilungen und internen Fallaufzeichnungen der Anwaltskanzlei ergänzt werden. Durch diesen Designansatz wird sichergestellt, dass die generierten Antworten für das Fachgebiet relevant sind, auf das der Anwalt spezialisiert ist.

Designalternative

Für den Vektorspeicher und die semantischen Suchkomponenten in der Architektur können Sie die Vertex AI Vektorsuche verwenden. Die Vektorsuche ist ein vollständig verwalteter Dienst, der eine optimierte Bereitstellungsinfrastruktur für die sehr umfangreiche Vektorsuche bietet. Die Rohdaten (Textblöcke) können entweder in Objektspeichern wie Cloud Storage oder in Schlüssel/Wert-Speichern wie Filestore gespeichert werden. In beiden Fällen wird die Vektordarstellung jedes Rohtextblocks in der Vektorsuche gespeichert.

Wenn Daten aufgenommen werden, wird jedem Rohtextblock eine eindeutige ID zugewiesen. Diese ID wird in Cloud Storage als Dateiname des Objekts verwendet. Dieselbe ID wird als Vektor-ID in der Vektorsuche verwendet.

Zum Zeitpunkt der Bereitstellung wird eine eingehende Textabfrage in einen Einbettungsvektor umgewandelt. Die Vektorsuche führt eine Ähnlichkeitssuche durch, um die semantisch ähnlichsten Vektoren zurückzugeben. Die Vektor-IDs werden dann verwendet, um die ursprünglichen Textblöcke zu suchen. Gemeinsam bieten diese Textblöcke den relevanten Kontext an, den das LLM für eine bestimmte Aufgabe benötigt.

Informationen zum Erstellen, Bereitstellen und Abfragen eines Vektorsuchindexes finden Sie in der Kurzanleitung zur Vektorsuche.

Designaspekte

Dieser Abschnitt enthält eine Anleitung zum Entwickeln einer RAG-fähigen generativen KI-Architektur in Google Cloud, die Ihre spezifischen Anforderungen an Sicherheit und Compliance, Zuverlässigkeit, Kosten und Leistung erfüllt. Die Anleitung in diesem Abschnitt ist nicht vollständig. Abhängig von den spezifischen Anforderungen Ihrer generativen KI-Anwendung und der von Ihnen verwendeten Google Cloud-Produkte und -Features müssen Sie möglicherweise zusätzliche Designfaktoren und Kompromisse berücksichtigen.

Sicherheit und Compliance

In diesem Abschnitt werden Faktoren beschrieben, die Sie beim Entwerfen und Erstellen einer RAG-fähigen generativen KI-Anwendung in Google Cloud berücksichtigen sollten, die Ihre Sicherheits- und Compliance-Anforderungen erfüllt.

Produkt Designaspekte
Vertex AI Vertex AI unterstützt Google Cloud-Sicherheitskontrollen, mit denen Sie Ihre Anforderungen an Datenstandort, Datenverschlüsselung, Netzwerksicherheit und Access Transparency erfüllen können. Weitere Informationen finden Sie unter Sicherheitskontrollen für Vertex AI und Sicherheitskontrollen für generative KI.
Cloud Run

Standardmäßig verschlüsselt Cloud Run Daten mit einem Google-eigenen und von Google verwalteten Schlüssel. Zum Schutz Ihrer Container mit einem von Ihnen kontrollierten Schlüssel können Sie vom Kunden verwaltete Verschlüsselungsschlüssel verwenden (CMEK). Weitere Informationen finden Sie unter vom Kunden verwaltete Verschlüsselungsschlüssel verwenden.

Damit nur autorisierte Container-Images in den Cloud Run-Jobs bereitgestellt werden, können Sie die Binärautorisierung verwenden.

Cloud Run unterstützt Sie dabei, die Anforderungen an den Datenstandort zu erfüllen. Cloud Run-Containerinstanzen werden in der von Ihnen ausgewählten Region ausgeführt.

AlloyDB for PostgreSQL

Standardmäßig werden Daten, die in AlloyDB for PostgreSQL gespeichert sind, mit Google-eigenen und von Google verwalteten Schlüsseln verschlüsselt. Wenn Sie Verschlüsselungsschlüssel verwenden müssen, die Sie selbst steuern und verwalten, können Sie dazu CMEKs verwenden. Weitere Informationen finden Sie unter Informationen zu CMEK.

Sie können mit VPC Service Controls einen Dienstperimeter erstellen, um das Risiko einer Daten-Exfiltration aus AlloyDB for PostgreSQL-Datenbanken zu verringern.

Standardmäßig akzeptiert eine AlloyDB for PostgreSQL-Instanz nur Verbindungen, die SSL verwenden. Wenn Sie Verbindungen zu Ihren AlloyDB for PostgreSQL-Datenbanken weiter sichern möchten, können Sie den Auth-Proxy-Connector von AlloyDB for PostgreSQL verwenden. Der Auth-Proxy-Connector bietet eine auf der Identitäts- und Zugriffsverwaltung basierende Verbindungsautorisierung und verwendet eine TLS 1.3-Verbindung mit einer 256-Bit-AES-Chiffre, um Client- und Serveridentitäten zu überprüfen und den Datentraffic zu verschlüsseln. Weitere Informationen finden Sie unter Auth-Proxy von AlloyDB for PostgreSQL. Verwenden Sie für Verbindungen, die mit Java, Python oder Go erstellt wurden, den entsprechenden Sprach-Connector anstelle des Auth-Proxy-Connectors.

Mit AlloyDB for PostgreSQL können Sie die Anforderungen an den Datenstandort erfüllen. Die Daten werden in den von Ihnen angegebenen Regionen gespeichert oder repliziert.

BigQuery

BigQuery bietet viele Funktionen, mit denen Sie den Zugriff auf Daten steuern, sensible Daten schützen und die Datengenauigkeit und -konsistenz gewährleisten können. Weitere Informationen finden Sie unter Einführung in die Data Governance in BigQuery.

BigQuery unterstützt Sie dabei, die Anforderungen an den Datenstandort zu erfüllen. Die Daten werden in der von Ihnen angegebenen Region gespeichert.

Cloud Storage

Standardmäßig werden in Cloud Storage gespeicherte Daten mit Google-eigenen und von Google verwalteten Schlüsseln verschlüsselt. Bei Bedarf können Sie CMEKs oder Ihre eigenen Schlüssel verwenden, die Sie mithilfe einer externen Verwaltungsmethode wie vom Kunden bereitgestellte Verschlüsselungsschlüssel (Customer-Supplied Encryption Keys, CSEKs) verwalten. Weitere Informationen finden Sie unter Datenverschlüsselungsoptionen.

Cloud Storage bietet Ihnen zwei Systeme, um Nutzern die Berechtigung zum Zugriff auf Ihre Buckets und Objekte zu erteilen: IAM und Access Control Lists (ACLs). In den meisten Fällen empfehlen wir die Verwendung von IAM, mit dem Sie Berechtigungen auf Bucket- und Projektebene erteilen können. Weitere Informationen finden Sie unter Zugriffssteuerung.

Die Daten, die Sie über Cloud Storage in das Datenaufnahmesubsystem laden, können sensible Daten enthalten. Zum Schutz solcher Daten können Sie die Daten mithilfe von Sensitive Data Protection ermitteln, klassifizieren und de-identifizieren. Weitere Informationen finden Sie unter Sensitive Data Protection mit Cloud Storage verwenden.

Cloud Storage unterstützt Sie dabei, die Anforderungen an den Datenstandort zu erfüllen. Die Daten werden in den von Ihnen angegebenen Regionen gespeichert oder repliziert.

Pub/Sub

Standardmäßig verschlüsselt Pub/Sub alle Nachrichten, sowohl im inaktiven Zustand als auch bei der Übertragung, mit Google-eigenen und von Google verwalteten Schlüsseln. Pub/Sub unterstützt die Verwendung von CMEKs für die Nachrichtenverschlüsselung auf Anwendungsebene. Weitere Informationen finden Sie unter Nachrichtenverschlüsselung konfigurieren.

Wenn Sie Anforderungen an den Datenstandort haben, können Sie Richtlinien für den Nachrichtenspeicher konfigurieren, um sicherzustellen, dass Nachrichtendaten an bestimmten Standorten gespeichert werden.

Document AI Standardmäßig werden inaktive Daten mit von Google verwalteten Verschlüsselungsschlüsseln verschlüsselt. Wenn Sie Verschlüsselungsschlüssel verwenden müssen, die Sie selbst steuern und verwalten, können Sie dazu CMEKs verwenden. Weitere Informationen finden Sie unter Sicherheit und Compliance von Document AI.
Cloud Logging

Audit-Logs zur Administratoraktivität sind standardmäßig für alle Google Cloud-Dienste aktiviert, die in dieser Referenzarchitektur verwendet werden. In diesen Logs werden API-Aufrufe oder andere Aktionen aufgezeichnet, die die Konfiguration oder Metadaten von Google Cloud-Ressourcen ändern.

Audit-Logs zum Datenzugriff sind für BigQuery standardmäßig aktiviert. Für die anderen Dienste, die in dieser Architektur verwendet werden, können Sie Audit-Logs zum Datenzugriff aktivieren. Mit den Logs können Sie API-Aufrufe verfolgen, die die Konfiguration oder Metadaten von Ressourcen oder Nutzeranfragen zum Erstellen, Ändern oder Lesen der von Nutzern bereitgestellten Ressourcendaten lesen.

Zur Erfüllung der Anforderungen an den Datenstandort können Sie Cloud Logging so konfigurieren, dass Logdaten in der von Ihnen angegebenen Region gespeichert werden. Weitere Informationen finden Sie unter Logs regionalisieren.

Allgemeine Anleitungen zu Sicherheitsgrundsätzen für KI-Anwendungen finden Sie unter Einführung in das Secure AI Framework von Google.

Zuverlässigkeit

In diesem Abschnitt werden Designfaktoren beschrieben, die Sie beim Erstellen und Betrieb einer zuverlässigen Infrastruktur für eine RAG-fähige generative KI-Anwendung in Google Cloud berücksichtigen sollten.

Produkt Designaspekte
Cloud Run

Cloud Run ist ein regionaler Dienst. Die Daten werden synchron über mehrere Zonen innerhalb einer Region hinweg gespeichert. Der Traffic wird automatisch auf die Zonen verteilt. Wenn ein Zonenausfall auftritt, werden Cloud Run-Jobs weiterhin ausgeführt und es gehen keine Daten verloren. Wenn ein regionaler Ausfall auftritt, werden die Cloud Run-Jobs so lange ausgeführt, bis Google den Ausfall behoben hat.

Einzelne Cloud Run-Jobs oder -Aufgaben können fehlschlagen. Zur Behebung solcher Fehler können Sie Aufgabenwiederholungen und Prüfpunktausführung verwenden. Weitere Informationen finden Sie unter Best Practices für Wiederholungsversuche und Prüfpunkte.

AlloyDB for PostgreSQL

Standardmäßig bieten AlloyDB for PostgreSQL-Cluster eine Hochverfügbarkeit (High Availability, HA) mit automatischem Failover. Die primäre Instanz hat redundante Knoten, die sich in zwei verschiedenen Zonen innerhalb einer Region befinden. Diese Redundanz gewährleistet, dass die Cluster gegen Zonenausfälle resistent sind.

Zur Planung der Wiederherstellung nach regionalen Ausfällen können Sie die regionenübergreifende Replikation verwenden.

BigQuery

Daten, die Sie in BigQuery laden, werden synchron in zwei Zonen innerhalb der von Ihnen angegebenen Region gespeichert. Diese Redundanz trägt dazu bei, dass Ihre Daten nicht verloren gehen, wenn ein Zonenausfall auftritt.

Weitere Informationen zu Zuverlässigkeitsfeatures in BigQuery finden Sie unter Zuverlässigkeit.

Cloud Storage Sie können Cloud Storage-Buckets an einem von drei Standorttypen erstellen: regional, biregional oder multiregional. In regionalen Buckets gespeicherte Daten werden synchron über mehrere Zonen innerhalb einer Region repliziert. Für eine höhere Verfügbarkeit können Sie Buckets mit zwei oder mehr Regionen verwenden, bei denen Daten asynchron über Regionen hinweg repliziert werden.
Pub/Sub

Zum Verwalten vorübergehender Spitzen beim Nachrichtentraffic können Sie die Ablaufsteuerung in den Publisher-Einstellungen konfigurieren.

Passen Sie die Variablen für Wiederholungsanfragen nach Bedarf an, um fehlgeschlagene Veröffentlichungen zu verarbeiten. Weitere Informationen finden Sie unter Anfragen wiederholen.

Document AI Document AI ist ein regionaler Dienst. Die Daten werden synchron über mehrere Zonen innerhalb einer Region hinweg gespeichert. Der Traffic wird automatisch auf die Zonen verteilt. Wenn ein zonaler Ausfall auftritt, gehen keine Daten verloren. Wenn ein regionaler Ausfall auftritt, ist Document AI erst verfügbar, wenn Google den Ausfall behoben hat.

Kostenoptimierung

Dieser Abschnitt enthält Anleitungen zum Optimieren der Kosten für die Einrichtung und den Betrieb einer RAG-fähigen generativen KI-Anwendung in Google Cloud.

Produkt Designaspekte
Cloud Run

Beim Erstellen von Cloud Run-Jobs geben Sie die Größe des Arbeitsspeichers und die CPU an, die der Containerinstanz zugewiesen werden sollen. Zur Kostenkontrolle beginnen Sie mit den standardmäßigen (Mindest-)CPU- und -Speicherzuweisungen. Zur Verbesserung der Leistung können Sie die Zuweisung erhöhen, indem Sie das CPU-Limit und das Speicherlimit konfigurieren.

Wenn Sie die CPU- und Arbeitsspeicheranforderungen Ihrer Cloud Run-Jobs vorhersagen können, können Sie Geld sparen, weil Sie Rabatte für die zugesicherte Nutzung erhalten. Weitere Informationen finden Sie unter Rabatte für zugesicherte Nutzung von Cloud Run.

AlloyDB for PostgreSQL

Standardmäßig ist eine primäre Instanz eines AlloyDB for PostgreSQL-Clusters hochverfügbar. Die Instanz hat einen aktiven Knoten und einen Standby-Knoten. Wenn der aktive Knoten ausfällt, führt AlloyDB for PostgreSQL automatisch ein Failover auf den Standby-Knoten durch. Wenn Sie keine Hochverfügbarkeit für die Datenbanken benötigen, können Sie die Kosten senken, indem Sie die primäre Instanz des Clusters zu einer einfachen Instanz machen. Eine einfache Instanz ist nicht gegen zonale Ausfälle resistent und hat während Wartungsvorgängen längere Ausfallzeiten. Weitere Informationen finden Sie unter Kosten mit einfachen Instanzen reduzieren.

Wenn Sie die CPU- und Arbeitsspeicheranforderungen Ihrer AlloyDB for PostgreSQL-Instanz vorhersagen können, können Sie Geld sparen, weil Sie Rabatte für zugesicherte Nutzung erhalten. Weitere Informationen finden Sie unter Rabatte für zugesicherte Nutzung von AlloyDB for PostgreSQL.

BigQuery Mit BigQuery können Sie die Kosten für Abfragen schätzen, bevor Sie sie ausführen. Zur Optimierung der Abfragekosten müssen Sie die Speicher- und Abfrageberechnung optimieren. Weitere Informationen finden Sie unter Kosten schätzen und kontrollieren.
Cloud Storage Wählen Sie für den Cloud Storage-Bucket, den Sie zum Laden von Daten in das Datenaufnahme-Subsystem verwenden, einen geeigneten Wert aus. Speicherklasse basierend auf den Anforderungen an die Datenaufbewahrung und die Zugriffshäufigkeit Ihrer Arbeitslasten. Sie können beispielsweise die Speicherklasse Standard auswählen und die Verwaltung des Objektlebenszyklus verwenden, um die Speicherkosten durch automatisches Downgrade von Objekten auf eine kostengünstigere Speicherklasse zu steuern oder Objekte basierend auf den von Ihnen festgelegten Bedingungen zu löschen.
Cloud Logging

So können Sie die Kosten für die Speicherung von Logs kontrollieren:

Leistung

In diesem Abschnitt werden die Faktoren beschrieben, die Sie beim Entwerfen und Erstellen einer RAG-fähigen generativen KI-Anwendung in Google Cloud berücksichtigen sollten, die Ihre Leistungsanforderungen erfüllt.

Produkt Designaspekte
Cloud Run Standardmäßig werden jeder Cloud Run-Containerinstanz eine CPU und 512 MiB Arbeitsspeicher zugewiesen. Abhängig von Ihren Leistungsanforderungen für Ihre Cloud Run-Jobs können Sie das CPU-Limit und das Speicherlimit konfigurieren.
AlloyDB for PostgreSQL

Mit AlloyDB for PostgreSQL können Sie die Abfrageleistung der Datenbanken analysieren und verbessern. Mit diesem Tool können Sie die Leistung überwachen und die Quelle einer problematischen Abfrage verfolgen. Weitere Informationen finden Sie in der Übersicht zu Query Insights.

Um einen Überblick über den Status und die Leistung Ihrer Datenbanken zu erhalten und detaillierte Messwerte wie Spitzenverbindungen und maximale Replikationsverzögerung anzuzeigen, verwenden Sie das System Insights-Dashboard. Weitere Informationen finden Sie unter Instanz mit dem AlloyDB for PostgreSQL-Systemstatistik-Dashboard überwachen.

Um die Last auf Ihrer primären AlloyDB for PostgreSQL-Instanz zu reduzieren und die Kapazität für die Verarbeitung von Leseanfragen horizontal zu skalieren, können Sie dem Cluster Lesepoolinstanzen hinzufügen. Weitere Informationen finden Sie unter AllyDB for PostgreSQL-Knoten und -Instanzen.

BigQuery

BigQuery bietet eine Grafik zur Abfrageausführung, mit der Sie die Abfrageleistung analysieren und Leistungsinformationen zu Problemen wie Slot-Konflikten und unzureichenden Shuffle-Kontingenten erhalten können. Weitere Informationen finden Sie unter Statistiken zur Abfrageleistung abrufen.

Nachdem Sie die Probleme behoben haben, die Sie anhand von Statistiken zur Abfrageleistung ermittelt haben, können Sie Abfragen mit Methoden wie der Reduzierung des Volumens der Eingabe- und Ausgabedaten weiter optimieren. Weitere Informationen finden Sie unter Abfrageleistung optimieren.

Cloud Storage Zum Hochladen großer Dateien können Sie eine Mathode namens parallele zusammengesetzte Uploads verwenden. Bei dieser Strategie wird die große Datei in Blöcke unterteilt. Die Blöcke werden parallel in Cloud Storage hochgeladen und dann die Daten in der Cloud neu zusammengesetzt. Parallele zusammengesetzte Uploads können schneller sein als reguläre Uploadvorgänge, wenn Netzwerkbandbreite und Laufwerksgeschwindigkeit keine einschränkenden Faktoren darstellen. Diese Strategie hat jedoch einige Einschränkungen und Auswirkungen auf die Kosten. Weitere Informationen finden Sie unter Parallele zusammengesetzte Uploads.

Bereitstellung

Zum Einstieg in das Erstellen und Experimentieren mit dem Erstellen einer Infrastruktur in Google Cloud für RAG-fähige generative KI-Anwendungen können Sie Schnellstartlösung: Generative KI-RAG mit Cloud SQL verwenden. Diese Lösung stellt eine Python-basierte Chatanwendung in Cloud Run bereit und verwendet eine vollständig verwaltete Cloud SQL-Datenbank für die Vektorsuche. Der Beispielcode für diese Anleitung ist in GitHub verfügbar.

Nächste Schritte

Beitragende

Autor: Kumar Dhanagopal | Cross-product Solution Developer

Weitere Beitragende: