Resumen Técnico: ASSCG – Gating de "Justo lo Necesario" para la Planificación de LLM Rápido-Lento en Conducción Autónoma

1. Planteamiento del Problema

Los Modelos de Lenguaje de Gran Escala (LLMs) y los Modelos de Lenguaje-Visión (VLMs) ofrecen un potencial significativo para la planificación de la conducción autónoma al proporcionar razonamiento de sentido común y guía sensible al contexto. Sin embargo, su alta latencia de inferencia y costo computacional impiden su despliegue por cuadro (frame) en sistemas de tiempo real. La solución prevalente es el paradigma rápido-lento (dual-system), donde un planificador "rápido" ligero y de tiempo real opera en cada cuadro, mientras que un módulo "lento" de LLM pesado proporciona guía de alto nivel a una frecuencia menor.

Las estrategias actuales de coordinación para activar el módulo lento sufren de dos limitaciones principales:

1. Activación de intervalo fijo: Consulta el sistema lento a una tasa constante (por ejemplo, cada $K$ cuadros). Esto ignora la variabilidad temporal, lo que conduce a consultas redundantes en escenarios simples (desperdiciando cómputo) y oportunidades perdidas en escenarios complejos.
2. Activación basada en heurística de dificultad: Depende de indicadores como la "complejidad de la escena" o estimaciones de incertidumbre. Estos indicadores a menudo fallan al alinearse con la utilidad marginal real de invocar el módulo lento, lo que provoca oscilaciones innecesarias o consultas mal temporizadas.

Crucialmente, el artículo observa que un razonamiento lento más frecuente no siempre es beneficioso. En ciertos segmentos (denominados Intervalos de Fallo), invocar el sistema lento puede degradar el rendimiento debido a alucinaciones o interpretaciones erróneas. El desafío central es formular una política de control que decida cuándo consultar, cuándo reutilizar la guía almacenada en caché y cuándo suprimir el módulo lento por completo para maximizar el rendimiento de bucle cerrado bajo un presupuesto de cómputo.

2. Metodología: Control de Gate Adaptativo del Sistema Lento (ASSCG)

Los autores proponen ASSCG, una interfaz de control agnóstica a la arquitectura que gestiona la interacción entre un planificador rápido y un módulo LLM lento a nivel de cuadro.

2.1 Marco Conceptual

Los autores definen tres intervalos operativos para caracterizar el valor de la guía lenta:

• Intervalo Equivalente (EI): Una ventana donde volver a consultar el sistema lento produce información incremental insignificante. El sistema debe Almacenar en Caché (reutilizar) la guía existente.
• Intervalo Efectivo (EfI): La duración en la que la guía actual almacenada en caché es válida y útil.
• Intervalo de Fallo (FI): Una ventana donde invocar el sistema lento degrada el rendimiento posterior en comparación con no invocarlo. El sistema debe Descartar (suprimir) la guía.

2.2 Arquitectura del Sistema

ASSCG opera dentro de una arquitectura desacoplada rápido-lento (por ejemplo, AsyncDriver):

• Sistema Rápido: Un planificador en tiempo real (por ejemplo, basado en GameFormer) que se ejecuta en cada cuadro.
• Sistema Lento: Un planificador basado en LLM (por ejemplo, LLaMA2-13B) invocado bajo demanda.
• Buffer: Almacena una representación compacta de la guía lenta (características latentes, waypoints o logits).
• Controlador ASSCG: Una red ligera que genera una acción discreta $a_t \in \{0, 1, 2\}$ para cada cuadro:
  • Consultar (0): Invocar el sistema lento, refrescar el buffer y fusionar la nueva guía.
  • Caché (1): Reutilizar la guía del buffer sin consultar el sistema lento.
  • Descartar (2): Ignorar el buffer (sustituirlo por un vector nulo) para evitar que una guía obsoleta o perjudicial afecte al planificador rápido.

2.3 Diseño del Modelo

• Backbone: ASSCG utiliza un backbone RWKV-7. Esta elección está motivada por la necesidad de un modelado temporal de horizonte largo eficiente con complejidad de tiempo lineal y memoria constante por paso (tras el almacenamiento en caché del estado), evitando el costo cuadrático de los Transformers para episodios largos.
• Entradas: El gate recibe:
  • Embedding de la escena actual (de un Codificador de Mapa Vectorial).
  • Memoria de referencia (el último embedding de la guía lenta).
  • Similitud de coseno entre la escena actual y la de referencia.
  • Característica de tiempo ($\Delta t$ desde la última consulta lenta).
• Pipeline de Entrenamiento:
  1. Ajuste Fino Supervisado (SFT): El gate se inicializa utilizando pseudo-etiquetas derivadas de una búsqueda de cuadrícula (grid search) de programas de consulta de intervalo fijo. Para cada escena, se selecciona el programa que produce la puntuación más alta en bucle cerrado, y su secuencia de Consulta/Caché/Descarte por cuadro sirve como etiqueta.
  2. Ajuste Fino de Aprendizaje por Refuerzo Consciente del Cómputo (RL): El gate se optimiza adicionalmente utilizando un algoritmo de estilo GRPO (Optimización de Política Relativa de Grupo). La función de recompensa está diseñada para maximizar la puntuación oficial de bucle cerrado penalizando los costos de consulta.
     • Modelado de Recompensa (Reward Shaping): Utiliza modelado basado en potencial para proporcionar retroalimentación intermedia densa basada en métricas de seguridad y confort (TTC, confort, cumplimiento de límites de velocidad).
     • Costo de Consulta: Se aplica un término de penalización ($\lambda_{call}$) a la acción "Consultar" para fomentar la eficiencia.
     • Objetivo: La política se entrena para optimizar el equilibrio entre la calidad de la planificación y la frecuencia de las invocaciones del módulo lento.

3. Contribuciones Clave

1. Análisis de la Colaboración Rápido-Lento: El artículo introduce los conceptos de Intervalos Equivalentes, Efectivos y de Fallo, demostrando empíricamente que los programas fijos y los disparadores heurísticos son subóptimos porque la utilidad del razonamiento lento varía dinámicamente dentro de un solo episodio.
2. Arquitectura ASSCG: Un mecanismo de gating a nivel de cuadro (Consulta/Caché/Descarte) que es agnóstico a la arquitectura y capaz de suprimir intencionalmente la guía lenta perjudicial.
3. Estrategia de Entrenamiento: Un nuevo protocolo de entrenamiento de dos etapas que combina SFT con ajuste fino de RL consciente del cómputo (GRPO) para optimizar directamente las métricas de bucle cerrado bajo restricciones explícitas de costo de consulta.
4. Validación Empírica: Evaluación en dos instancias distintas de rápido-lento y benchmarks, demostrando mejores compromisos entre rendimiento y eficiencia.

4. Resultados Experimentales

4.1 nuPlan Hard20 (Basado en AsyncDriver)

• Configuración: Evaluado en el split nuPlan closed-loop Hard20 usando una arquitectura AsyncDriver.
• Rendimiento: La integración de ASSCG mejoró la puntuación general a 67.28 (un aumento de +2.28 sobre el baseline AsyncDriver).
• Eficiencia: La latencia de inferencia de extremo a extremo promedio se redujo en aproximadamente un 60% en comparación con el baseline de consulta continua. El intervalo de consulta efectivo promedio fue de 5.26 cuadros (consultando ~19% de los cuadros), igualando la latencia de un programa de paso fijo de 5 cuadros pero logrando puntuaciones significativamente más altas.
• Desglose de Métricas: Se observaron mejoras en las métricas relacionadas con la seguridad (TTC, evitación de colisiones) y el cumplimiento de reglas (área de conducción, dirección de conducción), lo que sugiere que ASSCG permite un comportamiento de conducción más estable y seguro.

4.2 NAVSIM (Basado en RecogDrive)

• Configuración: Evaluado en el benchmark NAVSIM utilizando un sistema dual donde un planificador rápido ligero basado en ViT compite con un planificador lento basado en VLM (InternVL-2B).
• Rendimiento: El sistema habilitado con ASSCG logró un PDMS de 91.4 (un aumento de +0.6 sobre el ReCogDrive original).
• Eficiencia: La latencia de inferencia de tiempo real promedio disminuyó de 350 ms a **270 ms** por escena.
• Observación: El sistema seleccionó con éxito la rama lenta para solo ~40% de las escenas, demostrando que el mecanismo de gating identifica eficazmente cuándo el planificador rápido es suficiente.

4.3 Estudios de Ablación

• Estrategia de Entrenamiento: Reemplazar GRPO con PPO resultó en puntuaciones más bajas (66.76 vs 67.28) e inestabilidad, resaltando el beneficio de la formulación específica de RL utilizada.
• Backbone: Reemplazar RWKV con un Transformer de cantidad similar de parámetros produjo una precisión comparable pero una latencia significativamente mayor (0.06s vs 0.02s para el último cuadro en episodios largos), validando la elección de RWKV para aplicaciones en tiempo real.
• Acción de Descarte (Drop): Eliminar la acción "Descartar" redujo la puntuación de 67.28 a 66.71, confirmando que la capacidad de suprimir la guía lenta es crítica, no solo la capacidad de reducir la frecuencia de consulta.

5. Significado y Reivindicaciones

El artículo afirma que ASSCG proporciona un mecanismo de gating de "justo lo necesario" que equilibra la calidad de la planificación y el costo de los recursos. Su principal significancia radica en:

• Ir más allá de los disparadores estáticos: Demostrar que los programas adaptativos a nivel de cuadro superan a los programas fijos y a las estimaciones de complejidad heurística.
• Manejo de Intervalos de Fallo: Probar que el sistema puede aprender a ignorar el módulo lento cuando es probable que sea perjudicial, una capacidad ausente en los enfoques previos de "consulta continua" o "disparadores por complejidad".
• Generalizabilidad: Mostrar que el principio de gating funciona a través de diferentes arquitecturas de planificadores subyacentes (AsyncDriver y RecogDrive) y protocolos de evaluación (nuPlan closed-loop y NAVSIM one-shot).

Los autores señalan modestamente que su trabajo evalúa cuándo usar una rama lenta dado los sistemas existentes, más que probar que el razonamiento de LLM es necesario para cada escenario. Identifican los benchmarks de cola larga (long-tail) más difíciles como el siguiente paso natural.