Compartir a través de

Arquitectura de referencia de chat de Azure AI Foundry de línea base

Azure OpenAI Service
Servicios de Azure AI
Azure App Service
Azure Monitor

Las aplicaciones de chat empresarial pueden capacitar a los empleados a través de interacciones conversacionales con agentes de IA. Esta funcionalidad es cada vez más eficaz gracias a los avances continuos en los modelos de lenguaje, como los modelos GPT y los SDK de orquestación de OpenAI, como kernel semántico. Estas aplicaciones de chat normalmente constan de los siguientes componentes:

  • Interfaz de usuario (UI) de chat integrada en una aplicación empresarial más grande. Proporciona a los usuarios una experiencia conversacional junto con otras funciones empresariales.

  • Repositorios de datos que contienen información específica del dominio pertinente para las consultas de usuario.

  • Modelos de lenguaje que razonan sobre los datos específicos del dominio para generar respuestas pertinentes.

  • Orquestador o agente que supervisa las interacciones entre orígenes de datos, modelos de lenguaje y el usuario final.

En este artículo se proporciona una arquitectura de línea base para ayudarle a crear e implementar aplicaciones de chat empresarial mediante Azure AI Foundry y Azure OpenAI en Foundry Models. Esta arquitectura usa un único agente hospedado en azure AI Foundry Agent Service. El agente recibe mensajes de usuario y, a continuación, consulta los almacenes de datos para recuperar información de base para el modelo de lenguaje.

La interfaz de usuario de chat sigue las instrucciones de aplicación web de Azure App Service de línea base sobre cómo implementar una aplicación web segura, con redundancia de zona y de alta disponibilidad en App Service. En esa arquitectura, App Service se comunica con la solución de plataforma como servicio (PaaS) de Azure a través de la integración de red virtual a través de puntos de conexión privados. En la arquitectura de la interfaz de usuario de chat, App Service se comunica con el agente a través de un punto de conexión privado. El acceso público al portal de Azure AI Foundry y los agentes están deshabilitados.

Importante

En este artículo no se describen los componentes ni las decisiones de arquitectura de la arquitectura de la aplicación web de App Service de línea de base. Lea ese artículo para obtener instrucciones arquitectónicas sobre cómo hospedar la aplicación web que contiene la interfaz de usuario de chat.

Esta arquitectura usa la configuración del agente estándar foundry Agent Service para habilitar la seguridad, el cumplimiento y el control de nivel empresarial. En esta configuración, traiga su propia red para el aislamiento de red y sus propios recursos de Azure para almacenar el estado del chat y del agente. Toda la comunicación entre los componentes de la aplicación y los servicios de Azure se produce a través de puntos de conexión privados, lo que garantiza que el tráfico de datos permanezca dentro de la red virtual de la carga de trabajo. El tráfico saliente de los agentes enruta estrictamente a través de Azure Firewall, que aplica reglas de salida.

Sugerencia

La implementación de referencia del servicio Foundry Agent muestra una implementación de chat de un extremo a otro de línea base en Azure. Sirve como base para desarrollar soluciones personalizadas a medida que avanza hacia la producción.

Arquitectura

Diagrama que muestra una arquitectura de chat completa básica que usa Azure AI Foundry.

Descargue un archivo de Visio de esta arquitectura.

Flujo de trabajo

  1. Un usuario de aplicación interactúa con una interfaz de usuario de chat. Las solicitudes se enrutan a través de Azure Application Gateway. Azure Web Application Firewall inspecciona estas solicitudes antes de reenviarlas al servicio de aplicaciones back-end.

  2. Cuando la aplicación web recibe una consulta o instrucción de usuario, invoca al agente creado específicamente. La aplicación web se comunica con el agente a través del SDK del agente de Azure AI. La aplicación web llama al agente a través de un punto de conexión privado y se autentica en Azure AI Foundry mediante su identidad administrada.

  3. El agente procesa la solicitud del usuario en función de las instrucciones del símbolo del sistema. Para cumplir la intención del usuario, el agente usa un modelo de lenguaje configurado y herramientas conectadas y almacenes de conocimiento.

  4. El agente se conecta al almacén de conocimiento (Azure AI Search) en la red privada a través de un punto de conexión privado.

  5. Las solicitudes a almacenes de conocimiento externos o herramientas, como Wikipedia o Bing, atraviesan Azure Firewall para el cumplimiento de directivas de inspección y salida.

  6. El agente se conecta a su modelo de lenguaje configurado y pasa el contexto pertinente.

  7. Antes de que el agente devuelva la respuesta a la interfaz de usuario, conserva la solicitud, la respuesta generada y una lista de almacenes de conocimiento consultados en una base de datos de memoria dedicada. Esta base de datos mantiene el historial de conversaciones completo, lo que permite interacciones con reconocimiento del contexto y permite a los usuarios reanudar conversaciones con el agente sin perder el contexto anterior.

    Las API de Azure AI Foundry admiten el desarrollo de experiencias de usuario que administran varias conversaciones simultáneas aisladas de contexto.

Componentes

Esta arquitectura se basa en la arquitectura de referencia básica del chat de Azure AI Foundry. Esta arquitectura presenta más servicios de Azure para satisfacer los requisitos empresariales de confiabilidad, seguridad y control operativo. Cada uno de los siguientes componentes desempeña un papel específico en una solución de chat empresarial de producción:

  • Foundry Agent Service proporciona la capa de orquestación para las interacciones de chat. Hospeda y administra agentes que realizan las siguientes tareas:

    • Procesar solicitudes de usuario
    • Coordinar llamadas a herramientas y otros agentes
    • Exigir la seguridad del contenido
    • Integración con la identidad empresarial, las redes y la observabilidad

    La configuración del agente estándar garantiza el aislamiento de red y proporciona control sobre el almacenamiento de datos. Proporciona recursos de Azure dedicados para el estado del agente, el historial de chat y el almacenamiento de archivos, que el servicio Foundry Agent administra exclusivamente. Otros componentes de la aplicación de la carga de trabajo no deben usar estos recursos necesarios.

    • Azure Cosmos DB para NoSQL hospeda la base de datos de memoria de esta carga de trabajo, denominada enterprise_memory, dentro de la suscripción. Esta base de datos almacena el estado operativo del agente, incluidos los subprocesos de chat y las definiciones de agente. Este diseño garantiza que el historial de chat y la configuración del agente estén aislados, auditables y administrados según los requisitos de gobernanza de datos. Foundry Agent Service administra la base de datos, sus colecciones y sus datos.

    • Una cuenta de Azure Storage dedicada almacena los archivos cargados durante las sesiones de chat. Hospedar esta cuenta en la suscripción proporciona un control de acceso granular, funcionalidades de auditoría y cumplimiento de las directivas de residencia o retención de datos. Foundry Agent Service administra los contenedores y el ciclo de vida de datos dentro de esos contenedores.

    • Una instancia dedicada de AI Search almacena un índice fragmentado y buscable de archivos cargados de conversaciones con el agente. También almacena archivos estáticos que se agregan como orígenes de conocimiento cuando se crea el agente. Foundry Agent Service administra el índice, el esquema y los datos, y usa su propia estrategia de fragmentación y lógica de consulta.

  • Application Gateway actúa como punto de entrada seguro y escalable para todo el tráfico HTTP y HTTPS a la interfaz de usuario de chat. Proporciona terminación de la capa de transporte (TLS) y enrutamiento basado en rutas de acceso. También distribuye solicitudes entre zonas de disponibilidad, que admiten alta disponibilidad y rendimiento para el nivel de aplicación web. Su back-end es app Service que hospeda el código de la aplicación.

    • Azure Web Application Firewall se integra con Application Gateway para proteger la interfaz de usuario de chat frente a vulnerabilidades y ataques web comunes. Inspecciona y filtra las solicitudes HTTP, que proporciona una capa de seguridad para las aplicaciones orientadas al público.

    • Azure Key Vault almacena y administra de forma segura los certificados TLS que requiere Application Gateway. La administración centralizada de certificados en Key Vault admite la rotación automatizada, la auditoría y el cumplimiento de los estándares de seguridad de la organización. Esta arquitectura no requiere claves almacenadas ni otros secretos.

  • Azure Virtual Network proporciona aislamiento de red para todos los componentes. Cuando se colocan recursos en una red virtual privada, se controla el tráfico este-oeste y norte-sur, se aplica la segmentación, se mantiene el tráfico privado y se habilita la inspección de flujos de entrada y salida. Esta configuración le ayuda a cumplir los requisitos de seguridad y cumplimiento.

  • Azure Private Link conecta todos los servicios PaaS, como Azure Cosmos DB, Storage, AI Search y Foundry Agent Service, a la red virtual a través de puntos de conexión privados. Este enfoque garantiza que todo el tráfico de datos permanezca en la red troncal de Azure, lo que elimina la exposición a la red pública de Internet y reduce la superficie expuesta a ataques.

  • Azure Firewall inspecciona y controla todo el tráfico saliente (salida) de la red virtual. Aplica reglas basadas en nombres de dominio completos (FQDN), lo que garantiza que solo se pueda acceder a los destinos aprobados. Esta configuración ayuda a evitar la filtración de datos y a cumplir los requisitos de seguridad de red.

  • Azure DNS proporciona zonas privadas del sistema de nombres de dominio (DNS) vinculadas a la red virtual. Esta característica habilita la resolución de nombres para los puntos de conexión privados, lo que garantiza que toda la comunicación entre servicios use direcciones IP privadas y permanezca dentro del límite de red.

  • El almacenamiento hospeda el código de la aplicación web como un archivo ZIP para la implementación en App Service. Este método admite flujos de trabajo de implementación automatizados seguros y separa los artefactos de aplicación de los recursos de proceso.

