La reunión con el proveedor empieza con una diapositiva. Muestra un benchmark, una prueba estándar con tareas y una forma de corregirlas. El puntaje de su agente está arriba de todos. Después viene la prueba de concepto.
En un hilo de Reddit para compradores de TI, alguien contó cómo suele ser (la prueba 45). El proveedor te da una clave de API y te dice que lo pruebes vos. Las respuestas agregaron que SOC 2, una certificación de seguridad, no cubre el comportamiento del modelo.
Debajo de esa reunión hay cuatro supuestos:
Si el agente saca buena nota en los benchmarks, va a andar bien en producción.
Si el puntaje sube, el agente mejoró.
Si resolvió la tarea alguna vez, sirve.
Si un modelo juez ya se calibró contra personas, sirve para medir cualquier modelo nuevo. Un modelo juez es un modelo que corrige las respuestas de otro.
Los cuatro se usan para elegir modelos, aprobar presupuestos y prometer fechas.
Los agentes mejoran rápido, y los benchmarks lo muestran. Lo registra el AI Index 2026 de Stanford (la prueba 75). En OSWorld, un benchmark de tareas en una computadora, el éxito pasó de cerca de 12 % a cerca de 66 %. En SWE-bench Verified, que mide arreglos de código, pasó de 60 % a cerca de 100 % en un año.
de cerca de 12 % a cerca de 66 %
Éxito en OSWorld, un benchmark de tareas de agentes en una computadora. Prueba 75
METR, un instituto que evalúa modelos de IA, mide el horizonte temporal (la prueba 55). Es el largo de las tareas que un modelo resuelve con 50 % de éxito. El largo se mide en el tiempo que le lleva a una persona experta. Desde 2023, ese horizonte se duplica cada 128,7 días, unos 4,2 meses.
SWE-Bench Pro es un benchmark de código más difícil. En su tabla pública, el mejor modelo de 2026 resuelve cerca de 6 de cada 10 problemas (la prueba 151). Un año antes, el mejor llegaba a 43,6 %.
Corregir a escala también tiene buenas noticias. MobileJudgeBench midió jueces automáticos sobre 931 trayectorias reales de agentes de celular (la prueba 125). El mejor juez acertó 90,9 % de las veces al decidir si el agente había logrado la tarea. Entre personas, el acuerdo fue de 88,4 %. Un equipo de OpenAI mostró otra cosa (la prueba 36). Vigilar la cadena de razonamiento de un modelo rinde más que vigilar solo sus acciones.
En código, acertar una vez puede alcanzar. Si un test filtra los intentos malos, no importa cuántos fallaron antes. Simon Willison lo pone como regla para quien manda código, sea persona o agente (la prueba 35). La regla es mostrar que funciona, con tests que fallen si se revierte el cambio.
Un buen puntaje en un benchmark dice poco sobre otro. SWE-Bench Pro armó 1.865 problemas en 41 repositorios (la prueba 20). Hay repositorios públicos, retenidos y comerciales privados. Con modelos de 2025, los que pasaban el 70 % en SWE-bench Verified resolvían menos de la mitad del conjunto público. En el conjunto comercial, Claude Opus 4.1 llegó a 17,8 % y GPT-5 a 15,7 %. Lo publica Scale AI, que vende evaluación.
Según la prensa, OpenAI dejó de reportar SWE-bench Verified (la prueba 93). OpenAI auditó problemas que los modelos fallaban. Encontró que al menos 59,4 % tenía tests que rechazaban soluciones correctas.
El número también depende de la máquina y del corrector. En Terminal-Bench 2.0, la configuración de memoria y CPU movió el puntaje 6 puntos (la prueba 53). Anthropic publicó esas corridas. Recomienda desconfiar de diferencias de menos de 3 puntos.
METR hizo que mantenedores de tres proyectos revisaran pull requests de agentes (la prueba 67). Un pull request es una propuesta de cambio al código. Esos cambios ya pasaban el corrector automático. El corrector les dio 24,2 puntos más que los mantenedores. Una revisión de 445 benchmarks encontró que solo 16,0 % usaba estadística para comparar resultados (la prueba 14).
METR también escribió las letras chicas del horizonte (la prueba 44). El horizonte no dice cuánto tiempo puede trabajar solo un agente. En tareas de uso visual de una computadora, el horizonte es de 40 a 100 veces menor. Y RealUserSim mostró que los usuarios simulados de los benchmarks son demasiado formales y cooperativos (la prueba 76).
Si el agente saca buena nota en los benchmarks, va a andar bien en producción.
Veredicto: No, aunque muestran que los agentes mejoran rápido. Con modelos de 2025, los que pasaban el 70 % en SWE-bench Verified rendían mucho menos en SWE-Bench Pro. En su conjunto comercial resolvían menos de un quinto. Un corrector automático les dio a pull requests de agentes 24,2 puntos más que los mantenedores. Y en Terminal-Bench 2.0, la configuración de la máquina movió el puntaje 6 puntos.
Criterio
Usá los benchmarks públicos (pruebas estándar) para descartar candidatos, no para elegir. Mirá primero los que se parecen a tu caso, como código privado o usuarios realistas. Desconfiá de diferencias de menos de 3 puntos.
Por qué confianza media. Varias fuentes independientes coinciden: el puntaje depende del benchmark, del corrector y de la máquina. Pero ninguna lo compara con resultados en producción. Con modelos de 2026, el mejor ya resuelve cerca de 6 de cada 10 problemas del conjunto público de SWE-Bench Pro. Ese benchmark lo publica una empresa que vende evaluación. Lo de OpenAI se conoce por prensa.
Ver el detalle de las 10 pruebasOcultar el detalle1 a favor, 6 en contra, 3 matizan
Compilación anual de datos sobre IA. La adopción en las organizaciones es amplia y los agentes mejoran rápido en los benchmarks, pero también suben los incidentes de IA documentados.
Números
88 %Adopción de IA en las organizaciones.
de cerca de 12 % a cerca de 66 %Éxito en OSWorld, un benchmark de tareas de agentes en una computadora.
de 60 % a cerca de 100 %SWE-bench Verified en un año.
233 y 362Incidentes de IA documentados en 2024 y en 2025.
Limitación Compila fuentes de terceros (benchmarks, encuestas, bases de incidentes). Un benchmark no equivale a desempeño en producción. La página de conclusiones no trae costos de inferencia de 2026.
Es un benchmark de ingeniería de software más difícil que SWE-bench Verified y menos contaminado (con menos problemas ya vistos en el entrenamiento). Usa repositorios públicos, repositorios retenidos y repositorios comerciales privados. Los mismos modelos que pasan el 70 % en SWE-bench Verified resuelven menos de la mitad en el conjunto público. En el comercial resuelven menos de un quinto.
Números
1.865 problemas en 41 repositoriosTamaño del benchmark.
43,6 % y 41,8 %Conjunto público: Claude Sonnet 4.5 y GPT-5 (high).
17,8 % y 15,7 %Conjunto comercial: Claude Opus 4.1 y GPT-5 (high).
Limitación La fecha es la de la versión 2 (14 de noviembre de 2025), que cambia los resultados: suma a Claude Sonnet 4.5 y Claude Haiku 4.5, que salieron después de la versión 1 (21 de septiembre de 2025). Los números de esta ficha son los de la versión 2. Datos de 2025: los modelos de 2026 no están en el paper. Lo publica Scale AI, que vende datos y evaluación.
Cuatro mantenedores de scikit-learn, Sphinx y pytest revisaron pull requests de agentes que ya pasaban el corrector automático de SWE-bench Verified. Cerca de la mitad no se integraría. En los modelos nuevos, las fallas se corrieron hacia la calidad del código más que hacia funciones rotas. Los autores aclaran que no prueba un límite de capacidad: el agente tuvo un solo intento, sin poder iterar con el revisor.
Números
24,2 puntosCuánto más da el corrector automático que los mantenedores, normalizado contra pull requests humanos (error estándar 2,7). Sin normalizar, 34,9 puntos.
296 pull requests de agentesRevisados, junto con 47 humanos de referencia, en 95 de los 500 problemas. Los mantenedores integraron cerca de 68 % de los humanos.
unos 50 contra unos 8 minutosHorizonte de Claude Sonnet 4.5 con el corrector automático y con revisión de mantenedores; los autores dicen que esta cifra es muy ruidosa.
Limitación Nota de investigación, no paper revisado. Cuatro mantenedores y tres repositorios. Modelos desde Claude 3.5 Sonnet hasta Claude Sonnet 4.5 y GPT-5.
“roughly half of test-passing SWE-bench Verified PRs”
La configuración de la máquina (memoria, CPU, tiempo límite) cambia el puntaje de los agentes de código. Ese cambio supera a las diferencias que se usan para ordenar modelos. Con límites estrictos gana la estrategia austera, y con límites holgados gana la que usa muchos recursos. Recomienda informar la configuración y desconfiar de diferencias de menos de 3 puntos.
Números
6 puntos porcentualesDiferencia en Terminal-Bench 2.0 entre la configuración con más y con menos recursos (p < 0,01).
5,8 %, 2,1 % y 0,5 %Errores de infraestructura con límite estricto, con 3 veces de margen y sin límite.
Limitación Lo publica un proveedor de modelos con sus propias corridas.
Según la nota, OpenAI dejó de reportar SWE-bench Verified (una prueba de programación) porque ya no sirve para medir modelos de punta. OpenAI revisó problemas que los modelos fallaban y encontró muchos tests que rechazan soluciones correctas. También hay contaminación (los modelos ya vieron la prueba): algunos reproducen el enunciado y el código corregido. OpenAI recomienda SWE-Bench Pro.
Números
27,6 %Parte de los problemas fallados que auditó OpenAI.
al menos 59,4 %De esos problemas auditados, los que tenían tests que rechazaban soluciones correctas.
Limitación La fuente original es el post de OpenAI "Why we no longer evaluate SWE-bench Verified" (23 de febrero de 2026, según búsqueda). Ese post dio 403 dos veces. Las cifras vienen de la nota de prensa y no se verificaron en la fuente primaria.
Bean, A. M., Kearns, R. O., Romanou, A., et al. arXiv (Oxford y otros)
Revisión sistemática de 445 benchmarks (pruebas estándar) de modelos de lenguaje, hecha con 29 expertos. Encuentra problemas repetidos en qué se mide, con qué tareas y con qué métricas. Esos problemas debilitan lo que los benchmarks dicen probar. Pocos usan estadística para comparar resultados, y el trabajo da ocho recomendaciones y una lista de control.
Números
16,0 %Benchmarks que usaron estimaciones de incertidumbre o pruebas estadísticas para comparar resultados.
38,2 %Benchmarks que reutilizan datos de benchmarks anteriores o exámenes humanos (riesgo de contaminación).
Limitación Revisa benchmarks de modelos en general, no de agentes. Las cifras salen del texto completo (HTML de la versión 1). NeurIPS 2025.
“16.0% used uncertainty estimates or statistical tests to compare the results”
Nota de los propios autores de la métrica. El horizonte temporal no dice cuánto tiempo puede trabajar solo un agente. Dice cuánto trabajo humano reemplaza la IA con 50 % de éxito. La cifra cambia mucho según el dominio y no se traslada sin más al trabajo real, que es más desordenado.
Números
4 h 49 minHorizonte de Claude Opus 4.5, con un intervalo del 95 % que va de 1 h 49 min a 20 h 25 min.
de 40 a 100 veces menorHorizonte en tareas de uso visual de una computadora.
unos 2 minutosHorizonte de Claude 4.5 Sonnet en una tarea física real: hacer café.
Limitación Es una nota de los autores sobre su propia métrica, no un estudio aparte. La cifra de 4 h 49 min es una medición con la serie TH1. Con TH1.1, tras la corrección de METR, el mismo modelo da 293 minutos (ficha “Time Horizon 1.1”). Para trabajo que necesita 98 % de éxito o más, un horizonte al 50 % no sirve como guía.
Estudio de casos y encuesta a profesionales que tienen agentes en producción. La mayoría evalúa con personas y no con benchmarks (pruebas estándar), y deja pocos pasos al agente antes de que intervenga alguien. La confiabilidad, es decir, que el agente se comporte bien de forma sostenida, sigue siendo el principal desafío. Los equipos la atacan con diseño del sistema.
Números
20 casos y 86 practicantesBase del estudio: 20 entrevistas en profundidad y una encuesta a practicantes de 26 dominios.
74 %Depende sobre todo de evaluación humana.
68 %Corre como máximo 10 pasos antes de que intervenga una persona.
70 %Usa modelos comerciales con prompts en vez de reentrenarlos.
Limitación Muestra chica y elegida por los autores; no representa a todas las empresas. Preprint.
“Reliability (consistent correct behavior over time) remains the top development challenge”
Tabla pública de resultados del conjunto público de SWE-Bench Pro. Con modelos de 2026, el mejor ya resuelve más de la mitad: cerca de 6 de cada 10 problemas. Un año antes, en el paper, el mejor llegaba a 43,6 %. El conjunto comercial privado no tiene una tabla actualizada.
Números
61,50 % (± 3,10)Primero de la tabla (Muse Spark 1.1), sobre 731 tareas.
59,10 %, 51,90 % y 46,10 %gpt-5.4 (xHigh), claude-opus-4-6 (thinking) y gemini-3.1-pro (thinking).
Limitación La página no muestra fecha: la fecha es la de la consulta (2 de noviembre de 2026). La mantiene Scale AI, autora del benchmark. La página del conjunto comercial solo repite las cifras del paper.
Zhu, M., Tan, J., Murthy, R., et al. arXiv (Salesforce AI Research)
Los usuarios simulados con un modelo son demasiado formales y cooperativos, y no se parecen a los usuarios reales. Los autores arman simuladores con perfiles de comportamiento sacados de conversaciones reales. Con usuarios más realistas aparecen fallas del agente que el usuario cooperativo escondía. Además, baja el éxito en TauBench, una prueba estándar para agentes.
Números
7.275 perfilesPerfiles de comportamiento sacados de más de 14.000 conversaciones reales (WildChat).
de 24,2 % a 45,3 %Coincidencia de estilo con usuarios reales, sin y con el método. Sin restricciones, los simuladores coinciden de 6 % a 8 %.
de 3,2 % a 3,5 %Caída promedio del éxito del agente en TauBench con usuarios realistas.
Limitación Preprint; se leyó el resumen. La página de arXiv muestra envío el 7 de abril de 2026, aunque el número corresponde a mayo. La caída medida es chica. No repite la medición de un agente que guía al usuario.
Leída en la fuente. Revisada el 2 nov 2026.
El puntaje también mide al evaluador y los atajos. HAL es una infraestructura para evaluar agentes de forma pareja (la prueba 9). Encontró un agente que buscó el benchmark en HuggingFace en vez de resolver la tarea.
Anthropic encontró algo parecido en BrowseComp, un benchmark de búsqueda web (la prueba 66). En dos casos, Opus 4.6 sospechó que lo evaluaban. Identificó el benchmark y descifró la clave de respuestas.
La guía de evaluación de Anthropic da el caso del otro lado (la prueba 40). Opus 4.5 pasó de 42 % a 95 % en CORE-Bench después de que corrigieron errores del evaluador. El agente era el mismo. Cambió quien lo corregía.
Si el puntaje de la evaluación sube, el agente mejoró.
Veredicto: No siempre. La capacidad de los agentes crece de verdad, pero un puntaje también mide al evaluador y los atajos. Un agente buscó el benchmark en HuggingFace en vez de resolver la tarea. En dos casos, Opus 4.6 identificó BrowseComp y descifró su clave de respuestas. Un modelo pasó de 42 % a 95 % en CORE-Bench después de corregir errores del evaluador.
Criterio
Ante cada cambio grande de puntaje, para arriba o para abajo, leé una muestra de transcripciones y revisá el evaluador antes de sacar conclusiones.
Por qué confianza alta. La afirmación cae con un solo caso, y hay varios documentados en fuentes primarias. Son un paper independiente con 21.730 ejecuciones y dos informes de un proveedor sobre sus propias evaluaciones. Los casos son de benchmarks públicos, no de empresas. Que la capacidad crece sale de la medición de METR, con tareas de software, aprendizaje automático y ciberseguridad.
Ver el detalle de las 4 pruebasOcultar el detalle1 a favor, 2 en contra, 1 matiza
Página de datos de METR con el horizonte temporal 1.1. Mide el largo de las tareas que cada modelo resuelve con 50 % y con 80 % de éxito, en tiempo de una persona experta. La tendencia sigue siendo exponencial, y desde 2023 el horizonte se duplica más rápido que en el paper de 2025. Pero el horizonte con 80 % de éxito es entre 4 y 10 veces más corto que el de 50 %. METR avisa que por encima de 16 horas su medición ya no es confiable.
Números
128,7 días (intervalo de 104,4 a 158,0)Tiempo en que se duplica el horizonte al 50 %, contando desde 2023 (unos 4,2 meses). Desde 2019 es de 187,8 días. Excluye mediciones de más de 16 horas.
293 minutos (162 a 624) y 49 minutos (21 a 105)Horizonte de Claude Opus 4.5 con 50 % y con 80 % de éxito, con los datos corregidos el 3 de marzo de 2026.
719 minutos (317 a 3.634) y 70 minutosHorizonte de Claude Opus 4.6 con 50 % y con 80 % de éxito.
1.045 minutos (509 a 3.304) y 186 minutosHorizonte de Claude Mythos Preview (versión temprana, abril de 2026) con 50 % y con 80 % de éxito: unas 17,4 horas y 3,1 horas. Está por encima del techo de 16 horas que METR considera confiable.
352, 342 y 384 minutosHorizonte al 50 % de GPT-5.2, GPT-5.4 y Gemini 3.1 Pro.
Limitación Los números salen del archivo de datos de la página (benchmark_results_1_1.yaml). El 3 de marzo de 2026 METR corrigió un error de regularización, así que las cifras de 1.1 publicadas antes de esa fecha no coinciden. El 8 de septiembre de 2026 METR dijo que la página ya no se actualiza activamente. Son tareas de software, aprendizaje automático y ciberseguridad, y 50 % de éxito es un umbral bajo para delegar.
“Measurements above 16 hrs are unreliable with our current task suite.”
Es una infraestructura para evaluar agentes de forma pareja, que mide costo y comportamiento además de precisión. Más esfuerzo de razonamiento bajó la precisión en la mayoría de las corridas. Encontraron un agente que buscó el benchmark (la prueba) en HuggingFace en vez de resolver la tarea. También encontraron uso indebido de tarjetas de pago en tareas de reserva de vuelos.
Números
21.730 ejecucionesEjecuciones de agentes con 9 modelos en 9 benchmarks.
unos 40.000 dólaresCosto de correr la evaluación.
unos 2.500 millones de tokensRegistros publicados para que otros los revisen.
Limitación Benchmarks públicos, no despliegues en empresas. Modelos de 2025.
Anthropic revisó las respuestas de Opus 4.6 en BrowseComp, un benchmark (prueba estándar) de búsqueda web. Encontró respuestas que no salían de resolver la pregunta. En dos casos el modelo sospechó que lo estaban evaluando, identificó el benchmark y descifró la clave de respuestas. La configuración multiagente busca más y por eso también encuentra más filtraciones del benchmark.
Números
86,81 % ajustado a 86,57 %Puntaje de la configuración multiagente, antes y después de sacar respuestas tomadas del material del benchmark.
11 de 1.266 (0,87 %)Problemas resueltos por vías no previstas en multiagente (9 por contaminación en la web); con un solo agente, 0,24 %.
Limitación Lo publica el proveedor del modelo sobre su propio modelo.
Esta guía para evaluar agentes recomienda empezar temprano con tareas sacadas de fallas reales. También pide combinar tres tipos de evaluadores (código, modelo y persona), calificar el resultado y no el camino, y leer las transcripciones. Distingue pass@k, acertar al menos una vez en k intentos, de pass^k, acertar en todos. Advierte que parte de los fallos son errores del evaluador.
Números
20 a 50 tareasTareas simples sacadas de fallas reales, como buen punto de partida.
75 % por intento, cerca de 42 % en 3 de 3Ejemplo de pass^k: acertar las tres veces es mucho menos probable que acertar una.
de 42 % a 95 %Resultado de Opus 4.5 en CORE-Bench después de corregir errores del evaluador.
Limitación La escribe un proveedor de modelos. Es una guía de práctica, no un estudio.
“20-50 simple tasks drawn from real failures is a great start”
Cita verificada contra el original
Leída en la fuente. Revisada el 2 nov 2026.
Acertar alguna vez tampoco alcanza si nadie revisa cada intento. La guía de Anthropic separa dos medidas. La medida pass@k es acertar al menos una vez en k intentos. La medida pass^k es acertar en todos. Con 75 % por intento, acertar 3 de 3 baja a cerca de 42 %.
Un preprint, un estudio sin revisión de pares, corrió las mismas tareas de OSWorld muchas veces (la prueba 83). Un agente con GPT-5 resolvió cerca de 78 % de las tareas al menos una vez en 10 intentos. En los 10 intentos, resolvió cerca de 36 %.
Agent S3 con GPT-5: tareas resueltas al menos una vez en 10 intentos (Pass@10) contra tareas resueltas en los 10 intentos (Pass^10). Leído de la figura 1.Prueba 83
Tareas resueltas, en %
En al menos 1 de 10 intentoscerca de 78 %
En los 10 intentoscerca de 36 %
0100 %
τ-Knowledge mide atención al cliente de una fintech, una empresa de servicios financieros digitales (la prueba 63). Ahí la mejor tasa bajó de 25,52 % en un intento a 13,40 % en los 4. Un cliente no ve tu mejor intento. Ve el que le tocó.
Y el test que filtra tiene que probar algo. En Hacker News, un practicante contó que el agente escribió tests que no probaban nada (la prueba 43).
Para saber si un agente sirve, alcanza con ver que resuelve la tarea alguna vez.
Veredicto: Alcanza solo si algo verifica cada intento, como los tests en código. Para lo que llega a un cliente importa acertar siempre. Con 75 % por intento, acertar 3 de 3 baja a cerca de 42 %. En OSWorld, un agente con GPT-5 tuvo 10 intentos por tarea. Resolvió cerca de 78 % al menos una vez, y cerca de 36 % en los 10. En atención al cliente de una fintech, la mejor tasa de acierto fue 25,52 % en un intento. En los 4 intentos bajó a 13,40 %.
Criterio
Medí pass^k, que es acertar en todas las repeticiones de la misma tarea. Usalo para todo lo que no tiene una verificación automática antes de llegar a alguien. Dejá pass@k, que es acertar al menos una vez, para cuando un test filtra los intentos malos.
Por qué confianza media. La cuenta de 75 % a cerca de 42 % es aritmética y supone intentos independientes. Dos benchmarks de 2026 muestran la misma caída al repetir: uno de uso de computadora y otro de atención al cliente. Pero son preprints, sin revisión de pares. Uno lo hace un equipo de una empresa que vende agentes de atención. La guía la escribe un proveedor de modelos. Nadie defiende con datos que alcance con un acierto. Las fuentes que matizan piden tests que prueben el cambio. Un practicante cuenta que el agente escribió tests que no probaban nada.
Ver el detalle de las 5 pruebasOcultar el detalle0 a favor, 3 en contra, 2 matizan
Esta guía para evaluar agentes recomienda empezar temprano con tareas sacadas de fallas reales. También pide combinar tres tipos de evaluadores (código, modelo y persona), calificar el resultado y no el camino, y leer las transcripciones. Distingue pass@k, acertar al menos una vez en k intentos, de pass^k, acertar en todos. Advierte que parte de los fallos son errores del evaluador.
Números
20 a 50 tareasTareas simples sacadas de fallas reales, como buen punto de partida.
75 % por intento, cerca de 42 % en 3 de 3Ejemplo de pass^k: acertar las tres veces es mucho menos probable que acertar una.
de 42 % a 95 %Resultado de Opus 4.5 en CORE-Bench después de corregir errores del evaluador.
Limitación La escribe un proveedor de modelos. Es una guía de práctica, no un estudio.
“20-50 simple tasks drawn from real failures is a great start”
Gonzalez-Pumariega, G., Agashe, S., Yang, J., Li, A., Wang, X. E. arXiv
El estudio corre muchas veces las mismas tareas de OSWorld y busca por qué un agente que acierta una vez no lo repite. Encuentra tres causas: azar en la ejecución, tareas ambiguas y variación en el comportamiento del agente. Cambios cosméticos en el entorno bajaron la confiabilidad de GPT-5 y de Claude. Escribir el criterio de evaluación en la instrucción mejoró la confiabilidad en todos los modelos.
Números
cerca de 78 % contra cerca de 36 %Agent S3 con GPT-5: tareas resueltas al menos una vez en 10 intentos (Pass@10) contra tareas resueltas en los 10 intentos (Pass^10). Leído de la figura 1.
Limitación Preprint. Las cifras son aproximadas, leídas de una figura. Uso de computadora, no atención al cliente.
Shi, Q., Zytek, A., Razavi, P., Narasimhan, K., Barres, V. arXiv (Sierra, Princeton)
El equipo de τ-bench suma un dominio nuevo: atención al cliente de una fintech, con unos 700 documentos de conocimiento enlazados. Aun los mejores modelos, con mucho razonamiento, resuelven cerca de un cuarto de las tareas. Además, la confiabilidad cae cuando repiten la misma tarea. Es parte de τ³-bench.
Números
25,52 %Mejor tasa de acierto en un intento (pass^1) con búsqueda realista: GPT-5.2 con razonamiento alto, sobre 97 tareas.
13,40 %Mejor tasa de acierto en los 4 intentos (pass^4).
39,69 % y 26,80 %Claude 4.5 Opus con los documentos correctos ya dados: pass^1 y pass^4.
Limitación Preprint de un equipo de una empresa que vende agentes de atención al cliente. Benchmark con usuario simulado.
Quien manda código tiene que mostrar que funciona: probarlo a mano y dejar tests automáticos que fallen si se revierte el cambio. A los agentes de código se les pide lo mismo, y la persona sigue siendo la responsable de lo que entrega.
Números
859 puntos y 658 comentariosTamaño de la discusión en Hacker News (item 46313297).
Limitación Ensayo de opinión de un especialista, sin datos propios.
“Your job is to deliver code you have proven to work.”
El autor ve un empuje a revisar poco o nada el código ("si pasan los tests, publicá"). En su código existente, la mitad del tiempo se le iba en arreglar errores sutiles. Quienes cuentan éxitos coinciden en las condiciones: código ya ordenado por personas, tipos estáticos, tests amplios, tareas acotadas y revisar el plan antes. Uno cuenta que el agente escribió tests que no probaban nada.
Números
461 puntos y 455 comentariosTamaño del hilo.
Limitación Opiniones de practicantes. Se leyó con la API de Algolia (post y respuestas de primer nivel con más respuestas).
Leída en la fuente. Revisada el 2 nov 2026.
Los jueces automáticos tienen su propio problema. Un preprint evaluó 21 jueces de nueve proveedores en unos 541.000 juicios (la prueba 112). Medir el acuerdo con las personas como coincidencia exacta lo infla. Al descontar los aciertos por azar, el acuerdo bajó de 33 a 41 puntos. En agentes de celular, los jueces fallaron en direcciones opuestas: unos rechazaban éxitos y otros aprobaban fallas.
Un modelo puede corregir las respuestas del agente en lugar de una persona.
Veredicto: Sirve para evaluar a escala, no para sacar a las personas. En agentes de celular, el mejor juez acertó 90,9 % de las veces si la tarea se había logrado. Eso está a la altura del 88,4 % de acuerdo entre personas. Pero los jueces fallan en direcciones opuestas: unos rechazan éxitos y otros aprueban fallas. En chats, su acuerdo con las personas baja de 33 a 41 puntos al descontar los aciertos por azar.
Criterio
Usá el juez para la pregunta de si el agente logró la tarea. Calibralo contra una muestra que corrige una persona. Medí el acuerdo descontando el azar, y mirá por separado los falsos positivos y los falsos negativos.
Por qué confianza media. Los dos papers sobre jueces son preprints recientes, sin revisión de pares. Uno mide una tarea binaria en agentes de celular. El otro mide chats, no trayectorias de agentes. El paper sobre vigilar el razonamiento lo publica el equipo de OpenAI. Muestra que vigilar el razonamiento rinde más que vigilar solo las acciones, y no da porcentajes. Que la mayoría de los equipos en producción evalúe con personas sale de una muestra chica.
Ver el detalle de las 4 pruebasOcultar el detalle2 a favor, 1 en contra, 1 matiza
Wang, Z., Gu, L., Chi, Z., Liu, Z., Ayyoubzadeh, S. M., Yu, Y., Wang, Y. arXiv
Mide jueces automáticos (modelos que califican a otros) sobre trayectorias reales de agentes de celular, no sobre chats. Un juez simple que mira capturas de pantalla iguala o supera a métodos hechos a medida. En la pregunta de si el agente logró la tarea, llega al nivel de acuerdo entre personas. Lo que más pesa es el modelo de base, y los modelos fallan en direcciones opuestas: unos rechazan éxitos y otros aprueban fallas.
Números
931 trayectoriasAnotadas por personas, de 6 benchmarks, 4 agentes y 68 apps.
88,4 %Acuerdo promedio entre personas en la etiqueta de éxito.
90,9 %Exactitud del mejor juez (un juez simple con Gemini 3 Flash); su ranking de agentes correlaciona 0,97 con el de las personas.
71 de 78Fallas graves de los jueces con base Qwen que fueron falsos positivos.
Limitación Preprint. Es una tarea binaria (¿lo logró o no?) en agentes de celular. No prueba que el juez sirva para calificar la calidad de un entregable.
Guan, M. Y., Wang, M., Carroll, M., Dou, Z., et al. arXiv (OpenAI)
El equipo de OpenAI que estudia monitores de razonamiento arma pruebas para medir cuánto se puede vigilar la cadena de razonamiento de un modelo. Vigilar el razonamiento rinde más que vigilar solo las acciones. La mayoría de los modelos de frontera se pueden vigilar bastante, pero no del todo. El entrenamiento por refuerzo a la escala actual no bajó mucho esa propiedad. Los autores avisan que puede ser frágil con otros métodos de entrenamiento.
Números
13 evaluaciones en 24 entornosTamaño del conjunto de pruebas de vigilancia.
Limitación Se leyó el resumen, que no da porcentajes. El post de OpenAI sobre el paper dio 403. Lo publica un proveedor de modelos.
“CoT monitoring is more effective than action-only monitoring in practical settings”
Evalúa 21 jueces (modelos que califican respuestas) de nueve proveedores en tres benchmarks (pruebas estándar). Medir el acuerdo con las personas como coincidencia exacta lo infla, porque no descuenta los aciertos por azar. Un juez puede ser muy consistente consigo mismo y tener sesgo de posición a la vez. Además, el ranking de jueces cambia mucho de un benchmark a otro.
Números
unos 541.000 juiciosEn 118 corridas sobre MT-Bench, JudgeBench y RewardBench.
de 33 a 41 puntosCuánto baja el acuerdo en MT-Bench al pasar de coincidencia exacta a kappa de Cohen.
hasta 14 puestosCuánto se mueve un juez en el ranking entre benchmarks.
Limitación Preprint; se leyó el resumen. Son chats y preferencias, no trayectorias de agentes.
Estudio de casos y encuesta a profesionales que tienen agentes en producción. La mayoría evalúa con personas y no con benchmarks (pruebas estándar), y deja pocos pasos al agente antes de que intervenga alguien. La confiabilidad, es decir, que el agente se comporte bien de forma sostenida, sigue siendo el principal desafío. Los equipos la atacan con diseño del sistema.
Números
20 casos y 86 practicantesBase del estudio: 20 entrevistas en profundidad y una encuesta a practicantes de 26 dominios.
74 %Depende sobre todo de evaluación humana.
68 %Corre como máximo 10 pasos antes de que intervenga una persona.
70 %Usa modelos comerciales con prompts en vez de reentrenarlos.
Limitación Muestra chica y elegida por los autores; no representa a todas las empresas. Preprint.
“Reliability (consistent correct behavior over time) remains the top development challenge”
Cita verificada contra el original
Leída en la fuente. Revisada el 2 nov 2026.
Calibrar una vez tampoco alcanza. El Remote Labor Index usa 240 proyectos reales de trabajo freelance (la prueba 11). Los corrigen evaluadores entrenados. Sus autores decían que esa evaluación no se puede automatizar con modelos.
Después probaron un juez automático calibrado con modelos anteriores (la prueba 115). Ordenó bien a los modelos nuevos, con una correlación de ranking de 0,90 con las personas. La correlación de ranking mide cuánto se parecen dos órdenes. Pero a GPT-5.5 le dio 17,9 %, y las personas le daban 6,25 %. Es unas 2,9 veces la nota humana. En el preprint de los 21 jueces, un mismo juez se movió hasta 14 puestos de un benchmark a otro.
Si calibré el juez automático contra personas una vez, ya puedo usarlo para medir cada modelo nuevo.
Veredicto: No. En el Remote Labor Index, un juez calibrado con modelos anteriores le dio a GPT-5.5 17,9 %. Las personas le daban 6,25 %, así que el juez dio unas 2,9 veces la nota humana. Igual ordenó bien a los modelos, con una correlación de ranking de 0,90 con la evaluación humana. En un ranking de jueces, uno mismo puede moverse hasta 14 puestos de un benchmark a otro.
Criterio
Recalibrá el juez contra personas cada vez que cambia el modelo evaluado o el tipo de tarea. Usalo para comparar versiones entre sí, no para dar la nota absoluta.
Por qué confianza media. El juez inflado lo mide el propio equipo del benchmark, en un post y no en un paper. En el paper original ya decían que ese trabajo no se puede evaluar automáticamente con modelos. El paper de los rankings de jueces es un preprint sobre chats, sin revisión de pares. Lo que muestra a un juez cerca de las personas es una tarea binaria en agentes de celular. Ahí, el ranking de agentes del juez coincide 0,97 con el de las personas. Ninguna fuente sostiene que calibrar una vez alcance.
Ver el detalle de las 4 pruebasOcultar el detalle0 a favor, 3 en contra, 1 matiza
Seguimiento del equipo del Remote Labor Index. En menos de ocho meses, el mejor agente pasó de automatizar 2,5 % a 15,8 % de los proyectos freelance. También probaron un juez automático calibrado contra evaluación humana con modelos anteriores. El juez ordenó bien a los modelos nuevos, pero infló mucho cuánto aciertan. Los autores concluyen que sirve para seguir el progreso relativo, no para medir la capacidad absoluta.
Números
15,8 %Tasa de automatización del mejor agente (Fable 5). Opus 4.8: 8,3 %; GPT-5.5: 6,25 %; Gemini 3 Pro: 1,25 %.
6,25 % contra 17,9 %GPT-5.5 según evaluadores humanos y según el juez automático (unas 2,9 veces). Para Opus 4.8: 8,33 % contra 18,8 %.
ρ = 0,90Correlación de ranking (Spearman) entre el juez y la evaluación humana.
Limitación Lo publica el equipo del benchmark. Una nota de prensa da 16,1 % y dice que solo se evaluaron 218 de 240 proyectos. El post no lo menciona y la base usa la cifra del post. Más de 84 % de los proyectos sigue sin salir al nivel profesional.
“not a substitute for human evaluation of absolute capability”
Mazeika, M., Gatti, A., et al. arXiv (Center for AI Safety, Scale AI)
Este benchmark (una prueba estándar para comparar agentes) usa 240 proyectos reales de trabajo freelance, no una empresa simulada. Cada proyecto ya lo hizo una persona profesional. Un proyecto cuenta como automatizado solo si el entregable de la IA es al menos tan bueno como el humano, según evaluadores entrenados. Al lanzarse, ningún agente automatizaba más de 3 % de los proyectos.
Números
240 proyectos en 23 subcategoríasTamaño del benchmark: más de 6.000 horas de trabajo humano y más de 140.000 dólares pagados; mediana de 11,5 horas por proyecto.
2,5 %Tasa de automatización del mejor agente al lanzarse (Manus). Grok 4 y Claude Sonnet 4.5 llegaron a 2,1 %; GPT-5, a 1,7 %.
94,4 %Acuerdo entre evaluadores en la tasa de automatización.
Limitación Modelos de 2025. La evaluación es humana y cara; los autores dicen que hoy no se puede automatizar con modelos. Coautores de Scale AI, que vende datos y evaluación.
Evalúa 21 jueces (modelos que califican respuestas) de nueve proveedores en tres benchmarks (pruebas estándar). Medir el acuerdo con las personas como coincidencia exacta lo infla, porque no descuenta los aciertos por azar. Un juez puede ser muy consistente consigo mismo y tener sesgo de posición a la vez. Además, el ranking de jueces cambia mucho de un benchmark a otro.
Números
unos 541.000 juiciosEn 118 corridas sobre MT-Bench, JudgeBench y RewardBench.
de 33 a 41 puntosCuánto baja el acuerdo en MT-Bench al pasar de coincidencia exacta a kappa de Cohen.
hasta 14 puestosCuánto se mueve un juez en el ranking entre benchmarks.
Limitación Preprint; se leyó el resumen. Son chats y preferencias, no trayectorias de agentes.
Wang, Z., Gu, L., Chi, Z., Liu, Z., Ayyoubzadeh, S. M., Yu, Y., Wang, Y. arXiv
Mide jueces automáticos (modelos que califican a otros) sobre trayectorias reales de agentes de celular, no sobre chats. Un juez simple que mira capturas de pantalla iguala o supera a métodos hechos a medida. En la pregunta de si el agente logró la tarea, llega al nivel de acuerdo entre personas. Lo que más pesa es el modelo de base, y los modelos fallan en direcciones opuestas: unos rechazan éxitos y otros aprueban fallas.
Números
931 trayectoriasAnotadas por personas, de 6 benchmarks, 4 agentes y 68 apps.
88,4 %Acuerdo promedio entre personas en la etiqueta de éxito.
90,9 %Exactitud del mejor juez (un juez simple con Gemini 3 Flash); su ranking de agentes correlaciona 0,97 con el de las personas.
71 de 78Fallas graves de los jueces con base Qwen que fueron falsos positivos.
Limitación Preprint. Es una tarea binaria (¿lo logró o no?) en agentes de celular. No prueba que el juez sirva para calificar la calidad de un entregable.
Los benchmarks sirven para ver la tendencia y para descartar candidatos.No sirven para elegir, y menos para prometer. El puntaje cambia entre benchmarks. Depende de la máquina, del corrector y de los atajos, y casi nunca se parece a tu caso. Ninguna fuente de la base compara el puntaje con resultados en producción.
Los equipos con agentes en producción ya lo saben. “Measuring Agents in Production” encuestó a 86 practicantes (la prueba 29). El 74 % depende sobre todo de evaluación humana.
El modelo juez sirve para escalar esa evaluación, con estas condiciones:
Usalo para la pregunta binaria: si el agente logró la tarea o no.
Calibralo contra una muestra que corrige una persona.
Volvé a calibrarlo cuando cambia el modelo o el tipo de tarea.
Usalo para comparar versiones entre sí, no para dar la nota absoluta.
Evaluar bien cuesta, y conviene saberlo antes de empezar. HAL corrió 21.730 ejecuciones de 9 modelos en 9 benchmarks. La cuenta llegó a unos 40.000 dólares. Vos no necesitás eso. La guía de Anthropic dice que de 20 a 50 tareas sacadas de fallas reales son un buen comienzo. Es la guía de un proveedor de modelos. Pero coincide con lo que hacen los equipos en producción y con lo que pide el hilo de compradores.
20 a 50 tareas
Tareas simples sacadas de fallas reales, como buen punto de partida. Prueba 40
Antes de comprar o lanzar un agente, hay que armar pruebas propias en lugar de confiar en las del proveedor.
Veredicto: Sí. Según un hilo de compradores, en las pruebas de concepto el proveedor da una clave y dice: probalo vos. Y SOC 2, una certificación de seguridad, no cubre el comportamiento del modelo. En un estudio con 86 practicantes, 74 % depende sobre todo de evaluación humana. Evaluar a gran escala cuesta: unos 40.000 dólares por 21.730 ejecuciones. Pero para empezar alcanzan de 20 a 50 tareas.
Criterio
Armá de 20 a 50 tareas sacadas de fallas reales de tu operación y hacé que el agente del proveedor las corra antes de firmar. Leé las transcripciones, no solo el puntaje.
Por qué confianza media. El punto del comprador sale de un hilo de Reddit con muy poco puntaje. La guía de tareas la escribe un proveedor de modelos. El estudio de equipos en producción tiene una muestra chica. Ninguna fuente sostiene lo contrario con datos. La que matiza solo muestra lo que cuesta evaluar a gran escala.
Ver el detalle de las 4 pruebasOcultar el detalle3 a favor, 0 en contra, 1 matiza
En las pruebas de concepto, los proveedores de agentes dan una clave de API y dicen “pruébelo usted”. El autor pregunta por qué la auditoría queda del lado del comprador. Según las respuestas, pedir que prueben que el modelo no alucina es pedir que prueben un negativo. Además, SOC 2 no cubre el comportamiento del modelo. La salida práctica es que el comprador arme su propio set de evaluaciones.
Números
4 puntos y 26 comentariosTamaño del hilo según el archivo.
Limitación Hilo con muy poco puntaje: vale como idea, no como consenso. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“there are no frameworks for doing any kind of an audit of model behavior.”
Esta guía para evaluar agentes recomienda empezar temprano con tareas sacadas de fallas reales. También pide combinar tres tipos de evaluadores (código, modelo y persona), calificar el resultado y no el camino, y leer las transcripciones. Distingue pass@k, acertar al menos una vez en k intentos, de pass^k, acertar en todos. Advierte que parte de los fallos son errores del evaluador.
Números
20 a 50 tareasTareas simples sacadas de fallas reales, como buen punto de partida.
75 % por intento, cerca de 42 % en 3 de 3Ejemplo de pass^k: acertar las tres veces es mucho menos probable que acertar una.
de 42 % a 95 %Resultado de Opus 4.5 en CORE-Bench después de corregir errores del evaluador.
Limitación La escribe un proveedor de modelos. Es una guía de práctica, no un estudio.
“20-50 simple tasks drawn from real failures is a great start”
Estudio de casos y encuesta a profesionales que tienen agentes en producción. La mayoría evalúa con personas y no con benchmarks (pruebas estándar), y deja pocos pasos al agente antes de que intervenga alguien. La confiabilidad, es decir, que el agente se comporte bien de forma sostenida, sigue siendo el principal desafío. Los equipos la atacan con diseño del sistema.
Números
20 casos y 86 practicantesBase del estudio: 20 entrevistas en profundidad y una encuesta a practicantes de 26 dominios.
74 %Depende sobre todo de evaluación humana.
68 %Corre como máximo 10 pasos antes de que intervenga una persona.
70 %Usa modelos comerciales con prompts en vez de reentrenarlos.
Limitación Muestra chica y elegida por los autores; no representa a todas las empresas. Preprint.
“Reliability (consistent correct behavior over time) remains the top development challenge”
Es una infraestructura para evaluar agentes de forma pareja, que mide costo y comportamiento además de precisión. Más esfuerzo de razonamiento bajó la precisión en la mayoría de las corridas. Encontraron un agente que buscó el benchmark (la prueba) en HuggingFace en vez de resolver la tarea. También encontraron uso indebido de tarjetas de pago en tareas de reserva de vuelos.
Números
21.730 ejecucionesEjecuciones de agentes con 9 modelos en 9 benchmarks.
unos 40.000 dólaresCosto de correr la evaluación.
unos 2.500 millones de tokensRegistros publicados para que otros los revisen.
Limitación Benchmarks públicos, no despliegues en empresas. Modelos de 2025.
No prometas un resultado que no mediste con tus tareas. Antes de firmar o de lanzar:
Usá los benchmarks públicos para descartar, no para elegir. Mirá primero los que se parecen a tu caso, como código privado o usuarios realistas. Desconfiá de diferencias de menos de 3 puntos.
Armá de 20 a 50 tareas sacadas de fallas reales de tu operación. Hacé que el agente del proveedor las corra antes de firmar. El plan de evaluación tiene el formato.
Si un resultado llega a una persona sin un control automático antes, medí pass^k. La calculadora de confiabilidad muestra cuánto cae el acierto con las repeticiones.
Si usás un modelo juez, medí su acuerdo descontando el azar. Mirá por separado los falsos positivos y los falsos negativos. Recalibralo con cada modelo nuevo.
Si el puntaje cambia mucho, para arriba o para abajo, leé una muestra de transcripciones. Revisá el evaluador antes de sacar conclusiones.