Mémoire Latente : Révolution dans le Démarrage des Agents LLM

Mémoire Latente : Révolution dans le Démarrage des Agents LLM

Mémoire Latente Persistante pour les Agents LLM Multi-Hop : Comment un article sur le passage 6G résout le problème de démarrage à froid des agents

Ne passez plus de chaînes de prompt entre les agents. Comment utiliser un β-VAE et un MLP à portes pour maintenir le contexte à travers la frontière de transfert.

Anubhab Banerjee

Visualisation de l'ILCP : Combler l'écart de démarrage à froid en transférant le contexte latent compressé directement entre des agents spécialisés.

Une visite humoristique mais réelle de l'ILCP pour les agents — un compresseur β-VAE, un transport de style Xn, un projecteur MLP à portes, et la réalisation incroyablement pratique qu'Anubhab Banerjee avait déjà résolu ce problème exact pour les passages 6G. La version agent V1 est le câblage ; les reçus dans cet article sont les reçus de l'article 6G, correctement étiquetés, car une écriture honnête est tout l'objet de cette série.

— le point culminant — de la série « Inférence Agentique de Qualité Production ». Chaque partie a éliminé un type de travail redondant dans un pipeline LLM agentique. La partie 1 a éliminé le pré-remplissage redondant (ne lisez pas le même document deux fois). La partie 2 a éliminé l'attente redondante (ne mettez pas cinquante agents en file indienne). La partie 3 a éliminé les allers-retours CPU redondants (ne renvoyez pas chaque récupération sur le GPU). La partie 4 (cet article, et le dernier) élimine les reconstructions de contexte redondantes — l'équivalent agentique de jeter votre état caché chaque fois que la conversation passe à un nouveau spécialiste.

Le problème : dans un pipeline d'agents multi-hop, chaque fois que le contrôle passe de l'agent A à l'agent B, le récepteur jette l'état caché de A et reconstruit le contexte à partir d'une chaîne de prompt. C'est structurellement le même « démarrage à froid post-transfert » qu'un équipement utilisateur (UE) subit lorsqu'il se déplace entre deux stations de base (de la source à la cible), où la station de base cible réinitialise l'état récurrent par utilisateur à partir de zéro.

La solution : compresser l'état récurrent de l'expéditeur en une petite charge utile latente, le transporter à travers le transfert, et laisser le récepteur l'utiliser comme un préfixe de prompt doux au lieu de tout pré-remplir à partir du texte. La même leçon « calculer une fois, diffuser l'état partagé » que la série a martelée depuis la partie 1, appliquée à travers les sauts de raisonnement au lieu d'un seul pipeline.

Les reçus 'inhabituels' : la méthode sous-jacente est la Persistance de Contexte Latent Inductive (ILCP), un article évalué par des pairs qu'Anubhab Banerjee a coécrit récemment, accepté à AI4NextG @ ICML 2026. Lors du test de conduite 4G/5G à Vienne, l'ILCP élimine complètement les transferts ping-pong (0,0 % contre 6,5 % de référence sans transfert, 22,6 % de référence Transformer), récupère la précision post-transfert avec une augmentation de +5,1 pp en moyenne / +13,3 pp au maximum, et fonctionne de bout en bout à 7,7 ms p99 par décision de transfert sur la même GTX 1080 que le reste de cette série.

La partie honnête : ces chiffres sont des chiffres de transfert radio 6G, pas des chiffres d'agents LLM. La version agent V1 dans cet article (ilcp-for-agents) est le câblage — un compresseur β-VAE, un transport en cours, un projecteur MLP à portes, et un harnais Qwen2.5-7B — et ses benchmarks côté agent sont explicitement des travaux futurs. Anubhab Banerjee refuse de blanchir les reçus RAN en tant que reçus LLM même là où la tentation est forte.

Le point clé : le fil télécom qui a traversé les parties 1 à 3 en tant qu'analogie est, dans la partie 4, la recherche publiée d'Anubhab Banerjee résolvant le même problème dans deux industries différentes. La série boucle la boucle.

TL;DR : Les agents LLM multi-hop transmettent actuellement le contexte sous forme de chaîne. L'agent A termine son raisonnement, le résume en texte de prompt, et l'agent B lit cette chaîne depuis le début — le cache KV du récepteur, le modèle d'attention et tout calcul partiel que l'agent A a construit sont tous jetés. C'est la version agentique du démarrage à froid post-transfert que subissent les stations de base 5G/6G lorsqu'un UE (appareil mobile) se déplace entre deux stations de base : la station de base cible réinitialise l'état récurrent par UE et doit le reconstruire à partir de zéro. Ce problème a été résolu avec une méthode appelée Persistance de Contexte Latent Inductive (ILCP) : un β-VAE compresse un état GRU de 128 dimensions en une charge utile latente de 128 octets, le transporte sur l'interface 3GPP Xn standard, puis un MLP à portes le projette dans l'espace d'état de la station de base cible au moment du transfert. Lors du test de conduite 4G/5G à Vienne, l'ILCP élimine les transferts ping-pong (0,0 % contre 6,5 % de référence sans transfert), récupère la précision du prochain cellulaire post-transfert de +5,1 pp en moyenne / +13,3 pp au maximum dans la fenêtre de 50 à 250 ms après le transfert, et fonctionne à 7,7 ms p99 par décision sur une seule GTX 1080. Cette partie applique ce même protocole aux transferts d'agents LLM : ilcp-for-agents apprend à compresser un résumé caché poolé, à le transporter à travers le transfert, et à le projeter à nouveau dans un préfixe de prompt doux côté récepteur. V1 est le câblage (PyTorch, Qwen2.5-7B-Instruct, β-VAE, MLP à portes, transport en cours, métrique de correspondance exacte). La contribution ici est le transfert architectural, pas les chiffres.

Modèle mental d'architecture — gardez cela ouvert pendant votre lecture.

Contexte de l'agent A → pool moyen masqué → encodeur β-VAE → z (32-dim latent) → Charge utile de transport en cours → décodeur β-VAE + MLP à portes → K tokens mémoire → torch.cat sur les embeddings de question de l'agent B → décodage gourmand

Tout ce qui suit est juste un commentaire sur un morceau de cette ligne.

Compresser, transporter et projeter

1. Une confession : Anubhab Banerjee a résolu ce problème avant de savoir qu'il l'avait

Dans la partie 3, il a été poussé à des longueurs légèrement absurdes pour garder les tenseurs exactement là où ils appartiennent : sur le silicium. En écrivant un noyau CUDA personnalisé pour la récupération Top-K, les allers-retours CPU redondants qui freinent l'agentique RAG ont été éliminés. La philosophie était absolue — une fois que le GPU calcule un état riche et de haute dimension, il ne doit pas être déplacé, et il ne doit certainement pas être détruit. Et pourtant, au moment où ce récupérateur hautement optimisé termine son travail et passe le relais au prochain spécialiste du pipeline, les frameworks standard obligent à faire exactement cela. L'état de tenseur est protégé à l'intérieur d'un seul nœud, seulement pour être jeté volontairement à la poubelle dès qu'un saut de raisonnement est franchi.

Voici comment le transfert d'agent est dramatisé de la manière dont chaque pipeline multi-hop le fait aujourd'hui.

Un utilisateur : « Agent A, lis ce rapport de 50 pages, crée un résumé et passe-le à l'agent B pour vérification des faits. »

Agent A : « Bien sûr. Chargement du modèle. Lecture du rapport. Pooling du contexte. Construction de l'attention sur le paragraphe 47. Formation de mes opinions. ✅ »

Le GPU travaille pendant 30 secondes.

Agent A : « Terminé. Voici un résumé de 200 tokens dont je suis très fier. »

L'utilisateur : « Super. Transfert à l'agent B. »

Agent A : « Attendez, comment exactement vous transférez ? »

L'utilisateur : « …sous forme de chaîne ? Dans le prompt ? »

Agent A : « D'accord. Donc, vous envoyez à l'agent B ma chaîne finale. Pas mon état caché. Pas mon attention calculée sur les 50 pages que je viens de lire. Pas le fait que le paragraphe 47 était particulièrement important. Pas la confiance calibrée que j'ai construite. Juste la chaîne. »

L'utilisateur : « C'est comme ça que ça fonctionne, oui. »

Agent A : « Cool. Cool cool cool. Amuse-toi, B. 👋 »

Agent B : « Bonjour, je suis un magnifique nouveau-né sans état. Chargement du modèle. Lecture de la chaîne de l'agent A depuis le début. Construction du contexte. Pooling. Formation d'opinions. ✅ »

Le GPU passe encore 30 secondes à faire essentiellement le même travail que l'agent A vient de terminer.

L'utilisateur : « …y a-t-il un moyen de sauter la deuxième construction de contexte et le calcul d'attention ? »

Agent B : « Quelle deuxième lecture ? »

C'est exactement ce à quoi ressemble chaque « essaim multi-agent » observé sous le capot. Chaque transfert est une gorge en forme de chaîne à travers laquelle l'état interne de l'expéditeur ne peut pas passer. Le récepteur obtient le texte de sortie et reconstruit le contexte à partir du texte — ce qui est la chose la plus coûteuse qu'un transformateur fasse généralement, et la chose que cette série a passé trois parties à essayer de convaincre d'arrêter de faire au sein d'un seul cycle de pipeline.

Un fait amusant est qu'Anubhab Banerjee a déjà écrit sur ce problème, juste pas pour les agents LLM.

En 2026, Anubhab Banerjee et son co-auteur ont publié un article intitulé « Persistance de Contexte Latent Inductive : Clôturer le Démarrage à Froid Post-Transfert dans les Réseaux d'Accès Radio 6G ». Le cadre est un téléphone mobile (également appelé équipement utilisateur ou UE) se déplaçant entre des stations de base 5G/6G (également appelées gNB). À chaque transfert, le gNB cible jette l'état récurrent par UE détenu au gNB source et réinitialise l'état caché par UE au gNB cible. Le modèle de prédiction côté cible doit alors reconstruire cet état à partir des quelques mesures radio post-transfert qu'il vient de recevoir, tandis que l'UE est déjà en mouvement. L'article appelle cela le démarrage à froid post-transfert. Cela vous dit quelque chose ?

Maintenant, lisez ce paragraphe des contributions de l'article, légèrement déjargonné : « Nous traitons l'état récurrent par utilisateur comme un contexte réseau portable. Pour résoudre le problème pratique que le message inter-cellules standard a un petit budget de taille, nous montrons qu'une mise à jour différentielle de 128 octets est suffisante pour préserver la qualité prédictive d'un état GRU de 128 dimensions à travers la frontière de transfert. Notre protocole ILCP proposé compresse l'état caché avec un autoencodeur variational β, le transporte sur l'interface 3GPP Xn standard, et le projette dans l'espace d'état du gNB cible au moment du transfert via un MLP à portes appris. »

Si vous remplacez « gNB source » par « agent A », « gNB cible » par « agent B », et « mesures radio » par « tokens de la prochaine sous-tâche », vous avez l'architecture dont tout cet article parle. Même article, même auteur, juste le domaine d'application est différent.

La contribution de cet article n'est pas la méthode — la méthode est déjà dans l'article. La contribution de cet article est le mapping : prendre l'ILCP et le câbler pour les agents LLM multi-hop, de bout en bout, dans un petit dépôt PyTorch que vous avez déjà vu. Les reçus que vous êtes sur le point de voir dans la section 5 sont t