Contexte technique
J'écarterais immédiatement l'idée de « tout garder dans les 256k ». Ça ne fonctionne que sur le papier. Pour un assistant de jeu qui a besoin de faits issus d'anciennes sessions, ce système tombe en panne dès qu'une nouvelle partie commence ou que l'ancienne histoire ne rentre plus.
J'ai vu la même chose à maintes reprises dans les projets d'implémentation d'IA : le résumé sauve la fenêtre de contexte mais tue progressivement la précision. À la troisième ou quatrième session, le modèle ne se souvient pas de l'histoire, mais d'un résumé de résumé. C'est là que commence l'amnésie silencieuse.
D'un point de vue pratique, je construirais la mémoire en trois couches. La première couche est le contexte « chaud » de la session en cours. La deuxième est un résumé d'état compact : personnages, quêtes, inventaire, branches inachevées, règles du monde. La troisième est un RAG local sur les événements bruts des sessions passées, et non un simple fichier markdown assemblé.
Il ne s'agit donc pas d'« exporter en md et de le découper n'importe comment », mais d'une véritable mémoire basée sur les événements. Chaque événement significatif est enregistré comme une entrée distincte : qui a fait quoi, où, quand et avec quelles conséquences. Ensuite, j'indexerais cela avec des embeddings et ajouterais des filtres de métadonnées standard : session_id, npc, location, quest, item.
Les résumés restent nécessaires, mais pas comme seule source de vérité. Je mettrais à jour le résumé à environ 70-80 % de la capacité de la fenêtre, mais en le gardant court et strictement structuré. Pas un récit littéraire, mais presque un cerveau JSON : objectifs, faits, relations, changements du monde.
Si l'infrastructure le permet, il est préférable d'exécuter Gemma 4 via vLLM ou un runtime similaire avec paged attention. Cela ne résout pas la mémoire à long terme en soi, mais simplifie grandement la gestion d'un contexte long et du cache KV, surtout si vous avez plusieurs sessions actives.
Ce que cela change pour l'entreprise et l'automatisation
Le principal avantage ici n'est pas que « le modèle est devenu plus intelligent », mais qu'il cesse d'oublier les détails critiques. Pour les assistants de jeu, le support client, les agents CRM et les copilotes internes, ce n'est plus une simple amélioration, mais le fondement de l'automatisation par l'IA.
Qui sont les gagnants ? Ceux qui ont besoin de précision sur les événements passés : projets de jeux, équipes de service, produits avec un long cycle de vie utilisateur. Qui sont les perdants ? Ceux qui espèrent tout résoudre avec un seul résumé et s'étonnent ensuite que leur agent invente des informations avec assurance.
Ma méthode serait la suivante : un résumé pour la continuité, un RAG pour les faits précis, et un state-store séparé pour les entités et les règles. C'est exactement ce que nous construisons pour nos clients chez Nahornyi AI Lab lorsqu'ils ont besoin d'une intégration IA fonctionnelle sans perte de mémoire, pas seulement d'une démo.
Si votre agent a déjà commencé à « oublier » des clients, des tâches ou des états de jeu, n'essayez pas de régler le problème avec un autre prompt interminable. Il est préférable de structurer la mémoire en couches et de développer une solution IA adaptée à votre scénario. Si vous le souhaitez, mon équipe chez Nahornyi AI Lab peut vous aider à la concevoir pour que le système se souvienne de l'essentiel, fonctionne localement et reste stable après quelques sessions.