Resumen Técnico: SCOPE – Agente de Cámara de Lenguaje Natural en Tiempo Real en el Borde (Edge)

Declaración del Problema

El despliegue de agentes impulsados por lenguaje para la robótica requiere marcos de evaluación que reflejen las restricciones del mundo real: instrucciones de lenguaje natural con resultados reproducibles, presupuestos de latencia estrictos y computación de borde limitada. Los benchmarks existentes para modelos de lenguaje (LM) y modelos de lenguaje-visión (VLM) a menudo se centran en la comprensión de imágenes estáticas o la navegación móvil, fallando al abordar los desafíos específicos del control de cámaras Pan-Tilt-Zoom (PTZ). El control PTZ implica un bucle de retroalimentación no trivial que acopla percepción, razonamiento y actuación (por ejemplo, "panorámica a la derecha en pasos de 15° hasta que veas seis conos"). Las evaluaciones actuales carecen de:

1. Evaluación de bucle cerrado: La mayoría no mide la capacidad del agente para percibir, planificar y actuar de forma iterativa.
2. Paridad Sim-to-Real: Pocos marcos aseguran que los entornos de simulación reflejen fielmente los espacios de acción y los bucles de observación del hardware físico.
3. Métricas críticas para el despliegue: La latencia, la huella de memoria y los modos de error en hardware de borde rara vez se capturan, lo que dificulta predecir el comportamiento del agente en bucles de control robótico real.

Metodología

Los autores presentan SCOPE (Simulation and Camera Operations for Perception and Evaluation), un marco modular diseñado para la evaluación ejecutable y de bucle cerrado de agentes PTZ impulsados por lenguaje.

Arquitectura del Sistema

SCOPE emplea un diseño desacoplado para gestionar las restricciones de borde:

• Planificador (Planner): Un Modelo de Lenguaje Pequeño (SLM) compacto actúa como planificador de alto nivel. Intercala el razonamiento con el control de la cámara y las consultas de percepción.
• Percepción: La comprensión visual se delega a modelos de lenguaje-visión (VLM) ligeros expuestos como herramientas invocables.
• Interfaz de Herramientas (Tool Interface): El SLM interactúa con el entorno mediante un conjunto fijo de herramientas compatibles con el esquema JSON de OpenAI. Estas incluyen:
  • Control Directo: ADJUST_PTZ (pan/tilt/zoom), GO_TO_PRESET, TAKE_IMAGE.
  • Percepción: COUNT_OBJECTS, QUERY_ANSWER (OCR/atributos), ZOOM_TO_OBJECT, TRACK_OBJECT.
• Bucle (Loop): El agente consulta al LM con la solicitud del usuario y el historial. El modelo termina con una respuesta o emite llamadas a herramientas. Las salidas se reintroducen en el contexto para el razonamiento iterativo hasta completar la tarea o alcanzar un límite de pasos ($T_{max}$).

Construcción de Simulación y Benchmark

Para permitir pruebas repetibles de tipo CI (Integración Continua), el agente se implementó en Blender, creando un entorno de simulación que refleja el espacio de acción PTZ físico (yaw, pitch, distancia focal) y el bucle de observación.

• El Benchmark: Un conjunto de datos de 536 tareas de lenguaje natural que abarcan QA (pregunta-respuesta), comandos de paso único/múltiple, conteo, razonamiento espacial, descripciones y OCR.
• Verdad de Campo (Ground Truth): Las tareas están fundamentadas en anotaciones estructuradas de presets de cámara (entidades, atributos, disposición espacial y ausencias explícitas) para asegurar resultados verificables.
• Protocolo de Evaluación: Un LLM-as-Judge (específicamente gpt-oss-120B) evalúa las trayectorias del agente de forma holística. Asigna corrección binaria y atribuye errores a modos específicos (por ejemplo, errores de consulta VLM, alucinaciones, errores de enrutamiento de herramientas) en lugar de depender de la coincidencia determinista de cadenas de texto.

Selección de Modelos

El estudio evaluó 19 combinaciones de planificador–percepción:

• Planificadores (SLMs): Varias variantes de modelos Qwen3 (4B, 30B-A3B, 32B, 80B-A3B), incluyendo arquitecturas densas y de Mezcla de Expertos (MoE), tanto en formatos FP16 como en formatos cuantizados FP8/INT4.
• Percepción (VLMs): Familia Moondream (2B, 4-bit, 9B MoE) y Qwen2.5-VL-7B.

Contribuciones Clave

1. Marco SCOPE: Un agente PTZ modular impulsado por lenguaje que opera tanto en simulación como en hardware físico (AXIS M5075-G), permitiendo una transferencia fiel de sim-to-real.
2. Simulación basada en Blender: Un marco que expone capacidades PTZ realistas y una herramienta de panorama determinista para manejar el razonamiento de escena completa sin inconsistencia temporal.
3. Benchmark de 536 tareas: Un conjunto de datos que requiere control activo del punto de vista e interacción de bucle cerrado, exponiendo modos de fallo invisibles en los benchmarks de imágenes estáticas.
4. Evaluación Sistemática: Un análisis exhaustivo de 19 emparejamientos de modelos que miden precisión, latencia y modos de error para identificar elecciones arquitectónicas para el despliegue en tiempo real en el borde.

Resultados

Precisión y Análisis de Errores

• La Percepción como Cuello de Botella: Mientras que las tareas centradas en herramientas (Llamada Única, Comando de Paso Múltiple) alcanzaron una alta precisión (86–100%), las tareas con mayor carga de percepción (Conteo, OCR) fueron significativamente menores (38–83%).
• Planificador vs. Percepción: Los SLM más fuertes redujeron sustancialmente las alucinaciones y mejoraron el enrutamiento de herramientas. Sin embargo, una vez que se utilizó un SLM suficientemente capaz (por ejemplo, Qwen3-30B-A3B), la percepción se convirtió en el cuello de botella dominante del rendimiento.
  • En el escenario "oráculo" (ignorando errores de conteo/consulta del VLM), la precisión promedio saltó del 66.2% al 82.0%, indicando que los fallos de percepción representan aproximadamente el 47% de los errores.
  • Escalar los SLM más allá de 30B-A3B produjo rendimientos decrecientes en precisión en comparación con las ganancias observadas al mejorar los backbones de los VLM.
• Modos de Error: Los SLM más débiles fallaban debido a alucinaciones y uso impropio de herramientas. Los SLM más fuertes rara vez cometían errores de enrutamiento; sus fallos se debían casi exclusivamente a las limitaciones del VLM (errores de conteo, errores de OCR).

Latencia y Eficiencia

• Dominio de la Percepción: La latencia de extremo a extremo está dominada por el backbone del VLM, no por el planificador. Expandir el alcance de la observación a un panorama completo aumentó la latencia en un ~22%.
• Eficiencia de MoE: Los modelos de Mezcla de Expertos (MoE) (por ejemplo, Qwen3-30B-A3B con 3B de parámetros activos) igualaron o superaron a las alternativas densas en precisión, operando con latencias comparables a redes mucho más pequeñas.
• Cuantización: La cuantización FP8/INT4 proporcionó ganancias de eficiencia con una degradación mínima de la precisión, aunque los impactos en la latencia dependieron de la configuración.

Mejor Configuración

La configuración de mayor rendimiento fue Moondream3 (VLM) emparejado con Qwen3-30B-A3B (SLM), logrando un 73.8% de éxito en las tareas.

Significado y Reivindicaciones

El artículo afirma identificar un punto de diseño práctico, validado de sim-to-real, para el control PTZ impulsado por lenguaje en tiempo real y factible en el borde. Las conclusiones clave incluyen:

• Elección Arquitectónica: Separar la planificación (SLM) y la percepción (VLM) es esencial para el despliegue en tiempo real en el borde.
• Selección de Modelos: Los planificadores compactos de tipo MoE (como 30B-A3B) ofrecen el mejor equilibrio entre precisión y latencia, superando a modelos densos más grandes sin costos de latencia proporcionales.
• Limitaciones Actuales: El principal techo de rendimiento es el backbone de visión. Las mejoras futuras en los agentes PTZ dependerán más de VLMs más fuertes (para OCR y conteo) que de escalar más los planificadores.
• Realidad del Despliegue: El estudio valida que los modelos de código abierto pueden lograr bucles de control en tiempo real (~2 Hz, ≤500ms) en hardware de borde, siempre que la arquitectura sea modular y la percepción esté optimizada.

Los autores mantienen la modestia, señalando que su benchmark utiliza prompts estructurados que pueden subrepresentar consultas ambiguas del mundo real, y que las mediciones de latencia se vieron influenciadas por las configuraciones de servicio (por ejemplo, vLLM vs. auto-alojado). Excluyen explícitamente los modelos de frontera cerrados debido a su incompatibilidad con las restricciones de baja latencia en el borde.