Arquitectura de referencia básica de chat de Microsoft Foundry

En este artículo se proporciona una arquitectura básica que le ayudará a aprender a ejecutar aplicaciones de chat mediante Microsoft Foundry y Azure OpenAI en Foundry Models. La arquitectura incluye una interfaz de usuario (UI) de cliente que se ejecuta en Azure App Service. Para obtener datos de fundamentación para el modelo de lenguaje, la interfaz de usuario usa un agente de prompts alojado en Foundry Agent Service para orquestar el flujo de trabajo desde los prompts entrantes hasta los almacenes de datos. La arquitectura se ejecuta en una sola región.

Architecture

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

El siguiente flujo de trabajo corresponde al diagrama anterior:

1. Un usuario de aplicación interactúa con una aplicación web que contiene la funcionalidad de chat. Emiten 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 se establece desde el cliente directamente a App Service. Azure administra completamente el certificado.

2. La característica de App Service denominada Easy Auth garantiza que el usuario que accede al sitio web se autentique a través de Microsoft Entra ID.

3. El código de aplicación implementado en App Service controla la solicitud y representa una interfaz de usuario de chat para el usuario de la aplicación. El código de la interfaz de usuario de chat se conecta a las API hospedadas en la misma instancia de App Service. El código de la API se conecta a un agente de Agent Service mediante Microsoft Agent Framework.

4. El servicio de agente usa sus herramientas configuradas para capturar datos de base para la consulta. En esta arquitectura, esas herramientas incluyen un índice de Búsqueda de Azure AI y una capacidad de búsqueda web para obtener información pública actualizada. Los datos de base se agregan a la solicitud que se envía al modelo en el paso siguiente.

5. El servicio de agente se conecta a un modelo de OpenAI de Azure que se implementa en Foundry y envía el mensaje que incluye los datos de puesta a tierra pertinentes y el contexto de chat.

6. Application Insights registra información sobre la solicitud original a App Service y las interacciones del agente.

Components

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

• Foundry es una plataforma que se usa para compilar, probar, implementar y hospedar agentes que consumen modelos como servicio (MaaS). Esta arquitectura usa Foundry para hospedar un agente y ejecutar la inferencia en un modelo de OpenAI de Azure.

  • Los proyectos foundry son contenedores dentro de un recurso foundry donde se configuran agentes, implementaciones de modelos y conexiones a orígenes de datos. Cada proyecto expone un punto de conexión que las aplicaciones cliente usan para interactuar con los agentes y modelos del proyecto. Esta arquitectura solo tiene un proyecto Foundry dentro del recurso Foundry.

  • El servicio del agente es una funcionalidad hospedada en Foundry. Este servicio se usa para definir y hospedar agentes para controlar las solicitudes de chat. Administra el historial de conversaciones de chat, organiza las llamadas a herramientas, aplica la seguridad del contenido y se integra con sistemas de identidad, redes y observabilidad. En esta arquitectura, el servicio del agente orquesta el flujo que captura los datos de base de AI Search y otras herramientas conectadas, y los pasa junto con la solicitud al modelo implementado.

    Esta arquitectura usa un agente de indicaciones, que se define de forma declarativa. La solicitud del sistema del agente, combinada con los parámetros temperature y top_p, y las conexiones de conocimiento restringidas, define cómo se comporta el agente en todas las solicitudes.

  • Foundry Models le permiten implementar modelos insignia, incluidos los modelos openAI, desde el catálogo de inteligencia artificial de Azure en un entorno hospedado Microsoft. Este enfoque se considera una implementación de MaaS. Esta arquitectura implementa modelos mediante la configuración global estándar con una cuota fija.

• 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. Esta arquitectura incluye la búsqueda de IA porque se usa normalmente en orquestaciones detrás de aplicaciones de chat. La búsqueda de IA se usa para recuperar datos indexados relevantes para las consultas de usuario. AI Search sirve como almacén de conocimiento para el patrón Generación Aumentada por Recuperación. Este patrón extrae una consulta de un mensaje, consulta la búsqueda de IA y usa los resultados como datos de base para un modelo.

