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

Last reviewed 2024-12-11 UTC

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

Architettura

Il seguente diagramma mostra una panoramica di un'architettura per un'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 la funzionalità RAG. Il sottosistema di importazione dati interagisce con gli altri sottosistemi dell'architettura tramite il livello del database.
Sottosistema di pubblicazione Gestisci il flusso di richiesta-risposta tra l'applicazione di AI generativa e i suoi utenti. Il sottosistema di pubblicazione interagisce con il sottosistema di importazione dati tramite il livello del database.
Sottosistema di valutazione della qualità Valuta la qualità delle risposte generate dal sottosistema di pubblicazione. Il sottosistema di valutazione della qualità interagisce direttamente con il sottosistema di pubblicazione e con il sottosistema di importazione dati tramite il livello del database.
Database Memorizza i seguenti dati:
  • Prompt
  • Embedding vettoriali dei dati utilizzati per RAG
  • Configurazione dei job serverless nei sottosistemi di importazione e valutazione della qualità dei dati
Tutti i sottosistemi dell'architettura interagiscono con i database.

Il seguente diagramma mostra una visualizzazione dettagliata dell'architettura:

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

Le sezioni seguenti forniscono descrizioni dettagliate dei componenti e del flusso di dati 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 streaming. I dati caricati includono prompt per la valutazione della qualità. Il sottosistema di importazione dati fornisce la funzionalità RAG nell'architettura. Il seguente diagramma mostra i dettagli del sottosistema di importazione dati nell'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 dei dati:

  1. I dati sono caricati su un bucket Cloud Storage. L'origine dati potrebbe essere un utente dell'applicazione che esegue un caricamento, l'importazione di un database o lo streaming di dati.
  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 i dati caricati.
  4. Cloud Run avvia il job utilizzando i dati di configurazione memorizzati in un database AlloyDB per PostgreSQL.
  5. Il job Cloud Run utilizza Document AI per preparare i dati per l'ulteriore elaborazione. Ad esempio, la preparazione può includere l'analisi dei dati, la conversione dei dati nel formato richiesto e la divisione dei dati in blocchi.

  6. Il job Cloud Run utilizza il modello Vertex AI Embeddings for Text per creare incorporamenti vettoriali dei dati importati.

  7. Cloud Run archivia gli incorporamenti in un database AlloyDB per PostgreSQL in cui è abilitata l'estensione pgvector. Come descritto nella sezione seguente, quando il sottosistema di pubblicazione elabora le richieste degli utenti, utilizza gli incorporamenti nel database vettoriale per recuperare i dati specifici del dominio pertinenti.

Sottosistema di pubblicazione

Il sottosistema di pubblicazione gestisce il flusso di richiesta-risposta tra l'applicazione di AI generativa e i suoi utenti. Il seguente diagramma mostra i dettagli del sottosistema di pubblicazione nell'architettura:

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

Di seguito sono riportati i passaggi del flusso di richiesta-risposta nel sottosistema di pubblicazione:

  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 in incorporamenti.

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

    1. L'applicazione esegue una ricerca semantica dell'embedding nell'archivio vettoriale AlloyDB per PostgreSQL gestito dal sottosistema di importazione dei dati. La ricerca semantica consente di trovare gli incorporamenti in base all'intento di un prompt anziché ai suoi contenuti testuali.
    2. L'applicazione combina la richiesta originale con i dati non elaborati recuperati in base all'incorporamento corrispondente per creare un prompt contestualizzato.

  4. L'applicazione invia il prompt contestualizzato a uno stack di inferenza LLM che viene eseguito su Vertex AI.

  5. Lo stack di inferenza LLM utilizza un LLM di AI 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à di richiesta-risposta in Cloud Logging. Puoi visualizzare e utilizzare i log per il monitoraggio utilizzando Cloud Monitoring. Google non accede ai dati di log né li utilizza.
    2. L'applicazione carica le risposte in BigQuery per l'analisi offline.

  6. L'applicazione filtra le risposte utilizzando filtri di AI 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à nell'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, esegue le seguenti operazioni:

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

  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 da punteggi di valutazione per metriche come l'accuratezza oggettiva e la pertinenza.

  5. Cloud Run carica i punteggi di valutazione e i prompt e le risposte che sono state valutate in BigQuery per analisi future.

Prodotti utilizzati

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

  • Vertex AI: una piattaforma ML che ti consente di addestrare ed eseguire il deployment di modelli ML e applicazioni AI e personalizzare LLM da utilizzare in applicazioni basate sull'AI.
  • Cloud Run: una piattaforma di computing serverless che ti consente di eseguire 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 machine learning, analisi geospaziale e business intelligence.
  • Cloud Storage: uno spazio di archiviazione di oggetti a basso costo e senza limiti per diversi tipi di dati. I dati sono accessibili dall'interno e dall'esterno di Google Cloude vengono 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, tra cui l'elaborazione analitica e transazionale ibrida.
  • Document AI: una piattaforma di elaborazione dei documenti che prende dati non strutturati dai documenti e li trasforma in dati strutturati.
  • Pub/Sub: un servizio di messaggistica asincrono e scalabile che disaccoppia i servizi che producono messaggi da quelli che li elaborano.
  • Cloud Logging: un sistema di gestione dei log in tempo reale con archiviazione, ricerca, analisi e avvisi.
  • Cloud Monitoring: un servizio che offre visibilità su prestazioni, disponibilità e integrità delle tue applicazioni e della tua infrastruttura.

Casi d'uso

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

Suggerimenti personalizzati sui prodotti

Un sito di acquisti online potrebbe utilizzare un chatbot basato su LLM per aiutare i clienti a trovare prodotti o a ricevere assistenza per gli acquisti. Le domande di un utente possono essere arricchite utilizzando i dati storici sul comportamento di acquisto dell'utente e sui modelli di interazione con il sito web. I dati potrebbero includere recensioni e feedback degli utenti archiviati in un datastore non strutturato o metriche correlate alla ricerca archiviate in un data warehouse di analisi web. La domanda aumentata può essere elaborata dall'LLM per generare risposte personalizzate che l'utente potrebbe trovare più interessanti e coinvolgenti.

Sistemi di assistenza clinica

I medici negli ospedali devono analizzare e diagnosticare rapidamente le condizioni di salute di un paziente per prendere decisioni in merito alle cure e ai farmaci appropriati. Un'applicazione di AI generativa che utilizza un LLM medico come Med-PaLM può essere utilizzata per assistere i medici nella procedura di diagnosi clinica. Le risposte generate dall'applicazione possono essere basate sulle cartelle cliniche storiche dei pazienti contestualizzando i prompt dei medici con i dati del database delle cartelle cliniche elettroniche (EHR) dell'ospedale o di una knowledge base esterna come PubMed.

La ricerca giuridica basata sull'AI generativa consente agli avvocati di interrogare rapidamente grandi volumi di leggi e giurisprudenza per identificare precedenti giuridici pertinenti o riassumere concetti giuridici complessi. I risultati di questa ricerca possono essere migliorati integrando i prompt di un avvocato con i dati recuperati dal corpus proprietario di contratti, comunicazioni legali passate e registri interni dello studio legale. Questo approccio di progettazione garantisce che le risposte generate siano pertinenti al settore legale in cui è specializzato l'avvocato.

Alternative di progettazione

Questa sezione presenta approcci di progettazione alternativi che puoi prendere in considerazione per la tua applicazione di AI generativa compatibile con RAG in Google Cloud.

Se hai bisogno di un'architettura che utilizzi un prodotto di ricerca vettoriale completamente gestito, puoi utilizzare Vertex AI e Vector Search, che forniscono un'infrastruttura di pubblicazione ottimizzata per la ricerca vettoriale su larga scala. Per ulteriori informazioni, consulta Infrastruttura per un'applicazione di AI generativa compatibile con RAG utilizzando Vertex AI e Vector Search.

Modelli e strumenti open source

Se vuoi creare ed eseguire il deployment rapidamente di applicazioni di AI generativa compatibili con RAG utilizzando strumenti e modelli open source Ray, Hugging Face e LangChain, consulta Infrastruttura per un'applicazione di AI generativa compatibile con RAG utilizzando GKE e Cloud SQL.

