Vai al contenuto

AI-as-a-Service: Gestione delle Applicazioni GenAI con Azure API Management e Fabric

Scopri come Azure API Management e Microsoft Fabric possono ottimizzare la gestione delle applicazioni GenAI, garantendo efficienza e sicurezza.

Negli ultimi anni, l’adozione di modelli di linguaggio di grandi dimensioni (LLM) come Azure OpenAI è cresciuta esponenzialmente. Questi modelli, che utilizzano un approccio basato su token per elaborare le richieste, richiedono una gestione accurata per garantire un’adeguata ingegneria dei prompt, il monitoraggio dei modelli e delle API utilizzate, il bilanciamento del carico tra più istanze e la creazione di modelli di addebito. L’uso di Azure API Management (APIM) è fondamentale per affrontare queste sfide.

Durante il Microsoft Build 2024, sono stati annunciati diversi aggiornamenti specifici per l’integrazione di Azure OpenAI e APIM, rendendo più semplice il loro utilizzo congiunto. Con l’aumento dell’importanza dell’analisi dei dati e della scienza dei dati per i carichi di lavoro basati su Azure OpenAI, la memorizzazione delle informazioni sull’uso diventa cruciale. È qui che entra in gioco l’aggiunta di Microsoft Fabric e del Lakehouse all’architettura, permettendo di catturare i dati di utilizzo in un formato aperto per una conservazione a lungo termine e abilitando query rapide.

Non tutti i casi d’uso richiedono l’uso di un LLM. La recente ascesa dei modelli di linguaggio di piccole dimensioni (SLM), come Phi-3, per casi d’uso che non necessitano di LLM, indica che probabilmente ci saranno diversi tipi di modelli di Generative AI (GenAI) in uso in un’azienda tipica. Tutti questi modelli saranno esposti attraverso un set di API centralmente sicuro e governato, consentendo un rapido onboarding e adozione di ogni caso d’uso GenAI. Un framework di AI Center of Enablement che fornisce “AI-as-a-Service” sarà incredibilmente importante per le organizzazioni, permettendo di abilitare rapidamente diversi modelli GenAI e le loro numerose versioni, tutto entro il budget allocato o utilizzando un modello di addebito che può estendersi a tutta l’azienda.

Questo modello permetterà anche alle organizzazioni di avere una visibilità completa del consumo se acquistano Provisioned Throughput Units (PTU) per i loro carichi di lavoro GenAI in produzione. Questo approccio consente di ottenere una vera economia di scala, dove il PTU è acquistato per una particolare distribuzione del modello Azure OpenAI e condiviso tra tutti i casi d’uso critici per il business.

L’architettura complessiva per questa soluzione “AI-as-a-Service” è la seguente:

Flusso:

  1. Un cliente fa una richiesta a un modello AI tramite Azure API Management utilizzando una chiave di sottoscrizione unica. Questo permette a più clienti di condividere la stessa istanza del modello AI, identificando comunque ciascuno di essi in modo univoco.
  2. Azure API Management inoltra la richiesta al modello AI e riceve l’output del modello.
  3. Azure API Management registra i dettagli della sottoscrizione e i dati della richiesta/risposta su Event Hubs utilizzando una policy log-to-eventhub.
  4. Utilizzando l’esperienza di Realtime Intelligence in Microsoft Fabric, un processore Eventstream legge i dati da Event Hubs.
  5. L’output dello stream viene scritto in una tabella Delta gestita in un Lakehouse.
  6. Dopo aver creato una vista della tabella Delta nell’endpoint Sql Analytics per il Lakehouse, può essere interrogata da Power BI. È possibile utilizzare anche un Notebook per eseguire qualsiasi requisito di data science sui dati dei prompt.