Consideraciones

Estas consideraciones implementan los pilares del marco de Azure Well-Architected, que es un conjunto de principios rectores que puede usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Azure Well-Architected Framework.

Esta arquitectura básica no está pensada para producción. Favorece la simplicidad y la rentabilidad sobre la funcionalidad para que pueda aprender a crear aplicaciones de chat de un extremo a otro. En las secciones siguientes se describen las deficiencias y recomendaciones. Estas omisiones son deliberadas para minimizar el tiempo de instalación. No use esta topología en producción; cada omisión aumenta el riesgo.

Reliability

La confiabilidad ayuda a garantizar que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.

En la lista siguiente se describen las características de confiabilidad críticas que esta arquitectura omite:

• Esta arquitectura usa el nivel Básico de App Service, que no tiene compatibilidad con Azure zona de disponibilidad. La instancia deja de estar disponible si hay problemas con la instancia, el bastidor o el centro de datos. A medida que avanza hacia la producción, siga la guía de fiabilidad para las instancias de App Service.

• Esta arquitectura no habilita el escalado automático para la interfaz de usuario del cliente. Para evitar problemas de capacidad, sobreaprovisione los recursos de computación durante el aprendizaje. Implemente la escalabilidad automática antes de producción.

• Esta arquitectura implementa el servicio del agente como una solución totalmente hospedada Microsoft. Microsoft hospeda servicios dependientes (Cosmos DB, Storage, AI Search) en su nombre. La suscripción no muestra estos recursos. No controla usted sus características de fiabilidad. Para obtener instrucciones sobre cómo incorporar sus propias dependencias, consulte la arquitectura de línea de base.

  Nota:

  La instancia de AI Search en la sección de componentes y el diagrama es diferente de la instancia que es una dependencia de Agent Service. La instancia de la sección de componentes almacena los datos de base. La dependencia realiza la fragmentación en tiempo real de los archivos que se cargan dentro de una sesión de chat o como parte de la definición de un agente.

• Para obtener información, use el tipo de implementación del modelo estándar global. Antes de la producción, calcule las necesidades de rendimiento y residencia de datos. Si necesita un rendimiento reservado, elija un tipo de implementación Zona de Datos Aprovisionada o Global Aprovisionado. Utilice la Zona de Datos Aprovisionada para los requisitos de residencia explícitos.

• Esta arquitectura utiliza el nivel básico de búsqueda por IA, que no admite zonas de disponibilidad de Azure. Para la redundancia de zona, use el nivel Estándar o superior en una región habilitada para zonas e implemente tres o más réplicas.

Para obtener más información, consulte Baseline Foundry Arquitectura de referencia de chat.

Security

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

En esta sección se describen 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 el control de acceso basado en rol. Esta arquitectura no está diseñada para implementaciones de producción, por lo que esta sección también incluye consideraciones de 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

Foundry incluye un sistema de barandillas de protección y filtrado de contenido que usa una combinación de modelos de clasificación. Este filtrado detecta y bloquea categorías específicas de contenido potencialmente perjudicial en solicitudes de entrada y finalizaciones de salida. Este contenido potencialmente perjudicial incluye el odio, el contenido sexual, el autolesión, la violencia, la profanidad y el jailbreak (contenido diseñado para omitir las restricciones del modelo de lenguaje). Puede configurar la estricta de filtrado para cada categoría mediante opciones bajas, medias o altas. Esta arquitectura de referencia usa el DefaultV2 filtro de contenido al implementar modelos. Debe ajustar la configuración según sus requisitos.

Administración de identidades y acceso

La siguiente guía amplía la Guía de administración de identidad y acceso en la arquitectura de línea de base de App Service. La interfaz de chat se autentica con Agent Service mediante su identidad administrada. Microsoft Agent Framework utiliza la biblioteca Azure.Identity para autenticarse mediante la identidad administrada asignada a la instancia de App Service.

