Implementera avancerad övervakning för Azure OpenAI via en gateway
Övervakning av arbetsbelastningar som innehåller Azure OpenAI-tjänsten kan vara så enkelt som att aktivera diagnostik för Azure OpenAI och använda förkonfigurerade instrumentpaneler. Den här strategin uppfyller dock inte flera vanliga, mer komplexa, organisatoriska övervakningskrav för generativa AI-arbetsbelastningar, till exempel:
Anmärkning
Mer information om hur du övervakar Azure OpenAI direkt finns i Övervaka Azure OpenAI.
Följande diagram illustrerar övervakningen av Azure OpenAI-instanser utan en gateway. En gateway krävs inte för den här topologin. Ditt beslut att inkludera en gateway beror på om de beskrivna övervakningsscenarierna är en del av dina krav. Den här artikeln undersöker de utmaningar som varje övervakningsscenario hanterar, tillsammans med fördelarna och kostnaderna för att införliva en gateway för varje scenario.
Spåra modellanvändning
Många arbetsbelastningar eller organisationer behöver spåra användningen av Azure OpenAI-modeller av både klienter och modeller i alla Azure OpenAI-instanser. De använder den här informationen för att:
Implementera ett återbetalningssystem där de allokerar användningskostnader till lämplig organisation eller programägare.
Budget och prognos för framtida användning.
Koppla modal kostnad och användning till modellens prestanda.
Du kan använda den interna Azure OpenAI-övervakningsfunktionen för att spåra telemetri för tjänsten, men det finns utmaningar.
För återbetalningsmodeller måste du kunna associera användningsstatistiken för Azure OpenAI-token med ett program eller en affärsenhet. Azure OpenAI-telemetri innehåller en anropande IP-adress med den sista oktetten maskerad. Den här maskeringen kan göra det svårt att upprätta den här associationen till ett program eller en affärsenhet.
Azure OpenAI-instanser i olika regioner registrerar sannolikt loggar till Azure Monitor-instanser inom sina respektive lokala regioner. Den här processen kräver att du aggregerar loggar från olika Azure Monitor-instanser för att spåra användningen i alla Azure OpenAI-instanser.
Introducera en gateway för att spåra modellanvändning
Introducera en gateway i den här topologin för att samla in den fullständiga klientens IP-adress, Microsoft Entra-ID (eller alternativ identitet) för klienten eller en anpassad identifierare för en affärsenhet, en klientorganisation eller ett program på ett ställe. Du kan sedan använda dessa data för att implementera en återbetalningslösning för budgetering och prognostisering och för att utföra kostnads-nyttoanalyser av modeller.
I följande exempel visas användningsfrågor som är möjliga när du använder Azure API Management som en gateway.
Exempelfråga för användningsövervakning
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
Utdata:
Exempelfråga för övervakning av fråga om användning
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)
Utdata:
Indata och utfall av revisionsmodeller
Centralt för många granskningskrav för generativa AI-arbetsbelastningar är övervakning av indata och utdata från modellerna. Du kan behöva veta om ett svar kommer från en modell eller kommer från en cache. Det finns flera användningsfall för att övervaka både indata och utdata från modeller. I de flesta scenarier bör granskningsregler tillämpas enhetligt i alla modeller för både indata och utdata.
Följande användningsfall är för att övervaka indata till modeller.
Identifiering av hot: Analysera indata för att identifiera och minimera potentiella säkerhetsrisker.
Identifiering av överträdelser av användningsriktlinjer: Analysera indata för stötande språk eller andra användningsstandarder för att säkerställa att systemet är professionellt, säkert och opartiskt.
Modellens prestanda: Kombinera med modellutdata för att utvärdera prestanda på mätvärden som grundlighet och relevans. Du kan använda den här informationen för att åtgärda prestandaproblem med modellen eller prompterna.
Följande är några av användningsfallen för att övervaka utdata till modeller.
Identifiering av data exfiltrering: Analysera utdata för att skydda mot obehörig överföring av känslig information.
Tillståndskänslig efterlevnad: Övervaka utdata över flera interaktioner i samma konversation för att upptäcka smygande läckor av känslig information.
Tillmötesgående: Se till att resultaten följer företagets riktlinjer och lagstadgade krav. Två exempel är att modeller inte ger juridisk rådgivning eller ger ekonomiska löften.
Modellens prestanda: Kombinera med modellindata för att utvärdera prestanda på mätvärden som grundlighet och relevans. Du kan använda den här informationen för att åtgärda prestandaproblem med modellen eller prompterna.
Utmaningar med att granska modellindata och utdata direkt från modellen
Begränsningar för modellloggning: Vissa tjänster, till exempel Azure OpenAI, loggar inte modellens indata och utdata.
Cache: Mer komplexa arkitekturer kan hantera svar från cacheminnet. I dessa scenarier anropas inte modellen och loggar inte indata eller utdata.
Tillståndskänsliga konversationer: Tillståndet för en konversation med flera interaktioner kan lagras utanför modellen. Modellen vet inte vilka interaktioner som ska korreleras som en konversation.
Arkitektur med flera modeller: Orkestreringslagret kan dynamiskt anropa flera modeller för att generera ett slutligt svar.
Introducera en gateway för granskning av modellindata och utdata
Introducera en gateway i den här topologin för att samla in både de ursprungliga indata direkt från klienten och de slutliga utdata som returneras till klienten. Eftersom gatewayen är en abstraktion mellan klienten och modellerna och direkt tar emot begäran från klienterna är gatewayen i stånd att logga den råa, obearbetade begäran. På samma sätt, eftersom gatewayen är den resurs som returnerar det slutliga svaret till klienten, kan den också logga det svaret.
Gatewayen har den unika förmågan att logga både klientens begäran och det slutliga svaret som den fick. Den här funktionen gäller oavsett om svaret kom direkt från en modell, aggregerades från flera modeller eller hämtades från cacheminnet. Om klienterna skickar en konversationsidentifierare kan gatewayen logga identifieraren med indata och utdata. Du kan använda den här implementeringen för att korrelera flera interaktioner i en konversation.
Genom att övervaka indata och utdata på gatewayen kan du tillämpa granskningsregler på ett enhetligt sätt i alla modeller.
Övervakning i nära realtid
Azure Monitor är inte optimerat för bearbetning i nära realtid på grund av den inbyggda svarstiden i inmatning av loggdata. Om din lösning kräver nästan realtidsbearbetning av trafik kan du överväga en design där du publicerar loggar direkt till en meddelandebuss och använder en dataströmbearbetningsteknik, till exempel Azure Stream Analytics, för att utföra fönsteråtgärder.
Att tänka på när du introducerar en gateway för övervakning
Latens: Genom att introducera en gateway i din arkitektur ökar svarstiden för dina svar. Du måste se till att fördelarna med observerbarhet uppväger prestandakonsekvenserna.
Säkerhet och integritet: Se till att övervakningsdata som samlas in med hjälp av gatewayen fortsätter att följa kundernas förväntningar på sekretess. Observerbarhetsdata måste följa de etablerade säkerhets- och sekretessförväntningarna för arbetsbelastningen och inte bryta mot några kundsekretessstandarder. Fortsätt att behandla känsliga data som samlas in genom övervakning som känsliga data.
Tillförlitlighet: Avgör om övervakningsfunktionen är avgörande för arbetsbelastningens funktionalitet. Om så är fallet bör hela programmet vara nere när övervakningssystemet inte är tillgängligt. Om det inte är avgörande bör programmet fortsätta att fungera i ett oövervakat tillstånd om övervakningssystemet är nere. Förstå riskerna med att lägga till en ny felkritisk systemdel, antingen via tjänstfel eller konfigurationsproblem som orsakas av människor i gatewayen.
Genomförande: Implementeringen kan dra nytta av färdiga gatewayer som API Management, inklusive alla nödvändiga konfigurationer. En annan vanlig metod är att implementera ett orkestreringslager via kod.
Anledningar till att undvika att införa en gateway för övervakning
Om ett enda program har åtkomst till en enda modell uppväger den extra komplexiteten med att introducera en gateway troligen fördelarna med övervakning. Klienten kan hantera ansvaret för loggning av indata och utdata. Och du kan dra nytta av inbyggda loggningsfunktioner i den modell eller tjänst som du använder. Gatewayen blir fördelaktig när du har flera klienter eller flera modeller som du behöver övervaka.
Nästa steg
En gatewayimplementering för din arbetsbelastning ger fördelar utöver den taktiska fördelen med flera serverdelsroutningar som beskrivs i den här artikeln. Mer information finns i Åtkomst till Azure OpenAI och andra språkmodeller via en gateway.