Поисковая долгосрочная память для агентов инженерии данных

Агенты без состояния хорошо решают проблемы. Однако у них плохо получается запоминать, что они их уже решили.

Проблема амнезии

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

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

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

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

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

Что означает «память с возможностью поиска»

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

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

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

Когнитивная наука предлагает таксономию, которая хорошо соответствует системам агентов:

• Эпизодическая память хранит записи конкретного прошлого опыта: архивированные протоколы сессий, предыдущие сбои с способами их устранения, решения, принятые в предыдущих версиях.
• Семантическая память хранит структурированные факты, такие как «энтитет X принадлежит к продукту данных Y» или «эта исходная система аутентифицируется таким образом», желательно с интервалами действительности, поскольку факты могут меняться.
• Процедурная память — это набор знаний и навыков: файлы с инструкциями, умения и правила, загружаемые при каждой сессии.

Два уровня памяти

Одно решение устранило большую часть сложности: разделение памяти на два уровня.

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

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

Ориентир:

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

Такое разделение позволяет сохранять знания, не перегружая окно контекста.

Система с несколькими агентами, которой это было необходимо

Рассматриваемая система обрабатывает весь жизненный цикл работы с данными, преобразуя бизнес-требования в готовые к использованию потоки обработки и панели управления. Оркестратор координирует специализированных работников, у каждого из которых есть своя задача и только необходимые для нее инструменты:

• Функциональное описание включает в себя прочтение заявки на разработку, составление спецификации и получение одобрения от пользователя-заказчика.
• Технический проектирование преобразует утверждённую спецификацию в план данных, включающий контракты данных и сопоставления исходных и целевых данных.
• Приём, преобразование и интеграция ведут к созданию фактического кода пайплайна. Это включает в себя ноутбуки уровня Bronze, собирающие данные из Kafka, SAP, REST или файлов, ноутбуки уровня Silver, преобразующие данные, и дименциональные модели уровня Gold, всё это организовано по схеме медальона.
• Проверка — единственный агент, которому разрешено работать с рабочим кластером. Он запускает каждый сгенерированный ноутбук на временных таблицах для тестирования и проверяет результаты.
• Хранилище управляет ветками, коммитами и запросами на слияние кода.
• Мониторинг отслеживает процесс CI/CD после слияния изменений.

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

Отслеживание затрат показывает, сколько всё это стоит.

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

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

Проектирование памяти для множества агентов

Для решения этой проблемы используются четыре механизма.

1. Автоматическое захват

Хуки во время работы агента активируются в два момента: когда сессия закрывается и непосредственно перед сжатием контекста. Каждый из них считывает транскрипт и сохраняет повторно используемые уроки в хранилище памяти. Никому не нужно помнить о необходимости написания документации или обновления базы знаний.

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

2. Доступ в определённых пределах

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

3. Дневники, специфичные для ролей

Каждый рабочий процесс имеет собственное приватное пространство имен памяти. Сбои во время выполнения и проверенные способы их устранения фиксируются в дневнике агента валидации, в то время как монитор CI/CD собирает информацию о типах сбоев и эффективных решениях. Остальные агенты также хранят аналогично ограниченные объемы данных.

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

4. Воспроизведение на уровне контекста

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

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

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

Реализация в MemPalace

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

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

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

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

Агенты получают доступ к памяти через MCP. Оркестратор видит весь набор инструментов, тогда как рабочие процессы видят только функции diary_read, diary_write и search; границы использования инструментов определяются средствами программирования, а не промптами.

MemPalace был выбран потому, что он ориентирован на локальные решения, бесплатен и легко интегрируется, однако архитектура не зависит от него. Mem0, Zep или Letta могут выполнять ту же функцию. Важен не фреймворк, а цикл обратной связи: фиксация опыта, его хранение и использование при возникновении аналогичной проблемы.

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

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

mempalace_search(query="NoClassDefFoundError DBR 14.3")

Когда появляется аналогичная ситуация, агент использует урок, извлечённый из ранее успешного решения:

В программе «Bronze notebook for Orders» произошла ошибка на версии DBR 14.3 с сообщением NoClassDefFoundError, связанным с десериализатором Avro. Что помогло её устранить: явное указание библиотеки сериализатора в конфигурации кластера задач.

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

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

Не требуется повторная обучение. Цикл обучения происходит вне самой модели: накопление опыта, извлечение уроков, хранение информации, ее поиск и применение.

Уроки из практики

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

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

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

Выводы

Каждый раз, когда сотрудники выполняют одну и ту же работу неоднократно, они накапливают опыт, который стоит сохранить. Что предлагает данный подход:

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

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

Связанная литература

• От моделей к агентам: переработка трёх линий защиты — Как принципы управления MLOps применяются в системах агентов: что должно добавить каждая из трёх линий защиты, где находятся пробелы, и какие сигналы посылают регуляторы ЕС, FDA и финансовой сферы.
• Создание памяти агента, способной сохранять информацию в ходе диалога без её накопления — Трёхуровневая структура памяти для агентов: позволяющая удалять состояние сессии, сохранять долгосрочные записи в компактном и редактируемом виде, а также получать актуальные данные. Также рассматриваются ситуации с сбоями при передаче данных между агентами.

Объяснение агентов: инструменты, системные промпты и цикл мышления-действия — Пошаговое руководство для начинающих о том, как работают ИИ-агенты: почему чат-модели забывают, как описываются инструменты для ЯЗЫКОВ БОЛЬШОГО МАСШТАБА, системные промпты, метод ReAct, кодовые агенты и наблюдения.