Architettura di riferimento della chat end-to-end OpenAI di base

Le applicazioni di chat aziendali possono consentire ai dipendenti di interagire con conversazioni. Ciò è particolarmente vero a causa del continuo progresso dei modelli linguistici, ad esempio i modelli GPT di OpenAI e i modelli LLaMA di Meta. Queste applicazioni di chat sono costituite da un'interfaccia utente di chat, repository di dati che contengono informazioni specifiche del dominio pertinenti alle query dell'utente, modelli linguistici che ragionano sui dati specifici del dominio per produrre una risposta pertinente e un agente di orchestrazione che supervisiona l'interazione tra questi componenti.

Questo articolo fornisce un'architettura di base per la creazione e la distribuzione di applicazioni di chat aziendali che usano modelli linguistici del servizio OpenAI di Azure. L'architettura usa il flusso di prompt di Azure Machine Learning per creare flussi eseguibili. Questi flussi eseguibili orchestrano il flusso di lavoro dai prompt in ingresso agli archivi dati per recuperare i dati di base per i modelli di linguaggio, insieme ad altre logiche Python necessarie. Il flusso eseguibile viene distribuito in un cluster di calcolo di Machine Learning dietro un endpoint online gestito.

L'hosting dell'interfaccia utente di chat personalizzata segue le linee guida dell'applicazione Web dei servizi app di base per la distribuzione di un'applicazione Web sicura, con ridondanza della zona e a disponibilità elevata nei servizi app Azure. In tale architettura, servizio app comunica con la soluzione PaaS (Platform as a Service) di Azure tramite l'integrazione della rete virtuale su endpoint privati. L'interfaccia utente della chat servizio app comunica con l'endpoint online gestito per il flusso su un endpoint privato. L'accesso pubblico all'area di lavoro di Machine Learning è disabilitato.

L'area di lavoro di Machine Learning è configurata con isolamento della rete virtuale gestita che richiede l'approvazione di tutte le connessioni in uscita. Con questa configurazione viene creata una rete virtuale gestita, insieme agli endpoint privati gestiti che consentono la connettività alle risorse private, ad esempio l'area di lavoro Archiviazione di Azure, Registro Azure Container e Azure OpenAI. Queste connessioni private vengono usate durante la creazione e il test del flusso e dai flussi distribuiti nell'ambiente di calcolo di Machine Learning.

Architettura

Scaricare un file di Visio di questa architettura.

Componenti

Molti dei componenti di questa architettura sono gli stessi delle risorse nella baseline servizio app'architettura dell'applicazione Web perché il metodo usato per ospitare l'interfaccia utente della chat è lo stesso in entrambe le architetture. I componenti evidenziati in questa sezione si concentrano sui componenti usati per creare e orchestrare flussi di chat, servizi dati e servizi che espongono i modelli linguistici.

• Machine Learning è un servizio cloud gestito che è possibile usare per eseguire il training, la distribuzione e la gestione di modelli di Machine Learning. Questa architettura usa diverse altre funzionalità di Machine Learning usate per sviluppare e distribuire flussi eseguibili per applicazioni di intelligenza artificiale basate su modelli linguistici:

  • Il flusso di richieste di Machine Learning è uno strumento di sviluppo che è possibile usare per compilare, valutare e distribuire flussi che collegano richieste degli utenti, azioni tramite codice Python e chiamate ai modelli di apprendimento del linguaggio. Il flusso di richiesta viene usato in questa architettura come livello che orchestra i flussi tra il prompt, archivi dati diversi e il modello linguistico.

  • Gli endpoint online gestiti consentono di distribuire un flusso per l'inferenza in tempo reale. In questa architettura vengono usati come endpoint PaaS per l'interfaccia utente della chat per richiamare i flussi di prompt ospitati da Machine Learning.

• L'archiviazione viene usata per rendere persistenti i file di origine del flusso di richiesta per lo sviluppo del flusso di richiesta.

• Registro Contenitori consente di compilare, archiviare e gestire immagini e artefatti del contenitore in un registro privato per tutti i tipi di distribuzioni di contenitori. In questa architettura i flussi vengono inseriti in un pacchetto come immagini del contenitore e archiviati in Registro Container.

• Azure OpenAI è un servizio completamente gestito che fornisce l'accesso api REST ai modelli linguistici di Azure OpenAI, tra cui il set di modelli GPT-4, GPT-3.5-Turbo e incorporamenti. In questa architettura, oltre all'accesso al modello, viene usato per aggiungere funzionalità aziendali comuni, ad esempio rete virtuale e collegamento privato, supporto delle identità gestite e filtro del contenuto.

• Ricerca di intelligenza artificiale di Azure è un servizio di ricerca cloud che supporta la ricerca full-text, la ricerca semantica, la ricerca vettoriale e la ricerca ibrida. La ricerca di intelligenza artificiale è inclusa nell'architettura perché è un servizio comune usato nei flussi dietro le applicazioni di chat. La ricerca di intelligenza artificiale può essere usata per recuperare e indicizzare i dati rilevanti per le query utente. Il flusso di richiesta implementa il modello di generazione aumentata del recupero RAG per estrarre la query appropriata dal prompt, eseguire query su Ricerca di intelligenza artificiale e usare i risultati come dati di base per il modello OpenAI di Azure.

Flusso di richiesta di Machine Learning

Il back-end per le applicazioni di chat aziendali segue in genere un modello simile al flusso seguente:

• L'utente immette un prompt in un'interfaccia utente di chat personalizzata.
• Tale richiesta viene inviata al back-end dal codice dell'interfaccia.
• La finalità dell'utente, domanda o direttiva, viene estratta dalla richiesta dal back-end.
• Facoltativamente, il back-end determina gli archivi dati che contengono i dati pertinenti alla richiesta dell'utente
• Il back-end esegue una query sugli archivi dati pertinenti.
• Il back-end invia la finalità, i dati di base pertinenti e qualsiasi cronologia fornita nella richiesta al modello linguistico.
• Il back-end restituisce il risultato in modo che possa essere visualizzato nell'interfaccia utente.

