Arquitectura de referencia de chat de un extremo a otro de línea de base de OpenAI

Las aplicaciones de chat empresarial pueden capacitar a los empleados a través de la interacción conversacional. Esto es especialmente cierto debido al avance continuo de modelos de lenguaje, como los modelos GPT de OpenAI y los modelos LLaMA de Meta. Estas aplicaciones de chat constan de una interfaz de usuario de chat, repositorios de datos que contienen información específica del dominio pertinente a las consultas del usuario, modelos de lenguaje que se deben usar a través de los datos específicos del dominio para generar una respuesta relevante y un orquestador que supervisa la interacción entre estos componentes.

En este artículo se proporciona una arquitectura de línea de base para crear e implementar aplicaciones de chat empresariales que usan modelos de lenguaje de Azure OpenAI Service. La arquitectura emplea el flujo de avisos de Azure Machine Learning para crear flujos ejecutables. Estos flujos ejecutables orquestan el flujo de trabajo desde las solicitudes entrantes a los almacenes de datos para capturar datos de base para los modelos de lenguaje, junto con otra lógica de Python necesaria. El flujo ejecutable se implementa en un clúster de proceso de Machine Learning detrás de un punto de conexión en línea administrado.

El hospedaje de la interfaz de usuario (UI) de chat personalizado sigue las instrucciones de aplicación web de servicios de aplicaciones de línea de base para implementar una aplicación web segura, con redundancia de zona y de alta disponibilidad en Azure App Services. En esa arquitectura, App Service se comunica con la solución de plataforma como servicio (PaaS) de Azure mediante la integración de red virtual a través de puntos de conexión privados. La interfaz de usuario de chat App Service se comunica con el punto de conexión en línea administrado para el flujo a través de un punto de conexión privado. El acceso público al área de trabajo de Machine Learning está deshabilitado.

El área de trabajo de Machine Learning está configurada con aislamiento de red virtual administrada que requiere que se aprueben todas las conexiones salientes. Con esta configuración, se crea una red virtual administrada, junto con puntos de conexión privados administrados que permiten la conectividad a recursos privados, como el área de trabajo de Azure Storage, Azure Container Registry y Azure OpenAI. Estas conexiones privadas se usan durante la creación y las pruebas de flujo, y también se usan en los flujos implementados en el proceso de Machine Learning.

Arquitectura

Descargue un archivo Visio de esta arquitectura.

Componentes

Muchos componentes de esta arquitectura son los mismos que para la arquitectura de chat de un extremo a otro básica de Azure OpenAI. En esta lista solo se resaltan los cambios realizados en la arquitectura básica.

• Azure OpenAI se usa tanto en la arquitectura básica como en esta arquitectura de línea base. Azure OpenAI es un servicio totalmente administrado que proporciona acceso a la API REST a los modelos de lenguaje de Azure OpenAI , incluidos los modelos GPT-4, GPT-3.5-Turbo e Inserciones. La arquitectura de línea base aprovecha las características empresariales, como la la red virtual y el vínculo privado, que la arquitectura básica no implementa.
• Application Gateway es un equilibrador de carga y enrutador de tráfico web de capa 7 (HTTP/S). Utiliza el enrutamiento basado en rutas URL para distribuir el tráfico entrante por zonas de disponibilidad y descarga el cifrado para mejorar el rendimiento de las aplicaciones.
• Web Application Firewall (WAF) es un servicio nativo de la nube que protege las aplicaciones web de vulnerabilidad de seguridad comunes como SQL injection y scripting entre sitios. Web Application Firewall proporciona visibilidad del tráfico hacia y desde su aplicación web, permitiéndole supervisar y proteger su aplicación.
• Azure Key Vault es un servicio que almacena y administra de forma segura secretos, claves de cifrado y certificados. Centraliza la administración de la información confidencial.
• Azure virtual network es un servicio que permite crear redes virtuales privadas aisladas y seguras en Azure. Para una aplicación web en App Service, necesita una subred de red virtual para utilizar puntos de conexión privados para la comunicación segura de red entre recursos.
• Private Link permite a los clientes acceder a los servicios de la plataforma Azure como servicio (PaaS) directamente desde redes virtuales privadas sin utilizar direcciones IP públicas.
• Azure DNS es un servicio de hospedaje de dominios DNS que proporciona resolución de nombres utilizando la infraestructura de Microsoft Azure. Las zonas DNS privadas permiten asignar el nombre de dominio completo (FQDN) de un servicio a la dirección IP de un punto de conexión privado.

Consideraciones y recomendaciones

Confiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.

La arquitectura de la aplicación web de App Service de línea de base se centra en la redundancia zonal para los servicios regionales clave. Las zonas de disponibilidad son ubicaciones físicamente separadas dentro de una región. Proporcionan redundancia dentro de una región para los servicios de soporte cuando se implementan dos o más instancias en ellas. Cuando una zona experimenta tiempo de inactividad, es posible que las otras zonas de la región aún no se vean afectadas. La arquitectura también garantiza suficientes instancias de los servicios de Azure y la configuración de esos servicios que se van a distribuir entre zonas de disponibilidad. Para obtener más información, consulte la línea de base para revisar esa guía.

En esta sección se aborda la fiabilidad desde la perspectiva de los componentes de esta arquitectura que no se tratan en la línea de base de App Service, incluido Machine Learning, Azure OpenAI y AI Search.

Redundancia zonal para implementaciones de flujo

