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

Dieses Dokument enthält eine Referenzarchitektur, mit der Sie die Infrastruktur für die Ausführung einer auf generativer KI basierenden Anwendung mit Retrieval-augmented Generation (RAG) mithilfe von Google Kubernetes Engine (GKE), Cloud SQL und Open-Source-Tools wie Ray, Hugging Face und LangChain entwerfen können. Eine Beispielanwendung und eine Terraform-Konfiguration stehen in GitHub zur Verfügung, um Sie beim Experimentieren mit dieser Referenzarchitektur zu unterstützen.

Dieses Dokument richtet sich an Entwickler, die RAG-fähige Generative AI-Anwendungen mithilfe von Open-Source-Tools und -Modellen schnell erstellen und bereitstellen möchten. Dabei wird davon ausgegangen, dass Sie Erfahrung mit GKE und Cloud SQL und 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 AI-Anwendung in Google Cloud:

Allgemeine Architektur für eine RAG-fähige Generative-AI-Anwendung in Google Cloud.

Die Architektur umfasst ein Bereitstellungssubsystem und ein Einbettungssubsystem.

  • Das Bereitstellungssubsystem steuert den Anfrage-Antwort-Fluss zwischen der Anwendung und ihren Nutzern. Das Subsystem umfasst einen Frontend-Server, einen Inferenzserver und einen RAI-Dienst (Responsible AI). Das Bereitstellungssubsystem interagiert über eine Vektordatenbank mit dem Einbettungssubsystem.
  • Das eingebettete Subsystem aktiviert die RAG-Funktion in der Architektur. Dieses Subsystem übernimmt Folgendes:
    • Nimmt Daten aus Datenquellen in Google Cloud, lokalen Systemen und anderen Cloud-Plattformen 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 AI-Anwendung in Google Cloud.

Wie im vorherigen Diagramm gezeigt, werden der Front-End-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. Die Architektur verwendet eine Cloud SQL for PostgreSQL-Instanz mit der Erweiterung pgvector als Vektordatenbank, um Einbettungen zu speichern und semantische Suchen durchzuführen. Vektordatenbanken wurden entwickelt, um hochdimensionale Vektoren effizient zu speichern und abzurufen.

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

Einbettungssubsystem

So sieht der Datenfluss im Einbettungssubsystem aus:

  1. Daten aus externen und internen Quellen werden von Nutzern oder programmatisch in den Cloud Storage-Bucket hochgeladen. Die hochgeladenen Daten können sich in Dateien, Datenbanken oder gestreamten Daten befinden.
  2. (Nicht im Architekturdiagramm dargestellt.) Die Datenuploadaktivität löst ein Ereignis aus, das in einem Messaging-Dienst wie Pub/Sub veröffentlicht wird. Der Messaging-Dienst sendet eine Benachrichtigung an den Einbettungsdienst.
  3. Wenn der Einbettungsdienst eine Benachrichtigung über ein Datenuploadereignis erhält, geht er so vor:
    1. Ruft Daten aus dem Cloud Storage-Bucket über den CSI-Treiber für Cloud Storage FUSE ab.
    2. Die hochgeladenen Daten lesen und mit Ray Data vorverarbeiten Bei der Vorverarbeitung können die Daten aufgeteilt und in ein geeignetes Format für das Generieren von Einbettungen umgewandelt werden.
    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 im selben Cluster bereitgestellt wird.
    4. Die vektorisierten Einbettungen werden in die Vektordatenbank von Cloud SQL for PostgreSQL geschrieben.

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 sehen Sie den Anfrage-Antwort-Ablauf im Bereitstellungssubsystem:

  1. Ein Nutzer sendet über eine webbasierte Chatoberfläche eine Anfrage in natürlicher Sprache an einen Front-End-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, indem dasselbe Modell und dieselben Parameter wie der Einbettungsdienst verwendet 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 Fundierungsdaten kombiniert wird.
    4. Sendet die kontextbezogene Aufforderung an den Inferenzserver, der in GKE ausgeführt wird.
  3. Der Inferenzserver verwendet das Bereitstellungs-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 aufrufen und mithilfe von Cloud Monitoring logbasiertes Monitoring einrichten. Sie können die generierten Antworten auch zur Offlineanalyse in BigQuery laden.

  5. Der Front-End-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 ermitteln, zu filtern, zu klassifizieren und zu de-identifizieren.

  6. Der Front-End-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 Google-Infrastruktur 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 aus Gründen der Redundanz standortübergreifend repliziert.
  • Cloud SQL: Ein vollständig verwalteter relationaler Datenbankdienst, mit dem Sie Ihre MySQL-, PostgreSQL- und SQL Server-Datenbanken auf Google Cloudbereitstellen, betreiben und verwalten können.