Alternativas

Esta arquitectura incluye varios componentes que puede sustituir por otros servicios o enfoques de Azure, en función de los requisitos funcionales y no funcionales de la carga de trabajo. Tenga en cuenta las siguientes alternativas y desventajas.

Orquestación de chat

Enfoque actual: Esta arquitectura usa Foundry Agent Service para orquestar flujos de chat, incluida la captura de datos de base de almacenes de conocimiento y la invocación de modelos de Azure OpenAI. Foundry Agent Service proporciona orquestación sin código y no determinista. Controla las solicitudes de chat, la administración de subprocesos, la invocación de herramientas, la seguridad del contenido y la integración con la identidad, las redes y la observabilidad. Proporciona una solución de base de datos de memoria nativa.

Enfoque alternativo: Puede hospedar automáticamente la capa de orquestación mediante marcos como Kernel semántico o LangChain. Use estos marcos para implementar flujos de chat deterministas, controlados por código y lógica de orquestación personalizada.

Considere esta alternativa si la carga de trabajo requiere las siguientes funcionalidades:

  • Control determinista específico sobre la secuencia de orquestación, la invocación de herramientas o la ingeniería de mensajes

  • Integración con sistemas externos o lógica de negocios personalizados que el servicio Foundry Agent no admite de forma nativa

  • Enrutamiento avanzado de solicitudes de cliente para experimentación o prácticas de implementación seguras

  • Una solución de base de datos de memoria personalizada que difiere de la solución de servicio de agente de Foundry nativa

La orquestación autohospedada aumenta la complejidad operativa y requiere que administre el proceso, el escalado y la seguridad.

Componentes de nivel de aplicación

Enfoque actual: El sitio web front-end de la interfaz de usuario de chat se hospeda en la característica Web Apps de App Service, que proporciona una plataforma administrada y escalable para aplicaciones web. Web Apps se integra de forma nativa con las características de seguridad y redes de Azure.

Enfoque alternativo: Puede usar otras plataformas de proceso administradas por Azure, como Azure Container Apps o Azure Kubernetes Service (AKS) para hospedar el nivel de aplicación.

Considere esta alternativa si la carga de trabajo cumple alguna de las condiciones siguientes:

  • Otra plataforma de proceso admite mejor ciertos casos de uso y colocar servicios en esa plataforma puede mejorar la eficiencia de los costos y simplificar las operaciones.

  • La aplicación requiere un escalado, orquestación o redes personalizadas más sofisticadas.

App Service sigue siendo la opción preferida por su simplicidad en el hospedaje de aplicaciones web y sus API.

Almacén de datos en tierra (conocimiento)

Enfoque actual: Esta arquitectura usa AI Search como almacén de datos principal para obtener conocimientos básicos. Usa funcionalidades de búsqueda de vectores de búsqueda de IA y clasificación semántica.

Enfoque alternativo: Puede usar otras plataformas de datos para el conocimiento basado, como Azure Cosmos DB, Azure SQL Database u otros almacenes de datos de procesamiento de transacciones en línea (OLTP). La plataforma de datos depende del patrimonio de datos existente, de los requisitos de actualización de datos y de los requisitos de consulta.

Considere esta alternativa si la carga de trabajo cumple alguna de las condiciones siguientes:

  • Ya administra sus conocimientos básicos en una base de datos transaccional o operativa existente.

  • Necesita compatibilidad con varios modelos o SDK que no está disponible en AI Search.

  • Debe integrarse con orígenes de datos especializados o sistemas heredados.

La búsqueda vectorial es común para la generación aumentada de recuperación, pero no siempre es necesaria. Para obtener más información, consulte Elegir un servicio de Azure para vectores de búsqueda. Antes de elegir un almacén de datos, evalúe los patrones de acceso a datos, la latencia y las necesidades de escalabilidad de la carga de trabajo.

Agente predefinido o agente creado dinámicamente

Enfoque actual: La implementación de referencia usa un agente definido estáticamente que se implementa como un microservicio dentro de Azure AI Foundry. La lógica y los orígenes de datos del agente se configuran en la implementación y permanecen sin cambios hasta la próxima versión de la aplicación. Este enfoque funciona bien cuando el comportamiento del agente y los orígenes de datos son estables y controlados a través de procesos de DevOps.

Enfoque alternativo: Puede crear o modificar dinámicamente agentes en tiempo de ejecución mediante el SDK del agente de Azure AI. Este enfoque permite a la aplicación crear instancias de agentes a petición, ajustar las solicitudes del sistema o volver a configurar las conexiones en función del contexto del usuario o la lógica de negocios.

Tenga en cuenta los agentes dinámicos si la carga de trabajo requiere las siguientes funcionalidades:

  • Comportamiento personalizado del agente o orígenes de datos para cada usuario o sesión

  • Cambios frecuentes o mediante programación en la configuración del agente

  • Compatibilidad con agentes efímeros y específicos del contexto para experiencias avanzadas del usuario

La administración dinámica de agentes aumenta la flexibilidad, pero también introduce la carga de la administración del ciclo de vida. Asegúrese de que tiene los controles adecuados para la creación, modificación y limpieza del agente.

