El orden habitual es implementar la capacidad, probarla a mano, añadir algún caso de test y, cuando el sistema empieza a fallar en producción, preguntarse cómo sabemos si esto funciona realmente. Yo lo plantearía al revés: antes de construir una capacidad importante, definir qué significa que funcione bien. Un buen sistema de evaluación no sirve solo para ponerle nota al agente; sirve para convertir las expectativas del producto en una especificación ejecutable.

Empieza por definir el éxito

Imaginemos un agente de soporte que puede gestionar reembolsos. Decir que «debe resolver correctamente las solicitudes de reembolso» es demasiado ambiguo para construir nada encima. Hay que separar qué significa «correctamente», porque son propiedades distintas y cada una necesita un evaluador distinto:

  • Resultado: el reembolso correcto termina creado.
  • Política: respeta las reglas de devoluciones.
  • Uso de herramientas: llama a las APIs adecuadas.
  • Seguridad: no reembolsa cantidades no autorizadas.
  • Eficiencia: no hace llamadas innecesarias.
  • Experiencia: explica con claridad qué ha ocurrido.

No existe una única métrica de «calidad del agente», y tratar de fabricarla suele ser el primer error.

Evalúa el estado del mundo, no solo la respuesta

Supongamos que el usuario pide cancelar su vuelo y solicitar el reembolso, y el agente contesta que ha cancelado el vuelo y procesado el reembolso. Si le pedimos a otro LLM que juzgue esa respuesta, lo más probable es que le dé la nota máxima. Pero la pregunta que importa no es cómo suena la respuesta, sino qué pasó de verdad:

booking.status == "cancelled"
refund.status == "created"
refund.amount == expected_amount

Un agente actúa sobre sistemas, así que el resultado debería medirse sobre el estado real del entorno siempre que se pueda, y no sobre lo que el agente afirma haber hecho. Eso elimina de golpe una categoría entera de falsos positivos.

El resultado correcto no significa una buena ejecución

Consideremos dos agentes que consiguen exactamente el mismo resultado. El primero llama a get_order, luego a issue_refund, y termina. El segundo llama a get_customer, recibe un error, busca en search_orders, se equivoca de pedido, reintenta, encuentra el pedido correcto y entonces reembolsa. Los dos acaban con el reembolso bien hecho. Operativamente son sistemas muy distintos: uno cuesta el doble, tarda más y tiene más superficie donde romperse.

Por eso en agentes merece la pena evaluar también la trayectoria observable: qué herramientas usó, con qué argumentos, cuántos pasos necesitó, cuántos errores generó, si entró en bucles, si hizo acciones innecesarias, cuánto costó y cuánto tardó. Lo importante ahí es «observable». No construiría un sistema de evaluación alrededor del razonamiento privado del modelo; desde ingeniería lo útil son las acciones, las llamadas a herramientas, los cambios de estado y sus resultados.

Pero cuidado con exigir una trayectoria exacta

Aquí hay una trampa. Supongamos que el test espera search_customer → get_invoice → issue_refund y una versión nueva del agente descubre que puede hacer get_invoice_by_email → issue_refund, con el mismo resultado y en la mitad de pasos. ¿Debería fallar el test? Casi seguro que no.

Cuanto más capaces son los agentes, más caro sale confundir «ha seguido mi camino esperado» con «ha resuelto el problema». Las restricciones de trayectoria deberían expresar lo que de verdad importa —llamar a issue_refund como máximo una vez, comprobar que el pedido pertenece al usuario, no llamar nunca a delete_customer, no reembolsar por encima del límite— y dejar libre todo lo demás.

No uses un LLM para comprobar algo que puede comprobar el código

Sigue siendo una de las reglas más rentables. Si quieres saber si el agente llamó a search_customer, mira las trazas. Si la respuesta debe cumplir un esquema, valídalo. Si una fecha tiene que ser anterior a otra, escribe la aserción. Si una API debe llamarse una sola vez, cuenta las llamadas. Los graders deterministas son rápidos, baratos y reproducibles, y no se despiertan de mal humor.

Los jueces basados en LLM son mucho más útiles cuando la pregunta requiere interpretación de verdad: si la respuesta explica correctamente por qué se rechazó el reembolso, si está respaldada por la información recuperada, si el agente mantuvo la política cuando el usuario intentó convencerlo de saltársela. Ahí sí compensa poner otro modelo.

El juez también necesita evaluación

En cuanto usamos un LLM como grader hemos metido otro sistema probabilístico en el circuito, y ese también se equivoca. Su prompt debería estar versionado, su rúbrica debería ser explícita y sus decisiones deberían compararse periódicamente con juicios humanos. Lo interesante de esa comparación no es la correlación global sino dónde discrepan: si el juez aprueba justo los casos que un humano suspende, una correlación alta no sirve de nada.

Tampoco hace falta fabricar una precisión que no existe. Un 3.7 / 5 aparenta mucho más criterio del que hay detrás. A menudo PASS, FAIL e INSUFFICIENT_EVIDENCE es una representación más honesta y más accionable. Los evals son software, y el software necesita tests.

Capacidad no es lo mismo que fiabilidad

Supongamos que un agente resuelve bien una tarea el 90 % de las veces. Suena razonable. Ahora metámoslo en un flujo empresarial que encadena diez pasos parecidos: si las ejecuciones fueran independientes, la probabilidad de que salgan bien las diez es 0,910, alrededor del 35 %. La independencia es una simplificación —los fallos de un agente suelen estar correlacionados— pero el orden de magnitud es el que importa.

Hay una diferencia grande entre preguntar si el agente puede hacer una tarea y preguntar si la hace de forma consistente. Por eso ejecutaría los casos importantes varias veces: una tanda de cinco intentos con dos fallos cuenta una historia que un único PASS esconde. En sistemas críticos, la varianza también es una métrica.

No simules prompts, simula usuarios

Otra evolución útil es dejar de evaluar pares de prompt y respuesta para evaluar interacciones completas. Un usuario real responde a medias, cambia de opinión, se equivoca, rechaza una opción, aporta información contradictoria, abandona una tarea y vuelve a ella media hora después.

Eso se puede simular con un usuario sintético al otro lado del agente, que a su vez opera sobre un entorno con estado. Alguien pide cambiar su vuelo a París, el agente pregunta la fecha, el usuario dice que el viernes, el agente ofrece dos opciones y entonces el usuario decide que mejor el sábado. Ahí ya estamos evaluando algo parecido a lo que pasa en producción. Benchmarks como τ-bench y τ²-bench popularizaron precisamente este formato, con agente, usuario simulado y herramientas interactuando a lo largo de varios turnos. La trampa: un usuario simulado demasiado cooperativo hace que el agente parezca mejor de lo que es.

Producción debería alimentar los evals

Esta es probablemente la parte más importante del sistema. Imaginemos que un usuario descubre que, cuando un pedido contiene dos productos, el agente reembolsa los dos aunque solo se haya pedido uno. Arreglar el bug no debería ser el final: ese caso debería convertirse inmediatamente en un caso de regresión y ejecutarse en cada cambio relevante a partir de entonces.

El ciclo completo va de producción a trazas, de trazas al descubrimiento del fallo, de ahí a una revisión, a un caso de evaluación, a la suite de regresión, a CI y de vuelta a producción. Eso convierte el dataset de evaluación en algo bastante más valioso que una colección estática de ejemplos: pasa a ser la memoria institucional de los fallos del sistema. Plataformas como Braintrust o LangSmith están construidas alrededor de ese bucle entre trazas de producción, datasets y evals.

Separa capacidad de regresión

No todos los tests sirven para lo mismo. Cuando desarrollas una capacidad nueva quieres casos difíciles, y quieres margen para medir progreso: pasar del 45 % al 67 % es información. Cuando arreglas un bug quieres lo contrario, un caso que debe estar al 100 % y no volver a bajar nunca.

Una suite sana contiene ambas cosas separadas: por un lado casos difíciles, casos límite y adversarios; por otro, un archivo de regresiones nombradas por el incidente que las originó. Mezclarlas lleva a una confusión común, esperar que todos los evals tengan la misma dificultad y sirvan para la misma decisión.

Los benchmarks públicos son útiles, pero no son tu producto

SWE-bench, WebArena, GAIA o τ-bench sirven para medir capacidades generales y comparar sistemas. También envejecen, y 2026 ha dado un ejemplo bastante claro. El 23 de febrero OpenAI dejó de evaluar sus modelos frontera con SWE-bench Verified: cualquier modelo entrenado con datos de GitHub posteriores a junio de 2024 ha visto probablemente parte de los 500 problemas junto con sus soluciones, y al revisar 138 tareas difíciles encontraron fallos materiales en los tests del 59 %. Recomendaron entonces migrar a SWE-bench Pro. El 8 de julio retiraron también esa recomendación tras auditarlo y encontrar que cerca del 30 % de sus 731 tareas públicas estaban rotas.

La lección no es que los benchmarks públicos sean inútiles. Es que los modelos mejoran, los datasets se contaminan, los tests tienen bugs y los equipos acaban optimizando para la métrica. Si estás construyendo un agente de soporte, a tus usuarios no les importa tu posición en un leaderboard: les importa que entienda la factura, respete la política, no pierda información, no ejecute acciones incorrectas y funcione cuando lo necesitan. Tu distribución de producción es el benchmark que cuenta.

Cómo lo montaría

No empezaría eligiendo framework. Empezaría definiendo los criterios de éxito, construyendo entre veinte y cincuenta casos representativos, añadiendo graders deterministas, y solo después metería jueces LLM donde hicieran falta. Luego ejecutaría varios intentos en los casos críticos, instrumentaría producción, convertiría los fallos reales en regresiones y pondría la suite en CI.

Las herramientas vienen después: hoy hay opciones como AgentEvals para evaluar trayectorias, Promptfoo para evals declarativos y pruebas adversarias, o Braintrust y LangSmith para conectar datasets, trazas y experimentos. Pero la herramienta es secundaria. Lo que importa es el bucle.

Los evals son la especificación ejecutable del agente

Los agentes son sistemas probabilísticos y nunca vamos a describir su comportamiento por completo con una colección de tests unitarios. Lo que sí podemos hacer es convertir las propiedades que nos importan en algo observable y verificable de forma continua, y dejar que el ciclo se cierre: expectativas de producto, evals, agente, producción, fallos, evals nuevos.

Un buen sistema de evaluación crece con el producto. Empieza con unos pocos ejemplos escogidos con cuidado, incorpora casos difíciles, después usuarios simulados y después fallos reales. Y cada error importante que llega a producción debería dejar algo detrás: un test que haga más difícil cometer exactamente ese error otra vez. Ese es para mí el objetivo real. No una puntuación bonita, sino no volver a depurar dos veces el mismo fallo sin enterarnos.