Урок 2.7. World Memory и RAG: внешние знания агента

Цель лекции

Показать роль внешних знаний: документов, баз знаний, репозиториев, тикетов, CRM и других источников.

Ожидаемый результат

Читатель понимает место RAG внутри общей архитектуры памяти, видит разницу между knowledge base и personal memory, умеет объяснить роль freshness, grounding, source attribution и retrieval permissions.

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

До этого момента мы говорили в основном о памяти, которая возникает внутри жизни агента:

• episodic memory хранит события и опыт;
• semantic memory хранит факты, сущности и предпочтения;
• procedural memory хранит навыки, политики и workflows;
• reflection memory хранит lessons learned.

Но агент работает не в пустоте. Ему нужны внешние знания: документация продукта, кодовая база, внутренние wiki, тикеты, CRM, базы данных, файлы пользователя, веб-страницы, спецификации, research papers, policy documents.

Например:

• coding agent должен читать репозиторий, README, changelog и issues;
• support agent должен видеть справочный центр, CRM и историю обращений;
• enterprise agent должен искать по внутренней wiki и документам команды;
• research agent должен опираться на источники, а не только на знания модели;
• personal assistant должен находить файлы, письма, календарные события и заметки.

Этот слой часто называют RAG: retrieval-augmented generation. Агент сначала ищет релевантные внешние фрагменты, затем добавляет их в контекст модели и генерирует grounded answer.

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

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

World memory - это слой внешних знаний агента: документы, базы знаний, репозитории, сайты, тикеты, CRM, datasets, API-справочники и другие источники, которые существуют независимо от текущей сессии агента.

RAG - один из главных способов подключить world memory к LLM. В простейшей форме pipeline выглядит так:

User question -> retrieval -> relevant chunks -> context assembly -> LLM answer

В агентской системе этот pipeline становится частью более широкой memory architecture. Агенту нужно не просто найти похожие chunks, а понять:

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

World memory отвечает на вопрос: "что можно узнать из внешних источников?"

Personal memory отвечает на вопрос: "что агент помнит о пользователе, проекте, опыте и своих действиях?"

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

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

World memory не равна personal memory

Главная ошибка - считать любую внешнюю базу знаний памятью агента в полном смысле.

Документация продукта не является памятью о пользователе. CRM не является reflection memory агента. Репозиторий не является procedural memory, хотя в нем могут быть procedural documents. Vector database с chunks не знает, какие уроки агент вынес из прошлой ошибки.

Сравнение:

World memory может быть частью memory layer, но не заменяет его остальные слои.

Какие источники входят в world memory

World memory обычно собирается из нескольких классов источников.

Документация и knowledge base

Это самый привычный источник для RAG:

• product docs;
• help center;
• internal wiki;
• onboarding guides;
• runbooks;
• policy documents;
• FAQ;
• API reference;
• design docs;
• architecture decision records.

Такие источники часто хорошо подходят для chunking и semantic retrieval. Но им нужны metadata: версия, дата обновления, владелец, продуктовая область, доступы и canonical status.

Кодовая база

Для coding agents world memory включает:

• source code;
• tests;
• README;
• package manifests;
• comments;
• generated docs;
• changelog;
• issues и pull requests;
• CI logs;
• architecture docs.

Кодовая база требует особого retrieval. Для кода часто важны exact names, paths, symbols, imports и call graph. Одного vector search может быть мало: поиск по ключевым словам, AST, dependency graph и file path metadata часто дают более точный результат.

Тикеты и project tools

Таск-трекеры и planning tools хранят операционный контекст:

• requirements;
• acceptance criteria;
• bug reports;
• user stories;
• sprint goals;
• decisions в комментариях;
• links на design docs;
• статусы задач.

Этот источник помогает агенту понять намерение проекта. Но тикеты часто шумные: в них есть устаревшие обсуждения, непроверенные гипотезы и временные договоренности.

CRM и support systems

Для support и sales agents world memory может включать:

• customer profile;
• tickets;
• subscription plan;
• contract terms;
• support history;
• known incidents;
• account notes;
• escalation records.

Здесь особенно важны permissions, privacy и scope. Агент не должен извлекать или показывать данные клиента пользователю, который не имеет доступа к этому account.

Веб и внешние источники

Веб полезен для текущих сведений:

• официальная документация;
• release notes;
• стандарты;
• публичные справочники;
• research papers;
• новости;
• pricing pages;
• regulatory pages.

Но веб требует более строгой оценки источников: authority, freshness, date, version, domain, citation. Для текущих вопросов нельзя полагаться только на знания модели.

Базовый RAG pipeline

На концептуальном уровне RAG состоит из двух частей: ingestion и query-time retrieval.

