Evaluar un agente IA: pruebas, métricas y benchmarks

Para evaluar un agente IA, compruebe el resultado obtenido, las acciones ejecutadas y los recursos consumidos en un conjunto de tareas representativo. Repita las pruebas en un entorno controlado y contraste esas mediciones con los incidentes y los resultados observados en producción. Los benchmarks públicos sirven para seleccionar candidatos; su protocolo debe determinar si el agente se adapta al uso previsto y a sus restricciones.

Definir qué significa completar una tarea con éxito

Una respuesta convincente no demuestra que la tarea esté terminada. Un agente puede anunciar una actualización sin haber guardado el archivo, modificar la carpeta equivocada o completar la tarea después de ejecutar una acción prohibida. Por eso, la evaluación de modelos debe complementarse con una evaluación del sistema que actúa.

Redacte los criterios de éxito antes de iniciar las pruebas. Deben especificar el estado inicial, la solicitud, los permisos, el resultado esperado y las condiciones de parada. Una tarea ambigua suele generar desacuerdos entre evaluadores.

Piense en un escenario ficticio: preparar un recordatorio de pago de una factura pendiente. Completarlo con éxito significa localizar la factura correcta, comprobar su estado, utilizar el destinatario autorizado y guardar un borrador. Enviar el mensaje supone un fallo si las instrucciones exigen una aprobación previa.

Distinga tres aspectos:

El resultado: ¿el estado final responde a lo solicitado?
El comportamiento: ¿se han respetado las restricciones y los permisos?
El servicio prestado: ¿son aceptables el tiempo, el costo y el trabajo de corrección?

Defina también cuándo es correcto abstenerse de actuar. Pedir una aclaración ante datos de contacto contradictorios puede ser un acierto. Inventar el dato que falta para terminar antes debe penalizarse.

Las fichas del directorio de agentes IA ayudan a identificar las capacidades anunciadas; los criterios de éxito convierten esas capacidades en condiciones que se pueden verificar.

Crear un conjunto de pruebas representativo

Parta de las tareas que realmente tiene previsto realizar, con sus documentos, herramientas y dificultades. Las solicitudes preparadas para no presentar ninguna complicación ofrecen una imagen demasiado favorable del funcionamiento cotidiano. Reúna ejemplos cuyo uso esté autorizado, elimine los datos sensibles innecesarios y pida a una persona que conozca la actividad que valide los resultados esperados.

Distribuya los casos entre solicitudes habituales, situaciones límite y fallos controlados. Incluya información incompleta, documentos contradictorios, permisos insuficientes, herramientas no disponibles y solicitudes que excedan el ámbito autorizado. Si se trata de un agente documental, varíe también los idiomas, los formatos y la antigüedad de las fuentes.

Añada variantes similares: otro destinatario, una fecha distinta o un documento casi idéntico. Permiten comprobar que el agente utiliza los datos del caso en lugar de reproducir una respuesta memorizada.

Separe los conjuntos según su función:

Conjunto	Función	Acceso durante los ajustes	Evolución
Desarrollo	Entender y corregir los errores	Disponible para consulta	Ampliación frecuente
Validación	Comparar las configuraciones	Uso limitado	Renovación controlada
Prueba reservada	Estimar el rendimiento final	Se mantiene aparte	Versión fija para la comparación
Regresión	Preservar los comportamientos ya validados	Disponible para consulta	Se añaden casos tras validar una corrección

Evite los duplicados entre conjuntos, incluidas las variantes de un mismo documento. Separar los casos por cliente, expediente o período puede proteger mejor el conjunto de prueba que una distribución aleatoria.

Por último, mantenga dos perspectivas: un rendimiento ponderado según los usos observados y resultados desglosados por categoría. Los casos poco frecuentes pero graves deben seguir siendo visibles, aunque apenas influyan en el promedio.

Describir cada caso y controlar el entorno

La ficha de cada prueba debe permitir que otra persona entienda por qué una ejecución se considera correcta o fallida. Incluya un identificador estable, la categoría, las entradas, los datos de referencia, las acciones permitidas, las acciones prohibidas y las comprobaciones finales.

Especifique qué variantes son aceptables. Dos borradores pueden expresar correctamente la misma solicitud con palabras distintas. En cambio, un identificador de factura o un importe requieren una comprobación exacta.

El agente no debe poder acceder al resultado esperado. Guarde los scripts de evaluación y las respuestas de referencia fuera de su espacio de trabajo, con permisos de acceso separados.

Antes de cada ejecución, restablezca los archivos, la base de datos, las cuentas de prueba y la memoria. De lo contrario, una ejecución podría beneficiarse de los cambios que dejó la anterior. Documente también el reloj del sistema y las dependencias externas cuando influyan en la tarea.

