Урок 2.4. Semantic Memory: факты, сущности и знания

Цель лекции

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

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

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

Пользователь несколько раз просил писать кратко. В проекте все лекции пишутся на русском. В репозитории нельзя добавлять зависимости без обсуждения. В компании слово "customer" означает платящего клиента, а "account" - организацию. Сервис Billing зависит от Identity. Документ guide/content_plan.md является источником структуры курса.

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

Если episodic memory - это журнал опыта, то semantic memory - это карта того, что агент считает известным.

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

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

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

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

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

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

Что считается фактом

Факт в semantic memory - это не любая фраза пользователя. Это утверждение, которое имеет смысл использовать за пределами текущего сообщения или сессии.

Примеры хороших фактов:

• "Пользователь предпочитает краткие финальные ответы."
• "Курс AI Agent Memory Guide 101 пишется на русском языке."
• "Репозиторий является документационным и не имеет build step."
• "В проекте структура лекций хранится в guide/content_plan.md."
• "В компании термин workspace означает изолированную рабочую область клиента."
• "Сервис Billing зависит от Identity для проверки пользователя."

Плохие кандидаты в semantic memory:

• "Пользователь сегодня торопится."
• "Агент только что прочитал файл."
• "Команда упала один раз с timeout."
• "Возможно, проблема в timezone."
• "Пользователь сказал 'ок'."

Эти сведения могут быть важны как session memory или episodic memory, но не обязательно как устойчивые факты.

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

Семантическая запись

Концептуально semantic memory record может выглядеть так:

id: fact_project_001
type: project_fact
subject: ai-agent-memory-guide
predicate: primary_language
object: Russian
scope:
  project: ai-agent-memory-guide
source:
  kind: user_instruction
  reference: conversation_2026_08_04
confidence: high
created_at: 2026-08-04T10:00:00+03:00
last_confirmed_at: 2026-08-04T10:00:00+03:00
staleness: low
status: active

Это не требование к схеме базы данных. Это mental model: факт должен быть не просто строкой, а утверждением с контекстом, источником и жизненным циклом.

В простых системах факт может храниться как JSON-документ или Markdown-запись. В более сложных - как entity record, graph edge, SQL row, vector-indexed memory record или комбинация.

Схема fact/entity memory

Semantic memory часто удобно представлять как сочетание фактов и сущностей.

Такая схема помогает увидеть, что semantic memory - это не только "плоский список заметок". Часто агенту важно знать связи: пользователь работает над проектом, проект содержит модуль, модуль посвящен теме, документ является источником структуры.

Не каждой системе нужен graph database. Но даже если данные хранятся в простой таблице, полезно думать в терминах subject -> relation -> object.

User profile

User profile - один из самых известных видов semantic memory. Он хранит устойчивые сведения о пользователе, которые помогают персонализировать поведение агента.

Типичные категории:

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

Пример:

User profile facts:
- User prefers Russian for course-writing tasks.
- User wants concise final summaries from the assistant.
- User often works with Markdown lecture files.
- User expects TODO files not to be updated unless explicitly requested.

User profile должен быть осторожным. Нельзя превращать каждую реплику в постоянную характеристику. Если пользователь сказал "сегодня отвечай кратко", это session memory. Если сказал "всегда отвечай кратко в финале", это кандидат в user profile.

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

Project memory

Project memory хранит устойчивые знания о конкретном проекте. Для coding agents, research agents и writing agents это один из самых полезных типов semantic memory.

Примеры project facts:

• "Проект документационный, без runtime application."
• "Новые лекции должны лежать в modules/."
• "guide/content_plan.md является source of truth для структуры."
• "Файлы лекций используют Markdown."
• "Курс broad and conceptual, без низкоуровневой реализации, если не попросили."
• "Lesson files имеют шаблон modules/module_XX/lesson_XX_YY_alias.md."

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

Хорошая project memory отвечает на вопросы:

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

Domain memory

Domain memory хранит знания предметной области: бизнес-термины, правила, классификации, ограничения, типовые процессы.

Примеры:

• В SaaS-продукте workspace - это изолированная среда организации.
• В финтехе settlement и authorization - разные этапы платежа.
• В курсе по AI agents retrieval означает процесс поиска релевантной информации для context assembly.
• В medical support нельзя давать диагноз без qualified professional review.

Domain memory отличается от project memory тем, что описывает не конкретный репозиторий или документ, а предметную область. Но scope все равно важен: один и тот же термин может означать разное в разных компаниях.

Для enterprise agents domain memory часто критична. Агент, который не понимает внутренние термины организации, может давать формально грамотные, но практически неверные ответы.

Entity memory

Entity memory хранит сведения о конкретных объектах и связях между ними.

Типичные сущности:

• люди;
• команды;
• компании;
• проекты;
• документы;
• репозитории;
• сервисы;
• API;
• тикеты;
• продукты;
• datasets.

Пример entity memory:

Entity: guide/content_plan.md
type: document
project: ai-agent-memory-guide
role: canonical structure source
related_entities:
- modules/todo.md
- modules/writing_todo.md
known_facts:
- defines high-level course plan
- should be updated before structural changes

Entity memory полезна, когда агенту нужно связывать факты. Не просто "есть документ", а "этот документ задает структуру курса", "этот модуль относится к таксономии памяти", "этот сервис зависит от другого сервиса".

Confidence и source

Semantic memory без источников быстро становится опасной. Агент может уверенно использовать факт, но не знать, откуда он взялся и можно ли ему доверять.

Source отвечает на вопрос: кто или что подтвердило факт?

Возможные источники:

