LLM e OpenAI di Azure nel modello RAG (Retrieval Augmented Generation) (anteprima)

Questo articolo offre un esempio illustrativo dell'uso di LLM (Large Language Models) e OpenAI di Azure nel contesto del modello RAG (Retrieval Augmented Generation). Nello specifico, l'articolo esplora come si possono applicare queste tecnologie all'interno delle sovereign landing zone, considerando anche importanti misure di protezione.

Scenario

Uno scenario comune consiste nell'utilizzare gli LLM per impegnarsi in conversazioni utilizzando i propri dati tramite il modello RAG (Retrieval Augmented Generation). Questo modello ti consente di sfruttare le capacità di ragionamento degli LLM per generare risposte basate sui tuoi dati specifici senza richiedere la messa a punto del modello. Facilita la perfetta integrazione degli LLM nei processi o nelle soluzioni aziendali esistenti.

Cloud for Sovereignty - Architettura di riferimento IA e LLM

Microsoft Cloud for Sovereignty fornisce un'architettura di riferimento che illustra una tipica architettura RAG in una sovereign landing zone (SLZ). Fornisce una panoramica delle scelte tecnologiche di implementazione comuni e consigliate, della terminologia, dei principi tecnologici, degli ambienti di configurazione comuni e della composizione dei servizi applicabili.

Scarica un un PDF stampabile di questo diagramma dell'architettura di riferimento.

Le fasi principali/il flusso di dati sono i seguenti:

Zone di destinazione delle applicazioni

Nella gerarchia del gruppo di gestione, questi servizi vengono inseriti in una sottoscrizione all'interno di un gruppo di gestione non riservato.

Origini dati e pipeline di trasformazione

Le origini dati e le pipeline di trasformazione spesso esistono all'interno di un'organizzazione per le operazioni della line-of-business. Quando integri le applicazioni LLM, come le implementazioni RAG, ai dati esistenti, diventano nuovi carichi di lavoro.

Per garantire il controllo del flusso di dati, l'architettura di riferimento consiglia un dominio di dati allineato alle zone di destinazione dei dati per le origini dati e le pipeline di trasformazione dei dati vicine a tali origini per creare prodotti di dati che vengono utilizzati da applicazioni LLM. Questo approccio garantisce una gestione precisa dei dati di cui è stato eseguito il provisioning alla soluzione basata su LLM, ospitata separatamente.

I componenti di trasformazione dei dati si avvalgono di diverse tecnologie e servizi per trasformare i dati in un formato che può essere ricercato e utilizzato da un'applicazione basata su LLM tramite ricerca semantica o vettoriale per scopi di base. Queste pipeline possono funzionare autonomamente oppure utilizzare servizi di intelligenza artificiale, come Azure AI Services o Azure OpenAI, per trasformare i dati da inserire in un database di ricerca vettoriale o di ricerca semantica.

Quando si utilizzano i servizi di intelligenza artificiale, il peering di rete li rende sempre disponibili (tramite l'hub o direttamente) attraverso i relativi endpoint privati. Per motivi di governance, sicurezza e conformità, i componenti di trasformazione dei dati hanno l'autorità di determinare quali dati e in quale formato vengono forniti a un database di ricerca per il carico di lavoro LLM.

I componenti di trasformazione dei dati possono utilizzare vari tipi di origini dati per offrire dati con il risultato ottimale ai database di ricerca su cui si basano i carichi di lavoro LLM. Queste origini dati possono essere database SQL, data lake o anche macchine virtuali che ospitano soluzioni di dati personalizzate, a seconda dell'ambiente del cliente.

Le origini dati non devono essere accessibili direttamente dall'app Agente di orchestrazione, ma queste risorse devono invece essere disponibili solo all'interno dei confini privati della rete virtuale. Ciò impone l'integrazione diretta di Rete virtuale di Microsoft Azure (ad esempio, come nel caso delle VM), dei servizi di collegamento privato o degli endpoint servizio di rete virtuale (solo se il collegamento privato o l'integrazione diretta di Rete virtuale non è disponibile).

Componenti correlati all'intelligenza artificiale e a LLM

I componenti correlati all'intelligenza artificiale e a LLM devono essere ospitati come carichi di lavoro nella propria sottoscrizione nel gruppo di gestione Aziendale o Online (a seconda che sia richiesto o meno l'accesso pubblico). Questi componenti sono:

Azure OpenAI Service incapsula le operazioni di LLM come GPT e Text Embedding come Ada, rendendole accessibili tramite API standard fornite da Azure OpenAI all'app Orchestrator.

Un' app Agente di orchestrazione funge da front-end con un'interfaccia basata su API o UX e orchestra i diversi passaggi necessari per creare esperienze basate su RAG. Spesso si tratta di un'applicazione Web o di un'API Web. Questi passaggi in genere includuno:

• pull dei dati da motori di ricerca semantici per grounding dei prompt
• pull dei dati da origini dati per grounding dei prompt
• concatenazione corretta di diverse richieste all'LLM

L'app Orchestrator conserva la cronologia delle richieste inviate e delle risposte ricevute per garantire che il servizio Azure venga messo a terra in base alle interazioni precedenti. OpenAI Ad esempio, in un'esperienza di tipo chat come ChatGPT o Bing Chat, l'app Agente di orchestrazione mantiene o memorizza nella cache la cronologia della sessione di conversazione in modo che venga considerata nel flusso di conversazione dal back-end del servizio LLM.

In un ambiente Online, l'endpoint dell'app Agente di orchestrazione deve essere l'unica fornita tramite un endpoint pubblico protetto da un firewall per applicazioni Web e da servizi di protezione DDoS. Se ospitato in un ambiente Aziendale, senza endpoint pubblici, l'Agente di orchestrazione è ospitato in un servizio direttamente integrato nella rete virtuale, ad esempio macchine virtuali o set di scalabilità di macchine virtuali oppure utilizza servizi che supportano il collegamento privato o gli endpoint servizio di rete virtuale come nel caso dei servizi app di Azure.

I servizi di ricerca forniscono dati provenienti da diverse fonti in un formato ottimizzato per un utilizzo efficiente e per un rapido avviamento dei servizi LLM. Microsoft propone una combinazione di vettorizzazione e ricerca semantica per ottenere i migliori risultati per un grounding dei prompt basato sui servizi di ricerca, supportati da Azure AI Search. L'utilizzo della classificazione semantica migliora in modo misurabile la pertinenza della ricerca utilizzando la comprensione del linguaggio per classificare i risultati della ricerca. Ciò migliora l'esperienza utente delle applicazioni RAG, poiché il grounding dei prompt diventa più accurato attraverso risultati della ricerca migliori dal servizio di ricerca prima di inviare una richiesta a LLM.

Una combinazione di servizi di intelligenza artificiale potrebbe essere utilizzata per creare esperienze personalizzate per gli utenti finali tramite l'Agente di orchestrazione o per ottimizzare i processi di inserimento dati. Immagina di utilizzare un servizio di riconoscimento dei moduli come Elaborazione intelligente dei documenti di Azure AI per estrarre informazioni strutturate da moduli ed elaborare e riepilogare in modo efficiente gli input degli utenti. Questo servizio può quindi collaborare con un LLM per riassumere i risultati chiave di quegli input di moduli riconosciuti. Un altro scenario prevede l'utilizzo di un servizio di riconoscimento di documenti per convertirli in documenti di testo in vari formati come PDF o documenti Word. Successivamente, un servizio di incorporamento di testo LLM può vettorizzare questo testo riconosciuto per ulteriori analisi.

I servizi collegare privati vengono distribuiti per tutti i componenti in modo che tutti i servizi siano accessibili solo all'interno del ambiente privato. L'unica eccezione potrebbe essere l'app Agente di orchestrazione, che se ospitata in una zona di destinazione Online potrebbe essere offerta pubblicamente dietro un Web Application Firewall o servizi comparabili.

Componenti dell'infrastruttura

I componenti dell'infrastruttura possono essere ospitati come parte del carico di lavoro oppure centralmente in un hub o una sottoscrizione di identità.

Il componente dell'infrastruttura centrale di un'implementazione della zona di destinazione sovrana è l'hub di connettività della piattaforma, il quale è una rete virtuale fornito da ogni distribuzione della zona di destinazione sovrana. È posizionato nella sottoscrizione per la connettività all'interno del gruppo di gestione della piattaforma.

I componenti di rete condivisi sono posizionati nella rete virtuale dell'hub. Questi componenti in genere includono:

• Circuiti ExpressRoute o gateway VPN per la connettività alla rete aziendale di un'azienda, agenzia o organizzazione.

• I firewall possono essere implementati utilizzando appliance o una combinazione di offerte di Azure Firewall, tra cui Web Application Firewall. Queste soluzioni consentono l'ispezione, il filtraggio e il routing del traffico.

• Componenti di protezione DDoS per proteggere i carichi di lavoro dagli attacchi Distributed Denial of Service.

• Zone DNS private per tutti i tipi di servizi utilizzati nell'intero panorama del data center virtuale implementato con zone di destinazione.

• Peering di rete virtuale per connettere reti virtuali di vari carichi di lavoro, quali origini dati, trasformazione e componenti LLM, tramite la rete hub.

• Le policy controllano il flusso del traffico attraverso i firewall dell'hub ove necessario.

Considerazioni

