Progettazione di applicazioni per carichi di lavoro di intelligenza artificiale in Azure
Quando si crea un'applicazione con funzioni di intelligenza artificiale, è possibile prendere in considerazione molte opzioni. I requisiti funzionali e non funzionali univoci, ad esempio se il caso d'uso è l'apprendimento automatico tradizionale, generativo, deterministico o una combinazione di tipi di intelligenza artificiale, consentono di limitare le decisioni di alto livello sulla progettazione. Queste scelte verranno considerate man mano che si passa dalle aree di progettazione di alto livello alle aree di progettazione di livello inferiore.
Come illustrato nell'articolo Introduzione
Origini del catalogo. Esplorare repository come Hugging Face Model Hub, TensorFlow Hub e il catalogo dei modelli del portale Azure AI Foundry per trovare modelli pre-addestrati. Queste piattaforme offrono un ampio catalogo di modelli per varie attività.
Licenze. Assicurarsi che le condizioni di licenza del modello siano conformi agli obiettivi di sicurezza, conformità e applicazione, soprattutto se si prevede di distribuire l'applicazione o integrarla con altri servizi.
Componenti chiave. Esaminare l'architettura del modello, i dati di training, le prestazioni e le licenze per determinare se è ottimizzato per l'attività o il dominio.
Per indicazioni sulla scelta di una piattaforma di hosting, vedere Considerazioni per la piattaforma di hosting e inferenza del modello.
Questo articolo descrive le aree di progettazione e i fattori comuni da considerare quando si prendono decisioni relative alla tecnologia e all'approccio.
Consigli
La tabella seguente riepiloga le raccomandazioni fornite in questo articolo.
| Suggerimento | Descrizione |
|---|---|
| Assegnare priorità alle soluzioni off-the-shelf. | Quando pratico, usare soluzioni PaaS (Platform as a Service) per gestire le funzioni del carico di lavoro. Usare modelli predefiniti e con training preliminare, se possibile, per ridurre al minimo il carico di lavoro e sviluppo per i team operativi e dei carichi di lavoro. |
| Funzioni e funzionalità astratte dal client. | Mantenere il client il più sottile possibile progettando servizi back-end per gestire problemi trasversali, ad esempio la limitazione della frequenza e le operazioni di failover. |
| Bloccare l'accesso agli archivi dati. | Il codice nel sistema di intelligenza artificiale non deve accedere direttamente agli archivi dati. Instradare tutte le richieste di dati tramite un livello API. Le API devono essere compilate specificamente per l'attività richiesta. |
| Isolare i modelli. | Come per gli archivi dati, usare un livello API per fungere da gateway per le richieste al modello. A questo scopo, alcune soluzioni PaaS come il servizio Azure OpenAI e Azure Machine Learning usano SDK. Molti strumenti, ad esempio prompt flow, contengono il supporto nativo per propagare le API al servizio. |
| Progettare componenti da distribuire in modo indipendente. | I modelli di intelligenza artificiale, le pipeline di dati, i componenti front-end e i microservizi come la pre-elaborazione dei dati, l'estrazione delle funzionalità e l'inferenza devono essere distribuiti in modo indipendente per ottimizzare la flessibilità, la scalabilità e l'operabilità del carico di lavoro. |
Containerize components
Per garantire che i componenti distribuibili in modo indipendente siano completamente autonomi e per semplificare le distribuzioni, prendere in considerazione la containerizzazione come parte della strategia di progettazione. I componenti seguenti devono essere inclusi in contenitori:
microservizi. I singoli microservizi che gestiscono funzioni specifiche dell'applicazione, ad esempio l'elaborazione dei dati, l'inferenza del modello e l'autenticazione utente, devono essere in contenitori. Questo approccio consente la distribuzione e il ridimensionamento indipendenti e facilita aggiornamenti e manutenzione più efficienti.
modelli di intelligenza artificiale. Contenere i modelli di intelligenza artificiale per garantire che tutte le dipendenze, le librerie e le configurazioni siano raggruppate insieme. Questo approccio isola l'ambiente del modello dal sistema host per evitare conflitti di versione e garantire un comportamento coerente in diversi ambienti di distribuzione.
le pipeline di elaborazione dei dati. Tutte le attività di elaborazione dati che precedono o seguono l'inferenza del modello, ad esempio la pulizia dei dati, la trasformazione e l'estrazione delle funzionalità, devono essere incluse in contenitori. Questo approccio migliora la riproducibilità e semplifica la gestione delle dipendenze.
Servizi di infrastruttura. I servizi che forniscono il supporto dell'infrastruttura, ad esempio i database e i livelli di memorizzazione nella cache, possono anche trarre vantaggio dalla containerizzazione. L'inserimento in contenitori di questi servizi consente di mantenere la coerenza delle versioni e semplificare la scalabilità e la gestione di questi componenti.
Colocare componenti di intelligenza artificiale con altri componenti del carico di lavoro
Esistono diversi motivi validi per la condivisione dei componenti di intelligenza artificiale con altri componenti del carico di lavoro, ma esistono compromessi associati a questa operazione. È possibile scegliere di colocare i componenti per questi motivi:
sensibilità alla latenza. Collocare i componenti di intelligenza artificiale con altri servizi, ad esempio l'hosting di API, quando è importante una bassa latenza. Ad esempio, se è necessaria l'inferenza in tempo reale per migliorare l'esperienza utente, posizionare i modelli di intelligenza artificiale vicini all'API può ridurre al minimo il tempo necessario per recuperare i risultati.
La prossimità dei dati. Quando i modelli di intelligenza artificiale richiedono l'accesso frequente a set di dati specifici, ad esempio un indice di ricerca, l'individuazione di questi componenti può migliorare le prestazioni e ridurre il sovraccarico del trasferimento dei dati per velocizzare l'elaborazione e l'inferenza.
Utilizzo delle Risorse. Se i componenti specifici hanno esigenze di risorse complementari, ad esempio CPU e memoria, l'individuazione di tali componenti può ottimizzare l'utilizzo delle risorse. Ad esempio, un modello che richiede un calcolo significativo può condividere le risorse con un servizio con richieste più basse contemporaneamente.
compromesso. Ci sono compromessi da considerare quando si decide se collocare i componenti. È possibile perdere la possibilità di distribuire o ridimensionare in modo indipendente i componenti. È anche possibile aumentare il rischio di malfunzionamento aumentando il potenziale raggio di esplosione degli incidenti.
Valutare l'uso di agenti di orchestrazione nelle soluzioni di intelligenza artificiale generative
Un agente di orchestrazione gestisce un flusso di lavoro coordinando la comunicazione tra i diversi componenti della soluzione di intelligenza artificiale che altrimenti sarebbe difficile da gestire in carichi di lavoro complessi. È consigliabile creare un agente di orchestrazione nella progettazione se il carico di lavoro presenta una delle caratteristiche seguenti:
flussi di lavoro complessi. Il flusso di lavoro prevede più passaggi, ad esempio la pre-elaborazione, il concatenamento dei modelli o la post-elaborazione.
logica condizionale. Le decisioni, ad esempio il routing dei risultati a modelli diversi, devono essere prese in modo dinamico in base agli output del modello.
Ridimensionamento e gestione delle risorse. È necessario gestire l'allocazione delle risorse per le applicazioni con volumi elevati usando il ridimensionamento del modello basato su richiesta.
Gestione dello stato. È necessario gestire lo stato e la memoria delle interazioni dell'utente.
recupero dati. È necessario essere in grado di recuperare i dati di aumento dall'indice.
Considerazioni sull'uso di più modelli
Quando il carico di lavoro usa più modelli, è essenziale un orchestratore. L'agente di orchestrazione instrada i dati e le richieste al modello appropriato in base al caso d'uso. Pianificare il flusso di dati tra modelli, assicurandosi che gli output di un modello possano fungere da input per un altro. La pianificazione potrebbe comportare processi di trasformazione o arricchimento dei dati.
Orchestrazione e agenti
Per i carichi di lavoro di intelligenza artificiale generativi, prendere in considerazione un approccio basato su agente, talvolta definito agente, alla progettazione per aggiungere estendibilità all'orchestrazione. Gli agenti forniscono funzionalità associate al contesto. Condividono molte caratteristiche con i microservizi ed eseguono attività insieme a un orchestratore. L'orchestratore può annunciare attività a un pool di agenti, oppure gli agenti possono registrare le loro capacità con l'orchestratore. Entrambi gli approcci consentono all'orchestratore di determinare dinamicamente come suddividere e instradare la query tra gli agenti.
Gli approcci agentic sono ideali quando si ha un'interfaccia utente comune con funzionalità multiple e in continua evoluzione che possono essere integrate nell'esperienza per aggiungere competenze e dati di base al flusso nel tempo.
Per carichi di lavoro complessi con molti agenti, è più efficiente consentire agli agenti di collaborare in modo dinamico anziché usare un agente di orchestrazione per suddividere le attività e assegnarle.
La comunicazione tra l'agente di orchestrazione e gli agenti deve seguire un modello di coda di argomenti, in cui gli agenti sono sottoscrittori di un argomento e l'agente di orchestrazione invia attività tramite una coda.
L'uso di un approccio agentico funziona meglio con un modello di orchestrazione anziché con un modello coreografico.
Per altre informazioni, vedere Considerazioni per la piattaforma di orchestrazione.
Valutare l'uso dei gateway API
Gateway API come Azure API Management astraggono le funzioni dalle API e separano le dipendenze tra il servizio richiedente e l'API. I gateway API offrono i vantaggi seguenti per i carichi di lavoro di intelligenza artificiale:
molteplici microservizi. I gateway consentono di gestire più endpoint del modello di intelligenza artificiale quando è necessario applicare criteri coerenti, ad esempio la limitazione della frequenza e l'autenticazione.
Gestione del traffico. I gateway consentono di gestire in modo efficiente le app ad alto traffico gestendo le richieste, memorizzando nella cache le risposte e distribuendo i carichi.
Security. I gateway offrono un controllo di accesso centralizzato, la registrazione e la protezione dalle minacce per le API dietro il gateway.
Usare i modelli di progettazione delle applicazioni di intelligenza artificiale
Sono stati stabiliti diversi modelli di progettazione comuni nel settore per le applicazioni di intelligenza artificiale. È possibile usarli per semplificare la progettazione e l'implementazione. Questi modelli di progettazione includono:
Ensemble di modelli. Questo modello di progettazione prevede la combinazione di stime da più modelli per migliorare l'accuratezza e l'affidabilità attenuando i punti deboli dei singoli modelli.
L'architettura dei microservizi. La separazione dei componenti in servizi distribuibili in modo indipendente migliora la scalabilità e la gestibilità. Consente ai team di lavorare contemporaneamente su diverse parti dell'applicazione.
'architettura basata su eventi. L'uso di eventi per attivare azioni consente di separare i componenti e l'elaborazione in tempo reale per rendere il sistema più reattivo e adattabile ai dati modificati.
Strategie di spostamento e suddivisione in blocchi
Il modello Retrieval-Augmented Generation (RAG) combina modelli generativi con sistemi di recupero, che consente al modello di accedere a origini di conoscenze esterne per migliorare il contesto e l'accuratezza. Per indicazioni approfondite su questo schema, vedere la serie di articoli Progettare e sviluppare una soluzione RAG. Esistono due approcci rag:
just-in-time. Questo approccio recupera le informazioni pertinenti in modo dinamico al momento di una richiesta per assicurarsi che i dati più recenti vengano sempre usati. È utile negli scenari che richiedono un contesto in tempo reale, ma potrebbe introdurre latenza.
pre-calcolata (memorizzata nella cache). Questo metodo comporta la memorizzazione nella cache dei risultati di recupero per ridurre i tempi di risposta servendo i dati pre-calcolati. È adatto per scenari su richiesta in cui è possibile archiviare dati coerenti. I dati potrebbero non riflettere le informazioni più aggiornate, che potrebbero causare problemi di pertinenza.
Quando si usa un modello RAG, una strategia di suddivisione in blocchi ben definita è fondamentale per ottimizzare l'efficienza delle prestazioni del carico di lavoro. Iniziare con le linee guida fornite nella serie Design e sviluppare una soluzione RAG. Ecco alcuni consigli aggiuntivi da considerare:
Implementare una strategia dinamica di suddivisione in blocchi che regola le dimensioni dei blocchi in base al tipo di dati, alla complessità delle query e ai requisiti utente. In questo modo è possibile migliorare l'efficienza del recupero e la conservazione del contesto.
Incorporare cicli di feedback per perfezionare le strategie di suddivisione in blocchi in base ai dati sulle prestazioni.
Mantenere la derivazione dei dati per i blocchi mantenendo metadati e identificatori univoci che si collegano all'origine di base. Una chiara documentazione sulla derivazione assicura che gli utenti comprendano l'origine dei dati, le trasformazioni e come contribuisce all'output.
Quando usare modelli di progettazione
È consigliabile usare questi modelli di progettazione quando il caso d'uso soddisfa la condizione descritta:
flussi di lavoro complessi. Quando si hanno flussi di lavoro o interazioni complessi tra più modelli di intelligenza artificiale, modelli come RAG o microservizi possono aiutare a gestire la complessità e garantire una comunicazione chiara tra i componenti.
Requisiti di Scalabilità. Se la domanda sull'applicazione varia, un modello come i microservizi consente ai singoli componenti di ridimensionarsi in modo indipendente per gestire carichi variabili senza influire sulle prestazioni complessive del sistema.
applicazioni guidate dai dati. Se l'applicazione richiede una gestione completa dei dati, un'architettura basata su eventi può fornire velocità di risposta in tempo reale ed elaborazione efficiente dei dati.
Nota
Le applicazioni o i PC più piccoli in genere non traggono vantaggio da questi modelli di progettazione. Queste applicazioni devono essere progettate per semplicità. Analogamente, se si dispone di vincoli di risorse (budget, tempo o numero di personale), l'uso di un design semplice che può essere ristrutturato in un secondo momento è un approccio migliore rispetto all'adozione di un design pattern complesso.
Scegliere i framework e le librerie corretti
La scelta di framework e librerie è strettamente legata alla progettazione di applicazioni. Influiscono su prestazioni, scalabilità e gestibilità. Tuttavia, i requisiti di progettazione possono limitare le scelte del framework. Ad esempio, l'uso di Semantic Kernel SDK spesso incoraggia una progettazione basata su microservizi in cui ogni agente o funzione viene incapsulato all'interno del proprio servizio. Prendere in considerazione questi fattori quando si scelgono framework e librerie:
Requisiti dell'applicazione. I requisiti dell'applicazione, ad esempio l'elaborazione in tempo reale o l'elaborazione batch, potrebbero limitare la scelta del framework. Ad esempio, se l'applicazione richiede bassa latenza, potrebbe essere necessario usare un framework con funzionalità asincrone.
Integrazione ha bisogno di. La progettazione potrebbe richiedere integrazioni specifiche con altri sistemi o servizi. Se un framework non supporta i protocolli o i formati di dati necessari, potrebbe essere necessario riconsiderare la progettazione o scegliere un framework diverso.
Esperienza del team. Il set di competenze del team di sviluppo può limitare le scelte del framework. Una progettazione che si basa su un framework meno familiare potrebbe comportare un aumento del tempo di sviluppo e della complessità, quindi potrebbe essere necessario usare uno strumento più familiare.
Progettare una strategia per identità, autorizzazione e accesso
In generale, è consigliabile approcciarsi all'identità, all'autorizzazione e all'accesso nello stesso modo in cui normalmente si progettano applicazioni. È consigliabile usare un provider di identità, ad esempio Microsoft Entra ID, per gestire queste aree il più possibile. Tuttavia, molte applicazioni di intelligenza artificiale presentano sfide specifiche che richiedono considerazioni speciali. A volte è difficile o persino impossibile rendere persistenti gli elenchi di controllo di accesso (ACL) attraverso il sistema senza nuovi sviluppi.
Consultare Guida alla progettazione di una soluzione di inferenza RAG multitenant sicura per informazioni su come aggiungere metadati di riduzione della sicurezza a documenti e blocchi. Questo taglio può essere basato su gruppi di sicurezza o costrutti organizzativi simili.
Considerare i requisiti non funzionali
Il carico di lavoro potrebbe avere requisiti non funzionali che comportano sfide a causa di fattori intrinseci alle tecnologie di intelligenza artificiale. Di seguito sono riportati alcuni requisiti non funzionali comuni e le relative sfide:
latenza dell'inferenza del modello/timeout. Le applicazioni di intelligenza artificiale richiedono spesso risposte in tempo reale o quasi in tempo reale. La progettazione per bassa latenza è fondamentale. Implica l'ottimizzazione dell'architettura del modello, delle pipeline di elaborazione dei dati e delle risorse hardware. L'implementazione di strategie di memorizzazione nella cache e la garanzia di un caricamento efficiente dei modelli sono essenziali anche per evitare timeout e fornire risposte tempestive.
Limitazioni della velocità effettiva del token o della richiesta. Molti servizi di intelligenza artificiale impongono limiti al numero di token o alla velocità effettiva delle richieste, in particolare con i modelli basati sul cloud. La progettazione per queste limitazioni richiede un'attenta gestione delle dimensioni di input, l'invio in batch di richieste quando necessario e l'implementazione di meccanismi di limitazione della velocità o accodamento per gestire le aspettative degli utenti e prevenire interruzioni del servizio.
Scenari di costo e riaccredito. La progettazione per la trasparenza dei costi comporta l'implementazione di funzionalità di rilevamento e creazione di report sull'utilizzo che facilitano i modelli di chargeback. Queste funzionalità consentono alle organizzazioni di allocare i costi in modo accurato tra i reparti. La gestione del chargeback viene in genere gestita da un gateway API, ad esempio Gestione API di Azure.