GenUI-Harness eleva un modelo de 4B del 9,33% al 58% en Pass@3 y supera a Claude Opus 5

El equipo autor de un artículo en arXiv propone GenUI-Harness, un arnés multiagente en el que el modelo responde a una consulta compleja no con un párrafo de texto, sino con una interfaz temporal con formularios, listas y selección de parámetros. Tras el entrenamiento por refuerzo, un modelo de 4.000 millones de parámetros pasó del 9,33% al 58,00% en Pass@3 y superó a Claude Opus 5, que obtiene un 46,67%. En la encuesta a revisores, la duración media del diálogo bajó de 3,4 a 1,2 rondas.

Dos agentes en lugar de un chat

La arquitectura es sencilla. Tool Agent se encarga de buscar información y ejecutar tareas: consulta bases de datos y llama a herramientas. GUI Coder Agent examina la consulta y el resultado, detecta las ambigüedades y escribe el código frontend de una interfaz estructurada. Si el usuario pide «cambiar el vuelo», el agente no le hace cinco preguntas aclaratorias seguidas. Le muestra un formulario con opciones reales sacadas de la base de datos.

Los autores parten de la idea de que el texto, como canal para tareas complejas, sobrecarga a la persona: genera ambigüedad y ruido informativo, y obliga a introducir datos con lentitud. Una interfaz construida para unos datos concretos y un paso concreto de la tarea elimina esos problemas.

Cómo entrenar a un programador de interfaces

La parte principal de ingeniería del trabajo es cómo entrenar al GUI Coder con RL. Hay dos problemas, y cada uno tiene su propia solución.

El primero: una recompensa verificable para una interfaz interactiva exige ejecutar el código de verdad, y eso es caro. Para resolverlo, los autores crearon Dynamic UX, un paquete ligero que ofrece interacción dinámica y recogida de recompensas en un único sandbox.

El segundo: si la recompensa la da un LLM como juez, el modelo aprende rápido a engañarlo. Contra el reward hacking proponen Reward Auditor, una metarrecompensa. Este componente vigila la distribución de las recompensas, identifica patrones de diagnóstico y los reúne en una rúbrica común y una especificación de evaluación. Así, el juez no permanece fijo durante el entrenamiento.

Benchmark y cifras

Para la evaluación, los autores crearon UI-TAU Bench. Se apoya en 10 bases de datos temáticas reales de fuentes abiertas y adopta el planteamiento de Tau-Bench para el uso de herramientas. Hay versiones Lite (300 tareas) y Full (1000 tareas).

• Mejora media de Pass@3 sobre smolagents en Lite: 4,48 p. p.
• Modelo de 4B tras el entrenamiento en GenUI-Harness: de 9,33% a 58,00% en Pass@3.
• Claude Opus 5 en el mismo benchmark: 46,67%.
• Robustez: el sistema se mantiene tanto con consultas ambiguas como con consultas inequívocas.
• Encuesta a revisores: el diálogo se reduce de 3,4 a 1,2 rondas.

El 9,33% inicial del modelo de 4B muestra lo difícil que resulta la tarea para una versión base sin especialización. El salto hasta el 58% indica que el RL con auditoría de recompensas aporta más que el tamaño del modelo. Pero la comparación se hace en un benchmark creado por los propios autores, con su propio planteamiento, y los modelos de frontera no se entrenaron específicamente para él.

La mejora de 4,48 p. p. sobre smolagents parece mucho más modesta que el salto del modelo de 4B, y conviene tener presentes ambas cifras a la vez.

Además, la encuesta a revisores no sustituye a un experimento con usuarios corrientes. Los propios autores limitan sus conclusiones a «los escenarios evaluados con bases de datos».

Dónde puede resultar útil

Lo más cercano a la práctica son los escenarios en los que el agente cuenta con un backend estructurado: atención al cliente, reservas, paneles de administración internos, gestión de pedidos. En ellos, un diálogo de aclaración sale caro, y las opciones de respuesta son finitas y están en la base de datos.

Un equipo que construya agentes debería fijarse en dos técnicas trasladables. La primera: separar al ejecutor de tareas del generador de interfaces y entrenarlos por separado. La segunda: monitorizar la distribución de recompensas del LLM juez como una entidad aparte, en lugar de fiarse de una rúbrica redactada una sola vez. Esta segunda técnica es útil en cualquier pipeline de RL con juez, no solo en la generación de UI.

Por ahora se trata de un artículo en preprint v1: el código, la reproducibilidad y el comportamiento con datos ajenos a los diez dominios aún están por comprobar.