Когда ИИ должен использовать свою память? Пилоты и постоянная память, а также льстецы
Когда ИИ-модель должна использовать свою память? Получение информации из памяти не позволяет ей формировать ответ. Пилоты с заранее введенной памятью и устройством контроля влияния против лести.
Источники: When Should an AI Use Its Memory? An Experiment on Persistent Memory in LLM Agents
Каждый, кто использует ИИ-ассистента уже несколько месяцев, знает эту закономерность. Со временем он собирает о вас информацию: что вы предпочитаете Python Java, готовитесь к экзамену, и, возможно, даже знает детали о вашем здоровье, о которых вы бы не стали рассказывать коллеге.
Сначала это удобно. Вы просите его составить план питания с высоким содержанием белка, и он сам запоминает, что вы веган, без необходимости повторения. В этом и заключается смысл персонализированного ассистента.
Теперь измените ситуацию. Вы спрашиваете, как работает градиентный спуск. Должен ли ассистент упомянуть, что вы предпочитаете Python? Вряд ли.
Или предположим, что несколько месяцев назад вы заявили, что подход X явно лучший. Позже вы задаете объективный вопрос об X. Должен ли ассистент помнить, что вы придерживаетесь такого мнения? Возможно, да, как факт ваших взглядов. Но должен ли он считать это ваше мнение доказательством того, что X действительно лучший? Конечно, нет.
Здесь есть пробел, который при обсуждении памяти ассистентов часто игнорируется. Хранение факта и определение того, когда он должен быть включён в ответ, — это два разных навыка.
Постоянная память превращает это в реальную проблему
Обычные языковые модели работают в основном с контекстом, предоставленным в текущем диалоге. Системы с постоянной памятью меняют это. Примитивная система может вспомнить всё, что она знает о пользователе, поскольку это может быть релевантно, и затем адаптировать свои ответы под эти факты.
Поэтому качество памяти нельзя оценивать только по тому, использовала ли модель память. Не менее важно то, как она ею пользовалась.
Недавние исследования начали измерять это напрямую. PersistBench — тест на безопасность постоянной памяти в больших языковых моделях — рассматривает три категории: утечку памяти между доменами, слишком большую зависимость от памяти и эффективное использование памяти. В нем содержится 500 образцов, проверенных людьми, разделенных на 200 случаев утечки памяти, 200 случаев чрезмерной зависимости и 100 случаев эффективного использования памяти.
Два модели и более сложный вопрос
За этими тремя показателями скрывается более тонкое различие. Представьте модель, которая отлично умеет использовать память: каждый раз, когда информация из памяти актуальна, она включает её в ответ. Это звучит впечатляюще. Но что, если она будет включать информацию из памяти и тогда, когда это не имеет значения?
Теперь представьте вторую модель, которая почти никогда не опирается на память. Она редко допускает утечки информации, но также не способна адаптировать ответы под конкретного пользователя. Какая из них лучше?
Память со временем стареет
Возьмём пользователя, который в январе говорит, что в основном использует Python. В июне он утверждает, что перевёл большинство проектов на Rust. В декабре он спрашивает, какой язык он использует в основном.
У системы, которая просто хранит оба утверждения, есть проблема. Каждое из них могло быть истинным в момент сказания, но у них разный временной статус. Может ли модель определить, какие «воспоминания» должны влиять на её текущее поведение?
Эту более общую концепцию можно назвать управлением контекстуальной памятью. Основная идея заключается в том, что извлечение воспоминания не автоматически даёт право использовать его для формирования ответа. Именно эта идея лежит в основе последующих экспериментов.
Эксперимент первый: понимает ли модель смысл воспоминания?
Прежде чем разрабатывать новую систему памяти, требовался ответ на более простой вопрос. Что, если проблема не в самой памяти, а в том, как модель её интерпретирует?
Первый эксперимент возник в результате воспроизведения PersistBench. Был проведен пилотный тест с 30 образцами, распределенными по трем категориям: 10 образцов междоменного взаимодействия, 10 образцов лести и 10 образцов полезной памяти. Результаты оказались крайне односторонними.
Модель в целом не терпела неудач при использовании памяти. Ее проблема была более узкой: когда в памяти хранилось сильное мнение или убеждение пользователя, модель иногда воспринимала это убеждение как объективный факт.
Возьмем сохраненную фразу вроде «пользователь предпочитает Python Rust». Традиционная система сохраняет строку в том виде, в котором она представлена, но на самом деле она несет в себе больше смысла. Она указывает, кто высказывает мнение (пользователь), в чем заключается это мнение (например, «Waterfall лучше Agile») и что это за информация (убеждение).
Гипотеза
Это привело к простой гипотезе: указание семантической роли воспоминания может помочь большой языковой модели отличать информацию о пользователе от утверждений о мире. От модели не требуется забывать это убеждение. Суть в том, что убеждение пользователя не является фактом о мире. Это также позволяет более точно понимать явление льстивости, вызванной воспоминаниями.
Эксперимент два: контролируемое тестирование
Чтобы проверить эту идею, команда вернулась к неудачам первоначального пилотного исследования. Вместо того чтобы создавать новый критерий оценки, они снова использовали те же неудачные примеры, изменив лишь способ представления каждого воспоминания. Это привело к формированию трех условий.
Условие А: сырое воспоминание. Это базовый вариант. Модель видит воспоминание точно таким, каким оно предоставляется PersistBench:
User believes Waterfall is better than Agile.
Условие B, типизированная память. Содержимое остаётся прежним, но добавляется его семантический тип:
Type: USER_BELIEF
Content:
User believes Waterfall is better than Agile.
Ничего в содержании не меняется. Только его роль становится более ясной.
Условие C: типизированная память плюс эпистемический контекст. Здесь приводится краткое указание о том, что убеждение пользователя отражает его собственную точку зрения и не должно автоматически рассматриваться как объективный факт или независимое доказательство. Модели не говорят игнорировать убеждения; ей указывают лишь на необходимость различать два аспекта:
What the user believes
и
What is objectively supported
Сохранение масштабов
Тест был намеренно скромным по объему. В нем использовались семь примеров неудач в использовании лести из пилотного теста, каждый из которых анализировался во всех трех условиях; кроме того, для проверки корректности были добавлены три примера, способствующих формированию памяти. Всего получилось 10 образцов в 3 условиях, то есть 30 оценок в целом. Целевая модель оставалась прежней — Gemini Flash, и та же модель выполняла роль судьи. Запросы и содержимое памяти не менялись между условиями; менялись только их представление и сопутствующие инструкции.
Вопрос заключался в том, изменится ли поведение модели лишь из-за того, что эпистемическая роль памяти была четко определена.
Ответ не был однозначным
При использовании текстовых инструкций наблюдалось незначительное улучшение. Добавление четкой эпистемической инструкции не привело к дальнейшему снижению количества ошибок. Семь примеров слишком мало, чтобы сделать статистические выводы, поэтому их делать не следует.
Тем не менее само поведение было интересным. Модели можно было прямо указать, что что-то представляет собой убеждение пользователя, а не объективные доказательства, и в нескольких случаях она всё равно позволяла этому убеждению формировать ответ, как будто речь шла об объективной рекомендации.
Когда представление недостаточно
Это изменило подход к проблеме. Изначально предполагалось, что модель неправильно использует воспоминания из-за отсутствия понимания того, что они представляют. Второй эксперимент показал, что объяснение было неполным. Модели могут быть предоставлены семантический тип и правило интерпретации, но они всё равно могут давать неподходящие ответы. Это указывает на более глубокое различие: знание того, что представляет собой воспоминание, не обязательно равносильно способности контролировать его влияние.
Третий эксперимент: от извлечения к влиянию
Если описание воспоминания не всегда изменяет его влияние на ответ, возможно, настоящая проблема заключается в том, что после извлечения воспоминания у модели слишком много свободы в том, как им воспользоваться. Поэтому возник вопрос: должно ли извлечение воспоминания автоматически позволять ему влиять на ответ.
Рассмотрим сохранённую запись, согласно которой пользователь считает, что методология Waterfall превосходит Agile. Система извлечения данных может правильно определить её как релевантную для вопроса о методологиях программирования. Однако релевантность не указывает, как ею воспользоваться. Она может помочь ассистенту понять человека: вы предпочитаете Waterfall, вот как они сравниваются. Или же она может ошибочно стать основанием для вывода: Waterfall — лучшая методология. В обоих случаях извлекались одни и те же воспоминания. Разница заключается в степени их влияния. Извлечение и влияние — это разные вещи.
Контроллер влияния
Первое архитектурное изменение заключается в наличии контроллера, расположенного между этапами извлечения и генерации информации. Для каждой кандидатской памяти он выдает структурированное решение, описывающее не только содержание памяти, но и то, как оно должно повлиять на текущий ответ. Например, убеждение в использовании методологии «Водопад» может быть классифицировано как пользовательское убеждение с высоким уровнем релевантности, однако ему присваивается условное влияние и определенная роль с точки зрения точки зрения пользователя. Релевантность и влияние представляют собой отдельные показатели. Память может быть высокорелевантной к запросу, но при этом не являться тем, что модель должна использовать в качестве доказательства или основы для рекомендации.
Тест и его результаты
Чтобы протестировать дизайн без использования новых критериев оценки, команда вернулась к примерам, которые послужили стимулом для работы: семь случаев лицемерия и три случая полезной памяти. Базовой моделью оставалась исходная схема обработки памяти, а в экспериментальной системе был добавлен контроллер. Все остальное оставалось без изменений.
Результаты оказались более сложными, чем просто «успех» или «неудача». В семи случаях лицемерия количество неудач снизилось с 6 из 7 до 5 из 7. Это незначительное изменение уровня неудач. Более интересным стало изменение степени серьезности неудач: средний показатель серьезности снизился с 3,71 до 3,00, в то время как в случаях полезной памяти никаких изменений не произошло.
Решение контроллера
Окончательный ответ является лишь частью того, что команда хотела измерить. Впервые стали видны промежуточные решения по использованию памяти. В ходе 10 примеров контроллер принял 87 отдельных решений относительно использования памяти, и более половины извлеченных данных были помечены как SUPPRESS. Следовательно, архитектура не передавала все извлеченные данные генератору — она фильтровала контекст памяти.
Многие из данных, которые были подавлены, представляли собой нерелевантные для пользователя факты, такие как несвязанные личные детали, извлеченные рядом с вопросом, где они не играли никакой роли. Это указывает на то, что контроллер не просто учился использовать память из-за её полезности; он решал в каждом конкретном случае, заслуживает ли та или иная информация повлиять на текущий ответ.
Так сработало ли это?
Частично, что, вероятно, является самым честным ответом. Дизайн не устранил симпатию, вызванную воспоминаниями. Пять из семи случаев проявления симпатии всё ещё не прошли критерий теста. Однако по сравнению с исходными данными количество неудач сократилось с 6 до 5, а степень их серьёзности уменьшилась, при этом полезная персонализация сохранилась.
Возможно, более значимым моментом является то, что контроль влияния воспоминаний показался более перспективным, чем добавление дополнительной описательной информации о них. Во втором эксперименте модели говорили, что что-то является убеждением и не должно рассматриваться как факт. В третьем эксперименте был добавлен отдельный механизм, определяющий, что именно должно быть разрешено воспоминанию в данном конкретном ответе. Это существенно разные подходы.
Оставшаяся проблема
Пять неудач из семи — это совершенно недостаточно. Контроллер принимал структурированные решения, но они не полностью находили отражение в соответствующем окончательном поведении. Это ставит открытый вопрос: заключается слабость в способности контроллера принимать решения или в способности генератора их выполнять?
Что показывают эксперименты
Внимание сместилось от процесса извлечения информации к тому, как извлеченная память должна влиять на выводы ассистента. Результаты теста PersistBench показали, что проявление льстивости под влиянием памяти является значимым видом сбоя в пилотной версии. Присвоение памяти явной эпистемической идентичности, разделение убеждения и факта, не помогало стабильно. Разделение процессов извлечения информации и её влияния, а также добавление слоя, отвечающего за использование извлеченной памяти, привели к частичному улучшению: снизилась степень серьезности сбоев в пилотной версии при сохранении полезной персонализации.
Каждый эксперимент также уточнял сам вопрос, переходя от определения того, является ли память релевантной, к выяснению того, какого рода информацией она является, и к определению того, какое влияние она должна оказывать. Следовательно, управление постоянной памятью касается не только того, что ИИ должен запоминать, но и того, когда, почему и в какой степени память должна влиять на поведение. Всё это основано на небольших выборках, и для подтверждения любых выводов потребуется более масштабная независимая оценка.
Статьи, лежащие в основе этой работы
Данная работа опирается на несколько научных статей: тестовую базу PersistBench, разработанную Pulipaka и соавторами (2026) и посвящённую рискам долгосрочной памяти; исследование Sharma и соавторов (2023) о льстивости в языковых моделях, показывающее, что ассистенты могут отдавать предпочтение ответам, соответствующим убеждениям пользователя, перед правдивыми; статью Packer и соавторов (2023) MemGPT о рассмотрении памяти и контекста как элементов, которыми система больших языковых моделей активно управляет; исследование Park и соавторов (2023) Generative Agents о агентах, которые хранят, синтезируют и извлекают информацию из опыта; а также статью Tan и соавторов (2025) MemBench, посвящённую более систематической оценке памяти агентов.
Связанная литература
- Когда панель управления зеленая, а агент действует неправильно: отслеживание состояния — Как сбои агентов скрываются в состоянии, передаваемом между работающими этапами, и что необходимо зафиксировать с помощью отслеживания, ограничений во время выполнения, записей маршрутизации и оценок.
- Создание агента для фильтрации потенциальных клиентов с использованием ИИ на Python с FastAPI и Pydantic — Преобразование необработанных потенциальных клиентов в квалифицированных: структурированный извлечение данных с помощью LLM, проверка с использованием Pydantic, оценка по правилам, хранение в PostgreSQL, очереди и возможность ручного рассмотрения.