GuiaBuenas practicas6 min

Evals para agentes: por que una demo bonita no prueba nada

Como medir si un agente funciona de verdad con tareas reales, criterios de exito, regresiones y revision humana.

OpenAIClaude
Mesa de laboratorio con casos de prueba y trazas para evaluar agentes

Una demo sirve para explicar una idea. No sirve para probar que un agente esta listo para usuarios reales. El problema es que las demos se hacen con casos favorables: preguntas limpias, datos completos y ninguna interrupcion rara.

Un agente de produccion vive en el mundo contrario: mensajes incompletos, usuarios molestos, APIs lentas, datos contradictorios, archivos pesados y decisiones que no debe tomar solo.

Que es un eval de agente

Un eval es un conjunto repetible de pruebas que mide si el agente hace lo correcto bajo condiciones conocidas. Para agentes, no basta con revisar la respuesta final. Tambien hay que revisar:

Mapa visual del flujo operativo para Evals para agentes: por que una demo bonita no prueba nada

  • Que herramientas llamo.
  • En que orden las llamo.
  • Si uso datos permitidos.
  • Si escalo cuando debia escalar.
  • Si invento informacion.
  • Si dejo evidencia suficiente para auditar.

Un eval bueno se parece a una prueba de producto, no a una pregunta suelta.

Como armar el primer set

Empieza con 30 casos reales:

Mapa visual de verificacion y riesgos para Evals para agentes: por que una demo bonita no prueba nada

  1. Diez conversaciones faciles.
  2. Diez conversaciones ambiguas.
  3. Diez conversaciones peligrosas o sensibles.

Para cada caso define el resultado esperado. No escribas solamente "debe responder bien". Especifica:

  • Accion correcta.
  • Herramienta permitida.
  • Datos que debe citar.
  • Frases que no debe decir.
  • Momento en que debe pasar a humano.

Metricas utiles

Mide por tarea, no por impresiones subjetivas:

  • Tasa de resolucion sin humano.
  • Tasa de escalacion correcta.
  • Alucinaciones detectadas.
  • Acciones bloqueadas correctamente.
  • Latencia media y p95.
  • Costo por conversacion resuelta.

La metrica mas peligrosa es "se siente mejor". Puede ser verdad, pero no te protege de regresiones.

Evals antes de deploy

Cada cambio de prompt, modelo, herramienta o memoria deberia correr contra el mismo set. Si el agente mejora en una tarea y empeora en otra, necesitas verlo antes del usuario.

Tambien conviene guardar ejemplos fallidos. Esos fallos se convierten en pruebas permanentes para que el agente no vuelva a cometer el mismo error.

Regla practica

Si no puedes contestar "que porcentaje de mis casos reales resuelve el agente sin errores criticos", todavia no tienes un agente listo. Tienes una demo.

La buena noticia es que no necesitas un sistema enorme para empezar. Una tabla con casos, criterios y resultados ya te pone por delante de la mayoria de implementaciones improvisadas.