Las implementaciones empresariales suelen requerir redundancia zonal. Para lograr redundancia zonal en Azure, los recursos deben admitir zonas de disponibilidad y debe implementar al menos tres instancias del recurso o habilitar la compatibilidad con la plataforma cuando el control de instancia no esté disponible. Actualmente, el proceso de Machine Learning no ofrece compatibilidad con zonas de disponibilidad. Para mitigar el posible impacto de un desastre en nivel de centro de datos en los componentes de Machine Learning, es necesario establecer clústeres en varias regiones junto con la implementación de un equilibrador de carga para distribuir llamadas entre estos clústeres. Puede usar comprobaciones de estado para asegurarse de que las llamadas solo se enrutan a clústeres que funcionan correctamente.

La implementación de flujos de avisos no se limita a los clústeres de proceso de Machine Learning. El flujo ejecutable, que es una aplicación contenedorizada, se puede implementar en cualquier servicio de Azure compatible con contenedores. Estas opciones incluyen servicios como Azure Kubernetes Service (AKS), Azure Functions, Azure Container Apps App Service. Cada uno de estos servicios admite zonas de disponibilidad. Para lograr redundancia zonal para la ejecución del flujo de avisos, sin la complejidad adicional de una implementación de varias regiones, debe implementar los flujos en uno de esos servicios.

En el diagrama siguiente se muestra una arquitectura alternativa en la que los flujos de avisos se implementan en App Service. App Service se usa en esta arquitectura porque la carga de trabajo ya la usa para la interfaz de usuario de chat y no se beneficiaría de la introducción de una nueva tecnología en la carga de trabajo. Los equipos de carga de trabajo que tienen experiencia con AKS deben considerar la posibilidad de implementar en ese entorno, especialmente si AKS se usa para otros componentes de la carga de trabajo.

El diagrama se numera para áreas destacadas en esta arquitectura:

1. Los flujos se siguen creando en el flujo de avisos de Machine Learning y la arquitectura de red de Machine Learning no cambia. Los autores de flujos siguen conectándose a la experiencia de creación del área de trabajo a través de un punto de conexión privado y los puntos de conexión privados administrados se usan para conectarse a los servicios de Azure al probar flujos.

2. Esta línea de puntos indica que los flujos ejecutables contenedorizados se insertan en Container Registry. En el diagrama no se muestran las canalizaciones que contenedorizan los flujos e insertan en Container Registry.

3. Hay otra aplicación web implementada en el mismo plan de App Service que ya hospeda la interfaz de usuario de chat. La nueva aplicación web hospeda el flujo de avisos contenedorizado, colocado en el mismo plan de App Service que ya se ejecuta como mínimo en tres instancias, distribuidas entre zonas de disponibilidad. Estas instancias de App Service se conectan a Container Registry a través de un punto de conexión privado al cargar la imagen del contenedor de flujo de avisos.

4. El contenedor de flujo de avisos debe conectarse a todos los servicios dependientes para la ejecución del flujo. En esta arquitectura, el contenedor del flujo de avisos se conecta a AI Search y Azure OpenAI. Ahora, los servicios PaaS expuestos solo a la subred del punto de conexión privado administrado de Machine Learning también deben exponerse en la red virtual para que se pueda establecer una línea de visión desde App Service.

Azure OpenAI - Fiabilidad

Actualmente, Azure OpenAI no admite zonas de disponibilidad. Para mitigar el posible impacto de un desastre en nivel de centro de datos en las implementaciones de modelos en Azure OpenAI, es necesario implementar Azure OpenAI en varias regiones junto con la implementación de un equilibrador de carga para distribuir llamadas entre las regiones. Puede usar comprobaciones de estado para asegurarse de que las llamadas solo se enrutan a clústeres que funcionan correctamente.

Para admitir varias instancias de forma eficaz, se recomienda externalizar archivos de ajuste preciso, como una cuenta de almacenamiento con redundancia geográfica. Este enfoque minimiza el estado almacenado en Azure OpenAI para cada región. Todavía debe ajustar los archivos de cada instancia para hospedar la implementación del modelo.

Es importante supervisar el rendimiento necesario en términos de tokens por minuto (TPM) y solicitudes por minuto (RPM). Asegúrese de que se haya asignado suficiente TPM de la cuota para satisfacer la demanda de las implementaciones y evitar que las llamadas a los modelos implementados se limiten. Una puerta de enlace como Azure API Management se puede implementar delante OpenAI Service o servicios y se puede configurar para reintentar en caso de errores transitorios y limitación. API Management también se puede usar como disyuntor para evitar que el servicio se agote con la llamada, superando la cuota.

AI Search - Fiabilidad

Implemente AI Search con el plan de tarifa Estándar o superior en una región que admita zonas de disponibilidad e implemente tres o más réplicas. Las réplicas se distribuyen uniformemente entre zonas de disponibilidad.

Tenga en cuenta las instrucciones siguientes para determinar el número adecuado de réplicas y particiones:

• Supervise AI Search.

• Use métricas de supervisión y registros y análisis de rendimiento para determinar el número adecuado de réplicas para evitar la limitación y las particiones basadas en consultas a fin de evitar la limitación basada en índices.

Machine Learning - Confiabilidad

Si implementa en clústeres de proceso detrás del punto de conexión en línea administrado de Machine Learning, tenga en cuenta las siguientes instrucciones sobre el escalado:

• Siga las instrucciones para Escale automáticamente los puntos de conexión en línea para asegurarse de que hay suficiente capacidad disponible para satisfacer la demanda. Si las señales de uso no son lo suficientemente oportunas debido al uso de ráfagas, considere la posibilidad de sobreaprovisionamiento para evitar un impacto en la fiabilidad de demasiadas instancias disponibles.

