Infrastruktur für eine RAG-fähige generative KI-Anwendung mit GKE und Cloud SQL

Last reviewed 2024-12-11 UTC

In diesem Dokument wird eine Referenzarchitektur vorgestellt, mit der Sie die Infrastruktur für den Betrieb einer generativen KI-Anwendung mit Retrieval Augmented Generation (RAG) unter Verwendung von Google Kubernetes Engine (GKE), Cloud SQL und Open-Source-Tools wie Ray, Hugging Face und LangChain entwickeln können. Damit Sie diese Referenzarchitektur ausprobieren können, werden in GitHub eine Beispielanwendung und eine Terraform-Konfiguration bereitgestellt.

Dieses Dokument richtet sich an Entwickler, die schnell RAG-fähige Anwendungen basierend auf generativer KI erstellen und bereitstellen möchten. Es wird davon ausgegangen, dass Sie Erfahrung mit der Verwendung von GKE und Cloud SQL haben und dass Sie ein konzeptionelles Verständnis von KI, maschinellem Lernen (ML) und Large Language Models (LLMs) haben. 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:

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

Die Architektur umfasst ein Subsystem für die Bereitstellung und ein Subsystem für das Einbetten.

  • Das Subsystem für die Bereitstellung verarbeitet den Anfrage-Antwort-Fluss zwischen der Anwendung und ihren Nutzern. Das Subsystem umfasst einen Frontend-Server, einen Inferenzserver und einen RAI-Dienst (verantwortungsbewusste Anwendung von KI). Das Bereitstellungssubsystem interagiert über eine Vektordatenbank mit dem Einbettungssubsystem.
  • Das Subsystem für Einbettungen ermöglicht die RAG-Funktion in der Architektur. Dieses Subsystem führt Folgendes aus:
    • Nimmt Daten aus Datenquellen in Google Cloud, lokalen und anderen Cloudplattformen auf.
    • Konvertiert die aufgenommenen Daten in Vektoreinbettungen.
    • Speichert die Einbettungen in einer Vektordatenbank.

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.

Wie im vorherigen Diagramm dargestellt, werden der Frontend-Server, der Inferenzserver und der Einbettungsdienst in einem regionalen GKE-Cluster im Autopilot-Modus bereitgestellt. Daten für RAG werden über einen Cloud Storage-Bucket aufgenommen. In der Architektur wird eine Cloud SQL for PostgreSQL-Instanz mit der Erweiterung pgvector als Vektordatenbank verwendet, um Einbettungen zu speichern und semantische Suchvorgänge auszuführen. Vektordatenbanken sind für das effiziente Speichern und Abrufen von hochdimensionalen Vektoren konzipiert.

In den folgenden Abschnitten werden die Komponenten und der Datenfluss in jedem Subsystem der Architektur beschrieben.

Subsystem für Einbettungen

So werden Daten im Einbettungs-Subsystem verarbeitet:

  1. Daten aus externen und internen Quellen werden von Nutzern oder programmatisch in den Cloud Storage-Bucket hochgeladen. Die hochgeladenen Daten können in Dateien, Datenbanken oder Streamingdaten enthalten sein.
  2. (Nicht im Architekturdiagramm dargestellt.) Durch den Daten-Upload wird ein Ereignis ausgelöst, das in einem Nachrichtendienst wie Pub/Sub veröffentlicht wird. Der Messaging-Dienst sendet eine Benachrichtigung an den Einbettungsdienst.
  3. Wenn der Einbettungsdienst eine Benachrichtigung über ein Daten-Upload-Ereignis erhält, führt er die folgenden Schritte aus:
    1. Ruft Daten aus dem Cloud Storage-Bucket über den Cloud Storage FUSE-CSI-Treiber ab.
    2. Die hochgeladenen Daten werden gelesen und mit Ray Data vorverarbeitet. Die Vorverarbeitung kann das Aufteilen der Daten in Blöcke und das Transformieren in ein geeignetes Format für die Generierung von Einbettungen umfassen.
    3. Führt einen Ray-Job aus, um vektorisierte Einbettungen der vorverarbeiteten Daten mithilfe eines Open-Source-Modells wie intfloat/multilingual-e5-small zu erstellen, das auf demselben Cluster bereitgestellt wird.
    4. Schreibt die vektorisierten Einbettungen in die Cloud SQL for PostgreSQL-Vektordatenbank.

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

