QuoteBench plantea que una evaluación puede sobrestimar a los agentes de código cuando solo mide si el modelo escribió un comando válido.
El preprint muestra que esa misma respuesta puede fallar después, cuando otra capa la extrae o la vuelve a interpretar antes de ejecutarla en Bash.
Los autores probaron esa frontera con 56 tareas de una sola instrucción, agrupadas en 14 familias basadas en incidentes reales.
En ocho configuraciones, pasar la misma salida por un parser (estructurador analítico de caracteres) adicional sin escape redujo la tasa de éxito entre 55,4 y 73,2 puntos porcentuales.
El trabajo se centra en agentes de código, sistemas que responden a una instrucción con acciones como comandos de terminal.
En este tipo de herramienta, la ruta de ejecución también incluye cómo ese texto viaja por APIs, wrappers, contenedores o capas remotas antes de llegar al shell.
El preprint, firmado por Shangao Li, Yao Zhang, Volker Tresp y Yuanyuan Yang, está disponible en arXiv y no ha pasado por revisión por pares.
Su foco conversa con límites vistos en pruebas de trabajo real, aunque aquí se separan los errores del modelo de los que aparecen después, en la ejecución.
Qué mide QuoteBench en la ruta de un comando Bash
QuoteBench emplea un núcleo de 56 tareas resueltas con una sola orden de Bash.
Incluye variantes con texto multilínea, nombres de archivo conflictivos, metacaracteres, edición de JSON, variables de entorno, metadatos de Git y dos simulaciones locales de ejecución tipo SSH.
La puntuación valida el estado final del sistema: recibe crédito cualquier comando que deje correctos los bytes, archivos, argumentos o historial.
Así busca separar la preservación literal del contenido de problemas más amplios, como planificar varios pasos o recuperarse de un error.
La intervención central añade un parser posterior que vuelve a procesar el comando dentro de comillas dobles, un patrón que puede aparecer en flujos con ssh, docker exec o integración continua.
Los autores lo introducen deliberadamente para medir qué parte del fallo nace en el transporte y no en la generación inicial.
Cuando el punto de interpolación se escapa correctamente, la respuesta reproducida recupera el resultado del camino directo.
Por eso, si el modelo mejora tras conocer esa condición extra, el cambio viene de cómo genera el comando desde el inicio, no de una modificación posterior de la ejecución.
Ese ajuste recuperó entre 30,4 y 60,7 puntos porcentuales en seis de las ocho configuraciones. En las otras dos, la recuperación fue nula o ligeramente negativa. Los autores acotan el resultado a este benchmark y a esta frontera entre generación y transporte.
Cuando la evaluación y la ejecución dejan de coincidir
Una puntuación emparejada puede ocultar dos fuerzas opuestas. Un sistema puede parecer estable en una evaluación normal y, al mismo tiempo, perder fiabilidad cuando el mismo comando cruza una capa adicional antes de ejecutarse.
Para comparar asistentes de programación, herramientas de terminal o agentes de automatización, el artículo propone informar cinco piezas: configuración del modelo, contrato de generación, ruta de ejecución, punto operativo y validador del estado final. Sin esos datos, dos porcentajes parecidos pueden estar midiendo cosas distintas.
La página oficial del proyecto publica la especificación, el datasheet, el repositorio y archivos para repetir la prueba con el mismo núcleo de 56 tareas.
También advierte que una llamada de herramienta con argumentos válidos no garantiza que el comando llegue intacto al ejecutor.
Como preprint, el trabajo todavía puede recibir cambios en versiones posteriores. Su criterio para leer benchmarks es concreto: ver un comando correcto en pantalla no basta si la evaluación no muestra qué ocurrió entre esa salida y la máquina que finalmente lo ejecutó.
Fuentes
arXiv: QuoteBench: How Matched Scores Can Hide Command-Path Failures
QuoteBench — página oficial del proyecto
