Память ИИ-агента — это не база данных: что хранить, извлекать и забывать.

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

База данных может содержать миллионы записей, при этом ни одна из них не обязана находиться в памяти агента. Здесь возникают другие инженерные вопросы: что следует запоминать и на какой срок? Где это хранится, когда данные загружаются и когда удаляются? И является ли это вообще памятью? С такой точки зрения память — это скорее проблема релевантности, чем проблема хранения.

Почему подход «хранить всё» не срабатывает

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

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

Четыре понятия, которые часто путают

Эти концепции решают разные проблемы, и проектирование агентов улучшается при их разделении.

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

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

Состояние указывает на текущий этап выполнения работы. Это может быть статус вроде QUEUED, RUNNING, WAITING_FOR_TOOL, RETRYING или COMPLETED, либо более детальные флаги, такие как document_extracted = true, analysis_completed = true и report_generated = false. Состояние позволяет системе продолжать работу. Это не является знанием.

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

Краткосрочная память

Краткосрочная память — это рабочий набор информации. Люди, решающие проблему, хранят в голове определенные факты и удаляют большинство из них после завершения работы, и у агентов есть такая же потребность. В ходе одного рабочего процесса агент может использовать текущий запрос, выбранный документ, результаты недавних операций с инструментами, промежуточные расчеты, предыдущие решения и ход выполнения задачи. Все это имеет значение сейчас, но завтра может стать практически бесполезным. Хорошее определение — это минимальный набор информации, необходимый для продолжения текущей задачи, а не все, что произошло с момента ее начала.

Долгосрочная память должна заслужить своё место

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

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

RAG — это не долгосрочная память

Предположим, что в векторном индексе находится 20 000 внутренних документов, и агент может их искать. Это не память агента. Документы представляют собой знания, а RAG — способ их извлечения. Агент не должен хранить все документы в своей памяти, ему достаточно знать, как найти нужный. Здоровый подход заключается в том, что агенту нужна информация, он ищет её в источнике знаний, извлекает соответствующие доказательства и использует их. Нездоровый подход — копирование всего знания в память. Знания могут быть огромными, в то время как рабочая память должна оставаться небольшой.

Состояние часто важнее памяти

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

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

Не всё, что произошло, заслуживает хранения

Представьте, что инструмент возвращает JSON-данные объемом 500 строк. Нужны ли для следующего шага все 500 строк? Скорее всего, достаточно лишь одного-двух полей, таких как account_status = ACTIVE, total_balance = 120000 или document_found = true. Чистый вывод может оставаться в логах или хранилище, а в памяти можно сохранять только те данные, которые действительно важны.

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

Что стоит запомнить

Нет единого решения, подходящего для всех систем, но обычно хорошими кандидатами являются следующие категории:

• Стабильные предпочтения: формат вывода, язык, стиль отчетности.

Определенно подтвержденные решения: выбранная конфигурация, утвержденный вариант рабочего процесса, выбранный источник достоверной информации.

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

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

Чего стоит избегать при хранении

• Каждый ответ модели. Большая часть промежуточных рассуждений позже не бывает полезной.
• Каждый результат работы инструмента, который может быть объемным, устаревшим или актуальным только в определенный момент.
• Временные ошибки. Вчерашний сбой не должен становиться частью контекста завтрашней работы.
• Непроверенные предположения модели — самая серьезная проблема. Если модель утверждает, что документ «по-видимому относится к Компании А», но никто этого не подтверждает, хранение такого документа может превратить слабую догадку в постоянный факт, на котором позже будут основываться дальнейшие действия.
• Конфиденциальные данные, для хранения которых нет четкой причины. Память должна иметь определенную цель.

Память может быть неверной

Это одна из главных проблем долгосрочной памяти. Система запоминает, что валюта отчетности клиента — доллар США, но через шесть месяцев предпочтения клиента меняются, а старая запись остается. Что в итоге имеет приоритет? Память нуждается в понятии актуальности. Некоторые факты остаются верными годами, а другие — всего несколько минут, и хорошая система умеет различать их.

Цикл жизни данных, а не просто хранение и забвение

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

Важность исходных данных

Предположим, существуют два источника информации. В одном указано, что предпочтительным форматом является PDF, и пользователь вчера прямо это подтвердил. В другом говорится, что предпочтительным форматом может быть Excel, к чему шесть месяцев назад пришел к выводу ИИ-модель. Эти источники не должны иметь одинаковой весимости, именно поэтому в идеале в записях должна указываться происхождение информации: была ли она предоставлена пользователем, сгенерирована системой, выведена моделью, взята из документа, вернута инструментом или скопирована откуда-то еще? Этот контекст помогает системе определить, в какой степени ей можно доверять.

Уровень уверенности тоже важен

Фраза «Срок действия контракта, по-видимому, истекает в июне» — это другой тип утверждения по сравнению с записью «Дата истечения контракта: 30 июня 2027 года», взятой из структурированного поля. Одно можно считать утверждением с высокой степенью достоверности, а другое — требующим проверки, поэтому расплывчатые выводы не превращаются незаметно в факты. Полезная долгосрочная запись часто содержит не только значение, но и поля source, confidence, timestamp, scope и status, что значительно упрощает последующий поиск.

Краткое изложение — это интерпретация

Краткие резюме — один из лучших способов сокращения объема рабочей памяти. Храните записи вроде «пользователь хочет краткое техническое объяснение с примерами» вместо полного текста разговора, или «три вывода подтверждены, один остается нерешенным» вместо описания каждого шага анализа. Однако резюме представляет собой интерпретацию и может упустить важные детали. Для важных рабочих процессов следует сочетать резюме с ссылкой на исходные данные. Резюме помогает агенту работать эффективно, а исходные данные остаются доступными в случае необходимости проверки информации.

Не создавайте второй источник правды

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

Область применения

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

Получение информации из памяти — это задача поиска

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

Пишите меньше, извлекайте лучше

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

Наблюдаемость

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

Более реалистичная архитектура

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

• Контекст работы для того, что необходимо прямо сейчас, такой как текущий запрос, результат последнего инструмента и нынешнее решение.
• Краткосрочная память для того, что требуется в рамках данного рабочего процесса, например краткое описание задачи, промежуточные результаты и недавние решения.
• Долгосрочная память для того, что может помочь в будущих рабочих процессах, такое как стабильные предпочтения, подтвержденные факты или исторические результаты.
• Знания и технология RAG для информации, находящейся в других источниках, таких как документы, политики, отчеты и базы данных.
• Состояние приложения для определения истины, такое как статус, контрольные точки, количество попыток повтора и завершенные шаги.

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

Вопросы, которые следует задать перед добавлением функции памяти

• Поможет ли это в выполнении будущей задачи? Если нет, не храните ее.

Можно ли получить его из авторитетной системы? Если да, возможно, лучше использовать RAG или обычный запрос.

Является ли это состоянием рабочего процесса? Держите его вне LLM.

Было ли это проверено? Не превращайте предположения модели в постоянные факты.

Как долго оно действительно? Некоторые данные должны иметь срок действия.

Что происходит, когда оно меняется? Определите правила обновления и замены.

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

Можете ли вы объяснить, почему оно появилось в контексте агента? Если нет, отладка становится сложной.

Нужны ли модели исходные данные или только краткое резюме? Сохраняйте объем рабочих данных на минимуме.

Ответы на эти вопросы обычно важнее, чем выбор базы данных для хранения информации.

Забывание — это функция

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

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