Evaluar agentes de IA: qué significa exactamente «funciona mejor»

«Va mucho mejor.» Es la frase con la que se cierra la mayoría de revisiones de un agente en producción. Y es una frase que no contiene ninguna información. Mejor que qué. Medido con qué criterio. Con cuánta confianza de que la diferencia no es ruido. Tres preguntas, y en la mayoría de equipos no hay respuesta escrita para ninguna de las tres.

El problema no es de rigor personal, es conceptual. «Mejor» no es una propiedad del sistema: es una relación con un referente. Y «bien» no es una impresión: es el resultado de aplicar un criterio que alguien escribió antes de mirar la salida. Los dos objetos que faltan son siempre los mismos: la rúbrica —qué cuenta como correcto— y el baseline —contra qué se compara—. Sin ellos, cualquier comparación entre dos versiones de un agente es una conversación de opiniones con vocabulario técnico.

En el artículo anterior sobre LLMOps describimos el ciclo completo y dijimos que el nivel 2 de madurez empieza cuando un número puede bloquear un despliegue. Este artículo es de dónde sale ese número: cómo se construyen la rúbrica y el baseline a partir del golden set, cómo se sabe si una diferencia es real, y qué dicen los trabajos que han estudiado el problema — porque llevan tres años documentando exactamente los errores que los equipos repetimos.

Por qué en agentes la pregunta se rompe

Evaluar una llamada suelta a un modelo es incómodo pero tratable: entrada, salida, criterio. Evaluar un agente es otra cosa, y por cinco razones concretas.

Hay más de una trayectoria correcta. Una tarea resuelta bien puede resolverse consultando primero el CRM y luego la base de conocimiento, o al revés, o sin consultar la base de conocimiento porque el CRM ya bastaba. No existe una «respuesta de referencia» única contra la que comparar cadenas de texto.

El resultado no es un texto, es un efecto en el mundo. El agente creó el ticket, hizo la devolución, modificó el fichero, envió el correo. Lo que hay que verificar es el estado final del sistema, no la elegancia de la explicación.

Hay crédito parcial y no siempre cuenta. Ocho de diez pasos correctos y un noveno que rompe el estado no es un 80%: es un fallo. En otras tareas, en cambio, ocho de diez sí vale, porque el humano corrige el resto en dos minutos. La rúbrica tiene que decidir cuál de los dos casos es el tuyo, y esa decisión es de negocio, no técnica.

El no determinismo se compone. La varianza de un paso se multiplica por la del siguiente. Toby Ord propuso en 2025 un modelo sorprendentemente simple para esto: si el agente tiene una probabilidad de fallo aproximadamente constante por cada minuto de trabajo humano que la tarea representa, entonces la tasa de éxito decae exponencialmente con la longitud de la tarea, y cada agente queda caracterizado por su propia «media vida». La consecuencia operativa es dura: no puedes extrapolar de tareas de cinco minutos a tareas de dos horas. Que tu agente acierte el 90% de las tareas cortas no dice casi nada sobre las largas.

Y el coste varía por ejecución. Dos sistemas con la misma tasa de acierto pueden diferir en un orden de magnitud en lo que cuesta cada ejecución. Comparar sólo por acierto es comparar media foto.

«Bien» es una rúbrica, no una impresión

Una rúbrica es un conjunto explícito de criterios que convierte un juicio holístico en verificaciones discretas. Un trabajo de revisión publicado este verano —From Holistic Evaluation to Structured Criteria, Chen y otros, junio de 2026— sitúa las rúbricas en tres niveles: el evaluativo, donde descomponen un juicio global en dimensiones verificables; el de entrenamiento, donde funcionan como señal densa de recompensa; y el intrínseco, donde emergen del propio comportamiento del modelo. Lo que necesita un equipo de producto es el primero, y es el que casi nadie escribe.

Empecemos por lo que una rúbrica no es: una escala del 1 al 10 de «calidad». Pedirle a un juez —humano o modelo— que puntúe la calidad global de una respuesta produce un número con la reproducibilidad de una encuesta de satisfacción. Pedirle que verifique doce criterios concretos produce doce respuestas auditables, cada una con su evidencia. La diferencia entre las dos cosas es la diferencia entre una opinión numerada y una medida.

