Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
LIMBO научился решать для каждого задания, стоит ли LLM-агенту подмешивать прошлый опыт и сколько вычислений ему выделить, не дообучая модель. В препринте UCSD и West Virginia University, который не проходил рецензирование и где все числа получили сами авторы, подход почти сохранил долю правильных решений сильнейших вариантов с памятью, снизив расходы до 83%, в среднем на 53%. Это позволяет заменить единый лимит памяти управлением по ситуации.
Как LIMBO выбирает память и бюджет
LLM-агенты могут переносить опыт между заданиями через повтор опыта (experience replay): добавлять в новый запрос успешные траектории с командами, ответами инструментов и итоговым решением. Но каждая траектория занимает контекст, увеличивает число токенов и может сбить формат действий, если новое задание с ней не связано.
LIMBO ставит перед агентом отдельный контроллер. До запуска базовой модели он выбирает один из режимов: работать без памяти, добавить недавние траектории целиком, сжать их или извлечь наиболее подходящие записи. Вместе с режимом контроллер задаёт лимиты на генерацию, шаги диалога и вызовы инструментов.
Решение принимает контекстный бандит — алгоритм, который пробует доступные действия и уточняет их ценность по полученному результату. Он строит два прогноза для каждого варианта: вероятность правильного решения и ожидаемые расходы. Затем выбирает сочетание с лучшим балансом, оставляя небольшой запас на исследование ещё недостаточно проверенных вариантов.
Для прогноза используются признаки, доступные до обращения к LLM: размер и состав запроса, число требуемых навыков, качество найденных воспоминаний, недавняя доля успехов, расходы и ошибки. После выполнения задания контроллер получает сигнал правильности и фактическую стоимость, обновляет оценки и сохраняет успешную траекторию в память.
Контроллер проходит поток заданий один раз. Ему не нужны веса модели, градиенты, ответы модели-учителя или отдельный набор для обучения, поэтому тот же механизм можно поставить перед локальной моделью или коммерческим API.
Метод проверяли с Qwen 2.5 7B, Llama 3.1 8B и GPT-4o mini в средах DBBench и OS Interaction из LifelongAgentBench. Каждый эксперимент включал поток из 500 последовательных заданий с автоматической проверкой результата; такой протокол показывает перенос команд и способов работы с инструментами, но не охватывает произвольные производственные процессы.
Одинаковая память оказалась выгодна не всем моделям
На DBBench с Qwen максимальный фиксированный буфер увеличивал расходы более чем впятеро, а долю правильных решений — только на 2 процентных пункта. LIMBO чаще выбирал дешёвый режим без памяти, когда базовая модель уже справлялась с SQL-заданиями.
С Llama на той же среде получилась обратная картина. Без прошлых траекторий модель решала 20,8% заданий, а с LIMBO — 66,2%; при этом метод тратил на 54% меньше сильнейшего варианта с фиксированной памятью. Здесь контроллер чаще извлекал подходящие примеры, но не выдавал максимальный вычислительный бюджет всем запросам подряд.
В остальных сочетаниях моделей и сред LIMBO также находился на границе Парето по качеству и расходам: среди сравниваемых методов не было варианта, который одновременно решал больше заданий и стоил дешевле. Существенен не один универсальный режим, а различие политик: сильной модели в DBBench память почти не требовалась, тогда как задания с командами операционной системы чаще выигрывали от найденных траекторий.
Что меняется в архитектуре агента
Работа не предлагает заменить хранилище памяти или способ поиска. Она добавляет над ними управляющий слой: существующие варианты памяти становятся доступными действиями, а контроллер решает, какое из них применить сейчас. Новый способ сжатия или поиска можно подключить как ещё один вариант, не меняя базовую LLM.
Для команды, которая строит агента на последовательных заданиях, главный практический вывод — не фиксировать число примеров в запросе для всего продукта. Полезнее записывать по каждому запуску исход, стоимость, использованные инструменты и сохранённую траекторию, а затем выбирать память вместе с вычислительным лимитом.
Такая схема требует быстрого сигнала о результате. В работе это двоичная автоматическая проверка после каждого задания. Если продукт не умеет определить успех до следующего запуска или получает слишком мало однотипных заданий, контроллеру будет не на чем обновлять политику; сначала понадобится измеримый критерий выполнения.
LIMBO также не отменяет ручные предохранители: лимиты расходов, допустимые инструменты и правила хранения данных остаются частью системы. Но фиксированный буфер памяти уже не выглядит разумным значением по умолчанию. Прототипировать стоит слой выбора, который может отказаться от прошлого опыта, когда его ожидаемая польза не покрывает дополнительные токены и задержку.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
