Урок 1.3. Когнитивная модель памяти: полезная аналогия с человеком

Цель лекции

Дать читателю словарь типов памяти через понятную аналогию с человеческой памятью, не превращая лекцию в биологию.

Зачем это нужно

В предыдущих лекциях мы установили две базовые идеи: LLM сама по себе не хранит долговременное состояние, а память агента появляется как часть внешней системы. Теперь нужно научиться говорить о памяти точнее.

Фраза "агенту нужна память" слишком широкая. Одной системе нужно помнить последние реплики в диалоге. Другой - устойчивые факты о пользователе. Третьей - историю прошлых действий. Четвертой - правила работы с инструментами. Пятая должна координировать несколько агентов через общее состояние.

Если все это называть одним словом memory, архитектура быстро становится мутной. Непонятно, что хранить, где хранить, как долго, как извлекать, как обновлять и какие ошибки ждать. Когнитивная модель помогает разложить память на типы и увидеть, что у каждого типа своя роль в поведении агента.

Это не лекция по нейронауке. Мы используем аналогию с человеческой памятью как инженерную карту: она не обязана быть биологически точной, но помогает проектировать системы.

Основная идея

Разные виды памяти имеют разное время жизни, структуру, способ поиска и роль в поведении агента.

Working memory нужна для текущего фокуса внимания: что модель видит прямо сейчас. Short-term или session memory удерживает нить текущего взаимодействия. Long-term memory хранит более устойчивые сведения между сессиями. Внутри долгосрочной памяти полезно различать события, факты, навыки, выводы и общий контекст нескольких агентов.

Такое разделение помогает не только в терминологии. Оно влияет на архитектуру: что лежит в prompt, что в session state, что в базе фактов, что в event log, что в policy files, что в vector index, а что вообще не стоит сохранять.

Главный практический вывод: память агента - это не единое хранилище, а набор слоев с разной скоростью, структурой и назначением. Хороший memory layer умеет сочетать эти слои и доставать из каждого ровно то, что нужно текущей задаче.

Ключевые термины

Почему аналогия с человеком полезна

Человеческая память не выглядит как одна таблица. Мы можем держать в голове текущую фразу, помнить вчерашний разговор, знать столицу страны, уметь ездить на велосипеде и делать выводы из прошлой ошибки. Эти способности похожи, но устроены и используются по-разному.

Для AI-агентов это различие тоже важно. Когда агент пишет код, ему одновременно нужны:

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

Все эти сведения влияют на поведение, но они не должны жить в одном месте и доставаться одним способом. Текущий результат команды можно держать в working memory. Правила проекта лучше хранить как procedural memory. Ошибку прошлой попытки можно сохранить как episodic memory. Устойчивый факт о проекте относится к semantic memory.

Аналогия с человеком дает язык для таких различий. Она помогает спросить: это фокус внимания, эпизод, факт, навык, урок или общий контекст команды?

Где аналогия ограничена

Когнитивная модель полезна, пока мы помним, что агент не является человеком.

LLM не переживает события и не запоминает их сама. Система должна явно записать событие, выбрать представление, присвоить метаданные, сохранить его в хранилище и потом извлечь.

Человеческое воспоминание может быть ассоциативным, неполным и эмоционально окрашенным. Память агента должна быть проектируемой: со scope, source, timestamp, confidence, permissions, retention и механизмами удаления.

Человек часто забывает естественно. Агентская система без политики забывания может копить бесконечный шум, устаревшие факты и приватные данные. Поэтому forgetting в агенте - это не слабость, а архитектурная функция.

Наконец, человеческие термины не должны маскировать инженерные решения. Если мы говорим "semantic memory", нужно понимать, как она представлена: таблица фактов, документы, embeddings, graph, key-value records или комбинация. Если говорим "procedural memory", нужно понимать, где живут инструкции: system prompt, policy files, workflows, skill library или код orchestration layer.

Карта типов памяти

Ниже - обзорная таблица. В следующих модулях каждый тип будет разобран отдельно, а пока важно увидеть общую карту.

Working memory: текущий фокус внимания

Working memory - это то, что агент прямо сейчас держит "перед глазами". В LLM-системах это прежде всего содержимое context window: системные инструкции, запрос пользователя, недавняя история, результаты инструментов, активный план, выбранные memory records.

Это самая быстрая и самая ограниченная память. Она влияет на ближайший ответ, но не гарантирует сохранение после завершения шага. Если факт важен для будущего, его нужно вынести из working memory в более устойчивый слой.

Пример:

Текущая цель: написать лекцию 1.3.
Ограничение: курс на русском, conceptual 101, без низкоуровневой реализации.
Контекст: лекции 1.1 и 1.2 уже написаны.
Следующий шаг: добавить таблицу типов памяти и переход к Module 02.

Это рабочий контекст текущей задачи. Он не обязан становиться долгосрочной памятью целиком.

Short-term memory: текущая сессия

Short-term memory удерживает непрерывность внутри ограниченного взаимодействия. Это может быть история текущего диалога, summary длинной беседы, session variables, выбранные настройки или состояние workflow.

Она нужна, чтобы агент не терял нить: какие вопросы уже обсуждались, какие варианты отвергнуты, какой формат ответа выбран, какой шаг выполняется сейчас.

Типичные механизмы:

• sliding window: хранить последние N сообщений;
• rolling summary: сжимать старую часть диалога в краткое резюме;
• session state: хранить временные параметры задачи;
• TTL: автоматически очищать состояние после завершения сессии или периода неактивности.

Short-term memory не должна автоматически становиться user profile. Если пользователь сказал "сегодня отвечай максимально кратко", это может быть сессионной настройкой, а не постоянным предпочтением.

Long-term memory: устойчивый слой

Long-term memory хранит сведения, которые должны переживать одну сессию. Это не один конкретный тип данных, а общий класс устойчивой памяти. В него могут входить semantic, episodic, procedural и reflection records.

Long-term memory полезна, когда агент должен:

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

Но долгосрочная память требует сильной дисциплины. Чем дольше живет запись, тем важнее source, timestamp, confidence, scope и механизм обновления. Старый факт без даты и источника может навредить сильнее, чем отсутствие памяти.

Episodic memory: память событий

Episodic memory отвечает на вопрос: "что произошло?"

Она хранит события во времени: пользователь попросил изменить формат, агент вызвал инструмент, команда завершилась ошибкой, документ был обновлен, решение было принято, проверка прошла успешно.

Типичная запись эпизода содержит:

• timestamp;
• actor: пользователь, агент, инструмент, внешний сервис;
• observation или action;
• context: в какой задаче это произошло;
• result: чем закончилось;
• importance: стоит ли использовать это в будущем.

Episodic memory особенно полезна для debugging, auditability, восстановления контекста и обучения на прошлых попытках. Например, coding agent может помнить: "прошлый запуск тестов упал из-за отсутствия локальной базы". В следующий раз это событие помогает выбрать правильный порядок действий.

Semantic memory: память фактов

Semantic memory отвечает на вопрос: "что известно?"

Она хранит устойчивые факты, сущности и отношения: предпочтения пользователя, свойства проекта, правила домена, структуру организации, связи между людьми, сервисами, файлами и задачами.

Примеры:

• "Пользователь предпочитает короткие финальные ответы."
• "Курс написан на русском языке."
• "Этот репозиторий содержит только Markdown-документацию."
• "Module 02 посвящен таксономии памяти AI-агента."

Semantic memory часто требует обновления. Пользователь может изменить предпочтение. Проект может сменить стек. Организация может поменять политику. Поэтому факт должен иметь источник, дату, область применимости и уровень уверенности.

Важно отличать semantic memory от RAG по документам. Документ может быть источником факта, но semantic memory обычно хранит уже выделенную, нормализованную и применимую запись.

Procedural memory: память способов действия

Procedural memory отвечает на вопрос: "как действовать?"

Это инструкции, правила, workflows, навыки, политики и повторяемые процедуры. Для агента она часто важнее, чем кажется: именно процедурная память определяет, как запускать проверки, когда спрашивать разрешение, как оформлять результат, какие инструменты использовать и какие действия запрещены.

Примеры:

• "Перед изменением структуры курса обновить guide/content_plan.md."
• "Не перезаписывать пользовательские черновики в intro/."
• "Для лекций использовать Markdown, короткие разделы и вопросы самопроверки."
• "При работе с кодом сначала читать существующие паттерны проекта."

Procedural memory может жить в system prompts, AGENTS.md, policy files, playbooks, skill libraries, workflow definitions или коде агента. Она должна быть управляемой, потому что ошибка в процедурной памяти закрепляет неправильное поведение.

Reflection memory: уроки из опыта

Reflection memory хранит выводы агента о собственных действиях. Она отвечает на вопрос: "что мы поняли из прошлого опыта?"

Это не то же самое, что chain-of-thought. В memory layer не нужно сохранять скрытый ход рассуждений модели. Полезная reflection memory - это короткий, проверяемый и применимый вывод:

В задачах на расширение лекций сначала читать соседние уроки,
чтобы не дублировать материал и сохранить плавный переход.

Reflection полезна после ошибок, сложных задач и повторяемых workflows. Но она опасна, если сохранять слишком много самоуверенных выводов. Неверная reflection может стать постоянной плохой привычкой агента.

Хорошее правило: reflection должна быть короткой, привязанной к источнику, ограниченной по scope и пересматриваемой.

Shared memory: коллективный контекст

Shared memory нужна, когда в системе участвует несколько агентов, ролей или процессов. Один агент может исследовать источники, другой писать текст, третий проверять риски, четвертый управлять задачами.

Без shared memory агенты начинают дублировать работу или противоречить друг другу. С общим контекстом они могут координироваться: видеть текущий статус, передавать выводы, фиксировать решения и отслеживать открытые вопросы.

Типичный паттерн - blackboard: общее пространство, куда агенты записывают наблюдения, гипотезы, результаты и статусы.

Shared memory требует особенно строгих правил: кто может писать, кто может читать, как разрешаются конфликты, какие записи считаются подтвержденными и как не смешивать private memory одного агента с общей памятью команды.

Как типы памяти работают вместе

В реальном агенте типы памяти не существуют изолированно. Они образуют поток.

Например, пользователь в текущем диалоге сообщает новое ограничение проекта. Сначала оно попадает в working memory. Если ограничение важно на время текущей задачи, оно попадает в session memory. Если оно должно сохраняться дальше, система может записать его как semantic memory проекта. Если агент ошибся, проигнорировав ограничение, результат может стать episodic memory, а короткий вывод о том, как избегать ошибки, - reflection memory.

Procedural memory при этом задает правила: когда записывать факт, как проверять scope, нужно ли спрашивать подтверждение и как потом извлекать запись.

Мини-кейс: один факт в разных слоях

Пользователь говорит агенту:

В этом проекте все лекции должны быть на русском, но термины вроде retrieval и memory layer оставляй на английском.

Эта фраза может пройти через несколько уровней.

Одна реплика не обязана записываться во все слои. Но такой разбор показывает, почему "память" - не одно действие save(text). Система должна решить, какой смысл извлечь, в каком scope сохранить и как использовать позже.

Типичные ошибки и ограничения

Ошибка 1: считать когнитивные типы памяти физическими базами данных.

Episodic memory не обязательно отдельная база, а semantic memory не обязательно graph. Это логические роли. Физическое хранилище выбирается позже.

Ошибка 2: смешивать session memory и long-term memory.

Временное указание пользователя не всегда является постоянным предпочтением. Если все сессионные фразы сохранять навсегда, агент станет навязчивым и неточным.

Ошибка 3: превращать reflection в склад самоуверенных выводов.

Reflection полезна, когда вывод проверяемый и применимый. Если сохранять слишком общие фразы вроде "всегда сначала делай X", агент может закрепить плохую стратегию.

Ошибка 4: не хранить provenance.

Память без источника трудно обновлять и оспаривать. Для долгосрочных фактов важно знать, откуда они взялись и когда были записаны.

Ошибка 5: забыть про shared memory в multi-agent системах.

Если несколько агентов работают над одной задачей без общего состояния, они будут повторять шаги, терять решения и конфликтовать в выводах.

Краткое резюме

Когнитивная модель памяти - это инженерная карта, а не биологическая теория. Она помогает разделить разные роли памяти в агентской системе.

Working memory держит текущий фокус. Short-term memory удерживает сессию. Long-term memory сохраняет сведения между сессиями. Внутри нее полезно различать episodic, semantic, procedural и reflection memory. Для multi-agent систем добавляется shared memory.

Такое разделение помогает проектировать memory layer: выбирать представления, scopes, lifecycle, retrieval-стратегии и политики обновления. Вместо вопроса "как добавить память?" появляется более точный вопрос: "какой тип памяти нужен для этого поведения?"

Вопросы для самопроверки

1. Чем working memory отличается от short-term memory?
2. Почему semantic memory и episodic memory лучше не смешивать?
3. Какие примеры относятся к procedural memory, а не к фактам?
4. Почему reflection memory не должна быть сохраненным chain-of-thought?
5. Когда системе нужна shared memory, а когда достаточно памяти одного агента?

Что дальше

На этом Module 01 завершает фундамент: LLM не имеет встроенной долговременной памяти, агентская память живет в системной петле, а разные виды памяти выполняют разные роли.

В Module 02 мы разберем эту таксономию подробно. Начнем с Working Memory: что именно попадает в текущее окно внимания агента, как собирается context и почему даже рабочая память требует аккуратного дизайна.