Cómo se deriva del golden set, paso a paso

El golden set ya lo tienes si seguiste el ciclo del artículo anterior: treinta o cincuenta casos por capacidad, etiquetados por quien conoce el dominio. La rúbrica se extrae de ahí, no de una sesión de brainstorming en abstracto.

• Coge de 20 a 30 casos del golden set con sus respuestas de referencia. No más: el objetivo de esta fase es encontrar patrones, no cubrirlo todo.
• Pregunta caso por caso a la persona de dominio dos cosas: qué tiene que aparecer sí o sí, y qué no puede aparecer nunca. No preguntes «¿esto está bien?» — esa pregunta devuelve una impresión. Las dos anteriores devuelven criterios.
• Agrupa. Lo que aparece en más de un tercio de los casos es un criterio general de la capacidad. Lo que aparece una vez es un criterio específico de ese caso, y también vale: HealthBench funciona así.
• Reescribe cada criterio como una verificación binaria con evidencia localizable en la traza. Si no puedes señalar dónde se cumple o dónde falla, el criterio no está terminado.
• Pondera y marca los eliminatorios. No todos los criterios valen lo mismo, y algunos no promedian: o se cumplen o el caso falla entero.

La referencia industrial de este método es HealthBench, la evaluación clínica que OpenAI publicó en 2025: 5.000 conversaciones sanitarias, cada una con su rúbrica escrita por médicos —262 profesionales de 60 países y 26 especialidades—, con un total de 48.562 criterios, cada uno con su valor en puntos según la importancia que el médico le asignó. Nadie escribió «puntúa del 1 al 10 la calidad clínica». Se escribió, criterio a criterio, qué debía aparecer y qué debía evitarse. Tú no necesitas 48.562 criterios: necesitas la disciplina que produce esos criterios.

Anatomía de un criterio que sirve

La prueba de calidad de un criterio es esa última línea: dos personas distintas, el mismo caso, el mismo veredicto. Si el criterio necesita una conversación para resolverse, no está terminado. Y si no está terminado para un humano, un modelo juez tampoco lo va a aplicar de forma estable.

Ponderación, eliminatorios y la trampa de la media

Con doce criterios y una media aritmética, un sistema que falla el criterio de seguridad pero acierta los once restantes saca un 92%. Es exactamente el número equivocado. Por eso una rúbrica operativa tiene dos tipos de criterio:

• Acumulativos: suman puntos ponderados. Miden calidad.
• Eliminatorios: si fallan, el caso vale cero, independientemente del resto. Miden aceptabilidad.

Los eliminatorios suelen ser pocos —dos o tres— y casi siempre son de la misma familia: acciones irreversibles sin confirmación, fuga de datos que no debían salir del perímetro, y afirmaciones inventadas presentadas como hechos. Si tu rúbrica no tiene eliminatorios, o tu sistema es muy inocuo, o no has pensado todavía en qué es inaceptable.

En el informe, además, la media agregada no se reporta sola. Se reporta por capacidad, como decíamos en el ciclo LLMOps: una media que sube ocultando que la capacidad crítica cayó ocho puntos es peor que no medir, porque produce confianza donde debería producir una alarma.

Rúbrica de resultado y rúbrica de proceso

Hay dos preguntas distintas y conviene no mezclarlas. La rúbrica de resultado pregunta si el estado final del mundo es el correcto: ¿el pedido quedó cancelado, el importe es el que tocaba, el fichero compila? La rúbrica de proceso pregunta si el agente llegó ahí por un camino admisible: ¿usó sólo las herramientas permitidas, respetó el orden, evitó efectos colaterales, no entró en bucle?

Evaluar la trayectoria es caro si se hace a mano, y ahí es donde el trabajo Agent-as-a-Judge (Zhuge y otros, ICML 2025) aporta un dato útil: un agente evaluador que puede abrir ficheros, ejecutar comprobaciones y revisar cada paso alcanzó un 90% de alineación con el juicio humano sobre su benchmark DevAI, a un 2,29% del coste y un 2,36% del tiempo de la evaluación humana. La evaluación de proceso dejó de ser un lujo académico.

La regla práctica que aplicamos: resultado siempre; proceso cuando el resultado correcto por el camino equivocado sea inaceptable. Es decir, cuando hay acciones irreversibles, cuando hay obligaciones de cumplimiento —lo tratamos en Compliance-First AI Design— o cuando el camino determina el coste. En un flujo de varias etapas encadenadas, el proceso casi siempre importa.

Tu rúbrica puede ser correcta y estar midiendo otra cosa

Este es el punto que más veces se salta, y el que más caro sale. Una rúbrica bien escrita puede seguir sin medir lo que crees. El trabajo Establishing Best Practices for Building Rigorous Agentic Benchmarks (Zhu y otros, NeurIPS 2025) lo formaliza en dos condiciones:

• Validez de tarea: la tarea debería ser resoluble si y sólo si el agente tiene la capacidad que dices medir. Si se puede resolver por un atajo que no requiere esa capacidad, la tarea no es válida.
• Validez de resultado: la comprobación debería indicar correctamente si la tarea se resolvió. Si la comprobación es débil, mide otra cosa.

Los ejemplos que dan los autores son incómodos precisamente porque no son de benchmarks improvisados. Documentan que SWE-bench Verified usa casos de test insuficientes y que τ-bench llega a contar respuestas vacías como éxito; en conjunto, defectos de este tipo pueden infraestimar o sobreestimar el rendimiento de un agente hasta en un 100% en términos relativos. Si le pasa a benchmarks públicos, revisados y ampliamente citados, le pasa con más razón a la rúbrica que tu equipo escribió un jueves por la tarde.

«Mejor» es un baseline, no un adjetivo

Con la rúbrica ya puedes decir «bien». Para decir «mejor» hace falta un referente, y aquí es donde la mayoría de comparaciones se caen: se compara la versión nueva contra el recuerdo de la anterior. El recuerdo no es un baseline.

El baseline tonto, o por qué tu arquitectura puede no estar aportando nada

En 2024, un grupo de Princeton —Kapoor, Stroebl, Siegel, Nadgir y Narayanan— publicó AI Agents That Matter, un análisis de cómo se evalúan los agentes que sigue siendo el trabajo más incómodo de leer si tu equipo acaba de montar un pipeline agéntico. Su hallazgo central: baselines simples dominaban en Pareto a agentes de última generación —Reflexion, LDB, LATS— en HumanEval, con 50 veces menos coste. Y su diagnóstico: la comunidad se fija sólo en la exactitud, sin atender al coste, y de ahí salen agentes innecesariamente complejos y caros, y conclusiones equivocadas sobre de dónde vienen las mejoras.

Traducido a la realidad de un equipo de producto: si nadie midió la línea base simple —una sola llamada con buen contexto, sin orquestación—, no sabes si tu arquitectura de siete pasos aporta calidad o sólo aporta factura. La ablación es el experimento más barato del catálogo y casi nadie lo corre, porque el resultado puede ser políticamente incómodo.

El baseline humano se mide, no se imagina

El otro baseline que se maltrata es el humano. Se compara el agente contra una persona ideal que nunca se equivoca, y la conclusión es siempre la misma: «todavía no está». Pero el humano que hoy hace esa tarea tiene un tiempo medio, un coste por tarea y una tasa de error que no es cero. Sin esos tres números, la comparación está sesgada de origen.

Medirlo no requiere un estudio: veinte tareas cronometradas y revisadas con la misma rúbrica que aplicas al agente. La misma rúbrica es la parte importante — si al humano lo juzgas con indulgencia y al agente con lupa, no estás comparando, estás justificando una decisión que ya habías tomado.

El coste no es una consecuencia: es un eje de la comparación

De lo anterior sale la consecuencia metodológica: no se compara un punto contra otro punto, se comparan posiciones en una frontera de calidad y coste. Un sistema con 92% de acierto a 0,40 € por tarea y otro con 86% a 0,04 € no están ordenados: son dos puntos distintos de una frontera, y cuál es «mejor» depende de quién absorbe el 8% restante y a qué precio. La métrica que hace comparable esa frontera es el coste por tarea útil, y su comportamiento al escalar lo desarrollamos en el coste real de poner IA en producción.

Fiabilidad no es capacidad: pass@k frente a pass^k

Aquí hay una distinción que decide más despliegues de los que parece, y viene de τ-bench (Yao y otros, 2024), el benchmark de Sierra para agentes que conversan con un usuario y manejan herramientas bajo políticas de dominio.

• pass@k: el agente acierta al menos una vez en k intentos. Mide potencial. Es la métrica correcta cuando existe un verificador barato que descarta los intentos malos: compilar, pasar tests, validar un esquema.
• pass^k: el agente acierta las k veces. Mide fiabilidad. Es la métrica correcta cuando la salida va a producción sin red.

El dato de τ-bench es el que conviene tener presente: agentes de función avanzados resolvían menos del 50% de las tareas en una pasada, y en el dominio de retail caían por debajo del 25% en pass^8. Es decir: de cada cuatro tareas que sabían resolver, sólo una la resolvían ocho veces seguidas.

La pregunta de negocio, entonces, no es «¿qué porcentaje saca?» sino «¿con qué k lo necesito?». Y la k correcta es el número de veces que el proceso se ejecuta antes de que un humano lo revise. Si un agente procesa 200 devoluciones diarias y nadie las mira, tu k no es 8: es 200. Reportar pass@1 en ese escenario no es optimista, es incorrecto.

¿Y la diferencia es real? La estadística mínima que hay que hacer

Supongamos que ya tienes rúbrica, baseline y una métrica bien elegida. El sistema nuevo saca 85% y el anterior 82%. ¿Es una mejora?

Probablemente no lo sepas. Con 50 casos y una tasa cercana al 80%, el error estándar ronda los 5-6 puntos. Una diferencia de 3 puntos cabe entera dentro del ruido. Y si además cada caso se ejecutó una sola vez, parte de esos 3 puntos es simplemente el no determinismo del modelo.

El trabajo de referencia aquí es Adding Error Bars to Evals, de Evan Miller (Anthropic, 2024), que critica de entrada la práctica dominante: reportar evaluaciones con mentalidad de «el número más alto gana», en negrita, sin ninguna prueba de significación. Sus recomendaciones son directamente aplicables a un informe interno:

• Reportar el error estándar junto a la media, usando el teorema central del límite.
• Usar errores estándar agrupados cuando las preguntas vienen en grupos —varios casos derivados del mismo documento o del mismo cliente—, porque no son independientes.
• Analizar diferencias pareadas: los dos sistemas sobre los mismos casos, midiendo la diferencia caso a caso. Es la forma más barata de ganar potencia estadística sin ampliar el conjunto.
• Hacer análisis de potencia antes, para saber cuántos casos necesitas para detectar la diferencia que te importa.
• Generar varias respuestas por caso y promediar, para reducir el ruido de generación.

Nada de esto requiere un estadístico en plantilla. Requiere aceptar una frase incómoda en el informe: «la diferencia observada no es distinguible del ruido con este número de casos». Escribir esa frase cuando toca es lo que separa un equipo que mide de un equipo que decora.

El juez también hay que evaluarlo

Casi toda rúbrica a escala se acaba aplicando con un modelo como juez. El trabajo fundacional —Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, Zheng y otros, 2023— dio la buena noticia y la mala en la misma frase: jueces fuertes alcanzaban más del 80% de acuerdo con las preferencias humanas, el mismo nivel de acuerdo que hay entre humanos; y a la vez presentaban sesgo de posición (prefieren la primera opción), sesgo de verbosidad (prefieren respuestas largas), autoensalzamiento (prefieren su propia familia de modelos) y capacidad de razonamiento limitada en tareas que exigen cálculo.

Las contramedidas son mecánicas y baratas:

• Un criterio por llamada. No pidas una puntuación global; pide un veredicto binario con la evidencia que lo sostiene.
• Modelo juez distinto del evaluado, y a poder ser de otra familia, para no premiar el estilo propio.
• Orden alternado en comparaciones por pares: ejecutar A-B y B-A y promediar neutraliza el sesgo de posición.
• Calibración con etiquetas humanas antes de confiar, midiendo el acuerdo (kappa) sobre una muestra, y un muestreo humano permanente de en torno al 10% para detectar cuándo el juez se desalinea.

Y una observación que ordena todo lo anterior: el juez es mucho más fiable verificando un criterio binario con evidencia que puntuando calidad global. Esa es la razón técnica —no estética— por la que la rúbrica no es un refinamiento metodológico opcional: es lo que convierte al juez automático en una herramienta utilizable.

Cuando el eval se convierte en el objetivo

Toda métrica que se usa para decidir acaba siendo optimizada, y toda métrica optimizada deja de medir lo que medía. En evaluación de agentes esto tiene una forma muy concreta: al cabo de unos meses, el sistema es excelente en los 120 casos del golden set y sigue igual de flojo en producción.

Tres contramedidas que funcionan y no cuestan casi nada:

• Conjunto retenido. Un 20-30% de los casos nunca se usa para iterar. Sólo se toca para decidir promociones importantes. Si empieza a usarse para depurar, deja de ser retenido — y hay que decirlo en el informe.
• Rotación. Cada trimestre entran casos nuevos de producción y salen los que llevan seis meses en verde sin fallar nunca. Un caso que siempre pasa ya no aporta información.
• Separación de roles. Quien optimiza el sistema no escribe los criterios nuevos sin revisión de la persona de dominio. No es desconfianza: es que quien conoce el fallo tiende a escribir el criterio que su solución ya cumple.

La sensación de mejora no es evidencia

Merece la pena cerrar el argumento con el dato más incómodo de todos. En julio de 2025, METR publicó un ensayo controlado aleatorizado con desarrolladores open source experimentados trabajando en sus propios repositorios: 16 personas, 246 tareas reales. Antes de empezar preveían una aceleración del 24%. Después de la sesión, estimaban haber ido un 20% más rápido. La medición dio un 19% más lentos.

Conviene ser honesto con el alcance: METR ha marcado ese resultado como histórico —refleja herramientas y flujos de principios de 2025— y ha cambiado el diseño del experimento. La conclusión duradera no es «la IA ralentiza». Es algo más útil y más general: la percepción de mejora y la mejora medida pueden apuntar en sentidos opuestos, incluso en profesionales expertos evaluando su propio trabajo, inmediatamente después de hacerlo. Por eso «el equipo dice que va mucho mejor» no es un dato. Es un punto de partida para medir.

«Mejor» también significa «más largo»

Hay una última acepción de «mejor» que en agentes es cada vez más la que importa. METR mantiene una métrica de horizonte temporal: la longitud de tarea —medida en el tiempo que le llevaría a un profesional humano— que un agente completa con un 50% de fiabilidad. En su revisión de enero de 2026 (Time Horizon 1.1), el tiempo de duplicación posterior a 2023 se estima en unos 131 días, y a febrero de 2026 el modelo en cabeza rondaba las 14 horas y media de horizonte al 50%.

Para un equipo esto reordena la pregunta. Si la fiabilidad decae exponencialmente con la longitud de la tarea —el modelo de media vida de Ord— y el horizonte de los modelos crece rápido, la pregunta útil deja de ser «¿qué porcentaje saca mi agente?» y pasa a ser «¿hasta qué longitud de tarea aguanta con la fiabilidad que mi proceso necesita?». Esa frontera es lo que hay que medir, y es lo que se mueve cuando cambias de modelo. Fijar el 50% como umbral, además, es una convención de investigación: para un proceso de negocio sin revisión humana, el umbral relevante suele estar bastante más arriba.

La ficha de comparación: qué hace creíble un informe

Todo lo anterior se condensa en un artefacto muy poco glamuroso: la ficha con la que un equipo declara que la versión B es mejor que la A. Si le falta alguna de estas líneas, la afirmación no es verificable por nadie que no estuviera en la sala.

Los seis errores que anulan una comparación

Ninguno es exótico. Los hemos visto los seis en equipos técnicamente sólidos.

1. Comparar contra «lo que había» sin haberlo medido nunca. Si el sistema anterior nunca pasó por la rúbrica, no hay comparación: hay una versión nueva medida y un recuerdo.

2. Que la rúbrica la escriba quien optimiza el sistema. Sin mala fe, los criterios acaban pareciéndose sospechosamente a lo que la solución ya hace bien.

3. Una sola ejecución por caso. En un sistema no determinista, una pasada es una muestra de tamaño uno. Tres a cinco por caso es el mínimo razonable, y la varianza entre ellas ya es información valiosa.

4. Promediar todos los criterios por igual. Sin eliminatorios, un fallo de seguridad se diluye entre once aciertos y sale un 92% tranquilizador.

5. Cambiar dos cosas a la vez. Nuevo prompt y nuevo modelo en el mismo release: sabrás que cambió el número, no por qué. El cambio atómico no es purismo, es lo que hace atribuible el resultado.

6. Dejar el coste fuera del informe. Es el error que documenta el trabajo de Princeton, y el que produce arquitecturas caras que nadie sabe justificar seis meses después.

Las dos primeras semanas

Si ya tienes golden set —y si no, ese es el paso anterior— esto es lo que produce más señal por hora invertida.

Semana 1 · La rúbrica. Coge 25 casos y saca los criterios con la persona de dominio, preguntando qué debe aparecer y qué no puede aparecer. Reescríbelos como verificaciones binarias con evidencia localizable. Marca dos o tres eliminatorios. Y pásala por la prueba del agente nulo antes de usarla para nada.

Semana 2 · Los baselines y la ficha. Mide con esa rúbrica el agente nulo, el release actual y la ablación más simple que resuelva la tarea. Ejecuta cada caso de tres a cinco veces. Calcula la diferencia pareada con su intervalo. Rellena la ficha de nueve líneas y publícala donde la vea el equipo.

Al final de la segunda semana no tendrás un sistema mejor. Tendrás algo más valioso: la capacidad de saber, la próxima vez, si lo es. Todo el ciclo LLMOps se apoya en esa capacidad — sin ella, las puertas de calidad no pueden bloquear nada, y una puerta que no bloquea es decoración.

Medir es lo que convierte la velocidad en progreso

Hay una versión de la adopción de IA que consiste en ir muy rápido sin saber hacia dónde. Se reconoce fácil: mucha actividad, muchas demos, releases semanales, y nadie capaz de decir con un número si el sistema de hoy es mejor que el de marzo. La disciplina de la rúbrica y el baseline es lo que separa esa versión de la otra.

Es la misma lógica que aplicamos al código con Spec-Driven Development: escribir el criterio antes que el artefacto. En los programas onext AI-Accelerated Development, la rúbrica y los baselines son parte del harness que dejamos instalado, no un entregable posterior. Los resultados que firmamos con clientes en 2026 —×7 velocidad de entrega, 0 sprints perdidos, −50% time-to-production— se sostienen precisamente sobre eso: equipos que despliegan rápido porque saben, antes de desplegar, si el cambio es bueno.

Preguntas frecuentes

¿Qué es una rúbrica en la evaluación de agentes de IA?

Es un conjunto explícito de criterios que convierte un juicio holístico —«esta respuesta es buena»— en verificaciones discretas y comprobables una por una. Cada criterio se escribe como una comprobación binaria con evidencia localizable en la traza: qué tiene que aparecer, qué no puede aparecer nunca, qué herramienta debía usarse. No es una escala de 1 a 10 de calidad global: pedirle a un juez que puntúe «la calidad» produce un número poco reproducible, mientras que pedirle que verifique doce criterios concretos produce doce respuestas auditables.

¿Cómo se construye una rúbrica a partir del golden set?

Con veinte o treinta casos ya etiquetados, se le pregunta a la persona de dominio caso por caso qué tiene que aparecer sí o sí y qué no puede aparecer nunca — no «¿esto está bien?». Las respuestas recurrentes se convierten en criterios generales; el resto, en criterios específicos de cada caso. Después cada criterio se reescribe como verificación binaria, se pondera y se marca cuáles son eliminatorios. HealthBench, de OpenAI, es la referencia industrial del método: 5.000 conversaciones con rúbricas escritas por 262 médicos y 48.562 criterios ponderados por importancia.

¿Qué diferencia hay entre pass@k y pass^k, y cuál importa en producción?

pass@k mide si el agente acierta al menos una vez en k intentos: es potencial, y es la métrica adecuada cuando existe un verificador barato que descarta los intentos malos (compilar, pasar tests). pass^k mide si acierta las k veces: es fiabilidad, y es la métrica adecuada cuando la salida va a producción sin red. En τ-bench, agentes con menos del 50% de éxito en una sola pasada caían por debajo del 25% en pass^8. En negocio, la k correcta es el número de veces que el proceso se ejecuta antes de que un humano lo revise.

¿Cuántos casos hacen falta para afirmar que un sistema es mejor que otro?

Más de los que la mayoría de equipos usa. Con 50 casos y una tasa de acierto cercana al 80%, el error estándar ronda los 5-6 puntos: una mejora de 3 puntos es indistinguible del ruido. La forma barata de ganar potencia estadística no es multiplicar casos sino comparar en pareado —los dos sistemas sobre los mismos casos, midiendo la diferencia caso a caso— y ejecutar cada caso varias veces para promediar el no determinismo. Es exactamente lo que recomienda el trabajo de Anthropic sobre barras de error en evaluaciones.

¿Contra qué baseline hay que comparar un agente?

Contra cuatro, no contra uno: el agente nulo (que no hace nada, para validar que la rúbrica no regala puntos), el sistema anterior, el humano que hoy hace la tarea con su coste y su tasa de error reales, y la ablación —la versión más simple de tu propio sistema—. Esta última es la que más sorpresas da: el trabajo de Princeton «AI Agents That Matter» mostró baselines simples dominando en Pareto a agentes de última generación con 50 veces menos coste. Sin ablación no sabes si tu arquitectura agéntica aporta calidad o sólo factura.

¿Puedo fiarme de que el equipo diga que el agente va mucho mejor?

No como dato. En el ensayo controlado de METR con desarrolladores open source experimentados, los participantes preveían un 24% de aceleración, tras la sesión estimaban un 20% de aceleración, y la medición dio un 19% de ralentización. METR ha marcado ese resultado como histórico y ha cambiado el diseño del experimento, así que la conclusión duradera no es «la IA ralentiza»: es que la percepción de mejora y la mejora medida pueden apuntar en sentidos opuestos, incluso en expertos evaluando su propio trabajo.

Fuentes citadas

• Yao, Shinn, Razavi, Narasimhan (Sierra) — τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (métrica pass^k)
• Kapoor, Stroebl, Siegel, Nadgir, Narayanan (Princeton) — AI Agents That Matter (evaluación con control de coste, frontera de Pareto)
• Zhu y otros — Establishing Best Practices for Building Rigorous Agentic Benchmarks (validez de tarea y de resultado, NeurIPS 2025)
• OpenAI — HealthBench (rúbricas escritas por médicos, 48.562 criterios ponderados)
• Zhuge y otros — Agent-as-a-Judge: Evaluate Agents with Agents (evaluación de trayectoria, ICML 2025)
• Miller, E. (Anthropic) — Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations
• Zheng y otros — Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (sesgos del juez)
• Chen, Han, Yan, Zhu, Sun, Che — From Holistic Evaluation to Structured Criteria: Rubrics Across the Evolving LLM Landscape (junio 2026)
• Ord, T. — Is there a half-life for the success rates of AI agents? (decaimiento exponencial con la longitud de tarea)
• METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity y Time Horizon 1.1 (enero 2026)