🤖 AI

HarnessOpt-Bench: Evaluating LLMs at Harness Optimization

Este artículo presenta HarnessOpt-Bench, un nuevo benchmark diseñado para evaluar la capacidad de los LLM de frontera para optimizar iterativamente arneses agénticos (incluyendo prompts, herramientas y código de orquestación) bajo restricciones de recursos, demostrando que esta capacidad de optimización es una habilidad distinta y medible con un margen significativo de mejora.

Autores originales: Varun Ursekar, Apaar Shanker, Yash Maurya, Shehab Yasser, Vijay S. Kalmath, Veronica Chatrath, Yuan Xue

Publicado 2026-08-07

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Varun Ursekar, Apaar Shanker, Yash Maurya, Shehab Yasser, Vijay S. Kalmath, Veronica Chatrath, Yuan Xue

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que tienes un cerebro de robot brillante y superinteligente. Puede escribir código, resolver problemas matemáticos y responder preguntas. Pero este cerebro no funciona en el vacío; necesita un "arnés". Piensa en el arnés como la armadura del robot, su manual de instrucciones y su panel de control, todo en uno. Es el código que le dice al cerebro cómo usar sus herramientas, qué recordar y cómo comunicarse con el mundo exterior. Al igual que un coche de carreras necesita un gran conductor y un motor bien ajustado para ganar, una IA inteligente necesita un cerebro inteligente y un gran arnés para desempeñarse bien. A veces, el mismo cerebro puede ser un genio en un traje y un principiante torpe en otro.

Aquí está la gran pregunta: ¿Podemos enseñar a una IA a arreglar su propio traje? ¿Puede una IA mirar su propio arnés, darse cuenta de que es torpe y reescribir el código para hacerse más inteligente? Esto se llama "optimización del arnés". Es un poco como pedirle a un chef que no solo cocine una comida, sino que también rediseñe la cocina, afile los cuchillos y reescriba el libro de recetas mientras está cocinando, todo ello sin saber exactamente cómo probarán los jueces el plato final hasta el final. Este es un desafío masivo porque arreglar el traje es costoso y complicado; tienes que adivinar qué funciona sin ver la puntuación final, y tienes que hacerlo antes de que se te agote la "energía" (o en este caso, el tiempo de computación y el dinero).

Esto es exactamente lo que los investigadores de Scale AI se propusieron probar con un nuevo experimento llamado HarnessOpt-Bench. Construyeron un patio de juegos especial y seguro donde diferentes modelos de IA de primer nivel actúan como "optimizadores". ¿Su trabajo? Tomar un agente de IA básico y ligeramente torpe (la "semilla"), leer su código e intentar mejorarlo. La trampa es que el optimizador tiene un presupuesto estricto: solo puede ejecutar un número limitado de pruebas para ver si sus cambios funcionan. Recibe pistas de algunas ejecuciones de prueba (desarrollo y validación), pero la puntuación real y final está oculta hasta que presenta su mejor versión.

Los investigadores querían ver si estos modelos de IA podían realmente mejorar en esta tarea. Realizaron 111 experimentos diferentes utilizando cinco de los modelos de IA más inteligentes disponibles hoy en día, probándolos de dos maneras: una vez usando un "kit de herramientas" estándar y compartido (un arnés de codificación común) y otra vez usando sus propios kits de herramientas nativos e integrados. Midieron el éxito por cuánto mejoró el rendimiento del agente en comparación con la versión original y torpe.

Esto es lo que encontraron, y es un poco sorprendente. Primero, los modelos de IA en sí importan mucho más que el kit de herramientas que están utilizando. La diferencia de rendimiento entre la IA más inteligente y la menos inteligente fue enorme: casi el doble de grande que la diferencia causada por cambiar el kit de herramientas. Esto sugiere que el "cerebro" es la verdadera estrella, no solo el "traje" que lleva puesto.

Segundo, tener un kit de herramientas nativo y sofisticado no garantizaba la victoria. Podrías pensar que una IA tendría mejor desempeño con sus propias herramientas personalizadas, pero los resultados fueron mixtos. A veces el kit de herramientas nativo ayudaba, otras veces no, y a veces el kit de herramientas estándar era en realidad mejor. No hubo una "ventaja de local" constante.

Tercero, la forma en que las IA buscaban soluciones importaba. Aquellas que intentaron manipular más partes del código (como los prompts, la memoria, las reglas de reintento y las herramientas) tendieron a obtener mejores resultados. Sin embargo, las IA no pasaron mucho tiempo leyendo los informes detallados de fallos (trazas) de lo que salió mal. La mayoría se enfocó en las puntuaciones finales. Esto sugiere que para estas tareas, mirar el panorama general era más útil que obsesionarse con cada pequeño error.

Finalmente, las IA solían ser demasiado optimistas. Las puntuaciones que veían mientras buscaban (en las pruebas de "práctica") eran generalmente más altas que las puntuaciones que obtenían en la prueba final y oculta. Esto significa que las IA a veces pensaban que habían encontrado una solución perfecta, pero cuando los jueces reales las veían, no eran tan buenas.

En resumen, este artículo muestra que la optimización del arnés es una habilidad real y medible que los modelos de IA de frontera poseen, pero que todavía están aprendiendo a hacerla de manera consistente. Los mejores modelos pueden mejorar significativamente el rendimiento de un agente, pero aún no son perfectos. Necesitan aprender a ser menos optimistas y, tal vez, leer los informes de fallos con un poco más de atención. El mensaje clave es: nos dirigimos hacia un futuro donde la IA no solo realiza tareas, sino que también aprende a construir mejores versiones de sí misma, pero todavía nos queda un largo camino por recorrer antes de que puedan hacerlo de manera confiable sin ayuda humana.

Resumen Técnico: HarnessOpt-Bench

Declaración del Problema

A medida que los Modelos de Lenguaje Grande (LLM) se despliegan cada vez más dentro de sistemas agénticos, su rendimiento depende no solo de los pesos del modelo, sino también del "harness" (arnés): los prompts, herramientas, flujo de control, memoria y código de orquestación circundantes. Si bien la optimización del harness (la mejora iterativa y guiada por evaluación del harness) es una ruta crítica para construir sistemas de IA capaces, la comunidad carece de un protocolo común para medir qué tan bien los LLM de frontera realizan esta tarea ellos mismos.

Las evaluaciones existentes suelen estar confundidas por la variación en los agentes objetivo, semillas, presupuestos y protocolos de puntuación, lo que dificulta distinguir si las ganancias de rendimiento provienen del modelo optimizador, del harness de codificación que utiliza o de la configuración específica de la tarea. Además, la optimización del harness difiere de los benchmarks de codificación estándar porque la evaluación es costosa y estocástica; requiere diagnosticar fallos a partir de evidencia incompleta, gestionar un presupuesto de evaluación limitado y separar la mejora real del ruido, en lugar de simplemente producir un único paso de código correcto.

Metodología: HARNESSOPT-BENCH

Los autores presentan HARNESSOPT-BENCH, un benchmark diseñado para evaluar la optimización de harness de extremo a extremo bajo condiciones de evaluación costosas y estocásticas. El marco de trabajo impone un entorno controlado y reproducible con los siguientes componentes principales:

1. El Problema de Optimización

Harness Candidato ( $H$ ): Un código ejecutable que contiene prompts, herramientas y flujo de control. El optimizador puede editar, añadir o eliminar archivos sujetos a una interfaz de ejecución fija y rutas inmutables.
Invariantes ( $\theta$ ): Los modelos, el entorno y el verificador son fijos. El optimizador no puede cambiar el modelo objetivo ni la lógica de evaluación, solo el código del harness.
Presupuesto ( $B$ ): La búsqueda está restringida por un presupuesto fijo de llamadas de evaluación (limitado a 100 por partición) y el total de tokens del modelo objetivo. El optimizador debe decidir qué evaluar y con qué fidelidad.
Política de Divulgación:
- Desarrollo ( $D_{dev}$ ): Revela entradas de casos, resultados por caso y trazas de ejecución para apoyar el diagnóstico.
- Validación ( $D_{val}$ ): Revela únicamente puntuaciones agregadas para apoyar la selección.
- Prueba ( $D_{test}$ ): Permanece completamente inaccesible durante el proceso de búsqueda.

2. Entorno de Ejecución Confiable

Para evitar el sobreajuste y garantizar la equidad, el benchmark se ejecuta dentro de un entorno de ejecución confiable (basado en VERO [23]):

Aislamiento: Cada ejecución del agente objetivo ocurre en un sandbox efímero y sin privilegios.
Control de Acceso: El optimizador solo puede escribir en el harness del agente objetivo. Puede leer trazas de desarrollo y métricas de validación, pero no puede acceder a la partición de prueba ni modificar el verificador.
Auditoría: Cada versión candidata se preserva para auditoría, y el uso de recursos es medido.

3. Métrica de Evaluación

La métrica principal es la Ganancia Normalizada ( $g$ ), definida como la mejora del candidato nominado sobre la semilla fijada en la partición de prueba retenida, normalizada por el margen disponible:
$g = \frac{E_\theta(H^+) - E_\theta(H_0)}{1 - E_\theta(H_0)}$
donde $H_0$ es el harness semilla y $E_\theta$ es la puntuación esperada. Los valores negativos indican que el candidato tuvo un desempeño inferior a la semilla.

4. Diseño Experimental

Tareas: Cuatro tareas descendentes (OfficeQA, BrowseComp-Plus, Terminal-Bench, GAIA) con semillas fijadas. Tres semillas son competentes pero básicas; una (GAIA) es un stub no funcional.
Optimizadores: Se evaluaron cinco LLM de frontera (Claude Opus-5, Claude Sonnet-5, GPT-5.6-Sol, GPT-5.6-Terra, Kimi-K3).
Configuraciones de Harness: Cada modelo fue probado bajo dos condiciones:
1. Harness Compartido: Todos los modelos utilizan un harness de codificación común (opencode).
2. Harness Nativo: Los modelos utilizan sus respectivas herramientas de codificación nativas (por ejemplo, claude-code, codex, kimi-cli).
Protocolo: Cada configuración se ejecutó dos veces. Los resultados se promedian sobre $K=3$ rondas de evaluación independientes por caso de prueba para mitigar el ruido estocástico.

Contribuciones Clave

Un Benchmark Controlado: HARNESSOPT-BENCH desacopla el modelo optimizador del harness de codificación y de la tarea objetivo, permitiendo el aislamiento de la capacidad del modelo en la optimización del harness.
Protocolo Confiable: La introducción de un límite de ejecución confiable que impone presupuestos, bloquea el acceso a datos retenidos y preserva los candidatos para auditoría, asegurando que las mejoras reflejen la generalización en lugar del sobreajuste a las puntuaciones visibles.
Evaluación Empírica: Una evaluación exhaustiva de 5 modelos de frontera a través de 4 tareas y 111 ejecuciones puntuadas, comparando harnesses compartidos frente a nativos.
Análisis del Comportamiento de Búsqueda: Instrumentación de las trayectorias de búsqueda para correlacionar comportamientos específicos del optimizador (por ejemplo, amplitud de intervención, lectura de trazas) con la ganancia final.

Resultados

1. Sensibilidad del Modelo vs. Harness

El Modelo es el Dominante: La elección del modelo optimizador tiene un efecto significativamente mayor en el rendimiento que la elección del harness de codificación. Cambiar el modelo optimizador movió la ganancia normalizada en un promedio de 0.142, mientras que cambiar el harness la movió en 0.079.
Sin Ventaja Nativa Consistente: Los harnesses nativos (por ejemplo, claude-code para modelos Claude) no proporcionaron una ventaja consistente sobre el harness compartido. En 11 de 20 pares de modelo-tarea, el harness compartido superó al nativo; en 9, el nativo ganó. La diferencia agregada fue cercana a cero, sugiriendo que la sensibilidad al harness es heterogénea en lugar de uniforme.

2. Brechas de Capacidad y Progresión

Lanzamientos de Modelos: El benchmark distingue con éxito entre lanzamientos sucesivos de modelos. En OfficeQA, los lanzamientos de GPT-5.6 mostraron incrementos de ganancia monotónicos, mientras que los lanzos de Claude Opus mostraron una dispersión significativa pero no monotónica.
Varianza de Tareas: Las ganancias varían sustancialmente entre tareas. Las configuraciones más fuertes capturaron aproximadamente dos tercios del margen disponible en OfficeQA, pero no lograron resolver desde cero en BrowseComp-Plus y Terminal-Bench.

3. Información sobre el Comportamiento de Búsqueda

Amplitud de Intervención: Existe una fuerte correlación positiva ( $\rho$ de +0.34 a +0.88) entre la fracción de "palancas" del harness (por ejemplo, prompt, política de reintento, esquema de herramientas) tocadas durante la búsqueda y la ganancia normalizada final. Una exploración más amplia se asocia con mejores resultados.
Lectura de Trazas: Contrario a la intucción, la inspección detallada de las trazas de fallo rara vez fue utilizada (solo 16 veces en 111 celdas) y se asoció negativamente con la ganancia. Los optimizadores dependieron principalmente de resúmenes de puntuación por caso.
Restricciones de Presupuesto: El permiso de pases de casos (4 pases completos por partición) fue la restricción limitante para la mayoría de los optimizadores, no el límite de llamadas de evaluación.
Sobreajuste: Las puntuaciones de validación visibles fueron a menudo optimistas en comparación con las puntuaciones finales de la prueba retenida, confirmando la necesidad de la partición retenida.

Significado y Reivindicaciones

El artículo establece la optimización del harness como una capacidad medible y discriminatoria para los LLM de frontera. Los autores afirman que:

Los modelos actuales pueden realizar la optimización del harness, pero su rendimiento es desigual y depende altamente de la tarea específica y el régimen de semillas.
La capacidad de optimizar un agente es distinta de la capacidad de escribir código; la primera requiere razonar sobre sistemas estocásticos y gestionar recursos limitados.
HARNESSOPT-BENCH transforma la ingeniería de harness de una demostración específica de un optimizador en un objetivo de evaluación reproducible. Esto permite a la comunidad medir y desarrollar sistemas que puedan mejorar otros agentes de manera confiable.

Los autores mantienen la modestia en sus afirmaciones, señalando que el benchmark es "resistente a trucos, pero no a prueba de trucos" y que los resultados son específicos para la distribución actual de tareas y semillas. Enfatizan que la próxima frontera no es simplemente tener mejores agentes, sino modelos que puedan hacer que los agentes sean mejores de manera confiable.