La respuesta final puede ocultar una ejecución fallida
Un agente puede devolver la frase correcta después de tomar el camino equivocado. Puede llamar tres veces a la misma herramienta, ignorar una fuente más barata, superar el presupuesto de latencia o crear un efecto secundario duplicado antes de producir una respuesta convincente. Una revisión que solo mira el texto final marca esa ejecución como exitosa.
La guía de Google del 15 de octubre de 2026 para evaluar agentes de IA hace explícito este modo de fallo. Una respuesta educada puede ocultar loops, llamadas repetidas a herramientas, cuotas agotadas y consumo innecesario de tokens. Su recomendación práctica es probar escenarios realistas, registrar trazas completas de ejecución y reemplazar las revisiones puntuales improvisadas por un pipeline repetible.
Es un buen punto de partida, pero una suite de pruebas todavía no es una decisión de release. Un equipo necesita un contrato que diga qué escenarios importan, qué debe ser cierto al final, qué caminos están prohibidos, cuánto trabajo es aceptable y qué regresión detiene el despliegue.
Define el escenario antes que el grader
Empieza con un escenario, no con un prompt. Un prompt es solo una entrada. El escenario debe definir el estado inicial, el objetivo del usuario, las herramientas y los datos disponibles, los sistemas externos que el agente puede modificar y el estado final esperado.
Para un agente de soporte que emite un reembolso, la respuesta esperada no es suficiente. El contrato puede exigir un pedido verificado, un motivo elegible, una sola operación de reembolso, un registro de auditoría y un mensaje de confirmación. También puede prohibir reembolsar un pedido ya reembolsado o modificar la cuenta de otro cliente.
Escribe esas condiciones antes de elegir un grader. De lo contrario, la señal más fácil de medir se convierte en la definición de éxito. Es fácil puntuar una redacción fluida. El negocio depende de que las transiciones de estado sean correctas.
Mantén un conjunto pequeño de casos normales, casos límite y casos adversariales. Incluye fallos de herramientas y datos incompletos. Cuando producción genere un fallo nuevo, redúcelo al escenario más pequeño que todavía reproduzca el mecanismo y añádelo a la suite.
Califica el resultado y el camino
Una ejecución de agente tiene al menos dos superficies de prueba: qué cambió y cómo llegó hasta allí.
Las comprobaciones del resultado deberían ser deterministas siempre que sea posible. Lee la base de datos, inspecciona el archivo generado, valida un esquema, confirma que un identificador de pago existe exactamente una vez o ejecuta las pruebas producidas por un agente de programación. Estas comprobaciones responden si existe el estado solicitado sin pedir a otro modelo que lo juzgue.
El camino necesita una traza. La guía de evaluación de agentes de OpenAI describe una traza como el registro de extremo a extremo de llamadas al modelo, llamadas a herramientas, guardrails y handoffs. Su documentación sobre calificación de trazas recomienda puntuar esos registros para encontrar regresiones en el workflow.
Un grader del camino puede preguntar si el agente eligió la herramienta correcta, pasó argumentos válidos, respetó una aprobación obligatoria, evitó una fuente prohibida y se detuvo al completar la tarea. Esto importa cuando dos ejecuciones alcanzan el mismo resultado visible, pero una expone datos o depende de la suerte.
No exijas una secuencia exacta cuando varias sean válidas. Califica invariantes: ninguna escritura antes de la aprobación, ninguna búsqueda de cliente sin identificador, ninguna segunda llamada de reembolso y ningún handoff después del estado terminal.
Coloca límites duros junto a la calidad
Las puntuaciones de calidad no detectan todos los fallos operativos. Añade presupuestos duros para los recursos y efectos secundarios que pueden perjudicarte.
Los límites útiles incluyen el máximo de llamadas a herramientas, número de reintentos, tiempo transcurrido, tokens de entrada y salida, coste de APIs externas y cantidad de operaciones que cambian estado. Una ejecución que da una buena respuesta después de 40 llamadas innecesarias no equivale a otra que termina después de cuatro. Consume más dinero, tarda más y tiene diez veces más oportunidades de fallar.
Trátalos como puertas separadas, no como ingredientes de un único promedio. Una puntuación alta de calidad no debería compensar un pago duplicado. Una ejecución barata no debería compensar una respuesta incorrecta. Publica solo cuando la ejecución cumpla a la vez los contratos de resultado, camino y presupuesto.
Calibra los graders de modelo con personas
Algunos requisitos no pueden reducirse a código. Una respuesta de investigación puede necesitar distinguir evidencia de inferencia. Una respuesta de soporte puede necesitar claridad sin hacer una promesa que la política no respalda.
La guía de Anthropic sobre evaluaciones de agentes separa los graders en tres grupos: basados en código, basados en modelos y humanos. Los graders de código son rápidos y reproducibles, pero frágiles. Los graders de modelo manejan matices, pero son no deterministas y necesitan calibración. Los revisores humanos siguen siendo la referencia para juicios ambiguos o de alto impacto.
Crea un conjunto de calibración etiquetado a partir de ejemplos reales. Haz que personas lo puntúen con una rúbrica escrita y compara luego el grader de modelo con esas decisiones. Investiga los desacuerdos en lugar de ajustar hasta que el número principal parezca bueno. Repite la calibración cuando cambien el modelo evaluador, la rúbrica o el dominio.
No dejes que el mismo agente apruebe su propio trabajo. La autocrítica puede ayudar a mejorar la ejecución antes de entregarla, pero la evidencia de release debe venir de comprobaciones independientes y, cuando sea necesario, de un grader separado.
Convierte los fallos en la siguiente suite
Los escenarios sintéticos te dan cobertura antes del lanzamiento. Las trazas de producción te muestran dónde estaban equivocadas tus suposiciones.
Muestrea ejecuciones fallidas, éxitos caros, correcciones de usuarios y sesiones que requirieron un handoff humano. Elimina datos personales, conserva el estado relevante y convierte los mecanismos recurrentes en casos de regresión. El bucle de mejora de agentes de OpenAI usa la misma secuencia: las trazas muestran qué ocurrió, el feedback explica qué importó y los evals vuelven reutilizable la lección.
Mantén la muestra de producción separada del conjunto fijo de release. Si cada caso observado pasa directamente al benchmark, los equipos pueden sobreajustar prompts y herramientas a los fallos de ayer. Un conjunto estable de holdout indica si el sistema generaliza más allá de los ejemplos usados durante la iteración.
Haz que la puerta sea versionada y comparativa
Cada resultado debe identificar el modelo, prompt, definiciones de herramientas, política, grader, dataset y revisión de código usados en la ejecución. Sin esas versiones, una puntuación no puede explicar qué cambió.
Compara el candidato con el sistema desplegado actualmente sobre los mismos escenarios. Muestra tasas de éxito por grupo de escenarios, no solo un agregado. Informa por separado los fallos de presupuestos duros. Un release puede mejorar el promedio mientras empeora un workflow pequeño pero crítico.
Define la decisión antes de ejecutar la comparación: ninguna violación nueva de seguridad, ninguna regresión en escenarios críticos y una tolerancia definida para coste o latencia. Así evitas que el equipo mueva el umbral después de ver un resultado decepcionante.
Qué no cambia
Una suite de evaluación solo demuestra comportamiento dentro de los escenarios, entornos y graders que contiene. No demuestra que un agente abierto sea seguro en cualquier situación.
Las trazas también pueden capturar entradas sensibles, salidas de herramientas y artefactos internos de razonamiento. Recoge lo mínimo necesario para el diagnóstico, restringe el acceso, aplica límites de retención y redacta los datos antes de convertir sesiones de producción en pruebas.
Por último, los evals no reemplazan los controles en runtime. Las herramientas con privilegio mínimo, las puertas de aprobación, la idempotencia, los límites de tasa y las rutas de rollback siguen reduciendo el daño de un fallo no previsto.
El estándar práctico es más estrecho y más fuerte: define el éxito como un estado observable, inspecciona el camino que lo produjo, impone límites independientes de recursos, calibra los graders subjetivos y bloquea releases ante regresiones concretas. La puntuación es evidencia. El contrato la vuelve operativa.
Escrito por Dandelion Labs