El proyecto Foundry también tiene una identidad administrada. Esta identidad se autentica en servicios como AI Search a través de definiciones de conexión. El proyecto hace que esas conexiones estén disponibles para el Servicio del Agente.

Un recurso Foundry puede contener varios proyectos de Foundry. Cada proyecto debe usar su propia identidad administrada. Si distintos componentes de carga de trabajo requieren acceso aislado a orígenes de datos conectados, cree proyectos de Foundry independientes dentro del mismo recurso y evite compartir conexiones entre ellos. Si la carga de trabajo no requiere aislamiento, use un solo proyecto.

Roles de acceso basado en roles

Es responsable de crear las asignaciones de roles necesarias para las identidades administradas. En la tabla siguiente se resume la asignación de roles que debe agregar a App Service, el proyecto Foundry y las personas que usan el portal:

Seguridad de red

Para simplificar la experiencia de aprendizaje para crear una solución de chat de un extremo a otro, esta arquitectura no implementa la seguridad de red. Usa la identidad como perímetro y usa construcciones de nube pública. Desde Internet se puede acceder a servicios como Búsqueda de IA, Foundry y App Service. Esta configuración aumenta la superficie expuesta a ataques de la arquitectura.

Esta arquitectura tampoco restringe el tráfico de salida. Por ejemplo, un agente se puede configurar para conectarse a cualquier punto de conexión público en función de la especificación openAPI del punto de conexión. Por lo tanto, no se puede evitar la filtración de datos de base privados a través de controles de red.

Para obtener más información sobre la seguridad de red como perímetro adicional en la arquitectura, consulte Redes en la arquitectura de línea de base.

Si desea cierta seguridad de red durante la evaluación de esta solución, debe usar el soporte perimetral de seguridad de red en su proyecto de Foundry. Este enfoque proporciona control de entrada y salida antes de implementar recursos de red virtual en la arquitectura. Cuando el servicio del agente está configurado para una implementación privada estándar, el perímetro de seguridad de red se reemplaza por conexiones de Private Link.

Microsoft Defender para la nube

Para esta arquitectura básica, no es necesario habilitar Microsoft Defender planes de protección de cargas de trabajo en la nube para ningún servicio. Al pasar a producción, siga las instrucciones de seguridad en la arquitectura de línea base para Microsoft Defender, que usa varios planes para cubrir la carga de trabajo.

Gobernanza mediante políticas

Esta arquitectura no implementa la gobernanza a través de Azure Policy. A medida que avanza hacia la producción, siga las recomendaciones de gobernanza en la arquitectura de línea de base. Esas recomendaciones agregan Azure Policy a los componentes de tu carga de trabajo.

Optimización de costos

La optimización de costos se centra en 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 no representa los costos de una solución lista para producción. Tampoco incluye controles para protegerse frente a saturaciones de costos. En las consideraciones siguientes se describen las características cruciales que esta arquitectura no incluye. Estas características afectan al costo.

• En esta arquitectura se presuponen llamadas de modelo limitadas. Use el tipo de implementación Estándar global (pago por uso) en lugar de rendimiento aprovisionado. A medida que avanza hacia la producción, siga las instrucciones de optimización de costos en la arquitectura de línea de base.

• El servicio del agente incurre en costes para los archivos subidos durante las interacciones por chat. No haga que la funcionalidad de carga de archivos esté disponible para los usuarios de la aplicación si no forma parte de la experiencia de usuario deseada. Las conexiones de conocimientos adicionales, como la herramienta Búsqueda web, tienen sus propias estructuras de precios.

  El servicio del agente es una solución sin código. No puede controlar de forma determinista qué herramientas o orígenes de conocimiento invoca cada solicitud. En el modelado de costos, supongamos el uso máximo de cada conexión.

