Клиент однажды сообщил ассистенту, на какую почту отправлять счета. Через несколько месяцев в компании сменился контакт для бухгалтерии. Ассистент по-прежнему помнит старую договорённость и уверенно пользуется ею.
Технически всё работает. Память сохранилась, поиск нашёл нужную запись, модель учла её в ответе. Только результат неправильный: вчерашний контекст система приняла за сегодняшнюю истину.
Как только ИИ начинает помнить сведения между сессиями, продукт берёт на себя новую ответственность. Нужно решать, какие факты стоит сохранять, кто имеет право их менять и в какой момент они перестают быть актуальными.
История разговора — ещё не память
Самая простая реализация — сохранять все сообщения и искать по ним при следующем запросе. Так можно быстро собрать противоречия, временные просьбы, личные подробности и догадки самой модели.
История отвечает на вопрос «что мы обсуждали?». Полезная память должна отвечать на другой: «какие сведения допустимо использовать при решении этой задачи?»
Это разные задачи. Если пользователь однажды о чём-то рассказал, из этого не следует, что информацию надо превратить в постоянный атрибут его профиля. И уж точно сказанное не становится автоматически достоверным.
Для текущего диалога можно удерживать широкий контекст. Для долгосрочного хранения нужна гораздо более строгая логика.
Сохранять меньше, но понимать почему
Я бы начал с нескольких понятных типов данных: предпочтения, которые человек явно попросил запомнить; сведения из доверенной рабочей системы; информация для конкретной задачи с ограниченным сроком жизни.
У каждой записи должны быть происхождение и контекст. Откуда взялся факт — от пользователя, из CRM или из предположения модели? Когда он был подтверждён? Кому принадлежит? Когда устаревает?
Это позволяет разрешать конфликты. Актуальная запись в системе не должна незаметно проигрывать старой фразе в переписке. А догадку «похоже, клиент предпочитает…» нельзя через месяц представлять как явное решение клиента.
Модель может предложить, что стоит сохранить. Но право записывать данные надолго должно определяться правилами продукта, а не желанием модели быть полезной.
Найти факт — недостаточно
Даже правильная память нужна далеко не в каждом запросе. Предпочтение по способу оплаты вряд ли поможет ответить на технический вопрос. Лишние сведения увеличивают стоимость контекста и иногда уводят ответ не туда.
При поиске памяти стоит проверять три вещи: относится ли запись к текущей задаче, достаточно ли она актуальна и имеет ли пользователь право получить её в данном контексте.
Последнее особенно важно для корпоративных ассистентов. Информация, полученная на закрытой встрече, не должна всплывать в чате другого подразделения только потому, что поисковый алгоритм нашёл похожие слова.
Не стоит путать долговременную память с контекстным окном модели. Большое окно позволяет передать больше текста. Оно само по себе не решает, что сохранять, кому показывать и чему верить.
Исправление и удаление — часть архитектуры
Люди меняют решения. Компании — тарифы, процессы и сотрудников. Если сохранённую информацию невозможно исправить, память постепенно становится хранилищем уверенных ошибок.
Пользователь должен понимать, какие важные сведения сохранены, уметь их корректировать и удалять там, где это применимо. Причём удаление должно затрагивать реальные хранилища и производные данные, продолжающие влиять на ответы, с учётом законных требований к хранению.
Скрыть запись из интерфейса настроек недостаточно. Если её копия осталась в другом индексе и продолжает попадать в промпт, для пользователя ничего не изменилось.
А что делать, если удалённый факт ранее попал в другую, обобщённую запись памяти? Значит, системе нужно понимать связи между исходными и производными сведениями. Это уже вполне обычная задача управления данными.
Тестировать стоит не только удачные воспоминания
Проверка памяти не может ограничиваться демонстрацией «смотрите, ассистент запомнил имя». Интереснее посмотреть, как он реагирует на противоречия, игнорирует ли нерелевантные записи, соблюдает ли границы доступа и перестаёт ли использовать исправленное или удалённое.
Вопросы персональных данных и их движения по инфраструктуре я отдельно разбираю в материале о приватности AI.
Не каждому продукту вообще нужна долгосрочная память. Сервис, который извлекает данные из документов, может прекрасно работать с контекстом каждого отдельного запроса. Постоянная история пользователей добавит ему обязанности, но необязательно принесёт пользу.
Хорошая память — выборочная. Важнее не сколько всего ИИ способен запомнить, а можно ли доверять тем сведениям, которые он решит использовать завтра.