Ingestion готовит источники к поиску. Query-time retrieval выбирает фрагменты под конкретную задачу.

Для memory architecture важно, что RAG pipeline не заканчивается на vector search. После поиска нужны filtering, reranking, permission checks, source attribution и context assembly.

Chunking

Chunking - это разбиение документов на фрагменты, которые можно индексировать и извлекать.

Слишком крупные chunks плохо подходят для context assembly: они занимают много токенов и содержат лишний текст. Слишком мелкие chunks теряют смысл: модель видит отдельный абзац без заголовка, версии, примера или ограничения.

Хороший chunk обычно сохраняет:

• локальный смысл;
• заголовок или path;
• источник;
• структуру раздела;
• соседний контекст;
• metadata;
• дату или версию, если она важна.

Примеры:

Chunking не является просто технической оптимизацией. Он определяет, что агент сможет вспомнить и как именно это попадет в context window.

Metadata

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

Полезные metadata:

• source type: docs, code, ticket, CRM, web;
• path или URL;
• title и heading;
• author или owner;
• created_at и updated_at;
• version;
• product area;
• project или workspace;
• customer или account scope;
• language;
• permissions;
• canonical или draft status;
• confidence или source priority.

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

Source attribution и grounding

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

Source attribution отвечает на вопрос: откуда взято утверждение?

Для многих сценариев это критично:

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

Пример слабого ответа:

Этот API поддерживает batch updates.

Пример grounded ответа:

Согласно разделу "Batch updates" в API reference версии 2026-07,
endpoint поддерживает batch updates до 100 объектов за запрос.

В реальной системе grounded response может включать ссылку, title, path, timestamp, version или цитату короткого фрагмента. Даже если пользователь не видит все metadata, memory layer должен хранить источник.

Freshness

World memory часто устаревает быстрее, чем кажется.

Примеры:

• API изменил параметр;
• price page обновилась;
• legal policy получила новую версию;
• issue был закрыт;
• customer plan изменился;
• dependency получила security update;
• internal wiki осталась после старой архитектуры;
• README не соответствует коду.

Freshness - это оценка актуальности источника для конкретной задачи.

Не все источники требуют одинаковой свежести:

Свежесть не всегда означает "самый новый документ". Иногда важна версия, действовавшая в момент события. Поэтому metadata времени должна быть частью retrieval.

Retrieval permissions

World memory почти всегда имеет права доступа.

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

Примеры:

• сотрудник видит только документы своей команды;
• support agent видит только account, с которым работает;
• подрядчик не видит финансовые документы;
• пользователь видит только свои файлы;
• internal policy нельзя цитировать внешнему клиенту;
• один агент в multi-agent системе не должен видеть private memory другого агента.

Retrieval permissions должны применяться до инъекции данных в context window. Если запрещенный fragment уже попал в prompt, утечка почти произошла, даже если модель не процитировала его в ответе.

Надежный pipeline выглядит так:

query -> permission filter -> retrieval -> reranking -> context assembly

или:

query -> retrieval within allowed indexes -> reranking -> context assembly

Главная идея: права доступа являются частью memory architecture, а не только UI-фильтром после генерации.

RAG внутри memory architecture

RAG лучше понимать как retrieval-компонент, который подключает внешние источники к working memory.

Схема показывает две важные вещи.

Во-первых, personal memory и world memory - разные источники context assembly. Они могут использовать похожие search infrastructure, но отвечают за разные типы данных.

Во-вторых, RAG обычно не пишет обратно в world memory. Документы обновляются через свои системы: docs repo, CRM, ticket tracker, database, website. Агент может предложить изменение, но не должен считать retrieved chunk своей внутренней памятью без обработки.

Knowledge base vs memory layer

Knowledge base обычно отвечает за хранение и поиск внешней информации. Memory layer отвечает за управление состоянием агента.

Иногда эти системы физически используют одно и то же хранилище: SQL, object storage, vector database, search engine. Но логически это разные слои.

Конфликты между RAG и памятью агента

В реальной системе world memory и personal memory могут конфликтовать.

Примеры:

Semantic memory:
- User prefers concise answers.

Retrieved docs:
- The policy explanation is long and legally detailed.

Здесь нет фактического конфликта. Агент должен ответить кратко, но не исказить policy.

Другой пример:

Project memory:
- The project uses Jest.

Current package.json:
- The project uses Vitest.

Здесь RAG по текущей кодовой базе может показать, что semantic memory устарела. Агент должен использовать текущий источник и, возможно, обновить project fact.

Еще пример:

User profile:
- User works on account A.

Retrieved CRM:
- Query returns account B because names are similar.

Здесь retrieval ошибся по scope. Агент должен проверить permissions и entity match, а не смешивать данные разных клиентов.

