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 solicitud 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 punto de conexión en línea administrado con proceso administrado.

El hospedaje de la interfaz de usuario (UI) de chat personalizado sigue las instrucciones de la aplicación web de servicios de aplicaciones de línea base para implementar una aplicación web segura, con redundancia de zona y de alta disponibilidad en App de Azure Service. 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 a Azure AI Studio está deshabilitado.

El centro de Azure AI Studio está configurado 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.

Un centro es el recurso de Azure AI Studio de nivel superior que proporciona una manera central de controlar la seguridad, la conectividad y otros problemas en varios proyectos. Esta arquitectura solo requiere un proyecto para su carga de trabajo. Si tiene experiencias adicionales que requieren flujos de solicitud diferentes con una lógica diferente, posiblemente use diferentes recursos back-end, como almacenes de datos, puede considerar la posibilidad de implementarlos en un proyecto diferente.

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 red virtual y el vínculo privado, que la arquitectura básica no implementa.
• Inteligencia artificial de Azure Studio es una plataforma que puede usar para compilar, probar e implementar soluciones de inteligencia artificial. AI Studio se usa en esta arquitectura para compilar, probar e implementar la lógica de orquestación del flujo de avisos para la aplicación de chat. En esta arquitectura, Azure AI Studio proporciona la red virtual administrada para la seguridad de red. Para obtener más información, consulte la sección redes para obtener más información.
• 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.

Alternativas

Esta arquitectura tiene varios componentes que podrían servir otros servicios de Azure que podrían alinearse mejor con los requisitos funcionales y no funcionales de la carga de trabajo. Estas son algunas alternativas para tener en cuenta.

Áreas de trabajo de Azure Machine Learning (y experiencias del portal)

Esta arquitectura usa Azure AI Studio para compilar, probar e implementar flujos de solicitud. Como alternativa, podría usar áreas de trabajo de Azure Machine Learning, ya que ambos servicios tienen características superpuestas. Aunque AI Studio es una buena opción si está diseñando una solución de flujo de solicitud, hay algunas características para las que Azure Machine Learning tiene actualmente una mejor compatibilidad. Para obtener más información, consulte la comparación de características. Se recomienda que no combine ni coincida con Azure AI Studio y Azure Machine Learning. Si el trabajo se puede realizar completamente en AI Studio, use AI Studio. Si todavía necesita características de Estudio de Azure Machine Learning, siga usando Estudio de Azure Machine Learning.

Componentes de nivel de aplicación

Hay varias ofertas de servicios de aplicaciones administradas disponibles en Azure que pueden servir como nivel de aplicación para el front-end de la interfaz de usuario de chat. Consulte Elección de un servicio de proceso de Azure para todos los procesos y Elección de un servicio de contenedor de Azure para soluciones de contenedor. Por ejemplo, mientras que Azure Web Apps y Web App for Containers se seleccionaron para la API de interfaz de usuario de chat y el host de flujo de mensajes, respectivamente, se podrían lograr resultados similares con Azure Kubernetes Service (AKS) o Azure Container Apps. Elija la plataforma de aplicaciones de la carga de trabajo en función de los requisitos funcionales y no funcionales específicos de la carga de trabajo.

Hospedaje del flujo de mensajes

La implementación de flujos de solicitud no se limita a los clústeres de proceso de Machine Learning y esta arquitectura ilustra que con una alternativa en App de Azure Service. En última instancia, los flujos son una aplicación en contenedores que se puede implementar en cualquier servicio de Azure que sea compatible con los contenedores. Estas opciones incluyen servicios como Azure Kubernetes Service (AKS), Azure Container Apps y App de Azure Service. Elija un servicio de contenedor de Azure en función de los requisitos de la capa de orquestación.

En este artículo se describe un ejemplo de por qué hospedar el flujo de solicitud de hospedaje en un proceso alternativo es una consideración.

Almacén de datos en tierra

Aunque esta arquitectura conduce a Azure AI Search, la elección del almacén de datos para los datos de base es una decisión arquitectónica específica de la carga de trabajo. Muchas cargas de trabajo son de hecho políglotas y tienen orígenes y tecnologías dispares para la puesta en tierra de datos. Estas plataformas de datos van desde almacenes de datos OLTP existentes, bases de datos nativas en la nube como Azure Cosmos DB, a través de soluciones especializadas como Azure AI Search. Una característica común, pero no necesaria, para este almacén de datos es la búsqueda vectorial. Consulte Elección de un servicio de Azure para la búsqueda de vectores para explorar las opciones de este espacio.

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.

