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

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

Arquitectura

Figura 1: Arquitectura de chat de un extremo a otro básica con Azure OpenAI

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 de seguridad de la capa de transporte (TLS) se establece desde el cliente directamente a App Service. Azure administra completamente el certificado.
2. Easy Auth, una característica de Azure App Service, garantiza que el usuario que accede al sitio se autentique con Microsoft Entra ID.
3. El código de aplicación cliente implementado 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 a una instancia de proceso administrada de Azure Machine Learning donde se implementa la lógica de orquestación del flujo de avisos.
5. El código de orquestación del flujo de avisos comienza a ejecutarse. 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, con la misma área de trabajo de Log Analytics a la que fluye la telemetría de Azure OpenAI.

Flujo de avisos

Aunque el flujo de trabajo incluye el flujo de la aplicación de chat, en la lista siguiente se describe un flujo de avisos típico con más detalle.

1. El usuario escribe una solicitud en una interfaz de usuario (IU) 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 avisos extrae de la solicitud la intención del usuario, ya sea una pregunta o una directiva.
4. Opcionalmente, el flujo de avisos determina los almacenes de datos que contienen datos relevantes para la solicitud del usuario.
5. El flujo de avisos consulta los almacenes de datos pertinentes.
6. El flujo de avisos envía la intención, los datos base pertinentes y cualquier historial proporcionado en la solicitud al modelo de lenguaje.
7. El flujo de avisos devuelve el resultado para que se pueda mostrar en la interfaz de usuario.

El orquestador de flujos podría implementarse en cualquier número de idiomas y en varios servicios de Azure. En esta arquitectura se usa el flujo de avisos porque proporciona una experiencia simplificada para crear, probar e implementar flujos que se orquestan entre solicitudes, almacenes de datos de 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. Los componentes resaltados en esta sección se centran en los componentes que se usan para crear y orquestar flujos de chat, servicios de datos y los servicios que exponen los modelos de lenguaje.

• 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.

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

  • Los proyectos de AI Studio son los entornos que se usan para colaborar al desarrollar, implementar y evaluar 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. El flujo de avisos se usa en esta arquitectura como la capa que orquesta los flujos entre la solicitud, los distintos almacenes de datos 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: una opción de proceso sin servidor que administra las características de rendimiento y ciclo de vida del proceso y permite la personalización controlada por flujo del entorno. Esta arquitectura usa el entorno de ejecución automático para simplificar.

  • Tiempo de ejecución de la instancia de proceso: una opción de proceso siempre activa en la que el equipo de la carga de trabajo debe seleccionar las características de rendimiento. Este tiempo de ejecución ofrece 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 una característica de Machine Learning que se usa para implementar y hospedar flujos ejecutables para aplicaciones de inteligencia artificial con tecnología de modelos de lenguaje. Esta característica son los puntos de conexión en línea administrados, que 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 flujos de avisos hospedados por el entorno de ejecución automático de Machine Learning.

• Storage se usa para conservar los archivos de origen del flujo de avisos para el desarrollo del flujo de avisos.

• 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 Container Registry.

• 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. En esta arquitectura, además del acceso al modelo, se usa para agregar características empresariales comunes, como 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. 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. 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.

Recomendaciones y consideraciones

Los componentes enumerados en este vínculo de arquitectura a las guías de servicio de buena arquitectura de arquitectura de Azure, si los hay. En las guías de servicio se detallan recomendaciones y consideraciones para servicios específicos. En esta sección se amplía esa guía resaltando las recomendaciones y consideraciones clave del marco de arquitectura de Azure que se aplican a esta arquitectura. 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 permitirle evaluar y aprender a crear aplicaciones de chat de un extremo a otro con Azure OpenAI. En las secciones siguientes se describen algunas deficiencias de esta arquitectura básica, junto con 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, consulte Lista de comprobación de revisión de diseño para confiabilidad.

Dado que esta arquitectura no está diseñada para implementaciones de producción, a continuación se describen algunas de las características de confiabilidad críticas que se omiten en esta arquitectura:

