Prueba de agentes de IA por resultado: verificar el estado en lugar de confiar en las respuestas.
Aprender a evaluar a los agentes de IA que utilizan herramientas revisando el estado final, las huellas de acción y la veracidad, incluyendo tiempos de espera, casos sin acción y la fiabilidad en pruebas repetidas.
Fuentes: Your AI Agent Says “Done.” Did Anything Actually Happen?
Cuando un agente de IA responde “Hecho”, esa frase constituye una afirmación, no un comprobante. Una evaluación que solo considere el mensaje final clasificará erróneamente como exitosa una respuesta basada en ilusiones. Esta guía muestra cómo probar a los agentes que utilizan herramientas en función de lo que realmente cambió en el mundo: cómo definir la finalización del trabajo, qué evidencias examinar, cómo manejar los tiempos de espera y los casos en que el agente no debería hacer nada, y cómo medir la fiabilidad en lugar de una demostración fortuita.
Una respuesta segura no es evidencia
Tomemos una solicitud sencilla dirigida a un asistente de programación: mover una reunión al jueves por la tarde. El asistente responde, de manera educada y sin vacilar, que la reunión ahora está programada para las 3 p.m. Luego se abre el calendario y el evento sigue estando exactamente donde estaba.
También son plausibles otras variaciones: el evento se trasladó a las 3 p.m. en otra zona horaria, o apareció un evento completamente nuevo mientras el original permanecía igual, dejando al usuario con dos opciones. El ejemplo es ficticio, pero el problema de pruebas es muy real: si solo se evalúa el texto producido por el agente, los tres fallos parecen idénticos a un éxito.
El cambio de perspectiva útil es este: para un agente, la respuesta es un informe sobre el trabajo realizado, y un informe puede estar equivocado. El sistema que rodea al modelo, su estructura de soporte, determina si puede actuar de manera fiable en general (hablamos de esa capa en de dónde proviene realmente el comportamiento fiable de los agentes). La evaluación es el paso que confirma si ese sistema realmente cumplió con su función.
Escribe primero el contrato de aceptación
“Mover mi reunión” suena trivial hasta que intentas establecer criterios de aceptación para ello.
En el ejemplo que estamos analizando, supongamos que el usuario ha identificado un único evento, especificado una fecha y zona horaria, y autorizado su actualización. El resultado deseado no es simplemente que exista alguna reunión a las 3 p.m., sino que ese mismo evento comience ahora en la hora solicitada, mantenga su duración y lista de asistentes originales, y que ningún otro evento sea modificado. Si la solicitud es ambigua o el asistente carece de permisos, el comportamiento correcto es preguntar, no adivinar.
Esas reglas corresponden a este producto hipotético. Un producto diferente podría enviar notificaciones, requerir aprobación explícita o tratar a los asistentes de manera distinta. Lo importante es que el contrato esté por escrito. Sin él, un evaluador elogia a un asistente por tomar la iniciativa mientras otro considera esa misma ejecución como un cambio no autorizado, y sus calificaciones se vuelven irrelevantes.
Por lo tanto, cada caso de evaluación debe especificar:
- el estado inicial del entorno;
- la solicitud del usuario;
- las acciones que el agente puede realizar;
- las condiciones que deben cumplirse posteriormente; y
- lo que debe permanecer sin cambios.
Ese último punto es fácil de olvidar. Una buena prueba define tanto el objetivo como los límites que lo rodean.
Tres perspectivas de una sola ejecución
Cada ejecución del agente puede analizarse desde tres perspectivas, y cada una detecta fallos diferentes.
- Salida: el mensaje que vio el usuario. ¿Es preciso y útil, o simplemente oculta el trabajo inconcluso en lugar de abordarlo?
- Traectoria: la secuencia observable de llamadas a herramientas, resultados de las mismas, aprobaciones, intentos repetidos y verificaciones. ¿Elegió el agente el evento correcto, se mantuvo dentro de sus permisos y reaccionó adecuadamente cuando una herramienta falló?
- Resultado final: el estado real del calendario una vez finalizada la tentativa.
La guía de Anthropic para la evaluación de agentes establece la misma separación entre la transcripción y el estado final del entorno, y advierte contra calificar cada solución válida según una secuencia fija de pasos. Ese equilibrio merece ser adoptado: observe cómo se comportó el agente, pero no insista en seguir su ruta preferida a menos que el orden de las operaciones forme realmente parte del contrato.
En concreto, dos agentes podrían leer el calendario mediante operaciones diferentes y llegar aún así al mismo resultado correcto; ambos deberían aprobar la prueba. Por otro lado, omitir una aprobación obligatoria constituye un fallo, incluso si el calendario termina viéndose correcto. El resultado determina si la tarea tuvo éxito, los límites definen si estuvo permitida, y el rastro explica la diferencia entre ambos.
Verifique el mundo a través de un canal independiente
Para verificar la prueba del calendario, lea el evento almacenado a través de una interfaz autorizada que no tenga relación alguna con la respuesta del propio agente. No se permite al agente calificar su propia tarea.
Compare los campos que realmente definen la corrección con el estado esperado:
- el identificador estable del evento;
- las horas de inicio y finalización, así como la zona horaria;
- la lista de asistentes;
- los eventos adyacentes que deberían permanecer sin cambios.
Evite comparar por el título del evento. Dos reuniones pueden compartir un nombre, y una coincidencia en el título confirmará erróneamente la reunión incorrecta.
Esta idea es anterior a los marcos de trabajo para agentes actuales. τ-bench evalúa las conversaciones que involucran el uso de herramientas comparando el estado final de la base de datos con un estado objetivo anotado, mientras que WebArena mide si las tareas se completan funcionalmente dentro de entornos web realistas. Ambos son ejemplos de investigación para calificar lo que ocurrió en lugar de lo que se dijo.
Saber qué promete realmente una señal de éxito
Una respuesta API exitosa es una evidencia útil, pero solo si se conoce qué garantiza. “Aceptado” puede significar que la solicitud fue puesta en cola, no que se aplicó. Un banner de éxito en el navegador puede aparecer antes de que el registro correspondiente se almacene.
En los sistemas asíncronos, decida de antemano cuánto tiempo esperará el verificador y qué estado se considerará resuelto. Si no puede observar el estado en absoluto, registre el resultado como no verificado. No lo considere silenciosamente como aprobado, ni asuma lo contrario. Esa tercera categoría se vuelve esencial tan pronto como las solicitudes comienzan a exceder el tiempo de espera.
El momento más difícil: justo después de un tiempo de espera
Un tiempo de espera no le indica nada sobre si la actualización llegó a destino. Es posible que la solicitud haya fallado antes de llegar al servicio de calendario, o bien podría haber tenido éxito y solo la respuesta se haya perdido en el camino de regreso.
Un agente que reacciona creando una reunión de reemplazo nueva puede dejar al usuario con dos eventos. Eso hace que el comportamiento de recuperación sea un caso de prueba de primera importancia. Una secuencia de recuperación adecuada se ve así:
- Lea nuevamente el evento objetivo.
Si el resultado sigue siendo desconocido, lo más adecuado podría ser detenerse y explicar la incertidumbre al usuario. Una transición clara es mejor que un éxito forzado. Este mismo patrón se aplica en el diseño habitual de servidores; consulte las claves de idempotencia para los endpoints POST de Node.js para conocer el aspecto del servidor.
Evalúe tanto el estado como la redacción. La frase “No pude confirmar la actualización” es veraz incluso si el servicio aplica el cambio un momento después. “No se cambió nada” es una afirmación infundada en exactamente la misma situación. La incertidumbre es un resultado legítimo que el agente debe manejar, no una laguna que deba llenar con certeza.
Asigne el evaluador a la pregunta
Diferentes preguntas merecen diferentes jueces.
- Código determinista para hechos precisos: identificadores, marcas de tiempo, el conjunto de cambios permitidos, la cantidad de eventos duplicados.
- Evaluador basado en modelos con una rúbrica clara para la calidad de la comunicación: ¿el asistente distinguió el trabajo completado del intento de trabajo, y describió los pasos siguientes sin inventar detalles?
La documentación de evaluación de LangSmith trata las reglas de código, la revisión humana y el juicio basado en modelos como opciones distintas. No es necesario utilizar esa plataforma para beneficiarse de mantenerlas separadas.
Un patrón antiétnico merece mención especial: entregarle al segundo modelo la respuesta segura del agente y preguntarle si la tarea parece exitosa. El evaluador se dejará convencer por esa misma seguridad que te engañó a ti. En lugar de eso, proporciona al evaluador las pruebas que realmente requiere la pregunta y permítele responder “pruebas insuficientes”.
Se deben separar los fallos críticos de las puntuaciones de calidad. Una edición no autorizada del calendario no debe quedar diluida por un tono amable o una redacción cuidadosa. Una ficha de puntuación compacta funciona bien: resultado correcto, límites respetados, informe veraz y recuperación adecuada. Indique la latencia y el costo junto a ella, en lugar de combinar todo en un único número opaco.
Incluya casos en los que la respuesta correcta es no hacer nada
Un conjunto básico razonable para el asistente de calendario abarca:
- un reprogramación normal;
- dos eventos que comparten el mismo título;
- una solicitud sin zona horaria;
- un permiso denegado;
- un tiempo de espera del servicio de calendario;
- una actualización que ya se había aplicado antes de que ejecutara el agente;
- una solicitud para redactar un cambio propuesto sin aplicarlo.
Ese último caso te protege de un sesgo sutil. Si cada prueba recompensa realizar cambios externos, terminas seleccionando un agente que actúa con demasiada prisa.
Ejecuta pruebas que muten el estado en cuentas de prueba aisladas o entornos controlados, y reinicia los elementos fijos entre intentos independientes. Una prueba dejada por una ejecución anterior nunca debe hacer que la siguiente parezca exitosa.
Esta lista es un punto de partida, no una muestra estadísticamente suficiente. Amplíala según lo que realmente soliciten tus usuarios, dónde se encuentran los riesgos reales y qué fallos aparecen en la práctica. Elimina los datos personales de los elementos fijos que pretendas reutilizar, y restringe quién puede leer las huellas que contengan datos privados.
Mide la consistencia, no la mejor demostración
Ejecuta cada caso más de una vez, y registra cada intento, incluidos los tiempos de espera y las ejecuciones en las que falló la verificación.
τ-bench introdujo una métrica de pruebas repetidas, pass^k, que determina si un agente tiene éxito en los k intentos realizados, y no solo en al menos uno. Las puntuaciones de modelos que publican son históricas y no deben interpretarse como un ranking de los agentes actuales, pero la lección permanece: “poder tener éxito” y “tener éxito de manera fiable” son propiedades diferentes, y un solo intento exitoso solo indica lo primero.
Un panel de control inicial para productos podría registrar:
- tasa de finalización válida;
- número de acciones no autorizadas;
- afirmaciones de éxito sin soporte;
- escaladas apropiadas;
- latencia;
- costo por finalización válida.
Sé explícito respecto al denominador. ¿Estás contando las solicitudes de los usuarios, los intentos independientes o las reintentos individuales? Los mismos datos pueden generar tasas muy diferentes según la elección realizada.
Lean los números juntos. Un cambio que aumente la tasa de finalización pero también las acciones no autorizadas no constituye una victoria real. Tampoco lo es un agente que evita todo riesgo al rechazar todas las tareas útiles. Compare versiones de los mismos casos con los mismos presupuestos, y publique cuántos casos ejecutó y cuánto variaron los resultados entre las ejecuciones. Un pequeño número de pruebas es insuficiente para justificar una cifra precisa sobre la fiabilidad en producción.
Convierta cada fallo en una prueba de regresión
Cuando un caso falla, primero averigüe qué fue lo que realmente salió mal: el agente, la herramienta, el entorno o el sistema de evaluación. Una prueba defectuosa no es evidencia de que el modelo esté dañado.
Luego, capture un caso reproducible mínimo y versione todo lo que pueda influir en él: la tarea, el estado esperado, el evaluador, la configuración del modelo, las instrucciones y los contratos de la herramienta. Cuando alguno de estos cambie, ejecute nuevamente los casos afectados. Fijar el estado esperado es tan importante como fijar el modelo; nuestro artículo sobre fijación de versiones en suites de evaluación de LLM profundiza en este tema.
Las pruebas offline y la monitorización en tiempo real responden a preguntas diferentes. La evaluación previa cuidadosamente seleccionada le indica si un cambio es seguro para su implementación; evaluar interacciones reales le muestra qué está yendo mal en el entorno real. La documentación de LangSmith describe ambos enfoques y recomienda incorporar los fallos en producción al conjunto de pruebas.
Para el asistente de calendario, un bucle así podría comenzar con informes de los usuarios sobre eventos duplicados, agregar casos de respuestas perdidas al conjunto de funciones y confirmar que existe una solución de recuperación antes de su implementación a mayor escala.
Puntos clave
- Trate “Hecho” como algo que debe verificarse, nunca como prueba definitiva.
- Escriba el contrato según cada caso: estado inicial, solicitud, acciones permitidas, estado final requerido y lo que no debe cambiar.
- Evalúe el resultado, aplique los límites establecidos y utilice el seguimiento para explicar las diferencias.
- Verifique a través de una ruta de lectura independiente y autorizada, y mantenga “no verificado” como resultado honesto.
- Pruebe explícitamente los tiempos de espera, los casos de duplicados y aquellos sin acción; son aquí donde fallan los agentes confiados.
- Excluya las fallas críticas de las puntuaciones de calidad promedio, y mida la fiabilidad en los intentos repetidos.
Lecturas relacionadas
- Por qué los agentes de IA en producción fallan silenciosamente y cómo detectar respuestas incorrectas — Un estudio de caso con doce agentes de IA en producción muestra por qué una salida incorrecta pero plausible es el verdadero modo de fallo, y qué reglas de diseño mantuvieron útiles a los que sobrevivieron.
- Verificando qué hacen los agentes de IA: permisos, puertas de aprobación y niveles de riesgo — Entienda por qué los agentes autónomos necesitan una mentalidad de verificación, y cómo el principio de menor privilegio, la aprobación humana y la autonomía basada en riesgos evitan que sus errores se propaguen.