Пам'ять агента ШІ: як зберігати довгостроковий контекст відповідно до РОДО

Фірма, що впроваджує асистента ШІ для обслуговування клієнтів B2B, може мати 300-800 активних контрагентів в одній інстанції системи. Якщо довгострокова пам'ять не ізольована per-tenant, агент, який обслуговує клієнта з медичної галузі, може підтягувати контекст з розмов, проведених з клієнтом з фінансового сектору. Це не теоретичний сценарій: помилкова конфігурація фільтрації у векторній базі даних призводить до таких витоків на практиці, перш ніж хтось це помітить.

Кожен продуктивний агент працює щонайменше на трьох шарах пам'яті, які мають різні життєві цикли та вимоги.

Сесійна пам'ять – це контекст вікна поточної розмови (context window). Існує від першого повідомлення до завершення сесії. Не персистується, якщо явно не зберегти. Містить усю історію обміну в поточній сесії, системну інструкцію та завантажені фрагменти з RAG. Її розмір обмежений кількістю токенів, яку модель підтримує в одному вікні, зазвичай 8 000-128 000 токенів залежно від моделі.

Векторна пам'ять (довгострокова) – це персистовані ембедінги фрагментів історії розмов, документів клієнта та фактів, які агент має запам'ятовувати між сесіями. Зберігається у векторній базі даних (Qdrant, Weaviate, pgvector). Семантичний пошук при кожному новому запиті підтягує релевантні фрагменти з цього шару як контекст для відповіді, за зразком патерну RAG.

Профіль користувача / тенанта – це структуровані дані: переваги, ролі, історія справ, надані згоди, дати ретенції. Зберігається у реляційній базі даних (не векторній), оскільки потрібні точні запити, оновлення та каскадне видалення. Саме цей запис є доказом згоди та джерелом істини для права на забуття.

Найпоширеніша архітектурна помилка: векторна база даних без фільтрації за ідентифікатором тенанта. Безпечний патерн виглядає інакше.

Кожен фрагмент, що записується до векторної бази даних, отримує метадані tenant_id (та опціонально user_id). При кожному запиті пошук містить фільтр where: { tenant_id: { eq: current_tenant } } як обов'язкову умову, перш ніж буде обчислено косинусну подібність. Без цього фільтра модель ембедінгів може повернути фрагмент з абсолютно іншого контексту, якщо він семантично подібний.

Додаткові шари ізоляції, які варто впровадити:

Namespace per-tenant у векторній базі даних: Qdrant підтримує колекції або точки з фільтрами per-tenant. Зберігання даних різних клієнтів в окремих колекціях є сильнішою ізоляцією, ніж просте фільтрування метаданих, але коштує більше ресурсів при сотнях тенантів.

Токен сесії як межа контексту: кожна сесія отримує унікальний ідентифікатор. Фрагменти історії, що записуються до векторної пам'яті, містять session_id як метадані. Завдяки цьому можна видалити всю історію конкретної сесії без зміни решти даних тенанта.

Guardrails на виході: перш ніж агент поверне відповідь, шар guardrails перевіряє, чи відповідь не містить персональних даних (PII) іншого клієнта. Це страхувальна сітка, а не основна лінія захисту. Детальніше про архітектуру багатоетапних агентів у статті про багатоетапних агентів.

РОДО ст. 17 надає суб'єкту даних право вимагати видалення його даних. У контексті пам'яті агента це означає каскадну операцію щонайменше на чотирьох ресурсах.

Крок 1: Видалити профіль з реляційної бази даних. Зазвичай це проста операція DELETE WHERE user_id = X, але вимагає попереднього збору всіх ідентифікаторів, пов'язаних з цим користувачем.

Крок 2: Видалити ембедінги з векторної бази даних. Qdrant дозволяє видаляти точки за фільтром метаданих: DELETE WHERE user_id = X AND tenant_id = Y. Перш ніж це зробити, потрібно мати список point_id, пов'язаних з цим користувачем, тому реляційна база профілю повинна зберігати мапінг user_id → [point_id_1, point_id_2, ...].

Крок 3: Видалити або анонімізувати логи. Логи, що зберігаються для цілей аудиту, можуть містити текст розмов. Варіанти: псевдонімізація (заміна user_id на необоротний хеш) або повне видалення, якщо мета обробки не виправдовує довшого зберігання.

Крок 4: Інвалідувати кеш. Якщо семантичний кеш зберігає відповіді, що містять дані цього користувача (рідко, але можливо при персоналізованих відповідях), видалити пов'язані записи кешу.

Термін виконання: 30 календарних днів від вимоги. Автоматизуй весь процес і веди лог виконання вимог як доказ підзвітності (РОДО ст. 5 п. 2). Патерни анонімізації PII перед обробкою моделлю описані у статті про анонімізацію PII.

Ретенція даних у пам'яті агента – це не лише термін зберігання. Це рішення про те, як довго агент «пам'ятає» контекст і як це впливає на якість відповідей у порівнянні з ризиком зберігання надлишкових даних.

Практичний підхід: розділи векторну пам'ять на сегменти з різними TTL. Історія поточного проекту клієнта: TTL 6-12 місяців або до закриття проекту. Загальні комунікаційні переваги: TTL 24 місяці. Чутливі дані (наприклад, фінансові деталі): TTL 3-6 місяців або після першого використання.

Політику ретенції документуєш у DPIA. Якщо твій агент обробляє дані систематично у великих масштабах (наприклад, обслуговує тисячі клієнтів), DPIA є обов'язковою перед запуском. Вона містить опис мети обробки, категорій даних, часу ретенції та застосованих заходів безпеки.

Патерн ретенції, який добре зарекомендував себе у корпоративних впровадженнях: кожен фрагмент у векторній базі має поле expires_at (timestamp). Щоденний джоб бази даних видаляє застарілі фрагменти та оновлює мапінг point_id у профілі користувача. Для корпоративної бази знань (не персоналізованої) ретенція є необмеженою, але кожне оновлення документа запускає реіндексацію. Патерни управління знаннями RAG описані у статті про корпоративний GPT на базі знань.

Якщо дані клієнтів є особливо чутливими (медичні дані, фінансові дані, комерційна таємниця), self-hosting усього стеку пам'яті агента усуває ризик передачі даних до третьої країни. Модель ембедінгів (наприклад, BGE-M3), векторна база даних (Qdrant) та модель LLM (Ollama) можуть працювати на власній інфраструктурі. Уся система залишається під data-residency, як того вимагає РОДО. Детальні патерни self-hosting LLM з точки зору РОДО описані у статті про багатоагентні системи у компанії.

Векторні бази даних, як Qdrant, дозволяють видаляти точки за фільтром метаданих. Зберігай мапінг user_id → [point_id] у реляційній базі даних. При вимозі видалення: отримай список point_id з профілю, виконай DELETE points WHERE id IN (...) у векторній базі, видаляй профіль з SQL, анонімізуй логи. Увесь процес має бути автоматизованим і логованим як доказ підзвітності.

Перші ефекти помітні після 20-50 збережених фрагментів на користувача, зазвичай після 3-5 робочих сесій. При 100+ фрагментах агент починає точно підтягувати контекст з попередніх проектів. Якість більше залежить від точності чанкінгу та політики запису (що зберігаєш), ніж від обсягу даних.

Так, це хороша практика з двох причин. По-перше, підсумки займають менше токенів у вікні контексту, тому агент працює швидше. По-друге, можна видалити персональні дані з підсумку перед його збереженням, що спрощує ретенцію та зменшує обсяг DPIA. Недолік: втрата точності при специфічних фактах, які агент має запам'ятовувати детально.

Фільтр tenant_id у векторній базі даних є обов'язковим і має бути першою умовою запиту, перед обчисленням семантичної подібності. Сама подібність ембедінгів недостатня для ізоляції. Додатково шар guardrails на виході може перевіряти, чи відповідь не містить ідентифікаторів іншого тенанта (назви компаній, номери договорів).

Обидва підходи працюють у продакшені. pgvector у PostgreSQL (розширення) – хороше рішення при менш ніж 1-2 млн векторів та навантаженні до кількох сотень запитів на хвилину. При більших обсягах спеціалізовані бази (Qdrant, Weaviate) пропонують краще управління метаданими, багатоатрибутне фільтрування та оптимізації ANN (approximate nearest neighbor). Перевага pgvector – один системний сервіс для обробки як профілю користувача, так і ембедінгів, що спрощує каскадне видалення при реалізації права на забуття.