透過閘道實作 Azure OpenAI 的進階監視

Azure AI 服務

Azure OpenAI 服務

Azure API 管理

Microsoft Entra ID

Azure 監視器

監視包含 Azure OpenAI 服務的工作負載就像為 Azure OpenAI 啟用診斷並使用預配置的儀錶板一樣簡單。但是，此策略無法滿足生成式 AI 工作負載的幾個常見、更複雜的組織監控要求，例如：

按用戶端和模型跟蹤使用方式，以管理配額並實施按存儲容量使用計費解決方案。
記錄各種審計使用案例的模型輸入和模型輸出，並監控模型性能。
執行近乎即時的監視。

備註

有關如何直接監控 Azure OpenAI 的更多資訊，請參閱監控 Azure OpenAI。

下圖說明瞭如何在沒有網關的情況下監視 Azure OpenAI 實例。此拓撲不需要閘道。您是否包含閘道的決定取決於概述的監控方案是否是您要求的一部分。本文探討了每個監控方案解決的挑戰，以及為每個方案整合網關的好處和成本。

跟蹤模型使用方式

許多工作負載或組織需要跟蹤用戶端和所有 Azure OpenAI 實例中的模型對 Azure OpenAI 模型的使用方式。他們使用這些資訊來：

實施按存儲容量使用計費系統，將使用方式成本分配給相應的組織或應用程式擁有者。
未來使用方式的預算和預測。
將模態成本和使用方式與模型性能聯繫起來。

您可以使用原生 Azure OpenAI 監視功能來追蹤服務的遙測，但存在挑戰。

針對退款模型，您必須能夠將 Azure OpenAI 令牌使用計量與應用程式或業務單位產生關聯。 Azure OpenAI 遙測包括一個調用的IP位址，其中最後一個八位位元組被遮罩。這種遮罩可能會使建立與應用程式或營業單位的關聯具有挑戰性。
不同區域中的 Azure OpenAI 實例可能會將日誌記錄到其各自本地區域內的 Azure Monitor 實例中。此過程需要聚合來自不同 Azure Monitor 實例的日誌，以跟蹤所有 Azure OpenAI 實例的使用方式。

介紹用來追蹤模型使用方式的閘道

在此拓撲中引入閘道，以在一個位置捕獲完整的用戶端IP位址、用戶端的 Microsoft Entra ID（或備用標識）或營業單位、租戶或應用程式的自定義標識符。然後，您可以使用此數據實施用於預算和預測的按存儲容量使用計費解決方案，並執行模型的成本效益分析。

以下示例顯示了使用 Azure API 管理作為閘道時可能進行的使用方式查詢。

使用情況監視的範例查詢

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

輸出：

提示使用方式監視的範例查詢

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)

輸出：

審計模型輸入和輸出

對於衍生式 AI 工作負載的許多稽核需求而言，其核心是監視模型的輸入和輸出。您可能需要知道回應是來自模型還是來自緩存。有多種用例可用於監控模型的輸入和輸出。在大多數情況下，審計規則應統一應用於輸入和輸出的所有模型。

以下使用案例用於監控模型的輸入。

威脅檢測： 分析輸入以識別和緩解潛在的安全風險。
使用準則違規檢測： 分析冒犯性語言或其他使用標準的輸入，以確保系統專業、安全且公正。
模型性能： 結合模型輸出來評估 groundis 和 re相關性等指標的性能。您可以使用此資訊來解決模型或提示的性能問題。

以下是監控模型輸出的一些使用案例。

數據洩露檢測： 分析輸出以防止未經授權傳輸敏感資訊。
狀態合規性： 監控同一對話中多次交互的輸出，以檢測敏感資訊的隱蔽洩漏。
合規： 確保輸出符合公司準則和法規要求。兩個例子是模特不提供法律建議或做出財務承諾。
模型性能： 結合模型輸入來評估 groundis 和 res相關性等指標的性能。您可以使用此資訊來解決模型或提示的性能問題。

直接從模型稽核模型輸入和輸出的挑戰

模型日誌記錄約束： 某些服務（如 Azure OpenAI）不會記錄模型輸入和輸出。
緩存： 更複雜的架構可能會提供來自緩存的回應。在這些情況下，不會調用模型，也不會記錄輸入或輸出。
狀態對話： 多交互對話的狀態可能存儲在模型外部。模型不知道哪些互動應該與交談相互關聯。
多模型架構： 編排層可能會動態調用多個模型來生成最終回應。

引進用於稽核模型輸入和輸出的閘道

在此拓撲中引入閘道，以直接從用戶端捕獲原始輸入和返回給客戶端的最終輸出。由於閘道是用戶端與模型之間的抽象概念，而且會直接從用戶端接收要求，因此閘道會用來記錄該未經處理的原始要求。同樣，由於網關是將最終回應返回給客戶端的資源，因此它也能夠記錄該回應。

閘道具有記錄客戶端請求及其收到的最終回應的獨特功能。無論回應是直接來自模型、從多個模型聚合還是從緩存中檢索，此功能都適用。此外，如果客戶端傳遞交談標識碼，閘道可以使用輸入和輸出來記錄該標識碼。您可以使用此實施來關聯對話的多個交互。

監視閘道的輸入和輸出可讓您在所有模型中統一套用稽核規則。

近乎即時的監視

由於日誌數據引入的固有延遲，Azure Monitor 未針對準即時處理進行優化。如果您的解決方案需要近乎即時的流量處理，您可以考慮將記錄直接發佈至訊息總線，並使用 Azure 串流分析等串流處理技術來執行視窗化作業的設計。

引入閘道進行監控時的注意事項

延遲： 在架構中引入閘道會增加回應的延遲。您需要確保可觀測性的好處大於性能影響。
安全和隱私： 確保使用閘道收集的監控數據繼續符合客戶隱私期望。可觀測性數據必須遵守工作負載的既定安全和隱私預期，並且不違反任何客戶隱私標準。繼續將通過監控捕獲的任何敏感數據視為敏感數據。
可靠性： 確定監控功能是否對工作負載的功能至關重要。如果是，則當監控系統不可用時，整個應用程式應關閉。如果這並不重要，則當監控系統關閉時，應用程式應繼續在不受監控的狀態下工作。了解通過閘道中的服務故障或人為導致的配置問題添加新的單點故障的風險。
實現： 您的實施可以利用 API 管理等開箱即用的閘道，包括所有必需的配置。另一種常見的方法是通過代碼實現編排層。

避免引進閘道進行監視的原因

如果單個應用程式訪問單個模型，則引入閘道增加的複雜性可能會超過監控的好處。用戶端可以處理記錄輸入和輸出的責任。您可以利用您使用的模型或服務的本機日誌記錄功能。當您有多個用戶端或多個需要監控的模型時，閘道將變得非常有用。

後續步驟

適用於您的工作負載的網關實現提供的好處超出了本文中描述的戰術性、多個後端路由的優勢。有關詳細資訊，請參閱通過網關訪問 Azure OpenAI 和其他語言模型。

意見反應

此頁面對您有幫助嗎？