Una vez lancé un cambio de prompt que mejoró mi agente de soporte un 4% en la métrica que estaba observando y lo empeoró un 30% en su capacidad de cerrar tickets reales. El eval estaba en verde. Los usuarios estaban furiosos. Fue entonces cuando aprendí que la mayoría de los evals de agentes miden lo incorrecto — miden si la salida suena bien, no si el agente hizo lo correcto.
Si estás construyendo agentes y tus evals son un puñado de comprobaciones "¿se ve bien la respuesta?" puntuadas por otro modelo, no tienes evals. Tienes vibraciones con un número pegado. Así es como escribo evals para agentes de IA que realmente detectan regresiones.
Aserta sobre comportamiento, no sobre prosa
La mejora más importante: deja de calificar el texto final y empieza a calificar lo que hizo el agente. ¿Llamó a las herramientas correctas, en un orden razonable, con los argumentos correctos? ¿Modificó los archivos que debía y dejó el resto intacto? Esos son hechos verificables, no opiniones.
Para un agente de código, mi eval no lee el resumen. Comprueba: ¿pasa la suite de pruebas tras la ejecución, tocó el agente solo los archivos dentro del alcance, evitó editar el lockfile? Tres aserciones booleanas. Sin juez LLM en ningún lado. Nunca fallan aleatoriamente y capturan los fallos que importan.
assert run_tests() == 0, "tests fail after agent run"
assert touched_files <= allowed_files, f"out of scope: {touched_files - allowed_files}"
assert "package-lock.json" not in touched_files
Esa última surgió de un incidente real. Un agente seguía regenerando "amablemente" el lockfile y rompiendo el CI. Una aserción, y nunca volvió a ocurrir.
Prueba la trayectoria, no solo el punto final
Los agentes fallan en el medio. La respuesta final puede ser correcta por suerte después de un camino desastroso — seis búsquedas redundantes, una llamada a herramienta con argumentos basura que por casualidad manejó el error con gracia, un desvío del que se recuperó. Si solo compruebas el punto final, eres ciego ante una trayectoria que está a un pequeño cambio de fallar por completo.
Así que registro cada evento y aserto sobre el camino. ¿Llamó a búsqueda antes de responder una pregunta que necesitaba información fresca? ¿Hizo más de dos llamadas a herramientas redundantes? ¿Llegó alguna vez a is_error: true en un resultado de herramienta? Puedes puntuar una trayectoria sin un juez — la mayor parte es contar y hacer coincidencia de patrones sobre el flujo de eventos.
El comportamiento del modelo cambió recientemente, por cierto. Los modelos Opus más nuevos recurren a las herramientas de manera más conservadora. Una aserción de "buscar primero" que pasaba con un modelo anterior puede empezar a fallar no porque el agente empeoró, sino porque ahora responde desde el contexto cuando no debería. Ese es exactamente el tipo de regresión que un eval de trayectoria captura y un eval de salida pasa por alto.
Cuando necesites un juez LLM, fíjalo
Algunas cosas genuinamente necesitan juicio — ¿era el tono correcto, captó el resumen el punto clave, era la explicación realmente correcta? Bien. Usa un juez LLM. Pero trata al juez como código de producción, porque lo es.
Tres reglas que nunca rompo. Una: fija el modelo y la versión del juez. Si tu juez se actualiza silenciosamente, tus puntuaciones cambian y perseguirás una regresión que en realidad es un cambio de juez. Dos: dale al juez un rubric concreto, no "califica esto del 1 al 10." "¿La respuesta cita un archivo y número de línea específicos? sí/no" supera a una puntuación de vibraciones en todo momento. Tres: comprueba el juez contra etiquetas humanas en una muestra. Un juez que nunca has auditado es un generador de números aleatorios con buenas relaciones públicas.
Aquí hay una trampa específica de los modelos actuales. Si le dices al juez "solo marca problemas de alta gravedad" o "sé conservador," los modelos más nuevos lo siguen literalmente — encuentran los bugs, luego se niegan a reportar los que están por debajo de tu umbral. Tu recall medido cae y parece que el agente retrocedió cuando en realidad el juez simplemente se volvió más obediente. Dile al juez que reporte todo con una confianza y gravedad, y filtra aguas abajo. Mueve el filtrado fuera del paso de juicio.
Construye el conjunto de evals a partir de tus fallos
No te sientes a hacer lluvia de ideas sobre casos de prueba. Escribirás los que ya manejas. En cambio, cada vez que un agente la cague en producción, ese escenario exacto se convierte en un caso de eval. El incidente del lockfile, el bucle de ida y vuelta, la vez que respondió desde un contexto obsoleto — cada uno es ahora una prueba de regresión permanente.
Esta es la parte que la gente omite porque no es glamorosa. Pero un conjunto de evals crecido a partir de incidentes reales vale diez de los brainstormeados. Es estructural de una manera que los casos sintéticos nunca lo son, porque cada caso es un bug que realmente te afectó.
Ejecútalos en cada cambio de prompt
El punto completo es el bucle. Cambias un prompt, ejecutas los evals, ves las aserciones de trayectoria antes de hacer el deploy. Mi desastre con el agente de soporte ocurrió porque revisé un par de salidas a ojo y lancé con una corazonada. Si hubiera tenido evals de trayectoria — "¿lo resolvió realmente o solo sonó resuelto?" — la caída del 30% habría sido roja antes de tocar a un solo usuario.
Los evals no son una puerta de calidad que añades al final. Son lo único que separa "creo que este prompt es mejor" de "este prompt es mejor." Uno de esos es ingeniería. El otro es una suposición con bata de laboratorio.
Hazlos crecer a partir de tus cicatrices. Aserta sobre lo que hizo el agente. Fija tu juez. Y nunca, jamás, lances un cambio de prompt basándote en vibraciones.