Im Folgenden wird der Anfrage-Antwort-Ablauf im Bereitstellungs-Subsystem beschrieben:

  1. Ein Nutzer sendet über eine webbasierte Chatoberfläche eine Natural Language-Anfrage an einen Frontend-Server. Der Frontend-Server wird in GKE ausgeführt.
  2. Auf dem Frontend-Server wird ein LangChain-Prozess ausgeführt, der Folgendes ausführt:
    1. Konvertiert die Anfrage in natürlicher Sprache in Einbettungen. Dazu werden dasselbe Modell und dieselben Parameter verwendet, die auch vom Einbettungsdienst genutzt werden.
    2. Ruft relevante Fundierungsdaten ab, indem eine semantische Suche nach den Einbettungen in der Vektordatenbank durchgeführt wird. Mit der semantischen Suche lassen sich Einbettungen anhand der Absicht eines Prompts und nicht anhand ihres Textinhalts finden.
    3. Erstellt einen kontextbezogenen Prompt, indem die ursprüngliche Anfrage mit den abgerufenen Grounding-Daten kombiniert wird.
    4. Sendet den kontextbezogenen Prompt an den Inferenzserver, der in GKE ausgeführt wird.
  3. Der Inferenzserver verwendet das Serving-Framework Hugging Face TGI, um ein Open-Source-LLM wie Mistral-7B-Instruct oder ein offenes Gemma-Modell bereitzustellen.

  4. Das LLM generiert eine Antwort auf die Eingabeaufforderung und der Inferenzserver sendet die Antwort an den Frontend-Server.

    Sie können Logs der Anfrage-Antwort-Aktivität in Cloud Logging speichern und ansehen und logbasiertes Monitoring mit Cloud Monitoring einrichten. Sie können die generierten Antworten auch zur Offlineanalyse in BigQuery laden.

  5. Der Frontend-Server ruft einen RAI-Dienst auf, um die erforderlichen Sicherheitsfilter auf die Antwort anzuwenden. Sie können Tools wie Sensitive Data Protection und die Cloud Natural Language API verwenden, um sensible Inhalte in den Antworten zu erkennen, zu filtern, zu klassifizieren und zu de-identifizieren.

  6. Der Frontend-Server sendet die gefilterte Antwort an den Nutzer.

Verwendete Produkte

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

Google Cloud Produkte

  • Google Kubernetes Engine (GKE): Ein Kubernetes-Dienst, mit dem Sie Containeranwendungen in großem Maßstab mithilfe der Infrastruktur von Google bereitstellen und betreiben können.
  • Cloud Storage: Ein kostengünstiger, unbegrenzter Objektspeicher für verschiedene Datentypen. Auf Daten kann von innerhalb und außerhalb von Google Cloudzugegriffen werden. Sie werden zu Redundanzzwecken über Standorte hinweg repliziert.
  • Cloud SQL: Ein vollständig verwalteter Dienst für relationale Datenbanken, mit dem Sie Ihre MySQL-, PostgreSQL- und SQL Server-Datenbanken auf Google Cloudbereitstellen, betreiben und verwalten können.

Open-Source-Produkte

  • Hugging Face Text Generation Inference (TGI): Ein Toolkit zum Bereitstellen von LLMs.
  • Ray: Ein einheitliches Open-Source-Compute-Framework, mit dem Sie KI- und Python-Arbeitslasten skalieren können.
  • LangChain: Ein Framework zum Entwickeln und Bereitstellen von Anwendungen auf Basis von LLMs.

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.

Designalternativen

In diesem Abschnitt werden alternative Designansätze vorgestellt, die Sie für Ihre RAG-fähige generative KI-Anwendung in Google Cloudin Betracht ziehen können.

Wenn Sie eine Architektur benötigen, die ein vollständig verwaltetes Vektorsuchprodukt verwendet, können Sie Vertex AI und die Vektorsuche verwenden. Diese bieten eine optimierte Bereitstellungsinfrastruktur für die Vektorsuche in sehr großem Maßstab. Weitere Informationen finden Sie unter Infrastruktur für eine RAG-fähige generative KI-Anwendung mit Vertex AI und Vector Search.

Vektorfähige Google Cloud Datenbank

Wenn Sie die Vektorspeicherfunktionen einer vollständig verwalteten Google Cloud -Datenbank wie AlloyDB for PostgreSQL oder Cloud SQL für Ihre RAG-Anwendung nutzen möchten, lesen Sie den Abschnitt Infrastruktur für eine RAG-fähige generative KI-Anwendung mit Vertex AI und AlloyDB for PostgreSQL.

Weitere Optionen

Informationen zu anderen Infrastrukturoptionen, unterstützten Modellen und Grounding-Techniken, die Sie für generative KI-Anwendungen inGoogle Cloudverwenden können, finden Sie unter Modelle und Infrastruktur für Ihre generative KI-Anwendung auswählen.

Designaspekte

Dieser Abschnitt enthält eine Anleitung zum Entwickeln und Ausführen einer in GKE gehosteten RAG-fähigen generativen KI-Architektur, 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 Anwendung und der von Ihnen verwendeten Google Cloud -Produkte und ‑Features müssen Sie möglicherweise zusätzliche Designfaktoren und Kompromisse berücksichtigen.

Designanleitungen zu den Open-Source-Tools in dieser Referenzarchitektur, z. B. Hugging Face TGI, finden Sie in der Dokumentation für diese Tools.

Sicherheit, Datenschutz 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-, Datenschutz- und Compliance-Anforderungen erfüllt.

Produkt Designaspekte
GKE

Im Autopilot-Betriebsmodus konfiguriert GKE Ihren Cluster vor und verwaltet Knoten gemäß den Best Practices für Sicherheit. So können Sie sich auf die arbeitslastspezifische Sicherheit konzentrieren. Hier finden Sie weitere Informationen:

Mit Identity-Aware Proxy (IAP) können Sie den Zugriff auf Ihre in GKE ausgeführten Anwendungen besser steuern. IAP wird in die GKE-Ingress-Ressource eingebunden und sorgt dafür, dass nur authentifizierte Nutzer mit der richtigen IAM-Rolle (Identity and Access Management) auf die Anwendungen zugreifen können. Weitere Informationen finden Sie unter IAP für GKE aktivieren.

Standardmäßig werden Ihre Daten in GKE mit Google-owned and Google-managed encryption keys im Ruhezustand und bei der Übertragung verschlüsselt. Als zusätzliche Sicherheitsebene für sensible Daten können Sie Daten auf der Anwendungsebene mit einem Schlüssel verschlüsseln, der Ihnen gehört und den Sie mit Cloud KMS verwalten. Weitere Informationen finden Sie unter Secrets auf Anwendungsebene verschlüsseln.

Wenn Sie einen GKE Standard-Cluster verwenden, können Sie die folgenden zusätzlichen Funktionen zur Datenverschlüsselung nutzen:

Cloud SQL

Die Cloud SQL-Instanz in der Architektur muss nicht über das öffentliche Internet zugänglich sein. Wenn ein externer Zugriff auf die Cloud SQL-Instanz erforderlich ist, können Sie externe Verbindungen mit SSL/TLS oder dem Cloud SQL Auth-Proxy-Connector verschlüsseln. Der Auth-Proxy-Connector bietet eine Verbindungsautorisierung über IAM. Der Connector 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. Verwenden Sie für Verbindungen, die mit Java, Python, Go oder Node.js erstellt wurden, den entsprechenden Sprach-Connector anstelle des Auth-Proxy-Connectors.