• Considere la posibilidad de crear reglas de escalado basadas en métricas de implementación, como la carga de CPU y las métricas de punto de conexión, como la latencia de solicitudes.

• No se deben implementar menos de tres instancias para una implementación de producción activa.

• Evite las implementaciones en las instancias de uso. En su lugar, implemente en una nueva implementación y cambie el tráfico después de que la implementación esté lista para recibir tráfico.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para obtener más información, consulte Lista de comprobación de revisión de diseño para seguridad.

Esta arquitectura amplía la superficie de seguridad implementada en la arquitectura de chat de un extremo a otro básica con Azure OpenAI. Aunque la arquitectura básica usa identidades administradas asignadas por el sistema y asignaciones de roles asignadas por el sistema, esta arquitectura usa identidades asignadas por el usuario con asignaciones de roles creadas manualmente.

La arquitectura implementa un perímetro de seguridad de red, junto con el perímetro de identidad implementado en la arquitectura básica. Desde una perspectiva de red, lo único que debe ser accesible desde Internet es la interfaz de usuario de chat a través de Application Gateway. Desde una perspectiva de identidad, la interfaz de usuario de chat debe autenticar y autorizar solicitudes. Las identidades administradas se usan, siempre que sea posible, para autenticar aplicaciones en los servicios de Azure.

Junto con las consideraciones de red, en esta sección se describen las consideraciones de seguridad para la rotación de claves y el ajuste fino del modelo de Azure OpenAI.

Administración de identidades y acceso

Al usar identidades administradas asignadas por el usuario, tenga en cuenta las instrucciones siguientes:

• Cree identidades administradas independientes para los siguientes recursos de Machine Learning, si procede:
  • Áreas de trabajo para la creación y administración de flujos
  • Instancias de proceso para flujos de prueba
  • Puntos de conexión en línea en el flujo implementado si el flujo se implementa en un punto de conexión en línea administrado
• Implemente controles de acceso a identidades para la interfaz de usuario de chat mediante Microsoft Entra ID

Roles de acceso basado en roles de Machine Learning

Hay cinco roles predeterminados que puede usar para administrar el acceso al área de trabajo de Machine Learning: Científico de datos de AzureML, Operador de proceso de AzureML, Lector, Colaborador y Propietario. Junto con estos roles predeterminados, existe el Lector de secretos de conexión del área de trabajo de Azure Machine Learning y un Usuario del registro de Azure Machine Learning que pueden conceder acceso a los recursos del área de trabajo, como los secretos del área de trabajo y el registro.

Dado que la arquitectura usa identidades administradas asignadas por el usuario, es responsable de crear las asignaciones de roles adecuadas. Esta arquitectura sigue el principio de privilegios mínimos mediante la asignación de roles a las identidades anteriores en las que se requieren. Tenga en cuenta las siguientes asignaciones de roles.

Identidad administrada	Ámbito	Asignaciones de roles
Identidad administrada del área de trabajo	Resource group	Colaborador
Identidad administrada del área de trabajo	Cuenta de almacenamiento del área de trabajo	Colaborador de datos de blobs de almacenamiento
Identidad administrada del área de trabajo	Cuenta de almacenamiento del área de trabajo	Colaborador con privilegios de datos de archivos de Storage
Identidad administrada del área de trabajo	Almacén de claves del área de trabajo	Administrador de Key Vault
Identidad administrada del área de trabajo	Registro de contenedor del área de trabajo	AcrPush
Identidad administrada del punto de conexión en línea	Azure OpenAI	Usuario de OpenAI de Cognitive Services
Identidad administrada del punto de conexión en línea	Registro de contenedor del área de trabajo	AcrPull
Identidad administrada del punto de conexión en línea	Cuenta de almacenamiento del área de trabajo	Lector de datos de blobs de almacenamiento
Identidad administrada del punto de conexión en línea	Área de trabajo de Machine Learning	Lector de secretos de conexión del área de trabajo de AzureML
Identidad administrada de instancia de proceso	Registro de contenedor del área de trabajo	AcrPull
Identidad administrada de instancia de proceso	Cuenta de almacenamiento del área de trabajo	Lector de datos de blobs de almacenamiento

Redes

Junto con el acceso basado en identidades, la seguridad de red se encuentra en el núcleo de la arquitectura de chat de un extremo a otro de línea de base que usa OpenAI. Desde un alto nivel, la arquitectura de red garantiza lo siguiente:

• Un único punto de entrada seguro para el tráfico de la interfaz de usuario de chat.
• El tráfico de red se filtra.
• Los datos en tránsito se cifran de extremo a extremo con seguridad de la capa de transporte (TLS).
• La filtración de datos se minimiza usando Private Link para mantener el tráfico en Azure.
• Los recursos de red se agrupan y aíslan de forma lógica entre sí mediante la segmentación de la red.

Flujos de red

Dos flujos de este diagrama se tratan en la arquitectura de aplicaciones web de App Service de línea de base: el flujo de entrada del usuario final a la interfaz de usuario de chat (1) y el flujo de App Service a los servicios PaaS de Azure (2). Esta sección se centra en el flujo de punto de conexión en línea de Machine Learning. El flujo siguiente va desde la interfaz de usuario de chat que se ejecuta en la aplicación web de App Service de línea de base hasta el flujo implementado en el proceso de Machine Learning:

1. La llamada desde la interfaz de usuario de chat hospedada de App Service se enruta a través de un punto de conexión privado al punto de conexión en línea de Machine Learning.
2. El punto de conexión en línea enruta la llamada a un servidor que ejecuta el flujo implementado. El punto de conexión en línea actúa como equilibrador de carga y como enrutador.
3. Las llamadas a los servicios PaaS de Azure requeridos por el flujo implementado se enrutan a través de puntos de conexión privados administrados.

Entrada a Machine Learning

En esta arquitectura, el acceso público al área de trabajo de Machine Learning está deshabilitado. Los usuarios pueden acceder al área de trabajo a través del acceso privado, ya que la arquitectura sigue la configuración del punto de conexión privado para el área de trabajo de Machine Learning. De hecho, los puntos de conexión privados se utilizan en toda esta arquitectura para complementar la seguridad basada en la identidad. Por ejemplo, la interfaz de usuario de chat hospedada en App Service puede conectarse a servicios PaaS que no están expuestos a Internet público, incluidos los puntos de conexión de Machine Learning.

El acceso al punto de conexión privado también es necesario para conectarse al área de trabajo de Machine Learning para la creación de flujos.

En el diagrama se muestra un autor de flujo de avisos que se conecta a través de Azure Bastion a un jump box de máquina virtual. Desde ese jump box, el autor puede conectarse al área de trabajo de Machine Learning a través de un punto de conexión privado en la misma red que el jump box. La conectividad a la red virtual también podría lograrse a través de ExpressRoute o pasarelas VPN y emparejamiento de red virtual.

Flujo desde la red virtual administrada de Machine Learning a los servicios PaaS de Azure

Se recomienda configurar el área de trabajo de Machine Learning con aislamiento de red virtual administrada que requiere que se aprueben todas las conexiones salientes. Esta arquitectura sigue esa recomendación. Hay dos tipos de reglas de salida aprobadas. Las reglas de salida necesarias son para los recursos necesarios para que la solución funcione, como Container Registry y Storage. Las reglas de salida definidas por el usuario son para recursos personalizados, como Azure OpenAI o AI Search, que el flujo de trabajo va a usar. Debe configurar reglas de salida definidas por el usuario. Las reglas de salida necesarias se configuran cuando se crea la red virtual administrada.

Las reglas de salida pueden ser puntos de conexión privados, etiquetas de servicio o nombres de dominio completo (FQDN) para puntos de conexión públicos externos. En esta arquitectura, la conectividad a los servicios de Azure, como Container Registry, Storage, Azure Key Vault, Azure OpenAI y AI Search, se conectan a través de Private Link. Aunque no está en esta arquitectura, algunas operaciones comunes que podrían requerir la configuración de una regla de salida de FQDN descargan un paquete pip, clonan un repositorio de GitHub o descargan imágenes de contenedor base de repositorios externos.

Segmentación y seguridad de la red virtual

La red de esta arquitectura tiene subredes independientes para las siguientes finalidades:

• Application Gateway
• Componentes de integración de App Service
• Puntos de conexión privados
• Azure Bastion
• Máquina virtual de Jump box
• Entrenamiento - No se usa para el entrenamiento del modelo en esta arquitectura
• Puntuaciones

Cada subred tiene un grupo de seguridad de red (NSG) que limita el tráfico entrante y saliente de esas subredes a lo estrictamente necesario. La siguiente tabla muestra una vista simplificada de las reglas NSG que la línea de base añade a cada subred. La tabla indica el nombre de la regla y su función.

Subnet	Entrada	Salida
snet-appGateway	Las concesiones para las IP de origen de los usuarios de la interfaz de chat (como Internet público), además de los elementos necesarios para el servicio.	Acceso al punto de conexión privado de App Service, además de los elementos necesarios para el servicio.
snet-PrivateEndpoints	Permite solo el tráfico desde la red virtual.	Permite solo el tráfico a la red virtual.
snet-AppService	Permite solo el tráfico desde la red virtual.	Permite el acceso a los puntos de conexión privados y Azure Monitor.
AzureBastionSubnet	Consulte las instrucciones en Trabajo con el acceso a NSG y Azure Bastion.	Consulte las instrucciones en Trabajo con el acceso a NSG y Azure Bastion.
snet-jumpbox	Permite conexiones Remote Desktop Protocol (RDP) y SSH de entrada desde la subred de host de Azure Bastion.	Permite el acceso a los puntos de conexión privados
snet-agents	Permite solo el tráfico desde la red virtual.	Permite solo el tráfico a la red virtual.
snet-training	Permite solo el tráfico desde la red virtual.	Permite solo el tráfico a la red virtual.
snet-scoring	Permite solo el tráfico desde la red virtual.	Permite solo el tráfico a la red virtual.

El resto del tráfico queda bloqueado de forma explícita.

Tenga en cuenta los siguientes puntos al implementar la segmentación y seguridad de la red virtual.

• Habilite DDoS Protection para la red virtual con una subred que forme parte de una Application Gateway con una dirección IP pública.

• Añada una NSG a cada subred siempre que sea posible. Use las reglas más estrictas que permitan la funcionalidad completa de la solución.

• Use grupos de seguridad de aplicaciones para agrupar NSG. La agrupación de NSG facilita la creación de reglas para entornos complejos.

Rotación de claves

Hay dos servicios en esta arquitectura que usan la autenticación basada en claves: Azure OpenAI y el punto de conexión en línea administrado de Machine Learning. Dado que usa la autenticación basada en claves para estos servicios, es importante:

• Almacenar la clave en un almacén seguro, como Key Vault, para el acceso a petición desde clientes autorizados, por ejemplo, la aplicación web de Azure que hospeda el contenedor de flujo de avisos.