Hay algunas alternativas a los clústeres de proceso de Machine Learning, como Azure Kubernetes Service (AKS), Azure Functions, Azure Container Apps y App de Azure 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 solicitud y la arquitectura de red no cambia. Los autores de flujos se siguen conectando a la experiencia de creación en el proyecto de AI Studio 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. El proceso en el que se ejecutan esas canalizaciones debe tener una línea de visión de red a los recursos, como El registro de contenedor de Azure y el proyecto de AI Studio.

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 solicitud en contenedor, 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 del servicio o los servicios de Azure OpenAI y se puede configurar para reintentar si hay 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. Para más información sobre cómo agregar una puerta de enlace para problemas de confiabilidad, consulte Acceso a Azure OpenAI y otros modelos de lenguaje a través de una puerta de enlace.

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.

Azure AI Studio: 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.

Los puntos de conexión en línea administrados actúan como equilibrador de carga y enrutador para el proceso administrado que se ejecuta detrás de ellos. Puede configurar el porcentaje de tráfico que se debe enrutar a cada implementación, siempre que los porcentajes suman hasta el 100 %. También puede implementar un punto de conexión en línea administrado con un tráfico del 0 % que se enruta a cualquier implementación. Si, al igual que en la implementación de referencia proporcionada, usa la infraestructura como código (IaC) para implementar los recursos, incluidos los puntos de conexión en línea administrados, hay un problema de confiabilidad. Si tiene el tráfico configurado para enrutar a las implementaciones (creadas a través de la CLI o Azure AI Studio) y realiza una implementación posterior de IaC que incluye el punto de conexión en línea administrado, aunque no actualice el punto de conexión administrado en línea de ninguna manera, el tráfico del punto de conexión se revierte al enrutamiento del 0 % del tráfico. De hecho, esto significa que los flujos de solicitud implementados ya no serán accesibles hasta que ajuste el tráfico de nuevo a donde lo desee.

Diseño con varias regiones

Esta arquitectura no está creada para ser una marca regional en una arquitectura de varias regiones. Proporciona alta disponibilidad dentro de una sola región debido a su uso completo de zonas de disponibilidad, pero carece de algunos componentes clave para que esto esté realmente listo para una solución de varias regiones. Estos son algunos componentes o consideraciones que faltan en esta arquitectura:

• Entrada global y enrutamiento
• Estrategia de administración de DNS
• Estrategia de replicación de datos (o aislamiento)
• Designación activa-activa, activa-pasiva o activa-fría
• Una estrategia de conmutación por error y conmutación por recuperación para lograr el RTO y el RPO de la carga de trabajo
• Decisiones sobre la disponibilidad de regiones para experiencias de desarrollador en el recurso de Azure Studio Hub

Si los requisitos de la carga de trabajo requieren una estrategia de varias regiones, debe invertir en esfuerzos de diseño adicionales en torno a componentes y procesos operativos sobre lo que se presenta en esta arquitectura. Diseñe para admitir el equilibrio de carga o la conmutación por error en las capas siguientes:

• Datos de base
• Hospedaje de modelos
• Capa de orquestación (flujo de solicitud en esta arquitectura)
• Interfaz de usuario orientada al cliente

Además, necesitará mantener la continuidad empresarial en la observabilidad, las experiencias del portal y los problemas de inteligencia artificial responsables, como la seguridad del contenido.

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 Azure AI Studio y Machine Learning, si procede:
  • Centro de conectividad de IA Studio
  • Proyectos de AI Studio para la creación y administración de flujos
  • 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

Cree proyectos independientes y puntos de conexión en línea para diferentes flujos de solicitud que quiera aislar de otros usuarios desde una perspectiva de permisos. Cree una identidad administrada independiente para cada proyecto y punto de conexión en línea administrado. Proporcione acceso a los autores del flujo de mensajes solo a los proyectos que necesitan.

Al incorporar usuarios a proyectos de Azure AI Studio para realizar funciones como flujos de creación, debe realizar asignaciones de roles con privilegios mínimos los recursos que requieren.

Roles de acceso basado en roles de Machine Learning

Al igual que en la arquitectura básica, el sistema crea automáticamente asignaciones de roles para las identidades administradas asignadas por el sistema. Dado que el sistema no sabe qué características del centro y los proyectos que puede usar, crea asignaciones de roles que admiten todas las características potenciales. Las asignaciones de roles creadas automáticamente pueden sobreaprovisionar privilegios en función del caso de uso. Un ejemplo es el rol "Colaborador" asignado al centro para el registro de contenedor, donde solo es probable que requiera acceso "Lector" al plano de control. Si necesita limitar aún más los permisos para los objetivos de privilegios mínimos, debe usar identidades asignadas por el usuario. Creará y mantendrá estas asignaciones de roles usted mismo.

Debido a la carga de mantenimiento de administrar todas las asignaciones necesarias, esta arquitectura favorece la excelencia operativa sobre las asignaciones de roles con privilegios mínimos absolutos. Tenga en cuenta que tiene que realizar todas las asignaciones enumeradas en la tabla.

