Arquitectura de referencia de chat de un extremo a otro básica de OpenAI

En este artículo se proporciona una arquitectura básica que le ayudará a aprender a ejecutar aplicaciones de chat que usan modelos de lenguaje del servicio Azure OpenAI. La arquitectura incluye una interfaz de usuario (UI) de cliente que se ejecuta en Azure App Service y usa el flujo de mensajes para orquestar el flujo de trabajo desde las solicitudes entrantes a los almacenes de datos para capturar los datos de base del modelo de lenguaje. El flujo ejecutable se implementa en un punto de conexión en línea administrado que tiene proceso administrado. La arquitectura está diseñada para funcionar desde una sola región.

Arquitectura

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

1. Un usuario emite una solicitud HTTPS al dominio predeterminado de App Service en azurewebsites.net. Este dominio apunta automáticamente a la dirección IP pública integrada de App Service. La conexión seguridad de la capa de transporte se establece desde el cliente directamente a App Service. Azure administra completamente el certificado.
2. La autenticación sencilla, una característica de App Service, ayuda a garantizar que el usuario que accede al sitio se autentique mediante el identificador de Entra de Microsoft.
3. El código de aplicación cliente que se implementa en App Service controla la solicitud y presenta al usuario una interfaz de usuario de chat. El código de la interfaz de usuario de chat se conecta a las API que también se hospedan en esa misma instancia de App Service. El código de API se conecta a un punto de conexión en línea administrado de Azure Machine Learning para controlar las interacciones del usuario.
4. El punto de conexión en línea administrado enruta la solicitud al proceso administrado de Machine Learning donde se implementa la lógica de orquestación del flujo de solicitud.
5. El código de orquestación del flujo de solicitud se ejecuta. Entre otras cosas, la lógica extrae la consulta del usuario de la solicitud.
6. La lógica de orquestación se conecta a Búsqueda de Azure AI para capturar datos de base de la consulta. Los datos de base se agregan a la solicitud que se envía a Azure OpenAI en el paso siguiente.
7. La lógica de orquestación se conecta a Azure OpenAI y envía la solicitud que incluye los datos de base pertinentes.
8. La información sobre la solicitud original a App Service y la llamada al punto de conexión en línea administrado se registran en Application Insights. Este registro usa el mismo área de trabajo registros de Azure Monitor a la que fluye la telemetría de Azure OpenAI.

Flujo de avisos

En el flujo de trabajo anterior se describe el flujo de la aplicación de chat, pero en la lista siguiente se describe un flujo de solicitud típico con más detalle.

1. El usuario escribe un mensaje en una interfaz de usuario de chat personalizada.
2. El código de la API de la interfaz envía ese texto al flujo de avisos.
3. El flujo de aviso extrae la intención del usuario, que es una pregunta o una directiva, del símbolo del sistema.
4. Opcionalmente, el flujo de solicitud determina qué almacenes de datos contienen los datos relevantes para el aviso del usuario.
5. El flujo de avisos consulta los almacenes de datos pertinentes.
6. El flujo de aviso envía la intención, los datos de puesta a tierra pertinentes y cualquier historial que proporcione el mensaje al modelo de lenguaje.
7. El flujo de avisos devuelve el resultado para que se pueda mostrar en la interfaz de usuario.

Puede implementar el orquestador de flujo en cualquier número de idiomas e implementarlo en varios servicios de Azure. Esta arquitectura usa el flujo de mensajes porque proporciona una experiencia simplificada para compilar, probar e implementar flujos que orquestan entre mensajes, almacenes de datos back-end y modelos de lenguaje.

Componentes

Muchos de los componentes de esta arquitectura son los mismos que los recursos de la arquitectura de la aplicación web de App Service básica, ya que la interfaz de usuario de chat se basa en esa arquitectura. En esta sección se resaltan los componentes que puede usar para compilar y organizar flujos de chat, servicios de datos y los servicios que exponen los modelos de lenguaje.

• azure AI Foundry es una plataforma que puede usar para compilar, probar e implementar soluciones de inteligencia artificial. Esta arquitectura usa AI Foundry para compilar, probar e implementar la lógica de orquestación del flujo de mensajes para la aplicación de chat.

  • del centro ai Foundry es el recurso de nivel superior para AI Foundry. Es el lugar central donde puede controlar la seguridad, la conectividad y los recursos de proceso para su uso en los proyectos de AI Foundry. Las conexiones a recursos como Azure OpenAI se definen en el centro de AI Foundry. Los proyectos de AI Foundry heredan estas conexiones.

  • los proyectos de AI Foundry son los entornos que se usan para colaborar mientras desarrolla, implementa y evalúa modelos y soluciones de IA.

• El flujo de avisos es una herramienta de desarrollo que puede usar para crear, evaluar e implementar flujos que vinculan mensajes de usuario, acciones a través del código de Python y llamadas a los modelos de lenguaje. Esta arquitectura usa el flujo de solicitud como la capa que organiza los flujos entre el símbolo del sistema, los distintos almacenes de datos y el modelo de lenguaje. Para el desarrollo, puede hospedar los flujo de avisos en dos tipos de entornos de ejecución.

  • tiempo de ejecución automático es una opción de proceso sin servidor que administra las características de ciclo de vida y rendimiento del proceso. También facilita la personalización controlada por flujos del entorno. Esta arquitectura usa el entorno de ejecución automático para simplificar.

  • tiempo de ejecución de la instancia de proceso es una opción de proceso siempre activa en la que el equipo de cargas de trabajo debe elegir las características de rendimiento. Este tiempo de ejecución proporciona más personalización y control del entorno.

• Machine Learning es un servicio en la nube administrado que puede utilizar para entrenar, implementar y administrar modelos de aprendizaje automático. Esta arquitectura usa puntos de conexión en línea administrados, una característica de Machine Learning que implementa y hospeda flujos ejecutables para aplicaciones de inteligencia artificial con tecnología de modelos de lenguaje. Use puntos de conexión en línea administrados para implementar un flujo para la inferencia en tiempo real. Esta arquitectura las usa como punto de conexión de servicio como punto de conexión de servicio para la interfaz de usuario de chat para invocar los flujos de solicitud que hospeda el entorno de ejecución automático de Machine Learning.

• azure Storage es una solución de almacenamiento que puede usar para conservar los archivos de origen del flujo de solicitud para el desarrollo del flujo de solicitud.

• Azure Container Registry es un servicio de registro administrado que puede usar para compilar, almacenar y administrar imágenes y artefactos de contenedor en un registro privado para todos los tipos de implementaciones de contenedor. Esta arquitectura empaqueta flujos como imágenes de contenedor y las almacena en Container Registry.

• azure OpenAI es un servicio totalmente administrado que proporciona acceso a la API REST a los modelos de lenguaje OpenAI de Azure, incluidos el conjunto de modelos GPT-4, GPT-3.5-Turbo e incrustaciones. Esta arquitectura usa Azure OpenAI y el acceso al modelo para agregar características empresariales comunes, como identidad administrada compatibilidad y filtrado de contenido.

• AI Search es un servicio de búsqueda en la nube que admite búsqueda de texto completo, búsqueda semántica, búsqueda vectorialy búsqueda híbrida. La arquitectura incluye búsqueda de IA porque es un servicio común que se usa en los flujos que admiten aplicaciones de chat. Puede usar AI Search para recuperar e indexar datos relevantes para las consultas de usuario. El flujo de solicitud implementa el patrón de generación aumentada de recuperación de para extraer la consulta adecuada del símbolo del sistema, consultar búsqueda de IA y usar los resultados como datos de base para el modelo de Azure OpenAI.

Consideraciones

Estas consideraciones implementan los pilares de Azure Well-Architected Framework, que es un conjunto de principios rectores que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Esta arquitectura básica no está pensada para implementaciones de producción. La arquitectura favorece la simplicidad y la rentabilidad sobre la funcionalidad para que pueda aprender a crear aplicaciones de chat de un extremo a otro mediante Azure OpenAI. En las secciones siguientes se describen algunas deficiencias de esta arquitectura básica y se describen las recomendaciones y consideraciones.

Confiabilidad

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

Esta arquitectura no está diseñada para implementaciones de producción, por lo que en la lista siguiente se describen algunas de las características de confiabilidad críticas que esta arquitectura omite:

• El plan de App Service está configurado para el nivel Básico, que no tiene compatibilidad con la zona de disponibilidad de Azure. El servicio de aplicaciones deja de estar disponible si hay algún problema con la instancia, el bastidor o el centro de datos que hospeda la instancia. Siga las instrucciones de confiabilidad de para las instancias de App Service a medida que avanza hacia la producción.

• El escalado automático de la interfaz de usuario del cliente no está habilitado en esta arquitectura básica. Para evitar problemas de confiabilidad causados por la falta de recursos de proceso disponibles, debe sobreaprovisionar recursos para ejecutar siempre con suficiente proceso para controlar la capacidad simultánea máxima.

• El proceso de Machine Learning no admite zonas de disponibilidad . El orquestador deja de estar disponible si hay problemas con la instancia, el bastidor o el centro de datos que hospeda la instancia. Para obtener información sobre cómo implementar la lógica de orquestación en la infraestructura que admite zonas de disponibilidad, consulte redundancia zonal para implementaciones de flujo en la arquitectura de línea de base.

• Azure OpenAI no se implementa en una configuración de alta disponibilidad. Para obtener información sobre cómo implementar Azure OpenAI de forma fiable, consulte Azure OpenAI - Confiabilidad en la arquitectura de línea base.

• Ai Search está configurado para el nivel Básico, que no admite zonas de disponibilidad de Azure. Para lograr redundancia zonal, 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.

• El escalado automático no se implementa para el proceso de Machine Learning. Para obtener más información, consulte la guía de confiabilidad en la arquitectura de línea base.

Para más información, consulte arquitectura de referencia de chat de un extremo a otro de Azure OpenAI de línea base.

Seguridad

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

En esta sección se describen algunas de las recomendaciones clave que implementa esta arquitectura. Estas recomendaciones incluyen el filtrado de contenido y la supervisión de abusos, la administración de identidades y acceso y los controles de acceso basados en roles. Dado que esta arquitectura no está diseñada para implementaciones de producción, en esta sección también se describe la seguridad de red. La seguridad de red es una característica de seguridad clave que esta arquitectura no implementa.

Filtrado de contenido y supervisión de abusos

Azure OpenAI 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 en solicitudes de entrada y finalizaciones de salida. Este contenido potencialmente perjudicial incluye odio, sexual, daño personal, violencia, profanidad y jailbreak (contenido diseñado para omitir las restricciones de un modelo de lenguaje). Puede configurar el nivel estricto de lo que desea filtrar del contenido de cada categoría mediante las opciones bajas, medias o altas. Esta arquitectura de referencia adopta un enfoque estricto. Ajuste la configuración según sus requisitos.

Azure OpenAI implementa características de filtrado de contenido y supervisión de abusos. La supervisión de abusos es una operación asincrónica que detecta y mitiga 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 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.

Administración de identidades y acceso

La siguiente guía se expande en la guía de administración de identidades y acceso en la arquitectura de línea de base de App Service. Esta arquitectura usa identidades administradas asignadas por el sistema y crea identidades independientes para los siguientes recursos:

• Centro de ai Foundry
• Proyecto de AI Foundry 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

Si decide usar identidades administradas asignadas por el usuario, debe crear identidades independientes para cada uno de los recursos anteriores.

Los proyectos de AI Foundry deben aislarse entre sí. Aplique condiciones a las asignaciones de roles de proyecto para Blob Storage para permitir que varios proyectos escriban en la misma cuenta de Storage y mantengan los proyectos aislados. Estas condiciones conceden acceso solo a contenedores específicos dentro de la cuenta de almacenamiento. Si usa identidades administradas asignadas por el usuario, debe seguir un enfoque similar para mantener el acceso con privilegios mínimos.

Actualmente, la interfaz de usuario de chat usa claves para conectarse al punto de conexión en línea administrado implementado. Azure Key Vault almacena las claves. Al mover la carga de trabajo a producción, debe usar identidades administradas de Microsoft Entra para autenticar la interfaz de usuario de chat en el punto de conexión en línea administrado.

Roles de acceso basado en roles

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 para admitir todas las características potenciales. Por ejemplo, el sistema crea la asignación de roles Storage File Data Privileged Contributor a la cuenta de almacenamiento de AI Foundry. Si no usa el flujo de avisos, es posible que la carga de trabajo no requiera esta asignación.

En la tabla siguiente se resumen los permisos que el sistema concede automáticamente para las identidades asignadas por el sistema:

Las asignaciones de roles que crea el sistema pueden cumplir los requisitos de seguridad o puede restringirlas aún más. Si desea seguir el principio de privilegios mínimos, debe crear identidades administradas asignadas por el usuario y crear sus propias asignaciones de roles restringidas.

Seguridad de red

Para facilitarle aprender a crear una solución de chat de un extremo a otro, esta arquitectura no implementa la seguridad de red. Esta arquitectura usa la identidad como perímetro y usa construcciones de nube pública. Los servicios como AI Search, Key Vault, Azure OpenAI, el punto de conexión en línea administrado implementado y App Service son accesibles desde Internet. El firewall de Key Vault está configurado para permitir el acceso desde todas las redes. Estas configuraciones agregan área expuesta al vector de ataque de la arquitectura.

Para obtener información sobre cómo incluir la red como perímetro adicional en la arquitectura, consulte la sección de red de de la arquitectura de línea de base.

Optimización de costos

La optimización de costos consiste en examinar 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 costos.

Esta arquitectura básica no representa los costos de una solución lista para producción. La arquitectura tampoco tiene controles para protegerse frente a las saturaciones de costos. En las consideraciones siguientes se describen algunas de las características cruciales que afectan al costo y que esta arquitectura omite:

• En esta arquitectura se supone que hay llamadas limitadas a Azure OpenAI. Por este motivo, se recomienda usar los precios de pago por uso en lugar del rendimiento aprovisionado. Siga las guía de optimización de costos de Azure OpenAI en la arquitectura de línea base a medida que avanza hacia una solución de producción.

• El plan de App Service está configurado para el plan de tarifa Básico en una sola instancia, que no proporciona protección frente a una interrupción de zona de disponibilidad. El arquitectura de App Service de línea base recomienda usar planes Premium con tres o más instancias de trabajo para lograr una alta disponibilidad. Este enfoque afecta a los costos.

• El escalado no está configurado para el proceso administrado del punto de conexión en línea administrado. En el caso de las implementaciones de producción, debe configurar el escalado automático. El arquitectura de chat de un extremo a otro de línea base recomienda implementar en App Service en una configuración con redundancia zonal. Ambos cambios arquitectónicos afectan a los costos al pasar a producción.

• Ai Search está configurado para el plan de tarifa Básico sin réplicas agregadas. Esta topología no puede resistir un error en la zona de disponibilidad de Azure. El arquitectura de chat de un extremo a otro de línea base recomienda implementar la carga de trabajo con el plan de tarifa Estándar o superior e implementar tres o más réplicas. Este enfoque puede afectar a los costos a medida que avanza hacia la producción.

• No hay controles de contención ni gobernanza de costes en esta arquitectura. Asegúrese de protegerse frente a procesos o usos noovernados que podrían incurrir en altos costos para los servicios de pago por uso, como Azure OpenAI.

Excelencia operativa

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

Identidades administradas asignadas por el sistema

Esta arquitectura usa identidades administradas asignadas por el sistema para centros de AI Foundry, proyectos de AI Foundry y para el punto de conexión en línea administrado. El sistema crea y asigna automáticamente identidades a los recursos. El sistema crea automáticamente las asignaciones de roles necesarias para que se ejecute el sistema. No es necesario administrar estas asignaciones.

Entornos de ejecución de flujo de avisos integrados

Para minimizar las cargas operativas, esta arquitectura usa tiempo de ejecución automático. El tiempo 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 solicitud en el archivo requirements.txt de la aplicación en ejecución y la configuración de flow.dag.yaml. El tiempo de ejecución automático es bajo mantenimiento, efímero y controlado por aplicaciones.

Supervisión

Los diagnósticos están configurados 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, AppServiceAppLogsy AppServicePlatformLogs. Durante la fase de poC, es importante comprender qué registros y métricas están disponibles para la captura. Al pasar a producción, quite los orígenes de registro que no agreguen valor y solo creen ruido y costo para el receptor de registro de la carga de trabajo.

También se recomienda recopilar datos de puntos de conexión en línea administrados implementados para proporcionar observabilidad a los flujos implementados. Al elegir recopilar estos datos, los datos de inferencia se registran en Azure Blob Storage. Blob Storage registra tanto la solicitud HTTP como las cargas de respuesta. También puede elegir registrar datos personalizados.

Asegúrese de habilitar la integración de con diagnósticos de Application Insights para el punto de conexión en línea administrado. Las métricas y los registros integrados se envían a Application Insights y puede usar las características de Application Insights para analizar el rendimiento de los puntos de conexión de inferencia.

Operaciones del modelo de lenguaje

Dado que esta arquitectura está optimizada para el aprendizaje y no está pensada para su uso en producción, las instrucciones operativas como GenAIOps están fuera del ámbito. Al pasar a producción, siga las instrucciones de operaciones del modelo de lenguaje en la arquitectura de línea de base.

Desarrollo

El flujo de mensajes proporciona una experiencia de creación basada en explorador en AI Foundry 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 AI Foundry, los archivos se almacenan en archivos de una cuenta de almacenamiento. Al trabajar en VS Code, los archivos se almacenan en el sistema de archivos local.

Dado que esta arquitectura está pensada para aprender, está bien usar la experiencia de creación basada en explorador. Cuando empiece a pasar a producción, siga las instrucciones de desarrollo y control de código fuente en la arquitectura de línea base.

Se recomienda usar la opción de proceso sin servidor al desarrollar y probar los flujos de solicitud en AI Foundry. Esta opción le impide tener que implementar y administrar una instancia de proceso para desarrollo y pruebas. Si necesita un entorno personalizado, puede implementar una instancia de proceso.

Evaluación

Puede realizar una evaluación de la implementación del modelo de Azure OpenAI mediante la experiencia del usuario en AI Foundry. Se recomienda familiarizarse con cómo evaluar las aplicaciones de IA generativas para ayudar a garantizar que el modelo que elija cumpla los requisitos de diseño de la carga de trabajo y el cliente.

Una herramienta de evaluación importante con la que debe familiarizarse durante la fase de desarrollo de la carga de trabajo es el paneles de IA responsable en Machine Learning. Esta herramienta le ayuda a evaluar la equidad, la interpretación del modelo y otras evaluaciones clave de las implementaciones y es útil para ayudar a establecer una línea de base temprana para evitar regresiones futuras.

Implementación

Esta arquitectura básica implementa una sola instancia para el orquestador implementado. Al implementar los cambios, la nueva implementación ocupa el lugar de la implementación existente. Cuando empiece a pasar a producción, lea la flujo de implementación y guía de implementación en la arquitectura de línea base. Esta guía le ayuda a comprender e implementar enfoques de implementación más avanzados, como las implementaciones azul-verde.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para satisfacer las demandas que los usuarios ponen en ella de forma eficaz. Para obtener más información, vea Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.

Dado que esta arquitectura no está diseñada para implementaciones de producción, en esta sección se describen algunas de las características críticas de eficiencia del rendimiento que omite la arquitectura.

Un resultado de la POC debe ser la selección de un producto que se adapte a la carga de trabajo para el servicio de aplicaciones y el proceso de Machine Learning. Debe diseñar la carga de trabajo para satisfacer la demanda de forma eficaz mediante el escalado horizontal. El escalado horizontal permite ajustar el número de instancias de proceso que se implementan en el plan de App Service y en instancias que se implementan detrás del punto de conexión en línea. No diseñe un sistema que dependa de cambiar el producto de proceso para alinearse con la demanda.

• Esta arquitectura usa el modelo de consumo o pago por uso para la mayoría de los componentes. El modelo de consumo es un modelo de mejor esfuerzo y podría estar sujeto a problemas ruidosos vecinos u otros factores de estrés en la plataforma. Determine si la aplicación requiere rendimiento aprovisionado a medida que avanza hacia la producción. El rendimiento aprovisionado ayuda a garantizar que la capacidad de procesamiento está reservada para las implementaciones del modelo de Azure OpenAI. La capacidad reservada proporciona un rendimiento predecible para los modelos.

• El punto de conexión en línea de Machine Learning no tiene implementado el escalado automático, por lo que debe aprovisionar una cantidad de producto e instancia que pueda controlar la carga máxima. Debido a cómo se configura el servicio, no se escala dinámicamente para mantener el suministro de forma eficiente alineado con la demanda. Siga las instrucciones sobre cómo escalado automático de un punto de conexión en línea a medida que avanza hacia la producción.

Recomendaciones de diseño adicionales

Un arquitecto debe diseñar las cargas de trabajo de inteligencia artificial y aprendizaje automático, como esta, que comprende las instrucciones de diseño que se encuentran en las cargas de trabajo de inteligencia artificial de Azure Well-Architected Framework en Azure. A medida que pase de la ideación y la prueba de tecnología al diseño, asegúrese de combinar tanto los detalles de los aprendizajes que tiene de esta arquitectura como las instrucciones generales de carga de trabajo de IA/ML que se encuentran en Well-Architected Framework.

Implementación de este escenario

Hay disponible una implementación para una arquitectura de referencia que implementa estas recomendaciones y consideraciones en GitHub.

Paso siguiente

Recursos relacionados

• Perspectiva de Well-Architected Framework sobre las cargas de trabajo de inteligencia artificial de en Azure
• Modelos de lenguaje de Azure OpenAI
• Flujo de avisos
• Filtrado de contenido