• Implementar una estrategia de rotación de claves. Si rota manualmente las claves, cree una directiva de expiración de claves y use Azure Policy para supervisar si se ha rotado la clave.

Ajuste preciso del modelo de OpenAI

Si va a ajustar de forma precisa los modelos de OpenAI en la implementación, tenga en cuenta las instrucciones siguientes:

• Si va a cargar datos de entrenamiento para el ajuste preciso, considere la posibilidad de usar claves administradas por el cliente para cifrar esos datos.

• Si va a almacenar datos de entrenamiento en un almacén como Azure Blob Storage, considere la posibilidad de usar una clave administrada por el cliente para el cifrado de datos, una identidad administrada para controlar el acceso a los datos y un punto de conexión privado para conectarse a los datos.

Gobernanza mediante Policy

Para ayudar a garantizar la alineación con la seguridad, considere la posibilidad de usar Azure Policy y la directiva de red para que las implementaciones se alineen con los requisitos de la carga de trabajo. El uso de la automatización de la plataforma a través de la directiva reduce la carga de los pasos de validación manuales y garantiza la gobernanza incluso si se omiten las canalizaciones. Tenga en cuenta las siguientes directivas de seguridad:

• Deshabilite la clave u otro acceso de autenticación local en servicios como Servicios de Azure AI y Key Vault.
• Exija una configuración específica de reglas de acceso a la red o grupos de seguridad de red.
• Exija cifrado, como el uso de claves administradas por el cliente.

Asignaciones de roles de área de trabajo de Azure Machine Learning para Azure Key Vault

La identidad administrada del área de trabajo de Azure Machine Learning requiere asignaciones de roles del plano de control (colaborador) y del plano de datos (administrador de Key Vault). Esto significa que esta identidad tiene acceso de lectura y escritura a todos los secretos, claves y certificados almacenados en Azure Key Vault. Si la carga de trabajo tiene servicios distintos de Azure Machine Learning que requieren acceso a secretos, claves o certificados en Key Vault, es posible que la carga de trabajo o el equipo de seguridad no se sientan cómodos con la identidad administrada del área de trabajo de Azure Machine Learning que tenga acceso a esos artefactos. En este caso, considere la posibilidad de implementar una instancia de Key Vault específicamente para el área de trabajo de Azure Machine Learning y otras instancias de Azure Key Vault según corresponda para otras partes de la carga de trabajo.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costes.

Si quiere ver un ejemplo de precios para este escenario, use la Calculadora de precios de Azure. Deberá personalizar el ejemplo para que coincida con el uso, ya que en este ejemplo solo se incluyen los componentes incluidos en la arquitectura. Los componentes más caros del escenario son la interfaz de usuario de chat y el proceso de flujo de avisos y AI Search. Optimice esos recursos para ahorrar el mayor coste.

Proceso

El flujo de avisos de Machine Learning admite varias opciones para hospedar los flujos ejecutables. Las opciones incluyen puntos de conexión en línea administrados en Machine Learning, AKS, App Service y Azure Kubernetes Service. Cada una de estas opciones tiene su propio modelo de facturación. La elección del proceso afecta al coste total de la solución.

Azure OpenAI

Azure OpenAI es un servicio basado en el consumo y, al igual que con cualquier servicio basado en el consumo, controlar la demanda contra el suministro es el control de costes principal. Para ello, en Azure OpenAI en concreto, debe emplear una combinación de enfoques:

• Controlar los clientes. Las peticiones de los clientes son la principal fuente de costes en un modelo de consumo, por lo que es fundamental controlar su comportamiento. Todos los clientes deben:

  • Estar aprobados. Evitar exponer el servicio de tal manera que admita el acceso gratuito para todos. Limite el acceso a través de controles de red e identidad, como claves o control de acceso basado en roles (RBAC).

  • Autocontrolarse. Pida a los clientes que utilicen las restricciones de limitación de tokens que ofrecen las llamadas a la API, como max_tokens y max_completions.

  • Usar el procesamiento por lotes, donde sea práctico. Revise a los clientes para asegurarse de que están procesando adecuadamente las solicitudes.

  • Optimizar la longitud de la entrada y la respuesta de la solicitud. Las solicitudes más largas consumen más tokens, lo que aumenta el coste, pero las que carecen de contexto suficiente no ayudan a los modelos a obtener buenos resultados. Cree solicitudes concisas que proporcionen suficiente contexto para que el modelo pueda generar una respuesta útil. Del mismo modo, asegúrese de optimizar el límite de la longitud de la respuesta.

• El uso del área de juegos de Azure OpenAI debe ser el necesario y en las instancias de preproducción, por lo que esas actividades no incurren en costes de producción.

• Seleccione el modelo de IA adecuado. La selección de modelos también desempeña un papel importante en el coste general de Azure OpenAI. Todos los modelos tienen puntos fuertes y débiles y tienen precios por separado. Utilice el modelo correcto para cada caso de uso para garantizar que no se gasta más de la cuenta en un modelo más caro cuando un modelo menos caro ofrece resultados aceptables. En esta implementación de referencia del chat, se optó por GPT 3.5-turbo en lugar de GPT-4 para ahorrar alrededor de un orden de magnitud en los costes de implementación del modelo y, al mismo tiempo, obtener resultados suficientes.

• Comprenda los puntos de interrupción de facturación. El ajuste se cobra por hora. Para ser lo más eficiente posible, querrá utilizar la mayor parte de ese tiempo disponible por hora para mejorar los resultados del ajuste preciso, evitando al mismo tiempo pasar al siguiente periodo de facturación. Asimismo, el coste de 100 imágenes a partir de la generación de imágenes es el mismo que el de una imagen. Aproveche al máximo los puntos de ruptura de precios.

