Resumo Técnico: ASSCG – Gating "Just-Right" para Planejamento Fast–Slow de LLM em Condução Autônoma

1. Declaração do Problema

Modelos de Linguagem de Grande Escala (LLMs) e Modelos de Linguagem-Visão (VLMs) oferecem um potencial significativo para o planejamento de condução autônoma ao fornecer raciocínio de senso comum e orientação contextual. No entanto, sua alta latência de inferência e custo computacional impedem a implantação por quadro (per-frame) em sistemas de tempo real. A solução prevalente é o paradigma fast–slow (dual-system), onde um planejador "fast" leve e de tempo real opera a cada quadro, enquanto um módulo "slow" de LLM pesado fornece orientação de alto nível em uma frequência menor.

As estratégias atuais de coordenação para acionar o módulo lento sofrem de duas limitações principais:

1. Acionamento de intervalo fixo: Consulta o sistema lento a uma taxa constante (ex: a cada $K$ quadros). Isso ignora a variabilidade temporal, levando a consultas redundantes em cenários simples (desperdiçando computação) e oportunidades perdidas em cenários complexos.
2. Acionamento baseado em heurística de dificuldade: Baseia-se em proxies como "complexidade da cena" ou estimativas de incerteza. Esses proxies frequentemente falham em se alinhar com a utilidade marginal real de invocar o módulo lento, levando a oscilações desnecessárias ou consultas mal cronometradas.

Crucialmente, o artigo observa que o raciocínio lento mais frequente nem sempre é benéfico. Em certos segmentos (denominados Intervalos de Falha - Failure Intervals), invocar o sistema lento pode degradar o desempenho devido a alucinações ou interpretações errôneas. O desafio central é formular uma política de controle que decida quando consultar, quando reutilizar a orientação em cache e quando suprimir o módulo lento inteiramente para maximizar o desempenho de malha fechada (closed-loop) sob um orçamento computacional.

2. Metodologia: Controle de Sistema Lento Adaptativo (ASSCG)

Os autores propõem o ASSCG, uma interface de controle agnóstica à arquitetura que gerencia a interação entre um planejador rápido e um módulo LLM lento ao nível do quadro.

2.1 Estrutura Conceitual

Os autores definem três intervalos operacionais para caracterizar o valor da orientação lenta:

• Intervalo Equivalente (EI): Uma janela onde reconsultar o sistema lento gera informação incremental insignificante. O sistema deve Cache (armazenar em cache) a orientação existente.
• Intervalo Eficaz (EfI): A duração em que a orientação atual em cache é válida e útil.
• Intervalo de Falha (FI): Uma janela onde invocar o sistema lento degrada o desempenho downstream em relação a não invocá-lo. O sistema deve Drop (descartar) a orientação.

2.2 Arquitetura do Sistema

O ASSCG opera dentro de uma arquitetura desacoplada fast–slow (ex: AsyncDriver):

• Sistema Fast: Um planejador de tempo real (ex: baseado em GameFormer) rodando a cada quadro.
• Sistema Slow: Um planejador baseado em LLM (ex: LLaMA2-13B) invocado sob demanda.
• Buffer: Armazena uma representação compacta da orientação lenta (embeddings latentes, waypoints ou logits).
• Controlador ASSCG: Uma rede leve que produz uma ação discreta $a_t \in \{0, 1, 2\}$ para cada quadro:
  • Query (0): Invoca o sistema lento, atualiza o buffer e funde a nova orientação.
  • Cache (1): Reutiliza a orientação no buffer sem consultar o sistema lento.
  • Drop (2): Ignora o buffer (substitui por um vetor nulo) para evitar que orientações obsoletas ou prejudiciais afetem o planejador fast.

2.3 Design do Modelo

• Backbone: O ASSCG utiliza um backbone RWKV-7. Esta escolha é motivada pela necessidade de modelagem temporal de longo horizonte eficiente, com complexidade de tempo linear e memória constante por passo (após o cache de estado), evitando o custo quadrático dos Transformers para episódios longos.
• Inputs: O gate recebe:
  • Embedding da cena atual (de um Vector Map Encoder).
  • Memória de referência (o último embedding de orientação lenta).
  • Similaridade de cosseno entre a cena atual e a referência.
  • Feature de tempo ($\Delta t$ desde a última consulta lenta).
• Pipeline de Treinamento:
  1. Ajuste Fino Supervisionado (SFT): O gate é inicializado usando pseudo-labels derivados de uma busca em grade (grid search) de cronogramas de consulta fixos. Para cada cena, o cronograma que gera o maior score de malha fechada é selecionado, e sua sequência de Query/Cache/Drop por quadro serve como o rótulo.
  2. Ajuste Fino de Aprendizado por Reforço Consciente de Computação (RL): O gate é otimizado adicionalmente usando um algoritmo estilo GRPO (Group Relative Policy Optimization). A função de recompensa é projetada para maximizar o score oficial de malha fechada enquanto penaliza custos de consulta.
     • Modelagem de Recompensa (Reward Shaping): Utiliza modelagem baseada em potencial para fornecer feedback intermediário denso baseado em métricas de segurança e conforto (TTC, conforto, conformidade com o limite de velocidade).
     • Custo de Query: Um termo de penalidade ($\lambda_{call}$) é aplicado à ação "Query" para incentivar a eficiência.
     • Objetivo: A política é treinada para otimizar o equilíbrio entre qualidade de planejamento e a frequência de invocações do módulo lento.

3. Principais Contribuições

1. Análise de Colaboração Fast–Slow: O artigo introduz os conceitos de Intervalos Equivalentes, Eficazes e de Falha, demonstrando empiricamente que cronogramas fixos e gatilhos heurísticos são subótimos porque a utilidade do raciocínio lento varia dinamicamente dentro de um único episódio.
2. Arquitetura ASSCG: Um mecanismo de gating de nível de quadro, discreto (Query/Cache/Drop), que é agnóstico à arquitetura e capaz de suprimir intencionalmente orientações prejudiciais.
3. Estratégia de Treinamento: Um novo protocolo de treinamento em dois estágios combinando SFT com ajuste fino de RL consciente de computação (GRPO) para otimizar diretamente métricas de malha fechada sob restrições explícitas de custo de consulta.
4. Validação Empírica: Avaliação em duas instâncias distintas de fast–slow e benchmarks, demonstrando melhorias nos trade-offs de desempenho-eficiência.

4. Resultados Experimentais

4.1 nuPlan Hard20 (Baseado em AsyncDriver)

• Configuração: Avaliado no split nuPlan closed-loop Hard20 usando uma arquitetura AsyncDriver.
• Desempenho: A integração do ASSCG melhorou o score geral para 67.28 (um aumento de +2.28 sobre o baseline AsyncDriver).
• Eficiência: A latência média de inferência end-to-end foi reduzida em ~60% em comparação com o baseline de consulta contínua. O intervalo de consulta efetivo médio foi de 5.26 quadros (consultando ~19% dos quadros), correspondendo à latência de um cronograma de salto (stride) fixo de 5 quadros, mas alcançando scores significativamente maiores.
• Detalhamento de Métricas: Melhorias foram observadas em métricas relacionadas à segurança (TTC, evasão de colisão) e conformidade de regras (área dirigível, direção de condução), sugerindo que o ASSCG permite um comportamento de condução mais estável e seguro.

4.2 NAVSIM (Baseado em RecogDrive)

• Configuração: Avaliado no benchmark NAVSIM usando um sistema dual onde um planejador fast baseado em ViT compete com um planejador slow baseado em VLM (InternVL-2B).
• Desempenho: O sistema habilitado com ASSCG alcançou um PDMS de 91.4 (um aumento de +0.6 sobre o ReCogDrive original).
• Eficiência: A latência média de inferência de tempo de execução (wall-clock) diminuiu de 350 ms para **270 ms** por cena.
• Observação: O sistema selecionou com sucesso o ramo lento para apenas ~40% das cenas, demonstrando que o mecanismo de gating identifica efetivamente quando o planejador fast é suficiente.

4.3 Estudos de Ablação

• Estratégia de Treinamento: Substituir GRPO por PPO resultou em scores menores (66.76 vs 67.28) e instabilidade, destacando o benefito da formulação específica de RL utilizada.
• Backbone: Substituir RWKV por um Transformer de contagem de parâmetros similar resultou em precisão comparável, mas latência significativamente maior (0.06s vs 0.02s para o último quadro em episódios longos), validando a escolha do RWKV para aplicações de tempo real.
• Ação Drop: Remover a ação "Drop" reduziu o score de 67.28 para 66.71, confirmando que a capacidade de suprimir a orientação lenta é crítica, não apenas a capacidade de reduzir a frequência de consultas.

5. Significância e Alegações

O artigo alega que o ASSCG fornece um mecanismo de gating "just-right" que equilibra qualidade de planejamento e custo de recursos. Sua principal significância reside em:

• Ir além de gatilhos estáticos: Demonstrar que decisões adaptativas ao nível do quadro superam cronogramas fixos e estimativas de complexidade heurística.
• Lidar com Intervalos de Falha: Provar que o sistema pode aprender a ignorar o módulo lento quando ele é provavelmente prejudicial, uma capacidade ausente em abordagens anteriores de "sempre consultar" ou "gatilho por complexidade".
• Generalização: Mostrar que o princípio de gating funciona através de diferentes arquiteturas de planejadores subjacentes (AsyncDriver e RecogDrive) e protocolos de avaliação (nuPlan closed-loop e NAVSIM one-shot).

Os autores observam modestamente que seu trabalho avalia quando usar um ramo lento dado os sistemas existentes, em vez de provar que o raciocínio de LLM é necessário para todos os cenários. Eles identificam benchmarks de cauda longa (long-tail) end-to-end mais difíceis como um próximo passo natural.