Benchmarking agentes en modelos abiertos y tu tooling | Keryc
La pregunta deja de ser solo "¿acertó el agente?" y pasa a ser "¿cuánto trabajo tuvo que hacer para acertar?". En el nuevo benchmark de Hugging Face se mide exactamente eso: no solo la respuesta final, sino el camino, los tokens, los errores y las decisiones que toma un agente cuando usa tu librería.
Qué midieron y por qué importa
Los autores hicieron un experimento técnico y reproducible centrado en cómo los agentes usan transformers como caso de estudio. La idea es simple y poderosa: cuando un agente codifica por ti, la API ya no debe ser solo correcta y rápida; debe ser fácil de descubrir, tener ejemplos claros y estar testeada para uso agentico.
¿Por qué? Porque una API confusa no solo frustra a desarrolladores humanos, también hace que el agente gaste más tokens, tiempo y pasos para llegar a la misma respuesta. Medir únicamente el resultado final te deja ciego ante esos costes.
Diseño del benchmark: modelos, revisiones y "tiers"
Cada ejecución varia cuatro ejes: el modelo que conduce al agente, la revisión de (tags o commits), la tarea concreta y el "tier" de ayuda que recibe el agente. Los tiers son:
transformers
bare: pip install transformers y nada más.
clone: checkout completo del repositorio en el working directory.
skill: una Skill empaquetada con docs y ejemplos específicos de tarea.
Cada combinación (modelo × revisión × tarea × tier) corre como un Job de Hugging Face en hardware idéntico para mantener comparaciones justas y a escala.
Métricas que realmente importan
No basta con un "match". El harness chequea varias dimensiones:
match %: si la salida contiene la respuesta esperada (subcadena, regex o exacto según la tarea).
median time y median tokens: divide entre tokens nuevos, cacheados y generados.
runs with error %: incluye fallos silenciosos (0 tokens, ninguna llamada a herramienta).
marker adoption: etiquetas que describen comportamientos concretos del agente.
Además, todas las ejecuciones generan trazas nativas del agente, almacenadas en el Hub, para revisar comando a comando qué hizo el agente.
Tener la traza es un lujo: no solo ves el resultado, ves el proceso. Eso te permite reproducir fallos y entender decisiones erradas.
Hallazgos clave y ejemplos concretos
La misma tarea, caminos muy distintos
Dos agentes pueden llegar al mismo "POSITIVE (0.9999)" pero con perfiles muy distintos. Uno escribe y depura un script Python largo; otro ejecuta una única llamada de CLI. Ambos aciertan, pero difieren drásticamente en tokens, latencia y probabilidad de error.
Ejemplo comparativo (sentiment):
# opción larga: script piped a python
python - <<'PY'
from transformers import AutoTokenizer, AutoModelForSequenceClassification
import torch
import torch.nn.functional as F
model = AutoModelForSequenceClassification.from_pretrained('distilbert/distilbert-base-uncased-finetuned-sst-2-english')
# ...preprocesado, inferencia y print...
PY
# opción corta: CLI
transformers classify --model distilbert/distilbert-base-uncased-finetuned-sst-2-english --text 'I absolutely loved the movie, it was fantastic!'
Tradeoff CLI + Skill: menos tiempo, más tokens en clone
Cuando se introduce una CLI y ejemplos, las grandes modelos usan la nueva interfaz y completan tareas más rápido (menos turns). Pero en el clone tier, el checkout incluye el código y ejemplos, y muchos agentes primero leen esos archivos: median new tokens suben (por ejemplo de ~4k a ~6.4k), aunque el tiempo disminuye. Es un tradeoff que merece conocerse antes de mergear.
No todos los modelos se benefician igual
Grandes modelos: suelen aprovechar la Skill y el CLI, reduciendo tiempo y turns.
Modelos pequeños/locales: a veces empeoran. Los modelos pequeños pueden depender de patrones memorizados (por ejemplo pipeline(...)) y quedan confundidos por la nueva superficie. En casos extremos, la Skill puede reducir la match % o incluso romper la solución.
Casos concretos reportados:
Qwen3-4B: en clone, la median new tokens sube de ~2.4k a ~23k porque lee en bloque el nuevo código, sin mejorar la exactitud.
Qwen3-14B: añadir la Skill hizo caer match % en classify-sentiment de 100% a 0% porque el modelo empezó a emitir llamadas a una herramienta transformers(command=...) que nunca existió; interpretó la Skill como un API invocable en el contexto del agente.
Markers: etiquetando comportamientos para entender el "cómo"
Los markers son patrones definidos por el perfil de la herramienta que se buscan en comandos, código generado, archivos leídos o en la respuesta final. Para transformers destacaron dos:
cli: el agente ejecutó transformers en la shell.
pipeline: el agente usó la API alta pipeline(...).
Con esos markers puedes medir si un cambio a la librería realmente cambió el comportamiento del agente, no solo el resultado final.
Recomendaciones prácticas para mantenedores
Testea para agentes: añade tests que reproduzcan flujos agenticos. Si no está testeado, no existe para un agente.
Documenta pensando en agentes: estructura los ejemplos y docs para que el agente pueda encontrarlos rápido (README, ejemplos por tarea, snippets mínimos).
Evalúa across model sizes: un cambio puede ahorrar trabajo a modelos grandes y romper modelos pequeños. Mide ambos casos.
Considera generar Skills automáticamente: Upskill es la idea de convertir la solución de un modelo fuerte en una Skill solo si ayuda a los modelos débiles.
Usa trazas: revisa el agent-traces viewer para entender por qué un agente falló o se desvió.
Cómo usar el harness ahora mismo
El proyecto es un CLI llamado agent-eval. Flujo mínimo:
Instala y lee el README y SECURITY.md.
Define tareas deterministas y las respuestas esperadas.
Lanza el sweep modelos × revisiones como Jobs de HF; cada run necesita HF_TOKEN para servir modelos.
Publica el report como una Space y revisa las trazas en el Hub.
Advertencia de seguridad: el harness ejecuta agentes que pueden ejecutar código del repo que apuntas. Solo usa esto en entornos de confianza y revisa SECURITY.md antes de compartir resultados.
Reflexión final
Este trabajo no es solo una nueva métrica, es una llamada de atención: si quieres que tu librería funcione bien con agentes, diseña, documenta y testea con agentes. A veces una mejora para modelos grandes es una trampa para los pequeños. Medir el proceso, no solo el resultado, te da información accionable para tomar decisiones informadas antes de mergear cambios importantes.