Elija el enfoque del agente que se alinee con los requisitos de experiencia del usuario de la carga de trabajo.

Consideraciones

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

Aplique esta arquitectura y las cargas de trabajo de IA en la guía de diseño de Azure durante la fase de diseño de la carga de trabajo.

Fiabilidad

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.

La arquitectura de aplicaciones web de App Service de línea base se centra en la redundancia zonal para los servicios regionales clave. Las zonas de disponibilidad son ubicaciones físicamente independientes dentro de una región que proporcionan redundancia al implementar dos o más instancias en ellas. Si una zona experimenta tiempo de inactividad, otras personas de la región podrían no verse afectadas. La arquitectura también distribuye instancias y configuraciones de servicios de Azure entre zonas de disponibilidad. Para obtener más información, consulte aplicación web con redundancia de zona de alta disponibilidad de línea base.

En esta sección se aborda la confiabilidad de los componentes que no se tratan en la arquitectura de línea de base de App Service, específicamente Azure AI Foundry y AI Search.

Redundancia de zona en la capa de orquestación

Las implementaciones empresariales suelen requerir redundancia zonal para minimizar el riesgo de interrupción del servicio de errores de nivel de zona. En Azure, la redundancia zonal significa usar recursos que admiten zonas de disponibilidad e implementar al menos tres instancias, o habilitar la redundancia de nivel de plataforma donde el control de instancia directa no está disponible.

En esta arquitectura, Azure AI Foundry hospeda la funcionalidad del servicio Foundry Agent. La confiabilidad del agente depende de la disponibilidad de las dependencias del servicio Foundry Agent, que son Azure Cosmos DB, Storage y AI Search. Foundry Agent Service administra los datos de estos servicios, pero configura su confiabilidad en su suscripción.

Para lograr redundancia zonal para la capa de orquestación, siga estas recomendaciones:

Si el agente se integra con otras dependencias específicas de la carga de trabajo, como conexiones de herramientas personalizadas o almacenes de conocimiento externos, asegúrese de que esas dependencias cumplan los requisitos de disponibilidad y redundancia. Cualquier dependencia de una sola zona o no redundante puede perjudicar la confiabilidad general de la capa de orquestación.

El portal de AI Foundry, sus API de plano de datos y la funcionalidad del servicio Foundry Agent no proporcionan controles directos para la redundancia de zona.

Confiabilidad en el hospedaje de modelos de Azure AI Foundry

Azure AI Foundry proporciona modelos como servicio (MaaS) que hospedan varias opciones de implementación. Estas opciones admiten principalmente la administración de cuotas y rendimiento, en lugar de la alta disponibilidad tradicional dentro de una región. Las implementaciones de modelos estándar funcionan en una sola región y no admiten zonas de disponibilidad. Para lograr la disponibilidad de varios centros de datos, debe usar una implementación de modelo global o de zona de datos.

En escenarios de chat empresarial, implemente un modelo estándar de zona de datos aprovisionado y de zona de datos . Configure el desbordamiento para controlar el exceso de tráfico o errores. Si la carga de trabajo no requiere baja latencia o una residencia y procesamiento de datos geográficos estrictos, use implementaciones globales para lograr la máxima resistencia.

Azure AI Foundry no admite mecanismos avanzados de equilibrio de carga o conmutación por error, como el enrutamiento round robin o la interrupción del circuito, para las implementaciones de modelos. Si necesita redundancia granular y control de conmutación por error dentro de una región, hospede la lógica de acceso del modelo fuera del servicio administrado. Por ejemplo, puede crear una puerta de enlace personalizada mediante Azure API Management. Este enfoque le permite implementar estrategias personalizadas de enrutamiento, comprobaciones de estado y conmutación por error. Pero también aumenta la complejidad operativa y cambia la responsabilidad de la confiabilidad de ese componente al equipo.

También puede exponer modelos front-fronted de puerta de enlace como herramientas personalizadas basadas en API o almacenes de conocimiento para el agente. Para obtener más información, consulte Uso de una puerta de enlace frene a varias implementaciones o instancias de Azure OpenAI.

Confiabilidad en la búsqueda de inteligencia artificial para conocimientos empresariales

Implemente AI Search mediante el plan de tarifa Estándar o superior en una región que admita zonas de disponibilidad. Configure al menos tres réplicas para asegurarse de que el servicio distribuye instancias entre zonas de disponibilidad independientes. Esta configuración proporciona resistencia a errores de nivel de zona y admite alta disponibilidad para las operaciones de búsqueda.

Para determinar el número óptimo de réplicas y particiones para la carga de trabajo, use los métodos siguientes:

  • Supervise la búsqueda de IA mediante métricas y registros integrados. Realice un seguimiento de la latencia de consulta, la limitación y el uso de recursos.

  • Use métricas y registros de supervisión y análisis de rendimiento para determinar el número adecuado de réplicas. Este enfoque le ayuda a evitar la limitación del volumen de consultas elevado, las particiones insuficientes o las limitaciones de índice.

  • Asegúrese de la confiabilidad de la indexación evitando interrupciones de errores periódicos de indexación o indexación. Considere la posibilidad de indexar en un índice sin conexión y cambiar del índice activo al índice recompilado después de validar la integridad de los datos.

Confiabilidad en Azure Firewall

Azure Firewall es un punto de control de salida crítico en esta arquitectura, pero representa un único punto de error para todo el tráfico saliente. Para mitigar este riesgo, implemente Azure Firewall en todas las zonas de disponibilidad de su región. Esta configuración ayuda a mantener la conectividad saliente si una zona deja de estar disponible.

Si la carga de trabajo requiere un gran volumen de conexiones salientes simultáneas, configure Azure Firewall con varias direcciones IP públicas. Este enfoque distribuye las conexiones de traducción de direcciones de red de origen (SNAT) entre varios prefijos de dirección IP, lo que reduce el riesgo de agotamiento de puertos SNAT. El agotamiento de SNAT puede provocar una pérdida intermitente o total de conectividad saliente para agentes y otros componentes de carga de trabajo, lo que puede provocar tiempo de inactividad de características o un rendimiento degradado.

Supervise el uso del puerto SNAT y el estado del firewall. Si observa errores de conexión o problemas de rendimiento, revise las métricas y los registros del firewall para identificar y solucionar el agotamiento de SNAT u otros cuellos de botella.

Aislar las dependencias del servicio del agente de Foundry de componentes de carga de trabajo similares

Para maximizar la confiabilidad y minimizar el radio de explosión de errores, aísle estrictamente las dependencias del servicio foundry Agent de otros componentes de carga de trabajo que usan los mismos servicios de Azure. En concreto, no comparta ai Search, Azure Cosmos DB ni recursos de almacenamiento entre el servicio del agente y otros componentes de la aplicación. En su lugar, aprovisione instancias dedicadas para las dependencias necesarias del servicio del agente.

Esta separación proporciona dos ventajas clave:

  • Contiene errores o degradación del rendimiento a un único segmento de carga de trabajo, lo que evita impactos en cascada en las características de la aplicación no relacionadas.

  • Permite aplicar procesos operativos de destino, como la copia de seguridad, la restauración y la conmutación por error. Estos procesos se ajustan a los requisitos de disponibilidad y recuperación específicos del flujo de carga de trabajo que usa esos recursos.

