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

Le applicazioni di chat aziendali hanno la possibilità di consentire ai dipendenti l'interazione conversazionale. Ciò è particolarmente vero a causa dell'avanzamento continuo di modelli linguistici di grandi dimensioni, come i modelli GPT di OpenAI e i modelli LLaMA di Meta. Queste applicazioni di chat sono costituite da un'interfaccia utente per la chat, i repository di dati contenenti informazioni specifiche del dominio pertinenti alle query dell'utente, modelli di linguaggio di grandi dimensioni che riguardano i 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 di grandi dimensioni di Azure OpenAI. L'architettura usa il flusso di prompt di Azure Machine Learning (AML) per creare flussi eseguibili che orchestrano il flusso di lavoro dalle richieste in ingresso agli archivi dati per recuperare i dati di base per i moduli DI MIGRAZIONE, insieme a qualsiasi altra logica Python necessaria. Il flusso eseguibile viene distribuito in un cluster di calcolo di Azure 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 il servizio app comunica con i servizi PaaS di Azure tramite l'integrazione della rete virtuale su endpoint privati. Analogamente, l'interfaccia utente della chat servizio app comunica con l'endpoint online gestito per il flusso su un endpoint privato e l'accesso pubblico all'area di lavoro di Azure 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à a 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 Azure Machine Learning.

Architettura

Figura 1: Architettura di chat end-to-end di base con OpenAI

Scaricare un file di Visio di questa architettura.

Componenti

Molti dei componenti di questa architettura sono gli stessi delle risorse nell'applicazione Web dei servizi app di base, perché l'hosting dell'interfaccia utente di chat in questa architettura segue la baseline servizio app'architettura dell'applicazione Web. I componenti evidenziati in questa sezione sono incentrati sui componenti usati per creare e orchestrare i flussi di chat e i servizi dati e i servizi che espongono i moduli DI gestione delle applicazioni.

• Azure Machine Learning è un servizio cloud gestito usato per eseguire il training, la distribuzione e la gestione di modelli di Machine Learning. Questa architettura usa diverse altre funzionalità di Azure Machine Learning usate per sviluppare e distribuire flussi eseguibili per applicazioni di intelligenza artificiale basate su modelli linguistici di grandi dimensioni:
  • Il flusso di richieste di Azure Machine Learning è uno strumento di sviluppo che consente di compilare, valutare e distribuire flussi che collegano richieste degli utenti, azioni tramite codice Python e chiamate a LLMs. Il flusso di richiesta viene usato in questa architettura come livello che orchestra i flussi tra la richiesta, diversi archivi dati e LLM.
  • 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 Azure Machine Learning.
• Archiviazione di Azure viene usato per rendere persistenti i file di origine del flusso di richiesta per lo sviluppo del flusso di richiesta.
• Registro Azure Container 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 Azure Container.
• Azure OpenAI è un servizio completamente gestito che fornisce l'accesso all'API REST ai modelli linguistici di Azure OpenAI di grandi dimensioni, tra cui il set di modelli GPT-4, GPT-3.5-Turbo e Embeddings. 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. Ricerca di intelligenza artificiale di Azure è incluso nell'architettura perché è un servizio comune usato nei flussi dietro le applicazioni di chat. Ricerca di intelligenza artificiale di Azure può essere usato per recuperare e indicizzare i dati rilevanti per le query utente. Il flusso di richiesta implementa il modello RAG Retrieval Augmented Generation 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 prompt di Azure Machine Learning

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

• L'utente immette una richiesta 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
• (facoltativo) Il back-end determina gli archivi dati che contiene i dati rilevanti per la 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 all'LLM.
• Il back-end restituisce il risultato a 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. In questa architettura è stato scelto il flusso dei prompt di Azure Machine Learning perché offre un'esperienza semplificata per compilare, testare e distribuire flussi che orchestrano tra prompt, archivi dati back-end e LLM.

Rete

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

• 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 TLS
• L'esfiltrazione dei dati viene ridotta al minimo mantenendo il traffico in Azure usando collegamento privato
• Le risorse di rete sono raggruppate logicamente e isolate l'una dall'altra tramite la segmentazione di rete

Flussi di rete

Figura 2: Flussi di rete per l'architettura di chat end-to-end di base con OpenAI

Due flussi in questo diagramma sono trattati nell'applicazione Web dei servizi app di base: 1. il flusso in ingresso dall'utente finale all'interfaccia utente della chat e 2. flusso di servizio app ai servizi PaaS di Azure. Per informazioni dettagliate su tali flussi, vedere questo articolo. Questa sezione è incentrata sul flusso di endpoint online di Azure Machine Learning. Di seguito viene dettagliato il flusso dall'interfaccia utente della chat in esecuzione nella baseline servizio app'applicazione Web al flusso distribuito nell'ambiente di calcolo di Azure Machine Learning:

1. La chiamata dall'interfaccia utente della chat ospitata servizio app viene instradata tramite un endpoint privato all'endpoint online di Azure 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 Azure Machine Learning

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

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

Figura 3: Flussi di rete per un autore del flusso di richiesta di Azure Machine Learning

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. Connessione ività 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 Azure Machine Learning ai servizi PaaS di Azure

È consigliabile configurare l'area di lavoro di Azure Machine Learning per l'isolamento della rete virtuale gestita con una configurazione 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 obbligatorie sono relative alle risorse necessarie per il funzionamento della soluzione, ad esempio Registro Azure Container e Archiviazione di Azure. Le regole in uscita definite dall'utente riguardano risorse personalizzate, ad esempio Azure OpenAI o Ricerca di intelligenza artificiale di Azure, che il flusso di lavoro userà. È responsabilità dell'utente configurare le regole in uscita definite dall'utente, mentre le regole in uscita necessarie vengono configurate quando viene creata la rete virtuale gestita.

Le regole in uscita possono essere endpoint privati, tag di servizio o FQDN per endpoint pubblici esterni. In questa architettura la connettività ai servizi di Azure, ad esempio Registro Azure Container, Archiviazione di Azure, Azure Key Vault, il servizio Azure OpenAI e Ricerca di intelligenza artificiale di Azure vengono connessi 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, clonando un repository GitHub, scaricando immagini del contenitore di base da repository esterni.

Segmentazione e sicurezza della rete virtuale

La rete in questa architettura ha subnet separate per quanto segue:

• 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 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 alla baseline a ogni subnet. La tabella assegna il nome e la funzione della regola.

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 la 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. È consigliabile usare le regole più rigide che abilitano la funzionalità completa della soluzione.
• Usare i gruppi di sicurezza delle applicazioni. I gruppi di sicurezza delle applicazioni consentono di raggruppare gruppi di sicurezza di rete, semplificando la creazione di regole per ambienti complessi.

Monitoraggio di filtri e abusi sui contenuti

Il servizio OpenAI di Azure 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 LLM). È 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. È consigliabile modificare le impostazioni in base alle proprie esigenze.

Oltre al filtro dei contenuti, il servizio OpenAI di Azure implementa funzionalità di monitoraggio degli abusi. Il monitoraggio degli abusi è un'operazione asincrona progettata per rilevare e attenuare le istanze di contenuto ricorrente e/o comportamenti che suggeriscono l'uso del servizio in modo che possa violare il codice di comportamento di Azure OpenAI. È possibile richiedere un'esenzione dal monitoraggio degli abusi e dalla revisione umana, ad esempio 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à. 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 Azure Machine Learning, Azure OpenAI e Ricerca di intelligenza artificiale di Azure.

Ridondanza di zona per le distribuzioni di flussi

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

La distribuzione dei flussi di prompt non è limitata ai cluster di calcolo di Azure 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 Azure. 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.

Di seguito è riportata un'architettura alternativa in cui i flussi di richiesta vengono distribuiti in app Azure Servizio. 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.

Figura 4: Architettura di chat end-to-end alternativa con OpenAI che distribuisce flussi di prompt ai servizi di app Azure

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

1. I flussi vengono comunque creati nel flusso di richiesta di Azure Machine Learning e l'architettura di rete di Azure 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 tratteggiata indica che i flussi eseguibili in contenitori vengono inseriti in Registro Azure Container (ACR). Non illustrato nel diagramma sono le pipeline che in contenitorizzano i flussi e eseguono il push in Registro Azure Container.
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 di servizio app si connettono a Registro Azure 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 si tratterebbe di Ricerca di intelligenza artificiale di Azure e del servizio OpenAI di Azure. Anche i servizi PaaS esposti solo alla subnet dell'endpoint privato gestito AML devono essere esposti nella rete virtuale in modo che sia possibile stabilire una linea di visualizzazione 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. È consigliabile usare i controlli di integrità per garantire che le chiamate vengano indirizzate solo ai cluster che funzionano correttamente.

Per supportare in modo efficace più istanze, è consigliabile esternalizzare i file di ottimizzazione, ad esempio a un account di Archiviazione di Azure con ridondanza geografica. Questo ridurrà al minimo lo stato archiviato nel servizio OpenAI di Azure per area. Per ospitare la distribuzione del modello, è comunque necessario eseguire l'ottimizzazione per ogni istanza.

È importante monitorare la velocità effettiva necessaria in termini di token al minuto (TPM) e richieste al minuto (RPM) per assicurarsi di avere assegnato un TPM sufficiente dalla quota per soddisfare la domanda per le distribuzioni e impedire la limitazione delle chiamate ai modelli distribuiti. Un gateway come Azure Gestione API (APIM) può essere distribuito davanti ai servizi OpenAI e può essere configurato per il nuovo tentativo in caso di errori temporanei e limitazione. Gestione API può anche essere usato come interruttore per impedire al servizio di sovraccaricare la chiamata, superando la quota.

Ricerca di intelligenza artificiale di Azure - Affidabilità

Distribuire Ricerca di intelligenza artificiale di Azure con 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:

• Seguire le indicazioni per monitorare Ricerca intelligenza artificiale di Azure.
• 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 per evitare la limitazione basata su indici.

Azure Machine Learning - Affidabilità

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

• Seguire le indicazioni per ridimensionare automaticamente gli endpoint online per garantire che sia disponibile 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 che siano disponibili troppi casi di impatto sull'affidabilità.
• 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 deve essere accessibile da Internet è l'interfaccia utente della chat tramite il gateway app. 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.

La sicurezza di rete è stata discussa nella sezione Rete. Questa sezione illustra la gestione delle identità e degli accessi e considerazioni 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 AML seguenti, se applicabile:
  • Area di lavoro: usata durante la creazione e la gestione del flusso
  • Istanza di calcolo: usata durante il test dei flussi
  • Endpoint online: usato dal flusso distribuito se distribuito in un endpoint online gestito
• Implementare controlli di accesso alle identità per l'interfaccia utente della chat usando Microsoft Entra ID

Ruoli controllo degli accessi in base al ruolo di Azure Machine Learning

Esistono cinque ruoli predefiniti che è possibile usare per gestire l'accesso all'area di lavoro di Azure Machine Learning: AzureML Scienziato dei dati, Operatore di calcolo AzureML, Lettore, Collaboratore e Proprietario. Oltre a questi ruoli predefiniti, è disponibile un'area di lavoro di AzureML Connessione ion Secrets Reader e un utente del Registro azureML che concedono 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. Di seguito sono riportate le assegnazioni di ruolo.

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 Azure Machine Learning. Poiché si usa l'autenticazione basata su chiave per questi servizi, è importante:

• Archiviare la chiave in un archivio sicuro come Azure 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, è necessario 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, ad esempio Archiviazione BLOB di Azure, è consigliabile usare una chiave gestita dal cliente per la crittografia dei dati, usare un'identità gestita per controllare l'accesso ai dati e un endpoint privato per connettersi ai dati.

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 altre informazioni, vedere Panoramica del pilastro dell'efficienza delle prestazioni.

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

Ricerca di Azure - Efficienza delle prestazioni

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

Azure OpenAI - Efficienza delle prestazioni

• Determinare se l'applicazione richiede la velocità effettiva con provisioning o userà il modello di hosting condiviso (consumo). La velocità effettiva con provisioning offre capacità di elaborazione riservata per le distribuzioni del modello OpenAI, offrendo prestazioni prevedibili e velocità effettiva per i modelli. Questo modello di fatturazione è diverso dal modello di hosting condiviso (consumo), che è il miglior sforzo e potrebbe essere soggetto a un vicino rumoroso o ad altri stress sulla piattaforma.
• Per la velocità effettiva con provisioning, è consigliabile monitorare l'utilizzo gestito dal provisioning

Azure Machine Learning - Efficienza delle prestazioni

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

• Seguire le indicazioni su come ridimensionare automaticamente un endpoint online per rimanere strettamente allineati alla domanda, senza sovraccarico eccessivo, soprattutto nei periodi di basso utilizzo.
• Scegliere lo SKU della macchina virtuale appropriato per l'endpoint online per soddisfare gli obiettivi di prestazioni. Si vuole testare le prestazioni sia del numero di istanze inferiore che degli SKU più grandi rispetto al numero di istanze più grandi e agli SKU più piccoli per trovare una configurazione ottimale.

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 Panoramica del pilastro di 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, in quanto 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 di Azure, quindi cercare di ottimizzare tali risorse per risparmiare il costo più elevato.

Calcolo

Il flusso dei prompt di Azure Machine Learning supporta più opzioni per ospitare i flussi eseguibili. Le opzioni includono endpoint online gestiti in Azure Machine Learning, servizio Azure Kubernetes, servizio app Azure e servizio Azure Container. 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, nel servizio 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, in quanto 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 tramite controlli di rete e identità (chiave 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 OpenAI di Azure deve essere necessario e nelle istanze di preproduzione, quindi tali attività non comportano 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. L'uso del modello corretto per il caso d'uso può 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 all'ora. Per essere il più efficiente, è consigliabile usare la maggior parte di tale tempo disponibile all'ora per migliorare i risultati di ottimizzazione, evitando al tempo stesso di passare al periodo di fatturazione successivo. Analogamente, il costo per 100 immagini dalla generazione di immagini è uguale al costo per 1 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, valutare il passaggio a questo modello di fatturazione preacquisto se calcola che sia più conveniente in base al 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 di cui è stato effettuato il provisioning mentre è abilitata la quota dinamica. Si noti che la quota non esegue direttamente il mapping ai costi e ai costi può variare.
• Monitorare l'utilizzo con pagamento in base al consumo: se si usa il pagamento in base al consumo, monitorare l'utilizzo dei token al minuto (TPM) e delle richieste al minuto (RPM). Usare queste informazioni per informare le decisioni di progettazione dell'architettura, ad esempio i modelli da usare, nonché 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 del provisioning per assicurarsi di non sottoutilizzare 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.

Operazioni del modello linguistico di grandi dimensioni (LLMOps)

La distribuzione per soluzioni di chat basate su OpenAI di Azure, come questa architettura, deve seguire le indicazioni riportate in LLMOps con flusso di prompt con Azure DevOps e GitHub. Inoltre, deve prendere in considerazione le procedure consigliate per le architetture CI/CD e 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 Azure Machine Learning offre sia un'esperienza di creazione basata su browser in studio di Azure Machine Learning che tramite un'estensione di VS Code. Entrambe le opzioni archiviano il codice del flusso come file. Quando si usa studio di Azure Machine Learning, i file vengono archiviati in un account Archiviazione di Azure. Quando si lavora in VS 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, è consigliabile usare l'estensione VS Code e il prompt flow SDK/CLI per lo sviluppo. Gli autori del flusso dei prompt possono compilare e testare i flussi da VS 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

È consigliabile 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 LLM, ma è possibile usare un LLM stesso per valutare le risposte. Valutare la possibilità di implementare le valutazioni automatizzate seguenti dei flussi LLM:

• Accuratezza classificazione: valuta se l'LLM 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'affidabilità delle risposte stimate del modello in base al contesto preconfigurato. Anche se le risposte di LLM 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 IMS per generare uno dei dati nel set di dati golden.

Flusso di distribuzione

Figura 5: Distribuzione del flusso di richiesta

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 prompt per VS 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:

   a. 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 Azure Machine Learning quando vengono rilevate modifiche

   b. 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 Azure Machine Learning a un endpoint online di Azure 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 dell'LLM distribuito. Ciò include, ma non è limitato a:

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

Linee guida per la distribuzione

Gli endpoint di Azure Machine Learning consentono di distribuire 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 Azure Machine Learning isolata dalla rete, usare un agente self-hosted per distribuire gli artefatti nelle risorse di Azure.
• Il Registro modelli di Azure Machine Learning deve essere aggiornato solo quando vengono apportate modifiche al modello.
• LLM, i flussi e l'interfaccia utente client devono essere accoppiati in modo libero. Aggiornamenti ai flussi e all'interfaccia utente client può e deve essere in grado di essere eseguita senza influire sul modello e viceversa.
• Quando si sviluppano e distribuiscono più flussi, ogni flusso deve avere un proprio ciclo di vita, che consente un'esperienza ad accoppiamento debole quando si promuovono flussi 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.

• Azure Machine Learning workspace (Area di lavoro di Azure Machine Learning)
• Archiviazione di Azure account per l'area di lavoro di Azure Machine Learning
• Registro Azure Container
• Azure 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 flussi di prompt specifici, consentendo l'associazione di queste risorse al ciclo di vita del componente e diventano temporanee in questa architettura. Sono interessati 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 dei modelli di Azure 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 Azure 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 Azure 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.

Monitoraggio

La diagnostica è configurata per tutti i servizi. Tutti i servizi, ma Azure Machine Learning e il servizio app Azure sono configurati per acquisire tutti i log. La diagnostica di Azure 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. app Azure Servizio è configurato per acquisire AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs e AppServicePlatformLogs.

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.

Passaggi successivi

Altre informazioni su Azure OpenAI

Risorse correlate

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