A medida que los agentes de IA pasan de prototipos experimentales a aplicaciones del mundo real, la capacidad para entender su comportamiento, monitorear su rendimiento y evaluar sistemáticamente sus resultados se vuelve importante.
Después de completar esta lección, sabrás cómo/entenderás:
El objetivo es equiparte con el conocimiento para transformar tus agentes “caja negra” en sistemas transparentes, manejables y confiables.
Nota: Es importante desplegar Agentes de IA que sean seguros y confiables. Consulta también la lección Construyendo Agentes de IA Confiables.
Las herramientas de observabilidad como Langfuse o Microsoft Foundry usualmente representan las ejecuciones de agentes como rastros y spans.
Sin observabilidad, un agente de IA puede sentirse como una “caja negra”: su estado interno y razonamiento son opacos, dificultando diagnosticar problemas u optimizar el rendimiento. Con observabilidad, los agentes se vuelven “cajas de cristal”, ofreciendo transparencia vital para generar confianza y asegurar que operen como se espera.
La transición de agentes de IA a entornos de producción introduce un nuevo conjunto de desafíos y requisitos. La observabilidad ya no es un “lujo”, sino una capacidad crítica:
Para monitorear y entender el comportamiento del agente, se debe rastrear una variedad de métricas y señales. Aunque las métricas específicas pueden variar según el propósito del agente, algunas son universalmente importantes.
Aquí están algunas de las métricas más comunes que las herramientas de observabilidad monitorean:
Latencia: ¿Qué tan rápido responde el agente? Los tiempos de espera largos afectan negativamente la experiencia del usuario. Debes medir la latencia para tareas y pasos individuales rastreando ejecuciones del agente. Por ejemplo, un agente que tarda 20 segundos en realizar todas las llamadas a modelos podría acelerarse usando un modelo más rápido o ejecutando llamadas a modelos en paralelo.
Costos: ¿Cuál es el costo por ejecución del agente? Los agentes de IA dependen de llamadas a LLM que se facturan por token o a API externas. El uso frecuente de herramientas o múltiples prompts puede incrementar rápidamente los costos. Por ejemplo, si un agente llama a un LLM cinco veces para una mejora marginal en la calidad, debes evaluar si el costo está justificado o si puedes reducir la cantidad de llamadas o usar un modelo más barato. La monitorización en tiempo real también puede ayudar a identificar picos inesperados (por ejemplo, errores que causan bucles excesivos en la API).
Errores en Solicitudes: ¿Cuántas solicitudes falló el agente? Esto puede incluir errores de API o llamadas fallidas a herramientas. Para hacer tu agente más robusto frente a estos en producción, puedes entonces configurar mecanismos de respaldo o reintentos. Por ejemplo, si el proveedor LLM A está caído, cambias al proveedor LLM B como respaldo.
Retroalimentación de Usuarios: Implementar evaluaciones directas de usuarios proporciona información valiosa. Esto puede incluir calificaciones explícitas (👍pulgar arriba/👎abajo, ⭐1-5 estrellas) o comentarios textuales. Retroalimentación negativa consistente debe alertarte, ya que es señal de que el agente no funciona como se espera.
Retroalimentación Implícita del Usuario: Los comportamientos de los usuarios proporcionan retroalimentación indirecta incluso sin calificaciones explícitas. Esto puede incluir reformulación inmediata de preguntas, consultas repetidas o clic en un botón de reintento. Por ejemplo, si ves que los usuarios preguntan repetidamente lo mismo, es señal de que el agente no funciona como se espera.
Precisión: ¿Con qué frecuencia el agente produce salidas correctas o deseables? Las definiciones de precisión varían (por ejemplo, corrección de resolución de problemas, precisión en recuperación de información, satisfacción del usuario). El primer paso es definir qué significa éxito para tu agente. Puedes rastrear precisión mediante verificaciones automatizadas, puntuaciones de evaluación o etiquetas de tarea completada. Por ejemplo, marcar rastros como “exitoso” o “fallido”.
Métricas de Evaluación Automatizada: También puedes configurar evaluaciones automáticas. Por ejemplo, puedes usar un LLM para puntuar la salida del agente, ej. si es útil, precisa o no. También existen varias bibliotecas de código abierto que te ayudan a puntuar diferentes aspectos del agente. Por ejemplo, RAGAS para agentes RAG o LLM Guard para detectar lenguaje dañino o inyección de prompts.
En la práctica, una combinación de estas métricas brinda la mejor cobertura del estado de salud de un agente de IA. En el notebook de ejemplo de este capítulo, te mostraremos cómo se ven estas métricas en ejemplos reales, pero primero aprenderemos cómo luce un flujo típico de evaluación.
Para recolectar datos de rastreo, necesitarás instrumentar tu código. El objetivo es instrumentar el código del agente para emitir rastros y métricas que puedan ser capturados, procesados y visualizados por una plataforma de observabilidad.
OpenTelemetry (OTel): OpenTelemetry se ha establecido como un estándar industrial para la observabilidad de LLM. Proporciona un conjunto de APIs, SDKs y herramientas para generar, recopilar y exportar datos telemétricos.
Existen muchas bibliotecas de instrumentación que envuelven frameworks de agentes existentes y facilitan exportar spans OpenTelemetry a una herramienta de observabilidad. Microsoft Agent Framework se integra nativamente con OpenTelemetry. A continuación hay un ejemplo de instrumentación de un agente MAF:
from agent_framework.observability import get_tracer, get_meter
tracer = get_tracer()
meter = get_meter()
with tracer.start_as_current_span("agent_run"):
# La ejecución del agente se rastrea automáticamente
pass
El notebook de ejemplo en este capítulo demostrará cómo instrumentar tu agente MAF.
Creación Manual de Span: Aunque las bibliotecas de instrumentación proporcionan una buena base, a menudo hay casos donde se necesita información más detallada o personalizada. Puedes crear spans manualmente para añadir lógica de aplicación personalizada. Más importante aún, puedes enriquecer spans creados automática o manualmente con atributos personalizados (también conocidos como etiquetas o metadatos). Estos atributos pueden incluir datos específicos del negocio, cálculos intermedios o cualquier contexto útil para depuración o análisis, como user_id, session_id o model_version.
Ejemplo de creación manual de rastros y spans con el Langfuse Python SDK:
from langfuse import get_client
langfuse = get_client()
span = langfuse.start_span(name="my-span")
span.end()
La observabilidad nos da métricas, pero la evaluación es el proceso de analizar esos datos (y realizar pruebas) para determinar qué tan bien se está desempeñando un agente de IA y cómo puede mejorarse. En otras palabras, una vez que tienes esos rastros y métricas, ¿cómo los usas para juzgar al agente y tomar decisiones?
La evaluación regular es importante porque los agentes de IA a menudo son no deterministas y pueden evolucionar (a través de actualizaciones o cambios en el comportamiento del modelo): sin evaluación, no sabrías si tu “agente inteligente” realmente cumple bien su función o si ha regresado.
Existen dos categorías de evaluaciones para agentes de IA: evaluación en línea y evaluación fuera de línea. Ambas son valiosas y se complementan. Normalmente comenzamos con evaluación fuera de línea, ya que es el paso mínimo necesario antes de desplegar cualquier agente.

Esta implica evaluar el agente en un entorno controlado, típicamente usando conjuntos de datos de prueba, no consultas en vivo de usuarios. Usas datasets curados donde sabes cuál es la salida esperada o el comportamiento correcto, y luego ejecutas tu agente sobre estos.
Por ejemplo, si construiste un agente para resolver problemas matemáticos, podrías tener un dataset de prueba de 100 problemas con respuestas conocidas. La evaluación fuera de línea a menudo se realiza durante el desarrollo (y puede ser parte de pipelines CI/CD) para verificar mejoras o proteger contra regresiones. La ventaja es que es repetible y obtienes métricas claras de precisión porque tienes la verdad de base. También puedes simular consultas de usuario y medir las respuestas del agente contra respuestas ideales o usar métricas automáticas como se describió arriba.
El reto clave con la evaluación fuera de línea es asegurar que tu dataset de prueba sea completo y se mantenga relevante: el agente podría desempeñarse bien en un conjunto fijo, pero encontrar consultas muy diferentes en producción. Por lo tanto, debes mantener los conjuntos de prueba actualizados con nuevos casos límite y ejemplos que reflejen escenarios reales. Una mezcla de casos pequeños de “prueba rápida” y conjuntos de evaluación más grandes es útil: pequeños para chequeos rápidos y grandes para métricas de rendimiento amplias.

Esto se refiere a evaluar el agente en un entorno real y en vivo, es decir, durante el uso real en producción. La evaluación en línea implica monitorear el desempeño del agente en interacciones reales con usuarios y analizar resultados continuamente.
Por ejemplo, podrías rastrear tasas de éxito, puntuaciones de satisfacción del usuario u otras métricas en tráfico en vivo. La ventaja de la evaluación en línea es que captura cosas que podrías no anticipar en un laboratorio: puedes observar deriva del modelo a lo largo del tiempo (si la efectividad del agente decae al cambiar los patrones de entrada) y detectar consultas o situaciones inesperadas que no estaban en tus datos de prueba. Proporciona una imagen verdadera de cómo se comporta el agente en el entorno real.
La evaluación en línea a menudo implica recopilar retroalimentación implícita y explícita de usuarios, como se discutió, y posiblemente ejecutar pruebas sombra o pruebas A/B (donde una nueva versión del agente corre paralelamente para comparar con la antigua). El reto es que puede ser difícil obtener etiquetas o puntuaciones confiables para interacciones en vivo: podrías depender de la retroalimentación del usuario o métricas posteriores (como si el usuario hizo clic en el resultado).
Las evaluaciones en línea y fuera de línea no se excluyen mutuamente; son altamente complementarias. Las ideas del monitoreo en línea (p. ej., nuevos tipos de consultas donde el agente se desempeña mal) pueden usarse para mejorar y ampliar datasets de prueba fuera de línea. A la inversa, agentes que funcionan bien en pruebas fuera de línea pueden ser desplegados con mayor confianza y monitoreados en línea.
De hecho, muchos equipos adoptan un ciclo:
evaluar fuera de línea -> desplegar -> monitorear en línea -> recopilar nuevos casos de fallo -> añadir al dataset fuera de línea -> refinar agente -> repetir.
Al desplegar agentes de IA en producción, puedes encontrar varios desafíos. Aquí algunos problemas comunes y sus posibles soluciones:
| Problema | Solución Potencial |
|---|---|
| El Agente de IA no realiza tareas consistentemente | - Refinar el prompt dado al Agente de IA; ser claro en los objetivos. - Identificar dónde dividir las tareas en subtareas y manejarlas por múltiples agentes puede ayudar. |
| El Agente de IA entra en bucles continuos | - Asegurar que tienes términos y condiciones claros de terminación para que el Agente sepa cuándo parar el proceso. - Para tareas complejas que requieren razonamiento y planificación, usar un modelo más grande especializado en tareas de razonamiento. |
| Las llamadas a herramientas del Agente de IA no funcionan bien | - Probar y validar la salida de la herramienta fuera del sistema del agente. - Refinar los parámetros definidos, prompts y nombrado de herramientas. |
| Sistemas Multi-Agente no funcionan consistentemente | - Refinar los prompts dados a cada agente para asegurar que sean específicos y distintos entre ellos. - Construir un sistema jerárquico usando un agente “enrutador” o controlador para determinar cuál agente es el correcto. |
Muchos de estos problemas pueden identificarse más efectivamente con observabilidad en su lugar. Los rastros y métricas que discutimos antes ayudan a localizar exactamente dónde en el flujo de trabajo del agente ocurren los problemas, haciendo la depuración y optimización mucho más eficientes.
Aquí hay algunas estrategias para gestionar los costos de desplegar agentes de IA en producción:
Uso de modelos más pequeños: Los modelos de lenguaje pequeños (SLMs) pueden funcionar bien en ciertos casos de uso agenticos y reducirán significativamente los costos. Como se mencionó anteriormente, construir un sistema de evaluación para determinar y comparar el rendimiento frente a modelos más grandes es la mejor manera de entender qué tan bien funcionará un SLM en su caso de uso. Considere usar SLMs para tareas más simples como clasificación de intenciones o extracción de parámetros, mientras reserva modelos más grandes para razonamientos complejos.
Uso de un modelo enrutador: Una estrategia similar es usar una diversidad de modelos y tamaños. Puede usar un LLM/SLM o función serverless para enrutar las solicitudes según la complejidad al modelo que mejor se adapte. Esto también ayudará a reducir costos al mismo tiempo que asegura el rendimiento en las tareas adecuadas. Por ejemplo, enrute consultas simples a modelos más pequeños y rápidos, y solo use modelos grandes y costosos para tareas de razonamiento complejo.
Almacenamiento en caché de respuestas: Identificar solicitudes y tareas comunes y proporcionar las respuestas antes de que pasen por su sistema agentico es una buena manera de reducir el volumen de solicitudes similares. Incluso puede implementar un flujo para identificar qué tan similar es una solicitud a sus solicitudes en caché usando modelos de IA más básicos. Esta estrategia puede reducir significativamente los costos para preguntas frecuentes o flujos de trabajo comunes.
En el notebook de ejemplo de esta sección, veremos ejemplos de cómo podemos usar herramientas de observabilidad para monitorear y evaluar nuestro agente.
Únete al Microsoft Foundry Discord para reunirte con otros aprendices, asistir a horas de oficina y obtener respuestas a tus preguntas sobre agentes de IA.
Patrón de diseño de metacognición
Aviso legal:
Este documento ha sido traducido utilizando el servicio de traducción automática Co-op Translator. Aunque nos esforzamos por lograr precisión, tenga en cuenta que las traducciones automáticas pueden contener errores o inexactitudes. El documento original en su idioma nativo debe considerarse la fuente autorizada. Para información crítica, se recomienda la traducción profesional realizada por un humano. No nos hacemos responsables de malentendidos o interpretaciones erróneas derivadas del uso de esta traducción.