Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
LLM-агента научили переносить исправления пользователя между сессиями и применять их к новым задачам. В работе Georgian AI Lab система forge_dc выполнила 95% проверяемых требований против 55% у обычного поиска по журналам, хотя препринт не прошёл рецензирование и все числа получили сами авторы. Для продукта с инструментальными агентами память теперь стоит проектировать не только как хранилище фактов, но и как механизм изменения поведения.
Исправление превращается в правило с условием запуска
Фактическая память отвечает на вопросы вроде «какую версию Python использует проект» или «какой формат отчёта предпочитает пользователь». Поведенческая память должна изменить следующее действие: проверить права доступа перед настройкой сети, обработать страницы ответа API или выбрать другой порядок вызова инструментов.
Сохранить текст исправления недостаточно. Фраза «для корпоративных клиентов используй QRR» должна сработать только для нужного сегмента, перейти на другой объект и не затронуть пользователей с иными правилами. Если положить исходный диалог в векторную базу, агенту придётся самостоятельно восстановить условие, автора и требуемое действие.
forge_dc собирает сигналы из явных исправлений и из журналов инструментов. Отдельная модель-анализатор ищет случаи, когда вызов завершился ошибкой, агент изменил параметры и затем получил успешный результат. Чтобы анализатор не придумывал общие советы по всему разговору, ему показывают только вызовы инструментов.
Затем компилятор превращает цепочку исправлений в короткую директиву в повелительной форме. Вместе с правилом он сохраняет тип, автора, условие запуска и точку процесса, перед которой правило могло бы предотвратить ошибку. Позднее исправление того же автора заменяет прежнее, а конфликт между пользователями разрешается во время запроса: система выбирает правило текущего пользователя, мнение большинства либо не подставляет ничего.
Правила форматирования подаются в начале работы, потому что запрос про компанию семантически не похож на требование ставить символ валюты рядом с суммой. Правила, зависящие от данных, система ищет повторно между вызовами инструментов. Когда в накопленном контексте появляется условие запуска, директива попадает в системную инструкцию перед следующим решением.
Как проверяли перенос поведения на новые задачи
Для проверки авторы собрали DC-Bench: 71 сценарий по девяти видам поведения в двух областях — финансовом анализе и поддержке клиентов. Сначала агент получал исправление на одном объекте, затем должен был применить его к другому. Поэтому тест измеряет не поиск знакомой фразы, а изменение действия в новой ситуации.
Сценарии построены из выполненных агентами трасс, но инструменты заменены детерминированными имитациями. Это позволяет повторять одинаковые ошибки и ответы без влияния внешних API. Проверка охватывает условные правила, исключения, перенос между объектами, конфликты во времени и обучение на собственных сбоях агента.
Главный выигрыш дала не сама структура хранилища, а сочетание трёх решений: директива вместо описания прошлого разговора, условие запуска вместо поиска только по исходному запросу и подстановка непосредственно перед действием. Вариант с пояснением причины работал так же или немного хуже короткой команды: модель иногда начинала обсуждать правило и отменяла его.
forge_dc добавляла в запрос в среднем 159 токенов, тогда как вариант с графом и исходными фрагментами журналов — 1651. Короткая запись не только экономила контекст, но и чаще меняла поведение: длинные свидетельства конкурировали с текущей задачей за внимание модели.
Границы проверки существенны для архитектурного решения. Сравнивались последовательно усложнявшиеся системы, поэтому эксперимент не отделяет вклад компиляции правил от способа подстановки и разрешения конфликтов. Бенчмарк, критерии оценки и адаптации конкурирующих подходов подготовила та же команда; тест охватывает заданные версии моделей, две предметные области и имитированные инструменты.
Что менять в архитектуре продуктового агента
Работа меняет планы команд, если агент регулярно вызывает инструменты, обслуживает одних и тех же пользователей и получает повторяющиеся исправления. Складывать все журналы в общее хранилище и искать похожий фрагмент перед началом задачи недостаточно. Поведенческие правила стоит хранить отдельно от фактов, даже если оба вида памяти используют одну поисковую инфраструктуру.
В схеме правила нужны как минимум действие, условие запуска, область применения, автор и связь с исходным свидетельством. Отдельно придётся поддержать замену устаревших директив и конфликты между пользователями. По умолчанию память должна молчать: ошибочно сработавшее правило способно испортить результат, который агент без подсказки уже выдавал правильно.
Поиск также становится частью цикла исполнения. Агенту нужен первый набор безусловных правил перед стартом и повторная проверка после значимых результатов инструментов. Канал подстановки следует тестировать при каждой смене модели: в эксперименте ранние и поздние правила лучше работали в разных частях сообщения.
Компиляция требует отдельного модельного вызова и обходится дороже простого сохранения журнала. В приведённом учёте токенов эта разовая стоимость окупалась примерно после четырёх запросов за счёт более коротких запусков агента. Такой расчёт подходит для повторяемых процессов, но слабее обосновывает отдельный контур памяти для редких или одноразовых задач.
Приёмочные тесты тоже стоит изменить. Проверять нужно не только то, нашла ли память нужный текст, но и применил ли агент правило, не перенёс ли его на неподходящий случай и не ухудшил ли базовое поведение. Именно этот переход от качества поиска к качеству действия составляет практический результат работы.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
