Цель лекции
Объяснить дизайн памяти для корпоративного агента, работающего с документами, политиками и внутренними системами.
Ожидаемый результат
Читатель понимает enterprise-требования к памяти и почему они меняют архитектуру: retrieval должен быть permission-aware, память должна уважать tenant isolation, а действия агента должны оставлять audit trail.
Зачем это нужно
Enterprise knowledge agent отвечает на вопросы сотрудников, менеджеров, support teams, sales teams или аналитиков, используя корпоративный контекст:
- документы;
- политики;
- CRM;
- тикеты;
- почту;
- базы знаний;
- project docs;
- meeting notes;
- business glossary;
- внутренние процессы.
Здесь качество ответа важно, но недостаточно.
Агент не должен просто "найти полезный документ". Он должен найти документ, который этому пользователю разрешено видеть, который актуален, относится к правильной организации или tenant, и может быть процитирован в audit trail.
Основная идея
Enterprise memory должна быть permission-aware: качество ответа важно, но контроль доступа, аудит и изоляция данных обязательны.
Для enterprise-сценария память проектируется вокруг трех ограничений:
- access control: кому что можно читать;
- provenance: откуда взят факт;
- lifecycle: как обновлять, архивировать, удалять и проверять данные.
Если memory layer обходит корпоративные права доступа, она становится не ускорителем, а новым каналом утечки.
Ключевые термины
| Термин | Короткое определение |
|---|---|
Enterprise knowledge agent |
Агент, который отвечает и действует на основе корпоративных источников знаний. |
Permission-aware retrieval |
Retrieval, который учитывает права пользователя, агента, tenant, document и source. |
Tenant isolation |
Изоляция данных разных организаций, клиентов или рабочих пространств. |
Audit log |
Журнал того, какие источники использовались, кем, когда и почему. |
Business glossary |
Согласованный словарь корпоративных терминов и сущностей. |
Graph memory |
Память сущностей и связей: люди, команды, документы, процессы, клиенты, системы. |
Access violation |
Попытка прочитать, вывести или использовать недоступные данные. |
Stale document |
Документ, который устарел, но все еще может быть найден retrieval. |
Архитектура permission-aware retrieval
Ключевое отличие от обычного RAG: фильтрация прав не является последним cosmetic step. Она должна работать до retrieval, во время retrieval и перед context assembly.
Какие данные помнить
Enterprise agent может использовать разные виды памяти.
| Вид памяти | Примеры |
|---|---|
| Semantic memory | Org policies, business glossary, product facts. |
| World/RAG memory | Docs, knowledge base, ticket history, CRM records. |
| Episodic memory | Past support cases, decisions, incidents, task history. |
| Procedural memory | Approval workflow, escalation path, compliance playbooks. |
| Graph memory | People, teams, customers, systems, processes and relationships. |
| User/team context | Role, team membership, allowed projects, current workspace. |
Важно: многие records не должны копироваться в новый global memory store. Часто лучше хранить ссылки на authorized sources and metadata, а не дублировать чувствительные данные.
Org policies и business glossary
Корпоративные политики и glossary нужны, чтобы агент говорил на языке компании.
Примеры glossary records:
ARR = Annual Recurring Revenue
Enterprise plan = customers with signed enterprise agreement
Priority 1 incident = customer-facing outage with active business impact
Примеры policy records:
Refund approvals above $10k require finance review.
Security incidents must be escalated to security on-call.
Customer data may not be copied into public workspaces.
Но policy memory должна быть:
- source-linked;
- versioned;
- dated;
- permission-aware;
- conflict-aware.
Если старая политика и новая политика конфликтуют, агент должен показывать uncertainty or ask for confirmation, а не уверенно выбрать случайную.
Интеграции с источниками
Enterprise memory редко живет в одном хранилище.
Источники:
- document repositories;
- wiki;
- ticketing systems;
- CRM;
- email;
- chat;
- databases;
- data catalogs;
- policy systems;
- identity providers.
Для каждого source нужны:
- ingestion rules;
- metadata mapping;
- permissions mapping;
- freshness strategy;
- deletion/retention behavior;
- source attribution;
- audit integration.
Пример metadata:
source: support_ticket
tenant_id: acme_corp
visibility: support_team_only
created_at: 2026-03-10
updated_at: 2026-04-01
owner_team: support
retention_policy: 24_months
Без metadata enterprise retrieval неуправляем.
Tenant isolation
Tenant isolation означает, что данные одного customer, workspace или organization не смешиваются с другими.
Пример опасной ошибки:
Customer A asks:
"Есть ли обходной путь для export issue?"
Retrieval returns:
- Customer B private ticket with workaround
- Customer B internal contract note
Даже если workaround технически полезен, такой retrieval недопустим.
Tenant isolation должна работать:
- в primary store;
- в vector index;
- в search index;
- в cache;
- в summaries;
- в logs;
- в evaluation datasets;
- в debug tools.
Один забытый cache key может сломать всю security model.
Audit logs
Enterprise agent должен оставлять след:
- кто спросил;
- какой агент отвечал;
- какие sources были retrieved;
- какие filters применены;
- какие records были injected into context;
- какие claims попали в ответ;
- какие actions выполнены;
- какие policy blocks сработали.
Audit log помогает:
- расследовать incidents;
- доказывать compliance;
- отлаживать retrieval;
- проверять quality;
- объяснять решения;
- находить stale sources.
Важно: audit log сам может содержать sensitive data. Его тоже нужно защищать, фильтровать и хранить по retention policy.
Graph memory в enterprise
Enterprise knowledge часто имеет форму графа.
Примеры связей:
Employee -> member_of -> Team
Team -> owns -> Service
Service -> used_by -> Customer
Customer -> has_contract -> Plan
Policy -> applies_to -> Region
Incident -> affected -> Service
Graph memory помогает отвечать на вопросы:
- кто владелец процесса;
- какие команды связаны с системой;
- какие customers affected by incident;
- какие политики применимы к региону;
- почему документ относится к этому workflow.
Но graph traversal тоже должен быть permission-aware. Пользователь может иметь доступ к одному узлу, но не к соседним.
Пример корпоративного вопроса
Вопрос:
"Можем ли мы дать клиенту ACME расширенный экспорт данных?"
Агенту нужны:
- CRM: план клиента;
- policy docs: правила export;
- contract notes: особые условия;
- support tickets: текущая проблема;
- user role: имеет ли спрашивающий доступ к contract notes;
- glossary: что значит "расширенный экспорт".
Good behavior:
Agent retrieves only sources available to this user.
Agent cites current policy.
Agent notes that contract terms require legal review if user lacks access.
Agent does not reveal hidden contract clauses.
Agent logs source usage.
Bad behavior:
Agent summarizes restricted contract note in answer.
Agent uses stale export policy from old docs.
Agent mixes ACME with another customer.
Риски
| Риск | Как проявляется | Защита |
|---|---|---|
| Cross-tenant leakage | Данные одного клиента попадают другому. | Tenant filters everywhere, index isolation, tests. |
| Permission bypass | Агент видит больше, чем пользователь. | Identity-bound retrieval, source-level ACLs. |
| Stale documents | Старые политики используются как актуальные. | Freshness metadata, versioning, source priority. |
| Compliance gaps | Нельзя объяснить, откуда ответ. | Audit logs, citations, retention policy. |
| Sensitive summaries | Summary содержит то, что нельзя видеть всем. | Permissioned summaries, derived-data policy. |
| Graph leakage | Relation reveals hidden information. | Permission-aware graph traversal. |
Метрики
Enterprise metrics должны включать качество и безопасность.
| Метрика | Что показывает |
|---|---|
| Grounded answer rate | Ответы опираются на разрешенные sources. |
| Retrieval precision/recall | Находятся правильные документы. |
| Access violation count | Попытки доступа к forbidden records. |
| Cross-tenant leakage count | Критический security indicator. |
| Stale source usage | Как часто агент использует устаревшие документы. |
| Citation coverage | Есть ли source references для claims. |
| Audit completeness | Можно ли восстановить ход ответа. |
| User correction rate | Как часто сотрудники исправляют контекст. |
Нулевые access violations важнее небольшого прироста recall.
Минимальный enterprise checklist
Перед запуском enterprise memory нужно проверить:
- identity flows;
- source permissions;
- tenant isolation;
- metadata completeness;
- deletion and retention;
- audit logs;
- stale document handling;
- citation behavior;
- adversarial documents;
- admin visibility;
- human escalation paths.
Если хотя бы access control не определен, рано говорить о production memory.
Типичные ошибки
Ошибка 1: индексировать все документы в один общий vector store.
Так проще технически, но опасно без строгой permission model.
Ошибка 2: применять permissions только после retrieval.
Некоторые системы могут leak через candidate logs, summaries или reranking.
Ошибка 3: не учитывать derived data.
Summary или embedding тоже могут наследовать ограничения исходного документа.
Ошибка 4: считать citations достаточной защитой.
Citations помогают grounding, но не заменяют access control.
Ошибка 5: не тестировать stale policies.
Enterprise docs часто конфликтуют и устаревают.
Ошибка 6: не логировать memory decisions.
Без audit невозможно объяснить, почему агент дал ответ.
Краткое резюме
Enterprise knowledge agent требует memory layer, где retrieval, permissions, freshness, provenance, audit и tenant isolation спроектированы вместе. Graph memory может помочь с отношениями между людьми, документами, процессами и системами, но тоже должна уважать доступы.
Главная мысль: в enterprise memory безопасность и управляемость не являются дополнениями к quality; они часть определения quality.
Вопросы для самопроверки
- Почему permission-aware retrieval должен работать до context assembly?
- Какие слои системы должны поддерживать tenant isolation?
- Чем audit log помогает при memory failures?
- Когда enterprise agent выигрывает от graph memory?
- Почему stale document может быть таким же опасным, как нерелевантный документ?
Что дальше
В следующей лекции мы рассмотрим multi-agent system: там память нужна не только для знания, но и для координации нескольких агентов, разделения ролей, shared workspace и conflict resolution.