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

Last reviewed 2024-04-02 UTC

Questo documento fornisce un'architettura di riferimento che puoi utilizzare per progettare l'infrastruttura per eseguire un'applicazione di AI generativa con la ricerca RAG (Retrieval Augmented Generation) utilizzando Google Kubernetes Engine (GKE), Cloud SQL e strumenti open source come Ray, Hugging Face e LangChain. Per aiutarti a eseguire esperimenti con questa architettura di riferimento, in GitHub sono disponibili un'applicazione di esempio e una configurazione Terraform.

Questo documento è rivolto agli sviluppatori che vogliono creare ed eseguire rapidamente il deployment di applicazioni di AI generativa compatibili con RAG utilizzando modelli e strumenti open source. Si presume che tu abbia esperienza nell'utilizzo di GKE e Cloud SQL e che tu abbia una conoscenza concettuale 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:

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

L'architettura contiene un sottosistema di pubblicazione e un sottosistema di incorporamento.

  • Il sottosistema di pubblicazione gestisce il flusso di richiesta-risposta tra l'applicazione e i suoi utenti. Il sottosistema include un server frontend, un server di inferenza e un servizio di AI responsabile (RAI). Il sottosistema di pubblicazione interagisce con il sottosistema di incorporamento tramite un database di vettori.
  • Il sottosistema di embedding attiva la funzionalità RAG nell'architettura. Questo sottosistema esegue le seguenti operazioni:
    • Importa i dati dalle origini dati in Google Cloud, on-premise e altre piattaforme cloud.
    • Converte i dati importati in embedding vettoriali.
    • Memorizza gli embedding in un database vettoriale.

Il seguente diagramma mostra una visualizzazione dettagliata dell'architettura:

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

Come mostrato nel diagramma precedente, il server frontend, il server di inferenza e il servizio di embedding vengono dipiazzati in un cluster GKE regionale in modalità Autopilot. I dati per la RAG vengono importati tramite un bucket Cloud Storage. L'architettura utilizza un'istanza Cloud SQL per PostgreSQL con l'estensione pgvector come database vettoriale per archiviare gli incorporamenti ed eseguire ricerche semantiche. I database vettoriali sono progettati per archiviare e recuperare in modo efficiente vettori ad alta dimensione.

Le sezioni seguenti descrivono i componenti e il flusso di dati all'interno di ogni subsistema dell'architettura.

Sottosistema di embedding

Di seguito è riportato il flusso di dati nel sottosistema di embedding:

  1. I dati provenienti da origini esterne e interne vengono caricati nel bucket Cloud Storage da utenti umani o in modo programmatico. I dati caricati possono trovarsi in file, database o flussi di dati.
  2. (non mostrato nel diagramma dell'architettura). L'attività di caricamento dei dati attiva un evento che viene pubblicato in un servizio di messaggistica come Pub/Sub. Il servizio di messaggistica invia una notifica al servizio di incorporamento.
  3. Quando il servizio di incorporamento riceve una notifica di un evento di caricamento dei dati, esegue le seguenti operazioni:
    1. Recupera i dati dal bucket Cloud Storage tramite il driver CSI di Cloud Storage FUSE.
    2. Legge i dati caricati e li pre-elabora utilizzando Ray Data. La preelaborazione può includere l'organizzazione dei dati in blocchi e la loro trasformazione in un formato adatto alla generazione di embedding.
    3. Esegue un job Ray per creare embedding vettorializzati dei dati pre-elaborati utilizzando un modello open source come intfloat/multilingual-e5-small che è dipiegato nello stesso cluster.
    4. Scrive gli embedding vettorizzati nel database vettoriale Cloud SQL per PostgreSQL.

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

Di seguito è riportato il flusso di richiesta-risposta nel sottosistema di pubblicazione:

  1. Un utente invia una richiesta in linguaggio naturale a un server frontend tramite un'interfaccia di chat basata su web. Il server frontend viene eseguito su GKE.
  2. Il server frontend esegue un processo LangChain che svolge le seguenti operazioni:
    1. Converte la richiesta in linguaggio naturale in incorporamenti utilizzando lo stesso modello e gli stessi parametri utilizzati dal servizio di incorporamento.
    2. Recupera i dati pertinenti per il grounding eseguendo una ricerca semantica degli embedding nel database vettoriale. La ricerca semantica consente di trovare embedding in base all'intenzione di un prompt anziché ai suoi contenuti testuali.
    3. Costruisce un prompt contestualizzato combinando la richiesta originale con i dati di ancoraggio recuperati.
    4. Invia il prompt contestualizzato al server di inferenza, che gira su GKE.
  3. Il server di inferenza utilizza il framework di pubblicazione Hugging Face TGI per pubblicare un LLM open source come Mistral-7B-Instruct o un modello Gemma open.

  4. L'LLM genera una risposta al prompt e il server di inferenza invia la risposta al server frontend.

    Puoi archiviare e visualizzare i log dell'attività di richiesta/risposta in Cloud Logging e configurare il monitoraggio basato sui log utilizzando Cloud Monitoring. Puoi anche caricare le risposte generate in BigQuery per l'analisi offline.

  5. Il server frontend richiama un servizio RAI per applicare i filtri di sicurezza obbligatori alla risposta. Puoi utilizzare strumenti come Sensitive Data Protection e API Cloud Natural Language per scoprire, filtrare, classificare e anonimizzare i contenuti sensibili nelle risposte.

  6. Il server frontend invia la risposta filtrata all'utente.

Prodotti utilizzati

Di seguito è riportato un riepilogo dei prodotti Google Cloud e open source utilizzati dall'architettura precedente:

Prodotti Google Cloud

  • Google Kubernetes Engine (GKE): un servizio Kubernetes che puoi utilizzare per eseguire il deployment e gestire applicazioni containerizzate su larga scala utilizzando l'infrastruttura di Google.
  • 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.
  • Cloud SQL: un servizio di database relazionale completamente gestito che ti aiuta a eseguire il provisioning, a utilizzare e a gestire i tuoi database MySQL, PostgreSQL e SQL Server su Google Cloud.

Prodotti open source

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.

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.

Note sul layout

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

Per indicazioni di progettazione relative agli strumenti open source in questa architettura di riferimento, come TGI di Hugging Face, consulta la documentazione di questi strumenti.

Sicurezza, privacy 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 requisiti di sicurezza, privacy e conformità.

Prodotto Note sul layout
GKE

Nella modalità di funzionamento Autopilot, GKE preconfigura il cluster e gestisce i nodi in base alle best practice di sicurezza, in modo da consentirti di concentrarti sulla sicurezza specifica del carico di lavoro. Per ulteriori informazioni, consulta le seguenti risorse:

Per garantire un controllo dell'accesso avanzato per le applicazioni in esecuzione in GKE, puoi utilizzare Identity-Aware Proxy (IAP). IAP si integra con la risorsa GKE Ingress e garantisce che solo gli utenti autenticati con il ruolo IAM (Identity and Access Management) corretto possano accedere alle applicazioni. Per maggiori informazioni, consulta Abilitare IAP per GKE.

Per impostazione predefinita, i dati in GKE vengono criptati at-rest e in transito utilizzando chiavi di proprietà di Google e gestite da Google. Come ulteriore livello di sicurezza per i dati sensibili, puoi criptare i dati a livello di applicazione utilizzando una chiave di tua proprietà e gestita con Cloud KMS. Per ulteriori informazioni, consulta Crittografia dei secret a livello di applicazione.

Se utilizzi un cluster GKE Standard, puoi utilizzare le seguenti funzionalità aggiuntive di crittografia dei dati:

Cloud SQL

L'istanza Cloud SQL nell'architettura non deve essere accessibile dalla rete internet pubblica. Se è necessario l'accesso esterno all'istanza Cloud SQL, puoi criptare le connessioni esterne utilizzando SSL/TLS o il connettore Proxy di autenticazione Cloud SQL. Il connettore Auth Proxy fornisce l'autorizzazione di connessione utilizzando IAM. Il connettore 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 le connessioni create utilizzando Java, Python, Go o Node.js, utilizza il connettore di lingua appropriato anziché il connettore Auth Proxy.

Per impostazione predefinita, Cloud SQL utilizza chiavi di crittografia dei dati (DEK) e chiavi di crittografia della chiave (KEK) di proprietà e gestite da Google per criptare i dati at-rest. Se devi utilizzare chiavi KEK che controlli e gestisci, puoi utilizzare chiavi di crittografia gestite dal cliente (CMEK).

Per impedire l'accesso non autorizzato all'API Cloud SQL Admin, puoi creare un perimetro di servizio utilizzando Controlli di servizio VPC.

Per informazioni sulla configurazione di Cloud SQL per contribuire a soddisfare i requisiti di residenza dei dati, consulta la Panoramica della residenza dei dati.

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 controllare l'accesso degli utenti 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.

Per mitigare il rischio di esfiltrazione di dati da Cloud Storage, puoi creare un perimetro di servizio utilizzando Controlli di servizio VPC.

Cloud Storage ti aiuta a soddisfare i requisiti di residenza dei dati. I dati vengono archiviati o replicati nelle regioni che hai specificato.

Tutti i prodotti di questa architettura

Gli audit log delle attività di amministrazione sono abilitati per impostazione predefinita per tutti i servizi Google Cloud utilizzati in questa architettura di riferimento. Puoi accedere ai log tramite Cloud Logging e utilizzarli per monitorare le chiamate API o altre azioni che modificano la configurazione o i metadati delle risorse Google Cloud.

Anche gli audit log di accesso ai dati sono abilitati per impostazione predefinita per tutti i servizi Google Cloud di questa architettura. Puoi utilizzare questi log per monitorare quanto segue:

  • Chiamate API che leggono la configurazione o i metadati delle risorse.
  • Richieste dell'utente di creare, modificare o leggere i dati delle risorse forniti dall'utente.

Per indicazioni generali sui principi di sicurezza da prendere in considerazione per le applicazioni di IA, consulta 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
GKE

Con la modalità operativa Autopilot utilizzata in questa l'architettura, GKE fornisce le seguenti funzionalità di affidabilità integrate:

  • Il tuo carico di lavoro utilizza un cluster GKE a livello di regione. Il piano di controllo e i nodi worker sono distribuiti su tre zone diverse all'interno di una regione. I tuoi carichi di lavoro sono resistenti alle interruzioni delle zone. I cluster GKE a livello di regione hanno un tempo di attività superiore SLA rispetto ai cluster zonali.
  • Non è necessario creare nodi o gestire pool di nodi. GKE crea automaticamente i pool di nodi e li scala in base ai requisiti dei carichi di lavoro.

Per assicurarti che sia disponibile una capacità GPU sufficiente quando necessaria per l'autoscaling del cluster GKE, puoi creare e utilizzare le prenotazioni. Una prenotazione garantisce la capacità in una zona specifica per una risorsa specifica. Una prenotazione può essere specifica per un progetto o condivisa tra più progetti. Ti vengono addebitati costi per le risorse prenotate anche se non viene eseguito il provisioning delle risorse o se non vengono utilizzate. Per ulteriori informazioni, consulta Consumo di risorse di zona prenotate.

Cloud SQL

Per assicurarti che il database di vettori sia robusto contro i guasti del database e le interruzioni della zona, utilizza un'istanza Cloud SQL configurata per l'alta disponibilità. In caso di errore del database principale o di interruzione di una zona, Cloud SQL esegue automaticamente il failover sul database di standby in un'altra zona. Non è necessario modificare l'indirizzo IP per l'endpoint del database.

Per assicurarti che le tue istanze Cloud SQL siano coperte dal Contratto di livello del servizio, segui le linee guida operative consigliate. Ad esempio, assicurati che la CPU e la memoria siano dimensionate correttamente per il carico di lavoro e attiva gli incrementi automatici dello spazio di archiviazione. Per ulteriori informazioni, consulta le linee guida operative.

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

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
GKE

In modalità Autopilot, GKE ottimizza l'efficienza dell'infrastruttura del tuo cluster in base ai requisiti del carico di lavoro. Non è necessario monitorare costantemente l'utilizzo delle risorse o gestire la capacità per controllare i costi.

Se puoi prevedere l'utilizzo di CPU, memoria e spazio di archiviazione temporaneo del tuo cluster GKE Autopilot, puoi risparmiare denaro usufruendo di sconti per l'utilizzo previsto. Per ulteriori informazioni, consulta la pagina relativa agli sconti per impegno di utilizzo di GKE.

Per ridurre il costo di esecuzione dell'applicazione, puoi utilizzare le VM spot per i tuoi nodi GKE. Le VM spot hanno un prezzo inferiore rispetto alle VM standard, ma non forniscono alcuna garanzia di disponibilità. Per informazioni sui vantaggi dei nodi che utilizzano le VM spot, sul loro funzionamento in GKE e su come pianificare i carichi di lavoro su questi nodi, consulta VM spot.

Per ulteriori indicazioni sull'ottimizzazione dei costi, consulta Best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE.

Cloud SQL

Una configurazione ad alta disponibilità (HA) consente di ridurre i tempi di inattività del database Cloud SQL quando la zona o l'istanza non è disponibile. Tuttavia, il costo di un'istanza configurata per l'HA è superiore a quello di un'istanza autonoma. Se non hai bisogno di HA per il database di vettori, puoi ridurre i costi utilizzando un'istanza autonoma, che non è robusta contro le interruzioni di zona.

Puoi rilevare se la tua istanza Cloud SQL è con overprovisioning e ottimizzare la fatturazione utilizzando gli approfondimenti e i consigli sui costi di Cloud SQL basati su Active Assist. Per ulteriori informazioni, consulta Riduci le istanze Cloud SQL con provisioning eccessivo.

Se puoi prevedere i requisiti di CPU e memoria della tua istanza Cloud SQL, puoi risparmiare denaro usufruendo di sconti per l'utilizzo previsto. Per ulteriori informazioni, consulta Sconti per impegno di utilizzo di Cloud SQL.

Cloud Storage Per il bucket Cloud Storage che utilizzi per caricare i dati nel sottosistema di importazione dati, scegli una classe di archiviazione appropriata. Quando scegli la classe di archiviazione, tieni conto dei requisiti di conservazione dei dati e della frequenza di accesso dei tuoi carichi di lavoro. Ad esempio, per controllare i costi di archiviazione, puoi scegliere la classe Standard e utilizzare Gestione del ciclo di vita degli oggetti. In questo modo, viene attivato il downgrade automatico degli oggetti a una classe di archiviazione meno costosa o l'eliminazione degli oggetti in base alle condizioni impostate.

Per stimare il costo delle risorse Google Cloud, utilizza il Calcolatore prezzi di Google Cloud.

Ottimizzazione delle 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
GKE Scegli le classi di calcolo appropriate per i tuoi pod in base ai requisiti di prestazioni dei carichi di lavoro. Per i pod che eseguono il server di inferenza e il servizio di embedding, ti consigliamo di utilizzare un tipo di macchina GPU come nvidia-l4.
Cloud SQL

Per ottimizzare le prestazioni dell'istanza Cloud SQL, assicurati che la CPU e la memoria allocate all'istanza siano adeguate per il carico di lavoro. Per ulteriori informazioni, consulta Ottimizza le istanze Cloud SQL sottodimensionate.

Per migliorare il tempo di risposta per la ricerca vettoriale del vicino più prossimo approssimativo (ANN), utilizza l'indice Inverted File with Flat Compression (IVFFlat) o l'indice Hierarchical Navigable Small World (HNSW)

Per aiutarti ad analizzare e migliorare le prestazioni delle query dei database, Cloud SQL 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 Utilizzare Query Insights per migliorare le prestazioni delle query.

Per avere una panoramica dello stato e del rendimento dei tuoi database e visualizzare metriche dettagliate come picchi di connessioni e utilizzo del disco, puoi utilizzare la dashboard Approfondimenti sul sistema. Per ulteriori informazioni, consulta Utilizzare Approfondimenti di sistema per migliorare il rendimento del sistema.

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. Quando la larghezza di banda della rete e la velocità del disco non sono fattori limitanti, i caricamenti compositi paralleli possono essere più rapidi delle normali operazioni di caricamento. Tuttavia, questa strategia presenta alcune limitazioni e implicazioni in termini di costi. Per saperne di più, consulta Caricamenti compositi paralleli.

Deployment

Per eseguire il deployment di una topologia basata su questa architettura di riferimento, puoi scaricare e utilizzare il codice campione open source disponibile in un repository su GitHub. Il codice campione non è destinato ai casi d'uso di produzione. Puoi utilizzare il codice per sperimentare la configurazione dell'infrastruttura AI per un'applicazione di AI generativa abilitata per RAG.

Il codice di esempio esegue queste operazioni:

  1. Esegui il provisioning di un'istanza Cloud SQL per PostgreSQL da utilizzare come database di vettori.
  2. Esegue il deployment di Ray, JupyterHub e Hugging Face TGI in un cluster GKE specificato.
  3. Esegue il deployment di un'applicazione chatbot basata su web di esempio nel tuo cluster GKE per consentirti di verificare la funzionalità RAG.

Per istruzioni su come utilizzare il codice campione, consulta il README del codice. Se si verificano errori durante l'utilizzo del codice campione e se non esistono problemi GitHub aperti per gli errori, crea i problemi in GitHub.

Il codice campione esegue il deployment di risorse Google Cloud fatturabili. Al termine dell'utilizzo del codice, rimuovi le risorse di cui non hai più bisogno.

Passaggi successivi

Collaboratori

Autore: Kumar Dhanagopal | Sviluppatore di soluzioni cross-product

Altri collaboratori: