Технічний контекст
Я б одразу відкинув ідею «просто тримати все у 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 для безперервності, RAG для точних фактів, окремий state-store для сутностей і правил. Саме такі речі ми й створюємо для клієнтів у Nahornyi AI Lab, коли потрібна не демка, а жива AI integration без провалів у пам'яті.
Якщо ваш агент уже почав «забувати» клієнтів, завдання чи ігрові стани, не лікуйте це ще одним довгим промптом. Краще розкласти пам'ять по шарах і зібрати AI solution development під ваш сценарій. Якщо хочете, я з командою Nahornyi AI Lab допоможу спроєктувати це так, щоб система пам'ятала важливе, працювала локально і не розповзалася після кількох сесій.