Память ИИ-агента: какая бывает и что действительно нужно

У модели нет памяти: каждый запрос она обрабатывает с нуля, а всё, что «помнит» агент, ему передают заново с каждым обращением. Отсюда главное практическое следствие — память стоит денег: чем больше передаётся, тем дороже каждый шаг. Задача проектирования не в том, чтобы помнить всё, а в том, чтобы передавать необходимый минимум.

Четыре вида памяти

Контекст запроса

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

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

История диалога

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

Растёт с каждым шагом, поэтому требует управления: полная история на двадцатом сообщении стоит в разы дороже, чем на первом.

Долговременная память

То, что переживает сессию: предпочтения клиента, история обращений, ранее принятые решения. Хранится в обычной базе и подтягивается по необходимости.

Это не «память модели», а обычная работа с данными. Ошибка проектирования — пытаться держать такие сведения в контексте вместо базы.

Рабочая память задачи

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

Как управлять размером

Скользящее окно. Передаются последние N сообщений. Просто и предсказуемо по цене; минус — забывается то, что сказали в начале.

Сжатие истории. Старая часть диалога заменяется кратким изложением. Дешевле полной истории, но при сжатии теряются детали, и какие именно — заранее не известно.

Выборка по релевантности. Из истории подтягивается только относящееся к текущему вопросу. Точнее остальных, но требует поискового механизма.

Структурированное состояние вместо переписки. Вместо всей истории передаётся заполненная карточка задачи: что известно, что осталось выяснить. Самый экономный вариант и самый устойчивый — рекомендуется для агентов по умолчанию.

Последний подход стоит пояснить. Диалог — плохой формат хранения состояния: он длинный, избыточный и требует от модели заново извлекать из него факты. Явная структура вида «клиент: известен; телефон: есть; тип заявки: определён; остаток: уточнить адрес» занимает несколько строк вместо десятков сообщений и не даёт модели «забыть» что-то в середине.

Что ломается на практике

• Контекст растёт незаметно. Задача из тридцати шагов на последнем шаге тащит результаты всех предыдущих. Счёт растёт нелинейно.
• Модель теряет середину. При длинном контексте начало и конец учитываются лучше середины. Важное нужно ставить ближе к концу, а не полагаться на то, что «оно там есть».
• Сжатие выбрасывает нужное. Краткое изложение сохраняет сюжет и теряет числа, идентификаторы и точные формулировки. Их следует хранить структурно, а не в тексте.
• Долговременная память подтягивается вся. «Загрузим всю историю клиента» — типичная ошибка: контекст раздувается, а полезны две-три записи.
• Персональные данные оседают в логах. История диалога с клиентскими сведениями сохраняется дольше, чем нужно, и попадает туда, где не должна быть — см. «152-ФЗ и нейросети».

Сколько памяти реально нужно

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

• рабочей памяти в виде структурированного состояния — обязательно;
• истории диалога — только если пользователь ведёт разговор, и то с ограничением;
• долговременной памяти — по запросу из базы, а не постоянно в контексте.

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

Влияние на стоимость

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

Что снижает расход, не ухудшая работу:

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

Расчёт — в статье «Стоимость эксплуатации ИИ-агента», общая методика по токенам — в «Сколько стоит эксплуатация ИИ-решения».

Расчёт: как растёт контекст на задаче из десяти шагов

Числа условные, важно соотношение. Примем: инструкция и описания инструментов — 2 000 токенов, постановка задачи — 300, результат каждого вызова — 400.

Вариант 1. Передаётся вся история.

Суммарно за десять шагов передаётся около 41 000 токенов. При этом полезной новой информации на каждом шаге — 400 токенов, всё остальное пересылается повторно.

Вариант 2. Структурированное состояние.

Вместо накопления результатов передаётся карточка задачи, обновляемая на каждом шаге: «клиент: найден, ID 1042; заказ: найден, №8871; тип обращения: вопрос по срокам; осталось: проверить дату отгрузки». Такая карточка занимает около 150 токенов и не растёт.

Суммарно — около 24 500 токенов вместо 41 000. Экономия порядка 40 %, и она растёт с числом шагов: на задаче из двадцати шагов разница будет уже двукратной.

Побочная выгода, которая важнее экономии. В первом варианте на десятом шаге модель получает результаты девяти вызовов вперемешку и должна сама извлечь из них нужное — а середину длинного контекста она учитывает хуже краёв. Во втором варианте состояние уже разобрано и структурировано, терять там нечего.

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

Частые вопросы

Есть ли у ИИ-агента память?

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

Что делать, если агент забывает начало разговора?

Хранить состояние структурно, а не полагаться на историю переписки. Заполненная карточка задачи — что известно, что осталось выяснить — занимает несколько строк, передаётся целиком и не теряется в середине контекста. История диалога при этом ограничивается последними сообщениями или сжимается.

Нужна ли агенту долговременная память?

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

Почему длинный контекст ухудшает качество?

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

Как сжатие истории влияет на работу?

Сжатие сохраняет общий смысл и теряет точные значения: числа, идентификаторы, формулировки. Для диалога это приемлемо, для агента опасно — он может потерять номер заявки или сумму. Такие данные хранятся отдельно в структурированном виде, а сжимается только повествовательная часть.

Что дальше

Как агент выполняет шаги и что попадает в контекст — «Function calling». Почему агент повторяет действия — «Зацикливание ИИ-агента». Что передаётся между агентами в сложных схемах — «Мультиагентные системы». Как это отражается на счёте — «Стоимость эксплуатации ИИ-агента».

Проектирование состояния и расчёт расхода контекста — часть работ по разработке и внедрению ИИ-агента.