architettura di Microsoft Foundry

Microsoft Foundry organizza i carichi di lavoro di intelligenza artificiale tramite un'architettura a più livelli: una risorsa Foundry di primo livello per la governance, i progetti per l'isolamento dello sviluppo e i servizi di Azure connessi per l'archiviazione, la ricerca e la gestione dei segreti.

Questo articolo fornisce ai team IT operazioni e sicurezza con informazioni dettagliate sulla risorsa Foundry e sull'architettura del servizio Azure sottostante, i relativi componenti e la relativa relazione con altri tipi di risorse Azure. Usare queste informazioni per guidare la personalizzazione della distribuzione Foundry in base ai requisiti dell'organizzazione. Per altre informazioni su come implementare Foundry nell'organizzazione, vedere Foundry Rollout.

Quando usare questa architettura

Prendere in considerazione il modello di risorsa Foundry quando lo scenario prevede:

• Configurazione per la prima volta: si sta avviando un nuovo progetto di intelligenza artificiale e si vuole una singola risorsa che aggrega l'accesso al modello, l'hosting dell'agente e gli strumenti di valutazione.
• Accesso multi-team: più team necessitano di progetti isolati con distribuzioni di modelli condivisi e governance centralizzata.
• Progettazione guidata dalla conformità: La tua organizzazione richiede reti private, crittografia gestita dal cliente o RBAC di Azure a livello di risorsa e progetto.
• Azure migrazione OpenAI: si sta passando da una risorsa autonoma di Azure OpenAI e si vogliono mantenere i criteri di sicurezza e il controllo degli accessi in base al ruolo esistenti, aggiungendo funzionalità di agente e valutazione.

Per l'esplorazione a singolo sviluppatore, una risorsa Foundry con un progetto è l'impostazione predefinita consigliata. Se il tuo carico di lavoro richiede solo completamenti di Azure OpenAI senza hosting o valutazione dell'agente, potrebbe essere sufficiente una risorsa Azure OpenAI autonoma.

Tipi di risorse e provider di Intelligenza Artificiale in Azure

All'interno della famiglia di prodotti di intelligenza artificiale Azure è possibile usare questi provider di risorse Azure che supportano le esigenze degli utenti a livelli diversi nello stack.

Per la maggior parte degli scenari di sviluppo di intelligenza artificiale, inclusi i flussi di lavoro di compilazione, distribuzione di modelli e valutazione dell'agente, la risorsa Foundry è il punto di partenza consigliato. Le risorse foundry condividono il namespace del provider Microsoft.CognitiveServices con servizi come Azure OpenAI, Speech, Vision e Language. Questo spazio dei nomi del provider condiviso aiuta ad allineare le API di gestione, i modelli di controllo degli accessi, la rete e il comportamento delle politiche tra le risorse di intelligenza artificiale correlate.

Usare la tabella seguente per identificare il tipo di risorsa corrispondente al carico di lavoro. Mostra i tipi di risorse e le funzionalità specifici all'interno del provider Microsoft.CognitiveServices:

I tipi di risorse nello stesso spazio dei nomi del provider condividono le stesse API di gestione e utilizzano azioni simili di controllo degli accessi in base al ruolo di Azure (Azure RBAC), configurazioni di rete e alias per la configurazione di Criteri di Azure. Se si esegue l'aggiornamento da Azure OpenAI a Foundry, i criteri di Azure personalizzati esistenti e le azioni di controllo degli accessi in base al ruolo Azure continuano a essere applicate.

Gerarchia delle risorse di fonderia

Il diagramma seguente mostra una risorsa Foundry con distribuzioni di modelli, impostazioni di sicurezza, connessioni e due progetti. I servizi di Azure connessi, ad esempio Archiviazione, Key Vault e Azure AI Search sono risorse separate Azure ai propri limiti di governance:

Utilizzare questo modello quando si pianifica l'architettura e i limiti di accesso.