Altre opzioni

Per informazioni su altre opzioni di infrastruttura, modelli supportati e tecniche di grounding che puoi utilizzare per le applicazioni di AI generativa in Google Cloud, consulta Scegliere modelli e infrastruttura per la tua applicazione di AI generativa.

Note sul layout

Questa sezione fornisce indicazioni per aiutarti a sviluppare un'architettura di AI generativa con funzionalità RAG in Google Cloud che soddisfi i tuoi requisiti specifici di sicurezza e conformità, affidabilità, costi e prestazioni. Le indicazioni riportate in questa sezione non sono esaustive. A seconda dei requisiti specifici della tua applicazione di AI generativa e dei Google Cloud prodotti e delle funzionalità che utilizzi, potresti dover prendere in considerazione fattori di progettazione e compromessi aggiuntivi.

Sicurezza e conformità

Questa sezione descrive i fattori da considerare quando progetti e crei un'applicazione di AI generativa in Google Cloud che soddisfi i tuoi requisiti di sicurezza e conformità.

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

Per impostazione predefinita, Cloud Run cripta i dati utilizzando un Google-owned and Google-managed encryption key. Per proteggere i tuoi container utilizzando una chiave che controlli, puoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK). Per saperne di più, vedi Utilizzo delle chiavi di crittografia gestite dal cliente.

Per garantire che venga eseguito il deployment solo delle immagini container autorizzate nei job Cloud Run, puoi utilizzare Autorizzazione binaria.

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

AlloyDB per PostgreSQL

Per impostazione predefinita, i dati archiviati in AlloyDB per PostgreSQL vengono criptati utilizzando Google-owned and Google-managed encryption keys. Se devi utilizzare chiavi di crittografia che controlli e gestisci, puoi utilizzare le chiavi CMEK. Per ulteriori informazioni, consulta Informazioni su CMEK.

Per mitigare il rischio di esfiltrazione di dati dai database AlloyDB per PostgreSQL, puoi creare un perimetro di servizio utilizzando i Controlli di servizio VPC.

Per impostazione predefinita, un'istanza AlloyDB per PostgreSQL accetta solo le connessioni che utilizzano SSL. Per proteggere ulteriormente le connessioni ai tuoi database AlloyDB per PostgreSQL, puoi utilizzare il connettore proxy di autenticazione AlloyDB per PostgreSQL. Il connettore Auth Proxy fornisce l'autorizzazione di connessione basata su Identity and Access Management (IAM) e utilizza una connessione TLS 1.3 con una crittografia AES a 256 bit per verificare le identità di client e server e criptare il traffico di dati. Per saperne di più, consulta Informazioni sul proxy di autenticazione AlloyDB per PostgreSQL. Per le connessioni create utilizzando Java, Python o Go, utilizza il connettore di linguaggio appropriato anziché il connettore del 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 che specifichi.

BigQuery

BigQuery offre molte funzionalità che puoi utilizzare per controllare l'accesso ai dati, proteggere i dati sensibili e garantire l'accuratezza e la coerenza dei dati. 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 vengono criptati utilizzando Google-owned and Google-managed encryption keys. Se necessario, puoi utilizzare le chiavi CMEK o le tue chiavi gestite utilizzando un metodo di gestione esterno, ad esempio le chiavi di crittografia fornite dal cliente (CSEK). Per maggiori informazioni, consulta Opzioni di crittografia dei dati.

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

I dati caricati nel sottosistema di importazione dati tramite Cloud Storage potrebbero includere dati sensibili. Per proteggere questi dati, puoi utilizzare la protezione dei dati sensibili per rilevarli, classificarli e anonimizzarli. Per ulteriori informazioni, consulta 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 che specifichi.

Pub/Sub

Per impostazione predefinita, Pub/Sub cripta tutti i messaggi, sia at-rest che in transito, utilizzando Google-owned and Google-managed encryption keys. Pub/Sub supporta l'utilizzo di chiavi CMEK per la crittografia dei messaggi a livello di applicazione. Per saperne di più, consulta Configurare la crittografia dei messaggi.

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