Por ejemplo, si la aplicación de interfaz de usuario de chat necesita almacenar el estado transaccional en Azure Cosmos DB, aprovisione una cuenta y una base de datos de Azure Cosmos DB independientes para ese propósito, en lugar de reutilizar la cuenta o la base de datos que administra el servicio de agente foundry. Incluso si la simplicidad operativa o del costo motiva el uso compartido de recursos, el riesgo de que un evento de confiabilidad afecte a las características de carga de trabajo no relacionadas supera el ahorro potencial en la mayoría de los escenarios empresariales.

Importante

Si coloca datos específicos de la carga de trabajo con las dependencias del agente por motivos operativos o de costo, nunca interactúe directamente con los datos administrados por el sistema, como colecciones, contenedores o índices, que el servicio Foundry Agent crea. Estos detalles de implementación internos no están documentados y están sujetos a cambios sin previo aviso. El acceso directo puede interrumpir el servicio del agente o provocar la pérdida de datos. Use siempre las API del plano de datos del servicio Foundry Agent para la manipulación de datos y trate los datos subyacentes como opacos y solo de supervisión.

Diseño con varias regiones

Esta arquitectura usa zonas de disponibilidad para lograr una alta disponibilidad dentro de una sola región de Azure. No es una solución de varias regiones. Carece de los siguientes elementos críticos necesarios para la resistencia regional y la recuperación ante desastres (DR):

  • Enrutamiento de tráfico y entrada global
  • Administración de DNS para la conmutación por error
  • Estrategias de replicación o aislamiento de datos entre regiones
  • Designación activa-activa, activa-pasiva o activa-fría
  • Procesos regionales de conmutación por error y conmutación por recuperación para cumplir los objetivos de tiempo de recuperación (RTO) y los objetivos de punto de recuperación (RPO)
  • Consideración de la disponibilidad de regiones para experiencias de desarrollador, incluido el portal de Azure AI Foundry y las API del plano de datos

Si la carga de trabajo requiere continuidad empresarial si se produce una interrupción regional, debe diseñar e implementar componentes adicionales y procesos operativos más allá de esta arquitectura. En concreto, debe abordar el equilibrio de carga y la conmutación por error en cada capa de arquitectura, incluidas las siguientes áreas:

  • Datos en tierra (almacenes de conocimiento)
  • Hospedaje de modelos y puntos de conexión de inferencia
  • La orquestación o la capa del agente
  • Tráfico de interfaz de usuario orientado al usuario y puntos de entrada DNS

También debe asegurarse de que los controles de observabilidad, supervisión y seguridad de contenido permanezcan operativos y coherentes entre regiones.

Esta arquitectura de línea de base carece de funcionalidades de varias regiones, por lo que es probable que las interrupciones regionales resulten en la pérdida de servicio dentro de la carga de trabajo.

Recuperación ante desastres

Las arquitecturas de chat contienen componentes con estado, por lo que es esencial planear la recuperación ante desastres. Normalmente, estas cargas de trabajo requieren un almacén de memoria para las sesiones de chat activas o en pausa. También requieren almacenamiento para datos complementarios, como documentos o imágenes, agregados a subprocesos de chat. La capa de orquestación del agente también puede mantener el estado específico de los flujos de conversación. En esta arquitectura, Foundry Agent Service usa Azure Cosmos DB, Storage y AI Search para conservar el estado operativo y transaccional. El ciclo de vida y el acoplamiento de este estado entre componentes determina la estrategia de recuperación ante desastres y las operaciones de recuperación.

Para foundry Agent Service, asegúrese de que puede recuperar todas las dependencias a un momento dado coherente. Este enfoque ayuda a mantener la integridad transaccional en las tres dependencias externas.

Las siguientes recomendaciones abordan la recuperación ante desastres para cada servicio:

  • Azure Cosmos DB: Habilite la copia de seguridad continua para la enterprise_memory base de datos. Esta configuración proporciona restauración a un momento dado (PITR) con un RPO de siete días, que incluye definiciones de agente y subprocesos de chat. Pruebe el proceso de restauración periódicamente para confirmar que cumple el RTO y que los datos restaurados permanecen disponibles para el servicio del agente. Restaure siempre a la misma cuenta y base de datos.

  • Búsqueda de IA: Ai Search carece de funcionalidades de restauración integradas y no admite la manipulación directa de índices. Si se produce una pérdida de datos o daños, debe ponerse en contacto con el soporte técnico de Microsoft para obtener ayuda con la restauración del índice. Esta limitación puede afectar significativamente al RTO. Si la interfaz de usuario de chat no admite cargas de archivos y no tiene agentes que usan archivos estáticos como conocimiento, es posible que no necesite un plan de recuperación ante desastres para la búsqueda de IA.

    Mantenga una fuente independiente y actualizada periódicamente de verdad para su conocimiento de base empresarial. Esta práctica garantiza que puede volver a generar índices cuando sea necesario.

  • Almacenamiento: Si tiene una cuenta de almacenamiento con redundancia geográfica, use la conmutación por error administrada por el cliente para los contenedores de blobs que usa foundry Agent Service. Esta configuración le permite iniciar la conmutación por error durante una interrupción regional. Si usa solo almacenamiento con redundancia de zona, póngase en contacto con el soporte técnico de Microsoft para restaurar los datos. Este proceso podría extender el RTO. Al igual que con la búsqueda de IA, si la interfaz de usuario de chat no admite cargas de archivos y no tiene agentes que usan archivos estáticos como conocimiento, es posible que no necesite un plan de recuperación ante desastres para contenedores de blobs.

  • Coherencia transaccional: Si el almacén de estado de la carga de trabajo hace referencia a identificadores de agente de Azure AI, como identificadores de subprocesos o identificadores de agente, coordine la recuperación en todos los almacenes de datos pertinentes. Restaurar solo un subconjunto de dependencias puede dar lugar a datos huérfanos o incoherentes. Diseñe los procesos de recuperación ante desastres para mantener la integridad referencial entre la carga de trabajo y el estado del servicio del agente.

  • Definiciones y configuración del agente: Defina agentes como código. Almacene definiciones de agente, conexiones, avisos del sistema y parámetros en el control de código fuente. Esta práctica permite volver a implementar agentes desde una configuración correcta conocida si pierde la capa de orquestación. Evite realizar cambios sin realizar cambios en la configuración del agente a través del portal de AI Foundry o las API del plano de datos. Este enfoque garantiza que los agentes implementados permanezcan reproducibles.

Antes de pasar a producción, cree un runbook de recuperación que solucione los errores en el estado propiedad de la aplicación y en el estado de propiedad del agente.

Seguridad

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.

Esta arquitectura amplía la base de seguridad establecida en la arquitectura básica de referencia de chat de Azure AI Foundry. La principal diferencia es la adición de un perímetro de seguridad de red junto con el perímetro de identidad de la arquitectura básica. Desde una perspectiva de red, Application Gateway es el único recurso expuesto a Internet. Hace que la aplicación de interfaz de usuario de chat esté disponible para los usuarios. Desde una perspectiva de identidad, la interfaz de usuario de chat debe autenticar y autorizar solicitudes. Use identidades administradas siempre que sea posible para autenticar aplicaciones en servicios de Azure.

En esta sección se describen las consideraciones de red y seguridad para la rotación de claves y el ajuste preciso del modelo de Azure OpenAI.

Administración de identidades y acceso

