Benchmarks de agentes de IA: GAIA, WebArena, OSWorld y SWE-bench

GAIA evalúa respuestas a preguntas realistas que combinan razonamiento, multimodalidad, navegación web y uso de tools. WebArena evalúa tareas largas en sitios web funcionales y reproducibles. OSWorld añade aplicaciones de escritorio, file I/O y workflows entre varias apps en un entorno informático real. SWE-bench parte de un issue de GitHub y un snapshot del repositorio y comprueba si un patch resuelve el problema de ingeniería de software. No son cuatro rankings intercambiables: cada uno mide una distribución de tareas, un espacio de observación/acción y una definición de éxito diferentes.

Primero defina la decisión de producción: elegir un scaffold, habilitar un browser workflow, cambiar un coding agent o ampliar un nivel de autonomía. Después alinee el trabajo real con el contrato del benchmark. Un resultado externo aporta un prior sobre capacidad, pero no demuestra calidad sobre sus datos, permisos, locale, UI, repositorio o coste del error. Para release sigue haciendo falta un eval slice interno con el mismo tipo de tareas y un oracle independiente.

GAIA encaja cuando el agente recopila hechos, trabaja con archivos y entradas multimodales, usa web o tools y devuelve una respuesta corta verificable. Su fortaleza es combinar capacidades básicas de assistant; su límite para producción es que no contiene el estado de sus aplicaciones ni sus consequential side effects. Añada tareas propias de knowledge work, reglas de citación, freshness cutoff y casos de abstención.

Elija WebArena para un browser agent que navega interfaces de e-commerce, foros, desarrollo colaborativo o gestión de contenidos y debe alcanzar un estado funcional. OSWorld representa mejor a un computer-use agent que alterna entre navegador, office, sistema operativo y workflows de archivos. Para un coding agent, SWE-bench ofrece una señal issue-to-patch en repositorios reales, pero el replay interno debe reproducir su toolchain, instrucciones, hidden checks y review policy.

• GAIA → preguntas de assistant general, browsing, tools y evidencia multimodal.
• WebArena → tareas web funcionales y outcome basado en ejecución.
• OSWorld → escritorio, archivos y workflows entre aplicaciones.
• SWE-bench → issue del repositorio, cambio de código y resolución basada en tests.

El nombre del modelo más un porcentaje no es un resultado reproducible. Registre la revisión o split del benchmark, agent scaffold, prompt, tools, observation mode, action adapter, budget, retry policy, número de muestras, environment image, estado de dependencias y versión del grader. En entornos web y desktop añada viewport, locale, account fixtures, reset status y proporción de infrastructure failures. En evals de código fije el base commit, test command, aplicación del patch, network policy y contamination controls.

Compare solo runs con reglas compatibles. Pass@k con varios intentos no equivale a first-run reliability; éxito con browser no equivale a éxito sin acceso web; un scaffold distinto puede explicar la diferencia mejor que la model capability. No traslade números históricos de baseline al producto actual: pertenecen a una versión concreta del paper y del harness. En el decision record guarde el enlace al artifact de resultados primario, no una cifra de leaderboard copiada sin provenance.

La construct validity pregunta si la tarea y el grader miden la capacidad que realmente necesita. Un exact answer sirve para una pregunta tipo GAIA, pero no demuestra seguridad de la trayectoria. Un test aprobado en SWE-bench puede confirmar el comportamiento del patch sin garantizar mantenibilidad ni cumplimiento de la policy interna. Un grader web o desktop puede observar el final state correcto y no detectar un mensaje innecesario, una fuga de datos o un side effect repetido. Añada verdicts separados para outcome, trajectory, policy y side effects.

Compruebe si tasks, solutions, screenshots o repositorios pudieron aparecer en training, ejemplos o prompt tuning. Un conjunto interno held-out no debe ser visible para el equipo que optimiza el agente. Etiquete los fallos de entorno por separado: que un sitio no arranque, falte una dependencia o el oracle no esté disponible no es ni fallo del modelo ni éxito. Reproduzca periódicamente una baseline known-good para distinguir una regresión del agente de un drift del harness.

Un bridge set es un conjunto pequeño y versionado que conserva la forma del benchmark externo pero sustituye el dominio por el suyo. Para un research assistant use preguntas multi-source con fecha de actualidad y citation oracle; para un browser agent, una copia reseteable del workflow clave; para un desktop agent, archivos sintéticos y outputs interceptados; para un coding agent, issues históricos saneados sobre commits fijados. Cada tarea necesita owner, initial state, authority, terminal state, prohibited events y un grader independiente.

Ejecute la señal pública, el bridge set y la regression de producción como tres capas separadas. La primera permite comparar con el ecosistema de investigación, la segunda comprueba la transferencia de capacidad y la tercera protege invariantes locales. La promotion exige resultados aceptables por risk slice, ausencia de critical failures definidos y rollback probado para el bundle de modelo, prompt, tools y policy. Un score medio no compensa un pago no autorizado, una fuga de secretos ni un patch destructivo.

El evidence pack contiene la pregunta de decisión, mapping benchmark-to-workflow, manifest de cada run, raw outcomes, grader evidence, taxonomía de fallos, resultados segmentados, reviewer sign-off y limitaciones conocidas. Registre por separado lo que no se probó: una nueva locale, una tarea más larga, otro permission tier, latencia de producción o un side effect externo. No es burocracia; define el límite de lo que la evidencia permite concluir.

Tras actualizar modelo, scaffold, entorno o dataset, el verdict anterior pasa a ser evidencia histórica. Reproduzca primero el frozen slice, después tareas held-out y solo entonces un canary estrecho. Si el candidate pierde frente a la baseline local o genera un critical failure, rollback restaura un bundle compatible y detiene nuevos runs; los side effects incompletos deben reconciliarse aparte. Un leaderboard público nunca sustituye este release gate.