Open-Source-Produkte

Anwendungsfälle

RAG ist eine effektive Technik, um die Qualität der Ausgabe zu verbessern, die von einem LLM generiert wird. 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 AI-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 Vector Search verwenden. Diese bieten eine optimierte Bereitstellungsinfrastruktur für sehr umfangreiche Vektorsuche. Weitere Informationen finden Sie unter Infrastruktur für eine RAG-fähige Generative AI-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 Infrastruktur für eine RAG-fähige Generative AI-Anwendung mit Vertex AI und AlloyDB for PostgreSQL.

Weitere Optionen

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

Designaspekte

Dieser Abschnitt enthält Anleitungen zum Entwickeln und Ausführen einer 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. Je nach den spezifischen Anforderungen Ihrer Anwendung und den von Ihnen verwendeten Google Cloud Produkten und Funktionen müssen Sie möglicherweise zusätzliche Designfaktoren und Kompromisse berücksichtigen.

Anleitungen zum Design für die Open-Source-Tools in dieser Referenzarchitektur wie Hugging Face TGI finden Sie in der Dokumentation zu diesen 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 Ihren Sicherheits-, Datenschutz- und Compliance-Anforderungen entspricht.

Produkt Designaspekte
GKE

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

Für eine erweiterte Zugriffssteuerung für Ihre in GKE ausgeführten Anwendungen können Sie Identity-Aware Proxy (IAP) verwenden. IAP lässt sich in die GKE Ingress-Ressource einbinden 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 für ruhende Daten und bei der Übertragung mit Google-owned and Google-managed encryption keysverschlüsselt. Als zusätzliche Sicherheitsebene für sensible Daten können Sie Daten auf Anwendungsebene verschlüsseln. Dazu verwenden Sie einen Schlüssel, der Ihnen gehört und mit Cloud KMS verwaltet wird. Weitere Informationen finden Sie unter Secrets auf Anwendungsebene verschlüsseln.

Wenn Sie einen GKE-Standardcluster verwenden, können Sie die folgenden zusätzlichen Datenverschlüsselungsfunktionen verwenden:

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 ermöglicht die Verbindungautorisierung mithilfe von 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 Google-eigene und von Google verwaltete Datenverschlüsselungsschlüssel (Data Encryption Keys, DEKs) und Schlüsselverschlüsselungsschlüssel (Key Encryption Keys, KEKs), um ruhende Daten zu verschlüsseln. Wenn Sie KEKs verwenden müssen, die Sie steuern und verwalten, können Sie vom Kunden verwaltete Verschlüsselungsschlüssel (CMEKs) verwenden.

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

Informationen zum Konfigurieren von Cloud SQL für die Erfüllung der Anforderungen an den Datenstandort finden Sie unter Datenstandortübersicht.

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 mithilfe von VPC Service Controls einen Dienstperimeter erstellen, um das Risiko der 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 zu Administratoraktivitäten 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 beobachten, die die Konfiguration oder Metadaten von Google Cloud Ressourcen ändern.

Außerdem sind standardmäßig Audit-Logs zum Datenzugriff 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, die speziell für KI- und ML-Arbeitslasten gelten, finden Sie im Well-Architected Framework unter AI and MLperspektive: Sicherheit.

Zuverlässigkeit

In diesem Abschnitt werden Designfaktoren beschrieben, die Sie berücksichtigen sollten, um eine zuverlässige Infrastruktur für eine RAG-fähige Generative AI-Anwendung inGoogle Cloudzu erstellen und zu betreiben.

Produkt Designaspekte
GKE

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

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

Damit bei Bedarf für das Autoscaling des GKE-Clusters genügend GPU-Kapazität zur Verfügung steht, können Sie Reservierungen erstellen und verwenden. Eine Reservierung bietet garantierte Kapazität in einer bestimmten Zone für eine angegebene 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

Verwenden Sie eine für Hochverfügbarkeit konfigurierte Cloud SQL-Instanz, damit die Vektordatenbank Datenbankfehler und Zonenausfälle bewältigt. Bei einem Ausfall der primären Datenbank oder der Zone wird für Cloud SQL automatisch ein Failover auf die Stand-by-Datenbank in einer anderen Zone durchgeführt. Sie müssen die IP-Adresse für den Datenbankendpunkt nicht ändern.

Beachten Sie die empfohlenen Betriebsrichtlinien, damit Ihre Cloud SQL-Instanzen durch das SLA abgedeckt sind. Achten Sie beispielsweise darauf, dass CPU und Arbeitsspeicher die richtige Größe für die Arbeitslast haben, und aktivieren Sie automatische Speichererweiterungen. 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.

