你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

通过网关实现 Azure OpenAI 的高级监视

Azure AI 服务

Azure OpenAI 服务

Azure API 管理

Microsoft Entra ID

Azure Monitor

监视包含 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 和其他语言模型。

通过