Riepilogo Tecnico: ASSCG – Gating "Just-Right" per la Pianificazione Fast–Slow di LLM nella Guida Autonoma

1. Definizione del Problema

I Large Language Models (LLM) e i Vision-Language Models (VLM) offrono un potenziale significativo per la pianificazione della guida autonoma, fornendo ragionamento di senso comune e guida consapevole del contesto. Tuttavia, l'elevata latenza di inferenza e il costo computazionale impediscono il deployment per frame in sistemi real-time. La soluzione prevalente è il paradigma fast–slow (dual-system), in cui un pianificatore "fast" leggero e real-time opera ogni frame, mentre un modulo "slow" LLM pesante fornisce una guida di alto livello a una frequenza inferiore.

Le attuali strategie di coordinamento per attivare il modulo slow soffrono di due limitazioni principali:

1. Attivazione a intervallo fisso: Interroga il sistema slow a un tasso costante (ad esempio, ogni $K$ frame). Questo ignora la variabilità temporale, portando a query ridondanti in scenari semplici (spreco di calcolo) e opportunità mancate in sceni complessi.
2. Attivazione basata su euristiche di difficoltà: Si affida a proxy come la "complessità della scena" o stime di incertezza. Questi proxy spesso non si allineano con l'effettiva utilità marginale dell'invocazione del modulo slow, portando a oscillazioni inutili o query fuori tempo.

Crucialmente, il paper osserva che un ragionamento slow più frequente non è sempre benefico. In determinati segmenti (definiti Failure Intervals), invocare il sistema slow può degradare le prestazioni a causa di allucinazioni o interpretazioni errate. La sfida centrale è formulare una politica di controllo che decida quando interrogare, quando riutilizzare la guida in cache e quando sopprimere interamente il modulo slow per massimizzare le prestazioni in loop chiuso sotto un budget computazionale.

2. Metodologia: Adaptive Slow-System Control Gate (ASSCG)

Gli autori propongono ASSCG, un'interfaccia di controllo agnostica rispetto all'architettura che gestisce l'interazione tra un pianificatore veloce e un modulo LLM lento a livello di frame.

2.1 Framework Concettuale

Gli autori definiscono tre intervalli operativi per caratterizzare il valore della guida slow:

• Equivalent Interval (EI): Una finestra in cui ri-interrogare il sistema slow produce informazioni incrementali trascurabili. Il sistema deve Cache (riutilizzare) la guida esistente.
• Effective Interval (EfI): La durata in cui la guida in cache attuale è valida e utile.
• Failure Interval (FI): Una finestra in cui l'invocazione del sistema slow degrada le prestazioni a valle rispetto al non invocarlo. Il sistema deve Drop (sopprimere) la guida.

2.2 Architettura del Sistema

ASSCG opera all'interno di un'architettura disaccoppiata fast–slow (ad esempio, AsyncDriver):

• Sistema Fast: Un pianificatore real-time (ad esempio, basato su GameFormer) che gira ogni frame.
• Sistema Slow: Un pianificatore basato su LLM (ad esempio, LLaMA2-13B) invocato su richiesta.
• Buffer: Memorizza una rappresentazione compatta della guida slow (feature latenti, waypoint o logit).
• Controller ASSCG: Una rete leggera che emette un'azione discreta $a_t \in \{0, 1, 2\}$ per ogni frame:
  • Query (0): Invocare il sistema slow, aggiornare il buffer e fondere la nuova guida.
  • Cache (1): Riutilizzare la guida nel buffer senza interrogare il sistema slow.
  • Drop (2): Ignorare il buffer (sostituirlo con un vettore nullo) per evitare che una guida obsoleta o dannosa influenzi il pianificatore fast.

2.3 Design del Modello

• Backbone: ASSCG utilizza un backbone RWKV-7. Questa scelta è motivata dalla necessità di una modellazione temporale efficiente a lungo termine con complessità temporale lineare e memoria costante per step (dopo il caching dello stato), evitando il costo quadratico dei Transformer per episodi lunghi.
• Input: Il gate riceve:
  • Embedding della scena corrente (da un Vector Map Encoder).
  • Memoria di riferimento (l'ultimo embedding della guida slow).
  • Similarità del coseno tra la scena corrente e il riferimento.
  • Feature temporale ($\Delta t$ dal tempo dell'ultima query slow).
• Pipeline di Training:
  1. Supervised Fine-Tuning (SFT): Il gate viene inizializzato utilizzando pseudo-label derivati da una ricerca a griglia di schedule di query fisse. Per ogni scena, viene selezionato lo schedule che produce il punteggio più alto in loop chiuso, e la sua sequenza di Query/Cache/Drop per frame funge da label.
  2. Reinforcement Fine-Tuning consapevole del calcolo (RL): Il gate viene ulteriormente ottimizzato utilizzando un algoritmo di tipo GRPO (Group Relative Policy Optimization). La funzione di reward è progettata per massimizzare il punteggio ufficiale in loop chiuso penalizzando i costi di query.
     • Reward Shaping: Utilizza uno shaping basato sul potenziale per fornire feedback intermedio denso basato su metriche di sicurezza e comfort (TTC, comfort, rispetto dei limiti di velocità).
     • Costo di Query: Un termine di penalità ($\lambda_{call}$) è applicato all'azione "Query" per incoraggiare l'efficienza.
     • Obiettivo: La policy è addestrata per ottimizzare il trade-off tra qualità della pianificazione e frequenza delle invocazioni del modulo slow.

3. Contributi Chiave

1. Analisi della Collaborazione Fast–Slow: Il paper introduce i concetti di intervalli Equivalenti, Efficaci e di Fallimento, dimostrando empiricamente che gli schedule fissi e i trigger euristici sono subottimali perché l'utilità del ragionamento slow varia dinamicamente all'interno di un singolo episodio.
2. Architettura ASSCG: Un meccanismo di gating a livello di frame, discreto (Query/Cache/Drop), che è agnostico rispetto all'architettura ed è capace di sopprimere intenzionalmente la guida slow dannosa.
3. Strategia di Training: Un nuovo protocollo di training in due fasi che combina SFT con fine-tuning RL (GRPO) consapevole del calcolo per ottimizzare direttamente le metriche in loop chiuso sotto espliciti vincoli di costo di query.
4. Validazione Empirica: Valutazione su due diverse istanze fast–slow e benchmark, dimostrando miglioramenti nei trade-off tra performance ed efficienza.

4. Risultati Sperimentali

4.1 nuPlan Hard20 (basato su AsyncDriver)

• Setup: Valutato sullo split nuPlan closed-loop Hard20 utilizzando un'architettura AsyncDriver.
• Performance: L'integrazione di ASSCG ha migliorato il punteggio complessivo a 67.28 (un aumento di +2.28 rispetto al baseline AsyncDriver).
• Efficienza: La latenza media end-to-end è stata ridotta di circa il 60% rispetto al baseline di query continua. L'intervallo di query efficace medio è stato di 5.26 frame (interrogando circa il 19% dei frame), eguagliando la latenza di uno schedule a stride fisso di 5 frame ma ottenendo punteggi significativamente più alti.
• Analisi delle Metriche: Sono stati osservati miglioramenti nelle metriche legate alla sicurezza (TTC, evitamento collisioni) e alla conformità alle regole (area guidabile, direzione di guida), suggerendo che ASSCG abilita un comportamento di guida più stabile e sicuro.

4.2 NAVSIM (basato su RecogDrive)

• Setup: Valutato sul benchmark NAVSIM utilizzando un sistema duale in cui un pianificatore fast basato su ViT compete con un pianificatore slow basato su VLM (InternVL-2B).
• Performance: Il sistema abilitato da ASSCG ha raggiunto un PDMS di 91.4 (un aumento di +0.6 rispetto all'originale ReCogDrive).
• Efficienza: La latenza media di inferenza wall-clock è diminuita da circa 350 ms a circa 27 de 270 ms per scena.
• Osservazione: Il sistema ha selezionato con successo il ramo slow per solo circa il 40% delle scene, dimostrando che il meccanismo di gating identifica efficacementamente quando il pianificatore fast è sufficiente.

4.3 Studi di Ablazione

• Strategia di Training: Sostituire GRPO con PPO ha portato a punteggi inferiori (66.76 vs 67.28) e instabilità, evidenziando il beneficio della specifica formulazione RL utilizzata.
• Backbone: Sostituire RWKV con un Transformer di parametri simili ha prodotto un'accuratezza comparabile ma una latenza significativamente più alta (0.06s vs 0.02s per l'ultimo frame in episodi lunghi), validando la scelta di RWKV per applicazioni real-time.
• Azione Drop: Rimuovere l'azione "Drop" ha ridotto il punteggio da 67.28 a 66.71, confermando che la capacità di sopprimere la guida slow è critica, non solo la capacità di ridurre la frequenza delle query.

5. Significato e Claim

Il paper sostiene che ASSCG fornisca un meccanismo di gating "just-right" che bilancia la qualità della pianificazione e il costo delle risorse. Il suo significato primario risiede nel:

• Andare oltre i trigger statici: Dimostrare che le decisioni adattive a livello di frame superano gli schedule fissi e le stime di complessità euristica.
• Gestire i Failure Intervals: Provare che il sistema può imparare a ignorare il modulo slow quando è probabile che sia dannoso, una capacità assente negli approcci precedenti ("always-query" o "complexity-triggered").
• Generalizzabilità: Mostrare che il principio di gating funziona attraverso diverse architetture di pianificatore sottostanti (AsyncDriver e RecogDrive) e diversi protocolli di valutazione (nuPlan closed-loop e NAVSIM one-shot).

Gli autori notano con modestia che il loro lavoro valuta quando usare un ramo slow dato un sistema esistente, piuttosto che provare che il ragionamento LLM sia necessario per ogni scenario. Identificano i benchmark long-tail end-to-end più complessi come il passo successivo naturale.