Esta arquitectura usa principalmente identidades administradas asignadas por el sistema para la autenticación entre servicios. También puede usar identidades administradas asignadas por el usuario. En cualquier caso, aplique los siguientes principios:

  • Aísle las identidades por recurso y función. Aprovisione identidades administradas distintas para los siguientes componentes:

    • La cuenta de Azure AI Foundry
    • Cada proyecto de Azure AI Foundry
    • La aplicación web
    • Cualquier orquestador personalizado o código de integración

  • Asigne una identidad a un recurso de Azure solo si ese recurso debe autenticarse como cliente en otro servicio de Azure.

  • Use tipos de identidades adecuados para fines. Siempre que sea posible, use identidades de carga de trabajo para aplicaciones y automatización y use identidades de agente para agentes de IA.

Acceso a los empleados del portal de Azure AI Foundry

Al incorporar empleados a proyectos de Azure AI Foundry, asigne los permisos mínimos necesarios para su rol. Use los grupos de identificadores de Entra de Microsoft y el control de acceso basado en rol (RBAC) para aplicar la separación de tareas. Por ejemplo, distinga a los desarrolladores de agentes de científicos de datos que controlan tareas de ajuste fino. Sin embargo, tenga en cuenta las limitaciones y los riesgos.

El portal de Azure AI Foundry ejecuta muchas acciones mediante la identidad del servicio en lugar de la identidad del empleado. Como resultado, los empleados que tienen roles de RBAC limitados podrían tener visibilidad sobre los datos confidenciales, como los subprocesos de chat, las definiciones de agente y la configuración. Este diseño del portal de AI Foundry puede omitir accidentalmente las restricciones de acceso deseadas y exponer más información de lo previsto.

Para mitigar el riesgo de acceso no autorizado, restrinja el uso del portal en entornos de producción a los empleados que tengan una necesidad operativa clara. Para la mayoría de los empleados, deshabilite o bloquee el acceso al portal de Azure AI Foundry en producción. En su lugar, use canalizaciones de implementación automatizadas e infraestructura como código (IaC) para administrar la configuración del agente y del proyecto.

Trate la creación de nuevos proyectos en una cuenta de Azure AI Foundry como una acción con privilegios. Los proyectos creados a través del portal no heredan automáticamente los controles de seguridad de red establecidos, como puntos de conexión privados o grupos de seguridad de red (NSG). Y los nuevos agentes de esos proyectos omiten el perímetro de seguridad previsto. Aplique la creación de proyectos exclusivamente a través de los procesos de IaC controlados y auditables.

Asignaciones y conexiones de roles de proyecto de Azure AI Foundry

Para usar foundry Agent Service en modo estándar, el proyecto debe tener permisos administrativos en las dependencias del servicio foundry Agent. En concreto, la identidad administrada del proyecto debe tener asignaciones de roles elevados en la cuenta de almacenamiento, AI Search y la cuenta de Azure Cosmos DB. Estos permisos proporcionan acceso casi completo a estos recursos, incluida la capacidad de leer, escribir, modificar o eliminar datos. Para mantener el acceso con privilegios mínimos, aísle los recursos de carga de trabajo de las dependencias del servicio Foundry Agent.

Todos los agentes de un único proyecto de AI Foundry comparten la misma identidad administrada. Si la carga de trabajo usa varios agentes que requieren acceso a distintos conjuntos de recursos, el principio de privilegios mínimos requiere que cree un proyecto independiente de Azure AI Foundry para cada patrón de acceso de agente distinto. Esta separación permite asignar solo los permisos mínimos necesarios a la identidad administrada de cada proyecto, lo que reduce el riesgo de acceso excesivo o no deseado.

Al establecer conexiones a recursos externos desde Azure AI Foundry, use la autenticación basada en identificadores de Microsoft Entra si está disponible. Este enfoque elimina la necesidad de mantener secretos previamente compartidos. Ámbito de cada conexión para que solo el proyecto propietario pueda usarlo. Si varios proyectos requieren acceso al mismo recurso, cree una conexión independiente en cada proyecto en lugar de compartir una sola conexión entre proyectos. Esta práctica aplica límites de acceso estrictos e impide que los proyectos futuros hereden el acceso que no requieren.

Evite crear conexiones en el nivel de cuenta de Azure AI Foundry. Estas conexiones se aplican a todos los proyectos actuales y futuros de la cuenta. Pueden conceder accidentalmente acceso amplio a los recursos, infringir los principios de privilegios mínimos y aumentar el riesgo de exposición de datos no autorizados. Solo se prefieren conexiones de nivel de proyecto.

Redes

Además del acceso basado en identidades, esta arquitectura requiere confidencialidad de la red.

El diseño de red incluye las siguientes medidas de seguridad:

  • Un único punto de entrada seguro para todo el tráfico de la interfaz de usuario de chat, que minimiza la superficie expuesta a ataques.

  • Tráfico de red de entrada y salida filtrados mediante una combinación de grupos de seguridad de red, un firewall de aplicaciones web, rutas definidas por el usuario (UDR) y reglas de Azure Firewall

  • Cifrado de datos de un extremo a otro en tránsito mediante TLS

  • Privacidad de red mediante Private Link para todas las conexiones de servicio PaaS de Azure

  • Segmentación lógica y aislamiento de recursos de red, con subredes dedicadas para cada agrupación de componentes principal para admitir directivas de seguridad granulares

Flujos de red

Diagrama que muestra dos flujos de red desde la arquitectura de aplicaciones web de App Service de línea de base y el flujo de red de Foundry Agent Service.

La arquitectura de la aplicación web de App Service de línea base describe el flujo de entrada del usuario a la interfaz de usuario de chat y el flujo de App Service a los servicios PaaS de Azure. Esta sección se centra en las interacciones del agente.

Cuando la interfaz de usuario de chat se comunica con el agente implementado en Azure AI Foundry, se producen los siguientes flujos de red:

  1. La interfaz de usuario de chat hospedada en App Service inicia solicitudes HTTPS a través de un punto de conexión privado al punto de conexión de api del plano de datos de Azure AI Foundry.

  2. Cuando el agente accede a los servicios PaaS de Azure, como dependencias de servicio, almacenes de conocimiento personalizados o herramientas personalizadas, envía solicitudes HTTPS desde la subred delegada a los puntos de conexión privados de esos servicios.

  3. Cuando el agente accede a los recursos fuera de la red virtual, incluidas las API basadas en Internet o los servicios externos, se ve obligado a enrutar esas solicitudes HTTPS desde la subred delegada a través de Azure Firewall.

Los puntos de conexión privados sirven como un control de seguridad crítico en esta arquitectura complementando la seguridad basada en identidades.

Entrada a Azure AI Foundry

Esta arquitectura deshabilita el acceso público al plano de datos de Azure AI Foundry, ya que solo permite el tráfico a través de un vínculo privado para Azure AI Foundry. Puede acceder a gran parte del portal de Azure AI Foundry a través del sitio web del portal, pero toda la funcionalidad de nivel de proyecto requiere acceso a la red. El portal se basa en las API del plano de datos de la cuenta de AI Foundry, que solo son accesibles a través de puntos de conexión privados. Como resultado, los desarrolladores y científicos de datos deben acceder al portal a través de un jump box, una red virtual emparejada o una conexión VPN de sitio a sitio o ExpressRoute.

Todas las interacciones mediante programación con el plano de datos del agente, como desde la aplicación web o desde el código de orquestación externa al invocar la inferencia del modelo, también deben usar estos puntos de conexión privados. Los puntos de conexión privados se definen en el nivel de cuenta, no en el nivel de proyecto. Por lo tanto, todos los proyectos de la cuenta comparten el mismo conjunto de puntos de conexión. No se puede segmentar el acceso a la red en el nivel de proyecto y todos los proyectos comparten la misma exposición de red.

Para admitir esta configuración, configure DNS para los siguientes puntos de conexión de la API FQDN de Azure AI Foundry:

  • privatelink.services.ai.azure.com
  • privatelink.openai.azure.com
  • privatelink.cognitiveservices.azure.com

En el diagrama siguiente se muestra cómo un desarrollador de inteligencia artificial se conecta a través de Azure Bastion a un jump box de máquina virtual (VM). Desde ese jumpbox, el autor puede acceder al proyecto en el portal de Azure AI Foundry a través de un punto de conexión privado en la misma red.

Diagrama que muestra cómo un usuario se conecta a una máquina virtual de jump box a través de Azure Bastion.

Control del tráfico desde la subred del agente de Azure AI Foundry

Esta arquitectura enruta todo el tráfico de red saliente (salida) desde la funcionalidad del servicio foundry Agent a través de una subred delegada dentro de la red virtual. Esta subred actúa como punto de salida único para las tres dependencias de servicio necesarias del agente y cualquier origen de conocimiento externo o conexiones de herramientas que use el agente. Este diseño ayuda a reducir los intentos de filtración de datos desde la lógica de orquestación.

Al forzar esta ruta de salida, obtendrá un control total sobre el tráfico saliente. Puede aplicar reglas de NSG pormenorizadas, enrutamiento personalizado y control DNS a todo el tráfico del agente que sale del servicio.

El servicio de agente usa la configuración dns de la red virtual para resolver los registros de punto de conexión privado y los FQDN externos necesarios. Esta configuración garantiza que las solicitudes del agente generen registros DNS, que admiten la auditoría y la solución de problemas.

El grupo de seguridad de red asociado a la subred de salida del agente bloquea todo el tráfico entrante porque no debe producirse ninguna entrada legítima. Las reglas de NSG salientes solo permiten el acceso a subredes de punto de conexión privado dentro de la red virtual y al puerto 443 del Protocolo de control de transmisión (TCP) para el tráfico enlazado a Internet. El grupo de seguridad de red deniega el resto del tráfico.

Para restringir aún más el tráfico de Internet, esta arquitectura aplica una UDR a la subred, que dirige todo el tráfico HTTPS a través de Azure Firewall. El firewall controla qué FQDN puede acceder el agente a través de conexiones HTTPS. Por ejemplo, si el agente solo necesita acceder a las API públicas de Grounding con Bing , configure Azure Firewall para permitir el tráfico en api.bing.microsoft.com el puerto 443 desde esta subred. Se deniega el resto de destinos salientes.

Segmentación y seguridad de la red virtual

Esta arquitectura segmenta la red virtual asignando cada grupo de componentes principales a su propia subred. Cada subred tiene un grupo de seguridad de red dedicado que limita el tráfico entrante y saliente solo a lo que requiere el componente.

En la tabla siguiente se resume la configuración del grupo de seguridad de red y del firewall de cada subred.

Uso o nombre de subred Tráfico entrante (NSG) Tráfico saliente (NSG) UDR al firewall Reglas de salida del firewall
Puntos de conexión privados
snet-privateEndpoints		 Red de área virtual No se permite tráfico Sí No se permite tráfico
Application Gateway
snet-appGateway		 Direcciones IP de origen de usuario de la interfaz de usuario de chat, como la red pública de Internet y los orígenes necesarios para el servicio Subred del punto de conexión privado y elementos necesarios para el servicio No -
Servicio de Aplicaciones
snet-appServicePlan		 No se permite tráfico Puntos de conexión privados y Azure Monitor Sí Para Azure Monitor
Servicio de agente de fundición
snet-agentsEgress		 No se permite tráfico Puntos de conexión privados e Internet Sí Solo los FQDN públicos que permita que los agentes usen
Máquinas virtuales de Jump Box
snet-jumpBoxes		 Subred de Azure Bastion Puntos de conexión privados e Internet Sí Según sea necesario para la máquina virtual
Agentes de compilación
snet-buildAgents		 Subred de Azure Bastion Puntos de conexión privados e Internet Sí Según sea necesario para la máquina virtual
Azure Bastion
AzureBastionSubnet		 Consulte Acceso a NSG y Azure Bastion. Consulte Acceso a NSG y Azure Bastion. No -
Azure Firewall
AzureFirewallSubnet
AzureFirewallManagementSubnet		 Sin NSG Sin NSG No -

Este diseño deniega explícitamente el resto del tráfico, ya sea a través de reglas de NSG o de forma predeterminada en Azure Firewall.

Al implementar la segmentación de red y la seguridad en esta arquitectura, siga estas recomendaciones:

  • Implemente un plan de Azure DDoS Protection en la dirección IP pública de Application Gateway para mitigar los ataques volumétricos.

  • Conecte un grupo de seguridad de red a cada subred que lo admita. Aplique las reglas más estrictas posibles sin interrumpir la funcionalidad necesaria.

  • Aplique la tunelización forzada a todas las subredes admitidas para que el firewall de salida pueda inspeccionar todo el tráfico saliente. Use la tunelización forzada incluso en subredes en las que no se espera salida. Este método agrega una medida de defensa en profundidad que protege contra el uso indebido intencionado o accidental de la subred.

Gobernanza mediante Policy

Para alinearse con la línea de base de seguridad de la carga de trabajo, use Azure Policy y las directivas de red para asegurarse de que todos los recursos de carga de trabajo cumplan sus requisitos. La automatización de la plataforma a través de la directiva reduce el riesgo de desfase de configuración de seguridad y ayuda a reducir las actividades de validación manual.

Considere la posibilidad de implementar los siguientes tipos de directivas de seguridad para reforzar la arquitectura:

  • Deshabilite los métodos de autenticación basados en claves u otros métodos de autenticación local en servicios como servicios de Azure AI y Key Vault.

  • Requerir una configuración explícita de reglas de acceso de red, puntos de conexión privados y grupos de seguridad de red.

  • Requerir cifrado, como claves administradas por el cliente.

  • Restrinja la creación de recursos, como limitar regiones o tipos de recursos.

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 estimación de precios de Azure proporciona un ejemplo de precios para esta arquitectura. En este ejemplo solo se incluyen los componentes de esta arquitectura, por lo que puede personalizarlo para que coincida con el uso. Los componentes más caros del escenario son Azure Cosmos DB, AI Search y DDoS Protection. Otros costos importantes incluyen el proceso de la interfaz de usuario de chat y Application Gateway. Optimice esos recursos para reducir los costos.

Servicio de agente de fundición

Al usar la implementación estándar, debe aprovisionar y administrar las dependencias del servicio en su propia suscripción de Azure.

En las siguientes recomendaciones se explica cómo optimizar los costos de estos servicios necesarios:

  • Foundry Agent Service administra la asignación de unidad de solicitud (RU) en Azure Cosmos DB. Para reducir los costos a largo plazo, compre capacidad reservada para Azure Cosmos DB. Alinee las reservas con la duración y el volumen de uso esperados. Tenga en cuenta que la capacidad reservada requiere compromiso inicial y carece de flexibilidad si los patrones de uso de la carga de trabajo cambian significativamente.

  • Si el escenario de chat no requiere cargas de archivos, excluya esta característica en la aplicación. En ese caso, aplique los siguientes cambios de configuración:

    • Use un nivel de almacenamiento con redundancia local (LRS) para la cuenta de almacenamiento.
    • Configure AI Search con una sola réplica en lugar de las tres réplicas recomendadas.

  • Elimine periódicamente agentes sin usar y sus subprocesos asociados mediante el SDK o las API REST. Los agentes y subprocesos obsoletos siguen consumendo almacenamiento y pueden aumentar los costos en Azure Cosmos DB, Storage y AI Search.

  • Deshabilite las características de los recursos dependientes que la carga de trabajo no necesite, como las siguientes:

    • Clasificador semántico en AI Search
    • Funcionalidades de escritura de puerta de enlace y de varias regiones en Azure Cosmos DB

  • Para evitar cargos de ancho de banda entre regiones, implemente Azure Cosmos DB, Storage y AI Search en la misma región de Azure que foundry Agent Service.

  • Evite colocar datos específicos de la carga de trabajo en los mismos recursos de Azure Cosmos DB o AI Search que usa el servicio Foundry Agent. En algunos casos, puede compartir estos recursos para reducir la capacidad no usada en RU o unidades de búsqueda, lo que reduce el costo. Considere solo la posibilidad de compartir recursos después de una evaluación exhaustiva del riesgo para la confiabilidad, la seguridad y el rendimiento.

Conocimientos y herramientas del agente

Foundry Agent Service ejecuta la lógica del agente de forma no determinista. Puede invocar cualquier almacén de conocimiento, herramienta u otro agente conectado para cada solicitud, incluso si ese recurso no es relevante para la consulta del usuario. Este comportamiento puede dar lugar a llamadas innecesarias a api externas o orígenes de datos, aumentar los costos de cada transacción e introducir patrones de uso imprevisibles que complican la previsión del presupuesto.

Para controlar los costos y mantener un comportamiento predecible, aplique las siguientes estrategias:

  • Conecte solo los almacenes de conocimiento, las herramientas o los agentes que probablemente se usen con la mayoría de las invocaciones de agente. Evite conectar recursos que rara vez sean necesarios o que incurran en altos costos para cada llamada a menos que sean esenciales.

  • Diseñe cuidadosamente y refinar la solicitud del sistema para indicar al agente que minimice las llamadas externas innecesarias o redundantes. La solicitud del sistema debe guiar al agente para usar solo las conexiones más relevantes para cada solicitud.

  • Use la telemetría de Azure AI Foundry para supervisar las API externas, los almacenes de conocimiento o las herramientas a las que accede el agente, la frecuencia con la que accede a ellas y los costos asociados. Revise periódicamente esta telemetría para identificar patrones de uso inesperados o picos de costos, y ajuste la solicitud del sistema según sea necesario.

  • Tenga en cuenta que la invocación no determinista puede dificultar la previsión de costos, especialmente cuando se integra con api de uso medido. Si necesita costos predecibles, considere la posibilidad de autohospedaje del orquestador mediante código determinista.

Modelos de Azure OpenAI

Las implementaciones de modelos en Azure AI Foundry usan el enfoque MaaS. Los costos dependen principalmente del uso o la asignación aprovisionada previamente.

Para controlar los costos del modelo de consumo en esta arquitectura, use una combinación de los enfoques siguientes:

  • Controlar los clientes. Las solicitudes de cliente impulsan la mayoría de los costos en un modelo de consumo, por lo que el control del comportamiento del agente es fundamental.

    Para reducir el uso innecesario, realice las siguientes acciones:

    • Aprobar todos los consumidores del modelo. No exponga modelos de una manera que permita el acceso sin restricciones.

    • Aplique restricciones de limitación de tokens, como max_tokens y max_completions a través de la lógica del agente. Este control solo está disponible en la orquestación autohospedada. Foundry Agent Service no admite esta funcionalidad.

    • Optimizar la longitud de la entrada y la respuesta de la solicitud. Los mensajes más largos consumen más tokens, lo que aumenta el costo. Pide que falte suficiente contexto reduzca la eficacia del modelo. Cree solicitudes concisas que proporcionen suficiente contexto para que el modelo pueda generar una respuesta útil. Asegúrese de optimizar el límite de la longitud de la respuesta.

      Este nivel de control solo está disponible en la orquestación autohospedada. Foundry Agent Service no proporciona suficiente configuración para admitir esta funcionalidad.

  • Elija el modelo adecuado para el agente. Seleccione el modelo menos costoso que cumpla los requisitos del agente. Evite usar modelos de costos más altos a menos que sean esenciales. Por ejemplo, la implementación de referencia usa GPT-4o en lugar de un modelo más caro y logra resultados suficientes.

  • Supervisar y administrar el uso. Use Microsoft Cost Management y la telemetría del modelo para realizar un seguimiento del uso de tokens, establecer presupuestos y crear alertas para detectar anomalías. Revise periódicamente los patrones de uso y ajuste las cuotas o el acceso de cliente según sea necesario. Para más información, consulte Planeamiento y administración de costos para Azure AI Foundry.

  • Utilice el tipo de implementación adecuado. Use los precios de pago por uso para cargas de trabajo impredecibles y cambie al rendimiento aprovisionado cuando el uso sea estable y predecible. Combine ambas opciones al establecer una línea base confiable.

  • Restringir el uso del área de juegos. Para evitar costos de producción no planeados, restrinja el uso del área de juegos de Azure AI Foundry solo a entornos de preproducción.

  • Planee cuidadosamente la optimización y la generación de imágenes. Estas características tienen modelos de facturación diferentes. Se facturan por hora o por lote. Programe el uso para alinearse con los intervalos de facturación y evitar los residuos.

Recursos de seguridad de red

Esta arquitectura requiere Azure Firewall como punto de control de salida. Para optimizar los costos, use el nivel Básico de Azure Firewall a menos que el resto de los componentes de la carga de trabajo requieran características avanzadas. Los niveles más altos agregan costo, por lo que solo los usa si necesita sus funcionalidades.

Si su organización usa zonas de aterrizaje de Azure, considere la posibilidad de usar recursos de denegación de servicio distribuido y firewall compartido (DDoS) para aplazar o reducir los costos. Las cargas de trabajo que tienen requisitos de seguridad y rendimiento similares pueden beneficiarse de los recursos compartidos. Asegúrese de que los recursos compartidos no presentan riesgos operativos o de seguridad. Esta arquitectura, implementada en una zona de aterrizaje de Azure, usa recursos compartidos.

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.

La siguiente guía de excelencia operativa no incluye los elementos de la aplicación front-end, que siguen siendo los mismos que la arquitectura de aplicación web con redundancia de zona con redundancia de zona de base.

Al planear los entornos de experimentación, pruebas y producción, establezca recursos distintos y aislados de AI Foundry, incluidas las dependencias.

Proceso del agente

Microsoft administra completamente la plataforma de proceso sin servidor para las API REST del agente de Azure AI y la lógica de implementación de orquestación. Una orquestación autohospedada proporciona más control sobre las características y la capacidad del entorno de ejecución, pero debe administrar directamente las operaciones del día 2 para esa plataforma. Evalúe las restricciones y responsabilidades de su enfoque para comprender qué operaciones del día 2 debe implementar para admitir la capa de orquestación.

En ambos enfoques, debe administrar el almacenamiento de estado, como el historial de chat y la configuración del agente para la durabilidad, la copia de seguridad y la recuperación.

Monitorización

De forma similar a la arquitectura básica, los datos de diagnóstico de todos los servicios se configuran para que se envíen al área de trabajo de Log Analytics de la carga de trabajo. Todos los servicios excepto App Service capturan todos los registros. En producción, es posible que no necesite capturar todos los registros. Por ejemplo, la aplicación de interfaz de usuario de chat solo puede requerir AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs, AppServicePlatformLogsy AppServiceAuthenticationLogs. Ajuste las secuencias de registro a sus necesidades operativas.

Evalúe las alertas personalizadas, como las alertas personalizadas en las alertas de línea de base de Azure Monitor, para los recursos de esta arquitectura. Tenga en cuenta las siguientes alertas:

Supervise el uso de tokens en las implementaciones del modelo. En esta arquitectura, Azure AI Foundry realiza un seguimiento del uso de tokens a través de su integración con Application Insights.

Los cuadros de salto y las máquinas virtuales del agente de compilación residen en una ubicación con privilegios elevados, lo que proporciona a esas máquinas virtuales una línea de visión de red al plano de datos de todos los componentes de la arquitectura. Asegúrese de que esas máquinas virtuales emiten suficientes registros para comprender cuándo se usan, quién los usa y qué acciones realizan.

Control de versiones del agente y ciclo de vida

Trate a cada agente como una unidad que se pueda implementar de forma independiente dentro de la carga de trabajo de chat, a menos que diseñe específicamente la aplicación para crear y eliminar agentes dinámicamente en tiempo de ejecución. Estos agentes tienen requisitos de administración del ciclo de vida similares a otros microservicios de la carga de trabajo.

Para evitar interrupciones del servicio, asegúrese de la implementación segura y controlada del agente mediante la implementación de los siguientes enfoques:

  • Defina agentes como código. Almacene siempre definiciones de agente, conexiones, avisos del sistema y parámetros de configuración en el control de código fuente. Esta práctica garantiza la rastreabilidad y reproducibilidad. Evite los cambios sin realizar el seguimiento a través del portal de Azure AI Foundry.

  • Automatización de la implementación del agente. Use las canalizaciones de integración continua e implementación continua (CI/CD) de la carga de trabajo. Use el SDK del agente de Azure AI para compilar, probar e implementar los cambios del agente desde los agentes de compilación conectados a la red.

    Se prefieren canalizaciones de agente que se pueden implementar de forma independiente para cambios pequeños e incrementales. Pero asegúrese de que las canalizaciones proporcionan suficiente flexibilidad para implementarlas junto con el código de la aplicación cuando necesite actualizaciones coordinadas. Para admitir este método, acopla de forma flexible el código de la interfaz de usuario de chat y los agentes de chat para que los cambios en un componente no requieran cambios simultáneos en el otro.

  • Prueba antes de producción. Valide el comportamiento del agente, las solicitudes y las conexiones en entornos de preproducción. Use una combinación de pruebas automatizadas y manuales para detectar regresiones, problemas de seguridad y cambios no deseados en el comportamiento del agente.

    Los agentes definidos en Foundry Agent Service se comportan de forma no determinista, por lo que debe determinar cómo medir y mantener el nivel de calidad deseado. Cree y ejecute un conjunto de pruebas que compruebe si hay respuestas ideales a escenarios y preguntas realistas del usuario.

  • Versión y seguimiento de agentes. Asigne identificadores de versión no cifrados a cada agente. Mantenga los registros de las versiones del agente activas, junto con sus dependencias, como modelos, orígenes de datos y herramientas. Prefiere implementar nuevas versiones de agente junto con las existentes para habilitar la implementación progresiva, la reversión y la migración controlada de usuarios o sesiones.

  • Planee la conmutación por recuperación. Azure AI Foundry no proporciona compatibilidad integrada con implementaciones azul-verde o controlada de agentes. Si necesita estos patrones de implementación, implemente una capa de enrutamiento, como una puerta de enlace de API o un enrutador personalizado, delante de la API del agente. Esta capa de enrutamiento permite desplazar el tráfico de forma incremental entre las versiones del agente, supervisar el impacto y realizar una conmutación completa cuando esté lista.

  • Eliminación del agente de coordenadas. Al quitar agentes, coordine el proceso con los requisitos de administración de estado y experiencia del usuario de la aplicación. Controle las sesiones de chat activas de forma adecuada. En función de los requisitos funcionales de la carga de trabajo, puede migrar sesiones, anclar usuarios a la versión anterior del agente o requerir que los usuarios inicien nuevas sesiones.

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.

En esta sección se aborda la eficacia del rendimiento de la búsqueda de IA, las implementaciones de modelos y Azure AI Foundry.

En Foundry Agent Service, no controla las consultas específicas enviadas a los índices porque los agentes no tienen código. Para optimizar el rendimiento, céntrese en lo que puede controlar en el índice. Observe cómo el agente suele consultar el índice y aplicar instrucciones para analizar y optimizar el rendimiento en la búsqueda de IA.

Si el ajuste del servidor de índices por sí solo no resuelve todos los cuellos de botella, tenga en cuenta las siguientes opciones:

  • Reemplace la conexión directa a AI Search por una conexión a una API que posee. Esta API puede implementar código optimizado para los patrones de recuperación del agente.

  • Rediseñe la capa de orquestación para usar la alternativa autohospedada para que pueda definir y optimizar consultas en su propio código de orquestador.

Eficiencia del rendimiento en implementaciones de modelos

  • Determine si la aplicación necesita rendimiento aprovisionado o puede usar el modelo compartido (consumo). El rendimiento aprovisionado proporciona capacidad reservada y latencia predecible, lo que es importante para las cargas de trabajo de producción que tienen objetivos estrictos de nivel de servicio. El modelo de consumo proporciona un servicio de mejor esfuerzo y podría sufrir efectos ruidosos vecinos.

  • Supervise el uso administrado por el aprovisionamiento para evitar el aprovisionamiento excesivo o el aprovisionamiento insuficiente.

  • Elija un modelo conversacional que cumpla los requisitos de latencia de inferencia.

  • Implemente modelos en la misma región de datos que los agentes para minimizar la latencia de red.

Rendimiento del agente de Azure AI

Los agentes de Azure AI se ejecutan en un back-end de proceso sin servidor que no admite el ajuste de rendimiento personalizado. Sin embargo, todavía puede mejorar el rendimiento mediante el diseño del agente:

  • Minimice el número de almacenes de conocimiento y herramientas conectados al agente de chat. Cada conexión adicional puede aumentar el tiempo de ejecución total de una llamada de agente, ya que el agente podría invocar todos los recursos configurados para cada solicitud.

  • Use Azure Monitor y Application Insights para realizar un seguimiento de los tiempos de invocación del agente, las latencias del almacén de conocimiento y las latencias del almacén de conocimiento y las tasas de error. Revise periódicamente esta telemetría para identificar conexiones lentas de conocimientos o herramientas.

  • Design system prompts that guide the agent to use connections efficiently. Por ejemplo, indique al agente que consulte almacenes de conocimiento externos solo cuando sea necesario o para evitar invocaciones redundantes de herramientas.

  • Supervise los límites de servicio o las cuotas que podrían afectar al rendimiento durante el uso máximo. Observe los indicadores de limitación, como las respuestas HTTP 429 o 503, aunque el proceso sin servidor se escale automáticamente.

Implementación de este escenario

Para implementar y ejecutar esta implementación de referencia, siga la guía de implementación en la implementación de referencia de referencia de chat del servicio Foundry Agent.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autores principales:

  • Rob Bagby | Desarrollador principal de contenido: patrones y prácticas de Azure
  • Chad Kittel | Ingeniero principal de software: Patrones y prácticas de Azure

Otros colaboradores:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Paso siguiente