Implementace rozšířeného monitorování pro Azure OpenAI prostřednictvím brány

Služby Azure AI

Azure OpenAI Service

Azure API Management

Microsoft Entra ID

Azure Monitor

Monitorování úloh, které zahrnují službu Azure OpenAI, může být stejně jednoduché jako povolení diagnostiky pro Azure OpenAI a použití předem nakonfigurovaných řídicích panelů. Tato strategie ale nesplňuje několik běžných, složitějších požadavků organizace na monitorování úloh generativní umělé inteligence, jako jsou:

• Sledování využití podle klientů a modelů za účelem správy kvót a implementace řešení zpětného zúčtování.

• Protokolování vstupů a výstupů modelu pro různé případy použití auditu a sledování výkonu modelu.

• Provádění monitorování téměř v reálném čase.

Poznámka:

Další informace o tom, jak přímo monitorovat Azure OpenAI, najdete v tématu Monitorování Azure OpenAI.

Následující diagram znázorňuje monitorování instancí Azure OpenAI bez brány. Pro tuto topologii není brána vyžadována. Vaše rozhodnutí o zařazení brány závisí na tom, zda jsou nastíněné scénáře monitorování součástí vašich požadavků. Tento článek se zabývá výzvami, které každý scénář monitorování řeší, spolu s výhodami a náklady na začlenění brány pro každý scénář.

Diagram, který znázorňuje dva klienty označené jako A a B, kteří přímo komunikují s nasazením modelu ve dvou instancích Azure OpenAI. Klient A má přímý přístup k nasazení gpt-35-turbo a nasazení gpt-4-o ve stejné instanci Azure OpenAI. Klient B přistupuje k nasazení gpt-4o v první instanci Azure OpenAI a přistupuje k nasazení gpt-4 ve druhé instanci Azure OpenAI. Klient B také zobrazuje přerušovanou čáru, která se připojuje k instanci gpt-4o ve druhém nasazení Azure OpenAI. Obě instance Azure OpenAI předávají metriky a protokoly Azure OpenAI do služby Azure Monitor.

Sledování využití modelu

Mnoho úloh nebo organizací potřebuje sledovat používání modelů Azure OpenAI klienty i modely ve všech instancích Azure OpenAI. Tyto informace používají k:

• Implementujte systém zpětného zúčtování, kde přidělují náklady na využití příslušné organizaci nebo vlastníkovi aplikace.

• Rozpočet a prognóza pro budoucí využití.

• Spojte modální náklady a využití s výkonem modelu.

Ke sledování telemetrie služby můžete použít nativní funkci monitorování Azure OpenAI, ale existují výzvy.

• U modelů vracení peněz musíte být schopni přidružit metriky využití tokenu Azure OpenAI k aplikaci nebo obchodní jednotce. Telemetrie Azure OpenAI zahrnuje volající IP adresu s maskovaným posledním oktetem. Toto maskování může ztížit vytvoření tohoto přidružení k aplikaci nebo obchodní jednotce.

• Instance Azure OpenAI v různých oblastech pravděpodobně zaznamenávají protokoly do instancí Azure Monitor v rámci příslušných místních oblastí. Tento proces vyžaduje, abyste agregovali protokoly z různých instancí služby Azure Monitor a sledovali využití ve všech instancích Azure OpenAI.

Zavedení brány pro sledování využití modelu

Diagram znázorňující dva klienty označené jako A a B přímo protínající bránu Brána má dvě šipky, které ukazují na privátní koncové body. První privátní koncový bod má dvě plné šipky, které ukazují na nasazení gpt-35-turbo a nasazení gpt-4o v nasazení Azure OpenAI. Druhý privátní koncový bod má plnou šipku, která ukazuje na nasazení gpt-4, a přerušovanou čáru, která ukazuje na nasazení gpt-4o ve druhé instanci Azure OpenAI. Obě instance Azure OpenAI předávají metriky a protokoly Azure OpenAI do služby Azure Monitor. Brána má šipku ukazující na Azure Monitor, která ukazuje, že předává metriky využití, včetně IP adresy, modelu a dat tokenu klienta.

Do této topologie zaveďte bránu, která zachytí úplnou IP adresu klienta, Microsoft Entra ID (nebo alternativní identitu) klienta nebo vlastní identifikátor pro obchodní jednotku, klienta nebo aplikaci na jednom místě. Tato data pak můžete použít k implementaci řešení zpětného zúčtování pro rozpočtování a prognózování a k provádění analýz nákladů a přínosů modelů.

Následující příklady ukazují dotazy na použití, které jsou možné, když jako bránu používáte Azure API Management.

Příklad dotazu na monitorování využití

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

Výstup:

Snímek obrazovky, který ukazuje výstup monitorování využití. Zobrazuje tabulku, která má pět sloupců a pět řádků. Sloupce představují IP adresu, model a tři typy tokenů. Tyto tokeny jsou celkový počet tokenů použitých ve vstupní výzvě, celkový počet tokenů vygenerovaných modelem v reakci na výzvu a kombinovaný součet tokenů výzvy a tokenů dokončení.

Příklad dotazu pro monitorování využití výzvy

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)

Výstup:

Snímek obrazovky, který ukazuje výstup monitorování využití. Zobrazuje tabulku, která má čtyři sloupce a sedm řádků. Sloupce představují čas vygenerovaný ve formátu UTC, model, tokeny výzev a text výzvy.

Vstupy a výstupy modelu auditu

Centrální pro mnoho požadavků na auditování pro úlohy generující AI je monitorování vstupu a výstupu modelů. Možná budete potřebovat vědět, jestli odpověď pocházela z modelu nebo z mezipaměti. Existuje několik případů použití pro monitorování vstupů i výstupů modelů. Ve většině scénářů by měla být pravidla auditování aplikována jednotně ve všech modelech pro vstupy i výstupy.

Následující případy použití slouží k monitorování vstupů do modelů.

• Detekce hrozeb: Analyzujte vstupy za účelem identifikace a zmírnění potenciálních bezpečnostních rizik.

• Detekce porušení pravidel použití: Analyzujte vstupy z hlediska urážlivých jazyků nebo jiných standardů použití, abyste zajistili, že systém je profesionální, bezpečný a nezaujatý.

• Výkon modelu: Kombinujte s výstupy modelu a vyhodnocujte výkon na základě metrik, jako je uzemnění a relevance. Tyto informace můžete použít k řešení problémů s výkonem modelu nebo výzev.

Níže jsou uvedeny některé případy použití pro monitorování výstupů do modelů.

• Detekce exfiltrace dat: Analyzujte výstupy a chraňte se před neoprávněným přenosem citlivých informací.

• Stavové dodržování předpisů: Monitorujte výstupy přes více interakcí v rámci jedné konverzace a detekujte skryté úniky citlivých informací.

• Vyhovění: Zajistěte, aby výstupy byly v souladu s podnikovými směrnicemi a regulačními požadavky. Dva příklady jsou, že modelky neposkytují právní poradenství ani neslibují finanční prostředky.

• Výkon modelu: Kombinujte se vstupy modelu a vyhodnocujte výkon na základě metrik, jako je uzemnění a relevance. Tyto informace můžete použít k řešení problémů s výkonem modelu nebo výzev.

Problémy s auditem vstupů a výstupů modelu přímo z modelu

• Omezení protokolování modelu: Některé služby, jako je Azure OpenAI, neprotokolují vstupy a výstupy modelu.

• Mezipaměť: Složitější architektury mohou obsluhovat odpovědi z mezipaměti. V těchto scénářích se model nevolá a neprotokoluje vstup ani výstup.

• Stavové konverzace: Stav konverzace s více interakcemi může být uložen mimo model. Model neví, které interakce by se měly korelovat jako konverzace.

• Vícemodelová architektura: Vrstva orchestrace může dynamicky vyvolat více modelů a vygenerovat konečnou odpověď.

Zavedení brány pro auditování vstupů a výstupů modelu

Diagram znázorňující dva klienty označené jako A a B přímo protínající bránu Brána má dvě šipky, které ukazují na privátní koncové body. První privátní koncový bod má dvě plné šipky, které ukazují na nasazení gpt-35-turbo a nasazení gpt-4o v nasazení Azure OpenAI. Druhý privátní koncový bod má plnou šipku, která ukazuje na nasazení gpt-4, a přerušovanou čáru, která ukazuje na nasazení gpt-4o ve druhé instanci Azure OpenAI. Obě instance Azure OpenAI se zobrazují předávání metrik Azure OpenAI a protokolů do služby Azure Monitor. Brána má šipku ukazující na Azure Monitor, která ukazuje, že předává vstupy a výstupy.

Do této topologie zaveďte bránu, která zachytí jak původní vstup přímo od klienta, tak konečný výstup vracející se klientovi. Vzhledem k tomu, že brána je abstrakcí mezi klientem a modely a přímo přijímá požadavek od klientů, je brána v pozici pro protokolování nezpracovaných a nezpracovaných požadavků. Podobně platí, že protože brána je zdrojem, který vrací konečnou odpověď klientovi, může tuto odpověď také protokolovat.

Brána má jedinečnou schopnost protokolovat požadavek klienta i konečnou odpověď, kterou obdržel. Tato funkce platí bez ohledu na to, jestli odpověď pocházela přímo z modelu, byla agregována z více modelů nebo byla načtena z mezipaměti. Pokud klienti předávají identifikátor konverzace, může brána tento identifikátor protokolovat pomocí vstupu a výstupu. Tuto implementaci můžete použít ke korelaci více interakcí v konverzaci.

Monitorování vstupůach

Monitorování téměř v reálném čase

Azure Monitor není optimalizovaný pro zpracování téměř v reálném čase kvůli inherentní latenci při příjmu dat protokolu. Pokud vaše řešení vyžaduje zpracování provozu téměř v reálném čase, můžete zvážit návrh, ve kterém publikujete protokoly přímo do sběrnice zpráv a použijete technologii zpracování datových proudů, jako je Azure Stream Analytics, k provádění operací s okny.

Diagram znázorňující dva klienty označené jako A a B přímo protínající bránu Brána má dvě šipky, které ukazují na privátní koncové body. První privátní koncový bod má dvě plné šipky, které ukazují na nasazení gpt-35-turbo a nasazení gpt-4o v nasazení Azure OpenAI. Druhý privátní koncový bod má plnou šipku, která ukazuje na nasazení gpt-4, a přerušovanou čáru, která ukazuje na nasazení gpt-4o ve druhé instanci Azure OpenAI. Obě instance Azure OpenAI se zobrazují předávání metrik Azure OpenAI a protokolů do služby Azure Monitor. Brána má šipku ukazující na Azure Monitor, která ukazuje, že předává vstupy a výstupy. Brána má další šipku, která ukazuje na sběrnici zpráv. Sběrnice zpráv obsahuje šipky, které ukazují na úložiště objektů blob a na procesor datových proudů.

Důležité informace při zavádění brány pro monitorování

• Latence: Zavedení brány do vaší architektury zvyšuje latenci vašich odpovědí. Musíte zajistit, aby výhody pozorovatelnosti převažovaly nad důsledky pro výkon.

• Bezpečnost a ochrana osobních údajů: Zajistěte, aby data monitorování shromážděná pomocí brány i nadále splňovala očekávání zákazníků v oblasti ochrany osobních údajů. Pozorovatelnost dat musí splňovat zavedená očekávání zabezpečení a ochrany osobních údajů dané úlohy a nesmí porušovat žádné standardy ochrany osobních údajů zákazníků. Se všemi citlivými daty zachycenými během monitorování nadále zacházejte jako s citlivými daty.

• Spolehlivost: Zjistěte, zda je funkce monitorování zásadní pro funkčnost úlohy. Pokud ano, měla by být celá aplikace vypnutá, když je monitorovací systém nedostupný. Pokud to není zásadní, aplikace by měla pokračovat v práci v nemonitorovaném stavu, pokud je monitorovací systém mimo provoz. Pochopte rizika přidání nového jediného bodu selhání, ať už kvůli chybám služby nebo problémům s konfigurací v bráně způsobeným člověkem.

• Implementace: Vaše implementace může využívat předem připravené brány, jako je API Management, včetně všech požadovaných konfigurací. Dalším běžným přístupem je implementace vrstvy orchestrace prostřednictvím kódu.

Důvody, proč se vyhnout zavedení brány pro monitorování

Pokud jedna aplikace přistupuje k jedinému modelu, zvýšená složitost zavedení brány pravděpodobně převáží nad výhodami monitorování. Klient může převzít odpovědnost za logování vstupů a výstupů. A můžete využít nativní možnosti protokolování modelu nebo služby, kterou používáte. Brána se stává výhodnou, když máte více klientů nebo více modelů, které potřebujete monitorovat.

Další kroky

Implementace brány pro vaši úlohu poskytuje výhody nad rámec taktické výhody vícenásobného back-endového směrování popsané v tomto článku. Další informace najdete v tématu Přístup k Azure OpenAI a dalším jazykovým modelům prostřednictvím brány.

Související prostředky

• Azure OpenAI
• Navrhnout dobře navrženou úlohu AI
• Brána rozhraní API ve službě API Management

Monitorování úloh, které zahrnují službu Azure OpenAI, může být stejně jednoduché jako povolení diagnostiky pro Azure OpenAI a použití předem nakonfigurovaných řídicích panelů. Tato strategie ale nesplňuje několik běžných, složitějších požadavků organizace na monitorování úloh generativní umělé inteligence, jako jsou:

• Sledování využití podle klientů a modelů za účelem správy kvót a implementace řešení zpětného zúčtování.

• Protokolování vstupů a výstupů modelu pro různé případy použití auditu a sledování výkonu modelu.

• Provádění monitorování téměř v reálném čase.

Poznámka:

Další informace o tom, jak přímo monitorovat Azure OpenAI, najdete v tématu Monitorování Azure OpenAI.

Následující diagram znázorňuje monitorování instancí Azure OpenAI bez brány. Pro tuto topologii není brána vyžadována. Vaše rozhodnutí o zařazení brány závisí na tom, zda jsou nastíněné scénáře monitorování součástí vašich požadavků. Tento článek se zabývá výzvami, které každý scénář monitorování řeší, spolu s výhodami a náklady na začlenění brány pro každý scénář.

Diagram, který znázorňuje dva klienty označené jako A a B, kteří přímo komunikují s nasazením modelu ve dvou instancích Azure OpenAI. Klient A má přímý přístup k nasazení gpt-35-turbo a nasazení gpt-4-o ve stejné instanci Azure OpenAI. Klient B přistupuje k nasazení gpt-4o v první instanci Azure OpenAI a přistupuje k nasazení gpt-4 ve druhé instanci Azure OpenAI. Klient B také zobrazuje přerušovanou čáru, která se připojuje k instanci gpt-4o ve druhém nasazení Azure OpenAI. Obě instance Azure OpenAI předávají metriky a protokoly Azure OpenAI do služby Azure Monitor.

Sledování využití modelu

Mnoho úloh nebo organizací potřebuje sledovat používání modelů Azure OpenAI klienty i modely ve všech instancích Azure OpenAI. Tyto informace používají k:

• Implementujte systém zpětného zúčtování, kde přidělují náklady na využití příslušné organizaci nebo vlastníkovi aplikace.

• Rozpočet a prognóza pro budoucí využití.

• Spojte modální náklady a využití s výkonem modelu.

Ke sledování telemetrie služby můžete použít nativní funkci monitorování Azure OpenAI, ale existují výzvy.

• U modelů vracení peněz musíte být schopni přidružit metriky využití tokenu Azure OpenAI k aplikaci nebo obchodní jednotce. Telemetrie Azure OpenAI zahrnuje volající IP adresu s maskovaným posledním oktetem. Toto maskování může ztížit vytvoření tohoto přidružení k aplikaci nebo obchodní jednotce.

• Instance Azure OpenAI v různých oblastech pravděpodobně zaznamenávají protokoly do instancí Azure Monitor v rámci příslušných místních oblastí. Tento proces vyžaduje, abyste agregovali protokoly z různých instancí služby Azure Monitor a sledovali využití ve všech instancích Azure OpenAI.

Zavedení brány pro sledování využití modelu

Diagram znázorňující dva klienty označené jako A a B přímo protínající bránu Brána má dvě šipky, které ukazují na privátní koncové body. První privátní koncový bod má dvě plné šipky, které ukazují na nasazení gpt-35-turbo a nasazení gpt-4o v nasazení Azure OpenAI. Druhý privátní koncový bod má plnou šipku, která ukazuje na nasazení gpt-4, a přerušovanou čáru, která ukazuje na nasazení gpt-4o ve druhé instanci Azure OpenAI. Obě instance Azure OpenAI předávají metriky a protokoly Azure OpenAI do služby Azure Monitor. Brána má šipku ukazující na Azure Monitor, která ukazuje, že předává metriky využití, včetně IP adresy, modelu a dat tokenu klienta.

Do této topologie zaveďte bránu, která zachytí úplnou IP adresu klienta, Microsoft Entra ID (nebo alternativní identitu) klienta nebo vlastní identifikátor pro obchodní jednotku, klienta nebo aplikaci na jednom místě. Tato data pak můžete použít k implementaci řešení zpětného zúčtování pro rozpočtování a prognózování a k provádění analýz nákladů a přínosů modelů.

Následující příklady ukazují dotazy na použití, které jsou možné, když jako bránu používáte Azure API Management.

Příklad dotazu na monitorování využití

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

Výstup:

Snímek obrazovky, který ukazuje výstup monitorování využití. Zobrazuje tabulku, která má pět sloupců a pět řádků. Sloupce představují IP adresu, model a tři typy tokenů. Tyto tokeny jsou celkový počet tokenů použitých ve vstupní výzvě, celkový počet tokenů vygenerovaných modelem v reakci na výzvu a kombinovaný součet tokenů výzvy a tokenů dokončení.

Příklad dotazu pro monitorování využití výzvy

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)

Výstup:

Snímek obrazovky, který ukazuje výstup monitorování využití. Zobrazuje tabulku, která má čtyři sloupce a sedm řádků. Sloupce představují čas vygenerovaný ve formátu UTC, model, tokeny výzev a text výzvy.

Vstupy a výstupy modelu auditu

Centrální pro mnoho požadavků na auditování pro úlohy generující AI je monitorování vstupu a výstupu modelů. Možná budete potřebovat vědět, jestli odpověď pocházela z modelu nebo z mezipaměti. Existuje několik případů použití pro monitorování vstupů i výstupů modelů. Ve většině scénářů by měla být pravidla auditování aplikována jednotně ve všech modelech pro vstupy i výstupy.

Následující případy použití slouží k monitorování vstupů do modelů.

• Detekce hrozeb: Analyzujte vstupy za účelem identifikace a zmírnění potenciálních bezpečnostních rizik.

• Detekce porušení pravidel použití: Analyzujte vstupy z hlediska urážlivých jazyků nebo jiných standardů použití, abyste zajistili, že systém je profesionální, bezpečný a nezaujatý.

• Výkon modelu: Kombinujte s výstupy modelu a vyhodnocujte výkon na základě metrik, jako je uzemnění a relevance. Tyto informace můžete použít k řešení problémů s výkonem modelu nebo výzev.

Níže jsou uvedeny některé případy použití pro monitorování výstupů do modelů.

• Detekce exfiltrace dat: Analyzujte výstupy a chraňte se před neoprávněným přenosem citlivých informací.

• Stavové dodržování předpisů: Monitorujte výstupy přes více interakcí v rámci jedné konverzace a detekujte skryté úniky citlivých informací.

• Vyhovění: Zajistěte, aby výstupy byly v souladu s podnikovými směrnicemi a regulačními požadavky. Dva příklady jsou, že modelky neposkytují právní poradenství ani neslibují finanční prostředky.

• Výkon modelu: Kombinujte se vstupy modelu a vyhodnocujte výkon na základě metrik, jako je uzemnění a relevance. Tyto informace můžete použít k řešení problémů s výkonem modelu nebo výzev.

Problémy s auditem vstupů a výstupů modelu přímo z modelu

• Omezení protokolování modelu: Některé služby, jako je Azure OpenAI, neprotokolují vstupy a výstupy modelu.

• Mezipaměť: Složitější architektury mohou obsluhovat odpovědi z mezipaměti. V těchto scénářích se model nevolá a neprotokoluje vstup ani výstup.

• Stavové konverzace: Stav konverzace s více interakcemi může být uložen mimo model. Model neví, které interakce by se měly korelovat jako konverzace.

• Vícemodelová architektura: Vrstva orchestrace může dynamicky vyvolat více modelů a vygenerovat konečnou odpověď.

Zavedení brány pro auditování vstupů a výstupů modelu

Diagram znázorňující dva klienty označené jako A a B přímo protínající bránu Brána má dvě šipky, které ukazují na privátní koncové body. První privátní koncový bod má dvě plné šipky, které ukazují na nasazení gpt-35-turbo a nasazení gpt-4o v nasazení Azure OpenAI. Druhý privátní koncový bod má plnou šipku, která ukazuje na nasazení gpt-4, a přerušovanou čáru, která ukazuje na nasazení gpt-4o ve druhé instanci Azure OpenAI. Obě instance Azure OpenAI se zobrazují předávání metrik Azure OpenAI a protokolů do služby Azure Monitor. Brána má šipku ukazující na Azure Monitor, která ukazuje, že předává vstupy a výstupy.

Do této topologie zaveďte bránu, která zachytí jak původní vstup přímo od klienta, tak konečný výstup vracející se klientovi. Vzhledem k tomu, že brána je abstrakcí mezi klientem a modely a přímo přijímá požadavek od klientů, je brána v pozici pro protokolování nezpracovaných a nezpracovaných požadavků. Podobně platí, že protože brána je zdrojem, který vrací konečnou odpověď klientovi, může tuto odpověď také protokolovat.

Brána má jedinečnou schopnost protokolovat požadavek klienta i konečnou odpověď, kterou obdržel. Tato funkce platí bez ohledu na to, jestli odpověď pocházela přímo z modelu, byla agregována z více modelů nebo byla načtena z mezipaměti. Pokud klienti předávají identifikátor konverzace, může brána tento identifikátor protokolovat pomocí vstupu a výstupu. Tuto implementaci můžete použít ke korelaci více interakcí v konverzaci.

Monitorování vstupůach

Monitorování téměř v reálném čase

Azure Monitor není optimalizovaný pro zpracování téměř v reálném čase kvůli inherentní latenci při příjmu dat protokolu. Pokud vaše řešení vyžaduje zpracování provozu téměř v reálném čase, můžete zvážit návrh, ve kterém publikujete protokoly přímo do sběrnice zpráv a použijete technologii zpracování datových proudů, jako je Azure Stream Analytics, k provádění operací s okny.

Diagram znázorňující dva klienty označené jako A a B přímo protínající bránu Brána má dvě šipky, které ukazují na privátní koncové body. První privátní koncový bod má dvě plné šipky, které ukazují na nasazení gpt-35-turbo a nasazení gpt-4o v nasazení Azure OpenAI. Druhý privátní koncový bod má plnou šipku, která ukazuje na nasazení gpt-4, a přerušovanou čáru, která ukazuje na nasazení gpt-4o ve druhé instanci Azure OpenAI. Obě instance Azure OpenAI se zobrazují předávání metrik Azure OpenAI a protokolů do služby Azure Monitor. Brána má šipku ukazující na Azure Monitor, která ukazuje, že předává vstupy a výstupy. Brána má další šipku, která ukazuje na sběrnici zpráv. Sběrnice zpráv obsahuje šipky, které ukazují na úložiště objektů blob a na procesor datových proudů.

Důležité informace při zavádění brány pro monitorování

• Latence: Zavedení brány do vaší architektury zvyšuje latenci vašich odpovědí. Musíte zajistit, aby výhody pozorovatelnosti převažovaly nad důsledky pro výkon.

• Bezpečnost a ochrana osobních údajů: Zajistěte, aby data monitorování shromážděná pomocí brány i nadále splňovala očekávání zákazníků v oblasti ochrany osobních údajů. Pozorovatelnost dat musí splňovat zavedená očekávání zabezpečení a ochrany osobních údajů dané úlohy a nesmí porušovat žádné standardy ochrany osobních údajů zákazníků. Se všemi citlivými daty zachycenými během monitorování nadále zacházejte jako s citlivými daty.

• Spolehlivost: Zjistěte, zda je funkce monitorování zásadní pro funkčnost úlohy. Pokud ano, měla by být celá aplikace vypnutá, když je monitorovací systém nedostupný. Pokud to není zásadní, aplikace by měla pokračovat v práci v nemonitorovaném stavu, pokud je monitorovací systém mimo provoz. Pochopte rizika přidání nového jediného bodu selhání, ať už kvůli chybám služby nebo problémům s konfigurací v bráně způsobeným člověkem.

• Implementace: Vaše implementace může využívat předem připravené brány, jako je API Management, včetně všech požadovaných konfigurací. Dalším běžným přístupem je implementace vrstvy orchestrace prostřednictvím kódu.

Důvody, proč se vyhnout zavedení brány pro monitorování

Pokud jedna aplikace přistupuje k jedinému modelu, zvýšená složitost zavedení brány pravděpodobně převáží nad výhodami monitorování. Klient může převzít odpovědnost za logování vstupů a výstupů. A můžete využít nativní možnosti protokolování modelu nebo služby, kterou používáte. Brána se stává výhodnou, když máte více klientů nebo více modelů, které potřebujete monitorovat.

Další kroky

Implementace brány pro vaši úlohu poskytuje výhody nad rámec taktické výhody vícenásobného back-endového směrování popsané v tomto článku. Další informace najdete v tématu Přístup k Azure OpenAI a dalším jazykovým modelům prostřednictvím brány.

Související prostředky

• Azure OpenAI
• Navrhnout dobře navrženou úlohu AI
• Brána rozhraní API ve službě API Management