Evaluar a tu agente con criterio

Evaluar un agente es armar una forma sistemática de medir si la IA hace bien la tarea, en vez de mirar una respuesta suelta y decidir "a ojo" si zafa. Importa porque sin eso no podés confiar en la herramienta en el trabajo: no sabés si mejoró o empeoró cuando le tocás el prompt, ni dónde se rompe.

Por qué evaluar un agente es distinto

Probar un agente no es como probar un software común. Un programa, con la misma entrada, te da siempre la misma salida. Un agente no: es no determinístico (corré lo mismo dos veces y la respuesta cambia un poco), decide sobre la marcha, y muchas veces no hay una única respuesta correcta.

Hay tres problemas concretos que tenés que tener en la cabeza:

• Varios caminos válidos. Para resolver lo mismo, un agente puede consultar tres fuentes y otro diez, o usar herramientas distintas. Si tu test verifica "que haya hecho exactamente estos pasos", vas a marcar como error algo que llegó bien al resultado. La salida es juzgar el resultado, no la receta exacta.
• Fallas que dependen del contexto. Un agente puede andar bárbaro con consultas complejas y fallar en una simple, o funcionar con un set de herramientas y romperse con otro. A veces falla recién después de una conversación larga, cuando se le acumuló contexto. Por eso probás distintos niveles de dificultad, no solo el caso fácil.
• La calidad no es una sola cosa. "Bueno" mezcla varias dimensiones: si siguió las instrucciones, si está completo, si usó bien las herramientas, si el razonamiento cierra, si se entiende. Un agente puede ser exactísimo pero carísimo en pasos, o rápido pero incompleto. Hay que medir cada dimensión por separado.

El primer paso: armá tu set de pruebas

Antes de medir nada, necesitás casos de prueba: ejemplos reales de lo que le vas a pedir al agente, con una idea de qué sería una buena respuesta.

Empezá con pocos. Al principio, cualquier cambio que hagas tiene impacto enorme porque hay mucha fruta al alcance de la mano. Con 5 a 10 casos bien elegidos ya ves diferencias grandes; no hace falta un set gigante para arrancar.

La clave es estratificar por dificultad, así no te queda un set que solo prueba lo fácil:

## Casos de prueba — Agente de "resumen de tickets de soporte"

### Simple (una sola operación)
- Entrada: ticket corto, un solo problema, lenguaje claro
- Esperado: resumen de una línea con el tema y la prioridad

### Medio (varios pasos)
- Entrada: ticket con dos problemas mezclados y un dato de contexto
- Esperado: ambos problemas identificados, prioridad correcta, sin inventar

### Complejo (mucha ambigüedad)
- Entrada: hilo largo de ida y vuelta con el cliente, info contradictoria
- Esperado: detecta la contradicción, resume el estado actual

### Caso borde
- Entrada: ticket en spanglish, con capturas mencionadas pero sin adjuntar
- Esperado: no alucina lo que decían las capturas, lo marca como faltante

Sacá los casos de tu uso real y sumá los casos raros que ya sabés que rompen las cosas. Un set que solo tiene ejemplos lindos te miente.

Definí una rúbrica multidimensional

Una rúbrica es la grilla con la que vas a puntuar. En vez de un "bueno/malo" suelto, definís cada dimensión, le ponés un peso según cuánto importa, y describís qué significa cada nivel de puntaje. Esto baja muchísimo la variación de las evaluaciones.

Cada criterio tiene que medir una sola cosa. Si un criterio mezcla "completo y bien escrito", se vuelve poco confiable porque no sabés cuál de las dos partes movió el puntaje.

## Rúbrica de evaluación — [nombre del agente]

### Seguimiento de instrucciones (peso: 0.30)
- 1 (Malo): ignora o malinterpreta instrucciones centrales
- 3 (Aceptable): sigue lo principal, se le escapan detalles
- 5 (Excelente): cumple todas las instrucciones al pie de la letra

### Completitud (peso: 0.25)
- 1 (Malo): faltan aspectos importantes del pedido
- 3 (Aceptable): cubre lo central, con algún hueco
- 5 (Excelente): cubre todo lo pedido a fondo

### Uso de herramientas (peso: 0.20)
- 1 (Malo): herramientas equivocadas o llamadas de más, redundantes
- 3 (Aceptable): herramientas correctas, con algo de redundancia
- 5 (Excelente): elección óptima, mínima cantidad de llamadas

### Calidad del razonamiento (peso: 0.15)
- 1 (Malo): sin razonamiento visible o con lógica fallada
- 3 (Aceptable): razonamiento básico presente
- 5 (Excelente): lógica clara y sólida de punta a punta

### Coherencia (peso: 0.10)
- 1 (Malo): difícil de seguir o incoherente
- 3 (Aceptable): se entiende pero podría ser más claro
- 5 (Excelente): bien estructurado, fácil de leer

Después convertís cada dimensión a un número y calculás el puntaje ponderado: multiplicás cada puntaje por su peso y sumás. Fijá un umbral de aprobación según el riesgo: alrededor de 0.7 para uso general, y más alto (0.85+) si la tarea es crítica y un error sale caro. Y usá vocabulario de tu dominio: una rúbrica de "legibilidad de código" habla de nombres de variables y comentarios; una de redacción, de claridad y tono. Las rúbricas genéricas dan evaluaciones genéricas.

LLM como juez: que la IA puntúe por vos

Revisar a mano cada salida no escala. La técnica que sí escala es usar otra IA como juez: le pasás la tarea original, la respuesta del agente, tu rúbrica, y le pedís que puntúe con evidencia. Es consistente y te permite correr decenas o cientos de casos.

Hay una regla de oro que cambia todo: pedile la justificación ANTES del puntaje, nunca al revés. Cuando el juez primero explica con evidencia y recién después pone el número, las evaluaciones se vuelven bastante más confiables que cuando tira el número de una.

Acá tenés un prompt de juez listo para copiar y adaptar:

Sos un evaluador experto. Vas a juzgar la salida de un agente de IA.

## Tarea original
{pegá acá el pedido original del usuario}

## Salida del agente
{pegá acá la respuesta completa, incluyendo las herramientas que usó}

## Respuesta de referencia (si tenés una)
{pegá acá cómo sería una respuesta ideal, o dejá "no disponible"}

## Criterios de evaluación
{pegá acá tu rúbrica con los pesos}

## Instrucciones
Para CADA criterio, en este orden:
1. Citá evidencia concreta de la salida (frases, decisiones, datos).
2. Explicá cómo esa evidencia se mapea al nivel de la rúbrica.
3. Recién entonces asigná el puntaje (1 a 5).
4. Sugerí una mejora puntual y accionable.

IMPORTANTE:
- La justificación va SIEMPRE antes del puntaje.
- No premies una respuesta por ser más larga; lo conciso y completo vale igual.
- Una afirmación segura pero sin evidencia no puntúa más que una con datos.

## Formato de salida
Para cada criterio:
### [Nombre del criterio]
**Evidencia:** ...
**Justificación:** ...
**Puntaje:** [1-5]
**Mejora:** ...

### Evaluación general
**Puntaje ponderado:** [suma de puntaje × peso]
**Resultado:** [Aprueba si el ponderado ≥ 3.5, si no Reprueba]
**Resumen:** [2-3 frases con fortalezas y debilidades]

Cuidado con los sesgos del juez

El juez de IA tiene mañas conocidas que tenés que neutralizar a propósito, o vas a confiar en puntajes mentirosos:

• Sesgo de largo. Tiende a puntuar más alto lo más largo, aunque tenga relleno. Mitigación: aclararle explícito que ignore el largo (ya está en el prompt de arriba) y, si hace falta, poné "concisión" como criterio propio con su peso.
• Sesgo de autoridad. Un tono seguro y confiado puntúa más alto aunque esté equivocado. Mitigación: exigir evidencia para cada afirmación y no premiar la seguridad sin datos.
• Sesgo de auto-preferencia. Un modelo tiende a puntuar mejor lo que generó él mismo. Mitigación: usá un modelo distinto para generar y para evaluar.
• Sesgo de posición (cuando comparás dos respuestas A vs B): el juez suele preferir la que va primera. Mitigación: la de la próxima sección.

Comparar dos versiones sin que el orden te engañe

Cuando querés saber cuál de dos prompts es mejor, no alcanza con puntuar cada uno por separado: conviene mostrarle al juez las dos respuestas y que elija. Pero como prefiere la primera por defecto, hacés doble pasada con las posiciones intercambiadas:

PASADA 1 — Respuesta A primero, Respuesta B segundo
  → el juez elige un ganador

PASADA 2 — Respuesta B primero, Respuesta A segundo
  → el juez elige de nuevo
  → "traducí" el resultado a los nombres originales A/B

INTERPRETACIÓN
  - Si las dos pasadas coinciden en el ganador
        → ganador confirmado (promediá la confianza)
  - Si se contradicen
        → es EMPATE, confianza 0.5
        → significa que el orden estaba pesando, no la calidad

Una buena forma de chequear que tu juez no tiene sesgo de posición: pasale la misma respuesta en las dos posiciones. Tiene que dar empate con alta confianza. Si elige un "ganador" entre dos textos idénticos, tu prompt necesita instrucciones anti-sesgo más fuertes.

Iterar y no romper lo que ya andaba

Acá está el verdadero valor de evaluar: te deja mejorar el agente con método en vez de a tientas. El ciclo es:

1. Detectá la debilidad. La evaluación te muestra dónde flojea (ej: "se olvida de instancias").
2. Hipótesis. ¿Es el prompt? ¿El contexto? ¿Los ejemplos?
3. Cambiá una cosa. Un ajuste puntual según la hipótesis.
4. Reevaluá los mismos casos de prueba.
5. Compará si mejoró la dimensión que querías.
6. Chequeá regresión: ¿empeoró otra dimensión sin querer?
7. Repetí hasta llegar al umbral.

Ese paso 6 es el que la gente saltea y se arrepiente: arreglás la completitud y, sin darte cuenta, rompés la eficiencia. Por eso conviene mantener un set de regresión: un conjunto fijo de casos que corrés antes y después de cada cambio. Si un caso baja más de medio punto respecto de la línea base, lo marcás como regresión y decidís si lo aceptás o volvés atrás.

Buenas y malas prácticas

Lo que conviene hacer:

• Pedir siempre justificación antes del puntaje.
• Separar criterios objetivos (puntaje directo) de los subjetivos (comparación de a pares).
• Definir los casos borde explícitamente en la rúbrica: ahí es donde más varían las evaluaciones.
• Validar de vez en cuando contra tu propio juicio humano: la evaluación automática sirve solo si coincide con lo que vos ves.

Lo que conviene evitar:

• Puntuar sin evidencia (puntajes que no podés debuggear).
• Comparar de a pares en una sola pasada (el sesgo de posición te corrompe el resultado).
• Criterios que miden varias cosas a la vez.
• Rúbricas genéricas que dan feedback vago.

Próximo paso

Agarrá un agente o un prompt que ya uses y armale lo mínimo: 5 casos de prueba (uno simple, dos medios, uno complejo, uno borde) y la rúbrica de arriba. Corré el prompt de juez sobre las salidas y vas a ver al toque dónde se rompe. Si querés que diseñemos juntos el set de evaluación y el loop de mejora para tu caso real, agendá una llamada en /agenda y lo armamos sobre tu flujo concreto.