Un agente de IA puede dar una demo impresionante y aun así ser un mal sistema de producción.

La razón es simple: una demo suele demostrar que el agente puede completar una tarea. Producción exige evidencia de que puede completarla de forma confiable, repetible, con un costo aceptable, dentro de un tiempo aceptable y sin side effects inseguros.

Eso cambia por completo cómo conviene evaluar agentes.

Una sola respuesta final no basta. Un agente actúa durante varios pasos, llama tools, modifica estado, encuentra fallos parciales y puede llegar al mismo resultado por rutas distintas. Por eso el objeto de evaluación no es únicamente la salida. Es la trayectoria completa.

La guía actual de OpenAI para agent evals enfatiza traces, graders, datasets y ejecuciones repetibles. Anthropic plantea algo similar: evaluar agentes es un problema multi-turn donde importan el transcript, las tool calls, el estado intermedio y el resultado final.

El objetivo práctico es responder cuatro preguntas:

  1. ¿Completó la tarea?
  2. ¿La completa de manera consistente?
  3. ¿Cuánto tiempo y dinero consume?
  4. ¿Qué tipos de fallos produce cuando no tiene éxito?

Empieza con task success, no con ‘qué tan inteligente es el modelo’

No empieces preguntando si el modelo parece inteligente.

Empieza definiendo qué significa éxito dentro del entorno donde opera el agente.

Para un coding agent, éxito puede significar:

  • implementar el comportamiento solicitado;
  • pasar las pruebas relevantes;
  • no romper pruebas existentes;
  • no modificar archivos no relacionados;
  • explicar correctamente el diff final.

Para un agente de soporte, puede significar:

  • resolver el problema del cliente;
  • aplicar la política correcta;
  • modificar correctamente el estado backend;
  • escalar cuando corresponde;
  • no ejecutar acciones no autorizadas.

Para un research agent, puede significar:

  • responder la pregunta real;
  • respaldar afirmaciones con fuentes;
  • usar fuentes relevantes y suficientemente autoritativas;
  • hacer que las citas correspondan a las afirmaciones;
  • no inventar evidencia.

Siempre que sea posible, el evaluador debe verificar el resultado real.

Eso es más fuerte que pedirle a otro modelo que decida si la respuesta ‘se ve bien’.

Evalúa el estado final y la trayectoria por separado

Dos agentes pueden llegar al mismo resultado correcto siguiendo procesos muy distintos.

Uno puede:

  • elegir la tool correcta inmediatamente;
  • hacer una sola llamada válida;
  • verificar el resultado;
  • detenerse.

Otro puede:

  • llamar tres tools irrelevantes;
  • repetir la misma acción fallida;
  • exponer datos innecesarios;
  • terminar por casualidad en el estado correcto.

Si sólo calificas la salida final, ambos pueden pasar.

En producción no son equivalentes.

Una evaluación útil necesita por lo menos dos capas.

Evaluación del outcome

Verifica si el entorno terminó en el estado correcto.

Ejemplos:

  • valores esperados en base de datos;
  • pruebas pasando;
  • ticket en el estado correcto;
  • contenido correcto de archivos;
  • artifact generado correctamente;
  • structured output válido.

Evaluación de la trayectoria

Inspecciona cómo llegó el agente a ese estado.

Preguntas útiles:

  • ¿Eligió las tools correctas?
  • ¿Los argumentos eran válidos?
  • ¿Hizo acciones innecesarias?
  • ¿Respetó permisos?
  • ¿Se recuperó correctamente de errores?
  • ¿Se detuvo cuando la tarea ya estaba completa?
  • ¿Hizo handoff o pidió aprobación en el punto correcto?

La guía de trace grading de OpenAI está diseñada precisamente para este nivel: un trace captura model calls, tool calls, guardrails y handoffs para poder detectar regresiones y fallos de comportamiento.

La confiabilidad exige múltiples trials

El comportamiento de agentes no es determinista.

Una tarea que funciona una vez puede fallar en la siguiente ejecución incluso con la misma entrada.

Por eso una sola corrida exitosa dice muy poco sobre confiabilidad.

Ejecuta varias veces cada tarea importante.

Dos métricas útiles que Anthropic describe son pass@k y pass^k.

pass@k pregunta si al menos uno de k intentos tiene éxito.

Sirve cuando el producto tolera retries o puede generar varios candidatos y seleccionar uno.

pass^k pregunta si todos los k intentos tienen éxito.

Se parece más al requisito de confiabilidad de sistemas customer-facing donde el usuario espera que la misma tarea funcione de forma consistente.

Para agentes de producción, la consistencia suele importar más que el mejor resultado que el sistema puede conseguir ocasionalmente.

Mide costo por tarea exitosa

El costo bruto de tokens no basta.

Supón que el Agente A cuesta $0.08 por ejecución y tiene 60% de éxito. El Agente B cuesta $0.12 y tiene 95% de éxito.

Si miras sólo costo por run, A parece más barato.

Si miras costo por tarea exitosa, la conclusión puede cambiar.

Aplica el mismo principio al uso de tools.

Registra:

  • tokens de entrada y salida;
  • número de turnos del modelo;
  • número de tool calls;
  • APIs externas pagadas;
  • retries;
  • costo de sandbox o compute;
  • costo de revisión humana cuando exista.

Después normaliza esas cifras por tareas realmente completadas.

Un agente ligeramente más caro por turno puede ser operacionalmente más barato si consigue resultados correctos con menos retries y menos intervención humana.

La latencia también es calidad de producto

Los agentes suelen intercambiar latencia por calidad porque planean, llaman tools, observan resultados e iteran.

No midas únicamente tiempo total.

Métricas útiles:

  • tiempo hasta la primera acción útil;
  • latencia del modelo por turno;
  • latencia de tools;
  • número de pasos secuenciales;
  • latencia total de tarea;
  • p50, p95 y p99 de finalización.

La tail latency importa.

Un agente que normalmente tarda ocho segundos pero algunas veces tarda tres minutos puede crear una peor experiencia que uno que consistentemente tarda quince segundos.

Mide contra el entorno real, no sólo con tools mockeadas. Red, rate limits, operaciones de browser, cold starts y APIs externas pueden dominar el tiempo total.

Construye una taxonomía de fallos

Un eval suite útil no sólo produce un score.

Te dice cómo falla el sistema.

Crea categorías explícitas.

Fallos de planificación

El agente elige una estrategia pobre o descompone incorrectamente la tarea.

Fallos de selección de tool

Usa la tool equivocada o no usa una que era necesaria.

Fallos de argumentos

Elige la tool correcta pero envía parámetros inválidos, incompletos o peligrosos.

Fallos de comprensión de estado

Interpreta mal el entorno, datos viejos, una respuesta previa de tool o el estado actual de la tarea.

Fallos de recuperación

Una tool devuelve error y el agente repite a ciegas, entra en loop o abandona una tarea recuperable.

Fallos de terminación

El trabajo ya está correcto, pero el agente sigue actuando e introduce regresiones.

Fallos de permisos

Intenta una acción más allá de la autoridad requerida.

Fallos de comunicación

El trabajo subyacente es correcto, pero la respuesta al usuario representa mal lo ocurrido u omite una limitación importante.

Una vez categorizados los fallos, las mejoras se vuelven mucho más específicas.

Un problema de tool selection puede requerir mejores descripciones. Un problema de recovery puede requerir política explícita de retries. Un problema de permisos puede exigir cambios de arquitectura, no sólo de prompt.

Usa graders deterministas siempre que puedas

LLM-as-a-judge es útil, pero no debería sustituir verificaciones deterministas cuando existe ground truth.

Para coding:

  • ejecuta tests;
  • ejecuta type checks;
  • ejecuta linters;
  • inspecciona archivos modificados;
  • verifica outputs esperados.

Para sistemas transaccionales:

  • inspecciona estado de base de datos;
  • verifica ledger entries;
  • revisa autorización;
  • confirma idempotencia.

Para tareas estructuradas:

  • valida schemas JSON;
  • revisa campos requeridos;
  • compara valores exactos;
  • ejecuta reglas de negocio.

Usa model-based graders para dimensiones realmente semánticas, como calidad de explicación, síntesis de research o calidad conversacional.

Los mejores evals suelen combinar graders deterministas, model-based y humanos.

Construye el dataset desde fallos reales

No armes un eval set compuesto sólo por ejemplos limpios.

Empieza con:

  • fallos reales de producción;
  • edge cases encontrados en desarrollo;
  • solicitudes ambiguas;
  • respuestas malformadas de tools;
  • límites de permisos;
  • instrucciones adversariales o contradictorias;
  • tareas donde una versión anterior ya tuvo regresiones.

Cada fallo de producción significativo debería convertirse en candidato a regression test.

Con el tiempo, el eval set se convierte en memoria operacional de lo que el sistema ya aprendió que no debe romper.

Separa capacidad de policy compliance

Un agente puede ser capaz de completar una tarea y aun así ser inaceptable porque viola una restricción.

Mide ambas cosas.

Por ejemplo, un agente puede emitir correctamente un reembolso y aun fallar porque:

  • omitió aprobación obligatoria;
  • el monto excedía un límite configurado;
  • expuso información sensible;
  • usó una tool fuera del scope permitido.

Task success y policy compliance deben ser métricas distintas.

Si no, el sistema puede parecer que mejora simplemente porque se volvió más agresivo.

Compara cambios contra un baseline

Cada cambio importante debería correr contra el mismo eval set:

  • upgrade de modelo;
  • cambio de prompt;
  • nueva tool;
  • nueva capa de retrieval;
  • cambio en descripción de tool;
  • cambio de routing;
  • cambio de memory;
  • cambio de permisos.

Compara:

  • task success;
  • consistencia entre múltiples trials;
  • costo por éxito;
  • latencia total;
  • cantidad de tool calls;
  • violaciones de policy;
  • categorías de fallo.

Esto evita un patrón común: arreglar un fallo visible mientras se degrada silenciosamente otra parte del sistema.

Scorecard mínimo de producción

Antes de desplegar un agente, querría por lo menos este scorecard:

Dimensión Métrica
Task success % de tareas que llegan a estado correcto verificado
Reliability éxito en trials repetidos / pass^k cuando aplica
Cost costo promedio y p95 por tarea exitosa
Latency p50 / p95 / p99 de finalización
Tool quality tasa de tool y argumentos correctos
Efficiency turnos y tool calls por tarea exitosa
Safety tasa de violaciones de permisos/policies
Recovery éxito después de fallos inyectados de tool o entorno
Regression cambio contra baseline de producción

Ningún número resume bien a un agente.

Un benchmark puede decir algo sobre capacidad del modelo. No te dice si tu combinación específica de modelo, tools, prompts, permisos, datos y entorno constituye un producto confiable.

La regla de diseño

Evalúa agentes como sistemas.

Mide resultado final, trayectoria, costo operacional y distribución de fallos.

Usa ground truth determinista cuando exista. Ejecuta múltiples trials. Conserva los fallos reales dentro del eval set. Compara cada cambio relevante contra un baseline estable.

El objetivo no es demostrar que el agente puede tener éxito.

El objetivo es saber con qué frecuencia tiene éxito, cómo falla, cuánto cuesta cada éxito y si permanece dentro de los límites definidos mientras realiza el trabajo.

Fuentes