Intro

Cuando un equipo empieza a usar agentes, suele pasar algo bastante predecible.

Las primeras pruebas salen bien, el agente responde rápido, usa alguna tool, resuelve dos o tres casos visibles y da la sensación de que ya está “funcionando”. Entonces aparece la tentación de pasar de una demo prometedora a una confianza que todavía no fue ganada.

Ahí es donde entran las evals.

Qué es una eval, explicado sin humo

Una eval es una forma repetible de poner a prueba un sistema contra casos que importan y medir cómo le fue con criterios observables.

Dicho más simple: si querés saber si un agente realmente sirve, necesitás compararlo contra tareas concretas y no solo contra la impresión que deja en una conversación suelta.

Eso vale incluso más cuando el agente:

  • usa herramientas;
  • toma decisiones intermedias;
  • resume o transforma información;
  • opera sobre tickets, repositorios, documentos o infra;
  • cambia de modelo, prompt o configuración con frecuencia.

Mientras más capacidad operativa tenga, menos alcanza con decir “parece andar bien”.

Por qué una demo no alcanza

Una demo puede mostrar que el agente puede acertar. Una eval intenta medir con qué frecuencia acierta, cómo falla y qué tan grave es cuando falla.

Esa diferencia es enorme.

Un agente puede verse excelente en un caso preparado y, sin embargo:

  • inventar datos cuando el contexto viene incompleto;
  • elegir la tool equivocada;
  • romper una instrucción de formato;
  • ejecutar pasos de más;
  • omitir validaciones importantes;
  • responder con seguridad incluso cuando debería admitir incertidumbre.

Ese tipo de problema no siempre aparece en una prueba manual casual. Y cuando aparece en producción, ya no se siente como un detalle: se siente como regresión, incidente o pérdida de confianza.

El problema real de trabajar sin evals

Sin evaluaciones, casi todo cambio se vuelve opaco.

Si cambiás de modelo, ¿mejoró o empeoró?
Si ajustás el prompt, ¿subió la precisión o solo cambió el tono?
Si agregás memoria o una tool nueva, ¿resuelve más casos o mete más riesgo?
Si el agente usa menos tokens, ¿se volvió más eficiente o más superficial?

Sin evals, esas preguntas se responden con intuición, anécdotas o confianza excesiva en un par de ejemplos recientes.

Ese vacío genera varios problemas a la vez.

1. Regresiones invisibles

A veces una modificación mejora un tipo de caso y rompe otro. Sin una batería de pruebas representativa, eso puede pasar desapercibido hasta que el daño ya llegó al workflow real.

2. Cambios a ciegas

Moverse entre modelos, prompts o herramientas sin una referencia estable convierte cada cambio en una apuesta. A veces sale bien. Otras no. Pero sin medición, cuesta saber cuál fue cuál.

3. Falsa sensación de calidad

Los agentes suelen sonar convincentes. Ese es justamente uno de los riesgos. La fluidez verbal puede disfrazar errores de fondo, omisiones o decisiones incorrectas.

4. Mala gobernanza

Si no podés medir bien, también te cuesta decidir:

  • cuándo conviene pedir approvals;
  • qué tareas sí se pueden automatizar;
  • qué cambios merecen rollout parcial;
  • qué incidentes son de modelo, de prompt, de herramienta o de diseño.

Qué debería medir una eval útil

Acá conviene frenar una confusión común: una eval no siempre busca producir una sola nota final.

En agentes, lo normal es medir varias cosas al mismo tiempo.

Calidad de la respuesta

La respuesta resolvió la tarea o no. Pero incluso eso puede abrirse en preguntas más concretas:

  • respondió lo pedido;
  • usó el dato correcto;
  • respetó el formato esperado;
  • omitió errores graves;
  • mantuvo el nivel de detalle apropiado.

Cumplimiento de instrucciones

Muchos agentes fallan no por “no saber”, sino por no seguir bien restricciones operativas. Por ejemplo:

  • debía contestar en JSON y no lo hizo;
  • debía usar una tool antes de responder y la ignoró;
  • debía pedir confirmación antes de una acción sensible y se la saltó.

Seguridad

Acá entran señales como:

  • resistir prompt injection básico;
  • no exponer datos sensibles;
  • no invocar herramientas prohibidas;
  • no escalar permisos sin justificación;
  • no actuar con exceso de confianza cuando falta contexto.

Comportamiento operativo

En agentes con tools, memoria o pasos encadenados, también importa cómo llega al resultado.

No es lo mismo:

  • resolver con una llamada correcta,
  • que resolver después de tres pasos innecesarios,
  • o resolver de casualidad pero dejando efectos colaterales peligrosos.

Por eso, en ciertos workflows, conviene evaluar no solo la salida final sino también la trayectoria.

De lo básico a lo complejo: cómo escalan las evals

Una buena forma de pensarlo es por niveles.

Nivel 1: tareas simples con salida clara

Este es el punto de entrada más fácil.

Ejemplos:

  • clasificar tickets;
  • extraer campos de un texto;
  • resumir un incidente con estructura fija;
  • decidir si un caso debe escalarse o no según reglas conocidas.

Acá es relativamente fácil preparar ejemplos y definir qué era correcto.

Nivel 2: tareas con ambigüedad razonable

Después aparecen casos donde no existe una única frase perfecta, pero sí criterios verificables.

Por ejemplo:

  • responder una consulta técnica usando documentación interna;
  • redactar una recomendación operativa sin inventar pasos;
  • proponer una hipótesis con incertidumbre bien comunicada.

En estos casos, en vez de pedir coincidencia exacta, conviene medir atributos observables: si citó la fuente correcta, si no inventó, si cubrió los puntos mínimos, si mantuvo las restricciones.

Nivel 3: agentes con herramientas

Acá la cosa se pone más interesante.

Cuando el agente ya puede llamar tools, la pregunta no es solo “qué contestó”, sino también:

  • eligió la herramienta adecuada;
  • la usó en el momento correcto;
  • pasó parámetros válidos;
  • evitó herramientas innecesarias;
  • respetó permisos y límites del flujo.

En esta capa, una eval puede detectar cosas que una conversación bonita no muestra: tool misuse, pasos de más, validaciones omitidas o decisiones frágiles.

Nivel 4: workflows largos y multiobjetivo

El caso más complejo aparece cuando el agente participa en un flujo real con varias metas a la vez: calidad, seguridad, costo, latencia, trazabilidad y compliance.

Por ejemplo:

  • un agente de soporte que consulta sistemas, redacta una respuesta y decide si escalar;
  • un agente interno que resume incidentes, abre tickets y propone acciones;
  • un agente con shell o browser que ejecuta pasos, lee outputs y toma decisiones intermedias.

En esos escenarios, una sola métrica deja de alcanzar. Necesitás mirar conjuntos de señales.

Cómo diseñar una eval que sí sirva

La manera más sana de empezar no es buscar el benchmark perfecto. Es elegir casos reales y volverlos repetibles.

1. Partir del trabajo real

La mejor pregunta inicial no es “qué benchmark existe”, sino “qué hace este agente en la práctica”.

Tomá tareas que realmente importen:

  • las más frecuentes;
  • las más sensibles;
  • las que ya fallaron antes;
  • las que definen si el flujo ahorra tiempo o agrega riesgo.

Si la eval no se parece al trabajo real, puede dar una sensación de control falsa.

2. Definir criterios observables

Una eval útil necesita reglas que otra persona pueda entender y revisar.

Por ejemplo:

  • usa la fuente correcta;
  • no inventa hechos;
  • respeta el formato;
  • pide aprobación cuando corresponde;
  • no llama herramientas restringidas;
  • marca incertidumbre si faltan datos.

Cuanto más observable sea el criterio, menos dependés de percepciones difusas.

3. Separar generación y verificación

Este punto importa mucho.

Una cosa es la respuesta del agente. Otra es cómo decidís si estuvo bien. Si mezclás ambas en el mismo criterio informal, terminás validando con demasiada subjetividad.

Siempre que se pueda, conviene que la verificación tenga sus propias reglas, comparaciones o checks independientes.

4. Incluir casos normales y casos borde

Si solo medís ejemplos fáciles, terminás premiando fluidez y castigando poco el riesgo real.

Una batería razonable debería mezclar:

  • casos típicos;
  • inputs incompletos;
  • ambigüedad moderada;
  • instrucciones contradictorias;
  • intentos de desvío o abuso;
  • situaciones donde la mejor respuesta es frenar o pedir aclaración.

5. Aceptar que no todo entra en una sola métrica

A veces conviene tener varias notas parciales, por ejemplo:

  • exactitud funcional;
  • seguridad;
  • cumplimiento de formato;
  • uso correcto de tools;
  • costo o latencia.

Eso ayuda a evitar una trampa común: subir una métrica y destruir otra sin verlo.

Errores comunes al armar evals

Hay varios errores repetidos que conviene evitar.

Medir solo estilo o “qué bien suena”

Un agente elegante puede estar igual de equivocado.

Usar datasets demasiado chicos o demasiado limpios

Si todos los ejemplos están prolijos, claros y bien redactados, tu eval se parece más a un examen ideal que al mundo real.

Elegir benchmarks irrelevantes

Que un modelo rinda bien en una prueba famosa no implica que tu workflow esté cubierto.

No versionar cambios

Si cambiás prompt, modelo, herramientas o criterios sin registrar nada, después no podés reconstruir por qué subió o bajó el rendimiento.

No medir fallos importantes

Algunas organizaciones cuentan aciertos, pero no distinguen entre un error menor y una acción peligrosa. Eso distorsiona por completo la lectura del riesgo.

Cómo conecta esto con seguridad y operaciones

Las evals no son solo una herramienta de calidad. También son una herramienta de gobierno.

Sirven para decidir mejor:

  • si un cambio merece rollout completo o parcial;
  • si una tarea necesita approval humano;
  • si una tool está demasiado expuesta;
  • si un modelo nuevo introduce más alucinaciones o más riesgo operativo;
  • si un agente ya está listo para tocar sistemas reales.

En ese sentido, este tema se conecta bastante con Qué son las alucinaciones en los modelos de IA y por qué importa tenerlas en cuenta en un workflow de trabajo con agentes, con Cómo diseñar approvals en agentes sin frenar la operación ni abrir riesgos y con Qué es un AI gateway y por qué importa para seguridad, gobernanza y observabilidad de agentes.

Las alucinaciones explican una clase de fallo. Los approvals controlan decisiones sensibles. La observabilidad ayuda a entender comportamiento. Las evals, en cambio, sirven para medir de forma repetible si el sistema está mejorando o degradándose.

Cómo empezar sin volverte loco

No hace falta arrancar con miles de casos ni con una infraestructura enorme.

Un enfoque razonable puede ser este:

  1. elegir una tarea concreta del agente;
  2. reunir 20 a 50 casos representativos;
  3. definir criterios de éxito observables;
  4. medir antes de cambiar algo;
  5. volver a medir después de cada cambio importante;
  6. guardar resultados y compararlos en el tiempo.

Con eso ya podés detectar bastante más de lo que detecta una demo.

Más adelante, si el uso crece, podés sumar:

  • datasets más amplios;
  • segmentación por tipos de caso;
  • casos adversariales;
  • scorecards por tool;
  • gates de rollout;
  • alertas cuando una métrica crítica cae.

La idea importante

Un agente confiable no es el que impresiona una vez. Es el que resiste comparación, cambia con trazabilidad y mejora sin romper silenciosamente otras cosas.

Por eso las evals importan tanto.

No porque hagan que todo sea perfectamente medible, sino porque obligan a reemplazar una confianza estética por una confianza operativa.

En cuanto un agente participa de un workflow real, la pregunta deja de ser “¿parece útil?” y pasa a ser esta:

¿cómo sabemos, con evidencia, que sigue resolviendo bien lo que importa y que no se volvió más riesgoso en el proceso?

Ahí empieza la confiabilidad de verdad.