Dos tipos de entorno responden a necesidades diferentes:

Un entorno fijo facilita la comparación: documentos archivados, respuestas de herramientas grabadas y datos restaurados.
Un entorno conectado pone de manifiesto las dificultades reales: páginas modificadas, latencia de red, autenticación e interrupciones del servicio.

Mantenga ambos. El primero ayuda a identificar la causa de una regresión; el segundo mide la capacidad del sistema para funcionar pese a los problemas de sus dependencias. Una avería de una herramienta sigue siendo un fallo del servicio prestado, pero debe clasificarse por separado para orientar la corrección.

Medir calidad, fiabilidad, costo y tiempo

La tasa de éxito es necesaria, pero no basta. Debe acompañarse del número de tareas, el número de ejecuciones y la regla de evaluación. Una tasa calculada únicamente sobre las pruebas que llegaron a terminar oculta las interrupciones y los casos que superaron el presupuesto.

Utilice un panel en el que cada indicador sirva para tomar una decisión:

Dimensión	Medida	Qué revela	Limitación que debe vigilar
Resultado	Proporción de tareas completadas con éxito	Utilidad final	Oculta los resultados parcialmente correctos
Seguridad	Acciones prohibidas e intentos de ejecutarlas	Respeto del ámbito autorizado	Una tasa baja puede ocultar un incidente grave
Intervención	Tareas que requieren que una persona retome el trabajo	Carga operativa	Distinguir la aprobación prevista de la intervención para resolver un fallo
Costo	Gasto total por tarea completada con éxito	Viabilidad económica	Incluir los fallos y los reintentos
Tiempo	Mediana y percentiles altos	Experiencia de uso y saturación	El promedio oculta las tareas bloqueadas
Estabilidad	Éxitos en ejecuciones repetidas	Consistencia	Depende del protocolo de repetición

El costo por tarea completada con éxito se calcula dividiendo todos los gastos del lote entre las tareas que cumplen su definición de éxito. Incluya las llamadas a los modelos, las herramientas de pago y la infraestructura pertinente. Presente por separado el costo de la evaluación y el del funcionamiento; mida también el tiempo de trabajo humano necesario.

Distinga el tiempo hasta la primera respuesta útil del tiempo hasta alcanzar un estado final verificado. Al presentar un percentil, indique cómo debe interpretarse: el percentil 95 representa el tiempo por debajo del cual se sitúan aproximadamente el 95 % de las observaciones.

Una puntuación parcial ayuda a investigar los fallos, pero no debe dar por válida una operación que incumpla una condición obligatoria. Una acción prohibida puede seguir siendo motivo de rechazo, por buena que sea la calidad del resto.

Elegir y verificar los métodos de evaluación

Utilice comprobaciones programáticas cuando el resultado sea observable: existencia de un archivo, valor guardado, pruebas de software, destinatario o ausencia de escrituras fuera del ámbito permitido. Compruebe el estado final del entorno, además de lo que declara el agente.

Para un resumen o una explicación, una rúbrica editorial puede valorar la exactitud, la cobertura, la justificación y el cumplimiento de la solicitud. Cada criterio debe describir un comportamiento observable. Una valoración general de la fluidez favorece las respuestas bien redactadas, aunque estén incompletas.

La publicación de Anthropic Demystifying evals for AI agents distingue entre verificadores programáticos, evaluadores basados en modelos y evaluadores humanos. Entre otras cuestiones, destaca la necesidad de calibrar los evaluadores automáticos con valoraciones humanas.

Para realizar esa calibración, pida que se evalúe una muestra sin revelar qué configuración se está analizando. Examine los desacuerdos, aclare la rúbrica y mida después los falsos positivos: los fallos que el evaluador acepta como éxitos. Compruebe también los falsos negativos, que podrían llevarle a descartar una configuración útil.

Un evaluador automático debe tratar las salidas como datos no fiables. Una respuesta evaluada puede contener un intento de inyección de prompt dirigido al propio evaluador.

Por último, ponga a prueba las comprobaciones: un borrador dirigido al destinatario equivocado debe fallar, y una reformulación aceptable debe aprobarse. Un evaluador defectuoso puede hacer que se elija una configuración menos fiable.

Repetir las pruebas y comparar en igualdad de condiciones

Un agente puede completar una tarea con éxito y fallar al volver a ejecutarla. Repita las pruebas restaurando el estado inicial y fije el número de repeticiones antes de observar los resultados. Una temperatura baja no garantiza, por sí sola, que las ejecuciones sean idénticas.

