Aller au contenu

Une architecture d'encodeur

Rappel

Conception spéculative. Les points 3 et 4 en particulier sont une proposition, pas un résultat publié.


Le problème à résoudre, précisément

Compresser 10 M de tokens en une mémoire qui soit :

  1. cacheable — un bloc encodé une fois est réutilisable tel quel ;
  2. parallélisable — pas de dépendance causale entre blocs ;
  3. fidèle sur le rappel exact — y compris pour distinguer des passages qui se ressemblent.

Les points 1 et 2 sont résolus depuis 2024 par la littérature ouverte. Le point 3 est celui où tout le monde échoue — c'est la cause de l'écart RULER/MRCR chez Isaac, et de l'effondrement de Llama 4 Scout à 15,6 %.


Les six composants

1. Découpage en blocs avec recouvrement

Blocs de 1 024 tokens, avec un recouvrement de 64 tokens.

Le recouvrement n'est pas un détail : sans lui, un fait à cheval sur une frontière de bloc est réparti entre deux résumés et n'est correctement présent dans aucun. Coût : +6 % d'encodage.

2. Encodeur bidirectionnel léger et partagé

≈ 2 G de paramètres, 8 à 12 couches, partagé par tous les blocs.

Pourquoi bidirectionnel

Un bloc est traité en entier : aucune causalité n'est requise à l'intérieur. Un encodeur bidirectionnel voit le bloc dans les deux sens, ce qui produit de meilleurs résumés pour le même coût.

C'est aussi ce qui donne le parallélisme total au préfill — les blocs n'ont aucune dépendance entre eux — et donc mécaniquement un débit élevé. C'est le cœur de CEPE.

C'est enfin ce qui justifie littéralement l'étiquette « non purement décodeur » que revendique Pokee.

3. Quatre têtes de compression spécialisées

C'est ici que la proposition s'écarte de la littérature.

Au lieu d'un vecteur unique par bloc, l'encodeur produit quatre vecteurs, via quatre requêtes apprises distinctes :

Tête Ce qu'elle capture
Littérale Entités nommées, identifiants, nombres, chaînes rares
Sémantique Le sujet et le propos du bloc
Structurelle Rôle et position relative dans le document
Résiduelle Ce que les trois autres n'ont pas pris

Le raisonnement

Un vecteur unique doit simultanément résumer (agréger, généraliser) et discriminer (retenir ce qui distingue ce bloc d'un bloc presque identique). Ces deux objectifs tirent la représentation dans des directions opposées.

C'est très exactement l'origine des 22 points d'écart entre RULER et MRCR : la tâche facile ne demande que de résumer, la tâche dure demande de discriminer.

Séparer les têtes permet d'entraîner chacune sur son objectif propre.

Avec 4 têtes pour des blocs de 1 024 tokens, la compression effective est de 1:256 — mais la mémoire est bien plus riche qu'un vecteur unique pour 256 tokens.

4. Une voie creuse à côté de la voie dense

Second écart avec la littérature, et le plus important.

À côté des vecteurs denses, conserver par bloc un index lexical creux : un sac de n-grammes rares, ou une signature de hachage des tokens à faible fréquence.

Pourquoi c'est la bonne réponse au problème MRCR

La compression dense perd les quasi-doublons par construction : deux blocs sémantiquement identiques produisent des vecteurs voisins, et aucune quantité d'entraînement ne changera cela tant que la représentation est dense et de basse dimension.

Un index lexical, lui, distingue trivialement « facture n° 48 812 » de « facture n° 48 813 » — pour un coût de stockage négligeable et sans aucun calcul matriciel.

C'est l'hybride dense + creux standard en recherche d'information, transposé à la mémoire interne d'un modèle. La recherche documentaire a résolu ce problème il y a des années ; la compression de contexte ne s'en est pas encore servie.

5. Sélection avant lecture

Ne pas faire d'attention croisée sur toute la mémoire, mais scorer puis lire les \(k\) meilleurs blocs — le mécanisme de NSA.

C'est ce qui débloque tout le dimensionnement :

Configuration Mémoire Attention croisée Total
1:64 sans sélection 320 Mo 1,28 GFLOPs 18,03 — hors budget
1:1024 sans sélection 20 Mo 0,08 GFLOPs 13,23 — fidélité sacrifiée
1:64 avec \(k=32\) 320 Mo 1,05 MFLOPs 12,91
1:64 avec \(k=64\) 320 Mo 2,10 MFLOPs 12,91
1:64 avec \(k=128\) 320 Mo 4,19 MFLOPs 12,91

Le résultat de conception le plus utile

La compression 1:64 avec sélection coûte moins cher que 1:1024 sans sélection. On gagne un facteur 16 de fidélité tout en économisant du calcul.

Et le coût de lecture devient invisible — quelques mégaFLOPs, contre 12 000 pour les couches linéaires. La valeur de \(k\) n'a plus aucune influence sur le budget : autant la prendre large.

C'est le seul point de ce chapitre où l'on n'a pas à arbitrer.

6. Où brancher l'attention croisée

Quatre couches réparties dans la profondeur, pas au début de la pile.

YOCO empile son cross-decoder au-dessus du self-decoder : la moitié basse construit une représentation, la moitié haute consulte la mémoire. Répartir plutôt que concentrer permet au modèle de reformuler sa requête entre deux consultations — l'équivalent d'un raisonnement en plusieurs sauts.


L'entraînement — le vrai point dur

L'inférence est facile à dimensionner. L'entraînement est là où tout se joue, et c'est vraisemblablement ce que protègent les cinq brevets de Pokee.

Trois objectifs simultanés :

Objectif Fonction Emprunté à
Reconstruction Le décodeur doit pouvoir régénérer le bloc depuis sa mémoire seule — garantit que rien d'essentiel n'est perdu ICAE
Modélisation du langage à longue portée Prédire la suite en s'appuyant sur la mémoire des blocs lointains CEPE
Discrimination contrastive Forcer les mémoires de blocs quasi identiques à rester séparables proposition

Sans le troisième objectif, on refabrique le problème

Les deux premiers objectifs sont déjà publiés et fonctionnent. Aucun des deux ne pénalise le modèle lorsqu'il confond deux blocs semblables — au contraire, la reconstruction et la modélisation du langage récompensent la généralisation.

Un modèle entraîné sur ces deux objectifs seuls produira exactement le profil « excellent en RULER, faible en MRCR ». Le troisième objectif est le correctif, et il demande de construire des paires difficiles — des blocs qui se ressemblent mais qu'il faut distinguer.

C'est coûteux, et c'est probablement là que se situe la vraie difficulté d'ingénierie.


Ce que cette proposition ne résout pas

Par honnêteté :

  • Aucun travail publié ne va à 10 M par cette voie. CEPE plafonne à 128 K, YOCO à 1 M. L'extrapolation du design reste entièrement à démontrer.
  • Les points 3 et 4 ne sont pas validés expérimentalement. Ils sont raisonnables et bon marché, ce qui n'est pas la même chose que démontrés.
  • Trois mémoires de natures différentes à orchestrer dans un moteur d'inférence : Kimi K3 montre que deux coûtent déjà très cher en infrastructure.
  • La compression reste avec perte. L'index creux atténue le problème sur les identifiants littéraux ; il ne fait rien pour les distinctions sémantiques fines.

Chapitre suivant : Ce que la recherche ouverte a déjà exploré