💻 computer science

ASSCG: Just-Right Gating over Chattering for Fast-Slow LLM Planning in Autonomous Driving

Cet article introduit ASSCG, un mécanisme de porte adaptatif qui optimise l'invocation des planificateurs lents et coûteux des LLM dans la conduite autonome en prenant des décisions de requête, de réutilisation ou d'abandon au niveau de la trame via un squelette RWKV léger entraîné par apprentissage par renforcement, améliorant ainsi considérablement les performances de planification tout en réduisant la latence d'inférence sur plusieurs bancs d'essai.

Auteurs originaux : Sining Ang, Yuan Chen, Liu Haiyan, Xuanyao Mao, Jason Bao, Xuliang, Bingchuan Sun, Yan Wang

Publié 2026-06-25

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Sining Ang, Yuan Chen, Liu Haiyan, Xuanyao Mao, Jason Bao, Xuliang, Bingchuan Sun, Yan Wang

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Le gros problème : L'« Over-Thinker » (celui qui réfléchit trop) vs Le « Réflexe »

Imaginez que vous conduisez une voiture. Vous avez deux « cerveaux » qui travaillent pour vous :

Le Cerveau Réflexe (Système Rapide) : C'est votre instinct. Il réagit instantanément aux feux de freinage, évite les nids-de-poule et maintient la voiture dans sa voie. Il est super rapide mais passe parfois à côté de la vue d'ensemble (comme une zone de travaux complexe).
L'Over-Thinker (Système Lent / LLM) : C'est une IA super intelligente capable de lire les règles de circulation, de comprendre les signaux sociaux complexes et de planifier des itinéraires à long terme. Elle est incroyablement intelligente, mais elle est lente et coûteuse à faire fonctionner (comme engager un consultant brillant mais lent).

Le dilemme actuel :
Si vous demandez conseil à l'« Over-Thinker » chaque seconde de la conduite, la voiture devient trop lente et l'ordinateur chauffe trop (trop coûteux).
Si vous ne lui demandez conseil que toutes les 10 minutes, vous pourriez manquer un moment critique où vous aviez vraiment besoin de son aide.
Les systèmes actuels essaient de deviner quand demander, mais ils demandent souvent trop (gaspillage d'argent) ou au mauvais moment (demandant de l'aide alors que le « Cerveau Réflexe » faisait déjà du super travail).

La Solution : Le « Gardien Intelligent » (ASSCG)

Les auteurs ont créé un nouveau système appelé ASSCG (Adaptive Slow-System Control Gate). Voyez cela comme un Gardien Intelligent se tenant entre le Cerveau Réflexe et l'Over-Thinker.

Au lieu d'un calendrier fixe (ex: « Demander toutes les 5 secondes »), ce Gardien observe la route en temps réel et prend trois décisions spécifiques pour chaque instant :

Query (Demander) : « Hé, la situation vient de devenir bizarre ! Nous avons besoin de l'aide de l'Over-Thinker dès maintenant. »
Cache (Réutiliser) : « L'Over-Thinker nous a donné un excellent conseil il y a 2 secondes, et la route n'a pas changé. Utilisons simplement ce même conseil à nouveau. Pas besoin de déranger l'Over-Thinker. »
Drop (Ignorer) : « L'Over-Thinker est sur le point de donner un mauvais conseil pour cet instant précis (peut-être qu'il hallucine ou qu'il est confus). Ignorons-le et laissons le Cerveau Réflexe gérer seul. »

Le concept du « Juste Milieu » (Just-Right)

Le papier introduit trois idées géniales pour expliquer comment cela fonctionne :

L'« Equivalent Interval » (La portion ennuyeuse) : Imaginez conduire sur une autoroute droite et déserte. Demander conseil à l'Over-Thinker chaque seconde est un gaspillage. Le Gardien réalise : « Nous sommes dans une zone ennuyeuse », et dit : « Cache ». Il réutilise le dernier conseil, économisant ainsi du temps et de l'argent.
Le « Failure Interval » (La zone de mauvais conseils) : Parfois, l'Over-Thinker peut être confus par une ombre étrange ou un reflet et suggérer une manœuvre dangereuse. Le Gardien repère cela et dit : « Drop ». Il ignore activement le système lent pour éviter un accident. C'est une innovation clé : parfois, ne pas utiliser l'IA intelligente est la décision la plus intelligente.
L'« Effective Interval » (Le moment critique) : Lorsqu'une intersection complexe apparaît, le Gardien dit : « Query ! ». Il réveille l'Over-Thinker pour obtenir des directives de haut niveau fraîches.