Standardmäßig verwendet Cloud SQL von Google verwaltete Datenverschlüsselungsschlüssel (Data Encryption Keys, DEKs) und Schlüsselverschlüsselungsschlüssel (Key Encryption Keys, KEKs), um inaktive Daten zu verschlüsseln. Wenn Sie KEKs verwenden müssen, die Sie selbst steuern und verwalten, können Sie vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEKs) verwenden.

Um unautorisierten Zugriff auf die Cloud SQL Admin API zu verhindern, können Sie mit VPC Service Controls einen Dienstperimeter erstellen.

Informationen zum Konfigurieren von Cloud SQL zur Erfüllung der Anforderungen an den Datenstandort finden Sie unter Übersicht zum Datenstandort.

Cloud Storage

Standardmäßig werden die in Cloud Storage gespeicherten Daten mit Google-owned and Google-managed encryption keysverschlü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 die Nutzerberechtigung zum Zugriff auf Ihre Buckets und Objekte zu steuern: 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.

Sie können mit VPC Service Controls einen Dienstperimeter erstellen, um das Risiko einer Daten-Exfiltration aus Cloud Storage zu verringern.

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

Alle Produkte in dieser Architektur

Audit-Logs zur Administratoraktivität sind standardmäßig für alle Google Cloud -Dienste aktiviert, die in dieser Referenzarchitektur verwendet werden. Sie können über Cloud Logging auf die Logs zugreifen und sie verwenden, um API-Aufrufe oder andere Aktionen zu überwachen, die die Konfiguration oder Metadaten von Google Cloud Ressourcen ändern.

Audit-Logs zum Datenzugriff sind standardmäßig für alle Google Cloud -Dienste in dieser Architektur aktiviert. Mit diesen Logs können Sie Folgendes überwachen:

  • API-Aufrufe, die die Konfiguration oder Metadaten von Ressourcen lesen.
  • Nutzeranfragen zum Erstellen, Ändern oder Lesen der von Nutzern bereitgestellten Ressourcendaten.

Sicherheitsgrundsätze und ‑empfehlungen speziell für KI- und ML-Arbeitslasten finden Sie im Well-Architected Framework unter KI- und ML-Perspektive: Sicherheit.

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 inGoogle Cloudberücksichtigen sollten.

Produkt Designaspekte
GKE

Im Autopilot-Betriebsmodus, der in dieser Architektur verwendet wird, bietet GKE die folgenden integrierten Zuverlässigkeitsfunktionen:

  • Ihre Arbeitslast verwendet einen regionalen GKE-Cluster. Die Steuerungsebene und die Worker-Knoten werden auf drei verschiedene Zonen innerhalb einer Region verteilt. Ihre Arbeitslasten sind gegen Zonenausfälle resistent. Regionale GKE-Cluster haben eine höhere SLA als zonale Cluster.
  • Sie müssen keine Knoten erstellen oder Knotenpools verwalten. GKE erstellt die Knotenpools automatisch und skaliert sie automatisch entsprechend den Anforderungen Ihrer Arbeitslasten.

Damit genügend GPU-Kapazität verfügbar ist, wenn dies für das Autoscaling des GKE-Cluster erforderlich ist, können Sie Reservierungen erstellen und verwenden. Eine Reservierung bietet zugesicherte Kapazität in einer bestimmten Zone für eine bestimmte Ressource. Eine Reservierung kann für ein Projekt spezifisch sein oder für mehrere Projekte freigegeben sein. Für reservierte Ressourcen fallen auch dann Gebühren an, wenn die Ressourcen nicht bereitgestellt oder verwendet werden. Weitere Informationen finden Sie unter Reservierte zonale Ressourcen nutzen.

Cloud SQL

Damit die Vektordatenbank vor Datenbankfehlern und Zonen-Ausfällen geschützt ist, verwenden Sie eine für Hochverfügbarkeit konfigurierte Cloud SQL-Instanz. Bei einem Ausfall der primären Datenbank oder einem Zonenausfall führt Cloud SQL automatisch ein Failover auf die Standby-Datenbank in einer anderen Zone aus. Sie müssen die IP-Adresse für den Datenbankendpunkt nicht ändern.

Damit Ihre Cloud SQL-Instanzen vom SLA abgedeckt sind, sollten Sie die empfohlenen Betriebsrichtlinien einhalten. Achten Sie beispielsweise darauf, dass CPU und Arbeitsspeicher für die Arbeitslast richtig dimensioniert sind, und aktivieren Sie automatische Speichererhöhungen. Weitere Informationen finden Sie unter Betriebsrichtlinien.

Cloud Storage Sie können Cloud Storage-Buckets an einem von drei Standorttypen erstellen: regional, biregional oder multiregional. Daten, die in regionalen Buckets gespeichert sind, werden synchron über mehrere Zonen innerhalb einer Region hinweg 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.

Zuverlässigkeitsprinzipien und ‑empfehlungen speziell für KI- und ML-Arbeitslasten finden Sie im Well-Architected Framework unter KI- und ML-Perspektive: Zuverlässigkeit.

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
GKE

Im Autopilot-Modus optimiert GKE die Effizienz der Infrastruktur Ihres Clusters basierend auf den Anforderungen der Arbeitslast. Sie müssen die Ressourcennutzung nicht ständig überwachen oder die Kapazität verwalten, um die Kosten zu kontrollieren.

Wenn Sie die CPU-, Arbeitsspeicher- und sitzungsspezifische Speichernutzung Ihres GKE Autopilot-Clusters 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 GKE.

Um die Kosten für die Ausführung Ihrer Anwendung zu senken, können Sie Spot-VMs für Ihre GKE-Knoten verwenden. Spot-VMs sind günstiger als Standard-VMs, bieten aber keine Verfügbarkeitsgarantie. Informationen zu den Vorteilen von Knoten, die Spot-VMs verwenden, wie sie in GKE funktionieren und wie Sie Arbeitslasten auf solchen Knoten planen, finden Sie unter Spot-VMs.

Weitere Informationen zur Kostenoptimierung finden Sie unter Best Practices zum Ausführen kostenoptimierter Kubernetes-Anwendungen in GKE.

Cloud SQL

Eine Hochverfügbarkeitskonfiguration (HA) trägt dazu bei, Ausfallzeiten für Ihre Cloud SQL-Datenbank zu reduzieren, wenn die Zone oder Instanz nicht mehr verfügbar ist. Die Kosten einer für hohe Verfügbarkeit konfigurierten Instanz sind jedoch höher als die einer eigenständigen Instanz. Wenn Sie keine Hochverfügbarkeit für die Vektordatenbank benötigen, können Sie die Kosten senken, indem Sie eine eigenständige Instanz verwenden, die nicht gegen Zonenausfälle geschützt ist.

Mit den von Active Assist unterstützten Cloud SQL-Kosteninformationen und -Empfehlungen können Sie erkennen, ob Ihre Cloud SQL-Instanz überdimensioniert ist, und die Abrechnung optimieren. Weitere Informationen finden Sie unter Überdimensionierte Cloud SQL-Instanzen reduzieren.

Wenn Sie die CPU- und Arbeitsspeicheranforderungen Ihrer Cloud SQL-Instanz 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 SQL.

Cloud Storage Wählen Sie für den Cloud Storage-Bucket, den Sie zum Laden von Daten in das Datenaufnahme-Subsystem verwenden, eine geeignete Speicherklasse aus. Berücksichtigen Sie bei der Auswahl der Speicherklasse die Anforderungen an die Datenaufbewahrung und die Zugriffshäufigkeit Ihrer Arbeitslasten. Um beispielsweise die Speicherkosten zu senken, können Sie die Klasse „Standard“ auswählen und die Verwaltung des Objektlebenszyklus verwenden. So können Sie Objekte automatisch auf eine kostengünstigere Speicherklasse herabstufen oder Objekte basierend auf den von Ihnen festgelegten Bedingungen löschen.

Mit dem Google Cloud Preisrechner können Sie die Kosten für Ihre Google Cloud -Ressourcen schätzen.

Kostenoptimierungsgrundsätze und ‑empfehlungen speziell für KI- und ML-Arbeitslasten finden Sie im Well-Architected Framework unter KI- und ML-Perspektive: Kostenoptimierung.

Leistungsoptimierung

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
GKE Wählen Sie basierend auf den Leistungsanforderungen der Arbeitslasten geeignete Compute-Klassen für Ihre Pods aus. Für die Pods, in denen der Inferenzserver und der Einbettungsdienst ausgeführt werden, empfehlen wir die Verwendung eines GPU-Maschinentyps wie nvidia-l4.
Cloud SQL

Um die Leistung Ihrer Cloud SQL-Instanz zu optimieren, müssen Sie dafür sorgen, dass die der Instanz zugewiesene CPU und der Arbeitsspeicher für die Arbeitslast ausreichen. Weitere Informationen finden Sie unter Unterdimensionierte Cloud SQL-Instanzen optimieren.

Verwenden Sie den Index Inverted File with Flat Compression (IVFFlat) oder den Index Hierarchical Navigable Small World (HNSW), um die Reaktionszeit für die ANN-Vektorsuche (Approximate Nearest Neighbour) zu verbessern.

Mit Cloud SQL 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 unter Abfragestatistiken verwenden, um die Abfrageleistung zu verbessern.

Um einen Überblick über den Status und die Leistung Ihrer Datenbanken zu erhalten und detaillierte Messwerte wie Spitzenverbindungen und maximale Laufwerkauslastung anzuzeigen, verwenden Sie das System Insights-Dashboard. Weitere Informationen finden Sie unter Systemstatistiken zur Verbesserung der Systemleistung verwenden.

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. Wenn Netzwerkbandbreite und Laufwerksgeschwindigkeit keine einschränkenden Faktoren darstellen, können parallele zusammengesetzte Uploads schneller sein als reguläre Uploadvorgänge. Diese Strategie hat jedoch einige Einschränkungen und Auswirkungen auf die Kosten. Weitere Informationen finden Sie unter Parallele zusammengesetzte Uploads.

Grundsätze und Empfehlungen zur Leistungsoptimierung, die speziell auf KI- und ML-Arbeitslasten zugeschnitten sind, finden Sie im Well-Architected Framework unter KI- und ML-Perspektive: Leistungsoptimierung.

Bereitstellung

Wenn Sie eine Topologie bereitstellen möchten, die auf dieser Referenzarchitektur basiert, können Sie den Open-Source-Beispielcode herunterladen und verwenden, der in einem Repository auf GitHub verfügbar ist. Der Beispielcode ist nicht für Produktionsanwendungsfälle vorgesehen. Mit dem Code können Sie die Einrichtung einer KI-Infrastruktur für eine RAG-fähige generative KI-Anwendung testen.

Dieser Beispielcode tut Folgendes:

  1. Stellt eine Cloud SQL for PostgreSQL-Instanz als Vektordatenbank bereit.
  2. Stellt Ray, JupyterHub und Hugging Face TGI in einem von Ihnen angegebenen GKE-Cluster bereit.
  3. Stellt eine webbasierte Chatbot-Beispielanwendung in Ihrem GKE-Cluster bereit, damit Sie die RAG-Funktion prüfen können.

Eine Anleitung zur Verwendung des Beispielcodes finden Sie in der README-Datei für den Code. Wenn bei der Verwendung des Beispielcodes Fehler auftreten und es für diese Fehler keine offenen GitHub-Probleme gibt, erstellen Sie Probleme in GitHub.

Im Beispielcode werden abrechenbare Google Cloud Ressourcen bereitgestellt. Wenn Sie den Code nicht mehr verwenden, entfernen Sie alle Ressourcen, die Sie nicht mehr benötigen.

Nächste Schritte

Beitragende

Autor: Kumar Dhanagopal | Cross-product Solution Developer

Weitere Beitragende: