ALRM: Agentic LLM for Robotic Manipulation

Resumen Técnico: LLM Agéntico para Manipulación Robótica (ALRM)

Declaración del Problema
Si bien los Modelos de Lenguaje Extensos (LLMs) han demostrado capacidades avanzadas de razonamiento y planificación, su integración en los procesos de control robótico sigue estando limitada por dos restricciones principales. Primero, los enfoques previos basados en LLM carecen a menudo de mecanismos de ejecución agénticos modulares, lo que impide que los sistemas planifiquen, reflexionen sobre los resultados y revisen las acciones de manera de bucle cerrado. Segundo, los benchmarks existentes para tareas de manipulación robótica se centran predominantemente en el control de bajo nivel, fallando al evaluar sistemáticamente el razonamiento de múltiples pasos o la robustez de los agentes frente a variaciones lingüísticas en las instrucciones de las tareas.

Metodología: El Marco ALRM
Los autores proponen ALRM (Agentic LLM for Robot Manipulation), un marco diseñado para cerrar la brecha entre el razonamiento en lenguaje natural y la ejecución robótica fiable. La arquitectura se construye alrededor de un bucle de razonamiento de estilo ReAct y consta de tres módulos principales:

1. Agente Planificador de Tareas (Task Planner Agent): Genera ciclos iterativos de pensamiento y acción para descomponer solicitudes de usuario de alto nivel en subtareas. Crea dinámicamente subtareas basadas en las observaciones del entorno y la retroalimentación del ejecutor.
2. Agente Ejecutor de Tareas (Task Executor Agent): Convierte las subtareas en lenguaje natural en acciones ejecutables. Este agente opera en dos modos complementarios:
   • Código como Política (Code-as-Policy - CaP): El LLM genera código Python que llama directamente a funciones de control disponibles (por ejemplo, recoger, colocar, mover) en una sola ejecución. Este modo es más rápido y admite modelos sin capacidades de llamada a herramientas (tool-calling), pero es frágil ante errores de generación de código.
   • Herramienta como Política (Tool-as-Policy - TaP): El LLM ejecuta acciones mediante llamadas a herramientas anidadas en pasos interactivos. Este modo permite el razonamiento intermedio y la corrección de errores (por ejemplo, referirse a un objeto incorrecto) pero incurre en una mayor latencia y depende de la fiabilidad del modelo en la llamada a herramientas.
3. Servidor API: Un servidor RESTful que se interconecta con el backend robótico (brazo Interbotix wx250s en simulación Gazebo mediante ROS y MoveIt), gestionando consultas de percepción y comandos de movimiento.

Contribuciones Clave

• Marco ALRM: Un novedoso marco agéntico y modular que soporta ambos modos de ejecución, CaP y TaP, permitiendo la planificación iterativa y la reflexión.
• Nuevo Benchmark: Un benchmark de simulación que comprende 56 tareas en tres entornos (Utensilios de cocina, Cajas, Frutas). El benchmark presenta tres tareas canónicas por entorno, cada una parafraseada en cinco variaciones que cubren cuatro categorías lingüísticas: Léxica, Sintáctica, Semántica y Razonamiento de Alto Nivel (HLR). Este diseño prueba específicamente la capacidad del agente para manejar instrucciones diversas y razonamientos complejos (por ejemplo, seleccionar objetos basados en propiedades como "el de menos calorías" en lugar de nombres explícitos).
• Evaluación Sistemática: Una evaluación exhaustiva de diez LLMs (tanto de código abierto como de código cerrado) a través de ambos modos de ejecución, midiendo las tasas de éxito y la latencia.
• Entorno de Simulación: Un entorno de simulación reutilizable basado en Gazebo integrado con ROS y MoveIt para soportar el despliegue y las pruebas de la manipulación impulsada por LLM.

Resultos Experimentales
Los autores evaluaron diez LLMs, incluyendo GPT-5, Claude-4.1-Opus, DeepSeek-V3.1, y modelos de código abierto como Falcon-H1-7B y Llama-3.1-8B.

• Rendimiento de los Modelos:
  • Código Cerrado: Claude-4.1-Opus emergió como el mejor ejecutor, logrando tasas de éxito promedio del 93.5% en modo TaP y 92.6% en modo CaP.
  • Código Abierto: Falcon-H1-7B fue el mejor modelo de código abierto bajo CaP, logrando una tasa de éxito del 84.3% con una latencia significativamente menor (24.89s) en comparación con modelos más grandes.
• Comparación de Modos: Los LLM de gran escala generalmente lograron mayores tasas de éxito con TaP (aprovechando el razonamiento anidado), pero a costa de una mayor latencia. Por el contrario, los modelos de pequeña escala (hasta 8B de parámetros) tuvieron dificultades con TaP debido a la dificultad para manejar llamadas anidadas, pero se desempeñaron competitivamente con CaP.
• Categorías de Tareas: Los modelos de gran escala funcionaron consistentemente bien en todas las categorías lingüísticas, incluyendo el razonamiento de alto nivel. Los modelos de pequeña escala destacaron en variaciones sintácticas, pero mostraron caídas significativas de rendimiento en tareas de razonamiento de alto nivel, particularmente cuando se requería generar código (CaP) o manejar cadenas de herramientas complejas (TaP).

Significancia y Reivindicaciones
El artículo afirma que ALRM proporciona un enfoque escalable, interpretable y modular para la manipulación robótica. Los resultados demuestran que los LLM pueden resolver eficazmente tareas robóticas abstractas y de alto nivel cuando están equipados con marcos agénticos que soportan la reflexión y la revisión de bucle cerrado. Los autores destacan que, si bien los modelos de código cerrado lideran actualmente en rendimiento, modelos específicos de código abierto (como Falcon-H1-7B) ofrecen una alternativa viable de baja latencia para la ejecución basada en código. El trabajo subraya la importancia de evaluar a los agentes no solo por la completitud de la tarea, sino por su robustez ante la diversidad lingüística y su capacidad para razonar sobre las propiedades de los objetos.

Limitaciones y Direcciones Futuras
Los autores reconocen que el rendimiento del marco depende de la ingeniería de prompts y que el benchmark actual está limitado a tres entornos y tareas de recogida y colocación (pick-and-place). Se sugiere como trabajo futuro expandir el benchmark para incluir navegación y tipos de tareas más diversos, así como integrar componentes de percepción del mundo real para validar el rendimiento fuera de la simulación.