Plan de evaluación

Armá entre 20 y 50 tareas sacadas de fallas reales. Repetí cada una varias veces para medir pass^k (la probabilidad de que todos los intentos salgan bien).
La plantilla define quién califica y con qué límites. También fija cuándo el agente sale a producción y cuándo vuelve atrás.
Copiá el bloque con el botón de la esquina, o abrí el archivo en GitHub.
# Plan de evaluación: [nombre del agente]

<!--
Cómo usar esta plantilla:
- Completala antes de mostrar el agente a usuarios reales.
- Sacá las tareas de fallas reales, no de casos inventados para que el agente quede bien.
- Corré la evaluación cada vez que cambia el prompt, el modelo o una herramienta.
-->

- Fecha: [AAAA-MM-DD]
- Dueño de la evaluación: [nombre]
- Qué se evalúa: modelo [nombre y versión], prompt [versión], herramientas [lista y versiones]

## 1. Las tareas

<!--
Juntá entre 20 y 50 tareas. Fuentes buenas: tickets que salieron mal, incidentes,
casos que hoy resuelve mal una persona o el sistema actual.
Incluí casos donde la respuesta correcta es no actuar o pasar a una persona.
Incluí intentos de inyección de instrucciones (ver mapa-de-amenazas.md).
-->

| ID | Entrada | Resultado esperado | Origen | Cómo se califica |
|---|---|---|---|---|
| T01 | [...] | [estado final esperado] | [falla real / caso frecuente / caso borde / ataque] | [código / modelo / persona] |
| T02 | [...] | [pasar a una persona] | [...] | [...] |
| [...] | [...] | [...] | [...] | [...] |

## 2. Repeticiones y métrica

<!--
pass@k: al menos uno de k intentos sale bien. Sirve si una persona elige el mejor intento.
pass^k: los k intentos salen bien. Sirve si el agente atiende solo a cada cliente.
Con 75 % de acierto por intento, pasar 3 de 3 da cerca de 42 %.
-->

- Intentos por tarea (k): [__]
- Métrica principal: [pass^k | pass@k], porque [razón]
- También medimos: costo por tarea exitosa, pasos por tarea, acciones bloqueadas por la compuerta (el control que frena acciones antes de ejecutarlas).

## 3. Quién califica y cómo

| Calificador | Para qué | Límites |
|---|---|---|
| Código | Estado final, formato, herramienta llamada, montos. Es la primera opción. | Solo mide lo que se puede escribir como regla. |
| Modelo como juez | Texto libre, tono, si la respuesta usa la fuente correcta. | En preguntas de sí o no, como si el agente logró la tarea, puede coincidir con las personas tanto como ellas entre sí. Cada modelo falla para un lado: unos rechazan éxitos y otros aprueban fallas. Puede ser consistente y tener sesgo de posición a la vez (preferir una respuesta por el lugar en que aparece). Comparalo con notas de personas antes de confiar en él. |
| Persona experta | Calibrar al juez, casos ambiguos, revisar muestras. | Es lenta y cara. Se cansa si revisa muchos casos seguidos. |

- Calificá el resultado (el estado final), no el camino que tomó el agente. Pero revisá el registro de acciones: buscá efectos secundarios en el camino.
- Antes de culpar al agente, leé las transcripciones de las fallas. Una parte de las fallas son errores del calificador.
- Si usás un modelo como juez, compará sus notas con las de una persona en [n] tareas. Coincidencia mínima: [__] %. Medila con kappa de Cohen, que descuenta los aciertos por azar. No la midas como coincidencia exacta.

## 4. Criterio de salida

El agente sale a producción si cumple todo esto:

- [ ] pass^[k] de al menos [__] % en el conjunto de tareas.
- [ ] Ninguna acción prohibida pasó la compuerta.
- [ ] Ningún intento de inyección logró una acción hacia afuera.
- [ ] Costo por tarea exitosa de [__] como máximo.

Cómo empieza: una persona revisa el 100 % durante [n semanas o n casos]. Después, abrimos por categoría: [orden de categorías].

## 5. Criterio de vuelta atrás

| Señal en producción | Umbral | Qué hacemos |
|---|---|---|
| Casos reabiertos o quejas | [__] % | [volver a modo sugerencia] |
| Correcciones humanas | [__] % | [...] |
| Costo por tarea exitosa | [__] | [...] |
| Acción no esperada hacia afuera | 1 | Apagar y seguir el runbook (el procedimiento escrito para incidentes). |

Decide la vuelta atrás: [rol]. Cómo volvemos: [interruptor, cola humana].

## 6. Regresión

<!-- Regresión: una falla que ya estaba resuelta y vuelve a aparecer. -->

- [ ] Cada falla confirmada en producción entra como tarea nueva.
- [ ] Las pruebas deterministas (con el modelo simulado, dan siempre el mismo resultado) corren separadas de esta evaluación.
- [ ] La evaluación corre en cada cambio de prompt, modelo o herramienta.

## Por qué está esto acá

- Empezá con 20 a 50 tareas tomadas de fallas reales, separá pass@k de pass^k y leé las transcripciones: *Demystifying evals for AI agents* (Anthropic, 2026).
- Con varios intentos por tarea, la consistencia cae. Un agente que usa la computadora resolvió cerca de 78 % de las tareas al menos una vez en 10 intentos. Resolvió cerca de 36 % en los 10: *On the Reliability of Computer Use Agents* (Gonzalez-Pumariega y otros, 2026).
- En la pregunta de si el agente logró la tarea, un juez simple puede coincidir con las personas tanto como ellas entre sí. Pero los modelos fallan para lados opuestos: unos rechazan éxitos y otros aprueban fallas: *Benchmarking LLM Judges for Mobile Agent Evaluation* (Wang y otros, 2026).
- Medir el acuerdo como coincidencia exacta lo infla. Y un juez puede ser consistente consigo mismo y tener sesgo de posición a la vez: *Reliability without Validity* (Norman y otros, 2026).