Il back-end può essere implementato in un numero qualsiasi di lingue e distribuito in vari servizi di Azure. Questa architettura usa il flusso di prompt di Machine Learning perché offre un'esperienza semplificata per compilare, testare e distribuire flussi che orchestrano tra prompt, archivi dati back-end e modelli linguistici.

Runtime del flusso di richiesta

Machine Learning può ospitare direttamente due tipi di runtime del flusso di richiesta.

• Runtime automatico: opzione di calcolo serverless che gestisce le caratteristiche del ciclo di vita e delle prestazioni del calcolo e consente la personalizzazione basata sul flusso dell'ambiente.

• Runtime dell'istanza di calcolo: opzione di calcolo sempre attiva in cui il team del carico di lavoro deve selezionare le caratteristiche delle prestazioni. Questo runtime offre maggiore personalizzazione e controllo dell'ambiente.

I flussi di prompt possono anche essere ospitati esternamente all'ambiente di calcolo di Machine Learning nelle piattaforme host host contenitore. Questa architettura usa servizio app per illustrare l'hosting esterno.

Rete

Oltre all'accesso basato sull'identità, la sicurezza di rete è alla base dell'architettura di chat end-to-end di base che usa OpenAI. Da un livello elevato, l'architettura di rete garantisce che:

• Solo un singolo punto di ingresso sicuro per il traffico dell'interfaccia utente della chat.
• Il traffico di rete viene filtrato.
• I dati in transito vengono crittografati end-to-end con Transport Layer Security (TLS).
• L'esfiltrazione dei dati viene ridotta a icona usando collegamento privato per mantenere il traffico in Azure.
• Le risorse di rete sono raggruppate e isolate logicamente l'una dall'altra tramite la segmentazione di rete.

Flussi di rete

Due flussi in questo diagramma sono trattati nella baseline servizio app'architettura dell'applicazione Web: il flusso in ingresso dall'utente finale all'interfaccia utente della chat (1) e il flusso da servizio app ai servizi PaaS di Azure (2). Questa sezione è incentrata sul flusso di endpoint online di Machine Learning. Il flusso seguente passa dall'interfaccia utente della chat eseguita nella baseline servizio app'applicazione Web al flusso distribuito nell'ambiente di calcolo di Machine Learning:

1. La chiamata dall'interfaccia utente della chat ospitata servizio app viene instradata tramite un endpoint privato all'endpoint online di Machine Learning.
2. L'endpoint online instrada la chiamata a un server che esegue il flusso distribuito. L'endpoint online funge sia da servizio di bilanciamento del carico che da router.
3. Le chiamate ai servizi PaaS di Azure richiesti dal flusso distribuito vengono instradate tramite endpoint privati gestiti.

Ingresso in Machine Learning

In questa architettura l'accesso pubblico all'area di lavoro di Machine Learning è disabilitato. Gli utenti possono accedere all'area di lavoro tramite accesso privato perché l'architettura segue l'endpoint privato per la configurazione dell'area di lavoro di Machine Learning. In realtà, gli endpoint privati vengono usati in questa architettura per integrare la sicurezza basata sull'identità. Ad esempio, l'interfaccia utente della chat ospitata servizio app può connettersi ai servizi PaaS che non sono esposti alla rete Internet pubblica, inclusi gli endpoint di Machine Learning.

L'accesso all'endpoint privato è necessario anche per la connessione all'area di lavoro di Machine Learning per la creazione di flussi.

Il diagramma mostra un autore del flusso di richiesta che si connette tramite Azure Bastion a una jump box della macchina virtuale. Da tale jump box, l'autore può connettersi all'area di lavoro di Machine Learning tramite un endpoint privato nella stessa rete della jump box. La connettività alla rete virtuale può essere eseguita anche tramite i gateway ExpressRoute o VPN e il peering di rete virtuale.

Passare dalla rete virtuale gestita di Machine Learning ai servizi PaaS di Azure

È consigliabile configurare l'area di lavoro di Machine Learning per l'isolamento della rete virtuale gestita che richiede l'approvazione di tutte le connessioni in uscita. Questa architettura segue questa raccomandazione. Esistono due tipi di regole in uscita approvate. Le regole in uscita necessarie sono quelle necessarie per il funzionamento della soluzione, ad esempio Registro Contenitori e Archiviazione. Le regole in uscita definite dall'utente si basano su risorse personalizzate, ad esempio Azure OpenAI o Ai Search, che il flusso di lavoro userà. È necessario configurare le regole in uscita definite dall'utente. Le regole in uscita obbligatorie vengono configurate quando viene creata la rete virtuale gestita.

Le regole in uscita possono essere endpoint privati, tag di servizio o nomi di dominio completi (FQDN) per endpoint pubblici esterni. In questa architettura, la connettività ai servizi di Azure, ad esempio Registro Contenitori, Archiviazione, Azure Key Vault, Azure OpenAI e Ricerca di intelligenza artificiale sono connesse tramite collegamento privato. Anche se non in questa architettura, alcune operazioni comuni che potrebbero richiedere la configurazione di una regola in uscita FQDN scaricano un pacchetto pip, clonano un repository GitHub o scaricano immagini del contenitore di base da repository esterni.

Segmentazione e sicurezza della rete virtuale

La rete in questa architettura ha subnet separate per gli scopi seguenti:

• Gateway applicazione
• componenti di integrazione servizio app
• Endpoint privati
• Azure Bastion
• Macchina virtuale Jump Box
• Training: non usato per il training del modello in questa architettura
• Punteggio

Ogni subnet ha un gruppo di sicurezza di rete (NSG) che limita il traffico in ingresso e in uscita per tali subnet solo a ciò che è necessario. Nella tabella seguente viene illustrata una visualizzazione semplificata delle regole del gruppo di sicurezza di rete aggiunte dalla baseline a ogni subnet. La tabella fornisce il nome e la funzione della regola.

