En este artículo, aprenderá cómo evaluar rigurosamente los agentes de IA examinando su proceso de ejecución completo en lugar de solo sus resultados finales.
Los temas que cubriremos incluyen:
Por qué la evaluación de agentes difiere de la evaluación del modelo de lenguaje tradicional y dónde fallan los agentes en las capas de razonamiento y acción. Cómo calificar agentes con verificaciones deterministas basadas en códigos y jueces basados en modelos, adaptados al tipo de agente que está creando. Cómo dar cuenta del no determinismo utilizando métricas como pass@k y pass^k, y cómo extender la evaluación desde el desarrollo hasta el monitoreo de la producción.
La hoja de ruta para dominar la evaluación de agentes de IA
No perdamos más tiempo.
Introducción
Muchos equipos que crean agentes de IA todavía los evalúan de la misma manera que evalúan modelos de lenguaje grandes: ejecutan algunas tareas, inspeccionan el resultado final y asumen que todo está funcionando. Ese enfoque a menudo pasa por alto los fracasos más importantes. El modelo puede seleccionar una herramienta inapropiada o generar argumentos de herramienta incorrectos, mientras que el sistema agente puede manejar mal las fallas de las herramientas o seguir una secuencia de acciones ineficiente. Evaluar sólo la respuesta final a menudo hace difícil identificar dónde ocurrieron estas fallas.
La evaluación de agentes aborda esta brecha. En lugar de centrarse únicamente en los resultados, examina el proceso de ejecución completo: cómo un agente razona, toma decisiones, utiliza herramientas y se adapta a medida que se desarrolla una tarea. Esto proporciona una imagen más precisa de la confiabilidad, la eficiencia y el rendimiento general, lo que ayuda a los equipos a identificar problemas antes de que lleguen a producción.
Los principios tratados en este artículo forman la base de un enfoque sistemático para medir y mejorar el desempeño de los agentes.
Paso 1: comprender por qué es importante la evaluación del agente
El instinto cuando un agente falla es tratarlo como un problema de aviso: el aviso del sistema debe ser más claro. A veces eso es cierto. Lo más frecuente es que el fallo sea un problema de medición: la evaluación no fue diseñada para detectar lo que se rompió.
Los agentes de IA operan a través de capas y esas capas pueden fallar de forma independiente:
La capa de razonamiento, impulsada por el modelo de lenguaje, maneja la planificación, la descomposición de tareas y la selección de herramientas. La capa de acción, impulsada por llamadas a herramientas y respuestas del sistema externo, maneja la ejecución.
Un agente puede razonar correctamente sobre qué hacer y luego llamar a la herramienta adecuada con argumentos mal formados. Tratar la evaluación del agente como una única verificación de precisión de un extremo a otro pasa por alto ambas superficies de falla.
Capa de razonamiento versus acción
La evaluación útil de agentes se ejecuta en dos ámbitos:
Una tasa de finalización de tareas del 80 % no dice nada sobre si el 20 % de fracaso se debe a una mala planificación, una selección incorrecta de herramientas, argumentos incorrectos o fallas en la infraestructura de herramientas. Los seguimientos a nivel de paso (registros que capturan cada llamada a la herramienta, sus argumentos, su resultado y la decisión posterior del modelo) son los que hacen posible ese diagnóstico. Sin rastros, depurar un fallo de producción es una conjetura.
Paso 2: Definir cómo se ve el éxito de la evaluación del agente
La evaluación es tan buena como sus criterios de éxito. Una tarea de evaluación bien formada es aquella en la que dos expertos en el dominio, trabajando de forma independiente, llegarían al mismo veredicto de aprobación/rechazo.
Comience con especificaciones de tareas inequívocas combinadas con soluciones de referencia: resultados correctos conocidos que aprueban todas las calificaciones. Demuestran que la tarea tiene solución y verifican que la lógica de calificación esté configurada correctamente.
Necesita definir lo siguiente para las evaluaciones antes de ejecutar cualquier calificación:
La tarea: qué entradas recibe el agente, qué se espera que haga y cómo se ve el entorno al entrar. Los criterios de éxito: no sólo la respuesta final, sino también los resultados intermedios que importan: ¿Se llamó a la herramienta adecuada? ¿Se actualizó correctamente el estado? ¿La respuesta se basó en el contexto recuperado? Los casos negativos: las evaluaciones unilaterales crean una optimización unilateral. Conjuntos de datos equilibrados, que cubren cuándo debería ocurrir un comportamiento y cuándo no, evitan que los agentes se activen demasiado o insuficientemente en una capacidad.
Un conjunto de tareas bien especificadas extraídas de fallas de uso reales es un mejor punto de partida que esperar por el conjunto de datos perfecto. Las evaluaciones se vuelven más difíciles de construir cuanto más se espera.
Paso 3: Calificación de la capa de acción del agente con comprobaciones basadas en código
Los calificadores deterministas (código que verifica condiciones específicas sin el juicio del modelo en el ciclo) son la opción más rápida, económica y reproducible en cualquier pila de evaluación de agentes. Para la capa de acción, siempre deben ser el punto de partida:
Verificación de llamada de herramienta: si el agente llamó a la herramienta correcta en la secuencia correcta Validación de argumentos: si las entradas tienen tipos correctos, parámetros requeridos y valores válidos Verificación de resultados: si el entorno termina en el estado esperado Análisis de transcripción: número de turnos, tokens consumidos y latencia
Suelen ser rápidos, objetivos y fáciles de depurar, pero frágiles. Un calificador que busque “código_confirmación”: “CONF-789” perderá una respuesta correcta que formatee los mismos datos de manera diferente.
Paso 4: Calificar el razonamiento del agente y la calidad de los resultados con jueces basados en modelos
Algunas dimensiones de la evaluación de los agentes se resisten a la verificación determinista: calidad del resultado, tono, fidelidad al contexto recuperado, empatía adecuada. Para estos, un modelo de lenguaje utilizado como juez o LLM-as-a-Judge es la herramienta adecuada: flexible y capaz de manejar resultados abiertos, pero introduciendo no determinismo y deriva de calibración que los calificadores basados en código no tienen.
Las siguientes prácticas mantienen confiables los calificadores basados en modelos:
Escribe rúbricas estructuradas. “Evaluar si la respuesta es útil” produce ruido. Una rúbrica que especifica que la respuesta debe abordar la pregunta del usuario, fundamentar las afirmaciones en el contexto recuperado y evitar sugerencias fuera de alcance produce una señal. Califique cada dimensión con un juicio separado y aislado.
Calibre periódicamente según el criterio humano. La precisión del LLM como juez debe compararse con una muestra calificada por expertos en el campo. Cuando aparece divergencia, el problema casi siempre es la rúbrica. Ofrezca al calificador una opción explícita de "No se puede determinar" para evitar juicios forzados en casos ambiguos.
Obtenga crédito parcial para tareas de múltiples componentes. Un agente de soporte que identifica correctamente el problema y verifica al cliente pero no procesa el reembolso es significativamente mejor que uno que falla en el paso uno. El binario pasa/falla oculta dónde el agente realmente está fallando.
Paso 5: hacer coincidir la estrategia de evaluación del agente con el tipo de agente
Las estrategias de calificación se aplican ampliamente, pero el tipo de agente determina qué calificadores tienen más peso y qué modos de falla priorizar.
Los agentes codificadores escriben, prueban y depuran código. El software es en gran medida determinista: ¿se ejecuta el código, se pasan las pruebas, la solución soluciona el problema sin interrumpir la funcionalidad existente? Los puntos de referencia como SWE-bench Verified y Terminal-Bench siguen este enfoque de aprobación/rechazo, complementado con controles de calidad basados en rúbricas para seguridad, legibilidad y manejo de casos extremos.
Los agentes conversacionales interactúan con los usuarios a través de flujos de trabajo de soporte, ventas y capacitación. La calidad de la interacción es parte de lo que se evalúa: no sólo si el ticket se resolvió, sino también si el tono fue apropiado y la resolución se explicó claramente. Esto requiere un modelo de segundo lenguaje que simule al usuario; El banco τ modela exactamente esto: los calificadores evalúan tanto la finalización de la tarea como la calidad de la interacción en cada turno.
Los agentes de investigación recopilan y sintetizan información entre fuentes. Las verificaciones de fundamento verifican que las afirmaciones estén respaldadas por fuentes recuperadas, las verificaciones de cobertura definen lo que debe incluir una buena respuesta y las verificaciones de calidad de las fuentes confirman que el agente consultó material autorizado.
Hacer coincidir la estrategia de evaluación del agente con el tipo de agente
Paso 6: Contabilización del no determinismo en los resultados de la evaluación de agentes
El comportamiento del agente varía entre ejecuciones; la misma tarea, los mismos insumos, el mismo agente pueden producir diferentes selecciones de herramientas, rutas de razonamiento y resultados. Por lo tanto, la evaluación de un solo ensayo puede ser engañosa, ya que oculta una variabilidad que las métricas de precisión simples no logran capturar.
Esta es una consecuencia directa del no determinismo en los sistemas de agentes. Los resultados del modelo estocástico, la latencia de las herramientas, los fallos parciales y la toma de decisiones adaptativa introducen variabilidad entre las ejecuciones. Como resultado, evaluar un agente requiere razonar sobre distribuciones de resultados en lugar de un único seguimiento de ejecución.
Para tener en cuenta esta variabilidad, se utilizan habitualmente métricas como pass@k y pass^k:
pass@k: la probabilidad de que al menos uno de k ensayos independientes tenga éxito, útil cuando son aceptables múltiples intentos pass^k: la probabilidad de que todos los k ensayos tengan éxito, importante cuando cada interacción debe ser confiable
Por ejemplo, un agente con una tasa de éxito en un solo ensayo del 75 por ciento tiene éxito en los tres intentos sólo alrededor del 42 por ciento de las veces, lo que muestra cuán rápidamente se degrada la confiabilidad en ejecuciones repetidas.
pasa@k y pasa^k
La elección entre estas métricas es, en última instancia, una decisión de producto más que puramente técnica. Si sólo se necesita un resultado correcto, pass@1 o pass@k son útiles. Si cada interacción debe tener éxito de manera consistente, pass^k es la medida más significativa.
Paso 7: Separar las evaluaciones de capacidad del agente de los conjuntos de regresión
Las evaluaciones de capacidad están diseñadas para responder una pregunta prospectiva: ¿qué puede hacer este agente que no podía hacer antes? Por eso, deberían comenzar con tasas de aprobación relativamente bajas y centrarse en tareas que aún representan un desafío para el sistema. Cuando una evaluación de capacidad alcanza puntuaciones muy altas (digamos 90 por ciento), a menudo ya no se trata de medir la capacidad, sino simplemente de confirmar la confiabilidad de problemas ya resueltos.
Las evaluaciones de regresión tienen un propósito diferente. Preguntan si el agente todavía puede realizar todo lo que antes podía hacer. Estas pruebas deberían ejecutarse cerca del 100 por ciento y actuar como protección contra regresiones en el desempeño. Cualquier caída significativa en la puntuación es una señal de que algo se ha roto y debe investigarse antes de publicarlo.
Con el tiempo, las evaluaciones de capacidad se vuelven naturalmente más fáciles para el agente. A medida que aumentan las tasas de aprobación y se estabiliza el rendimiento, esas tareas pueden promoverse al conjunto de regresión. Sin embargo, una vez que una suite se satura por completo, se vuelve menos sensible a las mejoras reales, lo que significa que un progreso significativo puede aparecer como ruido en lugar de una señal. Por esta razón, se deben introducir evaluaciones nuevas y más desafiantes antes de que se sature la suite existente, no después.
Paso 8: Ampliar la evaluación del agente al monitoreo de la producción
Las evaluaciones de desarrollo capturan lo que se espera que falle; La producción revela lo que realmente hace. Los usuarios reales introducen entradas, casos extremos y contextos que rara vez aparecen en los conjuntos de pruebas sintéticas, lo que hace que el seguimiento de la producción sea una extensión necesaria de la evaluación.
Un sistema de evaluación completo combina varias señales complementarias:
Método Qué captura Evaluaciones automatizadas Se ejecuta en cada confirmación, cubriendo modos de falla conocidos a escala antes de que los usuarios se vean afectados. Puede generar confianza falsa cuando el uso en el mundo real difiere de la distribución de prueba. Monitoreo de producción Realiza un seguimiento de la latencia, las tasas de error, las fallas de las herramientas y el uso de tokens. Las pruebas sintéticas de problemas de superficies pasan desapercibidas, pero generalmente solo después de que ocurren. Comentarios de los usuarios Destaca los casos en los que el agente parece correcto según las métricas pero no cumple con la intención del usuario. Escaso y autoseleccionado, pero a menudo muy informativo. Revisión manual de transcripciones Proporciona información cualitativa sobre el razonamiento, el uso de herramientas y las rutas de decisión, y ayuda a validar si los calificadores automatizados están midiendo los comportamientos correctos.
Juntas, estas capas forman una visión más completa del desempeño de los agentes en la práctica. Los seguimientos a nivel de paso (que capturan el razonamiento, las llamadas a herramientas, los argumentos, los resultados y las decisiones en cada punto del ciclo) son la infraestructura que hace que todo esto funcione. Herramientas como LangSmith, Arize Phoenix, Braintrust y Langfuse proporcionan marcos de seguimiento y evaluación; Harbor y DeepEval manejan la capa de arnés.
Resumen de los pasos clave de evaluación del agente
Aquí hay una descripción general rápida de los pasos que hemos discutido:
Paso Por qué es importante La evaluación de los agentes como un problema distinto Los agentes fallan en todas las capas de razonamiento y acción. La precisión de un extremo a otro puede ocultar ambos tipos de fallas. Definir el éxito antes de medirlo Las especificaciones claras y los resultados de referencia reducen el ruido y hacen que las métricas de evaluación sean más significativas. Calificadores basados en código para la capa de acción. Las comprobaciones deterministas identifican rápidamente el uso de herramientas, los argumentos y los errores de ejecución. Jueces basados en modelos para el razonamiento y la calidad de los resultados Las calificaciones basadas en LLM capturan cualidades matizadas como la corrección, la fidelidad y el tono. Estrategia de evaluación por tipo de agente Diferentes agentes fallan de diferentes maneras, lo que requiere métodos de evaluación adaptados a cada caso de uso. pass@k y pass^k para no determinismo. Los resultados de una sola ejecución pueden ser engañosos. Las métricas deben reflejar si uno o todos los intentos deben tener éxito. Evaluaciones de capacidad versus evaluaciones de regresión Las evaluaciones de capacidad miden el progreso, mientras que las evaluaciones de regresión protegen el desempeño existente. Ampliar la evaluación a la producción El monitoreo, los comentarios de los usuarios y las revisiones de transcripciones revelan fallas del mundo real que las evaluaciones fuera de línea pueden pasar por alto.
Como siguiente paso, lea la guía Desmitificando evaluaciones para agentes de IA de Anthropic, especialmente la sección Pasando de cero a uno: una hoja de ruta para excelentes evaluaciones para agentes.