Infrastruttura per un'applicazione di IA generativa compatibile con RAG che utilizza Vertex AI

Last reviewed 2024-06-07 UTC

Questo documento fornisce un'architettura di riferimento che puoi utilizzare per progettare per eseguire un'applicazione di intelligenza artificiale generativa (AI) con RAG (Retrieval-Augmented Generation). Il pubblico di destinazione di questo documento include sviluppatori e amministratori delle applicazioni di AI generativa e dei cloud architect. Il documento presuppone che venga utilizzata una comprensione di AI, machine learning (ML) e modello linguistico di grandi dimensioni (LLM) concetti. Questo documento non fornisce indicazioni su come progettare e sviluppare un'applicazione di AI generativa.

Architettura

Il seguente diagramma mostra una visione generale di un'architettura per Applicazione di AI generativa compatibile con RAG in Google Cloud:

Un'architettura di alto livello per un'applicazione di AI generativa compatibile con RAG in Google Cloud.

L'architettura contiene i seguenti componenti interconnessi:

Componente Finalità Interazioni
Sottosistema di importazione dati prepara ed elabora i dati esterni utilizzati per abilitare RAG funzionalità. Il sottosistema di importazione dati interagisce con gli altri sottosistemi dell'architettura a livello di database.
Sottosistema di pubblicazione Gestire il flusso di richiesta-risposta tra l'AI generativa dell'applicazione e dei relativi utenti. Il sottosistema di gestione interagisce con il sottosistema di importazione dati attraverso il livello del database.
Sottosistema di valutazione della qualità Valutare la qualità delle risposte che il sottosistema di pubblicazione generato. Il sottosistema di valutazione della qualità interagisce con il sottosistema di pubblicazione direttamente e con il sottosistema di importazione dati tramite il database livello di sicurezza.
Database Archivia i seguenti dati:
  • Prompt
  • Incorporamenti vettoriali dei dati utilizzati per RAG
  • Configurazione dei job serverless nell'importazione dei dati e sottosistemi di valutazione della qualità
Tutti i sottosistemi dell'architettura interagiscono con i database.

Il seguente diagramma mostra una vista dettagliata dell'architettura:

Un'architettura dettagliata per un'applicazione di AI generativa compatibile con RAG in Google Cloud.

Le seguenti sezioni forniscono descrizioni dettagliate dei componenti e dei dati flusso all'interno di ogni sottosistema dell'architettura.

Sottosistema di importazione dati

Il sottosistema di importazione dati importa i dati da origini esterne come file, database e servizi di flussi di dati. I dati caricati includono prompt per la valutazione della qualità. Il sottosistema di importazione dati fornisce la funzionalità RAG l'architettura. Il seguente diagramma mostra i dettagli dell'importazione dati dell'architettura:

Il sottosistema di importazione dati per un'applicazione di AI generativa compatibile con RAG in Google Cloud.

Di seguito sono riportati i passaggi del flusso di importazione dati:

  1. I dati sono caricati su un bucket Cloud Storage. L'origine dati potrebbe essere un utente di un'applicazione che esegue un caricamento, un'importazione di database o flussi e i dati di Google Cloud.
  2. Quando i dati vengono caricati, viene inviata una notifica a un argomento Pub/Sub.
  3. Pub/Sub attiva un job Cloud Run per elaborare per i dati caricati.
  4. Cloud Run avvia il job utilizzando i dati di configurazione archiviato in un database AlloyDB per PostgreSQL.
  5. Il job Cloud Run utilizza Document AI per prepararsi i dati per un'ulteriore elaborazione. Ad esempio, la preparazione può includere analizzare i dati, convertirli nel formato richiesto e dividere i dati in blocchi.

  6. Il job Cloud Run utilizza Vertex AI Incorporamenti per la creazione del modello di testo incorporamenti vettoriali dei dati importati.

  7. Cloud Run archivia gli incorporamenti in un Database AlloyDB per PostgreSQL che include pgvector attivata. Come descritto nella sezione seguente, quando che elabora le richieste dell'utente, utilizza gli incorporamenti nel vettore per recuperare dati specifici del dominio pertinenti.