• Comprende los modelos de facturación. Azure OpenAI también está disponible en un modelo de facturación basado en el compromiso a través de la oferta de rendimiento aprovisionado. Una vez que tenga patrones de uso predecibles, evalúe cambiar a este modelo de facturación previa a la compra si es más rentable para su volumen de uso.

• Establezca límites de aprovisionamiento. Asegúrese de que toda la cuota de aprovisionamiento se asigna solo a los modelos que se espera que formen parte de la carga de trabajo, por modelo. El rendimiento de los modelos ya implementados no está limitado a esta cuota aprovisionada mientras la cuota dinámica esté activada. La cuota no se corresponde directamente con los costes y estos pueden variar.

• Supervise el uso de pago por uso. Si usa precios de pago por uso, supervise el uso de TPM y RPM. Utilice esa información para tomar decisiones de diseño arquitectónico, como qué modelos utilizar, y para optimizar el tamaño de las solicitudes.

• Supervise el uso del rendimiento aprovisionado. Si usa el rendimiento aprovisionado, supervise el uso administrado por el aprovisionamiento para asegurarse de que no está infrautilizando el rendimiento aprovisionado que compró.

• Cost Management. Siga las orientaciones sobre el uso de las funciones de gestión de costes con OpenAI para supervisar los costes, establecer presupuestos para gestionarlos y crear alertas para notificar a las partes interesadas los riesgos o anomalías.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para obtener más información, consulte la Lista de comprobación de revisión de diseño para la excelencia operativa.

Aprendizaje automático - Tiempos de ejecución de flujo de avisos integrados

Al igual que en la arquitectura básica, esta arquitectura usa el entorno de ejecución automático para minimizar la carga operativa. El entorno de ejecución automático es una opción de proceso sin servidor dentro de Machine Learning que simplifica la administración de procesos y delega la mayoría de la configuración del flujo de avisos en el archivo requirements.txt y la configuración de flow.dag.yaml de la aplicación en ejecución. Esto hace que esta opción sea de bajo mantenimiento, efímera y controlada por aplicaciones. El uso del entorno de ejecución de la instancia de proceso o proceso externalizado, como en esta arquitectura, requiere un ciclo de vida más administrado por el equipo de la carga de trabajo del proceso y debe seleccionarse cuando los requisitos de carga de trabajo superan las funcionalidades de configuración de la opción de tiempo de ejecución automático.

Supervisión

Al igual que en la arquitectura básica, los diagnósticos se configuran para todos los servicios. Todos los servicios, excepto Machine Learning y App Service, están configurados para capturar todos los registros. El diagnóstico de Machine Learning está configurado para capturar los registros de auditoría, que son todos los registros de recursos que registran las interacciones del usuario con los datos o la configuración del servicio. App Service está configurado para capturar AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs y AppServicePlatformLogs.

Evalúe la creación de alertas personalizadas para los recursos de esta arquitectura, como las que se encuentran en las alertas de línea de base de Azure Monitor. Por ejemplo:

• Alertas de Container Registry
• Alertas de Machine Learning y Azure OpenAI
• Alertas de Azure Web Apps

Operaciones del modelo de lenguaje

La implementación de soluciones de chat basadas en Azure OpenAI como esta arquitectura debe seguir las instrucciones de GenAIOps con el flujo de avisos con Azure DevOps y con GitHub. Además, debe tener en cuenta las mejores prácticas para la integración continua y la entrega continua (CI/CD) y las arquitecturas seguras de red. En las instrucciones siguientes se aborda la implementación de flujos y su infraestructura asociada en función de las recomendaciones de GenAIOps. En esta guía de implementación no se incluyen los elementos de la aplicación front-end, que no se modifican en la arquitectura de aplicación web con redundancia de zona de base de línea de alta disponibilidad.

Desarrollo

El flujo de avisos de Machine Learning ofrece una experiencia de creación basada en explorador en Machine Learning Studio o a través de una extensión de Visual Studio Code. Ambas opciones almacenan el código de flujo como archivos. Al usar Machine Learning Studio, los archivos se almacenan en una cuenta de Storage. Al trabajar en Microsoft Visual Studio Code, los archivos se almacenan en el sistema de archivos local.

Para seguir las prácticas recomendadas para el desarrollo colaborativo, los archivos de código fuente deben mantenerse en un repositorio de código fuente en línea, como GitHub. Este enfoque facilita el seguimiento de todos los cambios de código, la colaboración entre los autores de flujos y la integración con flujos de implementación que prueban y validan todos los cambios de código.

Para el desarrollo empresarial, debería usar la extensión de Microsoft Visual Studio Code y el SDK o la CLI de flujo de avisos para el desarrollo. Los autores del flujo de avisos pueden crear y probar sus flujos desde Microsoft Visual Studio Code e integrar los archivos almacenados localmente con el sistema de control de código fuente en línea y las canalizaciones. Aunque la experiencia basada en el explorador es muy adecuada para el desarrollo exploratorio, con un poco de trabajo puede integrarse con el sistema de control de código fuente. La carpeta de flujo se puede descargar desde la página de flujo del panel Files, descomprimir e insertar en el sistema de control de código fuente.

Evaluación

Pruebe los flujos usados en una aplicación de chat al probar otros artefactos de software. Es difícil especificar y afirmar una única respuesta "correcta" para las salidas del modelo de lenguaje, pero puede utilizar un modelo de lenguaje en sí para evaluar las respuestas. Considere la posibilidad de implementar las siguientes evaluaciones automatizadas de los flujos de modelo de lenguaje:

• Precisión de clasificación: evalúa si el modelo de lenguaje proporciona una puntuación "correcta" o "incorrecta" y agrega los resultados para generar una calificación de precisión.

• Coherencia: evalúa lo bien escritas que están las frases de la respuesta prevista de un modelo y la coherencia con que se conectan entre sí.

• Fluidez: evalúa la respuesta prevista del modelo para su precisión gramatical y lingüística.

• Base con contexto: evalúa en qué medida las respuestas previstas del modelo se basan en el contexto preconfigurado. Incluso si las respuestas del modelo de lenguaje son correctas, si no se pueden validar con el contexto dado, entonces tales respuestas no están fundamentadas.

• Relevancia: evalúa en qué medida las respuestas previstas del modelo se ajustan a la pregunta formulada.

Tenga en cuenta las instrucciones siguientes al implementar evaluaciones automatizadas:

• Genere puntuaciones a partir de evaluaciones y mídalas con respecto a un umbral de éxito predefinido. Utilice estas puntuaciones para informar de los aprobados y suspensos en sus canalizaciones.

• Algunas de estas pruebas requieren entradas de datos preconfiguradas de preguntas, contexto y verdad básica.

• Incluya un número suficiente de pares de pregunta-respuesta para garantizar la fiabilidad de los resultados de las pruebas; se recomienda un mínimo de 100-150 pares. Estos pares de pregunta-respuesta se denominan "conjunto de datos de oro". Dependiendo del tamaño y el ámbito de su conjunto de datos, podría ser necesaria una población mayor.

• Evite el uso de modelos de lenguaje para generar cualquiera de los datos del conjunto de datos de oro.

Flujo de implementación

1. El ingeniero/científico de datos abre una rama de funciones en la que trabaja en la tarea o función específica. El ingeniero/científico de datos itera sobre el flujo utilizando el flujo de avisos para Microsoft Visual Studio Code, confirmando periódicamente los cambios y enviándolos a la rama de características.

2. Una vez finalizado el desarrollo local y la experimentación, el ingeniero/científico de datos abre una solicitud de incorporación de cambios de la rama de características a la rama principal. La solicitud de incorporación de cambios (PR) desencadena una canalización de PR. Esta canalización ejecuta comprobaciones de calidad rápidas que deben incluir:

   • Ejecución de flujos de experimentación
   • Ejecución de pruebas unitarias configuradas
   • Compilación del código base
   • Análisis de código estático

3. La canalización puede contener un paso que requiera al menos un miembro del equipo para aprobar manualmente la solicitud de incorporación de cambios antes de la combinación. El aprobador no puede ser el confirmador y debe tener experiencia en flujos de avisos y estar familiarizado con los requisitos del proyecto. Si no se aprueba la solicitud de incorporación de cambios, la combinación se bloquea. Si se aprueba la solicitud de incorporación de cambios o no hay ningún paso de aprobación, la rama de características se combina en la rama principal.

4. La combinación en la principal desencadena el proceso de compilación y versión para el entorno de desarrollo. Específicamente:

   1. La canalización de CI se desencadena desde la combinación a la principal. La canalización de CI realiza todos los pasos realizados en la canalización de PR y los pasos siguientes:
   • Flujo de experimentación
   • Flujo de evaluación
   • Registra los flujos en el Registro de Machine Learning cuando se detectan cambios.
   1. La canalización de CD se desencadena tras la finalización de la canalización de CI. Este flujo realiza los pasos siguientes:
   • Implementa el flujo desde el Registro de Machine Learning a un punto de conexión en línea de Machine Learning.
   • Ejecuta pruebas de integración que tienen como destino el punto de conexión en línea
   • Ejecuta pruebas de humo que tienen como destino el punto de conexión en línea

5. Un proceso de aprobación está integrado en el proceso de promoción de versiones: tras la aprobación, los procesos de CI y CD descritos en los pasos 4.a. & 4.b. se repiten y tienen como destino el entorno de prueba. Los pasos a. y b. son los mismos, excepto que las pruebas de aceptación del usuario se ejecutan después de las pruebas de humo en el entorno de prueba.

6. Los procesos de CI y CD descritos en los pasos 4.a. y 4.b. se ejecutan para promocionar la versión al entorno de producción después de comprobar y aprobar el entorno de prueba.

7. Después de su lanzamiento en un entorno activo, se realizan las tareas operativas de supervisión de las métricas de rendimiento y la evaluación de los modelos de lenguaje implementados. Entre otras cosas, nos ocupamos de:

   • Detectar desfases de datos
   • Observar la infraestructura
   • Administración de los costos
   • Comunicar el rendimiento del modelo a las partes interesadas

Guía para la implementación

Puede usar puntos de conexión de Machine Learning para implementar modelos de forma que permitan la flexibilidad al lanzarse a producción. Tenga en cuenta las siguientes estrategias para garantizar el mejor rendimiento y calidad del modelo:

• Implementaciones azules o verdes: con esta estrategia, puede implementar de forma segura la nueva versión del servicio web en un grupo limitado de usuarios o solicitudes antes de dirigir todo el tráfico a la nueva implementación.

• Pruebas A/B: no solo son implementaciones azules o verdes eficaces para implementar cambios de forma segura, también se pueden usar para implementar un nuevo comportamiento que permita a un subconjunto de usuarios evaluar el impacto del cambio.

• Incluya linting de archivos de Python que forman parte del flujo de avisos en las canalizaciones. Linting comprueba el cumplimiento de los estándares de estilo, los errores, la complejidad del código, las importaciones sin usar y la nomenclatura de variables.