Informationen zu Zuverlässigkeitsprinzipien und Empfehlungen, die speziell für KI- und ML-Arbeitslasten gelten, finden Sie im Well-Architected Framework unter AI and MLPerspective: Reliability.

Kostenoptimierung

Dieser Abschnitt enthält Informationen zur Kostenoptimierung 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 Clusterinfrastruktur anhand der Arbeitslastanforderungen. Sie müssen weder die Ressourcennutzung ständig überwachen noch die Kapazität verwalten, um die Kosten zu kontrollieren.

Wenn Sie die Nutzung von CPU, Arbeitsspeicher und sitzungsspezifischem Speicher Ihres GKE Autopilot-Clusters vorhersagen können, können Sie durch Rabatte für zugesicherte Nutzung Geld sparen. Weitere Informationen finden Sie unter GKE-Rabatte für zugesicherte Nutzung.

Sie können Spot-VMs für Ihre GKE-Knoten verwenden, um die Kosten für die Ausführung Ihrer Anwendung zu senken. Spot-VMs kosten niedrigere Preise als Standard-VMs, bieten aber keine Garantie für die Verfügbarkeit. 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

Mit einer Hochverfügbarkeitskonfiguration können Sie die Ausfallzeit Ihrer Cloud SQL-Datenbank reduzieren, wenn die Zone oder Instanz nicht mehr verfügbar ist. Die Kosten einer für Hochverfü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 gegen Zonenausfälle nicht robust ist.

Mithilfe der Cloud SQL-Kosteninformationen und -Empfehlungen von Active Assist 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 Cloud SQL-Rabatte für zugesicherte Nutzung.

Cloud Storage Wählen Sie für den Cloud Storage-Bucket, mit dem Sie Daten in das Subsystem der Datenaufnahme laden, eine geeignete Speicherklasse aus. Berücksichtigen Sie bei der Auswahl der Speicherklasse die Anforderungen Ihrer Arbeitslasten an die Datenaufbewahrung und die Zugriffshäufigkeit. Zur Kontrolle der Speicherkosten können Sie beispielsweise die Standardklasse auswählen und die Verwaltung des Objektlebenszyklus verwenden. Dadurch wird das automatische Downgrade von Objekten auf eine kostengünstigere Speicherklasse oder das Löschen von Objekten basierend auf von Ihnen festgelegten Bedingungen ermöglicht.

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

Prinzipien und Empfehlungen zur Kostenoptimierung, die speziell für KI- und ML-Arbeitslasten gelten, 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 Ihren Leistungsanforderungen entspricht.

Produkt Designaspekte
GKE Wählen Sie je nach den Leistungsanforderungen der Arbeitslasten geeignete Computing-Klassen für Ihre Pods aus. Für die Pods, die den Inferenzserver und den Einbettungsdienst ausführen, empfehlen wir die Verwendung eines GPU-Maschinentyps wie nvidia-l4.
Cloud SQL

Sorgen Sie zum Optimieren der Leistung Ihrer Cloud SQL-Instanz dafür, dass die der Instanz zugewiesene CPU und der Arbeitsspeicher für die Arbeitslast ausreichen. Weitere Informationen finden Sie unter Zu wenig bereitgestellte 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.

Zum Analysieren und Verbessern der Abfrageleistung der Datenbanken bietet Cloud SQL ein Query Insights-Tool. Mit diesem Tool können Sie die Leistung überwachen und die Quelle einer problematischen Abfrage verfolgen. Weitere Informationen finden Sie unter Mit Abfragestatistiken die Abfrageleistung 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 Faktoren sind, 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.

Prinzipien und Empfehlungen zur Leistungsoptimierung, die speziell für KI- und ML-Arbeitslasten gelten, finden Sie im Well-Architected Framework unter KI- und ML-Perspektive: Leistungsoptimierung.

Bereitstellung

Sie können den Open-Source-Beispielcode aus einem Repository in GitHub herunterladen und verwenden, um eine Topologie bereitzustellen, die auf dieser Referenzarchitektur basiert. Der Beispielcode ist nicht für Anwendungsfälle in der Produktion vorgesehen. Sie können den Code verwenden, um die Einrichtung einer KI-Infrastruktur für eine RAG-fähige Generative AI-Anwendung zu testen.

Dieser Beispielcode tut Folgendes:

  1. Stellt eine Cloud SQL for PostgreSQL-Instanz bereit, die als Vektordatenbank dient.
  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 zum Verwenden des Beispielcodes finden Sie in der README-Datei. Wenn bei der Verwendung des Beispielcodes Fehler auftreten und offene GitHub-Probleme nicht vorhanden sind, erstellen Sie die entsprechenden Probleme in GitHub.

Mit dem Beispielcode werden kostenpflichtige 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: