Benchmarks - referencia pública
Los benchmarks (SWE-bench, GAIA, τ-bench, HumanEval) dan una referencia compartida: corres el agente sobre el mismo dataset que otros publicaron y el número habla el mismo idioma. Riesgo clásico: optimizar para el benchmark y perder en el mundo real.
Qué es
Un benchmark es un dataset congelado más un protocolo de ejecución más un número publicado. Alguien arma 500 tareas, fija la métrica, ejecuta varios modelos en el mismo hardware y divulga una tabla. Tú repites el experimento, obtienes un número y lo comparas con la tabla. Es el mismo modelo del SDLC clásico: la prueba es estable, el sujeto varía, el veredicto es comparable.
Para el agente la mecánica cambia un poco. Los benchmarks públicos suelen ser demasiado estáticos (respuesta única, sin interacción) o sintéticos (clientes simulados que parecen humanos sin tener matices). Por eso el benchmark es un punto de partida, nunca un punto de llegada.
Los cuatro que importan
(Verified) es el estándar de facto para coding agents. Cerca de 500 issues reales de GitHub, cada una con la descripción del bug y el test que valida el fix. El agente recibe el repositorio, lee el código, propone un patch y corre los tests. Un agente que resuelve patches resuelve N% del benchmark.
GAIA mide agentes de propósito general en tareas multi-hop (cruzar fuentes, leer PDF, sumar valores). Mezcla herramienta, razonamiento y recuperación. Es el benchmark más usado para comparar agentes que navegan la web.
τ-bench (tau-bench) se enfoca en el diálogo agente vs usuario simulado, con herramientas y políticas. Mide si el agente cumple la tarea del cliente sin reventar el presupuesto de tool calls. Es una referencia reciente (2024) y ganó tracción en atención al cliente.
HumanEval es el padre de todos: 164 problemas de código en Python, función genera función, los asserts validan. Sigue siendo útil como sanity check de un modelo puro, pero cualquier agente moderno lo pasa sin sudar.
Corriendo un benchmark local
La mayoría de los benchmarks publica un harness en Python que estandariza la ejecución. El esqueleto de abajo muestra la mecánica de iteración sobre los casos, exponiendo el agente como una función pura para que el harness pueda comparar la salida con el gabarito:
import json
from datasets import load_dataset
from agent import solve # función de tu agente
CASES = load_dataset("princeton-nlp/SWE-bench_Verified", split="test")
def run(limit: int | None = None):
passed = 0
total = 0
failures = []
for case in CASES:
if limit and total >= limit:
break
total += 1
try:
patch = solve(case["repo"], case["problem_statement"])
ok = apply_and_test(case["instance_id"], patch, case["test_patch"])
if ok:
passed += 1
else:
failures.append((case["instance_id"], "tests_failed"))
except Exception as e:
failures.append((case["instance_id"], f"exception:{type(e).__name__}"))
return {"passed": passed, "total": total, "failures": failures}
if __name__ == "__main__":
print(json.dumps(run(limit=50), indent=2))El riesgo del overfitting
Cuando el dataset es público y el resultado se vuelve métrica de marketing, alguien aprende a hackear el benchmark. El caso más didáctico es el de la contamination: el modelo se entrena con texto que contiene los casos del benchmark, y la 'respuesta' se vuelve memorización disfrazada de razonamiento. Otro truco es el cherry-picking: correr el agente 10 veces, escoger la mejor ejecución y publicarla.
Defensa práctica. La primera es correr el benchmark a ciegas: nunca dejes que el agente lea la solución esperada, y trunca el dataset si se va a filtrar por el contexto. La segunda es cruzar con un dataset privado que mantienes en secreto, del mismo formato, y exigir que los dos avancen juntos. La tercera es monitorear la brecha entre benchmark y producción, e investigar siempre que diverja.
Benchmark versus producción
El benchmark es estático, finito y público. La producción es infinita, ruidosa y llena de cola larga (usuario frustrado, , consulta ambigua). Un agente puede sacar 80% en GAIA y aun así ser malo para el usuario real.
La lectura de sentido común trata el benchmark como triaje y el dataset privado como fuente de verdad. Publicar el número en el README es marketing honesto. Confiar en él para cerrar un release es una tontería.
Cómo elegir el benchmark correcto
Empieza por el workload. Si tu agente lee código, SWE-bench. Si conversa con clientes, τ-bench. Si hace investigación web, GAIA. Si el trabajo es generación pura, HumanEval resuelve.
Después mira la versión. SWE-bench Verified es el subconjunto validado por humanos del SWE-bench original. Siempre prefiere la versión verificada cuando exista, porque reduce el ruido de casos ambiguos.
Por último, mide el costo. Cada caso tiene un presupuesto de tokens y tool calls. Compara el costo por caso resuelto, no solo la tasa de acierto. Un agente que resuelve 60% con la mitad de los tokens suele ser mejor que uno que resuelve 80% con el doble.
Puntos fuertes
- comparación directa entre modelos y entre proveedores, con la misma regla
- las regresiones obvias (el proveedor empeoró el modelo entre versiones) saltan a la vista
- costo predecible por caso, útil para el presupuesto de API
Limitaciones
- contamination: el benchmark puede filtrarse al entrenamiento del modelo evaluado
- la cola larga de la producción no aparece: un caso raro que tumba al 1% de los usuarios no está en los 500
- gaming: el tiempo gastado en hackear el benchmark rara vez mejora al agente real
conexiones en el mapa
- Benchmarks - referencia públicaprovee datosEvals - calidad medida en producción
actualizado el 14/10/2026 · fuentes para profundizar · reportar un error
Estudia antes
pon a prueba lo que entendiste
Cargando preguntas…