Память ИИ-агента: что считать обучением?

Агент запомнил ваше последнее исправление. В следующей задаче он снова использовал это решение. Можно ли сказать, что он чему-то научился?

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

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

Чему ИИ-агент учится на исправлении?

В данном случае обучение означает изменение внешнего состояния, которое влияет на последующее решение. Речь не об обновлении весов модели. Запомненный выбор может повлиять на промпт, помочь обработать знакомую ситуацию или стать свидетельством для разбора. Это разные способы использовать одно наблюдение.

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

В препринте Grounding Agent Memory от 10 сентября исследуется проверка кандидатов в память по данным окружения вместо доверия только завершённым траекториям. Эти эксперименты не измеряют работу Norman.

Что установила наша проверка памяти агента?

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

Все перечисленные ниже признаки обнаружились в этом снимке. Для каждого мы намеренно ограничиваем возможный вывод.

Это позволяет сформулировать конкретный вывод из опыта Norman: подтверждение, пересмотр, применение и оценивание наблюдаемы. Их нельзя объединять в один статус «выучено». Мы уже описывали, как исправления попадают в память. Здесь вопрос другой: что инженерный отчёт вправе заключить по получившимся записям.

Почему повторная обратная связь не равна уверенности?

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

Рассмотрим полностью вымышленный пример. Команда хочет назначать знакомым записям метку A. Позже она меняет метку одной записи на B. Система памяти может сразу запомнить B. Но ей ещё предстоит различить утверждения «B является последним выбором» и «B подходит для каждой похожей записи». Повторение B не отвечает на этот вопрос, пока не определена правильная область применения.

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

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

Почему применение памяти не доказывает правильность?

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

Поэтому снимок «текущий выбор B, ранее применялось» не устанавливает, что применялось именно B. Часть применений могла относиться к A. Счётчик по-прежнему полезен для понимания активности, но последовательность событий уже потеряна при сведении данных к текущей записи. Ни величина счётчика, ни красивый график не восстановят эту последовательность.

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

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

Как оценивать память ИИ-агента?

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

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

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

{
  "claim": "Предпочитать метку B в указанном контексте",
  "scope": "Заданный процесс и условия совпадения",
  "evidence": "Явное исправление",
  "contradiction_policy": "Пересмотреть утверждение",
  "evaluation": "Последующие случаи, включая несовпадение области"
}

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

Чего мы пока не установили?

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

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

В следующем эксперименте мы бы связали последующие задачи с состоянием памяти в момент выполнения, а затем разделили уместное применение, неуместное применение и отказ от использования. Это предлагаемая проверка, а не уже полученный результат. Мы изучаем, как сделать такое различие полезным, не превращая публичный отчёт в раскрытие клиентской активности.

Что должно быть в полезном отчёте об обучении?

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

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

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