Questo documento fornisce un'architettura di riferimento che puoi utilizzare per proteggere l'infrastruttura di rete per applicazioni con Retrieval-Augmented Generation (RAG). Un'architettura RAG in genere contiene sottosistemi separati per gestire i flussi di elaborazione dei dati e recupero dei contenuti. Questa architettura di riferimento mostra come utilizzare il VPC condiviso per:
- Crea una separazione tra i sottosistemi utilizzando le autorizzazioni Identity and Access Management (IAM).
- Collega i componenti dell'applicazione utilizzando indirizzi IP privati.
Il pubblico di destinazione di questo documento include architetti, sviluppatori e amministratori di rete e sicurezza. Il documento presuppone che tu abbia una conoscenza di base del networking. Questo documento non descrive la creazione di un'applicazione basata su RAG.
Architettura
Il seguente diagramma mostra l'architettura di rete presentata in questo documento:
L'architettura nel diagramma precedente mostra i seguenti componenti:
| Componente | Finalità |
|---|---|
| Rete esterna, on-premise o in un altro cloud |
|
| Progetto di routing |
|
| Progetto host VPC condiviso RAG | Ospita una rete VPC condiviso che ospita il bilanciatore del carico del servizio di frontend e qualsiasi altro servizio che necessita di una rete VPC. Tutti i progetti di servizio hanno accesso a questa rete VPC condiviso. |
| Progetto di servizio di importazione dati |
Contiene un bucket Cloud Storage per l'input dei dati non elaborati. Contiene il sottosistema di importazione dati, che include i seguenti componenti:
|
| Progetto di servizio di pubblicazione |
Contiene il sottosistema di pubblicazione, che include i seguenti componenti che forniscono i servizi e le funzioni per l'inferenza e l'interazione:
|
| Progetto di servizio frontend |
Contiene il sottosistema di gestione, che è un bilanciatore del carico davanti a un servizio di interazione con l'utente in esecuzione su Cloud Run o Google Kubernetes Engine (GKE). Il progetto contiene anche Google Cloud Armor, che contribuisce a limitare l'accesso al tuo servizio. Se vuoi fornire l'accesso da internet, puoi aggiungere un bilanciatore del carico delle applicazioni esterno regionale. |
| Perimetro dei controlli di servizio VPC | Aiuta a proteggere dall'esfiltrazione di dati. I dati archiviati nei bucket Cloud Storage non possono essere copiati in posizioni esterne al perimetro e le operazioni del control plane sono protette. |
Le sezioni seguenti descrivono le connessioni e i flussi di traffico nell'architettura.
Connessioni tra i componenti
Questa sezione descrive le connessioni tra i componenti e le reti in questa architettura.
Rete esterna alla rete VPC di routing
Le reti esterne si connettono alla rete VPC di routing Google Cloud tramite Cloud Interconnect o VPN ad alta disponibilità, che sono spoke ibridi di un hub Network Connectivity Center.
I router Cloud nella rete VPC di routing e i router esterni nella rete esterna scambiano le route Border Gateway Protocol (BGP):
- I router nelle reti esterne annunciano le route per le subnet esterne al router Cloud VPC di routing. Puoi esprimere la preferenza delle route utilizzando metriche e attributi BGP.
- I router Cloud nella rete VPC di routing annunciano le route per i prefissi nei VPC di Google Cloudalle reti esterne.
Routing della rete VPC alla rete VPC condiviso
Connetti la rete VPC di routing e la rete VPC RAG utilizzando gli spoke VPC di Network Connectivity Center dell'hub Network Connectivity Center. L'hub ospita anche gli spoke ibridi alla rete esterna.
Da risorsa a risorsa all'interno della rete VPC condiviso
In questa progettazione, un bucket Cloud Storage riceve i dati dalla rete esterna. Le richieste di inferenza vengono inviate tramite un bilanciatore del carico delle applicazioni interno regionale. Per il resto dell'impianto, hai le seguenti opzioni:
- Ospita tutto nell'infrastruttura SaaS di Google, come bucket Cloud Storage, Vertex AI, Cloud Run e Pub/Sub. In questo caso, i componenti comunicano tramite l'infrastruttura Google privata.
- Ospita tutto nei carichi di lavoro eseguiti in VM Compute Engine, cluster GKE, database Cloud SQL o altri componenti eseguiti nelle reti VPC. In questo caso, i sistemi comunicano utilizzando indirizzi IP privati nelle reti collegate tramite Network Connectivity Center o peering di rete VPC.
- Utilizza un mix di servizi completamente gestiti, di piattaforma e di infrastruttura. In
questo caso, puoi stabilire connessioni tra una rete VPC e un servizio completamente
gestito utilizzando i seguenti metodi:
- Accesso privato Google: con questo metodo, i carichi di lavoro che non hanno indirizzi IP esterni e che vengono eseguiti nelle reti VPC possono accedere alle API di Google. Questo accesso avviene internamente tramite l'infrastruttura Google e questo processo non espone questo traffico a internet.
- Private Service Connect: con questo metodo, puoi creare un endpoint nel tuo progetto di servizio per servizi come AlloyDB per PostgreSQL ospitati in reti VPC gestite.
Bilanciatore del carico di rete esterno al servizio frontend
L'endpoint del bilanciatore del carico delle applicazioni interno regionale è un indirizzo IP nella rete RAG. La rete RAG, la rete di routing e le connessioni ibride alla rete esterna sono tutti spoke dello stesso hub Network Connectivity Center. Pertanto, puoi indicare a Network Connectivity Center di esportare tutti gli intervalli secondari spoke nell'hub, che a sua volta li riesporta nelle altre reti spoke. Gli utenti finali del sistema possono quindi raggiungere il servizio bilanciato del carico dalla rete esterna.
Flussi di traffico
I flussi di traffico in questa architettura di riferimento includono un flusso di dati RAG e un flusso di inferenza.
Flusso della popolazione RAG
Questo flusso descrive il modo in cui i dati RAG scorrono nel sistema dagli ingegneri dei dati all'archiviazione vettoriale.
- Dalla rete esterna, gli ingegneri dei dati caricano i dati non elaborati tramite la connessione Cloud Interconnect o Cloud VPN. I dati vengono caricati nell'endpoint Private Service Connect nella rete VPC di routing.
- I dati vengono trasferiti tramite l'infrastruttura interna di Google al bucket Cloud Storage nel progetto di servizio di importazione dati.
All'interno del progetto di servizio di importazione dati, i dati vengono trasferiti tra i sistemi utilizzando uno dei seguenti metodi:
- Accesso privato Google
- Endpoint di Private Service Connect
- Infrastruttura Google diretta
Il metodo dipende dal fatto che i sistemi siano ospitati in reti VPCGoogle Cloud o direttamente inGoogle Cloud. Nell'ambito di questo flusso, il sottosistema di importazione dati fornisce dati RAG suddivisi in blocchi al modello, che produce vettori per ogni blocco.
Il sottosistema di importazione dati scrive i dati vettoriali e i dati suddivisi in blocchi nell'archivio dati appropriato.
Flusso di inferenza
Questo flusso descrive le richieste dei clienti.
- Dalla rete esterna, un cliente invia una richiesta all'indirizzo IP del servizio.
- La richiesta viene trasmessa tramite la connessione Cloud Interconnect o Cloud VPN alla rete VPC di routing.
- La richiesta viene inviata tramite la connessione spoke VPC alla rete VPC RAG.
- La richiesta del cliente arriva al bilanciatore del carico, che la passa al sottosistema frontend.
- Il sottosistema frontend inoltra la richiesta al sottosistema di pubblicazione.
- Il sottosistema di pubblicazione aumenta la richiesta utilizzando i dati contestuali pertinenti dal datastore.
- Il sottosistema di pubblicazione invia il prompt arricchito al modello di AI, che genera una risposta.
Prodotti utilizzati
Questa architettura di riferimento utilizza i seguenti prodotti: Google Cloud
- Virtual Private Cloud (VPC): un sistema virtuale che fornisce funzionalità di rete globali e scalabili per i tuoi Google Cloud carichi di lavoro. VPC include il peering di rete VPC, Private Service Connect, l'accesso privato ai servizi e VPC condiviso.
- VPC condiviso: una funzionalità di Virtual Private Cloud che consente di connettere risorse di più progetti a una rete VPC comune utilizzando indirizzi IP interni di quella rete.
- Private Service Connect: una funzionalità che consente ai consumer di accedere ai servizi gestiti privatamente dall'interno della propria rete VPC.
- Accesso privato Google: una funzionalità che consente alle istanze VM senza indirizzi IP esterni di raggiungere gli indirizzi IP esterni dei servizi e delle API di Google.
- Cloud Interconnect: un servizio che estende la tua rete esterna alla rete Google tramite una connessione a disponibilità elevata e a bassa latenza.
- Cloud VPN: un servizio che estende in modo sicuro la tua rete peer alla rete di Google tramite un tunnel VPN IPsec.
- Cloud Router: un'offerta distribuita e completamente gestita che fornisce funzionalità di speaker e responder Border Gateway Protocol (BGP). Router Cloud funziona con Cloud Interconnect, Cloud VPN e le appliance router per creare route dinamiche nelle reti VPC in base alle route ricevute da BGP e a quelle apprese personalizzate.
- Network Connectivity Center: un framework di orchestrazione che semplifica la connettività di rete tra le risorse spoke connesse a una risorsa di gestione centrale chiamata hub.
- Controlli di servizio VPC: una funzionalità di networking gestita che riduce al minimo i rischi di esfiltrazione di dati per le tue risorse Google Cloud .
- Cloud Load Balancing: un portafoglio di bilanciatori del carico scalabili, globali e regionali ad alte prestazioni.
- Model Armor: un servizio che fornisce protezione per le tue risorse di AI generativa e agentica contro prompt injection, fughe di dati sensibili e contenuti dannosi.
- Google Cloud Armor: un servizio di sicurezza di rete che offre regole WAF (web application firewall) e aiuta a proteggere da attacchi DDoS e alle applicazioni.
- Cloud Storage: uno spazio di archiviazione di oggetti a basso costo e senza limiti per diversi tipi di dati. I dati sono accessibili dall'interno e dall'esterno di Google Cloude vengono replicati in più località per la ridondanza.
Casi d'uso
Questa architettura è progettata per scenari aziendali in cui l'input, l'output e le comunicazioni interne del sistema complessivo devono utilizzare indirizzi IP privati e non devono attraversare internet:
- Input privato: i dati caricati non vengono trasferiti su internet. Al contrario, ospiti il bucket Cloud Storage dietro un endpoint Private Service Connect nella tua rete VPC di routing Google Cloud. Copia i dati RAG tramite la connessione Cloud Interconnect o Cloud VPN utilizzando solo indirizzi IP privati.
- Connettività interservizi privata: i servizi comunicano tra loro tramite le interfacce interne di Google o tramite indirizzi privati interni alle tue reti VPC.
- Output privato: i risultati dell'inferenza non sono raggiungibili su internet, a meno che tu non scelga di configurare l'accesso. Per impostazione predefinita, solo gli utenti della rete esterna designata possono raggiungere l'endpoint privato del tuo servizio.
Alternative di progettazione
Questa sezione presenta approcci alternativi di progettazione della rete che puoi prendere in considerazione per la tua applicazione in grado di utilizzare RAG in Google Cloud.
Rendere il servizio disponibile pubblicamente
Nell'architettura mostrata in questo documento, solo gli utenti della tua rete interna possono inviare query alla tua applicazione. Se la tua applicazione deve essere accessibile ai client su internet, utilizza un bilanciatore del carico delle applicazioni esterno regionale.
Utilizzare GKE Inference Gateway
Se il sottosistema frontend viene eseguito su GKE, puoi utilizzare un gateway di inferenza anziché un bilanciatore del carico delle applicazioni.
Considerazioni sulla progettazione
Questa sezione fornisce ulteriori indicazioni per aiutarti a eseguire il deployment del networking per supportare la connettività privata per un'architettura compatibile con RAG. Queste indicazioni possono aiutarti a soddisfare i tuoi requisiti specifici di sicurezza e conformità, affidabilità, costi e prestazioni. Le indicazioni riportate in questa sezione non sono esaustive. Per la tua implementazione specifica, potresti dover considerare fattori di progettazione aggiuntivi non trattati in questa sezione.
Sicurezza, privacy e conformità
Nella maggior parte dei casi, esegui il deployment di Model Armor davanti al modello di AI per valutare sia i prompt in entrata che i risultati in uscita. Model Armor aiuta a prevenire potenziali rischi e a garantire pratiche di AI responsabile.
Per rifiutare le richieste inappropriate prima che raggiungano il sottosistema di pubblicazione, puoi collegare Model Armor al bilanciatore del carico.
Questa architettura utilizza i controlli di servizio VPC, che contribuiscono a impedire l'esfiltrazione di dati non autorizzata.
Questo design utilizza principi di sicurezza consolidati per proteggere i tuoi carichi di lavoro RAG. Per principi e consigli di sicurezza specifici per i workload AI e ML, consulta Prospettiva AI e ML: sicurezza nel framework Well-Architected.
Ottimizzazione dei costi
Per principi e suggerimenti di ottimizzazione dei costi specifici per i workload AI e ML, consulta Prospettiva AI e ML: ottimizzazione dei costi nel framework Well-Architected.
Ottimizzazione delle prestazioni
Per principi e consigli di ottimizzazione delle prestazioni specifici per i carichi di lavoro di AI e ML, consulta Prospettiva AI e ML: ottimizzazione delle prestazioni nel Well-Architected Framework.
Deployment
Questa sezione descrive i passaggi per creare l'applicazione:
- Identifica la regione per i workload.
- Crea Google Cloud progetti e reti VPC.
- Connetti le tue reti esterne alla tua rete VPC di routing.
- Collega le reti utilizzando Network Connectivity Center.
- Identifica i componenti per il deployment di RAG e crea service account.
- Configura i Controlli di servizio VPC.
- Crea il sottosistema di importazione dati dati.
- Crea il sottosistema di pubblicazione.
- Crea il sottosistema frontend.
- Rendere la tua applicazione raggiungibile da internet.
Identificare la regione per i workload
In generale, vuoi posizionare la connettività, le subnet VPC e i carichi di lavoro in prossimità delle reti on-premise o di altri client cloud. Google CloudPer saperne di più su come scegliere una regione per i tuoi workload, consulta Google Cloud Region Picker e Best practice per la scelta delle regioni di Compute Engine.
Crea Google Cloud progetti e reti VPC
Se la tua organizzazione ha già configurato Cross-Cloud Network per applicazioni distribuite, il progetto di routing e la rete VPC di routing dovrebbero già esistere.
Crea i progetti Google Cloud e una rete VPC nel seguente ordine:
- Crea il progetto di routing.
- Crea la rete VPC di routing con l'accesso privato Google abilitato.
- Crea il progetto RAG.
- Promuovi il progetto RAG a progetto host VPC condiviso.
- Crea il progetto di servizio di importazione dati.
- Crea il progetto del servizio di pubblicazione.
- Crea il progetto di servizio frontend.
- Crea la rete RAG VPC condiviso con l'accesso privato Google abilitato.
- Concedi ai progetti di servizio l'autorizzazione a utilizzare la rete RAG.
Connetti le tue reti esterne alla tua rete VPC di routing
Puoi saltare questo passaggio se hai già configurato Cross-Cloud Network per applicazioni distribuite.
Configura la connettività tra le reti esterne e la tua rete di routing. Per comprendere le tecnologie pertinenti, vedi Connettività esterna e ibrida. Per indicazioni su come scegliere un prodotto di connettività, consulta Scelta di un prodotto di connettività di rete.
Collegare le reti utilizzando Network Connectivity Center
- Nel progetto di routing, crea un hub Network Connectivity Center.
- Aggiungi le connessioni Cloud Interconnect come spoke di collegamento VLAN o aggiungi le connessioni Cloud VPN come spoke VPN.
- Aggiungi la rete VPC RAG e la rete VPC di routing all'hub come spoke VPC.
Identificare i componenti per il deployment di RAG e creare service account
- Scegli un deployment RAG e crea un elenco dei componenti necessari.
- Identifica l'accesso necessario per ogni componente.
- Per ogni componente, crea un service account con le autorizzazioni appropriate. In alcuni casi, ciò significa che concedi a un componente l'autorizzazione a leggere o scrivere in un altro progetto di servizio.
Questo design presuppone che tu utilizzi un bucket Cloud Storage come componente di input dei dati e un bilanciamento del carico nel frontend di inferenza. Il resto del design può variare in base alle esigenze.
Idealmente, ogni componente viene eseguito come account di servizio separato. Assicurati che ogni componente disponga solo delle autorizzazioni IAM minime necessarie per svolgere le sue funzioni richieste. Ad esempio, un job Cloud Run nel sottosistemaimportazione datii deve leggere dal bucket Cloud Storage di input, ma non deve scriverci. In questo esempio, il progetto di servizio che esegue il job Cloud Run deve avere l'autorizzazione per leggere solo dal bucket, senza autorizzazione di scrittura.
Configurazione dei Controlli di servizio VPC
- Crea un perimetro dei Controlli di servizio VPC intorno al deployment.
- Configurare le regole di accesso.
Crea il sottosistema di importazione dati
Il sottosistema di importazione dati prende i dati non elaborati dagli ingegneri dei dati e li elabora per l'utilizzo da parte del sottosistema di pubblicazione.
- Nel progetto di servizio di importazione dati, crea un bucket Cloud Storage.
- Nella rete VPC di routing, crea un endpoint Private Service Connect regionale e connettilo al bucket.
- Nella rete esterna, aggiungi una voce DNS per l'endpoint utilizzando l'indirizzo IP e l'URL generati nel passaggio precedente.
- Aggiorna le regole firewall di rete esterne per consentire l'accesso all'indirizzo IP dell'endpoint.
- Nel progetto del servizio di importazione dati, crea il resto della pipeline di importazione in base all'architettura RAG scelta.
- Concedi le autorizzazioni IAM in modo che la risorsa pertinente nella pipeline di importazione possa accedere al modello che produce i vettori.
- Concedi le autorizzazioni IAM in modo che la risorsa pertinente nella pipeline di importazione possa scrivere nel datastore vettoriale.
Crea il sottosistema di pubblicazione
- Nel progetto del servizio di pubblicazione, crea la pipeline di pubblicazione.
- Concedi le autorizzazioni IAM in modo che il account di servizio nel sistema frontend possa accedere all'output del sottosistema di pubblicazione.
Crea il sottosistema frontend
Questa sezione presuppone che tu utilizzi un bilanciatore del carico delle applicazioni interno regionale che utilizza un NEG serverless davanti a Cloud Run. Tuttavia, puoi utilizzare un bilanciatore del carico e un backend diversi.
- Crea il codice per il sistema di frontend.
- Nel progetto del servizio frontend, esegui il deployment del sistema frontend bilanciato dal carico, che include il passaggio facoltativo per configurare una policy di sicurezza di Cloud Armor.
- Configura Cloud Router nella rete VPC di routing per inoltrare le route dalla rete VPC RAG ai router on-premise. Questa configurazione consente ai client di raggiungere il bilanciatore del carico.
- Nella tua rete esterna, configura le regole firewall per rendere raggiungibile il frontend del bilanciatore del carico dalla tua rete esterna.
- Nella tua rete esterna, aggiorna il DNS in modo che punti alla regola di forwarding del bilanciatore del carico.
Rendere raggiungibile la tua applicazione da internet
Questa sezione è facoltativa.
Questo progetto presuppone che tu voglia che il tuo servizio sia raggiungibile solo dalla tua rete esterna, ma puoi anche renderlo raggiungibile da internet.
Per rendere il servizio raggiungibile da internet, completa i seguenti passaggi:
- Crea un bilanciatore del carico delle applicazioni esterno regionale che punta allo stesso backend a cui punta il bilanciatore del carico interno. Completa il passaggio facoltativo per configurare una policy di sicurezza di Cloud Armor.
- Aggiorna i Controlli di servizio VPC per consentire ai clienti del servizio di raggiungere i servizi di backend.
Passaggi successivi
- Scopri di più su Cross-Cloud Network per applicazioni distribuite.
- Scopri come ospitare app e agenti di AI su Cloud Run.
- Scopri di più sulle best practice per l'AI responsabile e sui filtri di sicurezza di Vertex AI.
- Scopri di più sulle best practice per i modelli linguistici di grandi dimensioni (LLM).
- Per una panoramica dei principi e dei consigli architetturali specifici per i workload di AI e ML in Google Cloud, consulta la prospettiva AI e ML nel Well-Architected Framework.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora Cloud Architecture Center.
Collaboratori
Autori:
- Deepak Michael | Networking Specialist Customer Engineer
- Mark Schlagenhauf | Technical Writer, Networking
Altri collaboratori:
- Kumar Dhanagopal | Sviluppatore di soluzioni cross-product
- Victor Moreno | Product Manager, Cloud Networking
- Samantha He | Technical Writer
- Ammett Williams | Developer Relations Engineer
- Aspen Sherrill | Cloud Security Architect