Un agente de 8B para iOS supera a Gemini-3.5-Flash en UINavBench y empata con Gemini-3.1-Pro

Un equipo de investigadores propone entrenar modelos pequeños de navegación por interfaces no con demostraciones grabadas, sino mediante interacción en vivo con aplicaciones iOS reales. El agente resultante, de 8.000 millones de parámetros, superó a Gemini-3.5-Flash y a Qwen3.8-27B en UINavBench, un benchmark de apps iOS reales cuyo éxito verifica un juez VLM, y empató con Gemini-3.1-Pro. En AndroidWorld, un sistema operativo distinto que el agente no vio durante el entrenamiento, su tasa de éxito es casi siete veces mayor que la del modelo base tras el SFT.

Por qué dividir el agente en un planificador y un «anclador»

El problema del que parte el trabajo le resultará conocido a cualquiera que haya intentado construir agentes de interfaz. Los modelos de frontera manejan bien la navegación por pantalla, pero a veces cuestan varios dólares por tarea, un precio demasiado alto para el uso cotidiano. Los modelos pequeños entrenados con SFT o RL sin conexión memorizan las trayectorias de los datos de entrenamiento. Si la aplicación muestra una pantalla inesperada, ese agente no sabe cómo volver al camino.

Los autores dividieron el sistema en dos partes. El planificador observa la captura de pantalla, guarda el historial de pasos anteriores y, mediante una cadena de razonamiento, produce el paso actual y un plan a largo plazo. Un modelo de anclaje (grounding) independiente convierte ese paso en una acción concreta y en coordenadas de toque.

El anclaje es una tarea casi determinista y el SFT convencional la resuelve bien. Por eso el costoso RL se emplea solo en el planificador. Este parte de Qwen3-VL-8B-Instruct, ajustado con trayectorias humanas, entre ellas el conjunto público GUIOdyssey para escenarios con cambio entre aplicaciones.

El planificador también dispone de una acción de aclaración: si la tarea está formulada de forma incompleta, puede preguntar al usuario por sus preferencias.

Recompensa por paso y estabilización del crítico

El entrenamiento se basa en un juez LLM que emite dos señales. La recompensa densa evalúa cada paso: si acerca al objetivo y si evita alucinaciones y bucles sin sentido. La recompensa terminal comprueba si la tarea se completó por entero. La señal densa es necesaria donde el éxito final es raro: el agente recibe retroalimentación incluso en episodios fallidos y aprende a salir de estados inesperados.

La optimización usa PPO con estimación de ventaja generalizada (GAE). Aquí los autores describen un problema conocido: cuando se premian los pasos, el agente empieza a alargar la trayectoria. Para evitarlo aplicaron un descuento asimétrico: las recompensas locales del proceso se descuentan, pero la de finalización de la tarea no.

La segunda novedad es GiGPPO. El método estima el valor de un estado teniendo en cuenta las recompensas de estados visualmente parecidos en trayectorias paralelas. Esto estabiliza el crítico. Los autores subrayan la diferencia con GiGPO, donde la línea base se calcula sobre estados que se repiten exactamente: en su entorno, esos estados casi siempre son únicos. Por eso la señal se hace pasar por una función de valor entrenable. Según los autores, tanto la recompensa densa como GiGPPO aceleran la convergencia, y el resultado es mejor que el de SFT y el de RL con solo recompensa terminal.

Infraestructura: 512 iPhone virtuales

El RL en línea requiere un número enorme de interacciones reales. Los autores montaron un conjunto de dispositivos iOS virtuales en la nube, controlados por VNC mediante acciones como tap, swipe, type, long press, home y wait. Cada dispositivo se configura una sola vez: se instalan las apps, se inicia sesión con un Apple ID y se toma una instantánea.

Después, cada episodio termina con una restauración de la instantánea, en lugar de recrear la sesión, y el reinicio tarda unos 10 segundos. Funcionan 512 trayectorias a la vez, cada una con su propio dispositivo. Los autores afirman que es el primer entrenamiento a gran escala de agentes de interfaz realizado por completo en dispositivos iOS reales con aplicaciones auténticas.

Qué conviene tener en cuenta

Se trata de un preprint y la descripción disponible no incluye porcentajes exactos de éxito en los benchmarks, así que «casi siete veces» se refiere a la baja base SFT en AndroidWorld, no a un nivel absoluto. La evaluación en UINavBench depende de un juez VLM y las recompensas del entrenamiento las da un juez LLM, de modo que los errores de los jueces pueden afectar tanto al entrenamiento como a la medición. La comparación con Gemini se hizo en un benchmark concreto de apps iOS reales y no tiene por qué trasladarse a cualquier tarea.

La conclusión práctica para los equipos que desarrollan agentes móviles: separar planificación y anclaje, junto con una recompensa por paso de un juez, permite obtener de un modelo de 8B una calidad de nivel de modelos de frontera en un ámbito acotado. El precio de este enfoque es contar con una granja propia de dispositivos virtuales y, a juzgar por el trabajo, esa granja es la condición principal para escalar.