Технический контекст
Я бы сразу выкинул идею «просто держать всё в 256k». Это красиво только на бумаге. Для игрового ассистента, где нужны факты из старых сессий, такая схема ломается ровно в тот момент, когда начинается новая игра или старая история перестаёт помещаться.
Я уже много раз видел одно и то же в AI implementation проектах: саммари спасает окно, но постепенно убивает точность. На третьей-четвёртой сессии модель помнит не историю, а пересказ пересказа. И вот тут начинается тихая амнезия.
Если говорить по делу, я бы строил память в три слоя. Первый слой это «горячий» контекст текущей сессии. Второй это компактное state-summary: персонажи, квесты, инвентарь, незавершённые ветки, правила мира. Третий это локальный RAG по сырым событиям прошлых сессий, а не по одному markdown-файлу, слепленному в кучу.
То есть не «экспортнул в md и как-нибудь чанканул», а нормальная event-based память. Каждое значимое событие пишется как отдельная запись: кто, что сделал, где, когда, с какими последствиями. Потом я бы индексировал это через embeddings плюс добавил обычные metadata-фильтры: session_id, npc, location, quest, item.
Саммари всё равно нужно, но не как единственный источник правды. Я бы обновлял его примерно на 70-80% окна, но держал коротким и строго структурированным. Не литературный пересказ, а почти JSON-мозг: цели, факты, отношения, изменения мира.
Если инфраструктура позволяет, Gemma 4 лучше крутить через vLLM или похожий рантайм с paged attention. Это не решает долгую память само по себе, но сильно упрощает жизнь с длинным контекстом и KV cache, особенно если у вас не одна активная сессия.
Что это меняет для бизнеса и автоматизации
Главный выигрыш тут не в «модель стала умнее», а в том, что она перестаёт забывать критичные детали. Для игровых ассистентов, саппорта, CRM-агентов и internal copilots это уже не косметика, а основа AI automation.
Кто выигрывает? Те, кому нужна точность по старым событиям: игровые проекты, сервисные команды, продукты с длинным пользовательским циклом. Кто проигрывает? Те, кто надеется закрыть всё одной суммаризацией и потом удивляется, почему агент уверенно врёт.
Я бы делал так: summary для continuity, RAG для точных фактов, отдельный state-store для сущностей и правил. Именно такие штуки мы и собираем для клиентов в Nahornyi AI Lab, когда нужна не демка, а живая AI integration без провалов памяти.
Если у вас агент уже начал «забывать» клиентов, задачи или игровые состояния, не лечите это ещё одним длинным промптом. Лучше разложить память по слоям и собрать AI solution development под ваш сценарий. Если хотите, я с командой Nahornyi AI Lab помогу спроектировать это так, чтобы система помнила важное, работала локально и не расползалась после пары сессий.