Questo documento fornisce un'architettura di riferimento che puoi utilizzare per progettare l'infrastruttura per l'esecuzione di un'applicazione di intelligenza artificiale generativa (AI) con generazione avanzata di recupero (RAG). Il pubblico di destinazione di questo documento include sviluppatori e amministratori di applicazioni diAIA 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'applicazione di AI generativa.
Architettura
Il seguente diagramma mostra una vista generale di un'architettura per un'applicazione di AI generativa con funzionalità 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 di database. |
| Sottosistema di pubblicazione | Gestire il flusso 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 di 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 di database. |
| Database | Archivia i seguenti dati:
|
Tutti i sottosistemi dell'architettura interagiscono con i database. |
Il seguente diagramma mostra una visualizzazione 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 streaming. I dati caricati includono richieste di 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 del 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 l'elaborazione dei dati caricati.
- Cloud Run avvia il job utilizzando 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 divisione in blocchi.
Il job Cloud Run utilizza il modello Vertex AI Embeddings for Text 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 pubblicazione elabora le richieste degli utenti, utilizza gli incorporamenti nel database vettoriale per recuperare dati pertinenti specifici del dominio.
Sottosistema di pubblicazione
Il sottosistema di pubblicazione gestisce il flusso richiesta-risposta tra l'applicazione diAIA 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 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 consente di trovare gli incorporamenti in base all'intento di un prompt anziché ai suoi contenuti testuali.
- L'applicazione combina la richiesta originale con i dati non elaborati raccolti in base all'incorporamento corrispondente per creare una richiesta contestualizzata.
L'applicazione invia il prompt contestualizzato a uno stack di inferenza LLM in esecuzione su Vertex AI.
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.
- L'applicazione può archiviare i log dell'attività richiesta-risposta in Cloud Logging. Puoi visualizzare e utilizzare i log per il monitoraggio tramite Cloud Monitoring. Google non accede ai dati dei log e non li utilizza.
- L'applicazione carica le risposte in BigQuery per le analisi offline.
L'applicazione filtra le risposte utilizzando filtri dell'IA responsabile.
L'applicazione invia le risposte filtrate agli utenti attraverso 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, effettua le seguenti operazioni:
- Pub/Sub attiva un job Cloud Run.
- Cloud Run avvia il job utilizzando 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 precedentemente 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 gestione.
L'output di questa valutazione è costituito dai punteggi di valutazione per metriche come l'accuratezza oggettiva e la pertinenza.
Cloud Run carica in BigQuery i punteggi di valutazione, nonché i prompt e le risposte valutati per analisi future.
Prodotti utilizzati
Di seguito è riportato un riepilogo di tutti i prodotti Google Cloud utilizzati nell'architettura precedente:
- Vertex AI: una piattaforma ML che consente di addestrare ed eseguire il deployment di modelli ML e applicazioni IA, nonché di personalizzare gli LLM per l'utilizzo nelle applicazioni basate su IA.
- Cloud Run: una piattaforma di serverless computing 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 a basso costo e senza limitazioni per tipi di dati diversi. I dati sono accessibili dall'interno e dall'esterno di Google Cloud e sono replicati tra località per 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 recupera 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à di applicazioni e 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 applicazioniAIA generativa con funzionalità RAG.
Suggerimenti personalizzati sui prodotti
Un sito di shopping online potrebbe utilizzare un chatbot LLM per aiutare i clienti a trovare prodotti o a ricevere assistenza in merito agli acquisti. Le domande di un utente possono essere migliorate utilizzando i dati storici sul comportamento di acquisto dell'utente e sui modelli di interazione sul sito web. I dati potrebbero includere recensioni e feedback degli utenti archiviati in un datastore non strutturato o metriche relative alla ricerca archiviate in un data warehouse di 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 convincenti.
Sistemi di assistenza clinica
I medici negli ospedali devono analizzare e diagnosticare rapidamente la condizione di salute di un paziente per prendere decisioni sulle cure e sui farmaci appropriati. Un'applicazione di AI generativa che utilizza un LLM medico come Med-PaLM può essere utilizzata per assistere i medici nel processo di diagnosi clinica. Le risposte generate dall'applicazione possono basarsi su cartelle cliniche storiche dei pazienti, contestualizzando le richieste dei medici con i dati del database delle cartelle cliniche elettroniche (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 di giurisdizioni per identificare precedenti giuridici pertinenti o riassumere concetti legali complessi. I risultati di questa ricerca possono essere migliorati potenziando le richieste di un avvocato con dati recuperati dal corpus di contratti di proprietà dello studio legale, dalle comunicazioni legali passate e dai registri interni dei casi. Questo approccio di progettazione garantisce che le risposte generate siano pertinenti per il dominio legale in cui l'avvocato è specializzato.
Note sul layout
Questa sezione fornisce indicazioni per aiutarti a sviluppare in Google Cloud un'architettura di AI generativa compatibile con RAG 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à Google Cloud che utilizzi, potresti dover prendere in considerazione ulteriori fattori di progettazione e compromessi.
Sicurezza e conformità
Questa sezione descrive i fattori da considerare quando progetti e crei un'applicazione di AI generativa con funzionalità 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 di rete e trasparenza degli accessi. Per maggiori 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à e gestita da Google. Per proteggere i tuoi container utilizzando una chiave controllata da te, puoi utilizzare chiavi di crittografia gestite dal cliente (CMEK). Per maggiori informazioni, consulta Utilizzare le 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 vengono criptati utilizzando chiavi di proprietà e gestite da Google. Se hai bisogno di utilizzare chiavi di crittografia controllate e gestite da te, puoi utilizzare CMEK. Per saperne di più, 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 alle connessioni basata su Identity and Access Management (IAM) e utilizza una connessione TLS 1.3 con crittografia AES a 256 bit per verificare le identità client e server e criptare il traffico dei dati. Per maggiori informazioni, consulta Informazioni sul proxy di autenticazione AlloyDB per PostgreSQL. Per le connessioni create utilizzando Java, Python o Go, utilizza il connettore di lingua 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à per controllare l'accesso ai dati, proteggere i dati sensibili e garantire accuratezza e 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 da te 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 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 tuoi bucket e ai tuoi oggetti: IAM ed elenchi di controllo dell'accesso (ACL). Nella maggior parte dei casi, consigliamo di utilizzare IAM, che consente di concedere le autorizzazioni a livello di bucket e di 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 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 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 di CMEK per la 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 vengono criptati mediante chiavi di crittografia gestite da Google. Se hai bisogno di utilizzare chiavi di crittografia controllate e gestite da te, puoi utilizzare 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 oppure le richieste degli utenti per 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 specificata. Per maggiori informazioni, consulta Regionalizzare i log. |
Per indicazioni generali sui principi di sicurezza da considerare per le applicazioni dell'IA, consulta Introduzione al framework Secure AI di Google.
Affidabilità
Questa sezione descrive i fattori di progettazione che devi prendere in considerazione per creare e gestire un'infrastruttura affidabile per un'applicazione di AI generativa con funzionalità 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 bilanciato automaticamente con il bilanciamento 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, i job Cloud Run si interrompono finché Google non risolve l'interruzione. I singoli job o attività Cloud Run potrebbero non riuscire. Per gestire questi errori, puoi utilizzare i nuovi tentativi delle attività e i checkpoint. Per maggiori informazioni, consulta Best practice per nuovi tentativi di job e checkpoint. |
| AlloyDB per PostgreSQL |
Per impostazione predefinita, i cluster AlloyDB per PostgreSQL forniscono alta disponibilità (HA) con failover automatico. L'istanza principale dispone di nodi ridondanti che si trovano in due zone diverse all'interno di una regione. Questa ridondanza assicura che i cluster siano robusti contro le interruzioni delle zone. Per pianificare il ripristino da interruzioni delle regioni, puoi utilizzare la replica tra regioni. |
| BigQuery |
I dati caricati in BigQuery vengono archiviati in modo sincrono in due zone all'interno della regione da te specificata. Questa ridondanza aiuta a garantire che i dati non vadano persi quando si verifica un'interruzione della zona. Per saperne di più sulle funzionalità di affidabilità in BigQuery, consulta Informazioni sull'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 in più zone all'interno di una regione. Per una maggiore disponibilità, puoi utilizzare bucket a due o più regioni, in cui 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 dell'editore. Per gestire le pubblicazioni non riuscite, modifica le variabili di richiesta di nuovo tentativo in base alle esigenze. Per maggiori informazioni, vedi Riprovare le richieste. |
| Document AI | Document AI è un servizio a livello di regione I dati vengono archiviati in modo sincrono in più zone all'interno di una regione. Il traffico viene bilanciato automaticamente con il bilanciamento del carico tra le zone. In caso di interruzione di una zona, i dati non andranno persi. In caso di interruzione di una regione, Document AI non sarà disponibile finché Google non risolverà 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 con funzionalità 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 di CPU e memoria predefinite (minime). 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 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à. 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 trasformando l'istanza principale del cluster come istanza di base. Un'istanza di base non è efficace in caso di interruzioni delle zone 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 ottenendo sconti per impegno di utilizzo. 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 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 Gestione del ciclo di vita degli oggetti per controllare i costi di archiviazione eseguendo il downgrade automatico degli oggetti a una classe di archiviazione con costi inferiori o eliminando gli oggetti in base alle condizioni impostate. |
| Cloud Logging |
Per controllare il costo dell'archiviazione dei log, puoi:
|
Prestazioni
Questa sezione descrive i fattori da considerare quando progetti e crei un'applicazione di AI generativa con funzionalità 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 sono 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 saperne di più, consulta la panoramica di Query Insights. Per una panoramica dello stato e delle prestazioni dei tuoi database e per visualizzare metriche dettagliate come i picchi di connessioni e il tempo di replica massimo, puoi utilizzare la dashboard di System Insights. Per maggiori informazioni, consulta Monitorare un'istanza utilizzando la dashboard AlloyDB per PostgreSQL di System Insights. Per ridurre il carico sull'istanza AlloyDB per PostgreSQL principale e fare lo scale out della capacità di gestione delle richieste di lettura, puoi aggiungere istanze del pool di lettura al cluster. Per maggiori informazioni, consulta 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 insight sulle prestazioni per problemi come la contesa degli slot e la quota di shuffling insufficiente. Per maggiori informazioni, consulta Ottenere gli 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 ulteriori informazioni, consulta Ottimizzare il calcolo delle query. |
| Cloud Storage | Per caricare file di grandi dimensioni, puoi utilizzare un metodo chiamato caricamenti composti paralleli. Con questa strategia, il file di grandi dimensioni viene suddiviso in blocchi. I blocchi vengono caricati in Cloud Storage in parallelo, quindi i dati vengono ricomposti nel cloud. I caricamenti composti paralleli possono essere più rapidi delle normali operazioni di caricamento quando la larghezza di banda e la velocità del disco non sono fattori limitanti. Tuttavia, questa strategia presenta alcune limitazioni e implicazioni in termini di costi. Per saperne di più, consulta Caricamenti composti paralleli. |
Deployment
Per iniziare e sperimentare la creazione di un'infrastruttura su Google Cloud per applicazioni di AI generativa con funzionalità RAG, puoi utilizzare Soluzione di avvio rapido: RAG per l'IA generativa con Cloud SQL. Questa soluzione esegue il deployment di un'applicazione di chat basata su Python in 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 di AI generativa di livello enterprise con i database Google Cloud.
- Scopri come la nuova app di recupero dei database GenAI aiuta a migliorare le risposte LLM.
- Prova il codelab per creare un'applicazione di chat basata su LLM e RAG utilizzando AlloyDB per l'IA PostgreSQL e LangChain.
- Prova il riepilogo dei documenti di IA generativa.
- Leggi ulteriori informazioni sulla generazione aumentata di recupero per attività NLP ad alta intensità di conoscenza.
- Scopri di più sulla generazione aumentata per il recupero per i modelli linguistici di grandi dimensioni (LLM).
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.
Collaboratori
Autore: Kumar Dhanagopal | Cross-Product Solution Developer
Altri collaboratori:
- Andrew Brook | Direttore tecnico
- Anna Berenberg | Engineering Fellow
- Nome Assaf | Principal Cloud Security Architect
- Balachandar Krishnamoorthy | Principal Software Engineer
- Daniel Lees | Cloud Security Architect
- Derek Downey | Ingegnere per i rapporti con gli sviluppatori
- Geoffrey Anderson | Product Manager
- Gleb Otochkin | Cloud Advocate, database
- Hamsa Buvaraghan | Product Manager dell'IA
- Irina Sigler | Product Manager
- Jack Wotherspoon | Ingegnere informatico
- Jason Davenport | Consulente per gli sviluppatori
- Julia Wiesinger | Product Manager
- Kara Greenfield | Customer Engineer
- Kurtis Van Gent | Ingegnere informatico del personale
- Per Jacobsson | Ingegnere informatico
- Pranav Nambiar | Direttore
- Richard Hendricks | Personale del Centro di architettura
- Safiuddin Khaja | Cloud Engineer
- Vladimir Vuskovic | Product Management Director
- Steren Giannini | Group Product Manager
- Wietse Venema | Ingegnere per le relazioni con gli sviluppatori