Progettare per supportare i cicli di vita del modello fondamentale

I modelli di base sono dipendenze versionate utilizzate nel carico di lavoro di intelligenza artificiale. Ogni modello di base ha un ciclo di vita che deve essere considerato. Come le librerie di codice e altre dipendenze nel carico di lavoro, i modelli di base ricevono aggiornamenti delle versioni secondari che forniscono miglioramenti e ottimizzazioni delle prestazioni. Gli aggiornamenti delle versioni principali introducono modifiche sostanziali alle funzionalità, alle prestazioni o all'aggiornamento dei dati di training. Nel corso del tempo, i modelli di base potrebbero essere deprecati a causa dell'obsolescenza o delle preferenze host del modello che esulano dal controllo.

È necessario progettare il carico di lavoro per supportare i cicli di vita documentati dei modelli scelti come dipendenze. Se non si considerano i cicli di vita dei modelli, è possibile che si eseguano inutilmente aggiornamenti rischiosi, introduca modifiche al comportamento non testato, si verifichino tempi di inattività del carico di lavoro non necessari o si verifichino interruzioni a causa del modo in cui la piattaforma di hosting gestisce i modelli di fine vita.

Un carico di lavoro progettato per supportare i cicli di vita dei suoi modelli semplifica la sperimentazione e la migrazione sicura ai nuovi modelli fondamentali man mano che entrano nel mercato.

Tipi di aggiornamenti del modello

L'ambito dell'aggiornamento del modello nella soluzione di intelligenza artificiale generativa può variare drasticamente, dall'aggiornamento per una modifica di revisione secondaria alla scelta di una nuova famiglia di modelli. Esistono diversi motivi per cui è possibile scegliere di aggiornare il modello nella soluzione. Nella tabella seguente sono elencati diversi ambiti di aggiornamento, insieme a un esempio e vantaggi dell'esecuzione di questo aggiornamento.

Come illustrato nella tabella, i vantaggi del passaggio a un nuovo modello sono in genere una combinazione dei fattori seguenti:

• Prestazioni, ad esempio velocità e latenza

• Capacità, ad esempio la velocità effettiva misurata nelle transazioni al minuto

• Disponibilità della quota

• Efficienza dei costi

• Disponibilità regionale

• Capacità multimodali

• Aggiornamento delle conoscenze di formazione

• Correzioni di bug

• Specializzazione o despecializzazione per allinearsi meglio al caso d'uso

• Evitare interruzioni del carico di lavoro a causa delle politiche del ciclo di vita dell'host del modello.

Comportamento del modello al pensionamento

Il comportamento di ritiro del modello dipende dalla strategia di distribuzione del modello. Esistono tre strategie chiave per la distribuzione dei modelli. È importante comprendere in che modo ogni strategia gestisce i ritiri delle versioni:

• Le soluzioni MaaS (modello come servizio) sono modelli con training preliminare esposti come API che offrono scalabilità e facilità di integrazione. Hanno un compromesso tra costi potenzialmente più elevati e un minore controllo sui modelli. Esempi di soluzioni MaaS includono modelli distribuiti nel servizio Azure OpenAI e modelli dal catalogo dei modelli distribuito come API serverless.

• Le soluzioni MaaP (modello come piattaforma) sono modelli distribuiti e gestiti all'interno di una piattaforma più ampia, ad esempio i modelli del catalogo dei modelli di Azure distribuiti nel calcolo gestito. Questa soluzione offre in genere un maggiore controllo dei modelli, ma richiede una gestione maggiore rispetto alle soluzioni MaaS.

• I modelli self-hosting sono modelli distribuiti sulla propria infrastruttura. Questa distribuzione offre il massimo controllo sui modelli, ma richiede una responsabilità significativa per l'infrastruttura, la gestione e la manutenzione.

Entrambe le strategie MaaS e MaaP nei modelli di origine di Azure del catalogo dei modelli di intelligenza artificiale di Azure. I modelli nel catalogo dei modelli seguono un ciclo di vita in cui i modelli sono deprecati e quindi ritirati. È necessario pianificare queste eventualità nel carico di lavoro.

Quando si usano modelli self-host o si usa il calcolo gestito, si mantiene il controllo completo e non è necessario aggiornare i modelli. È tuttavia possibile replicare un ciclo di vita del modello per i vantaggi aggiuntivi che un modello più recente può portare al carico di lavoro.

Ampiezza delle modifiche per gli aggiornamenti del modello

È necessario valutare il modo in cui un aggiornamento del modello influisce sul carico di lavoro in modo da poter pianificare la transizione dal modello precedente al nuovo modello. L'estensione della modifica del carico di lavoro dipende dalle differenze funzionali e non funzionali tra i modelli precedenti e nuovi. Il diagramma mostra un'architettura di chat semplificata con sezioni numerate che evidenziano le aree in cui un aggiornamento del modello potrebbe avere un effetto.

Per ognuna di queste aree, considerare il tempo di inattività causato dagli aggiornamenti e il modo in cui si gestiscono le richieste elaborate dal sistema. Se le finestre di manutenzione sono disponibili per il carico di lavoro, usare queste finestre quando l'ambito della modifica è elevato. Se le finestre di manutenzione non sono disponibili, affrontare le modifiche in queste aree per mantenere le funzionalità del carico di lavoro e gli obiettivi di livello di servizio durante l'aggiornamento del modello.

1. Il modello: La modifica ovvia consiste nel modello stesso. Si distribuisce il nuovo modello usando la strategia di distribuzione del modello scelta. È necessario valutare i compromessi tra gli aggiornamenti in loco e la distribuzione affiancata.

   Quando si passa a una nuova revisione del modello da un modello ottimizzato, è necessario eseguire di nuovo l'ottimizzazione sulla nuova versione del modello prima di usarla. Quando si esegue l'aggiornamento per usare un modello diverso, è necessario determinare se è necessaria l'ottimizzazione.

2. Configurazione del modello: Quando si aggiorna il modello di base nella soluzione di intelligenza artificiale, potrebbe essere necessario modificare gli iperparametri o le configurazioni per ottimizzare le prestazioni per l'architettura e le funzionalità del nuovo modello. Ad esempio, il passaggio da un modello basato su trasformatore a una rete neurale ricorrente potrebbe richiedere frequenze di apprendimento e dimensioni batch diverse per ottenere risultati ottimali.

3. Richiesta: Quando si modificano i modelli di base nel carico di lavoro, potrebbe essere necessario modificare le richieste di sistema negli agenti di orchestrazione o negli agenti per allinearsi ai punti di forza e alle funzionalità del nuovo modello.

   Insieme all'aggiornamento della configurazione del modello, l'aggiornamento della richiesta è una delle modifiche più comuni quando si aggiornano i modelli. Quando si valuta un nuovo modello, anche per un aggiornamento della versione secondaria, modificate il prompt se non soddisfa i vostri requisiti. Questo approccio garantisce di risolvere i problemi di prestazioni prima di esplorare altre modifiche. È necessario rispondere alla richiesta quando si passa a nuovi modelli. È anche probabile che sia necessario rispondere alla richiesta quando si apportano modifiche di revisione di grandi dimensioni.

4. Logica di orchestrazione: Alcuni aggiornamenti del modello, in particolare quando si sfruttano le nuove funzionalità, richiedono di apportare modifiche alla logica dell'orchestrazione o dell'agente.

   Ad esempio, se si aggiorna il modello a GPT-4 per sfruttare i vantaggi della chiamata di funzione, è necessario modificare la logica di orchestrazione. Il modello precedente ha restituito un risultato che è possibile restituire al chiamante. Quando si chiama una funzione, la chiamata al modello restituisce una funzione che la logica di orchestrazione deve invocare. In Azure è tipico implementare la logica di orchestrazione nel servizio Agente di intelligenza artificiale di Azure o usando soluzioni basate su codice come il kernel semantico o LangChain ospitato in Azure.

5. Dati di base: Alcuni aggiornamenti del modello e modifiche con ambito più ampio potrebbero richiedere di apportare modifiche ai dati di base o di ottimizzare i dati o il modo in cui vengono recuperati i dati.

   Ad esempio, quando si passa da un modello generalizzato a un modello specifico del dominio, ad esempio un modello incentrato su finanza o medicina, potrebbe non essere più necessario passare dati di base specifici del dominio al modello. Un altro esempio è quando un nuovo modello può gestire una finestra di contesto più grande. In questo scenario, è possibile recuperare altri blocchi pertinenti o ottimizzare le dimensioni dei blocchi. Per ulteriori informazioni, vedere Progettare e sviluppare una soluzione di generazione aumentata dal recupero (RAG).

6. Hardware: Per i modelli eseguiti in MaaP, una modifica del modello potrebbe richiedere un nuovo hardware. Solo gli SKU di calcolo specifici sono abilitati per i modelli del catalogo. Inoltre, l'hardware può diventare obsoleto, il che richiede di eseguire il modello su nuovo hardware.

Progettare per le modifiche

È probabile che tu aggiornerai i modelli nel tuo carico di lavoro. Se si usa la strategia di distribuzione MaaS in Azure, i modelli vengono ritirati ed è necessario eseguire l'aggiornamento a una versione più recente. È anche possibile scegliere di passare a modelli o versioni di modelli diversi per sfruttare le nuove funzionalità, i prezzi inferiori o migliorare le prestazioni. In entrambi i casi, l'architettura deve supportare l'aggiornamento del modello usato dal carico di lavoro di intelligenza artificiale generativo.

La sezione precedente ha illustrato le diverse ampiezze del cambiamento. È consigliabile seguire le procedure appropriate per le operazioni di Machine Learning (MLOps), le operazioni dei dati (DataOps) e le operazioni di intelligenza artificiale generative (GenAIOps) per creare e gestire pipeline automatizzate per l'ottimizzazione del modello, richieste di tecnici, modificare gli iperparametri e gestire la logica di orchestrazione.

Gli aggiornamenti agli iperparametri e le richieste sono comuni nella maggior parte degli aggiornamenti del modello. Poiché queste modifiche sono così comuni, l'architettura deve supportare un meccanismo di modifica controllato per queste aree. Una considerazione importante è che i prompt e gli iperparametri sono progettati per versioni specifiche del modello. È necessario assicurarsi che i prompt e gli iperparametri vengano sempre usati con il modello e la versione corretti.

Pipeline automatizzate

Implementare pipeline automatizzate per testare e valutare i diversi aspetti dell'applicazione di intelligenza artificiale generativa:

• MLOps: Seguire le indicazioni di Azure MLOps per creare pipeline per l'ottimizzazione del modello, se applicabile.

• GenAIOps: Implementare pipeline GenAIOps per testare e valutare le modifiche apportate al modello, agli iperparametri del modello, alla richiesta e alla logica di orchestrazione.

• DataOps: Implementare pipeline DataOps per testare e valutare le modifiche apportate ai dati di base RAG.

È consigliabile implementare le pipeline per i motivi seguenti:

• Per aiutarti nello sviluppo iterativo e nella sperimentazione (ciclo interno)
• Per eseguire la distribuzione sicura e l'operazionalizzazione della soluzione di intelligenza artificiale generativa (ciclo esterno)

Quando possibile, usare gli stessi dati di base usati con l'applicazione di produzione per testare le modifiche apportate all'applicazione di intelligenza artificiale generativa. Questo approccio potrebbe non essere possibile se l'applicazione aggiornata usa nuove funzionalità del modello che richiedono una modifica ai dati.

Considerazioni sull'architettura

Nelle architetture semplici, come l'architettura seguente, il client chiama direttamente il modello con la versione e la configurazione del prompt corrette. Se sono state apportate modifiche al prompt, viene distribuito un nuovo client con il nuovo prompt e chiama il nuovo modello. Il collegamento della richiesta, della configurazione e delle versioni del modello non è un problema.

Le architetture di produzione non sono semplici. In genere si implementa un agente di orchestrazione o un agente la cui responsabilità è gestire il flusso delle interazioni tra qualsiasi database delle informazioni e i modelli. L'architettura può anche implementare uno o più livelli di astrazione, ad esempio un router o un gateway:

• Router: Un router indirizza il traffico a diverse distribuzioni dell'orchestratore. Un router è utile nelle strategie di distribuzione, ad esempio distribuzioni blu-verde, in cui è possibile scegliere di instradare una percentuale specifica di traffico a una nuova versione dell'agente di orchestrazione come parte delle procedure di distribuzione sicure. Questo componente può essere usato anche per i test A/B o il mirroring del traffico per valutare le modifiche testate, ma non convalidate, insieme al traffico di produzione.

• Gateway: È comune utilizzare un proxy per l'accesso ai modelli di intelligenza artificiale per motivi diversi. Ad esempio, è possibile bilanciare il carico o abilitare il failover tra più istanze back-end, implementare l'autenticazione e l'autorizzazione personalizzate oppure implementare la registrazione e il monitoraggio per i modelli.

A causa dei livelli di riferimento indiretto coinvolti, l'architettura deve essere progettata per supportare l'invio di versioni specifiche di richieste a modelli o versioni del modello specifiche. Ad esempio, potrebbe essere presente un prompt nell'ambiente di produzione, ad esempio prompt1, progettato per un modello, ad esempio model1. Se si esegue l'aggiornamento a model1.1, potrebbe essere necessario aggiornare prompt1 a prompt2. In questo esempio l'architettura deve usare sempre prompt1 con model1 e prompt2 con model1.1.

Router

Il diagramma seguente illustra un'architettura che usa un router per instradare le richieste a più distribuzioni. Un altro esempio di questa architettura include Azure AI Foundry e usa un endpoint online gestito come router. E le diverse versioni dell'orchestratore vengono distribuite ai sistemi di calcolo gestiti.

Il flusso seguente descrive come le diverse distribuzioni di un orchestratore chiamano il modello corretto. Ogni distribuzione ha una propria versione della configurazione del modello e un prompt:

1. Un utente invia una richiesta da un'applicazione intelligente e tale richiesta viene inviata a un router.

2. Il router indirizza al Deployment 1 o al Deployment 2 dell'orchestratore, a seconda della logica.

3. Ogni distribuzione ha una propria versione del prompt e della configurazione.

4. L'orchestratore è configurato con il modello e la versione specifici. Usa queste informazioni per chiamare direttamente il modello e la versione appropriati.

5. Poiché la versione specifica del prompt viene distribuita insieme all'agente di orchestrazione configurato con il modello e la versione specifici, la richiesta corretta viene inviata alla versione del modello corretta.

Porta di accesso

Il diagramma seguente illustra un'architettura che usa un router per instradare le richieste a più distribuzioni. In questa architettura, tuttavia, tutte le richieste di modello vengono instradate tramite un gateway. È comune delegare l'accesso ai modelli di intelligenza artificiale per vari motivi, tra cui il bilanciamento del carico, l'abilitazione del failover tra più istanze back-end in una singola area o più aree e l'implementazione di un'unità di velocità effettiva con provisioning con una strategia di spillover con pagamento in base al consumo.

Il flusso seguente descrive in che modo le diverse distribuzioni di un orchestratore invocano il modello corretto tramite un gateway. Ogni distribuzione ha una propria versione della configurazione del modello e un prompt:

1. Un utente invia una richiesta da un'applicazione intelligente e tale richiesta viene inviata a un router.

2. Il router indirizza alla distribuzione 1 o alla distribuzione 2, a seconda della logica.

3. Ogni distribuzione ha una propria versione del prompt.

4. L'orchestratore è configurato con il modello e la versione specifici. Usa queste informazioni per impostare un'intestazione HTTP che indica il modello e la versione corretti da chiamare.

5. L'orchestratore chiama il gateway. La richiesta contiene l'intestazione HTTP che indica il nome e la versione del modello da usare.

6. Il gateway usa l'intestazione HTTP per instradare la richiesta al modello e alla versione appropriati. Potrebbe anche applicare la configurazione definita nel gateway.

Esternalizzare la configurazione

Il modello di progettazione cloud Archivio di Configurazione Esterna è un buon modo per gestire l'archiviazione di richieste e configurazioni. Per alcuni ambiti delle modifiche del modello, potrebbe essere possibile coordinare la distribuzione del modello con il prompt di sistema e le modifiche alla configurazione se sono archiviate in una posizione aggiornabile al di fuori del codice dell'orchestratore o dell'agente. Questo approccio non funziona se si ha la logica di orchestrazione da regolare, ma è utile in molti aggiornamenti a modello di più piccolo ambito.

Scelta di calcolo

Per l'hosting MaaP, i modelli sono spesso limitati a un subset di risorse di calcolo fornite dall'host. Tutte le risorse computazionali sono soggette a quote, vincoli di disponibilità e annunci di obsolescenza. Usare i modelli di routing per supportare la transizione al nuovo hardware quando l'hardware corrente non è più supportato o esistono vincoli che impediscono la scalabilità orizzontale aggiuntiva.

Un esempio di annuncio di fine vita è la serie NC A100 v4 dell'annuncio di calcolo. Se si ospitano modelli in questo hardware, è necessario passare a un altro SKU supportato che non è di fine vita e ha maggiore disponibilità. Questa transizione potrebbe anche richiedere contemporaneamente una modifica del modello se il nuovo SKU non supporta il modello corrente.

Consigli

• Aggiungere livelli di astrazione e indirezione per consentire modifiche controllate nelle aree specifiche del carico di lavoro. Queste aree includono il client, l'API dell'applicazione intelligente, l'orchestrazione, l'hosting di modelli e le conoscenze di base.

• Tutte le modifiche apportate alle versioni del modello, alle richieste, alle configurazioni, alla logica di orchestrazione e al recupero delle conoscenze di base devono essere testate prima dell'uso nell'ambiente di produzione. Assicurarsi che le combinazioni testate vengano unite insieme nell'ambiente di produzione, il che significa che rimangono strettamente collegate durante la distribuzione. I test A/B, il bilanciamento del carico e le distribuzioni blu-verde non devono combinare componenti per evitare di esporre gli utenti a combinazioni non testate.

• Testare e valutare nuove versioni e nuovi modelli usando pipeline automatizzate. È consigliabile confrontare i risultati con i risultati della baseline per assicurarsi di ottenere i risultati necessari.

• Essere intenzionali sull'aggiornamento dei modelli. Evitare di usare le funzionalità della piattaforma che aggiornano automaticamente i modelli di produzione a nuove versioni senza la possibilità di testare. È necessario essere consapevoli del modo in cui ogni aggiornamento del modello influisce sul carico di lavoro. Se si usa l'inferenza del modello di intelligenza artificiale di Azure, impostare le distribuzioni con una versione specifica e non fornire criteri di aggiornamento. Questa configurazione richiede un aggiornamento manuale se viene rilasciata una nuova versione. Per Azure OpenAI, impostare le distribuzioni su Nessun aggiornamento automatico per disattivare gli aggiornamenti automatici.

• Assicurarsi che la soluzione di osservabilità e registrazione raccoglie metadati sufficienti per correlare il comportamento osservato con la soluzione specifica di richiesta, configurazione, modello e recupero dati coinvolti. Questa correlazione consente di identificare regressioni impreviste nelle prestazioni del sistema.

Riassunto

Esistono diversi motivi per aggiornare il modello di base nel carico di lavoro generativo. Questi motivi vanno dagli aggiornamenti delle versioni necessari quando i modelli vengono ritirati alla decisione di passare a un modello diverso. A seconda dell'ambito dell'aggiornamento del modello, potrebbe essere necessario implementare e valutare le modifiche apportate al modello, incluse le modifiche al prompt, alla configurazione del modello, alla logica di orchestrazione o alla pipeline di dati. Per creare flussi di lavoro automatizzati per i diversi aspetti della soluzione, è necessario seguire le linee guida MLOps, DataOps e GenAIOps. I flussi di lavoro automatizzati consentono di testare, valutare e distribuire nuove versioni. È anche necessario assicurarsi che l'architettura supporti l'esecuzione di più versioni di un agente di orchestrazione in cui ogni versione collega la configurazione e la versione del prompt a una versione del modello specifica.

L'architettura deve supportare gli aggiornamenti a modelli nuovi o diversi ed eventuali modifiche necessarie alla configurazione del prompt o del modello, senza richiedere modifiche all'applicazione intelligente o all'esperienza utente. Questi aggiornamenti devono essere incapsulati all'interno dei relativi componenti appropriati e le operazioni devono automatizzare i test, la valutazione e la distribuzione di tali modifiche.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

• Ritesh Modi | Ingegnere Software Principale

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

Passo successivo

• Deprecazione e ritiro del modello OpenAI di Azure

" output is necessary.)

• Architettura di riferimento di base per la chat end-to-end di OpenAI
• MLOps
• GenAIOps per i professionisti di MLOps