Il diagramma dell'architettura di riferimento mostra un esempio di architettura rappresentativo che coinvolge i componenti tipici di un carico di lavoro basato su RAG LLM nel contesto di una zona di destinazione sovrana. Ci sono diverse considerazioni da tenere a mente che non sono state trattate nelle sezioni precedenti.

Allineamento ai principi di Well-Architected Framework e Cloud Adoption Framework

Nelle sezioni precedenti sono stati brevemente menzionati alcuni aspetti di allineamento relativi a Well-Architected Framework (WAF) e a Cloud Adoption Framework (CAF). È importante notare che tutte le decisioni relative all'architettura devono essere completamente allineate ai principi fondamentali di CAF e delle zone di destinazione Azure, analisi su scala cloud del CAF e WAF, inclusa la prospettiva WAF in OpenAI di Azure.

Considerazioni sulla progettazione dell'infrastruttura in relazione alle protezioni

Sebbene la gestione delle protezioni sia una procedura standard negli ambienti delle zone di destinazione, è necessario fare altre considerazioni in diverse aree per i carichi di lavoro LLM e IA. È meglio seguire la conformità alla baseline sulla sicurezza di Azure e gli standard dell'iniziativa criteri della baseline di Sovereignty durante la progettazione e la definizione dell'infrastruttura per la sottoscrizione al carico di lavoro.

Le principali considerazioni da evidenziare per le applicazioni basate su RAG LLM a partire da questi standard sono le seguenti:

Residenza dei dati e selezione dell'area geografica

La sovranità impone requisiti rigorosi sulla residenza dei dati e pertanto potrebbe limitare le distribuzioni a specifiche aree geografiche di Azure in una SLZ. La selezione di un'area geografica per i carichi di lavoro LLM è limitata dalla disponibilità dei servizi richiesti:

• Verifica che OpenAI di Azure e Azure AI Search siano entrambi disponibili nell'area geografica di destinazione in cui ospiti i dati e il carico di lavoro per motivi di residenza e/o prossimità dei dati. Inoltre, questi servizi sono importanti, dal punto di vista delle prestazioni, per l'esperienza dell'utente finale con l'applicazione.

• In secondo luogo, quando si esamina OpenAI di Azure, la disponibilità dei rispettivi modelli LLM è importante poiché non tutti i modelli sono ugualmente disponibili in tutte le aree geografiche.

• Se le origini dati o altri servizi cognitivi non sono disponibili nell'area geografica di destinazione designata, potresti essere in grado di trovarli e gestirli in un'altra area geografica in linea con i requisiti di residenza dei dati. Tuttavia, il servizio OpenAI di Azure e Azure AI Search devono trovarsi nella stessa area geografica dell'app Agente di orchestrazione per motivi di prestazioni.

Rete

Gli endpoint pubblici non sono consentiti negli ambienti Aziendale. Pertanto, tutti i servizi devono essere incapsulati in una rete virtuale. A seconda del servizio, potrebbe offrire funzionalità di incapsulamento diretto come VM o cluster AKS, collegamento privato o endpoint servizio di rete virtuale. Gli endpoint servizio di rete virtuale devono essere sostituiti dal collegamento privato ove possibile.

Oltre all'incapsulamento, l'accesso pubblico deve essere disabilitato per tutti i servizi. Infine, l'applicazione dei criteri tramite Criteri di Azure deve essere abilitata in modo che l'accesso pubblico non possa mai essere abilitato accidentalmente per i servizi in cui non è possibile creare criteri di negazione corrispondenti. La strategia di difesa approfondita consiste nell'abilitare le corrispondenti funzionalità di controllo per tutti i servizi.

Crittografia inattiva e in transito

La maggior parte dei servizi in Azure supporta sia funzionalità di crittografia inattive che in transito. Abilita la crittografia inattiva e in transito in tutti i servizi quando disponibile. Abilita l'ultima versione di TLS, attualmente TLS 1.2, per la crittografia in transito.

Identità gestite

Utilizza identità gestite per tutti i servizi e la comunicazione da servizio a servizio per evitare di gestire i segreti per le credenziali.

Rotazione delle chiavi in ​​Key Vault

Ogni volta che sono necessarie risorse di sicurezza come i certificati, abilita la rotazione delle chiavi per tali segreti in Key Vault per mantenere la conformità.

Gruppi di sicurezza di rete e delle applicazioni

In un ambiente sovrano e sicuro, viene imposto l'uso dei gruppi di sicurezza di rete (NSG) e i i gruppi di sicurezza delle applicazioni (ASG). In caso di gruppi di sicurezza mancanti, si hanno distribuzioni non conformi. Le normali porte SSL sono utili per la maggior parte dei servizi su cui si basano i carichi di lavoro LLM/RAG poiché sono basati su HTTPS. Sono necessarie porte specifiche per l'inserimento dei dati dalle origini ai database di ricerca e vettoriali. Gli IP pubblici non sono consentiti nelle zone di destinazione Aziendale. Tutti i servizi devono essere accessibili solo nella rete virtuale, che richiede l'uso del collegamento privato o degli endpoint servizio di rete virtuale per i servizi PaaS.

Ulteriori protezioni di sicurezza e sovranità

Le protezioni più importanti e ovvie trattate nelle sezioni precedenti per la progettazione dell'infrastruttura e delle applicazioni sono riutilizzabili anche all'esterno delle zone di destinazione sovrane o Azure. Altri criteri globali sono legati a risorse gestite centralmente come aree di lavoro Log Analytics o distribuzioni di Microsoft Sentinel in zone di destinazione su scala aziendale. Durante il processo di progettazione dell'infrastruttura e delle applicazioni, è fondamentale tenere in considerazione queste risorse gestite centralmente. In caso contrario, è possibile che sia necessario più tempo e risorse alla post-distribuzione. Per fortuna, la funzionalità di conformità ai criteri di Azure può identificare le risorse non conformi dopo la distribuzione. Inoltre, sia le zone di destinazione sovrane che quelle di Azure forniscono criteri DeployIfNotExists per numerose risorse, semplificando ulteriormente il processo.

Alcuni esempi di tali protezioni sono:

• Attivazione dell'accesso ad aree di lavoro Log Analytics gestite centralmente.

• Integrazione con Centro sicurezza di Azure o Microsoft Defender for Cloud.

• Integrazione con suite Security Information and Event Management (SIEM) come Microsoft Sentinel.

• Integrazione con firewall gestiti centralmente, Web application firewall o protezione DDoS.

Questi sono solo alcuni delle protezioni che potresti identificare come requisiti dopo la distribuzione iniziale. È consigliabile testare le distribuzioni in una zona di destinazione di prova e integrare in modo iterativo tali protezioni nella codebase dell'infrastruttura e delle applicazioni. Se ciò non è del tutto possibile, molte di queste protezioni possono essere integrate dopo la distribuzione con criteri DeployIfNotExists.

Distribuire il seguente scenario

Per sfruttare i vantaggi degli LLM (Large Language Model) e di OpenAI di Azure in base al modello RAG (Retrieval Augmented Generation) nelle sovereign landing zone, devi prima distribuire e configurare una sovereign landing zone e applicare le iniziative di criteri di base della sovranità. Per una panoramica dettagliata di una zona di destinazione sovrana e di tutte le relative funzionalità, consulta la documentazione sulle zone di destinazione sovrane in GitHub.

Una zona di destinazione sovrana fornisce un ambiente con protezioni tramite criteri e set di criteri, applicazione della sicurezza e un'infrastruttura baseline coerente per la distribuzione di carichi di lavoro e applicazioni. La SLZ si basa su zone di destinazione di Azure e le estende con misure di protezione e controlli di sicurezza specifici per i requisiti di sovranità.

Per aiutare ad accelerare il time-to-value dei clienti assistendoli nel raggiungimento dei loro obiettivi di conformità, Microsoft Cloud for Sovereignty include modelli di carichi di lavoro pronti all'uso che possono essere distribuiti e gestiti in modo coerente in modo ripetibile. I modelli del carico di lavoro sono allineati alle iniziative di criteri della baseline di sovranità, al portafoglio di criteri di Cloud for Sovereignty e criteri predefiniti delle zone di destinazione di Azure.

Modello di agente informativo Assistente

Il modello dell'agente Information Assistente fornisce un puntare iniziale che consente alle organizzazioni di creare la propria funzionalità di intelligenza artificiale generativa personalizzata per estendere la potenza di Azure OpenAI agli utenti dell'organizzazione e ai dati del loro dominio senza dover perfezionare il modello. Puoi distribuirlo all'interno di Cloud for Sovereignty ed allinearlo all'architettura di riferimento e alle linee guida fornite in questo articolo. Il modello dell'agente Information Assistente è compatibile con l'ambito del gruppo di gestione Sovereign Landing Zone Online utilizzando la configurazione di distribuzione in modalità protetta . Il supporto per l'ambito del gruppo di gestione Corp sarà disponibile a breve.

Il modello dell'agente è una combinazione di codice, documentazione e risorse didattiche fornite gratuitamente a clienti e partner, che possono contribuire ad accelerare il time-to-value.

Per ulteriori informazioni su come distribuire e configurare Information Assistente, consultare la documentazione del modello di agente Information Assistente su GitHub. ... Per i casi d'uso che è possibile realizzare con questo modello di agente, vedere Informazioni Assistente Video.