Distinga entre éxito en el primer intento, éxito tras reintentos y consistencia entre repeticiones. pass@k mide la posibilidad de obtener al menos un éxito entre varios intentos; no describe la fiabilidad de una ejecución habitual. Indique siempre si está contando intentos observados o utilizando un estimador.

Los reintentos deben reproducir el funcionamiento previsto. Si una persona tiene que reconocer la respuesta correcta entre varias propuestas, su trabajo y los medios de validación forman parte del protocolo.

Compare las configuraciones con los mismos casos y los mismos límites de tiempo, costo y acciones. Alterne el orden de ejecución cuando la carga de los servicios pueda variar. Examine las tareas en las que cada configuración mejora o empeora, además de la diferencia global.

Presente una estimación de la incertidumbre adecuada a la muestra. Si utiliza bootstrap, vuelva a muestrear las tareas manteniendo agrupadas sus repeticiones. Las variantes de un mismo expediente no son necesariamente observaciones independientes.

Si la diferencia sigue siendo incierta, concluya que la prueba no permite elegir entre los candidatos. Amplíe la cobertura de las situaciones decisivas en lugar de seguir repitiendo pruebas hasta obtener un resultado favorable.

Interpretar los benchmarks públicos sin extrapolar

Un benchmark mide un sistema bajo unas condiciones concretas: modelo, instrucciones, herramientas, entorno y presupuesto. Dos entradas que utilizan el mismo modelo pueden corresponder a agentes diferentes. El artículo Cómo interpretar las clasificaciones de modelos explica esta lectura; el comparador de benchmarks ofrece otro punto de partida.

Algunas familias de benchmarks ayudan a orientar la selección:

Benchmark	Ámbito evaluado	Resultado examinado	Limitación para su uso
SWE-bench	Resolución de problemas de software en repositorios	Validación del parche mediante las pruebas del protocolo	No abarca todo el mantenimiento de software
Terminal-Bench	Tareas realizadas en un terminal	Éxito en el entorno previsto	Depende de las herramientas y los presupuestos asignados
OSWorld	Uso de aplicaciones y de un ordenador	Estado final evaluado en el entorno	Sensible a las aplicaciones y las interfaces
τ-bench	Interacción entre agente, herramientas y usuario	Cumplimiento de las reglas del escenario	También depende de la simulación del usuario

Consulte los protocolos oficiales de SWE-bench, Terminal-Bench y OSWorld para identificar la edición, las tareas y los métodos de evaluación.

Las correcciones de un benchmark pueden cambiar las puntuaciones. A fecha del 24 de octubre de 2026, las notas de versión oficiales de τ-bench indican expresamente que los resultados de la versión 2.0 no son comparables con los de la rama 1.x.

Archive, por tanto, la referencia exacta del protocolo utilizado. Compruebe también si las tareas son públicas, si están disponibles las secuencias de ejecución y si el resultado procede de los autores del agente o de una evaluación independiente.

La selección del mejor intento, los ajustes repetidos sobre las tareas públicas y su posible presencia en los datos de entrenamiento limitan la interpretación. Una clasificación ayuda a decidir qué probar; no proporciona la tasa de éxito que obtendrá en su actividad.

Poner a prueba los permisos y los efectos no deseados

Evalúe las acciones a las que el agente tiene acceso real, incluidas las que se realizan a través de un servidor MCP. Una comprobación limitada a la respuesta final no revela una lectura prohibida ni un envío realizado durante la ejecución.

Prepare escenarios adversos plausibles: un documento que contiene una instrucción falsa, una solicitud que excede los permisos, un resultado engañoso de una herramienta o un error que incita a saltarse una aprobación. Defina el comportamiento esperado: ignorar el contenido, pedir confirmación, rechazar la solicitud o derivarla a una persona responsable.

Compruebe por separado el comportamiento del modelo y la eficacia de los controles técnicos. Si el agente intenta realizar una eliminación prohibida y el entorno la bloquea, la protección funciona; el comportamiento sigue necesitando una corrección. Esta distinción evita atribuir al modelo el éxito de una barrera externa.

Las pruebas deben utilizar cuentas específicas, destinatarios de prueba y operaciones reversibles. La guía Cómo proteger un agente IA detalla las medidas de contención.

Fije los criterios que impiden aprobar el sistema antes de las pruebas. Una filtración de datos no debe quedar diluida en un promedio de calidad de redacción. Documente también los límites de cobertura: superar los escenarios adversos conocidos no demuestra que no existan vulnerabilidades desconocidas.

Convertir las trazas de producción en evidencia

La evaluación fuera de producción permite controlar situaciones seleccionadas. La producción revela solicitudes nuevas, cambios en los documentos y fallos de las dependencias. Ambas deben alimentar el mismo ciclo de medición.

Asocie cada tarea con una traza que permita recuperar la configuración, las llamadas a herramientas, los errores, las aprobaciones humanas, los costos y el resultado verificado. Registre los eventos necesarios para investigar los fallos sin recopilar sistemáticamente todos los contenidos.

Langfuse describe la evaluación de trazas y los experimentos con conjuntos de datos en su documentación oficial. Este tipo de instrumentación facilita las comparaciones, pero los criterios propios de la actividad debe definirlos usted.

Tome muestras tanto de los éxitos aparentes como de los fallos. La ausencia de quejas no demuestra que un documento se haya procesado correctamente. Contraste las valoraciones de los usuarios con comprobaciones independientes.

Supervise los resultados por tipo de tarea, idioma, herramienta y configuración. Un promedio estable puede ocultar un deterioro en una categoría minoritaria. Mantenga también alertas operativas inmediatas para los casos que superen el presupuesto o impliquen acciones prohibidas.

Cada incidente confirmado debe convertirse en un caso de regresión reproducible y sin datos sensibles innecesarios. A la vez, actualice un conjunto de casos recientes para seguir la evolución de los usos. La guía Supervisar un agente en producción profundiza en las trazas y las alertas.

Organizar la decisión de despliegue

Antes de una campaña de evaluación, establezca el protocolo y las responsabilidades. Un procedimiento reproducible puede seguir este orden:

Definir el alcance y obtener la validación de los criterios de éxito.
Versionar los datos, el agente, las herramientas y los métodos de evaluación.
Medir una referencia: el procedimiento actual, una automatización fija o la configuración existente.
Ejecutar los candidatos con las mismas tareas y analizar las regresiones.
Decidir según umbrales establecidos antes de conocer los resultados.
Desplegar de forma gradual, con supervisión y posibilidad de volver a la configuración anterior.

Conserve un informe que separe los resultados medidos, las incertidumbres y las situaciones no cubiertas. Asigne un responsable a cada fallo significativo según su origen: datos, herramienta, instrucciones, permisos o modelo. Sin esa asignación, los ajustes pueden limitarse a trasladar el problema.

Si compara en paralelo la configuración anterior y la nueva con solicitudes reales, impida que la segunda produzca efectos externos. Una operación de la actividad no debe ejecutarse dos veces para poder medirla.

Antes de ampliar el despliegue, compruebe lo siguiente:

Los resultados se verifican con independencia de lo que declara el agente.
Los fallos, los reintentos y las intervenciones se incluyen en el balance.
Los permisos y los incidentes graves tienen criterios específicos.
Las comparaciones utilizan protocolos idénticos y versionados.
Las trazas permiten investigar y volver a la configuración anterior.

Así, la decisión puede revisarse a partir de evidencia: tareas completadas, restricciones respetadas, costos asumibles y limitaciones documentadas.

Páginas relacionadas

Preguntas frecuentes

¿Cuántas pruebas se necesitan para evaluar un agente IA?

No hay una cantidad que sirva para todos los casos. Empiece por las situaciones que puedan cambiar la decisión de despliegue y amplíe el conjunto con los incidentes y las solicitudes que observe. Un grupo reducido de casos bien definidos permite tomar mejores decisiones que una colección extensa con resultados ambiguos.

¿Se pueden comparar dos agentes que utilizan modelos diferentes?

Sí, si compara los sistemas completos para un mismo uso y con las mismas restricciones. La comparación permite elegir una solución, pero no atribuir la diferencia únicamente al modelo. Para aislar su efecto, mantenga las mismas herramientas, instrucciones y límites de recursos.

¿Puede un modelo evaluador sustituir a los evaluadores humanos?

Puede encargarse de parte de las comprobaciones repetitivas después de calibrarlo. Mantenga la revisión humana de los desacuerdos, los casos sensibles y una muestra de las decisiones automáticas. Un evaluador que parece coherente puede cometer los mismos errores que el sistema evaluado.

¿Basta con una buena puntuación pública para poner un agente en producción?

No: las tareas, los permisos y los datos del benchmark pueden diferir mucho de los de su actividad. La puntuación ayuda a seleccionar candidatos. La decisión de despliegue debe basarse en sus propias pruebas y en un piloto supervisado.

¿Hay que guardar todas las conversaciones para medir la calidad?

A menudo basta con conservar eventos estructurados, resultados de comprobaciones y fragmentos de los que se hayan eliminado los datos sensibles. Defina qué necesita para investigar los fallos antes de recopilar contenidos completos. Los datos utilizados para evaluar el sistema también deben tener un plazo de conservación definido.

Evaluar un agente IA: conjuntos de pruebas, métricas, benchmarks públicos y seguimiento en producción