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

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 prompt flow 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 componenti di questa architettura sono gli stessi dell'architettura di chat end-to-end di Azure OpenAI di base. Nell'elenco seguente vengono evidenziate solo le modifiche apportate all'architettura di base.

• Azure OpenAI viene usato sia nell'architettura di base che in questa architettura di base. Azure OpenAI è un servizio completamente gestito che fornisce l'accesso all'API REST ai modelli linguistici di Azure OpenAI, tra cui GPT-4, GPT-3.5-Turbo e il set di modelli di incorporamento. L'architettura di base sfrutta le funzionalità aziendali, ad esempio la rete virtuale e il collegamento privato, che l'architettura di base non implementa.
• Gateway applicazione è un load balancer di livello 7 (HTTP/S) e gestione traffico Web. Usa il routing basato sul percorso URL per distribuire il traffico in ingresso tra zone di disponibilità e esegue l'offload della crittografia per migliorare le prestazioni dell'applicazione.
• Web Application Firewall (WAF) è un servizio nativo del cloud che protegge le app Web da exploit comuni come SQL injection e cross-site scripting. WAF offre visibilità sul traffico da e verso l'applicazione Web, consentendo di monitorare e proteggere l'applicazione.
• Azure Key Vault è un servizio cloud che archivia e gestisce in modo sicuro informazioni sensibili, come segreti, chiavi di crittografia e certificati. Centralizza la gestione delle informazioni riservate.
• Rete virtuale di Azure è un servizio che consente di creare reti virtuali private isolate e sicure in Azure. Per un'applicazione Web in servizio app, è necessaria una subnet di rete virtuale per usare endpoint privati per la comunicazione sicura di rete tra le risorse.
• Collegamento privato consente ai client di accedere ai servizi PaaS (Platform as a Service) di Azure direttamente da reti virtuali private senza usare indirizzi IP pubblici.
• DNS di Azure è un servizio di hosting per i domini DNS che offre la risoluzione dei nomi usando l'infrastruttura di Microsoft Azure. Le zone di DNS privato consentono di eseguire il mapping del nome di dominio completo (FQDN) di un servizio all'indirizzo IP di un endpoint privato.

Raccomandazioni e considerazioni

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

L'architettura di base applicazione Web del servizio app è incentrata sulla ridondanza di zona per i servizi a livello di area chiave. Le zone di disponibilità sono località separate fisicamente entro 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 maggiori informazioni, consultare la sezione 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 prompt flow 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 prompt flow, 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 prompt flow 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 AKS devono prendere in considerazione la distribuzione in tale ambiente, soprattutto se AKS 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 prompt flow 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 contenitori. 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 prompt flow 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 contenitori tramite un endpoint privato durante il caricamento dell'immagine del contenitore del prompt flow.

4. Il contenitore del prompt flow deve connettersi a tutti i servizi dipendenti per l'esecuzione del flusso. In questa architettura, il contenitore del prompt flow si connette ad AI Search 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 sia sufficiente assegnato dalla quota per soddisfare la domanda per le distribuzioni e impedire la limitazione delle chiamate ai modelli distribuiti. Un gateway come API Management di Azure può essere distribuito davanti al servizio o ai servizi OpenAI e può essere configurato per riprovare se sono presenti errori temporanei e limitazioni. API Management può essere usato anche come interruttore per impedire al servizio di essere sovraccaricato con la chiamata, superandone la quota.

AI Search - Affidabilità

Distribuire AI Search 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 AI Search.

• 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

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

Questa architettura estende il footprint di sicurezza implementato nella chat end-to-end Basic con l'architettura Azure Open AI. L'architettura implementa un perimetro di sicurezza di rete, insieme al perimetro di identità implementato nell'architettura di base. 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.

Oltre alle considerazioni sulla rete, questa sezione descrive le considerazioni sulla sicurezza per la rotazione delle chiavi e l'ottimizzazione del modello OpenAI di Azure.

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:

• Un singolo punto di ingresso sicuro per il traffico UI chat.
• Il traffico di rete è filtrato.
• I dati in transito vengono crittografati end-to-end con TLS (Transport Layer Security).
• L'esfiltrazione dei dati viene ridotta al minimo 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 prompt flow 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 che servono 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.

Tutto il traffico di altro tipo viene rifiutato esplicitamente.

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 NSG a ogni subnet laddove possibile. Usare le regole più rigide che abilitano la funzionalità completa della soluzione.

• Usare gruppi di sicurezza applicazione per raggruppare gli NSG. Il raggruppamento degli NSG semplifica la creazione di regole per ambienti complessi.

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 prompt flow.

• 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 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 degli NSG.
• Richiedere la crittografia, ad esempio l'uso di chiavi gestite dal cliente.

Assegnazioni di ruolo dell'area di lavoro di Azure Machine Learning per Azure Key Vault

L'identità gestita dell'area di lavoro di Azure Machine Learning richiede sia le assegnazioni di ruolo del piano di controllo (Collaboratore) che del piano dati (amministratore dell'insieme di credenziali delle chiavi). Ciò significa che questa identità ha accesso in lettura e scrittura a tutti i segreti, le chiavi e i certificati archiviati in Azure Key Vault. Se il carico di lavoro dispone di servizi diversi da Azure Machine Learning che richiedono l'accesso a segreti, chiavi o certificati in Key Vault, il carico di lavoro o il team di sicurezza potrebbe non avere familiarità con l'identità gestita dell'area di lavoro di Azure Machine Learning che ha accesso a tali artefatti. In questo caso, è consigliabile distribuire un'istanza di Key Vault specificamente per l'area di lavoro di Azure Machine Learning e altre istanze di Azure Key Vault in base alle esigenze di altre parti del carico di lavoro.

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 l'ottimizzazione dei 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 prompt flow e ricerca di intelligenza artificiale. Ottimizzare queste risorse per risparmiare il maggior costo.

Calcolo

Il prompt flow di Machine Learning supporta più opzioni per ospitare i flussi eseguibili. Le opzioni includono endpoint online gestiti in Machine Learning, AKS, 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 approvati. 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 AI 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.

• Comprendere i modello 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 del 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 copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Machine Learning - Runtime del prompt flow predefiniti

Come nell'architettura di base, questa architettura usa il runtime automatico 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 prompt flow al file requirements.txt e flow.dag.yaml alla configurazione dell'applicazione 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

Come nell'architettura di base, 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 dell'utente 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 Contenitori
• 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 GenAIOps con prompt flow 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 GenAIOps. 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 prompt flow 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/CLI del prompt flow per lo sviluppo. Gli autori del prompt flow 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 pannello Files, 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.

• Fluidità: 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/Lo scienziato dei dati apre un ramo di funzionalità in cui lavora per l'attività o la funzionalità specifica. Il tecnico del prompt/Lo scienziato dei dati esegue l'iterazione del flusso usando il prompt flow 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/lo scienziato dei dati apre una richiesta pull dal ramo funzionalità al ramo principale. 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 codice statico

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 prompt flow 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 funzionalità viene unito al ramo principale.

4. L'unione al ramo principale attiva il processo di compilazione e rilascio per l'ambiente di sviluppo. In particolare:

   1. La pipeline CI viene attivata dall'unione al ramo principale. 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 viene integrato nel processo di promozione della versione: una volta approvati, vengono avviati i processi CI e CD descritti nei passaggi 4.a. & 4.b. vengono ripetuti, destinati all'ambiente di testing. I passaggi a. e b. sono gli stessi, ad eccezione del fatto che i test di accettazione dell'utente vengono eseguiti dopo smoke test nell’ambiente di testing.

6. I processi CI & CD descritti nei passaggi 4.a. & 4.b. vengono eseguiti per promuovere la versione rilasciata nell'ambiente di produzione dopo che l'ambiente di testing è stato verificato e approvato.

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 prompt flow 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 prompt flow 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 prompt flow o alle distribuzioni del modello.

• Area di lavoro di Machine Learning
• Account di archiviazione per l'area di lavoro di Machine Learning
• Registro contenitori
• AI Search
• 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 prompt flow 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 prompt flow 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à di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per maggiori informazioni, consultare la sezione 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 AI Search.

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 stressor sulla piattaforma.

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

Machine Learning - efficienza delle prestazioni

Se si distribuisce 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 & 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 Azure OpenAI
• prompt flow di Machine Learning
• Isolamento rete virtuale gestita dell'area di lavoro
• Configurare un endpoint privato per un'area di lavoro di Azure Machine Learning
• Filtri dei contenuti