Document AI Per impostazione predefinita, i dati at-rest vengono criptati utilizzando chiavi di crittografia gestite da Google. Se devi utilizzare chiavi di crittografia che controlli e gestisci, puoi utilizzare le CMEK. Per saperne di più, consulta Sicurezza e conformità di Document AI.
Cloud Logging

I log di controllo delle attività di amministrazione sono abilitati per impostazione predefinita per tutti i servizi Google Cloud utilizzati in questa architettura di riferimento. Questi log registrano le chiamate API o altre azioni che modificano la configurazione o i metadati delle risorse. Google Cloud

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

Per rispettare i requisiti di residenza dei dati, puoi configurare Cloud Logging in modo che memorizzi i dati di log nella regione che specifichi. Per ulteriori informazioni, vedi Regionalizzare i log.

Per principi e consigli di sicurezza specifici per i carichi di lavoro di AI e ML, consulta Prospettiva AI e ML: sicurezza nel framework Well-Architected.

Affidabilità

Questa sezione descrive i fattori di progettazione da considerare per creare e 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 regionale. I dati vengono archiviati in modo sincrono in più zone all'interno di una regione. Il traffico viene bilanciato automaticamente tra le zone. Se si verifica un'interruzione di zona, i job Cloud Run continuano a essere eseguiti e i dati non vengono persi. Se si verifica un'interruzione del servizio a livello di regione, i job Cloud Run smettono di essere eseguiti finché Google non risolve l'interruzione.

Singoli job o attività Cloud Run potrebbero non riuscire. Per gestire questi errori, puoi utilizzare i nuovi tentativi di esecuzione delle attività e il checkpointing. Per maggiori informazioni, consulta Best practice per i tentativi ripetuti e i checkpoint dei job.

AlloyDB per PostgreSQL

Per impostazione predefinita, i cluster AlloyDB per PostgreSQL forniscono alta disponibilità (HA) con failover automatico. L'istanza primaria ha nodi ridondanti che si trovano in due zone diverse all'interno di una regione. Questa ridondanza garantisce che i cluster siano robusti contro le interruzioni di zona.

Per pianificare il ripristino in caso di interruzioni del servizio a livello di regione, puoi utilizzare la replica tra regioni.

BigQuery

I dati che carichi in BigQuery vengono archiviati in modo sincrono in due zone all'interno della regione che specifichi. Questa ridondanza contribuisce a garantire che i dati non vengano persi in caso di interruzione della zona.

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

Cloud Storage Puoi creare bucket Cloud Storage in uno dei tre tipi di località: regionale, dual-region o multiregionale. I dati archiviati in bucket regionali vengono replicati in modo sincrono in più zone all'interno di una regione. Per una maggiore disponibilità, puoi utilizzare bucket dual-region o multiregionali, in cui i dati vengono replicati in modo asincrono tra le regioni.
Pub/Sub

Per gestire i picchi transitori nel traffico di messaggi, puoi configurare il controllo del flusso nelle impostazioni del publisher.

Per gestire le pubblicazioni non riuscite, modifica le variabili di richiesta di nuovi tentativi in base alle tue esigenze. Per maggiori informazioni, consulta la sezione Riprovare le richieste.

Document AI

Document AI è un servizio regionale. I dati vengono archiviati in modo sincrono in più zone all'interno di una regione. Il traffico viene bilanciato automaticamente tra le zone. Se si verifica un'interruzione della zona, i dati non vengono persi. In caso di interruzione di una regione, Document AI non è disponibile finché Google non risolve l'interruzione.

Per principi e consigli di affidabilità specifici per i workload AI e ML, consulta Prospettiva AI e ML: affidabilità nel framework Well-Architected.

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per aiutarti a ottimizzare il costo di configurazione e gestione di 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à di memoria e CPU da allocare all'istanza del container. Per controllare i costi, inizia con le allocazioni predefinite (minime) di CPU e memoria. Per migliorare le prestazioni, puoi aumentare l'allocazione configurando il limite di CPU e il limite di memoria.

Se riesci a prevedere i requisiti di CPU e memoria dei tuoi job Cloud Run, puoi risparmiare denaro ottenendo sconti per l'utilizzo con impegno. Per saperne di più, consulta la pagina Sconti per impegno di utilizzo di Cloud Run.

AlloyDB per PostgreSQL

Per impostazione predefinita, un'istanza primaria di un cluster AlloyDB per PostgreSQL è ad alta disponibilità (HA). L'istanza ha un nodo attivo e un nodo di standby. Se il nodo attivo non funziona, AlloyDB per PostgreSQL esegue automaticamente il failover sul nodo di standby. Se non hai bisogno dell'alta affidabilità per i database, puoi ridurre i costi rendendo l'istanza principale del cluster un'istanza di base. Un'istanza di base non è robusta contro le interruzioni di zona e ha tempi di inattività più lunghi durante le operazioni di manutenzione. Per maggiori informazioni, consulta Ridurre i costi utilizzando le istanze di base.

Se riesci a prevedere i requisiti di CPU e memoria della tua istanza AlloyDB per PostgreSQL, puoi risparmiare ottenendo sconti per l'utilizzo con impegno. Per saperne di più, consulta la pagina relativa agli sconti per impegno di utilizzo di AlloyDB per PostgreSQL.

BigQuery BigQuery ti consente di stimare il costo delle query prima di eseguirle. Per ottimizzare i costi delle query, devi ottimizzare l'archiviazione e il calcolo delle query. Per ulteriori informazioni, vedi Stimare e controllare i costi.
Cloud Storage Per il bucket Cloud Storage che utilizzi per caricare i dati nel sottosistema di importazione dati, scegli una classe di archiviazione appropriata in base ai requisiti di conservazione dei dati e frequenza di accesso dei tuoi carichi di lavoro. Ad esempio, puoi scegliere la classe di archiviazione Standard e utilizzare la Gestione del ciclo di vita degli oggetti per controllare i costi di archiviazione eseguendo automaticamente il downgrade degli oggetti a una classe di archiviazione a costi inferiori o eliminando gli oggetti in base alle condizioni che imposti.
Cloud Logging

Per controllare il costo di archiviazione dei log, puoi:

Per principi e consigli di ottimizzazione dei costi specifici per i carichi di lavoro di AI e ML, consulta Prospettiva AI e ML: ottimizzazione dei costi nel framework Well-Architected.

Prestazioni

Questa sezione descrive i fattori da considerare quando progetti e crei un'applicazione di AI generativa in Google Cloud in grado di utilizzare RAG che soddisfi i tuoi requisiti di rendimento.

Prodotto Note sul layout
Cloud Run Per impostazione predefinita, a ogni istanza di container Cloud Run vengono allocate una CPU e 512 MiB di memoria. A seconda dei requisiti di rendimento dei tuoi job Cloud Run, puoi configurare il limite di CPU e il 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 il rendimento e risalire all'origine di una query problematica. Per maggiori informazioni, consulta Panoramica di Query Insights.

Per ottenere una panoramica dello stato e del rendimento dei tuoi database e per visualizzare metriche dettagliate come picchi di connessioni e ritardo di replica massimo, puoi utilizzare il dashboard System Insights. Per saperne di più, consulta Monitorare un'istanza utilizzando la dashboard System Insights di AlloyDB per PostgreSQL.

Per ridurre il carico sull'istanza AlloyDB per PostgreSQL primaria e per fare lo scale out la capacità di gestire le richieste di lettura, puoi aggiungere istanze del pool di lettura al cluster. Per saperne di più, consulta la sezione Nodi e istanze di AlloyDB per PostgreSQL.

BigQuery

BigQuery fornisce un grafico di esecuzione delle query che puoi utilizzare per analizzare le prestazioni delle query e ottenere informazioni sulle prestazioni per problemi come la contesa degli slot e la quota di shuffle insufficiente. Per ulteriori informazioni, consulta Ottenere approfondimenti sul rendimento delle query.

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

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

Per principi e consigli di ottimizzazione delle prestazioni specifici per i carichi di lavoro di AI e ML, consulta Prospettiva AI e ML: ottimizzazione delle prestazioni nel Well-Architected Framework.

Deployment

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

Passaggi successivi

Collaboratori

Autore: Kumar Dhanagopal | Sviluppatore di soluzioni cross-product

Altri collaboratori: