Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
LLM-агента научили сохранять урок из прошлого эпизода только после проверки, что он помогает похожим задачам и не ломает прежние навыки. Команда Nanyang Technological University, Georgia Institute of Technology и других университетов назвала схему FGSE; доля вредных сохранённых обновлений составила 3,6%, но работа, которую пока не рецензировали, приводит числа из замеров самих авторов. Для продуктовых команд это превращает память агента из журнала наблюдений в управляемый контур изменений, но требует проверяемых задач и отдельного бюджета на прогоны.
Удачный эпизод ещё не делает правило безопасным
Агенты могут улучшать поведение без изменения весов модели: после выполненной задачи они формулируют урок и добавляют его в память, подсказку или рабочий регламент. Проблема возникает, когда локально полезное правило начинает действовать в ситуациях, которые лишь внешне похожи на исходную.
Например, агент может успешно исправить порядок вызова инструментов и записать слишком широкое правило. Оно поможет на соседних задачах, но сработает там, где порядок уже был правильным, или вступит в конфликт с ранее выученным поведением. Диагностические эксперименты в работе показали именно такую связь: чем менее точно задана область применения урока, тем чаще он вредит граничным и уже решённым задачам.
FGSE поэтому хранит новый урок не как свободный текст, а как структурированную гипотезу. Она описывает условие применения, изменение поведения, ожидаемый проверяемый эффект и способ проверки. До решения о сохранении гипотеза действует только во временном состоянии агента и не меняет постоянную память.
Память проходит три проверки перед сохранением
Сначала гипотезу запускают на задачах, где она должна переносить полезный эффект исходного эпизода. FGSE сравнивает поведение агента с временным правилом и без него по одному и тому же внешнему проверяющему механизму: валидатору успеха, состоянию базы данных, модульному тесту или другому наблюдаемому результату.
Затем система ищет контрпримеры. В эту группу входят граничные случаи, нарушения условия применения и отвлекающие задачи, похожие по форме, но требующие другого поведения. Такая проверка должна выявить короткие пути и слишком общие правила, которые обычный повтор исходной задачи не обнаружит.
Третья группа состоит из архивных задач, которые агент уже решал. Если временное правило ухудшает их результат, FGSE считает это регрессией. В постоянную память попадают только гипотезы, которые дают переносимый выигрыш, выдерживают контрпримеры и сохраняют прежние навыки.
Полезную, но слишком широкую гипотезу можно один раз уточнить: сузить условие применения и повторить проверки. Остальные кандидаты система отклоняет. После сохранения она продолжает учитывать нарушения и перестаёт извлекать правило из памяти, если оно регулярно не выполняет обещанный эффект.
Схема подходит не каждому агенту, но меняет архитектуру самообучения
На WebArena FGSE получил успешность 39,8%, а средний результат AppWorld составил 78,8. На τ-Retail показатель выполнения задачи с первой попытки достиг 0,724. В отдельном анализе шлюз сохранил 104 кандидата из 380 и отсеял остальные, хотя часть отклонённых обновлений улучшала целевую задачу.
Удаление любого из основных элементов — структуры гипотезы, проверок переноса, контрпримеров, архива регрессий или уточнения области применения — ухудшало результаты на всех показанных наборах задач. Замена внешних проверок на модель-оценщик тоже работала хуже: решение LLM о качестве обновления оказалось менее надёжным, чем проверяемый результат выполнения.
Схему проверяли на веб-задачах WebArena, приложениях AppWorld, работе с инструментами τ-Retail и τ-Airline, а также на долговременной памяти LongMemEval и LoCoMo. Сравнение охватывало подходы на основе рефлексии, памяти и изменения контекста. Все эти среды позволяют проверить итог действия, поэтому вывод прежде всего относится к агентам с исполняемыми валидаторами или явно наблюдаемым состоянием.
Командам, которые уже накапливают поведенческие правила между эпизодами, стоит разделить память на кандидатов и подтверждённые записи. Для каждого кандидата понадобятся область действия, архив успешных сценариев, набор граничных проверок и история нарушений. Это не требует переобучать модель, но увеличивает число запусков агента перед сохранением опыта.
Главное архитектурное следствие — проверяемость нужно проектировать одновременно с самообучением. Если продукт не умеет независимо определить, достигнут ли ожидаемый эффект, шлюзу не на чем основывать решение. Там, где результат можно подтвердить состоянием системы или тестом, FGSE предлагает практичное правило: считать опыт изменением поведения только после проверки переноса и отсутствия ущерба.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