• Al implementar el flujo en el área de trabajo de Machine Learning aislada de red, use un agente autohospedado para implementar artefactos en los recursos de Azure.

• El registro de modelos de Machine Learning solo debe actualizarse cuando haya cambios en el modelo.

• Los modelos de lenguaje, los flujos y la interfaz de usuario del cliente deben acoplarse de forma flexible. Las actualizaciones de los flujos y de la interfaz de usuario del cliente pueden y deben poder realizarse sin afectar al modelo y viceversa.

• Al desarrollar e implementar varios flujos, cada flujo debe tener su propio ciclo de vida, lo que permite una experiencia de acoplamiento flexible al promocionar flujos de experimentación a producción.

Infraestructura

Al implementar los componentes de chat de un extremo a otro de Azure OpenAI de línea base, algunos de los servicios aprovisionados son fundamentales y permanentes dentro de la arquitectura, mientras que otros componentes son más efímeros por naturaleza y su existencia está ligada a una implementación.

Componentes fundamentales

Algunos componentes de esta arquitectura existen con un ciclo de vida que se extiende más allá de cualquier flujo de avisos individual o cualquier implementación de modelos. Estos recursos suelen implementarse una vez como parte de la implementación fundamental por parte del equipo de carga de trabajo y se mantienen aparte de las implementaciones nuevas, eliminadas o actualizadas de los flujos de avisos o implementaciones de modelos.

• Área de trabajo de Machine Learning
• Cuenta de Storage para el área de trabajo de Machine Learning
• Container Registry
• AI Search
• Azure OpenAI
• Azure Application Insights
• Azure Bastion
• Máquina virtual de Azure para el jump box

Componentes efímeros

Algunos recursos de Azure están más estrechamente acoplados al diseño de flujos de avisos específicos. Este enfoque permite que estos recursos se enlacen al ciclo de vida del componente y se conviertan en efímeros en esta arquitectura. Los recursos de Azure se ven afectados cuando la carga de trabajo evoluciona, como cuando se añaden o eliminan flujos o cuando se introducen nuevos modelos. Estos recursos se vuelven a crear y se quitan las instancias anteriores. Algunos de estos recursos son recursos directos de Azure y algunos son manifestaciones del plano de datos dentro de su servicio contenedor.

• El modelo del registro de modelos de Machine Learning debe actualizarse, si se cambia, como parte de la canalización de CD.

• La imagen de contenedor debe actualizarse en el registro de contenedor como parte de la canalización de CD.

• Se crea un punto de conexión de Machine Learning cuando se implementa un flujo de avisos si la implementación hace referencia a un punto de conexión que no existe. Ese punto de conexión debe actualizarse para desactivar el acceso público.

• Las implementaciones del punto de conexión de Machine Learning se actualizan cuando se implementa o elimina un flujo.

• Key vault para la interfaz de usuario del cliente debe actualizarse con la clave al punto de conexión cuando se crea un nuevo punto de conexión.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad que tiene la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan realizado sobre ella. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.

En esta sección se describe la eficiencia del rendimiento desde la perspectiva de Azure Search, Azure OpenAI y Machine Learning.

Azure Search - Eficiencia del rendimiento

Siga las instrucciones para analizar el rendimiento en AI Search.

Azure OpenAI - Eficiencia del rendimiento

• Determine si la aplicación requiere rendimiento aprovisionado, el modelo de hospedaje compartido o el modelo de consumo. El rendimiento aprovisionado garantiza capacidad de procesamiento reservada para las implementaciones del modelo de OpenAI, lo que proporciona un rendimiento predecible para los modelos. Este modelo de facturación es diferente del modelo de hospedaje compartido o consumo. El modelo de consumo es el mejor esfuerzo y puede estar sujeto a vecinos ruidosos u otros factores estresantes en la plataforma.

• Supervise el uso administrado por el aprovisionamiento para el rendimiento aprovisionado.

Machine Learning - Eficiencia de rendimiento

Si va a implementar en puntos de conexión en línea de Machine Learning:

• Siga las instrucciones sobre cómo escalar automáticamente un punto de conexión en línea. Haga esto para mantenerse estrechamente alineado con la demanda sin exceso de aprovisionamiento, especialmente en períodos de bajo uso.

• Elija la SKU de máquina virtual adecuada para el punto de conexión en línea para satisfacer los objetivos de rendimiento. Pruebe el rendimiento del recuento de instancias inferiores y las SKU más grandes frente al recuento de instancias más grandes y las SKU más pequeñas para encontrar una configuración óptima.

Implementación de este escenario

Para implementar y ejecutar la implementación de referencia, siga los pasos descritos en la implementación de referencia de línea de base de un extremo a otro de OpenAI.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

• Rob Bagby | Patrones y prácticas - Microsoft
• Freddy Ayala | Arquitecto de soluciones en la nube - Microsoft
• Prabal Deb | Ingeniero de software sénior - Microsoft
• Raouf Aliouat | Ingeniero de Software II - Microsoft
• Ritesh Modi | Ingeniero principal de software - Microsoft
• Ryan Pfalz | Arquitecto sénior de soluciones - Microsoft

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Paso siguiente

Recursos relacionados

• Azure OpenAI
• Modelos de lenguaje de Azure OpenAI
• Flujo de avisos de Machine Learning
• Aislamiento de red virtual administrada por el área de trabajo
• Configuración de un punto de conexión privado para un área de trabajo de Machine Learning
• Filtrado de contenido