• risorsa Foundry: risorsa di Azure di primo livello in cui si gestiscono impostazioni di governance come rete, sicurezza e distribuzioni di modelli.
• Project: limite di sviluppo all'interno della risorsa Foundry in cui i team compilano e valutano i casi d'uso. I progetti consentono ai team di creare prototipi all'interno di un ambiente preconfigurato, riutilizzando distribuzioni e connessioni di modelli esistenti senza ripetere la configurazione IT.
• Asset del progetto: file, agenti, valutazioni e artefatti correlati nell'ambito di un progetto.
• Risorse connesse: servizi Azure come Archiviazione, Key Vault e Azure AI Search a cui fa riferimento la risorsa Foundry tramite connessioni. Queste risorse hanno limiti di governance separati, quindi è possibile gestire i criteri di rete e di accesso in modo indipendente.

Questa separazione consente ai team IT di applicare controlli centralizzati a livello di risorsa mentre i team di sviluppo lavorano entro i limiti a livello di project.

Separazione dei compiti basata sulla sicurezza

Foundry applica una netta separazione tra le operazioni di gestione e sviluppo per garantire carichi di lavoro di intelligenza artificiale sicuri e scalabili.

Governance delle risorse di primo livello

Le operazioni di gestione degli ambiti delle risorse Foundry di primo livello, ad esempio la configurazione della sicurezza, la definizione della connettività con altri servizi di Azure e la gestione delle distribuzioni. I contenitori di progetti dedicati isolano le attività di sviluppo e forniscono limiti per il controllo di accesso, i file, gli agenti e le valutazioni.

Controllo degli accessi in base al ruolo

Le azioni di Azure RBAC (Controllo degli Accessi Basato sul Ruolo) riflettono questa separazione delle responsabilità. Le azioni del piano di controllo, ad esempio la creazione di deployment e progetti, sono distinte dalle azioni del piano dati, ad esempio la creazione di agenti, l'esecuzione di valutazioni e il caricamento di file. È possibile definire l'ambito delle assegnazioni del controllo degli accessi in base al ruolo sia a livello di risorsa principale sia a livello di singolo progetto. Assegnare identità gestite a uno dei due ambiti per supportare l'automazione sicura e l'accesso ai servizi. Per altre informazioni, vedere Controllo degli accessi in base al ruolo per Microsoft Foundry.

Le assegnazioni iniziali comuni per l'onboarding con il minimo dei privilegi includono:

• Utente Azure AI per ogni principale utente sviluppatore nello scope della risorsa Foundry.
• Azure AI User per ogni identità gestita per progetto nell'ambito delle risorse Foundry.

Per le definizioni dei ruoli e le indicazioni sulla pianificazione dell'ambito, vedere Controllo degli accessi in base al ruolo per Microsoft Foundry.

Monitoraggio e osservabilità

Monitoraggio di Azure segmenta le metriche in base all'ambito. È possibile visualizzare le metriche di gestione e utilizzo nella risorsa di primo livello, mentre le metriche specifiche project, ad esempio le prestazioni di valutazione o l'attività dell'agente, hanno come ambito i singoli contenitori project.

Le principali funzionalità di monitoraggio includono:

• Metriche a livello di risorsa: consumo di token, latenza del modello, conteggi delle richieste e percentuali di errore in tutti i progetti.
• Metriche a livello di progetto: risultati delle esecuzioni di valutazione, conteggi delle chiamate dell'agente e attività delle operazioni sui file.
• Registrazione diagnostica: Abilitare le impostazioni di diagnostica per instradare i log a Log Analytics, Archiviazione, o Event Hubs per l'analisi e la conservazione.

Per altre informazioni, vedere panoramica Monitoraggio di Azure.

Infrastruttura di calcolo

Foundry gestisce l'infrastruttura di calcolo per l'hosting del modello, l'esecuzione dell'agente e l'elaborazione batch. Questa sezione illustra i tipi di distribuzione, l'infrastruttura di valutazione e l'agente, l'integrazione della rete virtuale, l'isolamento del tenant, i controlli di sicurezza del contenuto e la disponibilità a livello di area.

Tipi di distribuzione del modello

Foundry supporta più tipi di distribuzione per l'hosting di modelli, raggruppati in base all'ambito di elaborazione dati: globale (tra aree), zona dati (entro un limite definito) e area (singola area). Ogni tipo bilancia la latenza, la velocità effettiva e la posizione di elaborazione dei dati in modo diverso:

Per informazioni dettagliate su come scegliere il tipo di distribuzione corretto, vedere Tipi di distribuzione per i modelli foundry.

Agenti, valutazioni ed elaborazione batch

Gli agenti, le valutazioni e i processi batch sono completamente gestiti da Microsoft. I carichi di lavoro dell'agente vengono eseguiti all'interno dell'infrastruttura contenitore della piattaforma, che supporta l'integrazione della rete virtuale per scenari isolati dalla rete. Le valutazioni richiamano gli endpoint del modello, confrontano gli output con i criteri di classificazione e archiviano i risultati all'interno dell'ambito del progetto. Le code di elaborazione batch mettono in coda le richieste di inferenza per l'esecuzione asincrona con prezzi ridotti per token. I risultati per tutti e tre i tipi di carico di lavoro sono accessibili tramite il portale o l'SDK.

Integrazione della rete virtuale

Quando gli agenti si connettono con sistemi esterni, è possibile isolare il traffico di rete usando iniezione del contenitore, in cui la piattaforma inserisce una subnet nella rete virtuale, abilitando la comunicazione locale con le risorse Azure all'interno della stessa rete virtuale.

Foundry supporta due modelli di rete per l'isolamento in uscita:

Isolamento degli inquilini

I carichi di lavoro vengono eseguiti in ambienti isolati logicamente per ogni risorsa Foundry. Il codice del cliente non condivide i contenitori di runtime con altri tenant.

Sicurezza dei contenuti e protezioni

Foundry integra i controlli di sicurezza dei contenuti nella pipeline di inferenza per i modelli e gli agenti. Le guardrail definiscono i rischi da rilevare, i punti di intervento da analizzare (input utente, output, chiamate degli strumenti (anteprima) e risposte degli strumenti (anteprima)), e le azioni da intraprendere quando viene rilevato un rischio. I filtri dei contenuti vengono eseguiti in linea con le richieste di modello e possono essere configurati per ogni distribuzione. Per ulteriori informazioni, vedere Panoramica su guardrail e controlli e Livelli di gravità del filtraggio dei contenuti.

Disponibilità regionale

Le capacità di calcolo variano in base all'area di Azure. Disponibilità del modello, opzioni del tipo di distribuzione e supporto delle funzionalità, ad esempio agenti o valutazioni, possono variare in diverse aree. Verificare che l'area di destinazione supporti le funzionalità necessarie prima del provisioning. Per la disponibilità corrente, vedere Disponibilità delle funzionalità tra aree cloud.

Archiviazione dati

Foundry offre opzioni di storage dati flessibili e sicure per supportare un'ampia gamma di carichi di lavoro di intelligenza artificiale.

Archiviazione gestita per il caricamento di file

Nella configurazione predefinita, Foundry usa account di archiviazione gestiti Microsoft che sono separati logicamente e supportano i caricamenti diretti dei file per i casi d'uso selezionati, ad esempio modelli OpenAI e agenti, senza richiedere un account di archiviazione fornito dal cliente.

Porta il tuo spazio di archiviazione

Facoltativamente, è possibile connettere i propri account Archiviazione di Azure. Gli strumenti della fonderia, come le valutazioni e l'elaborazione batch, possono leggere input da e scrivere output su questi conti. Per informazioni dettagliate sugli scenari supportati, vedere Bring-your-own resources with the Agent service.

Archiviazione dello stato dell'agente

• Con la configurazione dell'agente basic, il servizio Agent archivia thread, messaggi e file nell'archiviazione multi-tenant gestita Microsoft, con separazione logica.
• Con la configurazione dell'agente standard, è possibile usare risorse Azure personalizzate per tutti i dati dei clienti, inclusi file, conversazioni e archivi vettoriali. In questa configurazione i dati vengono isolati dal progetto all'interno degli account di archiviazione.

Crittografia della chiave gestita dal cliente

Per impostazione predefinita, i servizi di Azure crittografano i dati a riposo e in transito usando chiavi gestite da Microsoft con crittografia AES a 256 bit conforme a FIPS 140-2. Non sono necessarie modifiche al codice.

Per usare le chiavi personalizzate, verificare invece questi prerequisiti prima di abilitare le chiavi gestite dal cliente per Foundry:

• Key Vault viene distribuito nella stessa area Azure della risorsa Foundry.
• L'eliminazione reversibile e la protezione da purga sono abilitate in Key Vault.
• Le identità gestite hanno i permessi di chiave necessari, come il ruolo Key Vault Crypto User quando si utilizza Azure RBAC.

Porta il tuo Key Vault

Per impostazione predefinita, Foundry archivia tutti i segreti di connessione basati su chiavi API in un Azure Key Vault gestito. Se si preferisce gestire i segreti personalmente, connettere il Key Vault alla risorsa Foundry. Una connessione Azure Key Vault gestisce tutti i segreti di connessione a livello di progetto e risorsa. Per altre informazioni, vedere come configurare una connessione Azure Key Vault a Foundry.

Per altre informazioni sulla crittografia dei dati, vedere Chiavi gestite dal cliente per la crittografia con Foundry.

Residenza e conformità dei dati

Foundry archivia tutti i dati inattivi nell'area geografica Azure designata. I dati di inferenza (richieste e completamenti) vengono elaborati in base al tipo di distribuzione: le distribuzioni globali potrebbero instradare in qualsiasi area di Azure, le distribuzioni delle zone dati rimangono all'interno della zona Stati Uniti o dell'UE, e le distribuzioni standard o regionali vengono elaborate nella regione di distribuzione. Per informazioni dettagliate, vedere Tipi di distribuzione. Foundry non supporta il failover automatico tra regioni. Se l'organizzazione richiede la disponibilità in più aree, distribuire risorse Foundry separate in ogni area di destinazione e gestire la sincronizzazione e il routing dei dati a livello di applicazione. Per informazioni dettagliate sulla certificazione di conformità, vedere Azure documentazione sulla conformità.

Convalidare le decisioni relative all'architettura

Prima dell'implementazione, convalidare quanto segue per l'ambiente di destinazione:

• Verificare che i modelli e le funzionalità necessari siano disponibili nelle aree di distribuzione. Per informazioni dettagliate, vedere Disponibilità delle funzionalità tra aree cloud.
• Verificare che le assegnazioni di ruolo siano scoperte correttamente sia a livello di risorsa di Foundry sia a livello di progetto. Per informazioni dettagliate, vedere Controllo degli accessi in base al ruolo per Microsoft Foundry.
• Convalidare i requisiti di isolamento della rete e i percorsi di accesso privato. Per informazioni dettagliate, vedere Come configurare un private link per Foundry.
• Verificare i requisiti di crittografia e gestione dei segreti, incluse le chiavi gestite dal cliente e l'integrazione Azure Key Vault. Per informazioni dettagliate, vedere Chiavi gestite daCustomer per la crittografia con Foundry e come configurare una connessione Azure Key Vault a Foundry.
• Rivedi le quote e i limiti per le tue risorse di destinazione, inclusi i limiti di distribuzione dei modelli e i limiti di frequenza. Per informazioni dettagliate, vedere quote e limiti di Azure OpenAI e limiti del servizio agenti, quote e regioni.

Contenuti correlati

• Implementazione di Foundry nell'organizzazione
• Controllo degli accessi in base al ruolo per Microsoft Foundry
• Chiavi gestite dal cliente per la crittografia con Foundry
• Come configurare un private link per Foundry
• Risorse self-service con il servizio Agent
• Panoramica di Monitoraggio di Azure
• Quote e limiti di Azure OpenAI
• Tipi di distribuzione per i modelli Foundry
• Panoramica delle protezioni e dei controlli
• Disponibilità delle funzionalità tra aree cloud