Implementare il monitoraggio avanzato per Azure OpenAI tramite un gateway
Il monitoraggio dei carichi di lavoro che includono il servizio Azure OpenAI può essere semplice come abilitare la diagnostica per Azure OpenAI e usare dashboard preconfigurati. Tuttavia, questa strategia non soddisfa diversi requisiti di monitoraggio organizzativo comuni e più complessi per i carichi di lavoro di intelligenza artificiale generativa, ad esempio:
Annotazioni
Per altre informazioni su come monitorare direttamente Azure OpenAI, vedere Monitorare Azure OpenAI.
Il diagramma seguente illustra il monitoraggio delle istanze di Azure OpenAI senza un gateway. Per questa topologia non è necessario un gateway. La decisione di includere un gateway dipende dal fatto che gli scenari di monitoraggio descritti facciano parte dei requisiti. In questo articolo vengono esaminate le sfide affrontate da ogni scenario di monitoraggio, insieme ai vantaggi e ai costi dell'incorporazione di un gateway per ogni scenario.
Monitora l'utilizzo del modello
Molti carichi di lavoro o organizzazioni devono tenere traccia dell'utilizzo dei modelli di Azure OpenAI da parte dei client e dei modelli in tutte le istanze di Azure OpenAI. Utilizzano queste informazioni per:
Implementa un sistema di chargeback in cui allocano i costi di utilizzo all'organizzazione o al proprietario dell'applicazione appropriati.
Budget e previsioni per l'utilizzo futuro.
Collega il costo e l'utilizzo modale alle prestazioni del modello.
È possibile usare la funzionalità di monitoraggio nativa di Azure OpenAI per tenere traccia dei dati di telemetria del servizio, ma esistono problemi.
Per i modelli di chargeback, è necessario essere in grado di associare le metriche di utilizzo dei token OpenAI di Azure a un'applicazione o a una business unit. I dati di telemetria di Azure OpenAI includono un indirizzo IP chiamante con l'ultimo ottetto mascherato. Questo mascheramento potrebbe rendere difficile la creazione di questa associazione a un'applicazione o a un'unità aziendale.
Le istanze di Azure OpenAI in varie aree probabilmente registrano i log nelle istanze di Monitoraggio di Azure all'interno delle rispettive aree locali. Questo processo richiede l'aggregazione dei log da diverse istanze di Monitoraggio di Azure per tenere traccia dell'utilizzo in tutte le istanze di Azure OpenAI.
Introdurre un gateway per tenere traccia dell'utilizzo del modello
Introdurre un gateway in questa topologia per acquisire l'indirizzo IP completo del client, l'ID Microsoft Entra (o identità alternativa) del client o un identificatore personalizzato per una business unit, un tenant o un'applicazione in un'unica posizione. È quindi possibile utilizzare questi dati per implementare una soluzione di chargeback per la definizione del budget e la previsione e per eseguire analisi costi-benefici dei modelli.
Gli esempi seguenti illustrano le query di utilizzo possibili quando si usa Gestione API di Azure come gateway.
Query di esempio per il monitoraggio dell'utilizzo
ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend modelkey = substring(parse_json(BackendResponseBody)['model'], 0, indexof(parse_json(BackendResponseBody)['model'], '-', 0, -1, 2))
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend completiontokens = parse_json(parse_json(BackendResponseBody)['usage'])['completion_tokens']
| extend totaltokens = parse_json(parse_json(BackendResponseBody)['usage'])['total_tokens']
| extend ip = CallerIpAddress
| summarize
sum(todecimal(prompttokens)),
sum(todecimal(completiontokens)),
sum(todecimal(totaltokens)),
avg(todecimal(totaltokens))
by ip, model
Risultato:
Query di esempio per il monitoraggio dell'utilizzo della richiesta
ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend prompttext = substring(parse_json(parse_json(BackendResponseBody)['choices'])[0], 0, 100)
Risultato:
Input e output del modello di audit
A molti requisiti di controllo per i carichi di lavoro generativi di intelligenza artificiale è il monitoraggio dell'input e dell'output dei modelli. Potrebbe essere necessario sapere se una risposta proviene da un modello o da una cache. Esistono diversi casi d'uso per il monitoraggio sia degli input che degli output dei modelli. Nella maggior parte degli scenari, le regole di controllo devono essere applicate in modo uniforme in tutti i modelli, sia per gli input che per gli output.
I seguenti casi d'uso riguardano il monitoraggio degli input dei modelli.
Rilevamento delle minacce: Analizza gli input per identificare e mitigare i potenziali rischi per la sicurezza.
Rilevamento delle violazioni delle linee guida per l'uso: Analizza gli input per il linguaggio offensivo o altri standard di utilizzo per assicurarti che il sistema sia professionale, sicuro e imparziale.
Prestazioni del modello: Combinalo con gli output del modello per valutare le prestazioni in base a metriche come la solidità e la pertinenza. È possibile utilizzare queste informazioni per risolvere i problemi di prestazioni con il modello o i prompt.
Di seguito sono riportati alcuni dei casi d'uso per il monitoraggio degli output dei modelli.
Rilevamento dell'esfiltrazione dei dati: Analizza gli output per proteggerti dal trasferimento non autorizzato di informazioni sensibili.
Conformità dichiarata: Monitora gli output su più interazioni all'interno della stessa conversazione per rilevare perdite furtive di informazioni sensibili.
Conformità: Assicurati che i risultati siano conformi alle linee guida aziendali e ai requisiti normativi. Due esempi sono che le modelle non forniscono consulenza legale o fanno promesse finanziarie.
Prestazioni del modello: Combinalo con gli input del modello per valutare le prestazioni in base a metriche come la solidità e la pertinenza. È possibile utilizzare queste informazioni per risolvere i problemi di prestazioni con il modello o i prompt.
Problemi di controllo degli input e degli output del modello direttamente dal modello
Vincoli di registrazione del modello: Alcuni servizi, ad esempio Azure OpenAI, non registrano gli input e gli output del modello.
Cache: Architetture più complesse potrebbero fornire risposte dalla cache. In questi scenari, il modello non viene chiamato e non registra l'input o l'output.
Conversazioni stateful: Lo stato di una conversazione con più interazioni potrebbe essere archiviato all'esterno del modello. Il modello non sa quali interazioni devono essere correlate come conversazione.
Architettura a più modelli: Il livello di orchestrazione può richiamare dinamicamente più modelli per generare una risposta finale.
Introdurre un gateway per il controllo degli input e degli output del modello
Introdurre un gateway in questa topologia per acquisire sia l'input originale direttamente dal client che l'output finale che ritorna al client. Poiché il gateway è un'astrazione tra il client e i modelli e riceve direttamente la richiesta dai client, il gateway è in grado di registrare tale richiesta non elaborata e non elaborata. Analogamente, poiché il gateway è la risorsa che restituisce la risposta finale al client, è anche in grado di registrare tale risposta.
Il gateway ha la capacità unica di registrare sia la richiesta del client che la risposta finale ricevuta. Questa funzionalità si applica indipendentemente dal fatto che la risposta provenga direttamente da un modello, sia stata aggregata da più modelli o sia stata recuperata dalla cache. Inoltre, se i client passano un identificatore di conversazione, il gateway può registrare tale identificatore con l'input e l'output. È possibile utilizzare questa implementazione per correlare più interazioni di una conversazione.
Il monitoraggio degli input e degli output nel gateway consente di applicare le regole di controllo in modo uniforme in tutti i modelli.
Monitoraggio quasi in tempo reale
Monitoraggio di Azure non è ottimizzato per l'elaborazione quasi in tempo reale a causa della latenza intrinseca nell'inserimento dei dati di log. Se la soluzione richiede un'elaborazione quasi in tempo reale del traffico, è possibile prendere in considerazione una progettazione in cui si pubblicano i log direttamente in un bus di messaggi e si usa una tecnologia di elaborazione dei flussi, ad esempio Analisi di flusso di Azure, per eseguire operazioni finestrate.
Considerazioni sull'introduzione di un gateway per il monitoraggio
Latenza: L'introduzione di un gateway nell'architettura aggiunge latenza alle risposte. È necessario assicurarsi che i vantaggi dell'osservabilità superino le implicazioni in termini di prestazioni.
Sicurezza e privacy: Assicurarsi che i dati di monitoraggio raccolti utilizzando il gateway continuino a rispettare le aspettative di privacy dei clienti. I dati di osservabilità devono rispettare le aspettative di sicurezza e privacy stabilite del carico di lavoro e non violare gli standard di privacy dei clienti. Continuare a trattare tutti i dati sensibili acquisiti tramite il monitoraggio come dati sensibili.
Affidabilità: Determinare se la funzione di monitoraggio è fondamentale per la funzionalità del carico di lavoro. In caso affermativo, l'intera applicazione dovrebbe essere inattiva quando il sistema di monitoraggio non è disponibile. Se non è cruciale, l'applicazione deve continuare a funzionare in uno stato non monitorato se il sistema di monitoraggio è inattivo. Comprendere i rischi dell'aggiunta di un nuovo singolo punto di errore, a causa di errori del servizio o problemi di configurazione causati dall'uomo nel gateway.
Implementazione: L'implementazione può sfruttare i gateway predefiniti come Gestione API, incluse tutte le configurazioni necessarie. Un altro approccio comune consiste nell'implementare un livello di orchestrazione tramite codice.
Motivi per evitare di introdurre un gateway per il monitoraggio
Se una singola applicazione accede a un singolo modello, la complessità aggiuntiva dell'introduzione di un gateway probabilmente supera i vantaggi del monitoraggio. Il client può gestire la responsabilità della registrazione degli input e degli output. È inoltre possibile sfruttare le funzionalità di registrazione native del modello o del servizio utilizzato. Il gateway diventa vantaggioso quando si dispone di più client o più modelli che è necessario monitorare.
Passaggi successivi
Un'implementazione del gateway per il carico di lavoro offre vantaggi oltre al vantaggio tattico di routing back-end multiplo descritto in questo articolo. Per altre informazioni, vedere Accedere ad Azure OpenAI e ad altri modelli linguistici tramite un gateway.