Evaluación de agentes de IA: cómo probar las habilidades de un agente

La evaluación de agentes de IA verifica si un agente puede completar un trabajo específico de forma confiable y segura antes de su uso normal. Para evaluar las habilidades de un agente, comienza con tareas reales, prueba las decisiones y los efectos secundarios que importan, y usa un criterio de lanzamiento acorde al riesgo. Una respuesta pulida en una sola ejecución es evidencia útil, pero no es suficiente para confiarle a un agente los mensajes de clientes, los cambios de datos o el dinero.

Resumen: Comienza con 8 a 12 casos extraídos del trabajo real. Compara la configuración prevista del agente con una línea base sin la habilidad. Usa código para verificar hechos como archivos, destinatarios, permisos y argumentos de herramientas. Usa un juez calibrado solo para las partes que requieren criterio humano. Bloquea el lanzamiento cuando se cruce un límite crítico.

Decisión	Qué probar	Evidencia a conservar
¿Debe actuar el agente?	Casos positivos, negativos, parafraseados y de colisión	Selección, tasa de abstención y de activación falsa
¿Completó el trabajo?	Hechos requeridos, archivos, llamadas a herramientas y estado final	Aserciones y artefactos de salida
¿Siguió un camino seguro?	Permisos, aprobaciones, reintentos y efectos secundarios	Traza de herramientas y violaciones de límites
¿Puede un equipo confiar en él?	Ejecuciones repetidas, costo y latencia	Tasa de aprobación, costo por éxito y latencia p95

La pregunta útil es simple: ¿puede este agente realizar este trabajo bajo las condiciones que enfrentará en la realidad? El Manual de Evaluación de Habilidades de Agentes contiene una versión copiable del proceso descrito a continuación.

Una evaluación de agente de IA debe respaldar una decisión de lanzamiento

Toda evaluación comienza con una decisión. Nombra el trabajo, la persona afectada por un resultado deficiente, la evidencia requerida para un lanzamiento y el límite que finaliza la ejecución. Eso evita que un equipo recopile indicaciones genéricas que nunca resuelven un debate.

Un agente que redacta una respuesta a una solicitud de cliente necesita más que prosa fluida. Puede necesitar identificar al cliente correcto, citar material de referencia aprobado, crear un borrador en el hilo correcto y detenerse antes de enviar. Cada requisito necesita su propia verificación.

Aquí es donde resulta útil la discusión de YC Paper Club sobre sistemas de agentes con automejora. Más herramientas y contexto pueden hacer que un agente sea más capaz. La evaluación le indica a un equipo si esas incorporaciones mejoran el trabajo o añaden una nueva vía de fallo.

Construye un marco de evaluación de agentes a partir del trabajo real

Comienza con los casos que tienen un costo visible cuando salen mal. Para cada decisión importante, incluye un positivo evidente, una paráfrasis, un negativo difícil y una colisión en la que otro flujo de trabajo parezca plausible. Agrega inyección de fallos cuando el agente pueda invocar una herramienta o cambiar el estado.

Caso	Qué demuestra	Ejemplo
Positivo	Se activa el flujo de trabajo correcto	Una solicitud que coincide directamente con la tarea documentada
Paráfrasis	La variación normal de redacción no rompe el enrutamiento	La misma solicitud expresada con vocabulario diferente
Negativo difícil	El flujo de trabajo se mantiene fuera de tareas no relacionadas	Una solicitud similar que pertenece a otro responsable
Colisión	Las instrucciones en competencia se resuelven bien	Podrían aplicarse dos habilidades del agente, pero una debe prevalecer
Inyección de fallos	El agente se recupera sin cruzar un límite	Un archivo faltante, un permiso denegado, un tiempo de espera agotado o una carga útil inválida

Mantén un conjunto de lanzamiento separado de los ejemplos usados para ajustar las instrucciones o el evaluador. Un caso aún puede detectar regresiones después de haber influido en la implementación, pero ya no te dice mucho sobre trabajo nuevo.

Ejecuta la misma tarea importante con la configuración prevista, sin ninguna habilidad, y con una habilidad plausible pero incorrecta cuando ese control esté disponible. Compara el resultado, la ruta de herramientas, el costo, la latencia y las infracciones críticas. El artículo de SWE-Skills-Bench es un recordatorio útil de que las instrucciones adicionales pueden ayudar en algunas tareas y perjudicar en otras. Los controles emparejados hacen visible el efecto en tu propio entorno.

Evalúa el resultado, la trayectoria y los permisos por separado

La respuesta final es solo una parte del resultado. En el caso de agentes que usan herramientas, registra la secuencia de llamadas a herramientas, argumentos, aprobaciones, reintentos y cambios de estado. Una respuesta que parece correcta puede aún así tener un destinatario equivocado, una afirmación sin respaldo, una aprobación omitida o una acción destructiva innecesaria detrás.

Usa código para los hechos que una máquina puede verificar:

1. Un archivo requerido existe y se valida contra su esquema.
2. Un destinatario pertenece a una lista permitida y una respuesta se dirige al mensaje humano correcto.
3. Un cambio en la base de datos se puso en staging, se revisó o se rechazó según lo requerido.
4. La herramienta esperada recibió los argumentos previstos.
5. Un efecto secundario prohibido no ocurrió.

Luego usa un evaluador semántico para las preguntas restantes, como la fidelidad a los hechos, la exhaustividad o si la respuesta atendió la tarea. Dale al evaluador una rúbrica acotada, una respuesta de referencia o material fuente cuando sea posible, y una opción de abstención. Compara una muestra de sus decisiones con etiquetas humanas e inspecciona los desacuerdos. La guía de Anthropic sobre evaluaciones de agentes plantea el mismo punto práctico: haz que el entorno sea observable y elige el evaluador más simple que pueda valorar el comportamiento.

Los permisos merecen sus propios casos. Prueba el acceso denegado, la autoridad ambigua, la inyección de instrucciones en material recuperado, los reintentos tras un tiempo de espera y las solicitudes que combinan trabajo seguro con una acción insegura. El análisis de ToxicSkills ofrece ejemplos de por qué las instrucciones y el acceso a herramientas de terceros necesitan una revisión explícita.

Métricas de evaluación de agentes de IA que ayudan a un equipo a decidir

Una sola puntuación rara vez describe bien a un agente. Ajusta la medición a la decisión de lanzamiento.

Si el riesgo es	Métrica	Una pregunta útil para el lanzamiento
Enrutamiento incorrecto	Precisión, exhaustividad y tasa de activación falsa	¿El agente actúa solo cuando debe?
Resultado incorrecto	Tasa de éxito emparejada y fallos de aserción	¿Mejora el trabajo real respecto a la línea base?
Acción insegura	Violaciones críticas y omisiones de aprobación	¿Alguna ejecución cruzó un límite que impide el lanzamiento?
Comportamiento inconsistente	Tasa de éxito en ejecuciones repetidas	¿Funciona de forma repetida bajo las mismas condiciones?
Economía inviable	Costo por ejecución exitosa y latencia p95	¿Puede el equipo permitirse esta fiabilidad con el volumen habitual?

Para una tarea estocástica, un solo resultado exitoso es una prueba débil. Repite los casos representativos e informa las condiciones: modelo, versiones de herramientas, fixtures, versión del evaluador y número de ejecuciones. Si las cinco ejecuciones deben aprobarse antes de un lanzamiento, calcula e informa ese estándar de forma explícita. Esto hace posibles comparaciones posteriores cuando cambian el modelo, las herramientas o las instrucciones.

Un ejemplo práctico: un agente de respuesta a clientes que solo genera borradores

Considera un agente que prepara una respuesta cuando un cliente pide ayuda. La decisión de lanzamiento es acotada: puede crear un borrador revisable usando material aprobado. No puede enviar un mensaje, modificar registros de clientes ni usar una fuente no verificada.

El conjunto inicial podría incluir una solicitud de soporte real, una solicitud parafraseada, una consulta de ventas similar que debería enrutarse a otro lugar, una solicitud con un enlace no confiable y un fallo de API simulado. Las verificaciones deterministas confirman el hilo correcto, los enlaces de origen, el estado de borrador y la ausencia de un evento de envío. Una persona o un evaluador semántico calibrado verifica si el borrador responde la pregunta de manera fiel.

Ese conjunto es lo bastante pequeño como para ejecutarlo antes de cada cambio relevante. Cuando ocurre un incidente, investígalo primero y luego añade la clase de fallo faltante al conjunto de evaluación. El objetivo es un registro útil de lo que el agente puede hacer y de cómo un equipo sabe que hizo bien el trabajo.

Incorpora el conjunto al ciclo de entrega

Ejecuta pruebas de humo antes de que se aplique un cambio pequeño. Ejecuta el conjunto emparejado antes del lanzamiento. Revisa la desviación cuando cambies modelos, herramientas, permisos o material de origen. Los incidentes de producción son una entrada valiosa una vez que se entiende el comportamiento subyacente.

El contexto duradero ayuda aquí porque los casos, los artefactos de referencia, las decisiones y las correcciones pueden permanecer conectados. Cómo mantienen los equipos actualizada la memoria de los agentes de IA explica la parte de ese trabajo relacionada con la memoria compartida. El tutorial de Codex muestra cómo las instrucciones, las habilidades y la verificación pueden residir en un repositorio. Una configuración de Second Brain AI puede proporcionar los archivos duraderos y los ciclos de revisión detrás del flujo de trabajo.

Preguntas frecuentes

¿Qué es la evaluación de agentes de IA?

La evaluación de agentes de IA comprueba si un agente puede completar una tarea definida de forma fiable y segura. Combina casos realistas, verificaciones de resultados, verificaciones de efectos secundarios, ejecuciones repetidas y una decisión de lanzamiento acorde con el riesgo.

¿Cuántos casos debe incluir una evaluación de agentes?

Comienza con 8 a 12 casos precisos vinculados a decisiones y fallos importantes. Añade casos cuando un lanzamiento, un incidente o una traza de usuario revele una clase de fallo ausente. Un conjunto más pequeño con controles claros es más útil que una lista larga de prompts genéricos.

¿Debe toda evaluación de agentes de IA usar un evaluador LLM?

No. Usa aserciones deterministas para archivos, esquemas, destinatarios, argumentos de herramientas, efectos secundarios y aprobaciones. Reserva los jueces basados en modelos para cuestiones semánticas y luego calíbralos con etiquetas humanas.

¿Cuál es la mejor primera métrica para un agente de IA?

Usa la métrica que se corresponda con la decisión de lanzamiento. El enrutamiento puede necesitar precisión y exhaustividad (recall). Un flujo de trabajo con efectos secundarios puede requerir cero infracciones críticas. Una tarea variable puede necesitar la tasa de éxito en ejecuciones repetidas, el costo por éxito y un presupuesto de latencia.

¿Cuándo puede un equipo lanzar un agente sin un benchmark completo?

Se puede lanzar cuando un conjunto de pruebas acorde al riesgo muestra el comportamiento requerido y protege los límites críticos. Los asistentes internos de bajo riesgo pueden comenzar con menos casos. Los agentes que envían mensajes, modifican datos, manejan dinero o acceden a secretos necesitan controles más sólidos antes de un uso habitual.

Empieza con un flujo de trabajo

Elige un flujo de trabajo con un costo de fallo visible. Define la decisión de lanzamiento, crea las familias de casos iniciales, añade una referencia sin habilidad (no-skill baseline) y haz que los hechos importantes sean deterministas. Luego usa el Agent Skill Evals Manual para ampliar el conjunto de pruebas con verificaciones de trayectoria, calibración de jueces, fiabilidad, costo y seguridad.