Sottosistema di pubblicazione

Il sottosistema di pubblicazione gestisce il flusso di richiesta-risposta tra l'ambiente di AI generativa e dei suoi utenti. Il seguente diagramma mostra i dettagli della pubblicazione dell'architettura:

Il sottosistema di gestione per un'applicazione di AI generativa compatibile con RAG in Google Cloud.

Di seguito sono riportati i passaggi nel flusso richiesta-risposta nella sottosistema:

  1. Gli utenti inviano richieste all'applicazione di AI generativa tramite un frontend (ad esempio, un chatbot o un'app mobile).

  2. L'applicazione di AI generativa converte la richiesta in linguaggio naturale incorporamenti.

  3. L'applicazione completa la parte di recupero dell'approccio RAG:

    1. L'applicazione esegue una ricerca semantica dell'incorporamento Archivio vettoriale di AlloyDB per PostgreSQL gestito dai dati di importazione. La ricerca semantica aiuta a trovare gli incorporamenti in base alla l'intento di un prompt piuttosto che il suo contenuto testuale.
    2. L'applicazione combina la richiesta originale con i dati non elaborati recuperate in base all'incorporamento corrispondente per creare un modello .

  4. L'applicazione invia il prompt contestualizzato a un'inferenza LLM e lo stack che viene eseguito su Vertex AI.

  5. Lo stack di inferenza LLM utilizza un LLM di IA generativa, che può essere un LLM di base o un LLM personalizzato e genera una risposta vincolata al contesto fornito.

    1. L'applicazione può archiviare i log dell'attività richiesta-risposta in Cloud Logging. Puoi visualizzare e utilizzare i log per il monitoraggio utilizzando e configurazione in Cloud Monitoring. Google non accede ai dati dei log e non li utilizza.
    2. L'applicazione carica le risposte a BigQuery per analisi offline.

  6. L'applicazione filtra le risposte filtri per l'IA responsabile.

  7. L'applicazione invia le risposte filtrate agli utenti tramite il frontend.

Sottosistema di valutazione della qualità

Il seguente diagramma mostra i dettagli del sottosistema di valutazione della qualità in dell'architettura:

Il sottosistema di valutazione della qualità per un'applicazione di AI generativa compatibile con RAG in Google Cloud.

Quando il sottosistema di valutazione della qualità riceve una richiesta, procede nel seguente modo:

  1. Pub/Sub attiva un job Cloud Run.
  2. Cloud Run avvia il job utilizzando i dati di configurazione archiviato in un database AlloyDB per PostgreSQL.
  3. Il job Cloud Run estrae i prompt di valutazione da un AlloyDB per PostgreSQL. I prompt sono stati caricati in precedenza dal sottosistema di importazione dati.

  4. Il job Cloud Run utilizza i prompt di valutazione per valutare la qualità delle risposte generate dal sottosistema di pubblicazione.

    L'output di questa valutazione è costituito dai punteggi di valutazione per le metriche come l'accuratezza e la pertinenza dei fatti.

  5. Cloud Run carica i punteggi di valutazione e i prompt e risposte valutate in BigQuery per il futuro e analisi.

Prodotti utilizzati