Costruzione:

  1. Crea un logger Event Hub in API Management.
  2. Nell’API che espone il backend AI, aggiungi una policy che invia i dati all’event hub. Questo esempio mostra Azure OpenAI come backend.
    3.                                         @("Bearer " + (string)context.Variables["msi-access-token"])                <set-variable name="requestBody" value="@(context.Request.Body.As(preserveContent: true))" />                                                                    @{                    var responseBody = context.Response.Body?.As(true);                    var requestBody = (string)context.Variables["requestBody"];                                 return new JObject(                        new JProperty("EventTime", DateTime.UtcNow),                        new JProperty("AppSubscriptionKey", context.Request.Headers.GetValueOrDefault("api-key",string.Empty)),                                             new JProperty("Request", requestBody),                        new JProperty("Response",responseBody )                      ).ToString();                }
  3. Costruisci un Eventstream in Fabric che trasferisce i dati nella tabella Delta.
  4. I dati arrivano in un formato troppo grezzo per essere utilizzati per l’analisi, ma con l’endpoint SQL Analytics, possiamo creare viste sopra la tabella.
    5. CREATE OR ALTER VIEW [dbo].[AIUsageView] ASSELECT CAST(EventTime AS DateTime2) AS [EventTime],[AppSubscriptionKey],JSON_VALUE([Response], '$.object') AS [Operation],JSON_VALUE([Response], '$.model') AS [Model],[Request], [Response],CAST(JSON_VALUE([Response], '$.usage.completion_tokens') AS INT) AS [CompletionTokens],CAST(JSON_VALUE([Response], '$.usage.prompt_tokens') AS INT) AS [PromptTokens],CAST(JSON_VALUE([Response], '$.usage.total_tokens') AS INT) AS [TotalTokens]FROM [YOUR_LAKEHOUSE_NAME].[dbo].[AIData]
  5. Ora possiamo creare un report utilizzando una query DirectLake da Power BI.
  6. Possiamo anche caricare i dati in un dataframe Spark per eseguire analisi di data science sui prompt e sulle risposte.

Puoi trovare istruzioni più dettagliate su come costruire questo esempio nel nostro GitHub sample.

Un Landing Zone Accelerator è disponibile per mostrare come costruire l’infrastruttura di base in modo aziendale.

Design Alternativi

  1. Azure Cosmos DB per NoSQL per persistere la cronologia delle chat – Se la tua applicazione sta già memorizzando la cronologia delle chat (prompt e completamenti) in Azure Cosmos DB per NoSQL, non è necessario registrare nuovamente le richieste e le risposte su Event Hub dalla policy APIM. In tal caso, puoi semplicemente registrare le metriche chiave su Event Hub (ad esempio, Identificatore del cliente, Tipo di distribuzione, Token consumati, ecc.) e ottenere i prompt e i completamenti da Cosmos DB per analisi avanzate. La nuova funzionalità in anteprima di Mirroring a Cosmos DB può semplificare questo processo.

Qui c’è un esempio di codice per analizzare il corpo della risposta e registrare il consumo di token tramite le policy APIM.

@{                return new JObject(                    new JProperty("TotalTokens",  context.Response.Body.As(preserveContent: true).SelectToken("usage.total_tokens").ToString())                ).ToString();}

Una volta che i conteggi grezzi dei token e le informazioni sui consumatori dell’API (ad esempio, diverse Business Unit che utilizzano il modello AI-as-a-Service) sono registrati su Event Hub e arrivano nel Fabric Lakehouse, è possibile creare misure aggregate direttamente sul modello semantico (predefinito o personalizzato) e visualizzarle in un dashboard Power BI a tua scelta. Un esempio di tale misura aggregata è il seguente:

TokensByBU = CALCULATE(SUMX(         aoaichargeback,          VALUE(MAX(aoaichargeback[TotalTokens]))     ),      ALLEXCEPT(aoaichargeback, aoaichargeback[BusinessUnitName]))

Qui aoaichargeback è il nome della tabella Lakehouse dove sono memorizzati tutti gli eventi emessi da APIM. La misura TokensByBU calcola la somma del valore massimo di TotalTokens per ciascun BusinessUnitName nella tabella aoaichargeback.

Poiché sia i dati della cronologia delle chat sia le metriche chiave di utilizzo/prestazioni sono nel Lakehouse, possono essere combinati e utilizzati per qualsiasi scopo analitico avanzato. Approcci simili (descritti in precedenza nell’articolo) di utilizzo dell’endpoint SQL Analytics del Fabric Lakehouse possono essere utilizzati per analizzare e governare i dati persistenti.

Azure OpenAI Emit Token Metric Policy – Con l’annuncio recente delle capacità del GenAI Gateway in Azure API Management, possiamo ora ottenere metriche chiave di consumo di Azure OpenAI direttamente dal nostro namespace App Insight quando questa funzionalità è abilitata e implementata. Una nuova policy azure-openai-emit-token-metric può ora essere utilizzata per inviare le metriche del conteggio dei token di Azure OpenAI a Application Insights insieme a ID utente, IP del cliente e ID API come dimensioni.

Tag: