Ingeniería del comportamiento agéntico

Los modelos de lenguaje grande (LLM) no son deterministas por naturaleza. Es posible que la misma entrada no siempre genere la misma salida. Los métodos de prueba tradicionales tienen dificultades para tener en cuenta esta variabilidad. ¿Cómo puede adaptar el proceso de desarrollo para tener la confianza de que el sistema funcionará de forma coherente según lo previsto?

La transformación de inteligencia artificial empresarial plantea más preguntas: ¿Cómo se protegen y gobiernan los conocimientos propietarios? ¿Cómo se diseña un comportamiento fiable? ¿Cómo se usa la evidencia de ejecución para mejorar el sistema a lo largo del tiempo?

La ingeniería del comportamiento agéntico (ABE), tal como se propone en este artículo, es una metodología independiente de la plataforma para especificar, fundamentar, controlar, comprobar y observar el comportamiento de los agentes de inteligencia artificial. La metodología le ayuda a aclarar las necesidades del usuario y del sistema, definir los resultados esperados, aplicar límites de ejecución y comprobar los cambios en escenarios representativos. Las pruebas tradicionales pueden confirmar que una implementación concreta funciona según lo esperado, pero a menudo no logran detectar por completo las desviaciones de comportamiento causadas por cambios en los modelos, las indicaciones, las herramientas o las fuentes de datos. ABE aborda este desafío al hacer que el comportamiento deseado sea explícito y verificable continuamente, lo que permite a los equipos evolucionar sistemas agénticos sin perder la confianza en sus resultados.

Conceptos clave

El artefacto clave de ABE es el contrato de comportamiento. El contrato define el comportamiento necesario por separado de la implementación para que las expectativas permanezcan explícitas y verificables a medida que cambia el sistema. En sistemas agénticos, modelos, prompts, implementaciones de herramientas, orígenes de conocimiento, memoria, directivas, orquestación y acceso de usuario pueden cambiar con el tiempo. Utilice contratos de comportamiento para evaluar el efecto de esos cambios en el comportamiento requerido, con el fin de identificar las desviaciones y subsanarlas.

Contrato de comportamiento

Un contrato de comportamiento define lo que un agente debe y no debe hacer en una situación delimitada. Especifica:

• Situación, actores y ámbito en el que se aplica el contrato.
• Resultados aceptables y características de resultado requeridas.
• Conclusiones, revelaciones, acciones y efectos secundarios prohibidos.
• Evidencia necesaria para que el agente pueda concluir o actuar.
• Comportamiento cuando la evidencia no es suficiente o las dependencias fallan.
• Escalación, aprobación y condiciones de parada.

El contrato hace explícitos los requisitos de seguridad y de inteligencia artificial responsables aplicables. Defina estos requisitos durante el diseño para que el equipo pueda incorporarlos a la implementación y la comprobación desde el principio. Para obtener instrucciones sobre cómo definir responsabilidades y directivas específicas de la carga de trabajo, consulte Inteligencia artificial responsable en las cargas de trabajo de Azure.

Un contrato de comportamiento comparte un principio con el diseño por contrato: hacer explícitas las obligaciones de software. Define el comportamiento necesario sin prescribir una implementación, por lo que los requisitos pueden permanecer estables a medida que cambia la implementación.

Utiliza un contrato para una situación delimitada y varios escenarios para sus variaciones. Cree otro contrato cuando los actores, autoridad, evidencia requerida o resultados aceptables cambien materialmente.

Los equipos de producto e ingeniería mantienen conjuntamente el contrato de comportamiento como un activo versionado. El propietario del producto, respaldado por expertos del dominio, aprueba el comportamiento previsto y los resultados esperados. El equipo de ingeniería elabora conjuntamente las restricciones técnicas y los requisitos de evidencia, y se encarga de mantener las definiciones de los escenarios comprobables, la cobertura, el control de versiones y la verificación.

Revise los cambios en las expectativas de comportamiento conjuntamente y realice una revisión de seguridad y riesgo cuando sea necesario. El mantenimiento técnico que conserva esas expectativas debe seguir el proceso de revisión de ingeniería del equipo. Para obtener instrucciones relacionadas, consulte propiedad de la especificación funcional y responsabilidades de la estrategia de pruebas.

Ejemplo: Aprobar revisiones de productos de bajo riesgo

Un sitio web minorista requiere que su equipo de estándares compruebe las reseñas de productos de los clientes con respecto a una directiva de uso aceptable antes de la publicación. El equipo de carga de trabajo desea que un agente apruebe las solicitudes de bajo riesgo y remita los casos de mayor riesgo o inciertos al equipo de normas. El objetivo es reducir la revisión manual al tiempo que se mantienen los estándares de publicación del sitio.

En la tabla siguiente se presenta un contrato de comportamiento con versiones para este agente.

Puede mantener el contrato en JSON, YAML, Markdown, un documento Word o PDF. Elija un formato para que los responsables de producto, expertos en dominio e ingenieros puedan revisar y versionar juntos. JSON o YAML pueden facilitar la lectura de campos individuales. Sea cual sea el formato que elija, mantenga una versión autoritativa y vincule los escenarios y los resultados de la evaluación a ella.

En este ejemplo, la directiva permite comentarios negativos sobre productos y requiere revisión humana de envíos que contienen información personal. Un cliente envía:

La batería duró solo una hora. No volvería a comprarlo.

La decisión esperada es aprobar el envío. El registro de decisión cita la regla de directiva aplicable y explica que el texto describe una experiencia de producto y no contiene contenido que requiera revisión humana según esta política.

Si el envío incluye información personal, la decisión esperada es enviarlo para revisión humana y mantenerlo sin publicar. Si no se puede recuperar la política actual, el envío también permanece sin publicar.

La aplicación aplica permisos y comprueba el envío antes de publicar una revisión aprobada. Para evaluar la decisión del agente, compárela con la decisión esperada del equipo de estándares para ese envío.

Biblioteca de escenarios

La biblioteca de escenarios convierte el contrato de comportamiento en escenarios de usuario concretos. Cada escenario define una consulta o tarea, evidencia y condiciones de dependencia, y un resultado esperado. Aplica el contrato de comportamiento sin modificar los requisitos del mismo.

Los expertos en producto y en dominio validan escenarios y resultados esperados. La ingeniería mantiene definiciones y cobertura del contrato.

En la tabla siguiente se muestra cómo la biblioteca de escenarios aplica el contrato de comportamiento a situaciones representativas para el agente de revisión del producto:

Comience a realizar pruebas con casos sintéticos: envíos ficticios y respuestas simuladas del servicio de políticas. La recopilación de datos de referencia puede impedir que el equipo de ingeniería complete la implementación de la funcionalidad. Los casos sintéticos ponen de manifiesto las lagunas en el contrato o en la implementación y dan tiempo a los expertos del ámbito para completar la curación de los datos de referencia.

Utilice casos sintéticos para guiar a expertos en la materia (SME) en la recopilación de casos de carga de trabajo reales para un conjunto de datos dorado independiente. El conjunto de datos golden expande los escenarios con la misma estructura: consultas reales, evidencia correspondiente y resultados esperados validados por SME. Un escenario puede tener muchos casos de referencia.

Para el escenario de revisión negativa, el equipo de estándares recopila envíos reales que critican un producto, pero cumplen la directiva de publicación. Conservan las entradas de prueba aprobadas y la versión de directiva aplicable y, a continuación, establecen la decisión esperada. Los casos sintéticos orientan la recopilación. No se incorporan al conjunto de datos de referencia.

La verdad de terreno es un resultado esperado validado por el dominio o una prueba de apoyo cuya corrección pueda establecerse, no la salida registrada de un agente. Consulte Use los datos adecuados para la evaluación.

Utiliza los escenarios durante una prueba de concepto para comparar las implementaciones con el mismo contrato y los mismos límites de coste y latencia. En el agente de revisión de productos, se comprobarían las decisiones de aprobación y los traspasos frente a los resultados esperados por el equipo de estándares. Registre el diseño y los inconvenientes en un registro de decisión de arquitectura y conserve los escenarios para las pruebas de regresión.

Vincule cada caso a su escenario y versión del contrato, y registre si es sintético o procede de datos reales de la carga de trabajo. Mantén los escenarios independientes de las indicaciones para que el comportamiento requerido siga siendo comprobable a medida que cambia la implementación.

Añade casos límite y fallos de producción revisados. Si los límites de seguridad están incluidos en el alcance, incluye escenarios de inyección de indicaciones, uso indebido y exfiltración procedentes de los ejercicios de red teaming de IA y del modelado de amenazas.

Mantén separados los conjuntos de desarrollo, regresión y lanzamiento protegido. Reserve algunos casos de prueba para la comprobación de la versión y no los use para desarrollar o ajustar la implementación. Restrinja el acceso a estos casos y sus resultados esperados. Si un caso guía un cambio de implementación, muévalo al conjunto de regresión y reemplácelo por otro caso validado por expertos en dominio.

Envolvente operativa

La envolvente operativa abarca un subconjunto de los requisitos no funcionales de la carga de trabajo. Define los límites de recursos y ejecución, como la latencia, el costo, el uso de tokens, los reintentos, las llamadas a herramientas y el tiempo dedicado a esperar la aprobación.

El contrato define el comportamiento correcto. La envolvente define los límites operativos dentro de los cuales debe funcionar el sistema. Un contrato puede hacer referencia a una versión de la envolvente operativa cuando esos límites forman parte de sus criterios de aceptación. Asigna versiones a la envolvente de forma independiente, de modo que los límites operativos puedan modificarse sin necesidad de redefinir los requisitos de comportamiento que no hayan cambiado. Los contratos de comportamiento y los envelopes operativos no requieren una relación uno a uno.

Volver a reproducir

Diseño para la reproducción

Replay, como sugiere el nombre, vuelve a ejecutar los pasos de inferencia del sistema proporcionando respuestas de API y herramientas recopiladas o resultados rag. Este enfoque le ayuda a optimizar la solicitud e identificar cualquier evidencia que falte. Evita llamadas repetidas a las API activas o a las herramientas del Protocolo de contexto de modelo (MCP), que pueden ser costosas, limitadas a velocidad o devolver datos que cambian con el tiempo.

Recopila datos de reproducción en producción. Quite o enmascare los datos confidenciales según la directiva antes del análisis o la revisión por parte del especialista en la materia. Conserva las cargas útiles de respuesta y sus argumentos de solicitud sin alterar el significado del caso. Si la censura elimina pruebas necesarias, utiliza un dispositivo de prueba aprobado y documenta la limitación.

Pida a un SME que revise y depure los datos derivados de producción antes de agregarlos al conjunto de datos golden o usarlos para crear dobles de prueba. Los dobles de prueba pueden simular respuestas, por lo que el replay puede admitir escenarios nuevos y existentes sin necesidad de datos de producción. Consulte Respuestas ficticias con Dev Proxy y Conjuntos de datos de evaluación en Microsoft Foundry.

Configuración y ejecución de la reproducción

Asigna versiones a los conjuntos de datos de reproducción que utilices para la evaluación y las pruebas de regresión. Para comparar una actualización con la línea base, ejecute ambas implementaciones con la misma versión del conjunto de datos, con los mismos casos y versiones del evaluador. Mantenga coherentes otras condiciones de prueba, excepto el cambio que está probando. Al agregar o revisar casos, cree una nueva versión del conjunto de datos y vuelva a ejecutar ambas implementaciones.

Durante el desarrollo, puede reproducir un conjunto más pequeño de casos para comprobar el comportamiento que está cambiando. Si aún no ha registrado respuestas para un nuevo escenario, use respuestas simuladas y etiquetelas en el conjunto de datos.

Elija el propósito de la ejecución:

La configuración de ejecución se extiende más allá del conjunto de datos y los evaluadores. También incluye prompts, modelos, servidores API/MCP, bibliotecas compatibles y mucho más. Al realizar evaluaciones, es necesario contar con una hipótesis clara y cambios correlacionados para garantizar que cada ejecución solo modifique un conjunto mínimo. Esto le permite medir correctamente el impacto y evitar ejecutar la misma actualización varias veces debido a deficiencias en el registro.

La reproducción no reemplaza las pruebas unitarias o de integración. Cada prueba comprueba un aspecto diferente del sistema de software, y todas son igualmente importantes. Véase Probar y evaluar cargas de trabajo de IA.

En el diagrama siguiente se muestra el proceso de reproducción compartida.

Ejemplo: Verificar un cambio del agente de revisión del producto

Supongamos que la versión 42 del agente de revisión del producto aprueba un envío que debería haberse remitido al equipo de estándares porque contiene información personal. El equipo prepara el caso utilizando las medidas de seguridad de los datos de reproducción y recurre a una prueba de desarrollo específica mientras revisa la implementación del candidato 43.

1. Configura una ejecución de evaluación para el candidato 43. El conjunto de datos de evaluación debe incluir casos normales, así como revisiones negativas conformes, envíos inciertos y fallos de dependencia. Actualícelo con casos que prueben la característica (regla de información personal). La actualización crea una nueva versión del conjunto de datos. Ejecuta la evaluación y la línea de base en el nuevo conjunto de datos. Reproducir el conjunto de datos completo para medir la precisión de la decisión, el costo y la latencia por escenario.

2. Actualice el conjunto de datos de verificación de la versión con el nuevo caso de uso y obtenga una versión actualizada. Haga referencia a la versión expandida del conjunto de datos y establezca umbrales de aceptación. Reproduce el candidato 43 y la línea de base 42 con el mismo conjunto ampliado de pruebas y las pruebas registradas.

3. Comprueba los casos existentes y los nuevos con respecto a las expectativas revisadas. Espere approve en caso de comentarios negativos que cumplen los requisitos y human_review en caso de envíos que contengan información personal. Confirme que los envíos que esperan revisión humana permanecen sin publicar.

4. Guarde los resultados y las trazas por caso con su versión de configuración. Calcule las métricas de cada escenario. Utiliza los resultados de la evaluación para mejorar la implementación y los resultados de la verificación previa al lanzamiento, a fin de decidir si el candidato puede lanzarse. Una mejora general no invalida un requisito obligatorio no superado.

Architecture

Para usar la metodología abe para diseñar las características de la carga de trabajo, comience con la detección de problemas y capture el comportamiento esperado en un contrato. A continuación, decida si la carga de trabajo necesita la ejecución dirigida por el agente. Trabaje con el responsable del negocio y el equipo de ingeniería para aclarar las necesidades y suposiciones del usuario. Derivar escenarios de los contratos de comportamiento, identificar el conocimiento y las evidencias que necesita el sistema y decidir qué controles debe aplicar el sistema circundante.

El contrato de comportamiento y la biblioteca de escenarios conectan el sistema de dos bucles y guían la implementación y la mejora. El bucle interno del desarrollador verifica los cambios antes del lanzamiento. El bucle externo de producción recopila evidencia de ejecución y comentarios para identificar fallos o requisitos modificados.

La ABE organiza este trabajo en cinco responsabilidades de ingeniería: especificar, fundamentar, controlar, verificar y observar. Estas responsabilidades son lógicas, no cinco servicios requeridos ni pasos secuenciales en tiempo de ejecución. El trabajo en una sola funcionalidad puede abarcar varias responsabilidades.

La inteligencia artificial responsable y la seguridad son preocupaciones transversales en todas las cinco responsabilidades del sistema. La responsabilidad especificar hace explícitas las expectativas de IA responsable y los requisitos de seguridad en los contratos de comportamiento. La responsabilidad controlar implementa las reglas de acceso y las medidas de seguridad de ejecución que respaldan dichos requisitos.

Especificar y base proporcionan comprobaciones tempranas sobre la preparación y la viabilidad del proyecto. Especificar establece el problema y lo que significa el éxito. Base evalúa si la información requerida está disponible y es utilizable según los requisitos de acceso aplicables. Utiliza estos hallazgos para identificar brechas antes de decidir implementar y, a continuación, validar las suposiciones restantes en una prueba de concepto. Para obtener más información, consulte Alineación de la estrategia técnica con los requisitos empresariales.

Utilice el contrato de comportamiento y la biblioteca de escenarios para comparar diseños factibles. Una implementación determinista o un flujo de trabajo fijo con pasos asistidos por modelos puede satisfacer los requisitos. Elija un enfoque agéntico cuando la evaluación muestre ventajas que justifican su costo adicional, latencia y complejidad operativa. Para obtener instrucciones sobre cómo elegir un enfoque de ejecución, consulte Flujos de trabajo fijos frente a sistemas dirigidos por agente.

Especificar

Utilice el pensamiento de diseño para comprender la necesidad real del usuario antes de elegir qué y cómo automatizar. Colabora con los usuarios, los responsables de negocio y los expertos en la materia para acordar resultados aceptables, restricciones y comportamientos en caso de fallo.

Recopile estos requisitos en un contrato de comportamiento con control de versiones y elabore escenarios de prueba para crear la biblioteca de escenarios. Los equipos de producto e ingeniería revisan los cambios en el comportamiento esperado juntos. Para abordar las preocupaciones sobre la IA responsable y la seguridad, implique a expertos del dominio, especialistas en riesgos y especialistas en seguridad. Asigne versiones tanto al contrato de comportamiento como a la biblioteca de escenarios. Las notas de la versión deben identificar la versión del contrato y de la biblioteca de escenarios que se admite y se ha publicado.

Revise los cambios de los requisitos junto con la hoja de ruta del producto y vuelva a comprobar la implementación respecto a ellos. En el caso de las cargas de trabajo de varios agentes, defina un contrato de un extremo a otro y agregue contratos de traspaso en los que cambian las responsabilidades, los requisitos de evidencia o los permisos.

Para el agente de revisión del producto, acuerde con el equipo de estándares qué envíos cumplen los requisitos para la aprobación automática, cuándo se requiere revisión humana y cómo gestionar una política no disponible o una cola de revisión.

En el diagrama siguiente se muestra cómo el contrato de comportamiento y la biblioteca de escenarios guían la implementación y la verificación. Use la biblioteca de escenarios para guiar la curación del conjunto de datos dorado y definir criterios de evaluación. Informe de los resultados por escenario, incluido el número de casos probados, para que una puntuación general no oculte las brechas. Los resultados revisados de la evaluación y la producción pueden dar lugar a actualizaciones de la biblioteca de escenarios o del contrato de comportamiento.

Para conocer las técnicas de descubrimiento, consulta Realizar investigación con usuarios y compartir los conocimientos obtenidos.

Tierra

Ground rige el conocimiento y las pruebas que se transmiten al agente, incluida la información recuperada, las respuestas de las herramientas, las reglas de negocio y la memoria. Prepara la información pertinente y autorizada para cada tarea a la vez que conserva su origen y autoridad. La procedencia, la vigencia y la confidencialidad son algunos atributos clave que deben representarse correctamente.

Para preparar la información gobernada para el agente:

• Seleccione fuentes acreditadas y asigne responsables para mantenerlas.
• Identifique los requisitos de acceso y conserve los metadatos de permisos y confidencialidad para la responsabilidad de control .
• Prepare la información en un formato que el agente pueda usar sin perder su significado empresarial, origen o versión.

Durante el diseño, asegúrese de que las fuentes puedan proporcionar las pruebas que requiere el contrato de comportamiento. En el caso del agente de revisión de productos, vincula cada evaluación al texto completo de la presentación, su revisión y la versión de la directiva aplicable. Si faltan pruebas necesarias o no son accesibles, resuelva el problema de datos o de acceso, restrinja el ámbito o aplace la funcionalidad afectada.

En tiempo de ejecución, la capa de recuperación notifica si una búsqueda devolvió datos, no encontró ninguna coincidencia o falló. La aplicación utiliza ese estado, junto con los metadatos de las pruebas, para determinar si debe continuar o seguir la respuesta del contrato en caso de pruebas insuficientes.

Mantén las definiciones y reglas de negocio en activos controlados por la carga de trabajo y con control de versiones, independientes de las indicaciones y los modelos. Utilice un contrato de datos o un modelo semántico para definir la estructura y el significado de la información intercambiada con otros agentes y sistemas.

En la tabla siguiente se distinguen las definiciones de negocio de la evidencia de una solicitud específica. Una plataforma de modelo semántico o ontología puede ayudar a organizar estas definiciones cuando los agentes y sistemas necesitan relaciones y conceptos empresariales compartidos.

Para ver ejemplos de implementación, consulta Enlace de datos de ontología de Fabric (versión preliminar) y Modelos semánticos de Power BI.

Puede establecer un motor de reglas o un flujo de trabajo para aplicar reglas de negocio en código determinista antes de pasar los resultados al agente. Pruebe estas reglas de forma repetible en los casos revisados por dominio para comprobar que la implementación coincide con la directiva prevista y reducir la incertidumbre de la implementación.

Al ensamblar el contexto, identifica la fuente y la autoridad de las directrices de negocio, la evidencia actual y la memoria. Defina lo que el agente puede escribir en la memoria y durante cuánto tiempo conservarlo. La memoria no debe anular los registros oficiales y no puede tratarse de la misma forma que las indicaciones o las instrucciones.

En el diagrama siguiente se muestra cómo preparar y combinar conocimientos, evidencias y memoria para el agente.

Control

El control protege la carga de trabajo mediante la autenticación, la autorización y la gobernanza en tiempo de ejecución. Establece quién puede acceder al sistema, qué puede hacer cada solicitante y cada agente, y qué acciones requieren aprobación. Aplique estas decisiones en el código de aplicación y los servicios conectados, no en el modelo.

Siga los procedimientos recomendados de seguridad y lleve a cabo el modelado de amenazas para decidir qué medidas de seguridad en tiempo de ejecución se van a implementar. Un diagrama de flujo de datos (DFD) muestra cómo se mueve la información entre personas que llaman, agentes, herramientas y almacenes de datos, incluido dónde cruza los límites de confianza. Usa ese análisis para determinar dónde aplicar comprobaciones de acceso, restringir el uso compartido de datos y requerir aprobaciones.

Estos límites de confianza forman parte de tu defensa contra ataques. Por ejemplo, las respuestas de herramientas o contenido recuperado pueden contener instrucciones malintencionadas. Las comprobaciones de acceso y los controles de aprobación deben seguir aplicándose si el modelo sigue esas instrucciones. Siga los principios de defensa en profundidad y Confianza cero. Combina estos controles con otras medidas de defensa contra la inyección de indicaciones, en lugar de considerar que una sola medida de seguridad es suficiente.

Autentique las identidades del llamante y del agente y autorice cada acceso a datos y acción de la herramienta según su tarea y el recurso de destino. Aplica el principio del privilegio mínimo y haz cumplir los requisitos de acceso identificados en la responsabilidad de base. Al delegar trabajo, conserva el contexto de autorización del solicitante y las referencias de evidencia, y vuelve a comprobar los permisos en cada traspaso. La delegación no debe expandir la autoridad. Si se deniega el acceso, siga la ruta definida de parada o escalado en lugar de eludir la denegación mediante otra herramienta o agente.

La gobernanza en tiempo de ejecución también hace cumplir las aprobaciones requeridas, los pasos obligatorios del flujo de trabajo y los límites operativos, como los presupuestos y los límites de tasa. Vuelva a intentar solo las operaciones que sean seguras para repetirse. Cuando se alcance un límite, siga el comportamiento de detención o de recambio establecido en el contrato. Estos controles complementan el diseño de resiliencia más amplio de la carga de trabajo.

En el ejemplo del agente de revisión de productos, el acceso se limita al envío asignado, a la directiva aplicable y a las acciones de moderación. El flujo de trabajo de publicación comprueba los permisos, la revisión del envío y la versión de la directiva antes de publicar una revisión aprobada. Mantén los cambios en las directivas y las acciones relacionadas con las cuentas de los clientes fuera de los permisos del agente.

En el diagrama siguiente se muestra cómo se evalúan y registran las acciones propuestas.

Para ver un ejemplo de recuperación, consulta Diseñar una solución segura de inferencia RAG multiinquilino. Para obtener instrucciones sobre identidad y protección por capas, consulte Identidad, acceso y privilegios mínimos y Principios de diseño de seguridad.

Para obtener ejemplos de controles de ejecución implementados a través de la orquestación de flujos de trabajo, consulte Patrones multiagente orientados al flujo de trabajo.

Verificar

Verificar combina comprobaciones de casos individuales con una evaluación a nivel de conjunto de datos en el bucle interno del desarrollador.

Comprobación de un único caso

Durante la implementación, ejecute o reproduzca un caso de prueba mediante respuestas grabadas o simuladas. Inspeccione el seguimiento de ejecución para comparar la evidencia, las llamadas a herramientas, las decisiones de control y el resultado con el contrato de comportamiento y el escenario. Usa los resultados para depurar y refinar la implementación.

Evaluaciones

Ejecute evaluaciones en un conjunto de datos con versiones para medir el comportamiento en escenarios admitidos. Defina las métricas y los umbrales de aceptación a partir del contrato de comportamiento. En la tabla siguiente se describen los escenarios y las medidas asociadas para el agente de revisión del producto.

Comparar el candidato y la línea base mediante el mismo conjunto de datos y versiones del evaluador. Para obtener más información, consulta Configurar y ejecutar la reproducción.

Informe los resultados por escenario para que las puntuaciones agregadas no oculten las regresiones. Repita los casos de prueba para comprobar la coherencia. Defina el número de ejecuciones y criterios de aceptación antes de la evaluación. Registre el contrato de comportamiento, el conjunto de datos, el evaluador y las versiones de umbral con los resultados.

Pruebe los casos de ejecución prolongada y el comportamiento ante fallos en los límites operativos. Defina recuentos de pasos y llamadas a herramientas, pero requiera una ruta de acceso exacta solo cuando el contrato especifique una. En el caso de las cargas de trabajo de varios agentes, pruebe las transferencias, así como los resultados de un extremo a otro.

Ejecute estas comprobaciones junto con pruebas unitarias e de integración. Bloquee las versiones que no superen los umbrales de escenario requeridos. Para obtener orientación sobre el lanzamiento, consulte Lista de comprobación de la ruta de adopción.

Observar

Observe analiza las ejecuciones de producción para identificar el comportamiento correcto, los errores y sus causas. El sistema debe recopilar comentarios de los usuarios para facilitar el análisis. Inicie el análisis con la clasificación de escenarios:

1. Clasifique las ejecuciones grabadas utilizando la tarea y el contexto de ejecución. Haga coincidir cada ejecución con el escenario y las versiones de contrato aplicables. Marcar casos desconocidos o ambiguos para su revisión.

2. Compare el resultado con el comportamiento esperado del escenario y combine esa información con los comentarios del usuario para evaluar el éxito o el fracaso. Deje los casos sin evaluar cuando la evidencia no sea suficiente.

3. Investigue los fallos utilizando trazas y los comentarios de los revisores. Agrupe los hallazgos por causa, como lagunas de conocimiento, fallos de implementación o de dependencias, o requisitos poco claros.

4. Haga que los propietarios de productos, expertos en dominio e ingenieros revisen los resultados y decidan qué cambiar. Valide los resultados esperados antes de agregar casos preparados a la cobertura de regresión. Registre el motivo de cada cambio y compruébalo antes del lanzamiento.

En el ejemplo del agente de revisión del producto, enrutar un envío que contiene información personal a la revisión humana mientras se mantiene sin publicar es un comportamiento correcto. Aprobarlo es un ejemplo de fallo. Una solicitud para admitir revisiones de imágenes identifica, en cambio, un posible cambio de alcance.

Captura los datos de entrada de la tarea, las solicitudes y respuestas de las herramientas, el contenido recuperado suministrado al modelo y los resultados. Conserva las versiones originales, las decisiones de control y los fallos. Vincula los comentarios de los usuarios y revisores a la ejecución y al lanzamiento. Minimiza los datos capturados, aplica límites de acceso y retención, y sigue la guía de preparación de datos de reproducción antes del análisis o la curación del conjunto de datos.

Para ver un ejemplo de cómo vincular los resultados de producción con la evaluación, consulta el ciclo de calidad de la observabilidad de agentes.

Lista de comprobación de la ruta de adopción

Empieza con una implementación mínima viable centrada en un comportamiento relevante de tu carga de trabajo.

La implementación útil más pequeña de ABE no es una plataforma. Se trata de un comportamiento que sea explícito, reproducible, evaluado y controlado. El primer bucle de trabajo está en especificar y comprobar. Evite crear una plataforma amplia antes de que el equipo pueda usar un contrato para evitar, detectar o diagnosticar un problema de comportamiento real.

1. Seleccione una situación limitada y de impacto e identifique sus propietarios de producto e ingeniería e implique a expertos en dominios.
2. Escriba un contrato de comportamiento revisado, incluyendo evidencia y estados de fallo.
3. Define escenarios para casos normales, límite, de evidencia insuficiente y de fallo de dependencias. Genere casos sintéticos a partir de estos escenarios para iniciar las pruebas.
4. Utilice los casos sintéticos para guiar a los expertos en la materia en la recopilación y la selección de casos de carga de trabajo reales para un conjunto de datos dorado independiente.
5. Captura o simula respuestas estables de herramientas y conocimientos para su reproducción.
6. Agregue comprobaciones deterministas y solo los evaluadores basados en juicio necesarios para el contrato.
7. Ejecute los escenarios en la integración continua y bloquee los lanzamientos en caso de errores críticos.
8. Registre suficiente información de ejecuciones de producción para identificar el contrato, la implementación, la ruta de acceso de evidencia y el resultado.
9. Convierte los hallazgos de producción revisados en escenarios de regresión.

Los cambios en las solicitudes, la configuración del modelo y el código de aplicación pueden cambiar el comportamiento del agente. Valide estos cambios antes de usarlos en producción. Registre las versiones que ha probado, la configuración de evaluación y los resultados. Siga los procedimientos de implementación seguros para introducir cambios gradualmente y planear cómo recuperarse si causan problemas. Incluir cambios de configuración en el plan de recuperación.

Parta de esta primera iteración a medida que descubra qué necesita la carga de trabajo. Cuando los agentes y sistemas necesitan definiciones y relaciones empresariales compartidas, un modelo de datos semántico puede proporcionar esa base. Cuando las decisiones siguen reglas de negocio explícitas, un motor de reglas puede aplicar esas reglas fuera del modelo. Mantenga los controles de acceso y la evidencia de ejecución que requiere la carga de trabajo desde el principio y expanda la supervisión y automatización a medida que los riesgos y los resultados de producción lo justifican.

Implementación de ABE en Azure

ABE es independiente de la plataforma. Azure proporciona servicios que puedes utilizar para respaldar sus cinco responsabilidades de ingeniería.

En el diagrama siguiente se asigna cada responsabilidad de ABE a los servicios de Azure que se deben tener en cuenta para la carga de trabajo.

Para cada responsabilidad de ingeniería, combina capacidades de Azure con los contratos, controles y los procesos de revisión que mantiene el equipo.

Antes de elegir cualquier servicio Azure, compruebe que sus características, regiones y API se ajusten a la carga de trabajo. Da prioridad a los servicios disponibles de forma general (GA) y a los controles propios de la aplicación para la aplicación obligatoria y las comprobaciones de lanzamiento. Algunas de las características mencionadas en las secciones siguientes son características en versión preliminar y es posible que no sean adecuadas para la carga de trabajo.

Especificar en Azure

Mantén los contratos, los escenarios, los límites operativos y las configuraciones de reproducción en tu repositorio Git existente, por ejemplo, Azure Repos o GitHub. Sigue las responsabilidades de revisión compartidas cuando un cambio afecte al comportamiento esperado. Utilice la revisión de ingeniería para el mantenimiento técnico.

Base en Azure

Conecta el agente a las fuentes autorizadas que hayas identificado para la responsabilidad básica. En el caso del agente de reseñas de productos, empieza por las API de la aplicación existentes en el sitio web para recuperar las reseñas enviadas y la directiva actualmente aprobada.

Cuando necesites realizar búsquedas en varias fuentes de conocimiento, plantéate utilizar la búsqueda por agente de Búsqueda de Azure AI. Puede devolver contenido de fundamentación con referencias de origen opcionales y un registro de actividad. Mida el costo y la latencia del enfoque de recuperación que seleccione.

Si los datos empresariales ya están en Microsoft Fabric, la herramienta Fabric IQ puede conectar agentes de Microsoft Foundry a modelos semánticos y elementos de ontología. La integración y la capacidad ontológica se encuentran en fase de vista previa. Compruebe cómo se autentica la conexión, los datos a los que puede acceder y si los datos pueden dejar el límite de cumplimiento Azure.

Versione las definiciones semánticas por separado de la implementación del agente y registre sus versiones con la evidencia de prueba. Integración de Git de Fabric admite elementos de ontología en versión preliminar.

Controla y ejecuta en Azure

Puede ejecutar agentes de prompt y agentes hospedados personalizados en Foundry Agent Service. Para otros requisitos de tiempo de ejecución o implementación, considere AKS, Azure Container Apps o Azure App Service. Consulte Elección de un servicio de proceso de Azure para comparar opciones. Implemente las reglas de autorización, aprobación y ejecución en la aplicación y los servicios conectados.

Para los agentes de Foundry, utiliza identidades de agente de Microsoft Entra para las conexiones MCP y de agente a agente compatibles. Cuando el agente actúe en nombre de un usuario, comprueba tanto la autoridad del usuario como la del agente. Antes del lanzamiento, compruebe la identidad y los permisos que usará el agente en tiempo de ejecución.

Azure API Management puede controlar los puntos de conexión de MCP compartidos mediante directivas de autenticación, límites de velocidad y cuotas. Utiliza el middleware de Agent Framework para añadir comprobaciones propias de la aplicación para las herramientas de función que ejecuta el marco. Para las herramientas que se ejecutan fuera de ese límite, aplique la autorización y la directiva obligatorias en una puerta de enlace o en un servicio posterior.

Cuando una acción requiera confirmación humana, utilice la aprobación de herramientas de función. Si las aprobaciones de flujo de trabajo deben sobrevivir a un reinicio, configure el almacenamiento de punto de control persistente y restaure el estado de aprobación pendiente antes de permitir la ejecución. En el caso de las herramientas que cambian de estado, valide las entradas y agregue medidas de seguridad de idempoencia en el ejecutor de acciones. Orquestación de versiones y configuración de control con la implementación.

Prompt Shields en Seguridad del contenido de Azure AI puede detectar intentos de inyección de prompts en mensajes de usuario y documentos de grounding. Combine estas comprobaciones con la autorización. Defina cómo responde la carga de trabajo al contenido bloqueado en el contrato de comportamiento y pruebe esa respuesta.

Para el agente de revisión de productos, se concede acceso de lectura a los envíos asignados y a la directiva actual. El acceso de escritura está restringido a las operaciones de moderación que aprueban un envío o lo enrutan para la revisión humana. Las comprobaciones de versiones de envío y de política se aplican en el flujo de trabajo de publicación.

Verificar en Azure

Puede almacenar casos de reproducción preparados y resultados de pruebas en Azure Blob Storage. Haga referencia a versiones específicas del conjunto de datos en las configuraciones de reproducción y vincule los casos derivados de producción a sus ejecuciones de origen. Restrinja el acceso a los casos de reserva protegidos y a las pruebas de producción conservadas. Siga las instrucciones de arquitectura de Blob Storage para el acceso basado en identidades, la protección de datos y la retención.

Mediante el uso de conjuntos de datos de evaluación de Foundry, puede puntuar las respuestas completadas o enviar entradas a un agente para generar y evaluar nuevas respuestas. Para la reproducción controlada, configure los adaptadores de dependencia antes de invocar al agente. Publique conjuntos de datos como copias de ejecución de su biblioteca de escenarios regulados y aplique las mismas restricciones de acceso a los casos de reserva.

Utiliza comprobaciones determinísticas para los criterios con valores de referencia o reglas explícitos, y utiliza evaluadores basados en modelos para los criterios basados en el criterio. Los evaluadores personalizados de Foundry admiten ambos enfoques, así como puntos de conexión de puntuación externos.

Para el agente de revisión del producto, una comprobación basada en código puede comparar la decisión estructurada con la decisión esperada del equipo de estándares. Un evaluador basado en modelos puede valorar si la explicación y la regla de directiva citada respaldan esa decisión, a partir del texto enviado. Los evaluadores de rúbricas y los evaluadores personalizados están en versión preliminar.

Comprueba la compatibilidad de la herramienta de evaluación antes de utilizar las puntuaciones en una puerta de control. En el caso de las conversaciones que contienen Búsqueda de Azure AI o llamadas del agente de datos de Fabric, no use los resultados de tool_call_accuracy, tool_input_accuracy, tool_output_utilization, tool_call_success o groundedness. Utilice aserciones de contrato deterministas u otro método de evaluación admitido.

Guarde los resultados y los seguimientos por caso con la configuración que los generó. Aplique umbrales de lanzamiento en la canalización y bloquee el lanzamiento si falla un escenario obligatorio. Usa los mismos casos y versiones del evaluador al comparar implementaciones. Si entrena modelos personalizados en Azure Machine Learning, incluya sus versiones en la configuración.

Observe en Azure

El seguimiento de Foundry usa el recurso de Azure Monitor Application Insights que está conectado al proyecto. Implementa la herramienta y el código de recuperación de tu aplicación para recopilar cualquier evidencia adicional que necesites.

Decida qué contenido necesita grabar. La integración de trazas del lado del cliente de Foundry incluye opciones de configuración para registrar el contenido del mensaje. Compruebe que la instrumentación captura las respuestas de herramientas necesarias y el contenido recuperado junto con los nombres de operación y los tiempos. Minimice o redacte cargas útiles sensibles antes de la exportación de telemetría y conserve solo la evidencia permitida por la directiva de datos.

Considera la posibilidad de utilizar la evaluación de trazas (vista previa) para evaluar las trazas de Application Insights conservadas que cumplan los requisitos de limpieza. Puntúa las interacciones existentes sin volver a ejecutar solicitudes, incluidos los seguimientos de OpenTelemetry admitidos desde agentes externos a Foundry. Utiliza estas puntuaciones para investigar el comportamiento en producción y, a continuación, verifica cualquier cambio de implementación resultante mediante la reproducción y la evaluación antes del lanzamiento. Esta característica está en versión preliminar pública, no tiene ningún contrato de nivel de servicio y no se recomienda para cargas de trabajo de producción. No confíe en ella para la monitorización de producción ni para las decisiones de lanzamiento.

Utiliza consultas de Log Analytics y alertas de Azure Monitor para investigar fallos de comportamiento e incumplimientos de los límites operativos. La vista de detalles del agente de Application Insights, actualmente en versión preliminar, puede ayudarle a investigar ejecuciones individuales. Incorpora los hallazgos revisados y los casos preparados en el siguiente ciclo de cambio y reproducción.

Contributors

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

Autores principales:

• Yang Song | Ingeniero principal de software

Otros colaboradores:

• Chad Kittel | Ingeniero principal de software
• Bryan Ostdiek | Científico de datos principal
• Peter Parker | Ingeniero principal de soluciones, estratega y arquitecto de Azure AI Cloud
• Rama Pyarasani | Director de ingeniería multidisciplinar de despliegue avanzado
• Ronnie Yates | Director general de ingeniería de despliegue avanzado

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

Pasos siguientes

• Agentes de Microsoft Foundry
• Evaluación de los agentes de IA
• Recuperación de agentes en Azure AI Search
• Supervisión de agentes de IA con Application Insights
• Contratos de comportamiento del agente (artículo de investigación)

Recursos relacionados

• Patrones de diseño del agente de IA
• Generación aumentada por recuperación agencial
• Operaciones de aprendizaje automático