Implementación de supervisión avanzada para Azure OpenAI a través de una puerta de enlace
La supervisión de cargas de trabajo que incluyen Azure OpenAI Service puede ser tan sencilla como habilitar el diagnóstico para Azure OpenAI y usar paneles preconfigurados. Sin embargo, esta estrategia no satisface varios requisitos comunes y más complejos de supervisión organizacional para las cargas de trabajo de IA generativa, como:
Nota:
Para obtener más información sobre cómo supervisar Azure OpenAI directamente, consulte Supervisión de Azure OpenAI.
En el diagrama siguiente se muestra la supervisión de instancias de Azure OpenAI sin una puerta de enlace. No se requiere una puerta de enlace para esta topología. La decisión de incluir una puerta de enlace depende de si los escenarios de supervisión descritos forman parte de los requisitos. En este artículo se examinan los desafíos que aborda cada escenario de supervisión, junto con los beneficios y costos de incorporar una puerta de enlace para cada escenario.
Seguimiento del uso del modelo
Muchas cargas de trabajo u organizaciones necesitan realizar un seguimiento del uso de los modelos de Azure OpenAI por parte de los clientes y los modelos en todas las instancias de Azure OpenAI. Utilizan esta información para:
Implemente un sistema de contracargos en el que asignen los costos de uso a la organización o al propietario de la aplicación correspondiente.
Presupuesto y previsión de uso futuro.
Vincule el costo y el uso modal con el rendimiento del modelo.
Puede usar la funcionalidad nativa de supervisión de Azure OpenAI para realizar un seguimiento de la telemetría del servicio, pero hay desafíos.
Para los modelos de contracargo, debe poder asociar las métricas de uso de tokens de Azure OpenAI a una aplicación o unidad de negocio. La telemetría de Azure OpenAI incluye una dirección IP de llamada con el último octeto enmascarado. Este enmascaramiento puede dificultar el establecimiento de esta asociación con una aplicación o unidad de negocio.
Es probable que las instancias de Azure OpenAI en varias regiones registren registros en instancias de Azure Monitor dentro de sus respectivas regiones locales. Este proceso requiere que agregue registros de diferentes instancias de Azure Monitor para realizar un seguimiento del uso en todas las instancias de Azure OpenAI.
Introducción de una puerta de enlace para realizar un seguimiento del uso del modelo
Introduzca una puerta de enlace en esta topología para capturar la dirección IP completa del cliente, el identificador de Microsoft Entra (o identidad alternativa) del cliente o un identificador personalizado para una unidad de negocio, un inquilino o una aplicación en un solo lugar. A continuación, puede utilizar estos datos para implementar una solución de contracargo para la elaboración de presupuestos y previsiones, y para realizar análisis de coste-beneficio de los modelos.
En los ejemplos siguientes se muestran las consultas de uso que son posibles cuando se usa Azure API Management como puerta de enlace.
Consulta de ejemplo para la supervisión del uso
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
Salida:
Consulta de ejemplo para la supervisión del uso de mensajes
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)
Salida:
Auditar las entradas y salidas del modelo
De forma fundamental para muchos requisitos de auditoría para cargas de trabajo de IA generativas, se supervisa la entrada y salida de los modelos. Es posible que necesite saber si una respuesta provino de un modelo o de una caché. Existen múltiples casos de uso para monitorear las entradas y salidas de los modelos. En la mayoría de los escenarios, las reglas de auditoría deben aplicarse de manera uniforme en todos los modelos, tanto para las entradas como para las salidas.
Los siguientes casos de uso son para monitorear las entradas a los modelos.
Detección de amenazas: Analice las entradas para identificar y mitigar los posibles riesgos de seguridad.
Detección de infracciones de las directrices de uso: Analice las entradas en busca de lenguaje ofensivo u otros estándares de uso para asegurarse de que el sistema sea profesional, seguro e imparcial.
Rendimiento del modelo: Combínelo con los resultados del modelo para evaluar el rendimiento en métricas como la fundamentación y la relevancia. Puede usar esta información para solucionar problemas de rendimiento con el modelo o las solicitudes.
A continuación se muestran algunos de los casos de uso para monitorear las salidas a los modelos.
Detección de exfiltración de datos: Analice los resultados para protegerse contra la transferencia no autorizada de información confidencial.
Cumplimiento con estado: Supervise los resultados de varias interacciones dentro de la misma conversación para detectar fugas sigilosas de información confidencial.
Conformidad: Asegúrese de que los resultados se adhieran a las directrices corporativas y a los requisitos normativos. Dos ejemplos son que las modelos no brindan asesoramiento legal ni hacen promesas financieras.
Rendimiento del modelo: Combínelo con las entradas del modelo para evaluar el rendimiento en métricas como la fundamentación y la relevancia. Puede usar esta información para solucionar problemas de rendimiento con el modelo o las solicitudes.
Desafíos para auditar las entradas y salidas del modelo directamente desde el modelo
Restricciones de registro del modelo: Algunos servicios, como Azure OpenAI, no registran las entradas y salidas del modelo.
Caché: Las arquitecturas más complejas pueden servir respuestas desde la caché. En esos escenarios, no se llama al modelo y no registra la entrada ni la salida.
Conversaciones con estado: Es posible que el estado de una conversación de varias interacciones se almacene fuera del modelo. El modelo no sabe qué interacciones se deben correlacionar como una conversación.
Arquitectura de varios modelos: La capa de orquestación puede invocar dinámicamente varios modelos para generar una respuesta final.
Introducción de una puerta de enlace para auditar entradas y salidas del modelo
Introduzca una puerta de enlace en esta topología para capturar tanto la entrada original directamente desde el cliente como la salida final que regresa al cliente. Dado que la puerta de enlace es una abstracción entre el cliente y los modelos y recibe directamente la solicitud de los clientes, la puerta de enlace está en una posición para registrar esa solicitud sin procesar y sin procesar. Del mismo modo, dado que la puerta de enlace es el recurso que devuelve la respuesta final al cliente, también puede registrar esa respuesta.
La puerta de enlace tiene la capacidad única de registrar tanto la solicitud del cliente como la respuesta final que recibió. Esta característica se aplica tanto si la respuesta provino directamente de un modelo, como si se agregó de varios modelos o se recuperó de la memoria caché. Además, si los clientes pasan un identificador de conversación, la puerta de enlace puede registrar ese identificador con la entrada y salida. Puede utilizar esta implementación para correlacionar varias interacciones de una conversación.
La supervisión de entradas y salidas en la puerta de enlace permite aplicar reglas de auditoría uniformemente en todos los modelos.
Supervisión casi en tiempo real
Azure Monitor no está optimizado para el procesamiento casi en tiempo real debido a la latencia inherente a la ingesta de datos de registro. Si la solución requiere un procesamiento casi en tiempo real del tráfico, puede considerar un diseño en el que publique registros directamente en un bus de mensajes y use una tecnología de procesamiento de flujos, como Azure Stream Analytics, para realizar operaciones con ventanas.
Consideraciones al introducir una puerta de enlace para la supervisión
Latencia: La introducción de una puerta de enlace en la arquitectura agrega latencia a las respuestas. Debe asegurarse de que los beneficios de la observabilidad superen las implicaciones de rendimiento.
Seguridad y privacidad: Asegúrese de que los datos de supervisión recopilados mediante el uso de la puerta de enlace sigan cumpliendo con las expectativas de privacidad del cliente. Los datos de observabilidad deben cumplir con las expectativas de seguridad y privacidad establecidas de la carga de trabajo y no violar ningún estándar de privacidad del cliente. Continúe tratando los datos confidenciales capturados a través de la supervisión como datos confidenciales.
Fiabilidad: Determine si la función de supervisión es crucial para la funcionalidad de la carga de trabajo. Si es así, toda la aplicación debe estar inactiva cuando el sistema de supervisión no esté disponible. Si no es crucial, la aplicación debe seguir funcionando en un estado no supervisado si el sistema de supervisión está inactivo. Comprenda los riesgos de agregar un nuevo punto único de error, ya sea a través de errores de servicio o problemas de configuración causados por humanos en la puerta de enlace.
Implementación: La implementación puede aprovechar las puertas de enlace listas para usar, como API Management, incluidas todas las configuraciones necesarias. Otro enfoque común es implementar una capa de orquestación a través del código.
Motivos para evitar la introducción de una puerta de enlace para la supervisión
Si una sola aplicación accede a un solo modelo, es probable que la complejidad adicional de introducir una puerta de enlace supere los beneficios de la supervisión. El cliente puede manejar la responsabilidad de registrar entradas y salidas. Y puede aprovechar las capacidades de registro nativas del modelo o servicio que utiliza. La puerta de enlace resulta beneficiosa cuando tiene varios clientes o varios modelos que necesita supervisar.
Pasos siguientes
Una implementación de puerta de enlace para la carga de trabajo proporciona ventajas más allá de la ventaja táctica de enrutamiento de back-end múltiple que se describe en este artículo. Para más información, consulte Acceso a Azure OpenAI y otros modelos de lenguaje a través de una puerta de enlace.