• прямое утверждение пользователя;
• project instruction file;
• документация;
• tool result;
• повторяющийся episodic pattern;
• администраторская настройка;
• imported knowledge base;
• вывод модели, требующий проверки.

Confidence отвечает на вопрос: насколько надежна запись?

Система не обязана показывать confidence пользователю каждый раз. Но она должна учитывать его при retrieval, conflict resolution и обновлении памяти.

Staleness и устаревание

Факт может быть истинным сегодня и неверным завтра. Это особенно важно для проектов, организаций, продуктов и внешних сервисов.

Примеры устаревания:

• пользователь поменял предпочтение;
• проект перешел с JavaScript на TypeScript;
• компания изменила политику refund;
• API получил новую версию;
• документ был переименован;
• команда больше не использует старый workflow.

Semantic memory должна хранить признаки времени:

• created_at: когда факт появился;
• last_confirmed_at: когда он последний раз подтверждался;
• valid_from и valid_until, если применимо;
• staleness: оценка риска устаревания;
• source_version: версия документа, API или политики.

Не все факты устаревают одинаково. "Пользователь предпочитает русский язык" может жить долго, но все равно быть изменяемым. "Текущий CEO компании" быстро устаревает и требует проверки. "Файл называется content_plan.md" может устареть при реорганизации репозитория.

Contradiction detection и обновление фактов

Новая информация может противоречить старой памяти. Например:

Old fact:
- User prefers very detailed explanations.

New message:
- "Теперь давай всегда короче, без длинных объяснений."

Система не должна просто добавить второй факт рядом с первым без обработки. Иначе retrieval может вернуть оба, а модель получит конфликт.

Возможные стратегии:

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

Semantic memory и retrieval

Semantic memory становится полезной только тогда, когда агент извлекает нужные факты в нужный момент.

Retrieval по semantic memory может учитывать:

• текущую задачу;
• scope: user, project, team, organization;
• entity: о каком объекте идет речь;
• relation: какой тип связи нужен;
• recency и staleness;
• confidence;
• source priority;
• similarity по смыслу;
• keyword match;
• graph neighborhood.

Пример: пользователь просит "напиши следующую лекцию". Агенту не нужно извлекать все факты о пользователе. Ему нужны project facts о структуре курса, writing conventions, текущий модуль и переход от предыдущего урока.

Хороший retrieval не только находит похожий текст, но и отбирает факты, которые должны повлиять на текущий шаг.

Мини-кейс: user profile и project facts

Допустим, агент помогает писать курс.

Из разных сессий накопились эпизоды:

Episode 1:
- User asked to write lesson 1.1 in Russian.

Episode 2:
- User asked to write lesson 1.2 with Mermaid diagram and self-check questions.

Episode 3:
- User did not ask to update writing_todo after lecture generation.

Episode 4:
- Project instructions say guide/content_plan.md is source of truth for structure.

Из них можно выделить semantic memory:

User profile:
- User accepts Russian technical prose for this course.
- User prefers concise final reports after file edits.

Project memory:
- Course lectures should use Markdown.
- Full lectures should include examples, diagrams, summary, and self-check questions.
- guide/content_plan.md defines high-level course structure.
- Do not overwrite drafts in intro/.

Writing context:
- Module 02 is the taxonomy of agent memory.
- Lesson 2.4 should explain semantic memory as facts, entities, preferences, and domain knowledge.

Когда пользователь просит написать следующую лекцию, агент извлекает эти факты и собирает working memory. Но он не обязан показывать весь исторический журнал. Semantic memory дает компактное, обобщенное знание.

Когда не стоит сохранять semantic memory

Semantic memory должна быть полезной и безопасной. Сохранять факт не стоит, если:

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

Иногда лучше сохранить событие как episodic memory, а не обобщать его. Иногда лучше вообще ничего не сохранять. Память - это не жадное накопление, а управляемый выбор.

Типичные ошибки

Ошибка 1: сохранять единичное событие как постоянный факт.

"Пользователь сегодня попросил краткий ответ" не равно "пользователь всегда хочет краткие ответы".

Ошибка 2: не хранить source.

Факт без источника трудно проверять, обновлять и объяснять пользователю.

Ошибка 3: игнорировать staleness.

Проектные, продуктовые и организационные факты устаревают. Без дат и подтверждений агент будет использовать старые знания.

Ошибка 4: смешивать user, project и organization scopes.

Личное предпочтение пользователя не всегда является правилом проекта. Политика организации не всегда является предпочтением пользователя.

Ошибка 5: считать vector database всей semantic memory.

Embeddings помогают искать похожие записи, но semantic memory также требует структуры, source, confidence, staleness, scope и обновления.

Ошибка 6: не обрабатывать противоречия.

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

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

Semantic memory - это слой устойчивых знаний агента: факты, сущности, предпочтения, связи, project facts и domain rules.

Она отличается от episodic memory тем, что отвечает не "что произошло?", а "что известно?". Эпизоды могут быть источником semantic facts, но обобщение требует проверки, scope, source и confidence.

Хорошая semantic memory не только хранит факты, но и управляет их жизненным циклом: проверяет источники, учитывает staleness, обнаруживает противоречия, обновляет записи и извлекает только релевантное в working memory.

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

1. Чем semantic memory отличается от episodic memory?
2. Какие признаки помогают решить, что утверждение стоит сохранить как факт?
3. Почему для semantic memory важны source и confidence?
4. Что такое staleness, и какие факты особенно быстро устаревают?
5. Как система должна поступать, если новый факт противоречит старому?

Что дальше

В следующей лекции мы перейдем к Procedural Memory: памяти навыков, политик и способов действия. Там важно будет провести новую границу: semantic memory говорит, что известно, а procedural memory говорит, как агент должен действовать.