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

Azure OpenAI Service
Azure Machine Learning
Azure App Service
Azure Key Vault
Azure Monitor

Las aplicaciones de chat empresarial tienen la capacidad de capacitar a los empleados a través de la interacción conversacional. Esto es especialmente cierto debido al avance continuo de modelos de lenguaje de gran tamaño, como los modelos GPT de OpenAI y los modelos LLaMA de Meta. Estas aplicaciones de chat constan de una interfaz de usuario para chatear, repositorios de datos que contienen información específica del dominio pertinente a las consultas del usuario, modelos de lenguaje grandes (LLM) 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 grande de Azure OpenAI. La arquitectura emplea el flujo de avisos de Azure Machine Learning (AML) para crear flujos ejecutables que orquesten el flujo de trabajo desde solicitudes entrantes a almacenes de datos para capturar datos de base para los LLM, junto con cualquier otra lógica de Python necesaria. El flujo ejecutable se implementa en un clúster de proceso de Azure 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 los servicios PaaS de Azure mediante la integración de red virtual a través de puntos de conexión privados. Del mismo modo, 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 y el acceso público al área de trabajo de Azure Machine Learning está deshabilitado.

Importante

En el artículo no se tratan los componentes ni las decisiones de arquitectura de la aplicación web de servicios de aplicaciones de línea de base. Lea ese artículo para obtener instrucciones de arquitectura para hospedar la interfaz de usuario de chat.

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 Azure Machine Learning.

Sugerencia

GitHub logo Este artículo está respaldado por una implementación de referencia que muestra una implementación de chat de un extremo a otro de línea de base en Azure. Esta implementación se puede usar como base para el desarrollo de soluciones personalizadas en el primer paso hacia la producción.

Architecture

Diagram that shows a baseline end-to-end chat architecture with OpenAI.

Figura 1: Arquitectura de chat de un extremo a otro de línea de base con OpenAI

Descargue un archivo Visio de esta arquitectura.

Componentes

Muchos de los componentes de esta arquitectura son los mismos que los recursos de la aplicación web de servicios de aplicaciones de línea de base, ya que la interfaz de usuario de chat que se hospeda en esta arquitectura sigue la arquitectura de la aplicación web de App Service de línea de base. Los componentes resaltados en esta sección se centran en los componentes que se usan para crear y orquestar flujos de chat, y los servicios de datos y los servicios que exponen los LLM.

  • Azure Machine Learning es un servicio en la nube administrado que se utiliza para entrenar, implementar y administrar modelos de aprendizaje automático. Esta arquitectura usa otras características de Azure Machine Learning que se usan para desarrollar e implementar flujos ejecutables para aplicaciones de inteligencia artificial con tecnología de modelos de lenguaje grandes:
    • El flujo de avisos de Azure Machine Learning es una herramienta de desarrollo que permite crear, evaluar e implementar flujos que vinculan mensajes de usuario, acciones a través del código de Python y llamadas a los LLM. El flujo de avisos se usa en esta arquitectura como la capa que orquesta los flujos entre la solicitud, los distintos almacenes de datos y los LLM.
    • Los puntos de conexión en línea administrados le permiten implementar un flujo para la inferencia en tiempo real. En esta arquitectura, se usan como punto de conexión de PaaS para la interfaz de usuario de chat para invocar los flujo de avisos hospedados por Azure Machine Learning.
  • Azure Storage se usa para conservar los archivos de origen del flujo de avisos para el desarrollo del flujo de avisos.
  • Azure Container Registry permite crear, almacenar y administrar imágenes y artefactos de contenedor en un registro privado para todo tipo de implementaciones de contenedor. En esta arquitectura, los flujos se empaquetan como imágenes de contenedor y se almacenan en Azure Container Registry.
  • Azure OpenAI es un servicio totalmente administrado que proporciona acceso a la API REST a los modelos de lenguaje grandes de Azure OpenAI , incluidos los modelos GPT-4, GPT-3.5-Turbo e Inserciones. En esta arquitectura, además del acceso al modelo, se usa para agregar características empresariales comunes, como la red virtual y el vínculo privado, la compatibilidad con identidad administrada y el filtrado de contenido.
  • Azure AI Search es un servicio de búsqueda en la nube que admite la búsqueda de texto completo, la búsqueda semántica, la búsqueda vectorial y la búsqueda híbrida. Azure AI Search se incluye en la arquitectura, ya que es un servicio común que se usa en los flujos detrás de las aplicaciones de chat. Azure AI Search se puede usar para recuperar e indexar datos relevantes para las consultas de usuario. El flujo de avisos implementa el patrón RAG Generación aumentada de recuperación para extraer la consulta adecuada de la solicitud, consultar la búsqueda de IA y usar los resultados como datos base para el modelo de Azure OpenAI.

Flujo de avisos de Azure Machine Learning

El back-end para las aplicaciones de chat empresarial suele seguir un patrón similar al siguiente flujo:

  • El usuario escribe una solicitud en una interfaz de usuario (IU) de chat personalizada.
  • La solicitud se envía al back-end mediante el código de interfaz.
  • La intención del usuario (pregunta o directiva) se extrae de la usuario mediante el back-end.
  • (opcional) El back-end determina los almacenes de datos que contienen datos relevantes para la solicitud del usuario.
  • El back-end consulta los almacenes de datos pertinentes.
  • El back-end envía la intención, los datos base pertinentes y cualquier historial proporcionado en la solicitud al LLM.
  • El back-end devuelve el resultado para que se pueda mostrar en la interfaz de usuario.

El back-end podría implementarse en cualquier número de idiomas y en varios servicios de Azure. En esta arquitectura, se eligió el flujo de avisos de Azure Machine Learning porque proporciona una experiencia simplificada para crear, probar e implementar flujos que se orquestan entre solicitudes, almacenes de datos de back-end y LLM.

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 mediante 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 TLS
  • La filtración de datos se minimiza manteniendo el tráfico en Azure mediante Private Link
  • Los recursos de red se agrupan y aíslan lógicamente entre sí mediante la segmentación de la red.

Flujos de red

Diagram that shows a baseline end-to-end chat architecture with OpenAI with flow numbers.

Figura 2: Flujos de red para la arquitectura de chat de un extremo a otro de línea de base con OpenAI

Dos flujos de este diagrama se tratan en la aplicación web de servicios de aplicaciones de línea de base: 1. el flujo de entrada del usuario final a la interfaz de usuario de chat y 2. el App Service al flujo de servicios de Azure PaaS. Consulte ese artículo para obtener más información sobre esos flujos. Esta sección se centra en el flujo de punto de conexión en línea de Azure Machine Learning. A continuación se detalla el flujo 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 Azure 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 Azure 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 Azure Machine Learning

En esta arquitectura, el acceso público al área de trabajo de Azure Machine Learning está deshabilitado y el acceso puede producirse a través del acceso privado, ya que sigue la configuración del punto de conexión privado para el área de trabajo de Azure 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, al permitir que la interfaz de usuario de chat hospedada en App Service se conecte a servicios PaaS no expuestos a la red pública de Internet, incluidos los puntos de conexión de Azure Machine Learning.

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

Diagram that shows a user connecting to an Azure Machine Learning workspace through a jump box to author a flow OpenAI with flow numbers.

Figura 3: Flujos de red para un autor del flujo de avisos de Azure Machine Learning

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 Machine Learning a los servicios PaaS de Azure

Se recomienda configurar el área de trabajo de Azure Machine Learning para el aislamiento de red virtual administrada con una configuración que requiera 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 Azure Container Registry y Azure Storage. Las reglas de salida definidas por el usuario son para recursos personalizados, como Azure OpenAI o Azure AI Search, que el flujo de trabajo va a usar. Es responsabilidad suya configurar reglas de salida definidas por el usuario, mientras que 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 FQDN para puntos de conexión públicos externos. En esta arquitectura, la conectividad a los servicios de Azure, como Azure Container Registry, Azure Storage, Azure Key Vault, Azure OpenAI Service y Azure 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, 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 lo siguiente:

  • 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 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 los usuarios de la interfaz de usuario de chat de origen (como Internet público), además de los elementos necesarios para el servicio Acceso al punto de conexión privado de Azure 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 RDP y SSH de entrada desde la subred de host de 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 Protección contra DDoS para la red virtual con una subred que forme parte de una pasarela de aplicaciones con una IP pública.
  • Añada una NSG a cada subred siempre que sea posible. Debe utilizar las reglas más estrictas que permitan la funcionalidad completa de la solución.
  • Utilice grupos de seguridad de aplicaciones. Los grupos de seguridad de aplicaciones permiten agrupar las NSG, lo que facilita la creación de reglas para entornos complejos.

Filtrado de contenido y supervisión de abusos

Azure OpenAI Service incluye un sistema de filtrado de contenido que usa un conjunto de modelos de clasificación para detectar y evitar categorías específicas de contenido potencialmente perjudicial tanto en solicitudes de entrada como en finalizaciones de salida. Entre las categorías de estos contenidos potencialmente nocivos figuran el odio, el contenido sexual, la autolesión, la violencia, las blasfemias y el jailbreak (contenido diseñado para eludir las restricciones de un LLM). Puede configurar el rigor con el que desea filtrar el contenido para cada categoría, con opciones de bajo, medio o alto. Esta arquitectura de referencia adopta un enfoque estricto. Debe ajustar la configuración según sus requisitos.