• El plan de App Service está configurado para el nivel Basic, que no tiene compatibilidad con la zona de disponibilidad de Azure. App Service deja de estar disponible en caso de cualquier problema con la instancia, el bastidor o el centro de datos que hospeda la instancia. A medida que avanza hacia la producción, siga las instrucciones de la sección de confiabilidad de la aplicación web con redundancia de zona de línea base.
• El escalado automático de la interfaz de usuario del cliente no está habilitado en esta arquitectura básica. Para evitar problemas de confiabilidad debido a la falta de recursos de proceso disponibles, debe sobreaprovisionar para ejecutar siempre con suficiente capacidad de proceso para controlar la capacidad simultánea máxima.
• El proceso de Azure Machine Learning no ofrece compatibilidad con zonas de disponibilidad. El orquestador deja de estar disponible en caso de cualquier problema con la instancia, el bastidor o el centro de datos que hospeda la instancia. Consulte la redundancia de zona para implementaciones de flujo en la arquitectura de línea base para obtener información sobre cómo implementar la lógica de orquestación en la infraestructura que admite zonas de disponibilidad.
• 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.
• Búsqueda de Azure AI está configurada para el nivel Basic, que no tiene compatibilidad con la zona de disponibilidad de Azure. Para lograr redundancia de zona, implemente Búsqueda de AI con el plan de tarifa Estándar o superior en una región que admita zonas de disponibilidad y que 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 de Machine Learning en la arquitectura de línea base.

Estos problemas de confiabilidad se abordan en el diseño de la arquitectura de referencia de chat de un extremo a otro de línea base de Azure OpenAI.

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.

En esta sección se tratan algunas de las recomendaciones clave implementadas en 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 se describe una característica de seguridad clave que no se implementó en esta arquitectura, la seguridad de red.

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 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 modelo de lenguaje). 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. Ajuste la configuración según sus requisitos.

Además del filtrado de contenido, Azure OpenAI implementa características de 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 amplía la Guía de administración de identidad y acceso en la línea de base de App Service. Esta arquitectura usa identidades administradas asignadas por el sistema. Se crean identidades independientes para los siguientes recursos:

• Centro de conectividad de IA Studio
• Proyecto 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

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

Los proyectos de Inteligencia artificial de Azure Studio están diseñados para aislarse entre sí. Para permitir que varios proyectos escriban en la misma cuenta de Azure Storage, pero mantener los proyectos aislados, las condiciones se aplican a sus asignaciones de roles para Blob Storage. Estas condiciones conceden acceso solo a determinados contenedores dentro de la cuenta de almacenamiento. Si usa identidades administradas asignadas por el usuario, deberá seguir un enfoque similar para mantener los privilegios mínimos.

Actualmente, la interfaz de usuario de chat usa claves para conectarse al punto de conexión en línea administrado implementado. Las claves se almacenan en Azure Key Vault. Al pasar a producción, debe usar la identidad administrada 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 puede usar, crear asignaciones de roles admiten todas las características potenciales. Por ejemplo, el sistema crea la asignación de roles "Colaborador con privilegios de datos de archivos de almacenamiento" a la cuenta de almacenamiento de Inteligencia artificial de Azure Studio. Si no usa el flujo de avisos, es posible que la carga de trabajo no requiera esta asignación.

A continuación se muestra un resumen de los permisos concedidos automáticamente para las identidades asignadas por el sistema:

Las asignaciones de roles creadas pueden ser válidas para los requisitos de seguridad, o puede que quiera restringirlas. Si desea seguir el principio de privilegios mínimos y restringir las asignaciones de roles solo a lo que es necesario, debe crear identidades administradas asignadas por el usuario y crear las asignaciones de roles restringidas.

Seguridad de red

Para que le resulte más fácil aprender a crear una solución de chat de un extremo a extremo, 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 Búsqueda de Azure AI, Azure Key Vault, Azure OpenAI, el punto de conexión en línea implementado y Azure App Service son accesibles desde Internet. El firewall de Azure 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 redes de la arquitectura de línea base.

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.

Esta arquitectura básica está diseñada para permitirle evaluar y aprender a crear aplicaciones de chat de un extremo a otro con Azure OpenAI. La arquitectura no representa los costes de una solución lista para producción. Además, la arquitectura no dispone de controles para evitar sobrecostes. A continuación se describen algunas de las características críticas que se omiten en esta arquitectura y que afectan al coste:

• En esta arquitectura se supone que hay llamadas limitadas a Azure OpenAI. Por este motivo, se recomienda usar los precios de pago por uso y no el rendimiento aprovisionado. A medida que avanza hacia una solución de producción, siga las instrucciones de optimización de costes de Azure OpenAI en la arquitectura de línea base.

• El plan de App Service está configurado para el plan de tarifas Básico en una sola instancia, que no ofrece protección contra una interrupción de zona de disponibilidad. La 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, lo que afectará al coste.

• El escalado no está configurado para el proceso administrado del punto de conexión en línea administrado. Para las implementaciones de producción, debe configurar el escalado automático. Además, la arquitectura de chat de un extremo a otro de línea base recomienda implementar en Azure App Service en una configuración con redundancia de zona. Ambos cambios de arquitectura afectan al coste al pasar a producción.

