Пошукова довгострокова пам’ять для агентів інженерії даних
Як система інженерії даних з кількома агентами припинила повторне виправлення одних і тих самих помилок: автоматичне фіксування, обмежені щоденники, відібрані рівні та відтворення на рівні контексту.
Джерела: Learning from Experience: Searchable Long-Term Memory for Data Engineering Agents
Агенти без стану добре вирішують проблеми. Вони погано пам’ятають, що вже їх вирішили.
Проблема амнезії
Уявіть собі агента, який майже годину працює над помилкою NoClassDefFoundError у щойно створеному нотатнику Databricks. Він аналізує стек-трейс, знаходить бібліотеку, відсутню у кластері, застосовує виправлення та підтверджує успішну роботу. Це якісне автономне відлагоджування.
Через тиждень інша пайплайн-система стикається з тією самою помилкою, але агент не має жодного уявлення про те, що вже бачив її раніше. Уся процедура відлагоджування повторюється знову з повною витратою ресурсів, і цього разу існує реальна ймовірність обрання іншого виправлення.
Це не невдача моделі. Це типова поведінка агентів за замовчуванням, і вони забувають три способами:
- Коли сеанс закінчується, все, що було навчено під час нього, зникає.
- Довгі сеанси зрештою піддаються узагальненню чи стисненню, що зберігає загальну сюжетну лінію, але часто видаляє важливі деталі реалізації.
- У багатоагентних системах агенти-робітники зазвичай починають роботу з чистого контексту, не успадковують нічого від попередніх агентів та не зберігають нічого після завершення своєї задачі.
Команда, яка керувала багатоагентною системою для створення конвеєрів типу Databricks lakehouse, сплачувала цей «податок на амнезію» у всіх трьох аспектах. Їхнім рішенням став шар довгострокової пам’яті з можливістю пошуку.
Що означає «пам’ять з можливістю пошуку»
У агентних системах під пам’яттю розуміють дві різні речі, тому ці терміни потрібно чітко визначати.
Вікно контексту виконує функцію робочої пам’яті агента. Усе, що знаходиться в ньому, миттєво доступне для моделі, але лише протягом тривалості сеансу. Як тільки інформація зникає, з точки зору агента вона втрачена.
Довгострокова пам’ять — це постійний сховище, яке існує довше за сеанси, завдання та агентів. Однак самого лише зберігання інформації недостатньо. Збережена інформація стає корисною пам’яттю лише тоді, коли вона автоматично фіксується, може ефективно пошукуватися та викликається у вікні контексту за потреби. Саме останній крок має вирішальне значення. Ідеальний урок, який ніколи не використовується, фактично не існує, а урок, який було отримано, є марним, якщо він не потрапляє до агента, який приймає рішення.
Когнітивна наука пропонує таксономію, яка добре відповідає системам агентів:
- Епізодична пам’ять зберігає записи конкретних минулих досвідів: архівовані транскрипції сеансів, попередні невдачі та способи їх усунення, рішення, прийняті під час попередніх версій.
- Семантична пам’ять зберігає структуровані факти, такі як «ентитет X належить до продукту даних Y» або «ця система-джерело автентифікується таким чином», бажано з інтервалами дійсності, оскільки факти змінюються.
- Процедурна пам’ять — це ноу-хау: файли інструкцій, навички та правила, які завантажуються під час кожної сесії.
Два рівні пам’яті
Одне рішення значно спростило ситуацію: розділення пам’яті на два рівні.
Рівень 1, кураторська пам’ять. Невеликий набір правил, який підтримується вручну та завантажується під час кожної сесії. Йдеться про архітектурні стандарти, вимоги до безпеки, правила найменування та обмеження управління. Місце в пам’яті є дорогим, тому цей рівень призначений для того, що має бути завжди доступним.
Рівень 2: пошукова пам’ять. Великий архів досвіду, який автоматично фіксується та відтворюється лише у відповідних ситуаціях: перевірені рішення проблем, результати діагностики, уроки, отримані під час розгортання, та ознаки частих збоїв. За замовчуванням він не враховується під час введення запиту.
Основне правило:
Факт, якого потрібно дотримуватися щоразу, має знаходитися у рівні з відібраними даними. Факт, який корисний у схожих ситуаціях, має бути у рівні з пошуковою пам’яттю.
Такий поділ дозволяє зберігати знання, не перевантажуючи вікно контексту.
Багатоагентна система, якій це було потрібно
Розглядувана система керує всім життєвим циклом обробки даних, перетворюючи бізнес-вимоги на готові до використання конвеєри та панелі керування. Оркестратор координує спеціалізованих агентів, кожен з яких виконує лише одне завдання та має лише необхідні інструменти:
- Функціональна специфікація — це процес читання заявки на формулювання вимог, складання специфікації та отримання схвалення від людини, яка її подала.
- Технічний дизайн — це перетворення схваленої специфікації на план даних, що включає контракти та мапування від джерела до місця призначення.
- Збір даних, їх трансформація та інтеграція — це створення фактичного коду потоку обробки даних. Це означає використання „бронзових“ ноутбуків для отримання даних з Kafka, SAP, REST чи файлів, „срібних“ ноутбуків для перетворення даних та „золотих“ вимірних моделей, усе це в рамках певної структури.
- Перевірка — це єдиний елемент, якому дозволено працювати з живим кластером. Він запускає кожен створений ноутбук на тимчасових таблицях для тестування та перевіряє результати.
- Репозиторій — це інструмент для керування гілками, збереженнями та запитами на з’єднання.
- Моніторинг — це процес стеження за процесом 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")
Коли ситуація повертається до початкового стану, агент отримує урок, заснований на попередньому успішному рішенні:
„Бронзовий“ зошит для обробки замовлень зламався на версії DBR 14.3 через помилку
NoClassDefFoundError, пов’язану з десеріалізатором Avro. Що це виправило: пряме вказування бібліотеки серіалізатора у конфігурації кластера завдань.
Різниця значна. Замість того, щоб знаходити рішення з нуля, агент виходить з доказів того, що вже спрацювало. І користь полягає не лише у швидкості — це також послідовність. Без пам’яті два агенти, які стикаються з однією проблемою, можуть обрати різні, на перший погляд розумні рішення. З пам’яттю система обирає те, що вже довело свою ефективність, та продовжує його використовувати.
Подібні покращення спостерігалися й в інших сферах. Тепер монітор CI/CD включає до своїх діагностичних звітів історичні записи про прояви певних помилок, функції запуску сеансів відновлюють актуальний нещодавній контекст, а спеціалізовані агенти з часом набувають досвіду, замість того щоб постійно його відновлювати.
Не потрібне повторне навчання. Цикл навчання знаходиться поза моделлю: досвід, уроки, зберігання, пошук, застосування.
Уроки з реальних умов експлуатації
Будьте обережні з історичними даними, які додаються пізніше. Перша спроба імпортувала великі обсяги старих записів. Результати виявилися розчаровуючими, оскільки старі дані часто затьмарювали новіші, кращі уроки та ускладнювали процес пошуку. Команда відмовилася від масового імпорту та почала все заново з моменту, коли почався запис даних. Актуальність та якість мають більше значення, ніж обсяг.
Записуйте спогади простою мовою. Ця система пропонує компактні формати запису, які команда і використала. Пошук є найефективнішим, коли збережений запис містить саме ті слова, які будуть використані під час подальшого пошуку: назви продуктів, назви елементів, повідомлення про помилки та класи винятків. У зберіганні спогадів важливіша здатність до пошуку, ніж мала кількість інформації.
Ретельно обирайте, що записувати. Не кожна побачена інформація заслуговує на постійне зберігання. Варто зберігати підтверджені виправлення, перевірені результати та універсальні уроки. Варто пропускати рутинні журнали, тимчасові спостереження, повторювані оновлення статусу та конфіденційну інформацію. Погано організовані спогади швидко накопичуються та можуть завдати більше шкоди, ніж їх відсутність.
Висновки
Коли співробітники постійно виконують реальну роботу, вони створюють досвід, який варто зберігати. Ось що пропонує ця система:
- Розділіть пам’ять на ретельно підібрані правила та можливості пошуку інформації.
- Автоматично фіксуйте уроки, особливо перед стисненням контексту.
- Надавайте працівникам вузькі, залежні від їхніх обов’язків права доступу.
- Звертайтеся до попередніх даних перед пошуком рішення, якщо схожа проблема вже могла бути вирішена.
- Включайте використані дані безпосередньо до запиту.
- Розглядайте пам’ять як доказ, а не як безумовну істину.
- Надавайте перевагу якості пам’яті перед її обсягом.
Найглибшим уроком є архітектурний підхід. Багато зусиль вкладається у те, щоб роботи ставали розумнішими, але на практиці довгострокова цінність полягає у здатності систем пам’ятати.
Пов’язана література
- Від моделей до агентів: переробка трьох ліній захисту — Як управління MLOps відображається у системах агентів: що має додати кожна з трьох ліній, де знаходяться прогалини та що сигналізують регулятори ЄС, FDA та фінансової сфери.
- Створення пам’яті агента, яка зберігає інформацію під час розмови без накопичення — Трьохрівнева структура пам’яті для агентів: дозволяти сесійному стану зникати, зберігати довгострокові записи у невеликому обсязі та у форматі, що дозволяє їх редагувати, а також отримувати актуальні дані. Також розглядається проблема невдалих передач даних між кількома агентами.