Память ИИ нужно не накапливать, а проектировать

Большая общая память портит ответы

Желание понятное: пусть ИИ помнит всё. Все чаты, решения, правки, стиль, задачи. Кажется, тогда не придётся каждый раз вводить его в курс дела.

На практике лишний контекст становится помехой. Один и тот же человек за день может быть руководителем, родителем, исполнителем подработки и другом. Информация, полезная для одной роли, в трёх других превращается в шум.

В эксперименте с 18 моделями качество ответов снижалось по мере роста входного контекста. Причём речь шла даже о простых заданиях. Короткий фрагмент примерно на 300 слов давал результат лучше, чем полная переписка примерно на 100 тысяч токенов, где нужный факт был спрятан внутри. Особенно вреден контекст, похожий на нужную тему. Он выглядит релевантным и уводит модель в сторону.

Вывод прямой: память нужна не для складирования всего подряд. Она нужна для точного извлечения малого числа актуальных фактов. Это снижает число ошибок и экономит время на исправлениях.

Границы контекста нужно задавать вручную

У памяти есть три уровня изоляции. Их стоит выбирать по риску смешения задач.

Отдельный проект подходит для самостоятельной рабочей темы. Его контекст не смешивается с другими проектами и личными разговорами. При этом общие настройки пользователя могут оставаться доступными. Это удобно для постоянных предпочтений: например, для привычной манеры работы.

Чат без сохранения нужен для сырой мысли. Туда стоит выносить гипотезы, неутверждённые решения и всё, что не должно через месяц всплыть как установленный факт. Ещё это честный способ проверить ответ модели без накопленных подсказок о пользователе.

Локальная папка рабочего пространства даёт самую жёсткую изоляцию. Правила и заметки живут рядом с материалами проекта, их можно править как обычный текст. Но есть ограничение: такие данные остаются на конкретном компьютере. На другом устройстве этого контекста не будет.

Граница решает простую задачу: какая информация имеет право попасть в текущую работу. Если границы нет, в ответе начинают жить старые договорённости, чужие стили и случайные детали.

Автоматическая память не обязана хранить ваши рабочие правила

Модель сама решает, что пригодится в будущих разговорах. Поэтому устойчивое предпочтение она может сохранить, а разовую правку пропустить. Например, отношение к длине абзацев похоже на постоянную привычку. Запрет на конкретное слово может выглядеть деталью одной задачи.

Именно здесь многие обжигаются. Инструкцию повторяют несколько раз, а потом считают, что ИИ игнорирует человека. Нет. Система могла отнести правку к временному контексту и не перенести её дальше.

Нужна отдельная сущность: файл правил проекта. В нём должны лежать инструкции, которые обязательны всегда: как называть вещи, чего не делать, чем заканчивать работу, какие ограничения действуют для конкретной задачи. Такой файл возвращает авторство человеку. Автоматические заметки остаются вспомогательным конспектом, а правила становятся управляемыми.

Полезная привычка проста: если одно и то же замечание прозвучало второй раз, не повторяйте его в третий. Перенесите в правила.

Формулируйте именно условия, а не историю одной правки. Не «в этом тексте заменили слово X на Y», а «для этого заказчика слово X не используется, замена - Y». Первое описание срабатывает один раз. Второе работает в следующих задачах и не зависит от того, решит ли ИИ сохранить деталь сам.

Устаревшая память опаснее пробела в данных

Когда модели не хватает информации, она может переспросить, оставить пробел или оговориться. Устаревшая запись действует иначе. Она тематически близка к текущей задаче, поэтому выглядит убедительно. Модель опирается на неё уверенно.

Типичный сценарий: в заметках осталось «первая версия согласована, дальше оформление». Позже содержание изменили, но статус в памяти не обновили. Следующая итерация будет строиться на ложном основании и выглядеть вполне готовой к отправке.

Поэтому записи стоит делать с условием отмены. Вместо безусловного «версия согласована» лучше зафиксировать, что согласование действует по содержанию и отменяется при изменении бюджета или состава участников. Такая запись не претендует на вечную истину.

После завершения заметного этапа нужна короткая ревизия. Не просьба «сохрани всё», а конкретная проверка: какие записи больше не соответствуют действительности? Часть исправлений будет очевидна из материалов. Часть потребует решения человека, потому что разовая правка может стать постоянным правилом.

Управляемое забывание делает ИИ предсказуемее

Память состоит из трёх вещей: границы действия, критерия отбора и срока актуальности. Проект или локальная папка задают границу. Файл правил передаёт критерий отбора человеку. Условия отмены и ревизия не дают старым решениям тихо управлять новой работой.

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

Первый шаг на сегодня: откройте один активный проект и создайте короткий файл правил. Перенесите туда две повторяющиеся правки. Затем найдите одну старую запись о решении и допишите условие, при котором она перестаёт действовать. Этого достаточно, чтобы перейти от случайной памяти к управляемому рабочему контексту.

Для задач, где правила, материалы и процессы должны быть собраны в одном рабочем пространстве, подойдёт ATLAS PANEL.