• Esta arquitectura usa el plan de tarifa básico de App Service en una sola instancia. No proporciona protección frente a una interrupción de zona de disponibilidad. La arquitectura de App Service básica recomienda planes Premium con tres o más instancias de trabajo para lograr una alta disponibilidad.

• Esta arquitectura utiliza el nivel de precios de AI Search Basic sin réplicas adicionales. Esta topología no puede soportar una falla de zona. La arquitectura de chat de extremo a extremo básica recomienda el nivel Estándar o superior y tres o más réplicas.

• Esta arquitectura no incluye controles de contención ni gobernanza de costos. Establezca los presupuestos y alertas de Azure pronto para protegerse contra el uso inesperado de tokens o herramientas.

  Para elaborar el presupuesto, modifique la estimación preconfigurada en la calculadora de precios de Azure de esta arquitectura para adaptarla a su escenario.

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.

Monitorización

Esta arquitectura configura diagnósticos para todos los servicios. App Service captura AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs y AppServicePlatformLogs. Foundry captura RequestResponse. Durante la fase de POC, hacer un inventario de los registros y las métricas disponibles. Antes de producción, quite los orígenes que no agregan valor.

Para usar las funcionalidades de supervisión de Foundry, conecte un recurso de Application Insights al proyecto de Foundry.

Esta integración permite la supervisión de:

• Supervisión en tiempo real del uso de tokens, incluidos el aviso, la finalización y el total de tokens
• Telemetría detallada de solicitud-respuesta, incluida la latencia, las excepciones y la calidad de respuesta

También puede realizar un seguimiento de los agentes mediante OpenTelemetry para diagnósticos distribuidos.

Operaciones de modelo

Esta arquitectura está optimizada para el aprendizaje y no está pensada para producción. Planifique la administración del ciclo de vida y la retirada y puesta en desuso del modelo antes de promover las cargas de trabajo.

Desarrollo

Para la arquitectura básica, puede crear agentes mediante la experiencia basada en explorador en el portal de Foundry. Al pasar a producción, siga la guía de desarrollo y control de código fuente en la arquitectura base. Cuando ya no necesite un agente, asegúrese de eliminarlo. Si el agente que elimina es el último que usa una conexión, quite también la conexión.

Evaluation

Evalúe la aplicación generativa en Foundry. Aprenda a usar evaluadores. Esto ayuda a garantizar que el modelo, la solicitud y la calidad de los datos cumplan los requisitos de diseño.

Eficiencia del rendimiento

La eficiencia del rendimiento hace referencia a la capacidad de escalado de la carga de trabajo para satisfacer las demandas de los usuarios de forma eficaz. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.

Esta arquitectura no está diseñada para implementaciones de producción, por lo que omite las características críticas de eficiencia del rendimiento:

• Utiliza los resultados del POC para elegir el producto adecuado de App Service. Satisfacer la demanda a través del escalado horizontal (ajuste el recuento de instancias). Evite diseños que requieran cambiar el nivel de producto para controlar la demanda rutinaria.

• Esta arquitectura usa componentes de pago por uso. La asignación de recursos de mejor esfuerzo puede introducir efectos ruidosos vecinos. Decida si necesita rendimiento aprovisionado para reservar capacidad y lograr un rendimiento predecible.

Otras recomendaciones de diseño

Los arquitectos deben diseñar cargas de trabajo de inteligencia artificial y aprendizaje automático, como esta, siguiendo las directrices del marco Well-Architected para cargas de trabajo de IA en Azure. Combine los conocimientos de su POC utilizando esta arquitectura junto con las mejores prácticas de inteligencia artificial y aprendizaje automático más amplios cuando avance más allá de la POC.

Implementación de este escenario

Implementación de una implementación de referencia que aplica estas recomendaciones y consideraciones.

Paso siguiente

Recursos relacionados

• Una perspectiva de marco bien diseñado sobre las cargas de trabajo de IA en Azure
• Límites de protección y controles
• Modelos de Azure OpenAI
• ¿Qué es el servicio del agente?