Además del filtrado de contenido, Azure OpenAI Service implementa características de supervisión de abusos. La supervisión de abusos es una operación asincrónica diseñada para detectar y mitigar instancias de contenido o comportamientos recurrentes que sugieren el uso del servicio de una manera que puede infringir el código de conducta de Azure OpenAI. Puede solicitar una exención de supervisión de abusos y revisión humana, por ejemplo, si sus datos son muy confidenciales o si hay directivas internas o normativas legales aplicables que impiden el procesamiento de datos para la detección de abusos.

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. 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 Azure Machine Learning, Azure OpenAI y Azure AI Search.

Redundancia zonal para implementaciones de flujo

Las implementaciones empresariales suelen requerir al menos redundancia zonal. Para lograrlo en Azure, los recursos deben admitir zonas de disponibilidad y debe implementar al menos las instancias del recurso o habilitar la compatibilidad con la plataforma cuando el control de instancia no esté disponible. Actualmente, el proceso de Azure 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 AML, 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. Debería 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 Azure 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 (ACA) y Azure 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.

A continuación se muestra una arquitectura alternativa en la que los flujos de avisos se implementan en Azure 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.

Diagram that shows a baseline end-to-end chat architecture with OpenAI with prompt flow deployed to Azure App Service.

Figura 4: Arquitectura alternativa de chat de un extremo a otro con openAI que implementa flujos de avisos en Azure App Services

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

  1. Los flujos se siguen creando en el flujo de avisos de Azure Machine Learning y la arquitectura de red de Azure 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 Azure Container Registry (ACR). En el diagrama no se muestran las canalizaciones que contenedorizan los flujos e insertan en ACR.
  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 ACR 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 sería azure AI Search y Azure OpenAI Service. Ahora, los servicios paaS expuestos solo a la subred del punto de conexión privado administrado de AML 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. Debería 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 Azure Storage con redundancia geográfica. Esto minimizará el estado almacenado en Azure OpenAI Service por región. Para hospedar la implementación del modelo, todavía es necesario realizar el ajuste preciso.

Es importante supervisar el rendimiento necesario en términos de tokens por minuto (TPM) y solicitudes por minuto (RPM) para asegurarse de que ha 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 (APIM) se puede implementar delante OpenAI Service y se puede configurar para reintentar en caso de errores transitorios y limitación. APIM también se puede usar como disyuntor para evitar que el servicio se agote con la llamada, superando la cuota.

Azure AI Search - Fiabilidad

Implemente Azure 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:

  • Siga las instrucciones para supervisar Azure 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 Machine Learning - Fiabilidad

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

  • Siga las instrucciones para escalar 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 el 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.

Nota:

Se aplica la misma guía de escalabilidad de App Service de la arquitectura de línea de base si implementa el flujo en Azure App Service.

Seguridad

Esta arquitectura implementa una red y un perímetro de seguridad de identidad. Desde una perspectiva de red, lo único que debe ser accesible desde Internet es la interfaz de usuario de chat a través de App 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.

La seguridad de red se ha tratado en la sección de redes. En esta sección se describe la administración de identidad y acceso, las consideraciones de seguridad para la rotación de claves y el ajuste preciso del modelo de Azure OpenAI.

Administración de identidades y acceso

La siguiente guía amplía la guía de administración de identidad y acceso en la línea de base de App Service:

  • Cree identidades administradas independientes para los siguientes recursos de AML, si procede:
    • Área de trabajo - Se usa durante la creación y administración de flujos
    • Instancia de proceso - Se usa al probar flujos
    • Punto de conexión en línea - Se usa en el flujo implementado si 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 RBAC de Azure Machine Learning

Hay cinco roles predeterminados que puede usar para administrar el acceso al área de trabajo de Azure 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 AzureML y un Usuario del registro de AzureML que concede acceso a los recursos del área de trabajo, como los secretos del área de trabajo y el registro.

Esta arquitectura sigue el principio de privilegios mínimos mediante la asignación de roles a las identidades anteriores en las que se requieren. A continuación se muestran las 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 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

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 Azure 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 Azure 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 girar manualmente las claves, debe crear una directiva de expiración de claves y usar Azure Policy para supervisar si se ha girado la clave.

Ajuste preciso del modelo openAI

Si va a ajustar de forma precisa los modelos 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, use una identidad administrada para controlar el acceso a los datos y un punto de conexión privado para conectarse a los datos.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para más información, consulte Información general sobre el pilar de eficiencia del rendimiento.

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

Azure Search - Eficiencia del rendimiento

Siga las instrucciones para analizar el rendimiento en Azure AI Search.

Azure OpenAI - Eficiencia del rendimiento

  • Determine si la aplicación requiere rendimiento aprovisionado o usará el modelo de hospedaje compartido (consumo). El rendimiento aprovisionado ofrece 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 (consumo), que es el más indicado y podría estar sujeto a vecino ruidoso u otros factores de estrés en la plataforma.
  • Para el rendimiento aprovisionado, debe supervisar el uso administrado por el aprovisionamiento

Azure Machine Learning - Eficiencia del rendimiento

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

  • Siga las instrucciones sobre cómo escalar automáticamente un punto de conexión en línea 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. Quiere probar 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.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

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 Azure AI Search, así que busque la optimización en torno a esos recursos para ahorrar el mayor coste.

Proceso

El flujo de avisos de Azure Machine Learning admite varias opciones para hospedar los flujos ejecutables. Entre las opciones se incluyen puntos de conexión en línea administrados en Azure Machine Learning, Azure Kubernetes Service, Azure App Service y Azure Container 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 Service, debe emplear específicamente 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. Limitar el acceso a través de controles de red e identidad (clave o 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 incurre en costes de producción.
  • Seleccionar 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. Utilizar el modelo correcto para cada caso de uso puede 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.
  • Conocer los puntos de ruptura de facturación - El ajuste preciso 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 1 imagen. Aproveche al máximo los puntos de ruptura de precios.
  • Conocer 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 calcula que es más rentable para su volumen de uso.
  • Establecer 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. Tenga en cuenta que la cuota no se corresponde directamente con los costes y que estos pueden variar.
  • Supervisar el uso del pago por uso - Si utiliza el pago por uso, supervise el uso de tokens por minuto (TPM) y las solicitudes por minuto (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.
  • Supervisar el uso del rendimiento aprovisionado - Si utiliza el rendimiento aprovisionado, supervise la utilización administrada por el aprovisionamiento para asegurarse de que no está infrautilizando el rendimiento aprovisionado que ha adquirido.
  • Gestión de costes - 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.

Operaciones de modelo de lenguaje grande (LLMOps)

La implementación de soluciones de chat basadas en Azure OpenAI como esta arquitectura debe seguir las instrucciones de LLMOps con el flujo de avisos con Azure DevOps y GitHub. Además, debe tener en cuenta las prácticas recomendadas para arquitecturas protegidas por CI/CD y red. En las instrucciones siguientes se aborda la implementación de flujos y su infraestructura asociada en función de las recomendaciones de LLMOps. 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 Azure Machine Learning ofrece una experiencia de creación basada en explorador en Estudio de Azure Machine Learning o a través de una extensión de VS Code. Ambas opciones almacenan el código de flujo como archivos. Al usar Estudio de Azure Machine Learning, los archivos se almacenan en una cuenta de Azure Storage. Al trabajar en VS 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, debe usar la extensión de VS 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 VS 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

Debe probar 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 de LLM, pero puede utilizar un LLM en sí para evaluar las respuestas. Considere la posibilidad de implementar las siguientes evaluaciones automatizadas de los flujos de LLM:

  • Precisión de clasificación: evalúa si LLM 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 de LLM 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 LLM para generar cualquiera de los datos del conjunto de datos de oro.

Flujo de implementación

Diagram that shows the deployment flow for a prompt flow.

Figura 5: Implementación del flujo de avisos

  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 VS 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:

    a. 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 Azure Machine Learning cuando se detectan cambios.

    b. 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 Azure Machine Learning a un punto de conexión en línea de Azure 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 del LLM implementado. 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 de implementación

Los puntos de conexión de Azure Machine Learning permiten 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 Azure Machine Learning aislada de red, use un agente autohospedado para implementar artefactos en los recursos de Azure.
  • El registro de modelos de Azure Machine Learning solo debe actualizarse cuando haya cambios en el modelo.
  • El LLM, 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 Azure Machine Learning
  • Cuenta de Azure Storage para el área de trabajo de Azure Machine Learning
  • Azure Container Registry
  • Azure 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 vinculados al diseño de flujos de avisos específicos, lo que permite que estos recursos estén vinculados al ciclo de vida del componente y se vuelvan efímeros en esta arquitectura. 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 Azure 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 Azure 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 Azure 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.

Supervisión

Los diagnósticos están configurados para todos los servicios. Todos los servicios, excepto Azure Machine Learning y Azure App Service, están configurados para capturar todos los registros. El diagnóstico de Azure Machine Learning está configurado para capturar los registros de auditoría, que son todos los registros de recursos que registran las interacciones del cliente con los datos o la configuración del servicio. Azure App Service está configurado para capturar AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs y AppServicePlatformLogs.

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.

Pasos siguientes

Más información sobre Azure OpenAI.