Memory Management для LLM

Короткая версия

Четыре главных слоя памяти:

Главный принцип

Не всё, что было в истории, должно стать memory. Память полезна только тогда, когда она:

• влияет на будущий ответ;
• достаточно стабильна;
• не дублирует transcript и retrieval;
• окупает token/storage cost.

Пользователь сказал:
- сегодня: «я хочу краткие ответы»
- вчера: «мы выбрали Anthropic для MVP»
- месяц назад: «я Product Manager в e-commerce»

1. Working State

Working state — это всё, что модель видит в текущем вызове:

• instructions;
• recent turns;
• retrieved docs;
• tool results;
• output constraints.

Это не “память” в долгоживущем смысле, а самый короткий слой состояния. Он живёт ровно один вызов и потом исчезает.

Поэтому working state надо держать маленьким, актуальным и хорошо структурированным.

2. Short-term Conversation State

Short-term state живёт в пределах одной сессии. Его задача — удерживать continuity:

• что обсуждают прямо сейчас;
• какую подзадачу решают;
• какие ограничения уже всплыли;
• какие шаги уже сделали;
• какой последний tool result важен.

Это почти всегда лучше хранить как сочетание:

• recent turns;
• compact summary state;
• latest task markers.

Short-term state не должен автоматически становиться durable memory.

3. Durable Memory

Durable memory хранит то, что полезно и за пределами одной сессии:

• preferred language;
• имя и роль пользователя;
• устойчивые preferences;
• важные account facts;
• постоянные style constraints.

Хороший durable memory слой обычно:

• небольшой;
• избирательный;
• обновляемый;
• пригодный для explicit CRUD.

4. Episodic и Semantic Memory

Кроме устойчивых фактов полезно хранить:

• отдельные важные прошлые события;
• решения и договорённости;
• большие смысловые summary завершённых сессий;
• факты, которые потом можно искать семантически.

Именно сюда часто попадают:

• “в прошлый раз выбрали стек X”;
• “отклонили вариант B из-за цены”;
• “пользователь уже просил examples из e-commerce”.

Это не всегда должно грузиться в каждый запрос. Часто такой слой лучше работает через semantic recall по необходимости.

5. Memory write policy важнее, чем сам store

Самая частая ошибка — хранить всё подряд.

В продакшене полезнее иметь explicit write policy:

записывать:

• устойчивые preferences;
• долгоживущие user facts;
• решения, которые ещё влияют на работу;
• важные эпизоды.

не записывать:

• случайные детали одного вопроса;
• временные формулировки;
• всё подряд из transcript;
• шумные или конфликтующие факты без проверки.

6. Memory read policy тоже нужна

Не вся память должна загружаться всегда.

Обычно есть три режима чтения:

1. Always-on facts: имя, язык, persistent preferences.
2. Route-aware facts: подтягивать только для нужных сценариев.
3. Semantic recall: искать эпизоды и summary только если текущий запрос на них похож.

Это позволяет не раздувать context бесполезными фактами.

7. Memory и transcript — не одно и то же

Одна из самых важных границ:

Плохая архитектура — та, где transcript просто без фильтра переезжает в memory.

8. Memory и RAG тоже не одно и то же

RAG обычно отвечает на вопрос:

• какие внешние документы нужны сейчас?

Memory отвечает на другой вопрос:

• что система должна помнить об этом пользователе, процессе или прошлой работе?

Они могут использовать похожие retrieval-механизмы, но их purpose разный.

9. CRUD memory лучше не прятать

Если память живёт долго, ей почти всегда нужен lifecycle:

• create;
• read;
• update;
• delete.

Это важно потому, что факты устаревают:

• пользователь сменил роль;
• preference изменился;
• старое решение больше не актуально;
• один факт противоречит новому.

Поэтому memory store без update/delete быстро становится грязным.

10. Memory для agents

У агентных систем memory почти всегда делится ещё жёстче:

• working state текущего шага;
• task memory по текущему run;
• durable memory между runs;
• shared memory для multi-agent coordination.

Это особенно важно, потому что агенту часто нужно помнить:

• что уже пробовали;
• какие tool calls сработали;
• какой state уже достигнут;
• где остановились при предыдущем запуске.

11. MemGPT как крайний ориентир

MemGPT полезен не столько как буквальный production default, сколько как mental model: контекстное окно похоже на RAM, а durable store — на более медленное, но большое внешнее хранилище.

Это подталкивает к здоровому вопросу:

• что держать в working state;
• что выгружать в durable memory;
• что подтягивать обратно только по необходимости.

12. Healthy memory architecture

Для большинства production-систем здоровый memory stack выглядит так:

1. recent turns в short-term state;
2. compact summary текущей сессии;
3. небольшой durable profile;
4. episodic recall по необходимости;
5. explicit write/read policy;
6. cleanup и update rules.

Пример минимального memory policy

from dataclasses import dataclass


@dataclass
class MemoryFact:
    key: str
    value: str
    scope: str  # durable | episodic


def should_store_fact(key: str, value: str) -> bool:
    if key in {"language", "role", "style_preference", "project_choice"}:
        return True
    return False


def build_memory_block(facts: list[MemoryFact]) -> str:
    lines = [f"- {fact.key}: {fact.value}" for fact in facts[:10]]
    return "\n".join(lines)

Критично здесь не количество кода, а наличие policy:

• не всё записывается;
• facts ограничиваются по числу;
• durable и episodic scope различаются.