TinyEngram : injecter de la mémoire N-gram dans Qwen et Stable Diffusion

Le problème : mémoriser des phrases sans réentraîner le modèle

Un transformer classique encode le contexte dans ses activations, qui disparaissent à la fin de la fenêtre. Pour qu'un modèle retienne un fait, un style ou un personnage, la méthode courante consiste à ajuster les poids, avec LoRA ou un fine-tuning complet. TinyEngram explore une autre voie, décrite dans le README comme l'intégration d'un module de mémoire N-gram compact et d'un mécanisme de récupération à porte dans certaines couches du transformer. L'objectif affiché est double : améliorer la compréhension au niveau des phrases et offrir une alternative aux adaptateurs de rang faible. Le public visé est précis. Ce sont des chercheurs et des ingénieurs qui veulent reproduire l'architecture Engram sur une base Qwen, comparer son comportement à LoRA, ou tester si le même principe fonctionne sur un modèle de diffusion. Le dépôt se présente comme un cahier de recherche vivant autant qu'une boîte à outils, ce qui implique des interfaces instables et une documentation qui suit les expériences plutôt que l'inverse.

Ce que le dépôt contient réellement

La structure visible dans le README est celle d'un projet de reproduction, pas d'une bibliothèque publiée. On y trouve un requirements.txt épinglé, un répertoire doc avec des rapports d'expériences, un rapport technique sur la vision au format PDF, et des scripts de reproduction pour l'expérience Engram contre LoRA. Les journaux d'annonces mentionnent des études d'ablation sur le nombre de paramètres, des observations de convergence, et une comparaison de l'oubli catastrophique entre TinyEngram et LoRA. Aucune release n'est listée dans les métadonnées fournies. Le badge du README pointe vers une licence MIT, mais le champ License de la fiche dépôt est vide. Cette divergence n'est pas anodine : elle signifie qu'il faut ouvrir le fichier LICENSE à la racine avant de réutiliser du code. Le langage principal est Python, la branche par défaut est main, et le dernier push date du 21 mai 2026.

Le mécanisme : correspondance exacte de N-grammes et récupération à porte

Le principe décrit est le suivant. Un vocabulaire N-gram est construit, puis associé à des embeddings appris. Quand le texte d'entrée contient un N-gramme présent dans ce vocabulaire, l'embedding correspondant est récupéré et injecté dans les couches concernées via un mécanisme de porte. Le README insiste sur un point qui distingue cette approche d'une mémoire associative classique : la correspondance est exacte, et les collisions de hachage sont qualifiées de dures. Autrement dit, deux entrées différentes ne partagent pas le même emplacement mémoire par accident. C'est ce qui permet à l'auteur d'affirmer que les souvenirs n'interfèrent pas entre eux et que l'on peut empiler de nombreux engrammes de personnages ou de styles, chacun ne se déclenchant que sur son nom exact. Cette propriété a un revers immédiat : une variante orthographique, une faute de frappe ou une reformulation ne déclenche rien. La mémoire est précise mais rigide, et la qualité du déclenchement dépend entièrement de la construction du vocabulaire. Le README ne détaille pas la procédure de construction ni les seuils de sélection, ce qui est une lacune pour quiconque veut reproduire l'expérience sur son propre corpus.

L'extension vision : injecter des concepts dans le Text Encoder

La partie TinyEngram-Vision applique le même schéma à Stable Diffusion. Les concepts visuels sont traités comme des souvenirs injectés dans le Text Encoder. Le README précise que le backbone U-Net ou DiT reste gelé, ce qui évite un fine-tuning lourd. Le déclenchement se fait par reconnaissance de N-grammes spécifiques dans le prompt. Un rapport technique complet est disponible en PDF dans doc/paper, avec une version arXiv. Le dépôt mentionne SD 1.5 et 3.5 comme bases. Cette approche est présentée comme composable, et l'argument de non-interférence repose sur la même correspondance exacte que pour le texte. Pour un lecteur qui a déjà manipulé des embeddings textuels inversés ou des adaptateurs de concept, la différence tient au point d'injection et au déclenchement par chaîne exacte plutôt que par similarité sémantique. Le README ne donne pas de mesure de qualité visuelle, et le rapport PDF n'est pas reproduit dans le matériel fourni. Toute évaluation de la fidélité des images générées devra donc se faire à partir du rapport lui-même.

Mise en route : commandes et fichiers de configuration

L'installation tient en quatre commandes, telles que listées dans le README. On crée un environnement conda nommé tinyengram avec Python 3.10, on l'active, on met pip à jour, puis on installe les dépendances depuis requirements.txt. Le README renvoie vers doc/reproduction/environment.md pour les notes CUDA et les dépendances optionnelles d'évaluation. C'est le seul fichier de configuration mentionné explicitement. Aucune clé de configuration, aucun paramètre d'entraînement et aucun point d'entrée de script ne sont donnés dans le matériel fourni. Les scripts de reproduction de l'expérience Engram contre LoRA sont annoncés comme publiés, mais leurs noms et leurs arguments ne figurent pas dans le README nettoyé. Concrètement, un lecteur qui clone le dépôt devra explorer l'arborescence pour trouver les points d'entrée, et lire environment.md avant de lancer quoi que ce soit sur GPU.

Les limites que le README ne masque pas, et celles qu'il omet

La correspondance exacte est présentée comme un avantage pour l'isolation des souvenirs. C'est aussi la principale contrainte d'usage : le système ne généralise pas au-delà de la chaîne apprise. Un modèle qui doit répondre à des formulations variées, à des paraphrases ou à des langues différentes de celles du vocabulaire construit ne bénéficiera pas de l'injection. La méthode est donc mal adaptée aux tâches de compréhension ouverte, où la similarité sémantique compte plus que l'identité littérale. Deuxième point : le dépôt ne publie aucune release, et les métadonnées n'indiquent pas de licence confirmée. Un projet de recherche sans release ni licence explicite dans la fiche n'offre aucune garantie de stabilité d'API. Troisième point, plus gênant pour la reproduction : le README affirme que TinyEngram surpasse LoRA en efficacité de paramètres et en résistance à l'oubli catastrophique, mais aucun chiffre, protocole ou jeu de données n'apparaît dans le texte fourni. Ces résultats sont renvoyés aux rapports et aux scripts, ce qui est normal pour un dépôt de recherche, mais insuffisant pour juger sur pièces.

Face à LoRA : deux logiques différentes

LoRA modifie le comportement du modèle en ajoutant des matrices de rang faible entraînées dans les couches d'attention. L'adaptation est continue et s'applique à toutes les entrées, ce qui permet une généralisation souple mais expose au chevauchement entre adaptateurs et, selon le README de TinyEngram, à l'oubli catastrophique. TinyEngram ne modifie pas les poids de la même manière : il ajoute une mémoire externe consultée par correspondance exacte, avec une porte qui contrôle l'injection. La différence pratique est nette. LoRA répond à une intention, TinyEngram répond à une chaîne. Pour empiler des dizaines de concepts distincts sans qu'ils se contaminent, la seconde approche est plus prévisible. Pour adapter un modèle à un domaine entier avec des formulations imprévues, LoRA reste plus adapté. Le choix dépend donc de la nature de ce que l'on veut mémoriser : des entités nommées et des déclencheurs précis, ou un style de réponse diffus.

Coût de maintenance et questions de licence

Le dépôt est actif, avec un dernier push en mai 2026, et il n'est pas archivé. Mais l'absence de release signifie qu'il n'existe pas de version figée à épingler. Un utilisateur qui suit main s'expose à des changements de structure entre deux commits. Le requirements.txt est présenté comme épinglé pour les dépendances directes, ce qui limite une partie du risque, sans le supprimer : les dépendances transitives et les versions CUDA restent à gérer, et le README renvoie explicitement à environment.md pour ces notes. Sur la licence, le badge du README indique MIT, mais le champ License des métadonnées est vide. En l'absence de confirmation dans le fichier LICENSE, on ne peut pas affirmer les conditions de réutilisation, notamment pour un usage commercial ou pour la redistribution de poids entraînés. C'est le premier point à vérifier avant toute intégration, et cela vaut aussi pour les modèles de base Qwen et Stable Diffusion, qui ont leurs propres conditions.

Conclusion éditoriale

TinyEngram s'adresse aux équipes de recherche qui veulent reproduire ou étendre l'architecture Engram sur Qwen et tester l'injection de concepts dans Stable Diffusion sans toucher au backbone. Ce n'est pas un outil de production : pas de release, pas de licence confirmée dans les métadonnées, pas de garantie de compatibilité. Avant tout usage, ouvrez le fichier LICENSE du dépôt et vérifiez requirements.txt ainsi que doc/reproduction/environment.md, car ce sont les seules sources fiables sur les dépendances et les conditions d'utilisation.

Sources officielles

1. AutoArk/TinyEngram on GitHub
2. Issues
3. README