Identidad administrada	Ámbito	Asignaciones de roles
Identidad administrada del centro de conectividad	Colaborador	Grupo de recursos
Identidad administrada del centro de conectividad	Hub	Administrador de Azure AI
Identidad administrada del centro de conectividad	Container Registry	Colaborador
Identidad administrada del centro de conectividad	Key Vault	Colaborador
Identidad administrada del centro de conectividad	Key Vault	Administrador
Identidad administrada del centro de conectividad	Cuenta de almacenamiento	Lector
Identidad administrada del centro de conectividad	Cuenta de almacenamiento	Colaborador de la cuenta de almacenamiento
Identidad administrada del centro de conectividad	Cuenta de almacenamiento	Colaborador de datos de blob de almacenamiento
Identidad administrada del centro de conectividad	Cuenta de almacenamiento	Colaborador con privilegios de datos de archivos de Storage
Identidad administrada del centro de conectividad	Cuenta de almacenamiento	Colaborador de datos de tabla de Storage
Identidad administrada del proyecto	Proyecto	Administrador de Azure AI
Identidad administrada del proyecto	Container Registry	Colaborador
Identidad administrada del proyecto	Key Vault	Colaborador
Identidad administrada del proyecto	Key Vault	Administrador
Identidad administrada del proyecto	Cuenta de almacenamiento	Lector
Identidad administrada del proyecto	Cuenta de almacenamiento	Colaborador de la cuenta de almacenamiento
Identidad administrada del proyecto	Cuenta de almacenamiento	Colaborador de datos de blob de almacenamiento
Identidad administrada del proyecto	Cuenta de almacenamiento	Colaborador con privilegios de datos de archivos de Storage
Identidad administrada del proyecto	Cuenta de almacenamiento	Colaborador de datos de tabla de Storage
Identidad administrada del punto de conexión en línea	Proyecto	Secretos de conexión del área de trabajo de Azure Machine Learning
Identidad administrada del punto de conexión en línea	Proyecto	AzureML Metrics Writer
Identidad administrada del punto de conexión en línea	Container Registry	ACRPull
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	Cuenta de almacenamiento	Colaborador de datos de blob de almacenamiento
Identidad administrada del punto de conexión en línea	Cuenta de almacenamiento	Lector de datos de blobs de almacenamiento
App Service (cuando se implementa el flujo de solicitud en App Service)	Azure OpenAI	Usuario de OpenAI de Cognitive Services
Usuario del portal (desarrollo del flujo de solicitud)	Azure OpenAI	Usuario de OpenAI de Cognitive Services
Usuario del portal (desarrollo del flujo de solicitud)	Cuenta de almacenamiento	Colaborador de datos de Storage Blob (uso del acceso condicional)
Usuario del portal (desarrollo del flujo de solicitud)	Cuenta de almacenamiento	Colaborador con privilegios de datos de archivos de Storage

Es importante comprender que el centro de AI Studio tiene recursos de Azure que se comparten entre proyectos, como una cuenta de almacenamiento y container Registry. Si tiene usuarios que solo necesitan acceso a un subconjunto de los proyectos, considere la posibilidad de usar condiciones de asignación de roles, para los servicios de Azure que los admiten, para proporcionar acceso con privilegios mínimos a los recursos. Por ejemplo, los blobs de Azure Storage admiten condiciones de asignación de roles. Para un usuario que requiere acceso a un subconjunto de los proyectos, en lugar de asignar permisos por contenedor, use condiciones de acceso de rol para limitar los permisos a los contenedores de blobs usados por esos proyectos. Cada proyecto tiene un GUID único que actúa como prefijo para los nombres de los contenedores de blobs usados en ese proyecto. Ese GUID se puede usar como parte de las condiciones de asignación de roles.

El centro tiene un requisito para tener Contributor acceso al grupo de recursos del concentrador para permitir que cree y administre los recursos del centro y del proyecto. Efecto secundario de que el centro tiene acceso al plano de control a cualquier recurso también en el grupo de recursos. Los recursos de Azure que no estén directamente relacionados con el centro y sus proyectos se deben crear en un grupo de recursos independiente. Se recomienda crear, como mínimo, dos grupos de recursos para un equipo de carga de trabajo mediante una instancia de Azure AI Studio Hub autoadministrada. Un grupo de recursos que contiene el centro, sus proyectos y todas sus dependencias directas, como el registro de contenedor de Azure, Key Vault, etc. Un grupo de recursos que contendrá todo lo demás en la carga de trabajo.

Se recomienda minimizar el uso de los recursos de Azure necesarios para la operación del centro (Container Registry, Cuenta de almacenamiento, Key Vault, Application Insights) por otros componentes de las cargas de trabajo. Por ejemplo, si necesita almacenar secretos como parte de la carga de trabajo, debe crear un almacén de claves independiente aparte del almacén de claves asociado al centro. El centro de claves solo debe usar el centro para almacenar secretos del centro y del proyecto.

Asegúrese de que para cada proyecto distinto, las asignaciones de roles para sus dependencias no proporcionan acceso a los recursos que el usuario del portal y la identidad administrada del punto de conexión en línea administrado no requieren. Por ejemplo, la Cognitive Services OpenAI User asignación de roles a Azure OpenAI concede acceso a todas las implementaciones de ese recurso. No hay ninguna manera de restringir los autores de flujos ni las identidades administradas de punto de conexión en línea con ese acceso de asignación de roles a implementaciones de modelos específicas en Azure OpenAI. Para escenarios como este, nuestra guía consiste en implementar servicios como Azure OpenAI y Azure AI Search por proyecto y no implementar recursos en esos servicios que fluyen autores o identidades administradas de punto de conexión en línea no deben tener acceso. Por ejemplo, solo implemente modelos en la instancia de Azure OpenAI del proyecto a la que el proyecto requiere acceso. Implemente solo índices en la instancia de Azure AI Search del proyecto a la que el proyecto debe tener acceso.

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 Azure AI Studio a los servicios PaaS de Azure

Se recomienda configurar el centro de Azure AI Studio para el 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. La red virtual administrada se implementa a petición cuando la usa por primera vez y es persistente desde entonces.

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

• Subredes de entrenamiento y puntuación: ambas son para traer su propio proceso relacionado con el entrenamiento y la inferencia. En esta arquitectura, no estamos realizando el entrenamiento y estamos usando el proceso administrado.

• 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 un servicio en esta arquitectura que usa la autenticación basada en claves: el punto de conexión en línea administrado por Machine Learning. Dado que usa la autenticación basada en claves para este servicio, 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 girado 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 Azure AI Studio para Azure Key Vault

La identidad administrada de Azure AI Studio 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 AI Studio 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 cumplan con la identidad administrada del centro de Azure AI Studio que tenga acceso a esos artefactos. En este caso, considere la posibilidad de implementar una instancia de Key Vault específicamente para el centro de Azure AI Studio 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 DDoS Protection y el firewall que se implementa como parte del punto de conexión en línea administrado. Otros costos importantes son la interfaz de usuario de chat y la solicitud de proceso de flujo y búsqueda de IA. Optimice esos recursos para ahorrar el mayor coste.

Proceso

El flujo de mensajes 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.

Entornos 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 App Service, están configurados para capturar todos los registros. App Service está configurado para capturar AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs y AppServicePlatformLogs. En producción, es probable que todos los registros sean excesivos. Ajuste las secuencias de registro a sus necesidades operativas. Para esta arquitectura, los registros de Azure Machine Learning usados por el proyecto de Azure AI Studio que son de interés incluyen: AmlComputeClusterEvent, AmlDataSetEvent, AmlEnvironmentEvent y AmlModelsEvent.

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

Asegúrese de realizar un seguimiento del uso de tokens en las implementaciones del modelo de Azure OpenAI. En esta arquitectura, prompt flow realiza un seguimiento del uso de tokens a través de su integración con App de Azure lication Insights.

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 mensajes ofrece una experiencia de creación basada en explorador en Azure AI Studio o a través de una extensión de Visual Studio Code. Ambas opciones almacenan el código de flujo como archivos. Cuando se usa Azure AI Studio, los archivos se almacenan en una cuenta de Almacenamiento. 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. Además, aunque la red virtual administrada es fundamental, se aprovisiona automáticamente al crear una instancia de proceso que conduce a algunas consideraciones.

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.

Red virtual administrada a petición

La red virtual administrada se aprovisiona automáticamente cuando se crea por primera vez una instancia de proceso. Si usa la infraestructura como código para implementar el centro y no tiene recursos de proceso de AI Studio en Bicep, la red virtual administrada no se implementa y recibirá un error al conectarse a Azure AI Studio. Deberá realizar una acción única para aprovisionar manualmente la red virtual administrada después de la implementación de IaC.

Organización de recursos

Si tiene un escenario en el que el centro es propiedad central de un equipo distinto del equipo de carga de trabajo, puede optar por implementar proyectos en grupos de recursos independientes. Si usa infraestructura como código, puede hacerlo estableciendo un grupo de recursos diferente en Bicep. Si usa el portal, puede establecer la defaultWorkspaceResourceGroup propiedad en el workspaceHubConfig grupo de recursos en el que desea que se creen los proyectos.

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 solicitud en Azure AI Studio
• 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