Конфликт не всегда решается правилом "документ важнее памяти" или "память важнее документа". Нужны source priority, freshness, scope и user intent.

Мини-кейс: документация проекта как world memory

Представим writing agent, который помогает писать курс.

Внутренняя память агента:

Semantic memory:
- Course is written primarily in Russian.
- guide/content_plan.md is source of truth for structure.

Procedural memory:
- When writing a lesson, read the target plan and adjacent lesson.

World memory:

guide/content_plan.md
modules/writing_todo.md
modules/module_02/lesson_02_06_reflection_memory.md
modules/module_02/lesson_02_08_shared_memory.md

Когда пользователь просит написать лекцию 2.7, агенту нужно:

1. Извлечь procedural memory: как писать лекцию.
2. Извлечь semantic memory: курс русский, broad and conceptual.
3. Прочитать world memory: план урока, content plan, соседние файлы.
4. Собрать context window из релевантных фрагментов.
5. Написать лекцию.

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

Мини-кейс: support agent и CRM

Support agent получает запрос:

"Почему у нас пропал доступ к функции export?"

World memory может дать:

• docs о функции export;
• CRM account plan;
• feature entitlement table;
• recent incident report;
• support tickets клиента;
• release notes.

Personal или agent memory может дать:

• пользователь уже спрашивал об этом вчера;
• агент ранее эскалировал похожий случай;
• команда просила не обещать SLA без проверки contract;
• reflection: в прошлый раз ошибка была из-за устаревшего entitlement cache.

Надежный ответ требует обеих сторон. RAG найдет документы и CRM facts. Memory layer удержит историю, policies и lessons learned.

При этом permissions критичны: агент должен искать только по account пользователя и не подтягивать данные другого клиента с похожим названием.

Когда RAG не заменяет memory layer

RAG не заменяет memory layer, если системе нужно:

• помнить предпочтения пользователя;
• сохранять прошлые действия агента;
• учитывать feedback;
• обновлять project facts;
• хранить policies поведения;
• применять workflows;
• анализировать прошлые ошибки;
• отличать session state от long-term memory;
• забывать или удалять персональные данные;
• управлять scope между user, project, team и organization;
• объяснять, почему агент выбрал конкретное действие.

RAG отвечает за доступ к знаниям. Memory layer отвечает за управляемую непрерывность агента.

Эта граница особенно важна для продуктового дизайна. Фраза "у нас есть memory, потому что мы подключили vector search по docs" обычно означает только RAG. Это полезно, но это не полноценная agent memory.

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

Ошибка 1: считать vector database всей памятью.

Vector database может быть частью RAG, но память агента также включает events, facts, preferences, procedures, reflection, scopes, update rules и forgetting.

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

Если агент не знает, откуда взят фрагмент, он не может проверить freshness, authority и permissions.

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

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

Ошибка 4: смешивать knowledge base и user profile.

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

Ошибка 5: применять permissions после генерации.

Доступ нужно проверять до попадания данных в context window.

Ошибка 6: использовать только semantic similarity.

Для кода, тикетов, API и CRM часто нужны keyword search, metadata filters, entity matching и temporal constraints.

Ошибка 7: не обрабатывать конфликты.

Если retrieved source противоречит сохраненной памяти, агент должен учитывать source, freshness, scope и confidence, а не слепо выбирать первый результат.

Ошибка 8: перегружать context window chunks.

Много внешнего текста не равно хороший контекст. Нерелевантные chunks ухудшают reasoning и могут вытеснить важные инструкции.

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

World memory - это слой внешних знаний агента: документы, код, wiki, CRM, тикеты, веб-источники и другие системы, которые существуют отдельно от текущей сессии агента.

RAG дает механизм доступа к world memory: найти релевантные фрагменты, добавить их в context assembly и сгенерировать grounded answer. Но RAG сам по себе не заменяет memory layer, потому что не управляет пользовательской памятью, событиями, процедурами, reflection, scope, forgetting и политиками поведения.

Хорошая архитектура соединяет RAG с memory layer: учитывает source attribution, freshness, metadata, permissions, reranking, conflicts и ограничения context window.

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

1. Чем world memory отличается от personal memory агента?
2. Почему RAG не равен полноценному memory layer?
3. Зачем нужны metadata и source attribution в RAG pipeline?
4. Почему freshness зависит от типа вопроса?
5. Почему permissions нужно применять до context assembly?

Что дальше

В следующей лекции мы разберем Shared Memory: память в multi-agent системах. После внешних знаний важно понять, как несколько агентов могут работать с общим состоянием, не смешивая private memory, team context, роли, права доступа и конфликтующие обновления.