Subnet	In ingresso	In uscita
snet-appGateway	Quote per gli indirizzi IP di origine degli utenti dell'interfaccia utente della chat (ad esempio Internet pubblico), oltre agli elementi necessari per il servizio.	Accesso all'endpoint privato servizio app, oltre agli elementi necessari per il servizio.
snet-PrivateEndpoints	Consentire solo il traffico dalla rete virtuale.	Consentire solo il traffico verso la rete virtuale.
snet-AppService	Consentire solo il traffico dalla rete virtuale.	Consentire l'accesso agli endpoint privati e a Monitoraggio di Azure.
AzureBastionSubnet	Vedere le linee guida in Uso dell'accesso al gruppo di sicurezza di rete e Azure Bastion.	Vedere le linee guida in Uso dell'accesso al gruppo di sicurezza di rete e Azure Bastion.
snet-jumpbox	Consentire RDP (Remote Desktop Protocol) in ingresso e SSH dalla subnet host di Azure Bastion.	Consentire l'accesso agli endpoint privati
snet-agents	Consentire solo il traffico dalla rete virtuale.	Consentire solo il traffico verso la rete virtuale.
snet-training	Consentire solo il traffico dalla rete virtuale.	Consentire solo il traffico verso la rete virtuale.
assegnazione dei punteggi snet	Consentire solo il traffico dalla rete virtuale.	Consentire solo il traffico verso la rete virtuale.

Tutto l'altro traffico viene negato in modo esplicito.

Quando si implementano la segmentazione e la sicurezza della rete virtuale, tenere presente quanto segue.

• Abilitare Protezione DDoS per la rete virtuale con una subnet che fa parte di un gateway applicazione con un indirizzo IP pubblico.

• Aggiungere un gruppo di sicurezza di rete a ogni subnet laddove possibile. Usare le regole più rigide che abilitano la funzionalità completa della soluzione.

• Usare i gruppi di sicurezza delle applicazioni per raggruppare i gruppi di sicurezza di rete. Il raggruppamento dei gruppi di sicurezza di rete semplifica la creazione di regole per ambienti complessi.

Monitoraggio di filtri e abusi sui contenuti

Azure OpenAI include un sistema di filtro del contenuto che usa un insieme di modelli di classificazione per rilevare e impedire categorie specifiche di contenuto potenzialmente dannoso sia nelle richieste di input che nei completamenti di output. Le categorie per questo contenuto potenzialmente dannoso includono odio, sesso, autolesionismo, violenza, volgarità e jailbreak (contenuto progettato per ignorare i vincoli di un modello linguistico). È possibile configurare la rigidità di ciò che si vuole filtrare il contenuto per ogni categoria, con opzioni di bassa, media o alta. Questa architettura di riferimento adotta un approccio rigoroso. Modificare le impostazioni in base alle esigenze.

Oltre al filtro dei contenuti, Azure OpenAI implementa funzionalità di monitoraggio degli abusi. Il monitoraggio degli abusi è un'operazione asincrona progettata per rilevare e attenuare le istanze di contenuto o comportamenti ricorrenti che suggeriscono l'uso del servizio in modo da violare il codice di comportamento di Azure OpenAI. È possibile richiedere un'esenzione dal monitoraggio degli abusi e dalla revisione umana se i dati sono altamente sensibili o se sono presenti criteri interni o normative legali applicabili che impediscono l'elaborazione dei dati per il rilevamento degli abusi.

Affidabilità

L'architettura di base servizio app'applicazione Web è incentrata sulla ridondanza di zona per i servizi a livello di area chiave. Le zone di disponibilità sono posizioni fisicamente separate all'interno di un'area. Forniscono ridondanza all'interno di un'area per i servizi di supporto quando due o più istanze vengono distribuite tra di esse. Quando una zona riscontra tempi di inattività, le altre zone all'interno dell'area potrebbero comunque non essere interessate. L'architettura garantisce anche un numero sufficiente di istanze di servizi di Azure e la configurazione di tali servizi da distribuire tra zone di disponibilità. Per altre informazioni, vedere la linea di base per esaminare tale materiale sussidiario.

Questa sezione illustra l'affidabilità dal punto di vista dei componenti di questa architettura non risolti nella baseline di servizio app, tra cui Machine Learning, Azure OpenAI e Ricerca di intelligenza artificiale.

Ridondanza di zona per le distribuzioni di flussi

Le distribuzioni aziendali richiedono in genere ridondanza di zona. Per ottenere la ridondanza di zona in Azure, le risorse devono supportare le zone di disponibilità ed è necessario distribuire almeno tre istanze della risorsa o abilitare il supporto della piattaforma quando il controllo dell'istanza non è disponibile. Attualmente, l'ambiente di calcolo di Machine Learning non offre supporto per le zone di disponibilità. Per ridurre il potenziale impatto di una catastrofe a livello di data center sui componenti di Machine Learning, è necessario stabilire cluster in varie aree insieme alla distribuzione di un servizio di bilanciamento del carico per distribuire le chiamate tra questi cluster. È possibile usare i controlli di integrità per garantire che le chiamate vengano instradate solo ai cluster che funzionano correttamente.

La distribuzione dei flussi di prompt non è limitata ai cluster di calcolo di Machine Learning. Il flusso eseguibile, essendo un'applicazione in contenitori, può essere distribuito in qualsiasi servizio di Azure compatibile con i contenitori. Queste opzioni includono servizi come servizio Azure Kubernetes (servizio Azure Kubernetes), Funzioni di Azure, App Azure Container e servizio app. Ognuno di questi servizi supporta le zone di disponibilità. Per ottenere la ridondanza di zona per l'esecuzione del flusso di richiesta, senza la complessità aggiunta di una distribuzione in più aree, è necessario distribuire i flussi in uno di questi servizi.

Il diagramma seguente illustra un'architettura alternativa in cui i flussi di richiesta vengono distribuiti in servizio app. servizio app viene usato in questa architettura perché il carico di lavoro lo usa già per l'interfaccia utente della chat e non trarrà vantaggio dall'introduzione di una nuova tecnologia nel carico di lavoro. I team del carico di lavoro con il servizio Azure Kubernetes devono prendere in considerazione la distribuzione in tale ambiente, soprattutto se il servizio Azure Kubernetes viene usato per altri componenti nel carico di lavoro.

Il diagramma è numerato per le aree rilevanti in questa architettura:

1. I flussi vengono ancora creati nel flusso di richiesta di Machine Learning e l'architettura di rete di Machine Learning rimane invariata. Gli autori di flussi si connettono ancora all'esperienza di creazione dell'area di lavoro tramite un endpoint privato e gli endpoint privati gestiti vengono usati per connettersi ai servizi di Azure durante il test dei flussi.

2. Questa linea punteggiata indica che i flussi eseguibili in contenitori vengono inseriti nel Registro Container. Non illustrato nel diagramma sono le pipeline in cui vengono inseriti in contenitori i flussi e il push in Registro Contenitori.

3. È disponibile un'altra app Web distribuita nello stesso piano di servizio app che ospita già l'interfaccia utente della chat. La nuova app Web ospita il flusso del prompt in contenitori, con lo stesso piano di servizio app che è già in esecuzione su almeno tre istanze, distribuite tra le zone di disponibilità. Queste istanze servizio app si connettono al Registro Container tramite un endpoint privato durante il caricamento dell'immagine del contenitore del flusso di richiesta.

4. Il contenitore del flusso di richiesta deve connettersi a tutti i servizi dipendenti per l'esecuzione del flusso. In questa architettura il contenitore del flusso di prompt si connette a Ricerca di intelligenza artificiale e Azure OpenAI. Anche i servizi PaaS esposti solo alla subnet dell'endpoint privato gestito di Machine Learning devono essere esposti nella rete virtuale in modo che sia possibile stabilire una linea di vista da servizio app.

Azure OpenAI - Affidabilità

Azure OpenAI attualmente non supporta le zone di disponibilità. Per ridurre il potenziale impatto di una catastrofe a livello di data center nelle distribuzioni di modelli in Azure OpenAI, è necessario distribuire Azure OpenAI in varie aree insieme alla distribuzione di un servizio di bilanciamento del carico per distribuire le chiamate tra le aree. È possibile usare i controlli di integrità per garantire che le chiamate vengano instradate solo ai cluster che funzionano correttamente.

Per supportare in modo efficace più istanze, è consigliabile esternalizzare i file di ottimizzazione, ad esempio in un account di archiviazione con ridondanza geografica. Questo approccio riduce al minimo lo stato archiviato in Azure OpenAI per ogni area. È comunque necessario ottimizzare i file per ogni istanza per ospitare la distribuzione del modello.

È importante monitorare la velocità effettiva richiesta in termini di token al minuto (TPM) e richieste al minuto (RPM). Assicurarsi che il TPM u assegnato dalla quota sia sufficiente per soddisfare la domanda delle distribuzioni e impedire che le chiamate ai modelli distribuiti vengano limitate. Un gateway come Azure Gestione API può essere distribuito davanti al servizio o ai servizi OpenAI e può essere configurato per riprovare se sono presenti errori temporanei e limitazioni. Gestione API può essere usato anche come interruttore per impedire al servizio di essere sovraccaricato con la chiamata, superandone la quota.

Ricerca di intelligenza artificiale - Affidabilità

Distribuire La ricerca di intelligenza artificiale con il piano tariffario Standard o superiore in un'area che supporta le zone di disponibilità e distribuire tre o più repliche. Le repliche vengono distribuite automaticamente in modo uniforme tra le zone di disponibilità.

Considerare le indicazioni seguenti per determinare il numero appropriato di repliche e partizioni:

• Monitorare la ricerca di intelligenza artificiale.

• Usare le metriche di monitoraggio e i log e l'analisi delle prestazioni per determinare il numero appropriato di repliche per evitare limitazioni e partizioni basate su query e per evitare la limitazione basata su indici.

Machine Learning - Affidabilità

Se si esegue la distribuzione in cluster di calcolo dietro l'endpoint online gestito da Machine Learning, prendere in considerazione le indicazioni seguenti relative al ridimensionamento:

• Ridimensionare automaticamente gli endpoint online per garantire una capacità sufficiente per soddisfare la domanda. Se i segnali di utilizzo non sono abbastanza tempestivi a causa dell'utilizzo di burst, prendere in considerazione l'overprovisioning per evitare un impatto sull'affidabilità da troppe istanze disponibili.

• Prendere in considerazione la creazione di regole di ridimensionamento in base alle metriche di distribuzione, ad esempio il carico della CPU e le metriche degli endpoint, ad esempio la latenza delle richieste.

• Non è necessario distribuire meno di tre istanze per una distribuzione di produzione attiva.

• Evitare distribuzioni in istanze in uso. Al contrario, eseguire la distribuzione in una nuova distribuzione e spostare il traffico dopo che la distribuzione è pronta per ricevere il traffico.

Sicurezza

Questa architettura implementa sia una rete che un perimetro di sicurezza delle identità. Dal punto di vista della rete, l'unica cosa che dovrebbe essere accessibile da Internet è l'interfaccia utente della chat tramite gateway applicazione. Dal punto di vista dell'identità, l'interfaccia utente della chat deve autenticare e autorizzare le richieste. Le identità gestite vengono usate, laddove possibile, per autenticare le applicazioni nei servizi di Azure.

Questa sezione descrive le considerazioni sulla gestione delle identità e degli accessi e sulla sicurezza per la rotazione delle chiavi e l'ottimizzazione del modello OpenAI di Azure.

Gestione delle identità e dell'accesso

Le linee guida seguenti estendono le linee guida per la gestione delle identità e degli accessi nella baseline di servizio app:

• Creare identità gestite separate per le risorse di Machine Learning seguenti, se applicabile:
  • Aree di lavoro per la creazione e la gestione dei flussi
  • Istanze di calcolo per i flussi di test
  • Endpoint online nel flusso distribuito se il flusso viene distribuito in un endpoint online gestito
• Implementare controlli di accesso alle identità per l'interfaccia utente della chat usando Microsoft Entra ID

Ruoli di accesso in base al ruolo di Machine Learning

Esistono cinque ruoli predefiniti che è possibile usare per gestire l'accesso all'area di lavoro di Machine Learning: AzureML Scienziato dei dati, Operatore di calcolo AzureML, Lettore, Collaboratore e Proprietario. Oltre a questi ruoli predefiniti, è disponibile un lettore di segreti per la connessione all'area di lavoro di AzureML e un utente del Registro di sistema di AzureML che può concedere l'accesso alle risorse dell'area di lavoro, ad esempio i segreti dell'area di lavoro e il Registro di sistema.

Questa architettura segue il principio dei privilegi minimi assegnando ruoli solo alle identità precedenti in cui sono necessarie. Prendere in considerazione le assegnazioni di ruolo seguenti.

Identità gestita	Ambito	Assegnazioni di ruoli
Identità gestita dell'area di lavoro	Gruppo di risorse	Collaboratore
Identità gestita dell'area di lavoro	Account di archiviazione dell'area di lavoro	Collaboratore ai dati del BLOB di archiviazione
Identità gestita dell'area di lavoro	Account di archiviazione dell'area di lavoro	Collaboratore privilegiato per i dati dei file di archiviazione
Identità gestita dell'area di lavoro	Insieme di credenziali delle chiavi dell'area di lavoro	Amministratore di Key Vault
Identità gestita dell'area di lavoro	Registro Contenitori dell'area di lavoro	AcrPush
Identità gestita degli endpoint online	Registro Contenitori dell'area di lavoro	AcrPull
Identità gestita degli endpoint online	Account di archiviazione dell'area di lavoro	Lettore dei dati del BLOB di archiviazione
Identità gestita degli endpoint online	Area di lavoro di Machine Learning	Lettore dei segreti delle connessioni all'area di lavoro di AzureML
Identità gestita dell'istanza di calcolo	Registro Contenitori dell'area di lavoro	AcrPull
Identità gestita dell'istanza di calcolo	Account di archiviazione dell'area di lavoro	Lettore dei dati del BLOB di archiviazione

Rotazione delle chiavi

In questa architettura sono disponibili due servizi che usano l'autenticazione basata su chiave: Azure OpenAI e l'endpoint online gestito di Machine Learning. Poiché si usa l'autenticazione basata su chiave per questi servizi, è importante:

• Archiviare la chiave in un archivio sicuro, ad esempio Key Vault, per l'accesso su richiesta da client autorizzati, ad esempio l'app Web di Azure che ospita il contenitore del flusso di richiesta.

• Implementare una strategia di rotazione chiave. Se si ruotano manualmente le chiavi, creare un criterio di scadenza della chiave e usare Criteri di Azure per monitorare se la chiave è stata ruotata.

Ottimizzazione dell'ottimizzazione del modello OpenAI

Se si ottimizzano i modelli OpenAI nell'implementazione, prendere in considerazione le indicazioni seguenti:

• Se si caricano dati di training per l'ottimizzazione, è consigliabile usare chiavi gestite dal cliente per crittografare tali dati.

• Se si archiviano dati di training in un archivio come Archiviazione BLOB di Azure, è consigliabile usare una chiave gestita dal cliente per la crittografia dei dati, un'identità gestita per controllare l'accesso ai dati e un endpoint privato per connettersi ai dati.

Governance tramite criteri

Per garantire l'allineamento alla sicurezza, è consigliabile usare Criteri di Azure e criteri di rete in modo che le distribuzioni siano allineate ai requisiti del carico di lavoro. L'uso dell'automazione della piattaforma tramite criteri riduce il carico di lavoro dei passaggi di convalida manuali e garantisce la governance anche se le pipeline vengono ignorate. Considerare i criteri di sicurezza seguenti:

• Disabilitare l'accesso alla chiave o ad altre autenticazioni locali nei servizi come i servizi di Intelligenza artificiale di Azure e Key Vault.
• Richiedere una configurazione specifica delle regole di accesso alla rete o dei gruppi di sicurezza di rete.
• Richiedere la crittografia, ad esempio l'uso di chiavi gestite dal cliente.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Ottimizzazione costi.

Per un esempio di prezzi per questo scenario, usare il calcolatore prezzi di Azure. È necessario personalizzare l'esempio in modo che corrisponda all'utilizzo perché questo esempio include solo i componenti inclusi nell'architettura. I componenti più costosi nello scenario sono l'interfaccia utente della chat e il calcolo del flusso di richiesta e ricerca di intelligenza artificiale. Ottimizzare queste risorse per risparmiare il maggior costo.

Calcolo

Il flusso dei prompt di Machine Learning supporta più opzioni per ospitare i flussi eseguibili. Le opzioni includono endpoint online gestiti in Machine Learning, servizio Azure Kubernetes, servizio app e servizio Azure Kubernetes. Ognuna di queste opzioni ha un proprio modello di fatturazione. La scelta del calcolo influisce sul costo complessivo della soluzione.

OpenAI di Azure

Azure OpenAI è un servizio basato sul consumo e, come per qualsiasi servizio basato sul consumo, il controllo della domanda rispetto all'offerta è il controllo dei costi primario. A tale scopo, in Azure OpenAI è necessario usare una combinazione di approcci:

• Controllare i client. Le richieste client sono l'origine principale dei costi in un modello di consumo, quindi il controllo del comportamento del client è fondamentale. Tutti i client devono:

  • Essere approvato. Evitare di esporre il servizio in modo tale che supporti l'accesso gratuito a tutti. Limitare l'accesso sia tramite controlli di rete che di identità, ad esempio chiavi o controllo degli accessi in base al ruolo.

  • Essere auto-controllati. Richiedere ai client di usare i vincoli di limitazione dei token offerti dalle chiamate API, ad esempio max_tokens e max_completions.

  • Usare l'invio in batch, dove pratico. Esaminare i client per assicurarsi che inviino in batch le richieste in modo appropriato.

  • Ottimizzare l'input della richiesta e la lunghezza della risposta. Le richieste più lunghe utilizzano più token, aumentando il costo, ma le richieste che mancano di contesto sufficiente non aiutano i modelli a produrre buoni risultati. Creare richieste concise che forniscono contesto sufficiente per consentire al modello di generare una risposta utile. Analogamente, assicurarsi di ottimizzare il limite della lunghezza della risposta.

• L'utilizzo del playground di Azure OpenAI deve essere necessario e nelle istanze di preproduzione, in modo che tali attività non incorra in costi di produzione.

• Selezionare il modello di intelligenza artificiale corretto. La selezione dei modelli svolge anche un ruolo importante nel costo complessivo di Azure OpenAI. Tutti i modelli hanno punti di forza e debolezza e sono a prezzo individuale. Usare il modello corretto per il caso d'uso per assicurarsi di non essere in sospeso su un modello più costoso quando un modello meno costoso restituisce risultati accettabili. In questa implementazione di riferimento di chat, GPT 3.5-turbo è stato scelto su GPT-4 per risparmiare circa un ordine di grandezza dei costi di distribuzione del modello, ottenendo risultati sufficienti.

• Informazioni sui punti di interruzione della fatturazione. L'ottimizzazione viene addebitata ogni ora. Per essere il più efficiente, si vuole usare la maggior parte di tale tempo disponibile all'ora per migliorare i risultati di ottimizzazione evitando di passare semplicemente al periodo di fatturazione successivo. Analogamente, il costo per 100 immagini dalla generazione di immagini è uguale al costo per un'immagine. Massimizzare i punti di interruzione del prezzo al vostro vantaggio.

• Informazioni sui modelli di fatturazione. Azure OpenAI è disponibile anche in un modello di fatturazione basato sull'impegno tramite l'offerta di velocità effettiva con provisioning. Dopo avere modelli di utilizzo prevedibili, è consigliabile passare a questo modello di fatturazione preacquisto se è più conveniente nel volume di utilizzo.

• Impostare i limiti di provisioning. Assicurarsi che tutte le quote di provisioning vengano allocate solo ai modelli che devono far parte del carico di lavoro, in base al modello. La velocità effettiva dei modelli già distribuiti non è limitata a questa quota con provisioning mentre è abilitata la quota dinamica. La quota non viene mappata direttamente ai costi e questo costo può variare.

• Monitorare l'utilizzo con pagamento in base al consumo. Se si usano prezzi con pagamento in base al consumo, monitorare l'utilizzo di TPM e RPM. Usare queste informazioni per informare le decisioni di progettazione dell'architettura, ad esempio i modelli da usare e ottimizzare le dimensioni delle richieste.

• Monitorare l'utilizzo della velocità effettiva con provisioning. Se si usa la velocità effettiva con provisioning, monitorare l'utilizzo gestito dal provisioning per assicurarsi di non usare la velocità effettiva con provisioning acquistata.

• Gestione dei costi. Seguire le indicazioni sull'uso delle funzionalità di gestione dei costi con OpenAI per monitorare i costi, impostare budget per gestire i costi e creare avvisi per notificare agli stakeholder rischi o anomalie.

Eccellenza operativa

L'eccellenza operativa descrive i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Machine Learning - Runtime predefiniti del flusso di prompt

Per ridurre al minimo il carico operativo, il runtime automatico è un'opzione di calcolo serverless all'interno di Machine Learning che semplifica la gestione delle risorse di calcolo e delega la maggior parte della configurazione del flusso di richiesta al file e flow.dag.yaml alla configurazione dell'applicazione requirements.txt in esecuzione. Ciò rende questa scelta a bassa manutenzione, temporanea e guidata dall'applicazione. L'uso del runtime dell'istanza di calcolo o del calcolo esternalizzato, ad esempio in questa architettura, richiede un ciclo di vita più gestito dal team del carico di lavoro del calcolo e deve essere selezionato quando i requisiti del carico di lavoro superano le funzionalità di configurazione dell'opzione di runtime automatico.

Monitoraggio

La diagnostica è configurata per tutti i servizi. Tutti i servizi, ma Machine Learning e servizio app sono configurati per acquisire tutti i log. La diagnostica di Machine Learning è configurata per acquisire i log di controllo che sono tutti i log delle risorse che registrano le interazioni dei clienti con i dati o le impostazioni del servizio. servizio app è configurato per acquisire AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs e AppServicePlatformLogs.

Valutare la creazione di avvisi personalizzati per le risorse in questa architettura, ad esempio quelle presenti negli avvisi di base di Monitoraggio di Azure. Ad esempio:

• Avvisi del Registro Container
• Avvisi di Machine Learning e Azure OpenAI
• Avvisi di Azure App Web

Operazioni del modello linguistico

La distribuzione per soluzioni di chat basate su OpenAI di Azure, come questa architettura, deve seguire le indicazioni in LLMOps con flusso di prompt con Azure DevOps e GitHub. Inoltre, deve prendere in considerazione le procedure consigliate per l'integrazione continua e il recapito continuo (CI/CD) e architetture protette dalla rete. Le indicazioni seguenti illustrano l'implementazione dei flussi e l'infrastruttura associata in base alle raccomandazioni LLMOps. Queste linee guida per la distribuzione non includono gli elementi dell'applicazione front-end, che non sono stati modificati nell'architettura dell'applicazione Web con ridondanza della zona a disponibilità elevata baseline.

Sviluppo

Il flusso di richieste di Machine Learning offre sia un'esperienza di creazione basata su browser in Machine Learning Studio che tramite un'estensione di Visual Studio Code. Entrambe le opzioni archiviano il codice del flusso come file. Quando si usa Machine Learning Studio, i file vengono archiviati in un account di archiviazione. Quando si lavora in Microsoft Visual Studio Code, i file vengono archiviati nel file system locale.

Per seguire le procedure consigliate per lo sviluppo collaborativo, i file di origine devono essere mantenuti in un repository di codice sorgente online, ad esempio GitHub. Questo approccio facilita il rilevamento di tutte le modifiche al codice, la collaborazione tra autori di flussi e l'integrazione con i flussi di distribuzione che testano e convalidano tutte le modifiche al codice.

Per lo sviluppo aziendale, usare l'estensione Microsoft Visual Studio Code e l'SDK/interfaccia della riga di comando del prompt per lo sviluppo. Gli autori del flusso dei prompt possono compilare e testare i flussi da Microsoft Visual Studio Code e integrare i file archiviati in locale con il sistema di controllo del codice sorgente online e le pipeline. Anche se l'esperienza basata su browser è ideale per lo sviluppo esplorativo, con alcune operazioni, può essere integrata con il sistema di controllo del codice sorgente. La cartella del flusso può essere scaricata dalla pagina del flusso nel Files pannello, decompressa e inserita nel sistema di controllo del codice sorgente.

Valutazione

Testare i flussi usati in un'applicazione di chat proprio come si testano altri artefatti software. È difficile specificare e asserire una singola risposta "corretta" per gli output del modello linguistico, ma è possibile usare un modello linguistico stesso per valutare le risposte. Valutare la possibilità di implementare le valutazioni automatizzate seguenti dei flussi del modello linguistico:

• Accuratezza della classificazione: valuta se il modello linguistico fornisce un punteggio "corretto" o "errato" e aggrega i risultati per produrre un grado di accuratezza.

• Coerenza: valuta la qualità delle frasi nella risposta stimata di un modello e il modo in cui si connettono tra loro in modo coerente.

• Fluency: valuta la risposta stimata del modello per la sua accuratezza grammaticale e linguistica.

• Base rispetto al contesto: valuta l'utilità delle risposte stimate del modello in base al contesto preconfigurato. Anche se le risposte del modello linguistico sono corrette, se non possono essere convalidate rispetto al contesto specificato, tali risposte non vengono rilevate.

• Pertinenza: valuta il grado di allineamento delle risposte stimate del modello con la domanda posta.

Quando si implementano valutazioni automatizzate, prendere in considerazione le indicazioni seguenti:

• Produrre punteggi dalle valutazioni e misurarli rispetto a una soglia di successo predefinita. Usare questi punteggi per segnalare il superamento/esito negativo dei test nelle pipeline.

• Alcuni di questi test richiedono input di dati preconfigurati di domande, contesto e verità di base.

• Includere coppie di domande-risposta sufficienti per garantire che i risultati dei test siano affidabili, con almeno 100-150 coppie consigliate. Queste coppie di domande-risposta vengono definite "set di dati d'oro". Un popolamento più ampio potrebbe essere necessario a seconda delle dimensioni e del dominio del set di dati.

• Evitare di usare i modelli linguistici per generare uno dei dati nel set di dati golden.

Flusso di distribuzione

1. Il tecnico del prompt/data scientist apre un ramo di funzionalità in cui lavora per l'attività o la funzionalità specifica. Il prompt engineer/data scientist esegue l'iterazione del flusso usando il flusso di richiesta per Microsoft Visual Studio Code, eseguendo periodicamente il commit delle modifiche ed eseguendo il push di tali modifiche nel ramo di funzionalità.

2. Al termine dello sviluppo e della sperimentazione locale, il tecnico del prompt/data scientist apre una richiesta pull dal ramo Feature al ramo Main. La richiesta pull attiva una pipeline di richiesta pull. Questa pipeline esegue controlli di qualità rapidi che devono includere:

   • Esecuzione di flussi di sperimentazione
   • Esecuzione di unit test configurati
   • Compilazione della codebase
   • Analisi statica del codice

3. La pipeline può contenere un passaggio che richiede almeno un membro del team di approvare manualmente la richiesta pull prima dell'unione. Il responsabile approvazione non può essere il commiter e ha competenze di flusso richieste e familiarità con i requisiti del progetto. Se la richiesta pull non è approvata, l'unione viene bloccata. Se la richiesta pull viene approvata o non è presente alcun passaggio di approvazione, il ramo di funzionalità viene unito al ramo Main.

4. L'unione a Main attiva il processo di compilazione e rilascio per l'ambiente di sviluppo. In particolare:

   1. La pipeline CI viene attivata dall'unione a Main. La pipeline CI esegue tutti i passaggi eseguiti nella pipeline di richiesta pull e i passaggi seguenti:
   • Flusso di sperimentazione
   • Flusso di valutazione.
   • Registra i flussi nel Registro di sistema di Machine Learning quando vengono rilevate modifiche
   1. La pipeline cd viene attivata dopo il completamento della pipeline CI. Questo flusso esegue i passaggi seguenti:
   • Distribuisce il flusso dal Registro di sistema di Machine Learning a un endpoint online di Machine Learning
   • Esegue test di integrazione destinati all'endpoint online
   • Esegue test di fumo destinati all'endpoint online

5. Un processo di approvazione è integrato nel processo di promozione del rilascio: dopo l'approvazione, i processi CI & CD descritti nei passaggi 4.a. & 4.b. vengono ripetuti, destinati all'ambiente di test. I passaggi a. e b. sono gli stessi, ad eccezione del fatto che i test di accettazione dell'utente vengono eseguiti dopo i test di fumo nell'ambiente di test.

6. I processi CI & CD descritti nei passaggi 4.a. & 4.b. vengono eseguiti per alzare di livello il rilascio all'ambiente di produzione dopo la verifica e l'approvazione dell'ambiente di test.

7. Dopo il rilascio in un ambiente live, vengono eseguite le attività operative di monitoraggio delle metriche delle prestazioni e la valutazione dei modelli linguistici distribuiti. Ciò include, ma non è limitato a:

   • Rilevamento delle deviazioni dei dati
   • Osservazione dell'infrastruttura
   • Gestione dei costi
   • Comunicazione delle prestazioni del modello agli stakeholder

Indicazioni per la distribuzione

È possibile usare gli endpoint di Machine Learning per distribuire i modelli in modo da consentire flessibilità durante il rilascio nell'ambiente di produzione. Prendere in considerazione le strategie seguenti per garantire prestazioni e qualità ottimali del modello:

• Distribuzioni blu/verde: con questa strategia, è possibile distribuire in modo sicuro la nuova versione del servizio Web in un gruppo limitato di utenti o richieste prima di indirizzare tutto il traffico alla nuova distribuzione.

• Test A/B: non solo le distribuzioni blu/verde sono efficaci per l'implementazione sicura delle modifiche, ma possono essere usate anche per distribuire un nuovo comportamento che consente a un subset di utenti di valutare l'impatto della modifica.

• Includere l'linting dei file Python che fanno parte del flusso di richiesta nelle pipeline. Linting verifica la conformità con gli standard di stile, gli errori, la complessità del codice, le importazioni inutilizzate e la denominazione delle variabili.

• Quando si distribuisce il flusso nell'area di lavoro di Machine Learning isolata dalla rete, usare un agente self-hosted per distribuire gli artefatti nelle risorse di Azure.

• Il Registro modelli di Machine Learning deve essere aggiornato solo quando sono presenti modifiche al modello.

• I modelli linguistici, i flussi e l'interfaccia utente client devono essere accoppiati in modo libero. Gli aggiornamenti ai flussi e all'interfaccia utente client possono e devono essere eseguiti senza influire sul modello e viceversa.

• Quando si sviluppano e si distribuiscono più flussi, ogni flusso deve avere un proprio ciclo di vita, che consente un'esperienza ad accoppiamento debole quando si promuove il flusso dalla sperimentazione alla produzione.

Infrastruttura

Quando si distribuiscono i componenti di chat end-to-end di Azure OpenAI di base, alcuni dei servizi di cui è stato effettuato il provisioning sono fondamentali e permanenti all'interno dell'architettura, mentre altri componenti sono più temporanei per natura, la loro esistenza associata a una distribuzione.

Componenti fondamentali

Alcuni componenti di questa architettura esistono con un ciclo di vita che si estende oltre qualsiasi singolo flusso di richiesta o qualsiasi distribuzione del modello. Queste risorse vengono in genere distribuite una volta come parte della distribuzione di base dal team del carico di lavoro e gestite oltre a nuove, rimosse o aggiornate ai flussi di richiesta o alle distribuzioni del modello.

• Area di lavoro di Machine Learning
• Account di archiviazione per l'area di lavoro di Machine Learning
• Registro Container
• Ricerca di intelligenza artificiale
• OpenAI di Azure
• Azure Application Insights
• Azure Bastion
• Macchina virtuale di Azure per il jump box

Componenti temporanei

Alcune risorse di Azure sono più strettamente associate alla progettazione di flussi di prompt specifici. Questo approccio consente di associare queste risorse al ciclo di vita del componente e diventare temporanee in questa architettura. Le risorse di Azure sono interessate quando il carico di lavoro si evolve, ad esempio quando i flussi vengono aggiunti o rimossi o quando vengono introdotti nuovi modelli. Queste risorse vengono ricreate e rimosse le istanze precedenti. Alcune di queste risorse sono risorse dirette di Azure e alcune sono manifestazioni del piano dati all'interno del servizio contenitore.

• Il modello nel Registro modelli di Machine Learning deve essere aggiornato, se modificato, come parte della pipeline cd.

• L'immagine del contenitore deve essere aggiornata nel registro contenitori come parte della pipeline cd.

• Un endpoint di Machine Learning viene creato quando viene distribuito un flusso di richiesta se la distribuzione fa riferimento a un endpoint che non esiste. L'endpoint deve essere aggiornato per disattivare l'accesso pubblico.

• Le distribuzioni dell'endpoint di Machine Learning vengono aggiornate quando un flusso viene distribuito o eliminato.

• L'insieme di credenziali delle chiavi per l'interfaccia utente client deve essere aggiornato con la chiave all'endpoint quando viene creato un nuovo endpoint.

Efficienza prestazionale

L'efficienza delle prestazioni è la capacità del carico di lavoro di ridimensionare in modo efficiente per soddisfare le esigenze poste dagli utenti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

Questa sezione descrive l'efficienza delle prestazioni dal punto di vista di Ricerca di Azure, Azure OpenAI e Machine Learning.

Ricerca di Azure - Efficienza delle prestazioni

Seguire le indicazioni per analizzare le prestazioni in Ricerca di intelligenza artificiale.

Azure OpenAI - Efficienza delle prestazioni

• Determinare se l'applicazione richiede la velocità effettiva con provisioning o l'hosting condiviso o il modello a consumo. La velocità effettiva con provisioning garantisce capacità di elaborazione riservata per le distribuzioni del modello OpenAI, che offre prestazioni prevedibili e velocità effettiva per i modelli. Questo modello di fatturazione è diverso dall'hosting condiviso o dal modello a consumo. Il modello di consumo è il miglior sforzo e potrebbe essere soggetto a rumorosi vicini o altri stressori sulla piattaforma.

• Monitorare l'utilizzo gestito del provisioning per la velocità effettiva con provisioning.

Machine Learning - Efficienza delle prestazioni

Se si esegue la distribuzione in endpoint online di Machine Learning:

• Seguire le indicazioni su come ridimensionare automaticamente un endpoint online. Eseguire questa operazione per rimanere strettamente allineati alla domanda senza un overprovisioning eccessivo, soprattutto nei periodi di basso utilizzo.

• Scegliere lo SKU della macchina virtuale appropriato per l'endpoint online per soddisfare gli obiettivi di prestazioni. Testare le prestazioni del numero di istanze inferiore e degli SKU più grandi rispetto al numero di istanze più grandi e agli SKU più piccoli per trovare una configurazione ottimale.

Distribuire lo scenario

Per distribuire ed eseguire l'implementazione di riferimento, seguire la procedura descritta nell'implementazione della baseline end-to-end OpenAI.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

• Rob Bagby | Modelli e procedure - Microsoft
• Freddy Ayala | Cloud Solution Architect - Microsoft
• Prabal Deb | Senior Software Engineer - Microsoft
• Raouf Aliouat | Software Engineer II - Microsoft
• Ritesh Modi | Principal Software Engineer - Microsoft
• Ryan Pfalz | Senior Solution Architect - Microsoft

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggio successivo

Risorse correlate

• OpenAI di Azure
• Modelli di linguaggio OpenAI di Azure
• Flusso di richiesta di Machine Learning
• Isolamento della rete virtuale gestita dell'area di lavoro
• Configurare un endpoint privato per un'area di lavoro di Machine Learning
• Filtri dei contenuti