Comment ils l'ont entraîné

On ne peut pas simplement programmer le Gardien avec des règles car le trafic est trop imprévisible. À la place, ils l'ont enseigné comme un étudiant :

Apprentissage Supervisé : Ils lui ont montré des milliers de vidéos de conduite et lui ont dit : « Dans cette situation, la meilleure décision était de demander ; dans celle-là, la meilleure était d'ignorer. »
Apprentissage par Renforcement (La phase « Essayer et Apprendre ») : Ils ont laissé le Gardien conduire dans un simulateur. S'il prenait une bonne décision (sauver du temps sans s'écraser), il recevait une « récompense » (un traitement de faveur). S'il perdait du temps ou s'écrasait, il recevait une « réprimande » (une pénalité). Avec le temps, il a appris le rythme parfait pour savoir quand demander, quand attendre et quand ignorer.

Les Résultats : Plus Rapides et Plus Intelligents

L'équipe a testé le système sur deux benchmarks de simulation de conduite (nuPlan et NAVSIM). Voici ce qui s'est passé :

Sur le test nuPlan : Ils ont utilisé un système appelé AsyncDriver. Avec le nouveau Gardien, la voiture conduit de manière plus sûre (score plus élevé) et plus vite (60 % de temps informatique en moins utilisé). C'était comme obtenir la vitesse d'une Ferrari avec l'efficacité énergétique d'un vélo.
Sur le test NAVSIM : Ils ont remplacé un module d'IA lourd par un plus léger et ont ajouté le Gardien. La voiture conduit de manière plus fluide et plus rapidement (augmentation de 25 % de la vitesse moyenne) tout en conservant un score de sécurité élevé.

L'essentiel à retenir

Ce papier ne porte pas sur la façon de rendre l'IA plus intelligente pour conduire ; il porte sur la façon de rendre le gestionnaire de système plus intelligent.

Voyez cela comme un Chef de Projet dans un bureau. Un mauvais manager demande l'aide du PDG pour chaque petit e-mail (perdant le temps du PDG). Un meilleur manager sait quand gérer les choses lui-même, quand utiliser un modèle d'hier, et quand ignorer entièrement un e-mail confus.

ASSCG est ce parfait Chef de Projet pour les voitures autonomes, garantissant que l'IA « intelligente » est utilisée uniquement lorsqu'elle apporte une réelle valeur ajoutée, rendant la conduite autonome à la fois plus sûre et plus pratique pour le monde réel.

Résumé Technique : ASSCG – Un déclenchement « juste comme il faut » pour la planification Fast–Slow des LLM dans la conduite autonome

1. Énoncé du problème

Les grands modèles de langage (LLM) et les modèles vision-langage (VLM) offrent un potentiel significatif pour la planification de la conduite autonome en fournissant un raisonnement de sens commun et une guidance contextuelle. Cependant, leur latence d'inférence élevée et leur coût computationnel empêchent un déploiement par image dans les systèmes en temps réel. La solution prédominante est le paradigme fast–slow (système dual), où un planificateur « rapide » (fast) léger et en temps réel opère à chaque image, tandis qu'un module « lent » (slow) lourd basé sur un LLM fournit une guidance de haut niveau à une fréquence plus basse.

Les stratégies de coordination actuelles pour déclencher le module lent souffrent de deux limitations principales :

Déclenchement à intervalle fixe : Interroge le système lent à un taux constant (par exemple, toutes les $K$ images). Cela ignore la variabilité temporelle, menant à des requêtes redondantes dans les scénarios simples (gaspillage de calcul) et à des opportunités manquées dans les scénarios complexes.
Déclenchement basé sur une heuristique de difficulté : Repose sur des indicateurs tels que la « complexité de la scène » ou des estimations d'incertitude. Ces indicateurs échouent souvent à s'aligner sur l'utilité marginale réelle de l'invocation du module lent, entraînant des oscillations inutiles ou des requêtes mal synchronisées.

De plus, l'article observe que la fréquence accrue du raisonnement lent n'est pas toujours bénéfique. Dans certains segments (nommés Intervalles d'Échec ou Failure Intervals), l'invocation du système lent peut dégrader les performances en raison d'hallucinations ou de mauvaises interprétations. Le défi central consiste à formuler une politique de contrôle qui décide quand interroger, quand réutiliser une guidance mise en cache, et quand supprimer totalement le module lent afin de maximer les performances en boucle fermée sous un budget de calcul donné.

2. Méthodologie : Contrôle adaptatif de la porte du système lent (ASSCG)

Les auteurs proposent l'ASSCG, une interface de contrôle agnostique à l'architecture qui gère l'interaction entre un planificateur rapide et un module LLM lent au niveau de l'image.

2.1 Cadre conceptuel

Les auteurs définissent trois intervalles opérationnels pour caractériser la valeur de la guidance lente :

Intervalle Équivalent (EI) : Une fenêtre où le ré-interrogation du système lent produit une information incrémentale négligeable. Le système doit Mettre en cache (reutiliser) la guidance existante.
Intervalle Effectif (EfI) : La durée pendant laquelle la guidance mise en cache actuelle est valide et utile.
Intervalle d'Échec (FI) : Une fenêtre où l'invocation du système lent dégrade les performances en aval par rapport à la non-invocation. Le système doit Supprimer (drop) la guidance.

2.2 Architecture du système

L'ASSCG opère au sein d'une architecture déconnectée fast–slow (ex: AsyncDriver) :

Système Rapide : Un planificateur en temps réel (ex: basé sur GameFormer) s'exécutant à chaque image.
Système Lent : Un planificateur basé sur un LLM (ex: LLaMA2-13B) invoqué à la demande.
Tampon (Buffer) : Stocke une représentation compacte de la guidance lente (caractéristiques latentes, waypoints ou logits).
Contrôleur ASSCG : Un réseau léger qui produit une action discrète $a_t \in \{0, 1, 2\}$ $a_{t} \in {0, 1, 2}$ pour chaque image :
- Interroger (0) : Invoquer le système lent, rafraîchir le tampon et fusionner la nouvelle guidance.
- Mettre en cache (1) : Réutiliser la guidance du tampon sans interroger le système lent.
- Supprimer (2) : Ignorer le tampon (substituer un vecteur nul) pour empêcher une guidance obsolète ou nuisible d'affecter le planificateur rapide.

2.3 Conception du modèle

Backbone : L'ASSCG utilise un backbone RWKV-7. Ce choix est motivé par le besoin d'une modélisation temporelle efficace à long horizon avec une complexité temporelle linéaire et une mémoire constante par étape (après mise en cache de l'état), évitant le coût quadratique des Transformers pour les longs épisodes.
Entrées : La porte reçoit :
- L'embedding de la scène actuelle (provenant d'un encodeur de carte vectorielle).
- La mémoire de référence (le dernier embedding de la guidance lente).
- La similitude cosinus entre la scène actuelle et la référence.
- La caractéristique temporelle ( $\Delta t$ depuis la dernière requête lente).
Pipeline d'entraînement :
1. Apprentissage supervisé (SFT) : La porte est initialisée à l'aide de pseudo-étiquettes dérivées d'une recherche par grille de calendriers de requêtes fixes. Pour chaque scène, le calendrier produisant le score de boucle fermée le plus élevé est sélectionné, et sa séquence de Query/Cache/Drop par image sert d'étiquette.
2. Apprentissage par renforcement sensible au calcul (RL) : La porte est ensuite optimisée via un algorithme de type GRPO (Group Relative Policy Optimization). La fonction de récompense est conçue pour maximiser le score officiel en boucle fermée tout en pénalisant les coûts de requête.
  - Shaping de la récompense : Utilise un shaping basé sur le potentiel pour fournir un feedback intermédiaire dense basé sur des métriques de sécurité et de confort (TTC, confort, respect des limites de vitesse).
  - Coût de requête : Un terme de pénalité ( $\lambda_{call}$ ) est appliqué à l'action « Query » pour encourager l'efficacité.
  - Objectif : La politique est entraînée pour optimiser le compromis entre la qualité de la planification et la fréquence des invocations du module lent.

3. Contributions clés

Analyse de la collaboration Fast–Slow : L'article introduit les concepts d'intervalles Équivalents, Effectifs et d'Échec, démontrant empiriquement que les calendriers fixes et les déclenchements heuristiques sont sous-optimaux car l'utilité du raisonnement lent varie dynamiquement au sein d'un même épisode.
Architecture ASSCG : Un mécanisme de déclenchement (gating) discret au niveau de l'image (Query/Cache/Drop) qui est agnostique à l'architecture et capable de supprimer intentionnellement une guidance lente nuisible.
Stratégie d'entraînement : Un protocole d'entraînement en deux étapes novateur combinant le SFT avec un affinement par RL (GRPO) pour optimiser directement les métriques en boucle fermée sous des contraintes explicites de coût de calcul.
Validation empirique : Évaluation sur deux instanciations distinctes de systèmes fast–slow et différents benchmarks, démontrant des compromis performance-efficacité améliorés.

4. Résultats expérimentaux

4.1 nuPlan Hard20 (basé sur AsyncDriver)

Configuration : Évalué sur le split nuPlan closed-loop Hard20 via une architecture AsyncDriver.
Performance : L'intégration de l'ASSCG améliore le score global à 67,28 (une augmentation de +2,28 par rapport à la baseline AsyncDriver).
Efficacité : La latence d'inférence de bout en bout moyenne a été réduite d'environ 60 % par rapport à la baseline de requête systématique. L'intervalle de requête effectif moyen était de 5,26 images (interrogeant ~19 % des images), ce qui correspond à la latité d'un calendrier à pas fixe de 5 images, mais avec des scores nettement plus élevés.
Détail des métriques : Des améliorations ont été observées dans les métriques liées à la sécurité (TTC, évitement de collision) et au respect des règles (zone de circulation, direction de conduite), suggérant que l'ASSCG permet une conduite plus stable et plus sûre.

4.2 NAVSIM (basé sur RecogDrive)

Configuration : Évalué sur le benchmark NAVSIM en utilisant un système dual où un planificateur rapide léger basé sur ViT est en compétition avec un planificateur lent basé sur un VLM (InternVL-2B).
Performance : Le système doté de l'ASSCG a atteint un PDMS de 91,4 (une augmentation de +0,6 par rapport à l'original ReCogDrive).
Efficience : La latence de calcul moyenne par scène est passée d'environ 350 ms à ~270 ms.
Observation : Le système a réussi à sélectionner la branche lente pour seulement ~40 % des scènes, démontrant que le mécanisme de déclenchement identifie efficacement quand le planificateur rapide est suffisant.

4.3 Études d'ablation

Stratégie d'entraînement : Remplacer GRPO par PPO a entraîné des scores plus bas (66,76 contre 67,28) et une instabilité, soulignant le bénéfice de la formulation RL spécifique utilisée.
Backbone : Remplacer RWKV par un Transformer de nombre de paramètres similaire a produit une précision comparable mais une latence nettement plus élevée (0,06s contre 0,02s pour la dernière image dans de longs épisodes), validant le choix de RWKV pour les applications en temps réel.
Action "Drop" : Supprimer l'action « Drop » a réduit le score de 67,28 à 66,71, confirmant que la capacité à supprimer la guidance lente est critique, et pas seulement la capacité à réduire la fréquence des requêtes.

5. Signification et affirmations

L'article affirme que l'ASSCG fournit un mécanisme de déclenchement « juste comme il faut » qui équilibre la qualité de la planification et le coût des ressources. Sa principale signification réside dans :

Le passage au-delà des déclenchements statiques : Démontrer que des décisions adaptatives au niveau de l'image surpassent les calendriers fixes et les estimations de complexité heuristiques.
La gestion des Intervalles d'Échec : Prouver que le système peut apprendre à ignorer le module lent lorsqu'il est susceptible d'être nuisible, une capacité absente des approches précédentes de type « toujours interroger » ou « déclenchement par complexité ».
La généralisabilité : Montrer que le principe de déclenchement fonctionne à travers différentes architectures de planificateurs sous-jacents (AsyncDriver et RecogDrive) et différents protocoles d'évaluation (nuPlan closed-loop et NAVSIM one-shot).

Les auteurs notent modestement que leur travail évalue quand utiliser une branche lente compte tenu des systèmes existants, plutôt que de prouver que le raisonnement LLM est nécessaire pour chaque scénario. Ils identifient les benchmarks de longue traîne (long-tail) plus complexes comme une étape naturelle suivante.