• Búsqueda de Azure AI está configurada para el plan de tarifas Básico sin réplicas agregadas. Esta topología no pudo resistir un error en la zona de disponibilidad de Azure. La arquitectura de chat de un extremo a otro de línea base recomienda implementar con el plan de tarifas Estándar o superior e implementar tres o más réplicas, lo que afecta al coste a medida que avanza hacia la producción.

• No hay controles de contención ni gobernanza de costes en esta arquitectura. Asegúrese de evitar procesos o usos no controlados que podrían incurrir en costes elevados para servicios de pago por uso como Azure OpenAI.

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.

Identidades administradas asignadas por el sistema

Esta arquitectura usa identidades administradas asignadas por el sistema para Inteligencia artificial de Azure Studio (Centro de conectividad), proyectos de Inteligencia artificial de Azure Studio y para el punto de conexión en línea administrado. Estas identidades se crean y asignan automáticamente 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, en esta arquitectura se usa el entorno de ejecución automático, 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. El entorno de ejecución automático es de 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, AppServiceAppLogs y AppServicePlatformLogs. Durante la fase de prueba de concepto, es importante comprender qué registros y métricas están disponibles para capturarse. Al pasar a producción, debe eliminar los orígenes de registro que no agregan valor y que agregan ruido y costo al receptor de registro de la carga de trabajo.

Además, 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. Tanto la solicitud HTTP como las cargas de respuesta se registran. También puede elegir registrar datos personalizados.

Asegúrese de habilitar la integración 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 base.

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 archivos de una cuenta de almacenamiento. Al trabajar en Microsoft Visual Studio Code, los archivos se almacenan en el sistema de archivos local.

Dado que esta arquitectura está pensada para el aprendizaje, está bien usar la experiencia de creación basada en explorador. A medida que empiece a avanzar hacia la producción, siga las instrucciones de la arquitectura de línea base en torno a los procedimientos recomendados de desarrollo y control de código fuente.

Se recomienda usar la opción de proceso sin servidor al desarrollar y probar los flujos de avisos en Inteligencia artificial de Azure Studio. Esto 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

Evaluación de cómo se puede realizar la implementación del modelo de Azure OpenAI a través de una experiencia de usuario en Inteligencia artificial de Inteligencia artificial de Azure Studio. Microsoft sugiere familiarizarse con la evaluación de las aplicaciones de IA generativa para asegurarse de que la selección del modelo cumple los requisitos de diseño de cargas de trabajo y usuario.

Una herramienta de evaluación importante con la que familiarizarse en las fases de desarrollo de la carga de trabajo son los paneles de IA responsable en Azure Machine Learning. Esta herramienta le ayudará a evaluar la equidad, la interpretación del modelo y otras evaluaciones clave de las implementaciones y es útil para establecer una línea 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 los documentos sobre flujo de implementación e instrucciones de implementación en la arquitectura de línea base para obtener instrucciones sobre cómo comprender e implementar enfoques de implementación más avanzados, como las implementaciones azules o verdes.

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.

Dado que esta arquitectura no está diseñada para implementaciones de producción, a continuación se describen algunas de las características de eficiencia del rendimiento críticas que se omitieron en esta arquitectura, junto con otras recomendaciones y consideraciones.

Un resultado de la prueba de concepto debe ser la selección de la SKU que estime que es adecuada para la carga de trabajo tanto para la instancia de App Service como para el proceso de Azure 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 las instancias implementadas detrás del punto de conexión en línea. No diseñe el sistema para que dependa de cambiar la SKU de proceso para que se ajuste a 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 el mejor esfuerzo y puede estar sujeto a vecinos ruidosos u otros factores estresantes en la plataforma. A medida que avanza hacia producción, debe determinar si la aplicación requiere rendimiento aprovisionado, lo que garantiza la capacidad de procesamiento 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 Azure Machine Learning no tiene implementado el escalado automático, por lo que tendría que aprovisionar una SKU y una cantidad de instancias que pueda controlar la carga máxima. El servicio, tal y como está configurado, no se escala dinámicamente para mantener la oferta alineada con la demanda. A medida que avanza hacia producción, siga las instrucciones sobre cómo escalar automáticamente un punto de conexión en línea.

Implementación de este escenario

Para implementar y ejecutar la implementación de referencia, siga los pasos descritos en la implementación de referencia básica de un extremo a otro de Azure OpenAI.

Paso siguiente

Recursos relacionados

• Modelos de lenguaje de Azure OpenAI
• Flujo de avisos
• Aislamiento de red virtual administrada por el área de trabajo
• Configuración de un vínculo privado para centros de conectividad de Inteligencia artificial de Azure Studio
• Configuración de un punto de conexión privado para un área de trabajo de Machine Learning
• Filtrado de contenido