Questo documento fornisce un'architettura di riferimento che puoi utilizzare per progettare l'infrastruttura 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 di applicazioni di AI generativa e cloud architect. Il documento presuppone una conoscenza di base dei concetti di AI, machine learning (ML) e modello linguistico di grandi dimensioni (LLM). Questo documento non fornisce indicazioni su come progettare e sviluppare un'applicazioneAIA generativa.
Architettura
Il seguente diagramma mostra una visione generale 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 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 distribuzione interagisce con il sottosistema di importazione dati attraverso 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 gestione e con il sottosistema di importazione dati tramite il livello del database. |
| Database | Archivia i seguenti dati:
|
Tutti i sottosistemi dell'architettura interagiscono con i database. |
Il seguente diagramma mostra una vista dettagliata dell'architettura:
Le seguenti sezioni 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 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 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 dati:
- I dati sono caricati su un bucket Cloud Storage. L'origine dati può essere un utente dell'applicazione che esegue un caricamento, un'importazione di database o un flusso 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 usando i dati di configurazione archiviati in un database AlloyDB per PostgreSQL.
- Il job Cloud Run usa Document AI per preparare i dati per l'ulteriore elaborazione. Ad esempio, la preparazione può includere l'analisi dei dati, la loro conversione nel formato richiesto e la suddivisione dei dati in blocchi.
Il job Cloud Run utilizza il modello Vertex AI Embeddings per il testo per creare incorporamenti vettoriali dei dati importati.
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 gestione 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 gestione 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 gestione nell'architettura:
Di seguito sono riportati i passaggi del flusso richiesta-risposta nel sottosistema di pubblicazione:
- Gli utenti inviano le 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 incorporamenti.
L'applicazione completa la parte di recupero dell'approccio RAG:
- L'applicazione esegue una ricerca semantica per l'incorporamento nell'archivio vettoriale di AlloyDB per PostgreSQL gestito dal sottosistema di importazione dei dati. La ricerca semantica aiuta a trovare gli incorporamenti in base all'intento di un prompt anziché al contenuto testuale.
- L'applicazione combina la richiesta originale con i dati non elaborati recuperati in base all'incorporamento corrispondente per creare un prompt contestualizzato.
L'applicazione invia il prompt contestualizzato a uno stack di inferenza LLM eseguito su Vertex AI.
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.
- L'applicazione può archiviare i log dell'attività richiesta-risposta in Cloud Logging. Puoi visualizzare e utilizzare i log per il monitoraggio con Cloud Monitoring. Google non accede ai dati dei log e non li utilizza.
- L'applicazione carica le risposte in BigQuery per l'analisi offline.
L'applicazione filtra le risposte utilizzando filtri di AI responsabile.
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:
Quando il sottosistema di valutazione della qualità riceve una richiesta, procede nel seguente modo:
- Pub/Sub attiva un job Cloud Run.
- Cloud Run avvia il job usando i dati di configurazione archiviati in un database AlloyDB per PostgreSQL.
- 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 sottosistema di importazione dati.
Il job Cloud Run utilizza i prompt di valutazione per valutare la qualità delle risposte generate dal sottosistema di gestione.
L'output di questa valutazione è costituito dai punteggi di valutazione per metriche come l'accuratezza dei fatti e la pertinenza.
Cloud Run carica i punteggi di valutazione, nonché i prompt e le risposte che sono stati valutati in BigQuery per le 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 consente di addestrare ed eseguire il deployment di modelli ML e applicazioni di IA, nonché di personalizzare gli LLM per l'utilizzo nelle applicazioni basate sull'IA.
- Cloud Run: una piattaforma di computing serverless che consente di eseguire i container direttamente sull'infrastruttura scalabile di Google.
- BigQuery: un data warehouse aziendale che ti aiuta a gestire e analizzare i tuoi dati con funzionalità integrate come l'analisi geospaziale di machine learning e la 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 e sono 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 di documenti che prende i 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 dai servizi 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 dell'infrastruttura.
Casi d'uso
RAG è una tecnica efficace per migliorare la qualità dell'output generato da un LLM. Questa sezione fornisce esempi di casi d'uso per cui puoi usare applicazioni di AI generativa con funzionalità RAG.
Suggerimenti personalizzati sui prodotti
Un sito di shopping online potrebbe utilizzare un chatbot basato su LLM per assistere i clienti nel trovare prodotti o ricevere assistenza per gli acquisti. Le domande di un utente possono essere ampliate utilizzando dati storici sul comportamento di acquisto dell'utente e sui modelli di interazione sul sito web. I dati possono includere recensioni e feedback degli utenti archiviati in un datastore non strutturato o metriche relative alla ricerca archiviate in un data warehouse per l'analisi dei dati web. La domanda aumentata può quindi essere elaborata dall'LLM per generare risposte personalizzate che l'utente potrebbe trovare più accattivanti e interessanti.
Sistemi di assistenza clinica
I medici negli ospedali devono analizzare e diagnosticare rapidamente le condizioni di salute di un paziente per prendere decisioni relative 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 nel loro processo di diagnosi clinica. Le risposte generate dall'applicazione possono essere basate sui dati storici dei pazienti, contestualizzando le richieste dei medici con i dati provenienti dal database della documentazione sanitaria elettronica (EHR) dell'ospedale o da una knowledge base esterna come PubMed.
Ricerca legale efficiente
La ricerca legale basata sull'IA generativa consente agli avvocati di interrogare rapidamente grandi volumi di statuti e giurisprudenza per identificare precedenti legali pertinenti o riassumere concetti legali complessi. Il risultato di queste ricerche può essere migliorato aumentando le richieste di un avvocato con dati recuperati dal corpus proprietario dello studio legale, dalle comunicazioni legali passate e dagli atti interni. Questo approccio di progettazione garantisce che le risposte generate siano pertinenti per l'ambito legale in cui l'avvocato è specializzato.
Alternativa di progettazione
Per i componenti di archiviazione vettoriale e ricerca semantica nell'architettura, puoi utilizzare Vertex AI Vector Search. Vector Search è un servizio completamente gestito che fornisce un'infrastruttura di distribuzione ottimizzata per la ricerca vettoriale su larga scala. I dati non elaborati (blocchi di testo) possono essere archiviati in archivi di oggetti come Cloud Storage o in archivi chiave-valore come Filestore. In entrambi i casi, la rappresentazione vettoriale 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 che viene utilizzato come nome file dell'oggetto in Cloud Storage. Viene utilizzato lo stesso ID per l'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 i vettori più semanticamente simili. Gli ID vettoriali vengono quindi utilizzati per cercare i blocchi di testo originali. Collettivamente, questi blocchi di testo forniscono il contesto pertinente necessario all'LLM per completare una determinata attività.
Per informazioni su come creare, eseguire il deployment ed eseguire query su un indice di ricerca vettoriale, consulta la guida rapida di Vector Search.
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 di sicurezza e conformità, affidabilità, costi e prestazioni. Le indicazioni in questa sezione non sono esaustive. A seconda dei requisiti specifici della tua applicazione di AI generativa e dei prodotti e delle 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 da considerare quando progetti e crei 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 requisiti di residenza dei dati, crittografia dei dati, sicurezza della rete e trasparenza degli accessi. Per maggiori informazioni, consulta Controlli di sicurezza per Vertex AI e Controlli di sicurezza per AI 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 container mediante una chiave che tu controlli, puoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK). Per maggiori informazioni, consulta Utilizzo delle chiavi di crittografia gestite dal cliente. Per assicurarti che venga eseguito il deployment nei job Cloud Run solo delle immagini container autorizzate, 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 selezionata. |
| AlloyDB per PostgreSQL |
Per impostazione predefinita, i dati archiviati in AlloyDB per PostgreSQL sono criptati utilizzando chiavi di proprietà di Google e gestite da Google. Se hai bisogno di utilizzare chiavi di crittografia che puoi controllare e gestire, puoi utilizzare le CMEK. Per maggiori informazioni, consulta 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 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 alla 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 maggiori informazioni, consulta Informazioni sul proxy di autenticazione AlloyDB per PostgreSQL. Per le connessioni create tramite Java, Python o Go, utilizza il Connettore di linguaggio appropriato 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 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 maggiori informazioni, consulta 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 criptati utilizzando chiavi di proprietà e gestite da Google. Se necessario, puoi utilizzare le 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, consigliamo di utilizzare IAM, che consente di concedere autorizzazioni a livello di bucket e progetto. Per maggiori 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 Sensitive Data Protection per scoprire, classificare e anonimizzare i dati. Per maggiori informazioni, consulta Utilizzare 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 specificate. |
| Pub/Sub |
Per impostazione predefinita, Pub/Sub cripta tutti i messaggi, sia at-rest che in transito, utilizzando chiavi di proprietà di Google e gestite da Google. Pub/Sub supporta l'uso di CMEK per crittografia dei messaggi a livello di applicazione. Per maggiori informazioni, consulta Configurare la crittografia dei messaggi. Se hai requisiti di residenza dei dati, per assicurarti che i dati dei messaggi siano archiviati in località specifiche, puoi configurare i criteri di archiviazione dei messaggi. |
| Document AI | Per impostazione predefinita, i dati at-rest sono criptati mediante chiavi di crittografia gestite da Google. Se hai bisogno di utilizzare chiavi di crittografia che puoi controllare e gestire, puoi utilizzare le CMEK. Per maggiori 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 audit log di accesso ai dati sono abilitati per impostazione predefinita per BigQuery. Per gli altri servizi utilizzati in questa architettura, puoi abilitare gli audit log di accesso ai dati. I log 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 dagli utenti. Per soddisfare i requisiti di residenza dei dati, puoi configurare Cloud Logging per archiviare i dati di log nella regione specificata. Per maggiori informazioni, consulta Regionalizzare i log. |
Per linee guida generali sui principi di sicurezza da considerare per le applicazioni di IA, consulta Introduzione al Secure AI Framework di Google.
Affidabilità
Questa sezione descrive i fattori di progettazione che dovresti prendere in considerazione per creare e utilizzare 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 in più zone all'interno di una regione. Il traffico viene automaticamente bilanciato del carico tra le zone. In caso di interruzione di una zona, i job Cloud Run continuano a essere eseguiti e i dati non vengono persi. In caso di interruzione di una regione, l'esecuzione dei job Cloud Run viene interrotta fino a quando Google non risolve l'interruzione. I singoli job o attività Cloud Run potrebbero non riuscire. Per gestire questi errori, puoi utilizzare i nuovi tentativi di attività e dei checkpoint. Per saperne di più, consulta Best practice per i nuovi tentativi di job e i punti di controllo. |
| AlloyDB per PostgreSQL |
Per impostazione predefinita, i cluster AlloyDB per PostgreSQL offrono disponibilità elevata (HA) con failover automatico. L'istanza principale ha nodi ridondanti che si trovano in due zone diverse all'interno di una regione. Questa ridondanza garantisce la robustezza dei cluster contro le interruzioni delle zone. Per pianificare il recupero da interruzioni del servizio per regione, 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 garantisce che i dati non vadano persi in caso di interruzione del servizio in una zona. Per saperne di più sulle funzionalità di affidabilità in BigQuery, consulta Comprendere l'affidabilità. |
| Cloud Storage | Puoi creare bucket Cloud Storage in uno dei tre tipi di località: a livello di regione, a due regioni o a più regioni. I dati archiviati nei bucket a livello di regione vengono replicati in modo sincrono tra più zone all'interno di una regione. Per una maggiore disponibilità, puoi utilizzare bucket a due o più regioni, dove i dati vengono replicati in modo asincrono tra le regioni. |
| Pub/Sub |
Per gestire i 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 di richiesta di nuovo tentativo in base alle necessità. Per maggiori informazioni, consulta 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 automaticamente bilanciato del carico tra le zone. In caso di interruzione di una zona, i dati non vengono persi. In caso di interruzione di una regione, Document AI non sarà disponibile finché Google non risolve l'interruzione. |
Ottimizzazione dei costi
Questa sezione fornisce indicazioni per aiutarti a ottimizzare i costi 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 di 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 puoi prevedere i requisiti di CPU e memoria dei tuoi job Cloud Run, puoi risparmiare denaro ottenendo sconti per l'impegno di utilizzo. Per maggiori 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 è ad alta disponibilità (HA). L'istanza ha un nodo attivo e un nodo in standby. In caso di errore del nodo attivo, AlloyDB per PostgreSQL esegue automaticamente il failover sul nodo in standby. Se non hai bisogno dell'alta disponibilità 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 puoi prevedere i requisiti di CPU e memoria della tua istanza AlloyDB per PostgreSQL, puoi risparmiare denaro ottenendo sconti per l'utilizzo impegnato. Per maggiori informazioni, consulta Sconti per impegno di utilizzo di AlloyDB per PostgreSQL. |
| BigQuery | BigQuery 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 maggiori informazioni, consulta Stima e controllo dei 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 dell'accesso dei tuoi carichi di lavoro. Ad esempio, puoi scegliere la classe di archiviazione Standard e utilizzare Gestione del ciclo di vita degli oggetti per controllare i costi di archiviazione eseguendo automaticamente il downgrade degli oggetti a una classe di archiviazione di costo inferiore o eliminando gli oggetti in base alle condizioni impostate. |
| Cloud Logging |
Per controllare i costi di archiviazione dei log, puoi procedere come segue:
|
Prestazioni
Questa sezione descrive i fattori da considerare quando progetti e crei 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 vengono allocati 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 tracciare l'origine di una query problematica. Per maggiori informazioni, consulta Panoramica di Query Insights. Per una panoramica dello stato e delle prestazioni dei tuoi database e per visualizzare metriche dettagliate come il picco di connessioni e il ritardo di replica massimo, puoi utilizzare la dashboard di System Insights. Per maggiori informazioni, consulta Monitorare un'istanza utilizzando la dashboard degli insight di sistema di AlloyDB per PostgreSQL. Per ridurre il carico sull'istanza AlloyDB per PostgreSQL principale e fare lo scale out della capacità per gestire le richieste di lettura, puoi aggiungere istanze del pool di lettura al cluster. Per maggiori informazioni, 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 insight sulle prestazioni per problemi come la contesa degli slot e la quota di shuffle insufficiente. Per maggiori informazioni, consulta Ottieni insight sulle prestazioni delle query. Dopo aver risolto i problemi identificati tramite gli insight sulle prestazioni delle query, puoi ottimizzare ulteriormente le query utilizzando tecniche come la riduzione del volume dei dati di input e di 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 blocchi vengono caricati in Cloud Storage in parallelo e quindi 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 limitano i fattori. Tuttavia, questa strategia presenta alcune limitazioni e implicazioni in termini di costi. Per maggiori informazioni, consulta Caricamenti compositi paralleli. |
Deployment
Per iniziare e sperimentare la creazione di un'infrastruttura su Google Cloud per applicazioni di IA generativa compatibili con RAG, puoi utilizzare Jump Start Solution: Generative AI RAG with 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 in GitHub.
Passaggi successivi
- Scopri come creare applicazioni di IA generativa con l'API Vertex AI PaLM e LangChain.
- Scopri come creare app aziendali di AI generativa con i database Google Cloud.
- Scopri come la nuova app di recupero database di IA generativa aiuta a migliorare le risposte LLM.
- Prova il codelab per creare un'applicazione di chat basata su LLM e RAG utilizzando AlloyDB per PostgreSQL AI e LangChain.
- Prova il riassunto dei documenti con l'IA generativa.
- Scopri di più sulla generazione aumentata per il recupero per attività NLP ad alta intensità di conoscenza.
- Scopri di più sulla generazione aumentata del recupero per i modelli linguistici di grandi dimensioni.
- Per altre architetture di riferimento, diagrammi e best practice, esplora 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 | Consulente cloud, database
- Hamsa Buvaraghan | Product manager IA
- Irina Sigler | Product Manager
- Jack Wotherspoon | Ingegnere informatico
- Jason Davenport | Consulente per gli sviluppatori
- 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 | Personale del Centro di architettura
- Safiuddin Khaja | Cloud Engineer
- Sandy Ghai | Group Product Manager
- Vladimir Vuskovic | Product Management Director
- Steren Giannini | Group Product Manager
- Wietse Venema | Developer Relations Engineer