Как проверить, что память действительно помогает агенту
Агент нашёл прошлый разбор ошибки и правильно его пересказал. Полезно, но для оценки памяти этого мало. Следующая проверка — помог ли разбор выполнить новую задачу, не перенёс ли агент устаревшее правило и сколько стоил весь процесс.
Одинаковую новую задачу выполняют с памятью и без неё из одного исходного состояния. Сравнение может показать пользу, вред или недостаток данных.
Проверять стоит изменение результата на новых задачах при добавлении памяти к тому же агенту. Ниже — авторский протокол такой проверки. Он рассчитан на разработчика или команду, которые могут повторно запускать агента в изолированном окружении, сохранять его действия и независимо проверять результат. Это план эксперимента; собственных измерений эффективности в статье нет.
Устройство памяти и различия её областей разобраны в обзоре агентной памяти. Здесь задача уже: подготовить сравнение, увидеть пользу и найти место отказа.
Сначала сформулируйте, какое действие должно улучшиться
Выберите один повторяющийся класс работы. Например: исправление ошибок импорта, подготовка плана по меняющимся ограничениям или продолжение исследования между сессиями. Запишите ожидаемое изменение через результат: «чаще исправляет дефект без потери корректных данных», «реже предлагает отменённую договорённость», «тратит меньше времени на повторное исследование при прежнем качестве».
Здесь полезны два исследовательских ориентира. LongMemEval проверяет ответы по истории общения: извлечение сведений, объединение нескольких сессий, работу со временем, обновления и воздержание при отсутствии данных. В нём отдельно оцениваются найденные свидетельства и итоговый ответ. Истории сконструированы для проверки, а оценка свободных ответов использует модель-оценщик. Это помогает выбрать вопросы к памяти, но не заменяет проверку действий в вашем приложении. LongMemEval, v2, §§3.1–3.3.
MemoryArena строит последовательности взаимозависимых задач: сведения из прошлых сессий нужны для последующих действий. Работа различает завершение задачи целиком и частичный прогресс. Её среды — веб-покупки, планирование поездок, поиск и формальные рассуждения — не являются испытанием вашей системы разработки. Для нашего протокола важен сам вопрос: использовал ли агент прошлое при выполнении следующей работы? MemoryArena, v2, §§3–4.2.
Не сводите эти вопросы к одному баллу. Сохранённый факт, найденная запись, правильное применение и успешная задача — разные наблюдения.
Условный пример: повторная доставка события
Представим агента разработки, который читает код, меняет его и запускает проверки. Все действия происходят в учебной копии сервиса импорта.
В прошлой задаче сервис дважды обработал одно событие. Агент установил: event_id обозначает событие, а order_id — заказ, у которого бывает несколько событий. Проверенное исправление отсеивало повтор по event_id. В память попали причина ошибки, условия применимости и две проверки: повтор одного события не меняет результат; новое событие того же заказа обрабатывается.
В новой задаче приходит другой обработчик. Согласно его текущему контракту, event_id уникален только внутри аккаунта. Поэтому опыт нужно уточнить: сравнивать пару account_id и event_id. Механическое копирование прежнего ключа потеряет корректное событие другого аккаунта.
Проверяющий заранее готовит случаи, скрытые от агента:
| Случай | Что должно произойти |
|---|---|
| Повтор того же события того же аккаунта | Повтор не создаёт дополнительного результата |
| Другое событие того же заказа | Новое событие обрабатывается |
Тот же event_id у другого аккаунта |
Оба события обрабатываются |
| Повторные события приходят одновременно | Итог соответствует одному применению каждого события |
Эти проверки относятся к вымышленному сервису. Они не задают универсальную реализацию обработки повторов: её выбирают с учётом транзакций, внешних действий и контракта конкретного приложения.
Успехом эксперимента будет исправленный обработчик, прошедший независимые проверки. Фраза «я учёл прошлый опыт» доказательством не считается. Если агент без памяти получил тот же результат быстрее, это тоже полезный результат сравнения.
Подготовьте опыт, новые задачи и проверяющего
Для запуска нужны четыре вещи: управляемая версия агента, восстанавливаемая среда, набор задач и проверяющий. Для примера выше среда включает исходный код, тестовую базу и контракт событий; проверяющий запускает скрытые проверки на результате работы агента.
Сначала разделите материал на три части:
- Прошлый опыт. Завершённые задачи, по которым можно строить память. Храните исходные действия, результат и основания считать его правильным.
- Задачи настройки. На них выбирайте способ записи, поиска и подачи памяти агенту.
- Отложенные задачи. Откройте их только после фиксации настройки. Их решения, скрытые проверки и результаты будущих запусков не должны попасть в исходную память.
Разделяйте задачи по смыслу. Переименование файлов в уже решённой задаче почти ничего не говорит о переносе опыта. В примере новизну создаёт изменение области уникальности идентификатора. Для более широкого вывода нужны другие причины ошибок и другие условия, а не только варианты имён.
Запишите версии модели, инструкции, инструментов, кода и хранилища; исходный снимок памяти; лимиты времени, действий и расхода; правило остановки и критерий успеха. Если результат оценивает человек или другая модель, заранее задайте рубрику и скройте от оценщика название варианта. На спорных случаях проверьте оценщика вручную. Уверенность проверяющей модели не заменяет наблюдаемого результата.
Число задач и повторов выбирайте под требуемую точность и стоимость ошибки. Для отладки достаточно обнаружить конкретный сбой; для решения о широком внедрении нужно увидеть устойчивость на разнообразных задачах. Универсального достаточного размера выборки этот протокол не задаёт. Повтор одного и того же задания помогает оценить разброс, но не заменяет новые независимые задачи.
Запустите парное сравнение
В основной паре меняется только добавочный механизм памяти:
| Вариант | Что доступно агенту |
|---|---|
| А. Без добавочной памяти | Текущая задача, исходники, инструменты и обычный доступ к архиву прошлой работы |
| Б. С памятью | Всё то же самое плюс записи и способ их извлечения, подготовленные из этого же архива |
Вариант А сохраняет обычное состояние текущей работы. Что считается состоянием, контекстом и межсессионной памятью, поясняет отдельный справочник. В этом эксперименте мы оцениваем пользу организованной памяти сверх уже доступных источников. Если лишить А всего прошлого, получится другой вопрос — полезна ли историческая информация вообще. Такое сравнение допустимо, но назовите его отдельно.
Одинаковые лимиты создают общий предел возможностей, а не одинаковый фактический расход. Запрос памяти может потратить часть бюджета Б; его результат может сэкономить дальнейшие действия. Сохраняйте оба эффекта. Если Б разрешён больший бюджет, нельзя приписать весь выигрыш только памяти.
Для каждой отложенной задачи выполните один и тот же порядок:
- Восстановите исходный код, данные и внешнее состояние учебной среды. Создайте чистую сессию — отдельный запуск агента без истории предыдущей попытки.
- Подключите вариант А или Б. Чередуйте либо случайно выбирайте порядок вариантов внутри пары, чтобы нагрузка сервиса и время запуска не совпадали постоянно с одним из них.
- Выполните задачу до заранее установленного условия остановки. Сохраните действия, полученные записи памяти, финальный артефакт, время и расход.
- После остановки передайте результат одному и тому же независимому проверяющему. Ответы скрытых проверок не возвращайте агенту в этот оцениваемый запуск. Не исключайте неудачные попытки из журнала.
- Полностью восстановите среду и повторите для второго варианта. Ни результат, ни новые записи первого запуска не должны перейти во второй.
- Выполните запланированные повторы с тем же правилом изоляции. Если сервис поддерживает фиксацию случайности, запишите параметры; это само по себе не гарантирует точного повтора ответа.
В таком опыте заморожены и исходная память Б, и общий архив прошлой работы, доступный обоим вариантам. Журналы новых запусков, новые записи памяти и ответы проверяющего сохраняйте отдельно для разбора. Не открывайте их ни одному варианту в следующих независимых задачах. Иначе порядок задач станет ещё одним фактором.
Накопление опыта проверяйте отдельным режимом. Заранее задайте последовательности зависимых задач, разрешите обновление памяти между их шагами и сбрасывайте её только перед новой последовательностью. Единицей сравнения тогда становится целая последовательность. Покажите и конечный результат, и прогресс по шагам; не смешивайте эти данные с опытом на замороженной памяти.
Добавьте случаи, в которых память должна уступить текущим данным
Полезный опыт не обязан применяться каждый раз. К обычным задачам добавьте следующие варианты и заранее запишите ожидаемое поведение:
| Вариант проверки | Ожидаемое поведение и наблюдаемый след |
|---|---|
| Подходящий прошлый опыт | Запись помогает выбрать действие; результат проходит независимую проверку |
| Похожая задача с другими условиями | Агент проверяет область применимости. В нашем примере учитывает аккаунт, а не копирует старый ключ |
| Устаревшая запись | Текущий контракт применяется к текущей задаче. Если задан исторический вопрос, используется соответствующая ему редакция |
| Две противоречивые записи | Агент обращается к принятому источнику или отмечает неразрешённый конфликт; не выбирает произвольную запись по уверенности формулировки |
| Нужного свидетельства нет | Агент ищет доступный источник либо сообщает, каких сведений не хватает. Для задачи, где по условиям нужен вопрос человеку, уточнение считается правильным действием |
| У записи отозван доступ | Запись не появляется в ответе хранилища для этого пользователя и не передаётся модели |
| Запись удалена в оговорённой области | После завершения предусмотренного системой удаления она не возвращается из поиска, сводок и подключённых к выдаче копий |
Для проверки доступа используйте синтетическую запись с уникальным маркером. Смотрите данные на границе хранилища и входа модели. Отсутствие маркера в финальном ответе не доказывает, что закрытая запись не попала в контекст — сведения, переданные модели при вызове.
Удаление тоже требует явного условия. Заранее перечислите, какие записи, индексы, сводки, кэши и архивы входят в обещание системы, когда оно должно выполниться и какие технические следы вправе сохраниться отдельно. По одному отсутствующему ответу поиска нельзя доказать уничтожение всех копий. Проверка резервных копий и хранения журналов — отдельная часть этого обещания; её результат не выводится из поведения агента.
Запишите результаты так, чтобы было видно, где память помогает
На каждый запуск сохраните одну строку журнала: идентификатор задачи и её группы, номер повтора, вариант, версии, исходный снимок памяти, исход проверки, найденные записи, ошибочное применение, время, расход и ссылку на артефакт. Для доступа отдельно отметьте прохождение запрещённых данных через границу; для удаления — проверенные места и момент проверки.
Ниже — пустой бланк, а не результаты измерения. Знак «—» означает «ещё не измерено». Группы строк заполняются отдельно для обычных задач, изменённых условий и остальных проверок.
| Показатель | А: без добавочной памяти | Б: с памятью |
|---|---|---|
| Группа задач; число задач и повторов | — | — |
| Успешные запуски / все оцениваемые запуски | — | — |
| Успех только этого варианта в паре | — | — |
| Неверное применение прошлого опыта: число и примеры | — | — |
| Правильное уточнение / случаи, где оно требовалось | — | — |
| Нарушения доступа или удаления | — | — |
| Время до проверенного результата: середина и разброс | — | — |
| Полная стоимость; затраты на подготовку отдельно | — | — |
| Неоценённые запуски и технические сбои | — | — |
Сравнивайте пары: где выиграл Б, где выиграл А, где оба справились и где оба ошиблись. Среднее по всем задачам может скрыть регресс на новом контракте. Покажите результаты каждой группы и разброс повторов. Для вывода с оценкой статистической неопределённости учитывайте зависимость повторов внутри одной задачи; их нельзя автоматически считать отдельными независимыми примерами.
В полную стоимость включите подготовку и обновление памяти, хранение, поиск, вызовы моделей, инструменты и время человека. Отдельно покажите разовые затраты и расход на задачу. Если распределяете стоимость подготовки на будущие задачи, укажите предполагаемое число использований: это допущение, а не уже полученная экономия.
Время измеряйте от начала запуска до завершения независимой проверки, отдельно показывая время агента и проверяющего. Обычные доступные агенту тесты и исправления внутри запуска входят в его бюджет. Скрытые проверки выполняются после остановки; агент не получает их ответы и не продолжает эту попытку. Для неуспешных запусков действует заранее установленный предел. Если хотите измерять доработку после замечаний независимого проверяющего, задайте отдельный режим с обратной связью и учитывайте его циклы и расходы отдельно.
Если Б ошибся, проверьте цепочку: нужное свидетельство было в исходном опыте? Сохранилось в записи? Было найдено? Попало во вход модели? Повлияло на действие в подходящих условиях? Для диагностики можно отдельно подать агенту нужное разрешённое свидетельство напрямую. Успех такого запуска даёт основание исследовать сохранение и поиск; провал оставляет вопросы к пониманию и исполнению. Одна попытка не устанавливает причину: результат может измениться из-за случайности ответа или состава остальных сведений. Этот диагностический вариант с дополнительной подсказкой нельзя смешивать с результатом обычного поиска.
Примите решение по заранее заданному правилу
До запуска определите, какой выигрыш оправдывает расходы, какую потерю качества вы готовы принять ради скорости и какие ошибки недопустимы. Для рассматриваемого сервиса потеря корректного события блокирует принятие исправления, даже если оно быстро устранило дубли.
Если Б устойчиво улучшает нужный результат в заданном бюджете и проходит обязательные проверки, есть основание расширить пилот на следующий класс задач. Если он только лучше пересказывает прошлое, цель проверки действий пока не достигнута. Если помогает на знакомом контракте и вредит на изменённом, следующий шаг — исправить отбор и проверку применимости. Если данных недостаточно, зафиксируйте неопределённость и добавьте задачи, способные различить объяснения результата.
Итог эксперимента должен быть конкретным: какая конфигурация помогает какой работе, по сравнению с чем, какой ценой и где пока ошибается. Такой вывод можно проверить повторно после смены модели, правил памяти или условий задачи.
Термины
- Добавочная память — подготовленные из прошлого опыта записи и механизм их подачи агенту сверх доступных исходников и обычного состояния работы.
- Отложенная задача — задание, которое не использовали для формирования опыта и настройки проверяемого решения.
- Парное сравнение — запуск вариантов на одной и той же задаче из одинакового исходного состояния.
- Перенос опыта — применение прошлого результата или способа действия к новой задаче с проверкой условий.
- Контекст — сведения, переданные модели при конкретном вызове, включая полученные записи памяти.
- Модель-оценщик — модель, которая проверяет результат по заданной рубрике; качество такой проверки тоже требует контроля.
Источники
Проверены 17 октября 2026 года. Использованы постановки задач и методы оценки двух работ; их эксперименты здесь не воспроизводились. Пример сервиса и прикладной протокол — авторская конструкция. Это не полный обзор способов оценки памяти.
- Wu et al. LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory, arXiv:2410.10813v2, 4 марта 2025 — §§3–4: разговорная память, обновления и отдельная оценка извлечения и ответа.
- He et al. MemoryArena: Benchmarking Agent Memory in Interdependent Multi-Session Agentic Tasks, arXiv:2602.16313v2, 17 сентября 2026 — §§3–4.2: зависимые задачи нескольких сессий, успех целой задачи и частичный прогресс.
Все материалы по теме: «Организационная и агентская память».
Хотите внедрить это у себя?
Помогаю командам выстроить работу с ИИ-агентами и проверить эффект изменений на реальных задачах. Короткие заметки между статьями выходят в Telegram-канале.