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 conoscenza 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 vista di alto livello di un'architettura 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 attivare 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:
|
Tutti i sottosistemi dell'architettura interagiscono con i database. |
Il seguente diagramma mostra una visualizzazione dettagliata dell'architettura:
Le sezioni seguenti forniscono descrizioni dettagliate dei componenti e del flusso di dati all'interno di ciascun sottosistema dell'architettura.
Sottosistema di importazione dati
Il sottosistema di importazione dati importa 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:
Di seguito sono riportati i passaggi del flusso di importazione dei dati:
- 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.
- Quando i dati vengono caricati, viene inviata una notifica a un argomento Pub/Sub.
- Pub/Sub attiva un job Cloud Run per elaborare i dati caricati.
- Cloud Run avvia il job utilizzando i dati di configurazione memorizzati in un database AlloyDB per PostgreSQL.
- Il job Cloud Run utilizza Document AI per preparare i dati per un'ulteriore elaborazione. Ad esempio, la preparazione può includere l'analisi dei dati, la loro conversione nel formato richiesto e la loro suddivisione in blocchi.
Il job Cloud Run utilizza il modello Vertex AI Embeddings per il testo per creare incorporamenti vettorializzati dei dati importati.
Cloud Run memorizza le istanze incorporate in un database AlloyDB per PostgreSQL in cui è attivata l'estensione
pgvector. Come descritto nella sezione seguente, quando il sottosistema di pubblicazione elabora le richieste degli utenti, utilizza gli embedding nel database di vettori per recuperare i dati pertinenti specifici del dominio.
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:
Di seguito sono riportati i passaggi del flusso di richiesta-risposta nel sottosistema di pubblicazione:
- Gli utenti inviano richieste all'applicazione di AI generativa tramite un frontend (ad esempio un chatbot o un'app mobile).
L'applicazione di AI generativa converte la richiesta in linguaggio naturale in embedding.
L'applicazione completa la parte di recupero dell'approccio RAG:
- L'applicazione esegue una ricerca semantica dell'embedding nello store vettoriale AlloyDB per PostgreSQL gestito dal sottosistema di importazione dei dati. La ricerca semantica aiuta a trovare gli embedding in base all'intento di un prompt anziché ai suoi contenuti testuali.
- L'applicazione combina la richiesta originale con i dati non elaborati recuperati in base all'embedding corrispondente per creare un prompt contestualizzato.
L'applicazione invia il prompt contestualizzato a uno stack di inferenza LLM eseguito su Vertex AI.
La pila 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.
- 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 né utilizza i dati dei log.
- L'applicazione carica le risposte in BigQuery per l'analisi offline.
L'applicazione seleziona le risposte utilizzando filtri di IA responsabile.
L'applicazione invia le risposte sottoposte a screening agli utenti tramite il frontend.
Sottosistema di valutazione della qualità
Il seguente diagramma mostra i dettagli del sottosistema di valutazione della qualità nell'architettura:
Quando il sottosistema di valutazione della qualità riceve una richiesta, esegue i seguenti passaggi:
- Pub/Sub attiva un job Cloud Run.
- Cloud Run avvia il job utilizzando i dati di configurazione memorizzati in un database AlloyDB per PostgreSQL.
- Il job Cloud Run estrae le richieste di valutazione da un database AlloyDB per PostgreSQL. In precedenza, i prompt erano stati caricati nel database dal sottosistema di importazione dati.
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 accuratezza oggettiva e pertinenza.
Cloud Run carica i punteggi di valutazione, i prompt e le risposte valutati in BigQuery per analisi future.
Prodotti utilizzati
Di seguito è riportato un riepilogo di tutti i prodotti Google Cloud utilizzati dall'architettura precedente:
- Vertex AI: una piattaforma ML che ti consente di addestrare ed eseguire il deployment di modelli ML e applicazioni IA e personalizzare LLM da utilizzare nelle applicazioni basate sull'IA.
- Cloud Run: una piattaforma di calcolo 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 Cloud e vengono replicati in più località per garantire 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 di documenti che acquisisce dati non strutturati dai documenti e li trasforma in dati strutturati.
- Pub/Sub: un servizio di messaggistica asincrono e scalabile che consente di disaccoppiare 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 fornisce visibilità su prestazioni, disponibilità e integrità delle tue applicazioni e dell'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 shopping online potrebbe utilizzare un chatbot basato su LLM per aiutare i clienti a trovare prodotti o ricevere assistenza in merito agli acquisti. Le domande di un utente possono essere migliorate utilizzando i dati storici sul suo comportamento di acquisto e sui modelli di interazione con il sito web. I dati potrebbero includere recensioni e feedback degli utenti archiviati in un archivio dati non strutturato o metriche correlate alla ricerca archiviate in un data warehouse di analisi web. La domanda aumentata può essere quindi elaborata dall'LLM per generare risposte personalizzate che l'utente potrebbe trovare più accattivanti e convincenti.
Sistemi di assistenza clinica
I medici degli ospedali devono analizzare e diagnosticare rapidamente le condizioni di salute di un paziente per prendere decisioni in merito a cure e farmaci appropriati. Un'applicazione di AI generativa che utilizza un modello 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 sui record storici dei pazienti contestualizzando le richieste dei medici con i dati del database della cartella clinica elettronica (EHR) dell'ospedale o di una knowledge base esterna come PubMed.
Ricerca legale efficiente
La ricerca legale basata sull'IA generativa consente agli avvocati di eseguire rapidamente query su grandi volumi di statuti e giurisprudenza per identificare precedenti legali pertinenti o riassumere concetti legali complessi. Il risultato di questa ricerca può essere migliorato integrando le richieste di un avvocato con i dati recuperati dal corpus proprietario di contratti, comunicazioni legali passate e registrazioni interne relative alle cause dello studio legale. Questo approccio di progettazione garantisce che le risposte generate siano pertinenti al dominio legale in cui l'avvocato è specializzato.
Design alternativo
Per i componenti del datastore vettoriale e della ricerca semantica nell'architettura, puoi utilizzare Vertex AI Vector Search. Ricerca di vettori è un servizio completamente gestito che fornisce un'infrastruttura di pubblicazione ottimizzata per la ricerca di vettori su larga scala. I dati non elaborati (blocchi di testo) possono essere archiviati in oggetti come Cloud Storage o in memorizzazioni delle chiavi come Filestore. In entrambi i casi, la rappresentazione vettoriale di ogni frammento 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, che viene utilizzato come nome file dell'oggetto in Cloud Storage. Viene utilizzato lo stesso ID dell'ID vettore in Ricerca vettoriale.
Al momento della pubblicazione, una query di testo in entrata viene convertita in un vettore di embedding. La ricerca vettoriale esegue una ricerca di similarità per restituire i vettori più simili dal punto di vista semantico. Gli ID vettore vengono poi utilizzati per cercare i blocchi di testo originali. Nel loro insieme, questi blocchi di testo forniscono il contesto pertinente di cui l'LLM ha bisogno per completare una determinata attività.
Per informazioni su come creare, implementare ed eseguire query su un indice di ricerca vettoriale, consulta la guida rapida di Ricerca vettoriale.
Note sul layout
Questa sezione fornisce indicazioni per aiutarti a sviluppare un'architettura di AI generativa compatibile con RAG in Google Cloud che soddisfi i tuoi requisiti specifici per 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 prodotti e delle funzionalità Google Cloud che utilizzi, potresti dover prendere in considerazione fattori di progettazione e compromessi aggiuntivi.
Sicurezza e conformità
Questa sezione descrive i fattori da considerare durante la progettazione e la creazione di un'applicazione di AI generativa compatibile con RAG in Google Cloud che soddisfi 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 tuoi requisiti di residenza dei dati, crittografia dei dati, sicurezza della rete e trasparenza dell'accesso. Per ulteriori informazioni, consulta 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 tuoi contenitori utilizzando una chiave che controlli, puoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK). Per ulteriori informazioni, consulta Utilizzo delle chiavi di crittografia gestite dal cliente. Per garantire che venga eseguito il deployment solo di 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 dei container Cloud Run vengono eseguite nella regione selezionata. |
| AlloyDB per PostgreSQL |
Per impostazione predefinita, i dati archiviati in AlloyDB per PostgreSQL vengono criptati utilizzando chiavi di proprietà e gestite da Google. Se devi utilizzare chiavi di crittografia che controlli e gestisci, puoi utilizzare le chiavi CMEK. Per ulteriori informazioni, consulta la pagina Informazioni su CMEK. Per ridurre il rischio di esfiltrazione di dati dai database AlloyDB per PostgreSQL, puoi creare un perimetro di servizio utilizzando Controlli di servizio VPC. Per impostazione predefinita, un'istanza AlloyDB per PostgreSQL accetta solo connessioni che utilizzano SSL. Per aumentare la sicurezza delle connessioni ai 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 un'algoritmo 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 del 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 nelle regioni specificate. |
| 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, consulta Introduzione alla governance dei dati in BigQuery. BigQuery ti aiuta a soddisfare i requisiti di residenza dei dati. I dati vengono archiviati nella regione specificata. |
| Cloud Storage |
Per impostazione predefinita, i dati archiviati in Cloud Storage vengono criptati utilizzando chiavi di proprietà e gestite da Google. Se necessario, puoi utilizzare le chiavi CMEK o le tue chiavi che gestisci utilizzando un metodo di gestione esterno come 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 la 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 della protezione dei dati sensibili con Cloud Storage. Cloud Storage ti aiuta a soddisfare i requisiti di residenza dei dati. I dati vengono archiviati o replicati nelle regioni specificate. |
| Pub/Sub |
Per impostazione predefinita, Pub/Sub cripta tutti i messaggi, sia at-rest che in transito, utilizzando chiavi di proprietà e gestite da Google. Pub/Sub supporta l'utilizzo delle chiavi CMEK per la crittografia dei messaggi a livello di applicazione. Per ulteriori informazioni, 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 le chiavi di crittografia gestite da Google. Se devi utilizzare chiavi di crittografia che controlli e gestisci, puoi utilizzare le chiavi CMEK. Per ulteriori informazioni, consulta Sicurezza e conformità di Document AI. |
| Cloud Logging |
Gli audit log 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 log di controllo per l'accesso ai dati sono abilitati per impostazione predefinita per BigQuery. Per gli altri servizi utilizzati in questa l'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 o le richieste degli utenti di creare, modificare o leggere i dati delle risorse forniti dall'utente. Per contribuire a soddisfare i requisiti di residenza dei dati, puoi configurare Cloud Logging in modo da archiviare i dati di log nella regione specificata. Per ulteriori informazioni, consulta Regionalizzare i log. |
Per indicazioni generali sui principi di sicurezza da prendere in considerazione per le applicazioni di IA, consulta la pagina Introduzione al Secure AI Framework di Google.
Affidabilità
Questa sezione descrive i fattori di progettazione da prendere in considerazione 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 del servizio in una zona, i job Cloud Run continuano a essere eseguiti e i dati non vengono persi. Se si verifica un'interruzione del servizio in una regione, i job Cloud Run non vengono più eseguiti finché Google non risolve il problema. I singoli job o le singole attività Cloud Run potrebbero non riuscire. Per gestire questi errori, puoi utilizzare i traguardi e i traguardi. Per ulteriori informazioni, consulta Best practice per i tentativi di ripetizione e i checkpoint dei job. |
| AlloyDB per PostgreSQL |
Per impostazione predefinita, i cluster AlloyDB per PostgreSQL forniscono disponibilità elevata (HA) con failover automatico. L'istanza principale ha nodi redundanti situati in due zone diverse all'interno di una regione. Questa ridondanza garantisce che i cluster siano resistenti alle interruzioni della zona. Per pianificare il recupero dalle interruzioni del servizio regionali, puoi utilizzare la replica tra regioni. |
| BigQuery |
I dati caricati in BigQuery vengono archiviati in modo sincrono in due zone all'interno della regione specificata. Questa ridondanza contribuisce a garantire che i dati non vadano persi in caso di interruzione del servizio in una zona. Per ulteriori informazioni sulle funzionalità di affidabilità in BigQuery, consulta Informazioni sull'affidabilità. |
| Cloud Storage | Puoi creare bucket Cloud Storage in uno dei tre tipi di località: regionale, con due regioni o multiregionale. I dati archiviati nei bucket regionali vengono replicati in modo sincrono in più zone all'interno di una regione. Per una maggiore disponibilità, puoi utilizzare i bucket a due o più regioni, in cui i dati vengono replicati in modo asincrono tra le regioni. |
| Pub/Sub |
Per gestire picchi temporanei nel traffico dei messaggi, puoi configurare il controllo del flusso nelle impostazioni del publisher. Per gestire le pubblicazioni non riuscite, modifica le variabili retry-request come necessario. Per ulteriori informazioni, consulta la sezione Reitentare 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. Se si verifica un'interruzione in una regione, Document AI non è disponibile fino a quando Google non risolve l'interruzione. |
Ottimizzazione dei costi
Questa sezione fornisce indicazioni per aiutarti a ottimizzare il costo della configurazione e del funzionamento 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 contenitore. 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 puoi prevedere i requisiti di CPU e memoria dei tuoi job Cloud Run, puoi risparmiare denaro ottenendo sconti per l'utilizzo previsto. Per ulteriori informazioni, consulta Sconti per impegno di utilizzo di Cloud Run. |
| AlloyDB per PostgreSQL |
Per impostazione predefinita, un'istanza principale di un cluster AlloyDB per PostgreSQL è a disponibilità elevata (HA). L'istanza ha un nodo attivo e un nodo di riserva. Se il nodo attivo non funziona, AlloyDB per PostgreSQL esegue automaticamente il failover sul nodo di standby. Se non hai bisogno dell'HA per i database, puoi ridurre i costi impostando l'istanza principale del cluster come istanza di base. Un'istanza di base non è molto resistente alle interruzioni di servizio nelle zone e presenta tempi di inattività più lunghi durante le operazioni di manutenzione. Per maggiori informazioni, consulta la sezione Ridurre i costi utilizzando istanze di base. Se puoi prevedere i requisiti di CPU e memoria della tua istanza AlloyDB per PostgreSQL, puoi risparmiare denaro usufruendo di sconti per l'utilizzo previsto. Per ulteriori informazioni, consulta 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 lo spazio di archiviazione e il calcolo delle query. Per ulteriori informazioni, consulta 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 meno costosa o eliminandoli in base alle condizioni impostate. |
| Cloud Logging |
Per controllare il costo della memorizzazione dei log, puoi:
|
Prestazioni
Questa sezione descrive i fattori da considerare durante la progettazione e la creazione di un'applicazione di AI generativa compatibile con RAG in Google Cloud che soddisfi i tuoi requisiti di prestazioni.
| Prodotto | Note sul layout |
|---|---|
| Cloud Run | Per impostazione predefinita, a ogni istanza di container Cloud Run viene assegnata una CPU e 512 MiB di memoria. A seconda dei requisiti di prestazioni per i 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 le prestazioni e risalire all'origine di una query problematica. Per ulteriori informazioni, consulta Panoramica di Query Insights. Per avere una panoramica dello stato e del rendimento dei tuoi database e per visualizzare metriche dettagliate come le connessioni di picco e il ritardo massimo nella replica, puoi utilizzare la dashboard Approfondimenti sul sistema. Per saperne di più, consulta Monitorare un'istanza utilizzando la dashboard Insight sul sistema AlloyDB per PostgreSQL. Per ridurre il carico sull'istanza AlloyDB per PostgreSQL principale e per scalare la capacità di gestire le richieste di lettura, puoi aggiungere al cluster istanze del pool di lettura. Per saperne di più, consulta Nodi e istanze 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 una quota di ordinamento insufficiente. Per ulteriori informazioni, consulta Ottenere approfondimenti sul rendimento delle query. Dopo aver risolto i problemi identificati tramite gli approfondimenti sul rendimento delle query, puoi ottimizzare ulteriormente le query utilizzando tecniche come la riduzione del volume dei dati di input e output. Per maggiori informazioni, consulta Ottimizzare il 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 chunk vengono caricati su Cloud Storage in parallelo e poi i dati vengono ricompositi nel cloud. I caricamenti compositi paralleli possono essere più rapidi 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, consulta Upload compositi paralleli. |
Deployment
Per iniziare e fare esperimenti sulla 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 di vettori. Il codice campione per questa soluzione è disponibile su GitHub.
Passaggi successivi
- Scopri come creare applicazioni di IA generativa con l'API Vertex AI PaLM e LangChain.
- Scopri come creare app di AI generativa aziendali con i database Google Cloud.
- Scopri come la nuova app di recupero di database di IA generativa contribuisce a migliorare le risposte degli LLM.
- Prova il codelab per creare un'applicazione di chat basata su LLM e RAG utilizzando AlloyDB per l'IA di PostgreSQL e LangChain.
- Prova la sintesi dei documenti con l'IA generativa.
- Leggi informazioni sulla Retrieval Augmented Generation per le attività di NLP che richiedono conoscenze.
- Leggi informazioni sulla generazione basata sul recupero per i modelli linguistici di grandi dimensioni.
- Per altre architetture di riferimento, diagrammi e best practice, visita il Cloud Architecture Center.
Collaboratori
Autore: Kumar Dhanagopal | Sviluppatore di soluzioni cross-product
Altri collaboratori:
- Andrew Brook | Engineering Director
- Anna Berenberg | Engineering Fellow
- Assaf Namer | Principal Cloud Security Architect
- Balachandar Krishnamoorthy | Principal Software Engineer
- Daniel Lees | Cloud Security Architect
- Derek Downey | Developer Relations Engineer
- Eran Lewis | Senior Product Manager
- Geoffrey Anderson | Product Manager
- Gleb Otochkin | Cloud Advocate, database
- Hamsa Buvaraghan | Product Manager IA
- Irina Sigler | Product Manager
- Jack Wotherspoon | Software Engineer
- Jason Davenport | Developer Advocate
- Jordan Totten | Customer Engineer
- Julia Wiesinger | Product Manager
- Kara Greenfield | Customer Engineer
- Kurtis Van Gent | Staff Software Engineer
- Per Jacobsson | Software Engineer
- Pranav Nambiar | Regista
- Richard Hendricks | Staff del Centro di Architettura
- Safiuddin Khaja | Cloud Engineer
- Sandy Ghai | Group Product Manager
- Vladimir Vuskovic | Director of Product Management
- Steren Giannini | Group Product Manager
- Wietse Venema | Ingegnere delle relazioni con gli sviluppatori