Di seguito è riportato un riepilogo di tutti i prodotti Google Cloud dell'architettura precedente usa:

  • Vertex AI: una piattaforma di ML che consente di addestrare ed eseguire il deployment di modelli ML applicazioni di IA e AI, nonché personalizzare gli LLM per l'utilizzo nelle applicazioni basate sull'AI.
  • Cloud Run: una piattaforma di serverless computing che ti consente di eseguire i container direttamente sull'infrastruttura scalabile di Google.
  • BigQuery: un data warehouse aziendale che ti aiuta a gestire e analizzare i dati con funzionalità integrate come il machine learning geospaziale analisi e business intelligence.
  • Cloud Storage: un archivio di oggetti economico e senza limiti per diversi tipi di dati. I dati sono accessibili dall'interno e dall'esterno di Google Cloud replicati in più località per la ridondanza.
  • AlloyDB per PostgreSQL: un servizio di database completamente gestito e compatibile con PostgreSQL progettato per i carichi di lavoro più impegnativi, inclusi i carichi ibridi elaborazione transazionale e analitica.
  • Document AI: una piattaforma di elaborazione di documenti che sfrutta dati non strutturati da documenti e li trasformano in dati strutturati.
  • Pub/Sub: un servizio di messaggistica asincrono e scalabile che disaccoppia i servizi che producono messaggi dai servizi che li elaborano messaggi.
  • Cloud Logging: un sistema di gestione dei log in tempo reale con archiviazione, ricerca, analisi e avvisi.
  • Cloud Monitoring: un servizio che offre visibilità le prestazioni, la disponibilità e l'integrità delle tue applicazioni e dell'infrastruttura.

Casi d'uso

RAG è una tecnica efficace per migliorare la qualità dell'output, generati da un LLM. Questa sezione fornisce esempi di casi d'uso per i quali possono utilizzare applicazioni di AI generativa compatibili con RAG.

Suggerimenti personalizzati sui prodotti

Un sito di shopping online potrebbe utilizzare un chatbot basato su LLM per assistere i clienti per la ricerca di prodotti o l'assistenza per gli acquisti. Le domande di un l'utente può essere incrementato utilizzando dati storici relativi al suo comportamento di acquisto e i modelli di interazione con il sito web. I dati potrebbero includere recensioni degli utenti e Feedback archiviato in un datastore non strutturato o in metriche relative alla ricerca in un data warehouse di analisi dei dati web. La domanda aumentata può essere poi elaborato dall'LLM per generare risposte personalizzate che l'utente potrebbero trovare più interessanti e convincenti.

Sistemi di assistenza clinica

I medici negli ospedali devono analizzare e diagnosticare rapidamente la salute di un paziente patologia per prendere decisioni relative a cure e farmaci appropriati. Un modello un'applicazione di AI che utilizza un LLM medico come Med-PaLM può essere utilizzato per assistere i medici nel loro processo di diagnosi clinica. Le risposte generati dall'applicazione possono essere basati sulle cartelle cliniche storiche dei pazienti, contestualizzare il lavoro con dati provenienti dal database elettronico dell'ospedale un database di cartelle cliniche (EHR) o da una knowledge base esterna come PubMed

La ricerca legale basata sull'IA generativa consente agli avvocati di interrogare rapidamente grandi volumi di statuti e giurisprudenza per identificare i precedenti legali pertinenti o riassumere concetti giuridici complessi. Il risultato di questa ricerca può essere migliorato Integrando le richieste di un avvocato con i dati recuperati dalla sua corpus proprietario di contratti, comunicazioni legali passate e casi interni record. Questo approccio di progettazione garantisce che le risposte generate siano pertinenti nell'ambito legale in cui l'avvocato è specializzato.

Alternativa di progettazione

Per i componenti di archiviazione vettoriale e di ricerca semantica nell'architettura, è possibile usare Vertex AI Vector Search. Vector Search è un servizio completamente gestito che fornisce di gestione dell'infrastruttura per la ricerca vettoriale su larga scala. I dati non elaborati (testo chunks) possono essere archiviati in archivi di oggetti come Cloud Storage o di archiviazione chiave-valore come Filestore. In entrambi i casi, il vettore di ogni blocco di testo non elaborato viene archiviata in Vector Search.

Quando i dati vengono importati, a ogni blocco di testo non elaborato viene assegnato un ID univoco L'ID viene utilizzato come nome file dell'oggetto in Cloud Storage. Lo stesso ID è utilizzato come ID vettoriale in Vector Search.

Al momento della pubblicazione, una query di testo in entrata viene convertita in vettore di incorporamento. La ricerca vettoriale esegue una ricerca di somiglianza per restituire vettori semanticamente simili. Gli ID vettoriali vengono quindi utilizzati per cercare a blocchi di testo originali. Collettivamente, questi frammenti di testo forniscono contesto necessario all'LLM per completare una determinata attività.

Per informazioni su come creare, eseguire il deployment e eseguire query su un indice di ricerca vettoriale, vedi il Guida rapida alla ricerca vettoriale.

Note sul layout

Questa sezione fornisce indicazioni per aiutarti a sviluppare un'IA generativa compatibile con RAG un'architettura in Google Cloud che soddisfi i tuoi requisiti specifici per sicurezza e conformità, affidabilità, costi e prestazioni. Le indicazioni in questa sezione non è esaustiva. In base ai requisiti specifici del l'applicazione dell'AI generativa e i prodotti e le funzionalità di Google Cloud che utilizzi, potresti dover prendere in considerazione altri fattori di progettazione e compromessi.

Sicurezza e conformità

Questa sezione descrive i fattori che devi prendere in considerazione quando progetti creare un'applicazione di AI generativa compatibile con RAG in Google Cloud che soddisfi le i tuoi requisiti di sicurezza e conformità.

Prodotto Note sul layout
Vertex AI Vertex AI supporta i controlli di sicurezza di Google Cloud che puoi utilizzare per soddisfare i requisiti di residenza dei dati, crittografia, sicurezza della rete e trasparenza degli accessi. Per ulteriori informazioni le informazioni, vedi Controlli di sicurezza per Vertex AI e . Controlli di sicurezza per l'IA generativa.
Cloud Run

Per impostazione predefinita, Cloud Run cripta i dati utilizzando una Chiave di proprietà di Google e gestita da Google. Per proteggere i container mediante una chiave gestita da te, puoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK). Per ulteriori informazioni, vedi Utilizzo di chiavi di crittografia gestite dal cliente.

Per garantire che venga eseguito il deployment nell'istanza solo delle immagini container autorizzate in Cloud Run, puoi utilizzare Autorizzazione binaria.

Cloud Run ti aiuta a soddisfare i requisiti di residenza dei dati. Le istanze di container Cloud Run vengono eseguite all'interno della regione che selezioni.

AlloyDB per PostgreSQL

Per impostazione predefinita, i dati archiviati in AlloyDB per PostgreSQL sono criptati mediante chiavi di proprietà e gestite da Google. Se hai bisogno di usare la crittografia che controlli e gestisci, puoi usare le CMEK. Per ulteriori informazioni le informazioni, vedi Informazioni su CMEK.

Per ridurre il rischio di esfiltrazione di dati da AlloyDB per PostgreSQL puoi creare un perimetro di servizio con Controlli di servizio VPC.

Per impostazione predefinita, un'istanza AlloyDB per PostgreSQL accetta solo connessioni che usano SSL. Per proteggere ulteriormente le connessioni al tuo per i database AlloyDB per PostgreSQL, puoi utilizzare Connettore proxy di autenticazione AlloyDB per PostgreSQL. Il connettore del proxy di autenticazione fornisce l'autorizzazione per la connessione basata su Identity and Access Management (IAM) e utilizza una connessione TLS 1.3 con una crittografia AES a 256 bit per verificare il client le identità dei server e criptare il traffico dei dati. Per ulteriori informazioni, vedi Informazioni sul proxy di autenticazione AlloyDB per PostgreSQL. Per connessioni creati mediante Java, Python o Go, utilizza il linguaggio Connettore di lingua anziché il connettore proxy di autenticazione.

AlloyDB per PostgreSQL ti aiuta a soddisfare i requisiti di residenza dei dati. I dati vengono archiviati o replicati all'interno delle regioni in cui specificare.

BigQuery

BigQuery offre molte funzionalità che puoi usare controllare l'accesso ai dati, proteggere i dati sensibili e garantire l'accuratezza e la coerenza. Per ulteriori informazioni, vedi Introduzione alla governance dei dati in BigQuery.

BigQuery ti aiuta a soddisfare i requisiti di residenza dei dati. I dati vengono archiviati all'interno della regione specificata.

Cloud Storage

Per impostazione predefinita, i dati archiviati in Cloud Storage sono usando chiavi di proprietà e gestite da Google. Se necessario, puoi usare CMEK o le tue chiavi che gestisci utilizzando un come le chiavi di crittografia fornite dal cliente (CSEK). Per ulteriori informazioni, vedi Opzioni di crittografia dei dati.

Cloud Storage supporta due metodi per concedere l'accesso agli utenti ai bucket e agli oggetti: IAM ed elenchi di controllo dell'accesso (ACL). Nella maggior parte dei casi, consigliamo di utilizzare IAM, che consente concedi le autorizzazioni a livello di bucket e di progetto. Per ulteriori informazioni le informazioni, vedi Panoramica del controllo dell'accesso.

I dati caricati nel sottosistema di importazione dati tramite Cloud Storage potrebbe includere dati sensibili. Per proteggere tali dati, puoi utilizzare Sensitive Data Protection per scoprire, classificare e anonimizzare i dati. Per ulteriori informazioni, vedi Utilizzo di Sensitive Data Protection con Cloud Storage.

Cloud Storage ti aiuta a soddisfare i requisiti di residenza dei dati. I dati vengono archiviati o replicati all'interno delle regioni in cui specificare.

Pub/Sub

Per impostazione predefinita, Pub/Sub cripta tutti i messaggi, entrambi at-rest e in transito, usando chiavi di proprietà e gestite da Google. Pub/Sub supporta l'utilizzo di CMEK per messaggio la crittografia a livello dell'applicazione. Per ulteriori informazioni, vedi Configurare la crittografia dei messaggi.

Se hai requisiti di residenza dei dati, per assicurarti che i dati dei messaggi in posizioni specifiche, puoi configurare i criteri di archiviazione dei messaggi.

Document AI Per impostazione predefinita, i dati at-rest vengono criptati utilizzando la crittografia gestita da Google chiave. Se hai bisogno di utilizzare chiavi di crittografia controllate e gestite da te, puoi usare le CMEK. Per ulteriori informazioni, vedi Sicurezza e Conformità.
Cloud Logging

Gli audit log per le attività di amministrazione sono abilitati per impostazione predefinita per tutti Servizi Google Cloud utilizzati in questo riferimento dell'architettura. Questi log registrano le chiamate API o altre azioni che modificano la configurazione o i metadati delle risorse Google Cloud.

Gli audit log di accesso ai dati sono abilitati per impostazione predefinita in BigQuery. Per gli altri servizi utilizzati in questo , puoi abilitare gli audit log di accesso ai dati. I log ti consentono monitorare le chiamate API che leggono la configurazione o i metadati delle risorse richieste degli utenti di creare, modificare o leggere i dati delle risorse forniti dall'utente.

Per soddisfare i requisiti di residenza dei dati, puoi configurare Cloud Logging per archiviare i dati di log nella regione da te specificata. Per ulteriori informazioni, vedi Regionalizza i log.

Per linee guida generali sui principi di sicurezza da considerare per le applicazioni dell'AI, vedi Presentazione del Secure AI Framework di Google.

Affidabilità

Questa sezione descrive i fattori di progettazione che dovresti prendere in considerazione per creare e per gestire un'infrastruttura affidabile per un'applicazione di AI generativa compatibile con RAG in Google Cloud.

Prodotto Note sul layout
Cloud Run

Cloud Run è un servizio a livello di regione. I dati vengono archiviati in modo sincrono tra più zone all'interno di una regione. Il traffico è viene automaticamente bilanciato il carico tra le zone. In caso di interruzione di una zona i job Cloud Run continuano a essere eseguiti e i dati hanno perso. In caso di interruzione di una regione, i job Cloud Run non sarà più in esecuzione finché Google non risolve l'interruzione.

I singoli job o attività Cloud Run potrebbero non riuscire. A per gestire questi errori, puoi utilizzare senza nuovi tentativi e controlli. Per ulteriori informazioni, vedi Best practice per i nuovi tentativi di job e i checkpoint.

AlloyDB per PostgreSQL

Per impostazione predefinita, i cluster AlloyDB per PostgreSQL offrono disponibilità elevata con failover automatico. L'istanza principale contiene dati di nodi situati in due zone diverse all'interno di una regione. Questo la ridondanza assicura che i cluster siano robusti contro la zona o in caso di interruzione del servizio.

Per pianificare il ripristino dopo le interruzioni della regione, puoi utilizzare replica tra regioni.

BigQuery

I dati caricati in BigQuery vengono archiviati in modo sincrono in due zone all'interno della regione specificata. Questa ridondanza aiuta assicurarti che i tuoi dati non vadano persi quando si verifica un'interruzione della zona.

Per ulteriori informazioni sulle funzionalità di affidabilità in per BigQuery, consulta Comprendere l'affidabilità.

Cloud Storage Puoi creare bucket Cloud Storage in uno dei tre seguenti tipi di località: a singola regione, a due regioni o a più regioni. I dati archiviati in regionali vengono replicati in modo sincrono tra più zone all'interno una regione. Per una maggiore disponibilità, puoi utilizzare due o più regioni dei bucket, dove i dati vengono replicati in modo asincrono tra le regioni.
Pub/Sub

Per gestire i picchi temporanei nel traffico dei messaggi, puoi configurare controllo del flusso nelle impostazioni del publisher.

Per gestire le pubblicazioni non riuscite, modifica le variabili di richiesta di nuovo tentativo come necessaria. Per ulteriori informazioni, vedi Riprovare le richieste.

Document AI Document AI è un servizio regionale. I dati vengono archiviati in modo sincrono tra più zone all'interno di una regione. Il traffico è viene automaticamente bilanciato il carico tra le zone. In caso di interruzione di una zona e i dati non vanno persi. Se si verifica un'interruzione di una regione, Document AI non sarà disponibile finché Google non risolverà il problema o un'interruzione del servizio.

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per aiutarti a ottimizzare i costi di configurazione un'applicazione di AI generativa compatibile con RAG in Google Cloud.

Prodotto Note sul layout
Cloud Run

Quando crei job Cloud Run, specifichi la quantità e CPU da allocare all'istanza di container. A controllare i costi, inizia con CPU e memoria predefinite (minima) allocazioni. Per migliorare il rendimento, puoi aumentare l'allocazione configurando Limite CPU e . di memoria standard.

Se puoi prevedere i requisiti di CPU e memoria in Cloud Run, puoi risparmiare denaro ottenendo per l'utilizzo per impegno di utilizzo. Per ulteriori informazioni, vedi Sconti per impegno di utilizzo di Cloud Run.

AlloyDB per PostgreSQL

Per impostazione predefinita, un'istanza principale di un cluster AlloyDB per PostgreSQL l'alta disponibilità (HA). L'istanza ha un nodo attivo e un in standby. In caso di errore del nodo attivo, AlloyDB per PostgreSQL al nodo in standby. Se non hai bisogno di alta disponibilità puoi ridurre i costi rendendo l'istanza principale un'istanza di base. Un'istanza di base non è solida contro una zona e ha tempi di inattività più lunghi durante le operazioni di manutenzione. Per ulteriori informazioni, vedi Riduci i costi utilizzando le istanze di base.

Se puoi prevedere i requisiti di CPU e memoria AlloyDB per PostgreSQL, puoi risparmiare denaro ottenendo per l'utilizzo per impegno di utilizzo. Per ulteriori informazioni, vedi Sconti per impegno di utilizzo di AlloyDB per PostgreSQL.

BigQuery BigQuery ti consente di stimare il costo delle query prima eseguendole. Per ottimizzare i costi delle query, devi ottimizzare lo spazio di archiviazione e il calcolo delle query. Per ulteriori informazioni, vedi Stima e controllo dei costi.
Cloud Storage Per il bucket Cloud Storage che utilizzi per caricare i dati sottosistema di importazione dati, scegli un'istanza classe di archiviazione basata sulla conservazione dei dati e la frequenza di accesso per i requisiti dei tuoi carichi di lavoro. Ad esempio, puoi scegliere il modello classe di archiviazione e utilizza Gestione del ciclo di vita degli oggetti per controllare i costi di archiviazione in modo automatico eseguire il downgrade degli oggetti a una classe di archiviazione a basso costo o eliminazione di oggetti in base alle condizioni da te impostate.
Cloud Logging

Per controllare i costi di archiviazione dei log, puoi procedere come segue:

Prestazioni

Questa sezione descrive i fattori che devi prendere in considerazione quando progetti creare un'applicazione di AI generativa compatibile con RAG in Google Cloud che soddisfi le i tuoi requisiti di prestazioni.

Prodotto Note sul layout
Cloud Run Per impostazione predefinita, ogni istanza di container Cloud Run allocati una CPU e 512 MiB di memoria. In base di prestazioni per i tuoi job Cloud Run, puoi configurare lo Limite CPU e limite di memoria.
AlloyDB per PostgreSQL

Per aiutarti ad analizzare e migliorare le prestazioni delle query dei database, AlloyDB per PostgreSQL fornisce uno strumento Query Insights. Puoi utilizzare questo strumento per monitorare le prestazioni e tracciare l'origine di un una query problematica. Per ulteriori informazioni, vedi Panoramica di Query Insights.

per avere una panoramica dello stato e delle prestazioni dei tuoi database. e per visualizzare metriche dettagliate come i picchi di connessioni di replica, puoi utilizzare la dashboard di System Insights. Per ulteriori informazioni le informazioni, vedi Monitora un'istanza utilizzando gli insight di sistema di AlloyDB per PostgreSQL dashboard.

Per ridurre il carico sull'istanza AlloyDB per PostgreSQL principale e per fare lo scale out della capacità di gestire le richieste di lettura, puoi aggiungere di lettura delle istanze del pool nel cluster. Per ulteriori informazioni, vedi Nodi e istanze di AlloyDB per PostgreSQL.

BigQuery

BigQuery fornisce un grafico di esecuzione delle query che per analizzare le prestazioni delle query e ottenere insight sulle prestazioni problemi come la contesa degli slot e una quota shuffle insufficiente. Per ulteriori informazioni le informazioni, vedi Ottieni insight sulle prestazioni delle query.

Dopo aver risolto i problemi identificati tramite la query informazioni sulle prestazioni, puoi ottimizzare ulteriormente le query utilizzando tecniche come la riduzione del volume dei dati di input e di output. Per ulteriori informazioni, vedi Ottimizzare il calcolo delle query.

Cloud Storage Per caricare file di grandi dimensioni, puoi utilizzare un metodo chiamato parallelo caricamenti compositi. Con questa strategia, il file di grandi dimensioni viene in blocchi. I blocchi vengono caricati su Cloud Storage in parallelo e i dati vengono ricomposti nel cloud. Parallelo i caricamenti compositi possono essere più veloci delle normali operazioni di caricamento quando la larghezza di banda della rete e la velocità del disco non limitano i fattori. Tuttavia, questa strategia presenta alcune limitazioni e implicazioni in termini di costi. Per ulteriori informazioni le informazioni, vedi Caricamenti compositi paralleli.

Deployment

Per iniziare e sperimentare la creazione dell'infrastruttura su Google Cloud per le applicazioni di AI generativa compatibili con RAG, puoi usare Soluzione Jump Start: RAG di IA generativa con Cloud SQL. Questa soluzione esegue il deployment di un'applicazione di chat basata su Python Cloud Run e utilizza un database Cloud SQL completamente gestito per la ricerca vettoriale. Il codice campione per questa soluzione è disponibile in GitHub.

Passaggi successivi

Collaboratori

Autore: Kumar Dhanagopal | Sviluppatore di soluzioni cross-product

Altri collaboratori: